Complex GUI Architecture Discussion? 367
XNuke asks: "I have been searching for intelligent discussion (on dead trees or otherwise) of the issues involved in designing very complex GUIs. Things on the level of TecPlot, AutoCad, 3DS, etc, where there may be very many different views of the same data and there are many degrees of freedom for the user. I am not interested in 'where to put the buttons', but rather the nuts and bolts of making the 'Well Designed UI' work. I guess I am looking for a sort of 'Design Patterns applied to a big deskptop application' sort of discussion. It is no problem to find discussions of Model-View-Controller concepts at the component level, but at the application level there seems to be nothing. Too often the architectural level discussions encompass non-interactive, server side design issues and not the extremely chaotic problems a client side application with many degrees of freedom has. Short of wading through megabytes of source code for KWord et. al., does anyone know of any digested information? There is obviously no 'One Solution' to this, but there must be something out there."
Human Factors (Score:2, Offtopic)
Re:Human Factors (Score:2, Offtopic)
http://www.edwardtufte.com/290901521/tufte/book
Re:Human Factors (Score:2, Informative)
Re:Human Factors (Score:2, Offtopic)
These are the same people who think having one common title bar that is shared by all people is a good thing ...
Sorry, but your statement makes no sense. Are you speaking about the use of one menu bar shared by all windows of an application?
If yes, there are two major advantages to this design: menus are always in the same place, and one menu bar takes up less screen space than multiple menu bars.Whoa. They didn't choose; the situation was dicatated by the fact the until System 6 there was NO multitasking! Cooperative multitasking was the quickest way to implement multitasking without breaking existing applications. Apple stated very early on that they would eventually implement preemptive multitasking but, alas, it never came to pass. The endeavor died with the failure of Copeland. Then Apple bought NeXT.
And lets not forget the whole mhz myth marketing scheme. I think you should take anything Apple tells you with a block of salt.
Don't you mean the Intel Mhz myth? Where a higher clock speed CPU is automatically faster than a lower clock speed CPU just because one number is bigger than the other?
The Question is NOT about Human Factors (Score:5, Informative)
The poster is asking about software archecture and design patterns. Think of it this way: Okay I want to code a new IDE, but I want to code it well. So what's the best way to get the UI to talk to the code that actually compiles the source code. Or another example: a database management suite. How do I best seperate the UI code from the code that actually talks to the database. And once I have them in seperate modules, how do I get them to talk to each other? This is a question about computer software design, not UI design (although, UI design is very important). The advantage to thinking this way though, is that when software is coded this way, people who do understand "Human Factors" and proper User Interface Guidelines can tweek and adjust the UI without modifying the underlying code that performs the logic of the application.
The Model-View-Controller design pattern mentioned is a good start, although I'm not sure how well it scales to larger, more complex programs. (I'd love to hear from someone who has experience in this.) And of course the "Design Patterns" book by the 'Gang of Four' has other designs that might be more appropriate. Also, most complex applications will incorporate multiple design patterns.
This is a very interesting question, one I've had before and I haven't found any good resources yet either. Perhaps the best resource would be to actually go through the code of a complex program like Mozilla, OpenOffice, or the like. Fun? Easy? Probably not, but you'd learn a lot.
Re:The Question is NOT about Human Factors (Score:3, Insightful)
Actually, in this question lies the answer. On a sheet of paper, draw a line separating the paper into two halves. In one half write "UI Module" and in the other half write "Database Interface Module".
These two modules can be written, so that the UI module uses only the public interfaces of the database module. This is the high level design of the application.
Designing each module well is an entirely different challenge, since the quality of the database module's interfaces determine how resilient the application is to changing requirements.
I guess the lesson here is that the really high-level design is trivial, but the design of each module is very hard and should be done by someone experienced in such things. Reading good books on the subject is only the beginning.
Re:The Question is NOT about Human Factors (Score:5, Insightful)
On a sheet of paper, draw a line separating the paper into two halves. In one half write "UI Module" and in the other half write "Database Interface Module".
Actually, this is considered bad form in an OO design. The UI "Module" (classes) should only talk to the Model classes, while the Model classes may or may not talk directly to database classes. They may be mapped to database tabels thru an indirection layer.
There is some great discussion of this at Martin Fowlers website [martinfowler.com].
Re:The Question is NOT about Human Factors (Score:2, Interesting)
What do you define as a large, complex program? A lot of enterprise software work done for F500 companies are built as web applications (Struts-esque) using the MVC pattern. These applications scale to 10,000 users (and more) and obviously run on some serious hardware setups. Most of the applications aren't that sexy...they really just streamline business processes and help (hopefully, but the cynic in me says doubtfully) save money.
Anyway, back to the original question by the OP, there really is a dearth of information on the areas between architectural level patterns(MVC, blah blah blah) and the high level interaction-design/usability/experience world. I've found that in the software industry most of the nuts and bolts tend to be one-offs and specialized solutions, sort of whatever-it-takes-to-build-the-bridge. There are definitely existing toolkits, but when in comes down to it there's a buttload of unrefined work that needs to be done. Of course this is the case in any part of a significantly complex application.
In my experience I've built some pretty nifty ways of building UIs and in some cases I've abstracted out a lot of the nitty-gritty. The interesting part, though, is that most of the clever stuff I came up with was already pretty much expressed in existing design patterns (GOF) or done the same way decades ago, just with different paradigms (web vs. mainframe, which addmitedly aren't too different). I guess my point is that these problems have been repetitively solved over time, but so little of it has been truely formalized in the same manner that other aspects of computer science and software engineering have.
But honestly speaking user interfaces have really taken 2nd (or 3rd, or 4th, or -gasp- Nth) place to other topics in the ivory tower of computer science. Most kids coming out of CS undergrad programs are more excited about things like optimization, scalability, or building complex software like OSes and databases. After all, these are the hardcore, tried and true, well formalized product hallmarks of computer science.
To get back on topic again, the OP mentioned being reluctant to wade through the source of KWord. It's a tedious activity, but studying how existing or even historical applications were designed can be highly beneficial. As I said above I've invented a new wheel quite a few times only to find out that it only mirrored a previously built solution.
Re:Use Cases (Score:3, Interesting)
Me, I find UI to be king. No one cares if good code or magical elves are making things work; it has to have a good UI. The best UIs appear to be those crafted by skilled UI designers that outrank the developers; they can give the developers an idea of what they want to be able to do, and let the latter group decide precisely how to best implement the UI group's wishes. They don't have autonomy, though.
Computers, and software, have to be developed from the outside in, is what it boils down to.
Re:Human Factors (Score:2, Informative)
http://www.iarchitect.com/mshame.htm [iarchitect.com]
Re:Human Factors (Score:3, Interesting)
I wish the Slashdot coders had read that book. I got my butt jumped because I used ['s to encapsulate a bold tag instead of the typical HTML greater-than signs. According to some, my being used to VBulletin syntax (used by several forums I vist) is a sign of how truely stupid I am. I think it's a sign of how unfriendly Slashdot's interface can be.
It's not a poke at Slashdot, but rather an observation that book helped me make about UI. Slashdot's just a handy example. Now, when I write web pages, I have a better perspective of the things I should do to prevent mistakes like the bracket example from being irrecoverable.
Anybody who's interested in design should read that book, it helps you understand why humans make the mistakes they do and what you can do to accommodate them. Hint: It's not because we're all too stupid to read a manual.
Re:Human Factors (Score:5, Insightful)
He doesn't want fluffy designer stuff. He wants to implement a complex U/I with multiple views on the same data. Designing the interface is trivial. Implementing it is the problem. His question has no obvious answer other than: "just jump in; you'll get it right on the 2nd or 3rd try like the rest of us."
BTW, MVC is crap. It falls down for much smaller problems than what you're looking at.
My Favorite GUI (Score:3, Funny)
Re:My Favorite GUI (Score:2, Funny)
#
Re:My Favorite GUI (Score:3, Insightful)
Re:My Favorite GUI (Score:2)
Re:My Favorite GUI (Score:2, Funny)
Nougat.
Re:My Favorite GUI (Score:3, Funny)
<form>
<input type="submit" value="C:\>">
<input type="text" size=60 name="command">
</form>
Your favorite GUI sux0rz (Score:2, Redundant)
[foo@izumi bash]$ _
Re:Your favorite GUI sux0rz (Score:2)
Re: (Score:2, Informative)
Re:HCI (Score:3, Insightful)
Actually, Google's interface is one of the best examples of design and functionality going.Check out their cleanly laid out News area.Beats CNN, etc.
That's got to have had something to do with its' universal appeal
For UI Reference (Score:3, Informative)
Re:For UI Reference (Score:2, Informative)
I'm on a reading tear at the moment of old computer books where they are talking about the design of the interfaces that we have all come to know and love (books from a time when these were all new ideas). I plan on topping it off with Jeff Raskin's new book. [barnesandnoble.com]
As far as actually designing interfaces goes, several of my friends who actually design interfaces for a living have claimed that this book [barnesandnoble.com] has been a tremendous help in providing a direction and design philosophy. Most people who design interfaces for the web, for instance, don't seem to ask themselves questions like "How would I design a telephone if I had never seen, never heard of what this device was or was supposed to do".
Mac gets it right. (Score:2, Offtopic)
Re:Mac gets it right. (Score:2, Troll)
Also, iirc Interface Builder is based on absolute positioning mostly, with guidelines to let you line things up. The technique used by Glade/GTK/XUL, box packing, has several advantages like being able to scale the GUI up to any size you like (good for resolution independance) in any aspect ratio and still have it look right.
Anyway, I digress. I don't think this guy is talking about desktop design. He's talking about fantastically complex pieces of software, probably specialist stuff.
I'd suggest he exames emacs and vi. Given that they have practically no GUI elements, they nonetheless expose a lot of functionality via the keyboard (and mouse too). It may be worth considering having a "lite" graphical UI and a heavy duty keyboard based UI for this question.
Re:Mac gets it right. (Score:4, Funny)
Re:Mac gets it right. (Score:4, Informative)
If you would read the actual Apple HIG, they say that apps which are meant to replace a real-world item/function (such as Calculator, iCal, iTunes) should be built with the brushed metal look. All other apps should use the default, untextured look. Just thinking over the apps included in OS X, it seems to me like they follow this guideline fairly closely.
Re:Mac gets it right. (Score:2)
Still, it seems rather arbitrary. What does this distinction gain the user, when nobody other than those who know their HIG inside out can figure out the connection? Also, some of those app connections are somewhat dubious. What does QuickTime replace? A VCR perhaps? What about iChat. The closest analogy in the real world is a phone, but that's very rough indeed. If the Address Book is a replacement for a real world item, why is the text editor not (replacement for notepad)? I dunno, and don't really care to be honest. I was just pointing out that Apple are not the gui design gods people often assume they are.
Re:Mac gets it right. (Score:3, Insightful)
If you would read the actual Apple HIG, they say that apps which are meant to replace a real-world item/function (such as Calculator, iCal, iTunes) should be built with the brushed metal look.
They break this numerous places: in fact, virtually everywhere.
By the definition above, *everything* should be brushed metal. Word processor replaces pencil/typewriter. Spreadsheet replaces graph paper. Sherlock replaces phonebook/dictionary. Photoshop replaces sissors/paste/darkroom.
If you try and tighten it down to obvious objects like iTunes replacing a radio, then why is iChat brushed metal? Why is iMovie brushed metal and Final Cut Pro Aqua? They do exactly the same thing!
This is one area where Apple is just out to lunch. The HI folks had nothing to do with brushed metal: it's clearly a Steve "That's cool: go with it" decision.
MOD THIS JUNK DOWN (Score:2)
Congratulations. You didn't understand the question at all.
This is like somebody asking "Speilberg makes great movies - how do i learn how to do that?"
And you reply "get a Panavision camera. Thats what he uses. They're the best."
A tool is a tool, not a solution.
Map it out (Score:3, Funny)
These work well with the visualization needs that you and your group have as well for the upcoming project; search the Web for the Kohonen learning algorithm and apply a simple summation over each term in the respective vector, remembering to square each quantity as well.
This way, the topological view of your program's user interface will be well-refined, easy to navigate, and of a very high resolution (for CRTs, at least -- LCD monitors refresh too quickly and you may get relics [blurs] from high-oscillating models).
Re:Map it out (Score:2)
intelligent discussion (Score:3, Funny)
So you wrote into Slashdot expecting that? Please!
Carnegie Mellon's Human Comuter Interaction... (Score:4, Informative)
They seem to have a bunch of projects relating to what you are doing here [cmu.edu]
Good luck,
--Alex
Re:Carnegie Mellon's Human Comuter Interaction... (Score:3, Interesting)
Re:Carnegie Mellon's Human Comuter Interaction... (Score:2, Informative)
http://www.hcii.cs.cmu.edu/People/Masters_students /Masters_current.html [cmu.edu]
and click on the video on the right.
Micah
www.alpern.org [alpern.org]
Observers and Adapters (Score:5, Informative)
Adapters allow standard UI controls to embed domain objects without either layer knowing about the other. For example, say you want a tree to list Employee objects. The tree does not understand what an Employee is. However, you can make a tree that takes a TreeAdapter object that knows how to provde its name, subitems, handles renaming and drag-n-drop, etc. You can then make an EmployeeAdapter subclass of TreeAdapter that wraps an Employee and knows how to make a tree node out of it. If the EmployeeAdapter observes the Employee, it can handle changes to the Employee object.
Learn from other successful software GUIs (Score:5, Insightful)
Observe and Adapt. (Score:2)
But again, the original question was not "how should my UI look" but "how should I architect my complex GUI application?" A previous poster mentioned Observers and Adapters, which I think is the best way to go with a multiple viewpoint app like his. I'd work to make this division occur at the highest level possible. I'd have Observers "register" with the viewed object requesting updates only when it changes. And I'd want this separation be so wide that it would even be possible to have the Observers running in a different process, or even connected via sockets from a different machine.
Of course, that's just my opinion. I could be wrong.
For UI logic design... (Score:5, Informative)
Don't think of it as a GUI (Score:5, Insightful)
/. search (Score:4, Funny)
Too lazy to do a search yourself?
Just have a thousand geeks search for you!
Re:/. search (Score:3, Insightful)
Welcome to assholeforum.slashdot.com
The guy's already said he's looked everywhere for something similar, now he's come to the 'enlightened' forums of slashdot where the most helpful post some people can muster is RTFM. Since it isn't clear that there even IS a FM, maybe you can cut someone a little slack, offer a helpful suggestion or shut the fsck up.
Technological eletism helps no one. If you think what he's looking for can be found on Google... find it and prove us all wrong. If it isn't exactly what he's looking for, you can go crawl back under your hole where we will all leave you to peacefully revel in your astounding ability to program in assembly, while your festering glee grows with your ever-expanding intellect.
Re:/. search (Score:3, Funny)
mom: Google it, you lazy sot!
Boy I'm getting tired of hearing posts like yours every ask slashdot....
More appropriate author (Score:2, Informative)
GUIs are at times more elaborate than back end (Score:5, Interesting)
For redundancy or performance reasons you want to have the same business rules executed on the GUI as well as verified on the server. The work required to set a trigger on the database is not the same for representing that on the GUI to the user. The amount of detail that goes on interactively with the user could hardly be managed directly by a server. Because of these I agree that more patterns besides the model-view-controler are needed.
Currently I am on a project where a 'web' form takes 20 days to build but the store procedures that manage the data take 2 or 3 days.
Re:GUIs are at times more elaborate than back end (Score:5, Insightful)
This is typical of UI issues in general, and I wish to heck more non-technical managers would realize this. The amount of coding and hard thinking that goes into making an interface reliable, idiot-proof, and easy to use can be truly astounding, and is often the largest part of implementing an interactive application. A ratio of 85% UI code to 15% non-UI code isn't at all unusual. Nor should this be surprising: interfacing with a database using a set of well-defined logical rules is almost easy compared to interfacing with the unreliable sack of semi-random chemical reactions sitting at the keyboard. Even when they're not clueless and stupid, people are among the most complex real-world phenomena any programmer will ever deal with.
Re:GUIs are at times more elaborate than back end (Score:4, Insightful)
I attribute this to the huge difference between batch processing and running an event loop. Programming languages are very well suited to "do this, then do that" style batch programs. But it is much more difficult to handle interactivity ("on click, do this, on keypress, do that") since you have to keep track of dependencies between internal data structures and the external interface.
e.g. say you have a rule that when MyApp::toolbar_visible == true then the toolbar must be shown. But most programming languages don't allow this kind of declarative specification. Instead, you have to track down every line of code that modifies MyApp::toolbar_visible, and tack on extra code to hide/show the toolbar depending on its new value... Or, if you have a slider control that is supposed to reflect the value of some variable. You again have to track down every point where that variable can be modified, and insert code to update the scrollbar.
MVC helps here, but it's still annyoing - instead of the simple "MyApp::toolbar_visible = true;" you end up writing something like "MyApp::toolbar_visible = true; MyApp::notify_toolbar_change();" Ideally you should only need the "= true" part, and the language runtime should figure out that the toolbar needs to be shown.
I've seen some attempts to use declarative specifications for interface elements, like NeXT's interface builder and TCL's "watched" variables. But none of these are really mainstream. (I don't have much Visual Basic experience - is that declarative?)
Re:GUIs are at times more elaborate than back end (Score:4, Insightful)
Some languages (such as C#, VB.NET, or Python) even provide built-in support for accessors -- this uses the same syntax as a regular field access, so it is transparent to the user.
For example, in C#, you could write this as part of MyApp:
private bool mToolbarVisible = false;
public bool ToolbarVisible
{
get { return mToolbarVisible; }
set {
mToolbarVisible = value;
NotifyToolbarChange ();
}
}
and then later:
MyApp app =
app.ToolbarVisible = true;
and it would call notify automatically.
Re:GUIs are at times more elaborate than back end (Score:2)
I really hope those business rules are well-specified and documented. Otherwise the GUI and the server will never be in sync and no one will agree on the implementation. Sometimes, a development group must concede that they are incompetent at documentation and architect a system that favors simplicity over performance. Unfortunately, such self-realizing development groups are not common (if they are common, where?).
MVC is the pattern (Score:3, Interesting)
Other common approaches are essentially Use Case driven and can be very directed (see Installshield). Or more generalized (see phpAdmin,
Also people are VERY particular about the kind of interaction they like for a given set of tasks. When I design a UI I use MVC (or more usually M VC) and map out my UCs very carefully and in a fair amount of detail. Then I do prototyping to prove the design/UCs (often the users cannot give a good description of what they want until they are sitting down and using something).
The Humane Interface (Score:5, Insightful)
I found it on amazon where one reader stated that "Once you read this book you will know why you have the programs you hate." He is right... I absolutly loath vi now (not that emacs is that much better of going after Raskin;-).
Did you loathe vi before? (Score:3, Insightful)
Anything by Alan Cooper (Score:4, Offtopic)
He would call what you are talking about "interaction design" not "interface design". The Inmates book makes a good case for how the two are different and why interaction design is a better approach.
The revenge of the clippy (Score:4, Interesting)
it must be something that we ate.
Re:The revenge of the clippy (Score:4, Interesting)
GUIs try to present the subset of options that are meaningful to the computer in a consistant manner.
For instance if option B is only available if option A has been selected a GUI can help enforce that constraint. A shell type command line can't help the user make acceptable choices (generally).
The graphical framework helps the user organize his internal thought process to work in harmony with the interface. That the interface pushes the user to think a certain way is part of why interface preference is very personal.
Re:The revenge of the clippy (Score:2)
Yes, exactly. That's why I think the sci-fi story I presented should be called CUI (chaotic user interface :) it would use subsets of options to describe supersets of the options. Yes, very hard to implement but I consider this SETI@home :) in both cases we try to search for something that we know should be there but have no idea what and where to search for :)
Pick a rule and stick with it. (Score:5, Interesting)
This was the primary concern we had when I was working on Vegas Video [sonicfoundry.com]. At first, we treated audio and video differently, thinking that different media types would require different interfaces, but we quickly realized that most actions for one media type had a corresponding action for the other (i.e. Fade out). When a coherent interface element did not exist, we extended the user interface for the given media type. We never allowed an interface element to exhibit different behaviors for different media types.
Of course, Vegas Video is not the end-all of user interfaces, but I learned a lot about simplicity and consistence in interface design.
It's the difference between a complex application and a powerful one.
Re:Pick a rule and stick with it. (Score:4, Interesting)
Jef Raskin (who wrote the Humane Interface) referred to this as using "modes". He strongly recommends that modes should be *avoided*. A lot of software developers build UIs that *wrongly* expose the internal representations of the data used by the application.
In the Vegas Video example obviously sound and video are quite different types of data. To users, however, both are just media that they want to string together in some dramatic order. Users don't want to worry about whether they're in Audio Mode or Video Mode.
I saw a few posts above that mentioned Raskin's The Humane Interface, and I strongly recommend the book. Some of the book can get a bit dry (particularly the usability testing methodology) but the higher level conceps are very sound.
Tasks, Actions, Models, and Views (Score:3, Insightful)
What i've found to work is to use MVC in spirit but split up my application into
+ Tasks
+ Models
+ Controlers
+ Actions
+ Views
That's supposed to be a tree. This design came out of planning, reviewing the app's purpose, and environment constraints. I am developing my app in java/swing and i took the strengths it had but combined them into higher-level structures to help me make the app more modular.
Basically,
Tasks are general tasks that the user will perform. For example, an administrator managing customers of a web store.
Views represent the actual UI: trees, tables, text areas, fields, etc. Views register with the Tasks for appropriate model change notifications. I can provide a variety of views for my tasks and data, and incorporate tasks into higher tasks with complex views.
Actions represent the actual actions that a user will perform in that task's domain. for example, in the Administer Customers task, the user can "Delete", "Add", "Search For", "Edit" customers.
An object for each of these tasks is created and given a string representation, an inconic representation, and it implements the ActionPerformed function. this is taken straight out of swing.
Actions are then registered into the views and ui elements.
for example, in my customer manager window i provide a menu, but also buttons across the bottom. So now one action can provide the title of the menu or button text, the icon for the button, and the state for both menu and button.
finally, when either the item or the button are selected my one action gets the notification.
The action then trickles the command up into the task where the logic for enabling/disabling ui elements resides.
The Task then notifies the model (my data) so that proper manipulation can take place. Finally the model notifies the task and the task notifies the uis and actions for appropriate state change (enable disable commands) and view updates (change data in tables, etc.)
it works pretty well, and i've managed to extend things without having to code complex application state notification or validation so close to the UI. it works nicely in java/swing because up until recently most UI coding had to be done programmatically (didn't use resources like a windows rc) so i can tie UI objects fairly easily to controls. but i'm still not happy with it. however, it was the best i could come up with in a pinch.
hope this helps.
One Word (Score:5, Insightful)
UI Resources list (Score:5, Informative)
maryland HCI lab (Score:2, Informative)
Some useful links (Score:2, Informative)
While some may scoff, the ACM [acm.org] has an article on the Windows 95 interface, a little bit aged by now. Though many in this forum dislike Microsoft for its other faults (the constant crashes, draconian business practices, etc.), a big part of their current success comes from the fact that their user interface is simply easy to use. They do their homework [microsoft.com] when it comes to that.
My mom couldn't spell WWW when I set up my parent's computer for them a couple years ago. She complained that IE wouldn't go to the website after she typed in the address. It took me a while to realize that she wasn't pressing Enter when she finished typing the address in. That's why they have that little "Go" button next to the address box that I always get rid of right away.. Duh!
This is a noble quest, young hero. God speed.
Unidraw has what you're looking for (Score:5, Informative)
Not an HCI question... (Score:5, Insightful)
I think part of the reason such discussions seem to be lacking out there is that each GUI toolkit has its own way of conceiving of event-based GUI interaction, and separating the presentation of a GUI element from the logic that handles it. Thus there is no real standard set of design patterns for GUI implementation (there are tons of sites I found using Google on GUI "Design Patterns" which are basically just HCI best practices for communicating certain kinds of concepts). For example, Qt uses the signal-slot mechanism. wxWindows uses EVT_ macros to associate an event with an action method. These encourage different ways of structuring GUI code.
I am not saying it's impossible to come up with a set of rules of thumb for general GUI development and implementation in the same way that general design patterns for OO development exist to solve certain kinds of problems that are commonly encountered, but I'm doubtful they would be as useful as you would think.
Some references here (Score:5, Informative)
(If you have access to a university library, you can find those proceedings there as well)
Architecture -- not interaction design (Score:5, Insightful)
You mention MVC. This is a very useful abstraction, but you're right in saying that it doesn't address the larger question of application architecture. One kind of global abstraction that seems to help for large interfaces is some kind of messaging system. For example, you can use a global queue of update events (sent by Models when things change) which all interested Views can lsiten to, and react accordingly.
Some real problems come when you want views to react to changes so some other view (but NOT the underlying model data). e.g. changing from 2d to 3d display, you might want various menus to appear, disappear, or have entires change/gray-out. This breaks down the MVC abstraction to varying degrees.
At the end of it all, I also haven't seen much in the literature on architectures for large GUI apps. I think this is because very few of them are really ever produced. Most apps you see are, at the base of it all, fairly simple, and require only one or two views with pretty straightforward control architecture.
Re:Architecture -- not interaction design (Score:2, Interesting)
Also, as an alternative to MVC, take a look at Presentation Abstraction Control.
Google yielded this site, among others:
http://www.vico.org/pages/PatronsDisseny/Patter
Re:Architecture -- not interaction design (Score:5, Interesting)
Let your users do it (Score:2, Interesting)
One strategy to address this is make your whole GUI scripted. Implement all GUI commands with script language bindings, and implement your GUI as a script in this language (this can be done with Perl, Python, Tcl/Tk, etc.). Provide hooks for your users to create their own comands and extend the GUI as they wish. Now you don't have to figure it all out, because your users will.
This model is used by many complex applications, such as IC design CAD frameworks (with which I am familiar). Just make sure you don't fall into the trap of thinking you need your own scripting language. Use an off-the-shelf language.
My thoughts (Score:5, Insightful)
Everyone has a use for a word processor but not everyone has a use for one this programs but when you do you need it bad. When you design the architecture and the UI you need to keep flexibility in mind. This is not so much for the user but for you so you can met the needs of a SPECIFIC customer. It is my experience that customers really want the vertical market software they buy to aid their current way of doing things, not to change what they are doing to meet the needs of the software.
A specific industry has a lot of common needs but there is enough variation that if you don't design flexibility in mind it will drive you crazy with tech support and lose buyers who can't get the software to do what they exactly want.
There two things you need to consider for such programs. The architecture and the UI.
I following many of the standard advice on designing UIs but here are a couple that I try to keep in my mind.
1) Keep the focus of the screen in the center of the screen. Try to add widgets to the top AND bottom to keep the screen's focus in the center. For example there was a version of my software where the sheet of metal was bumped down so that it's center was a lot further down then the center of the screen. This is bad. The next version I redesigned that screen so that the widgets were equally distributed between the top and bottom. This way the user's eyes when they move to the monitor has the sheet exactly where it is needed.
2) Work-flow, you should provide either a means via keyboard or mouse to accomplish common tasks. You can do one, the other, or both. However what you shouldn't do is mix the two. If the task has keyboard components you should try to enable the user to complete the task without moving from the keyboard. The same for tasks involve the mouse. Tasks that involve a lot of moving from mouse to keyboard leave user unhappy.
Try to have a keyboard way and mouse way to do all tasks. Sometimes it isn't possible but if it is do it.
3)Softkeys, toolbars are nice it is my experience that users respond better to text then icons. User like big fat buttons on the screen. What I come up with the idea of softkeys. If you look across the top of your keyboard it probably has 12 function key arranged in groups of 4. What I do is have eight buttons on the top or bottom of my screen split into two groups of four. The first four correspond to F1 to F4 and the second four to F5 to F8. I use F9 to F12 for special actions. F9 is generally used for "flipping" the softkeys. This give me room for 16 commands per softkey group.
On the more complicated screen I have multiple groups of softkeys. For example Zoom, Cut, Edit Path, Sketch, Rotate, etc. Each having up to 16 commands. I also provide a way to switch between the groups.
The advantage of this that the user can see exactly what they can do in front of them. They can use the mouse to click on the command or use the corresponding function keys. While I do use some toolbar buttons most of commands are accessed through the softkeys.
4) Make important tasks very easily accessible. Use single letter or buttons to tie into the task. For example Edit Cutting Parameter is a command often used in my software. So I tie it into not only a softkey but a toolbar button accessible no matter what softkey group you are in.
Architecture.
First get Design Patterns and Refactoring Software, regardless of what langauge you use they will be very useful.
The goal of Architecture is to have flexibility to meet customer needs without introducing a lot of bugs into your software because you changed something. I am not sure what to call what I use but it builds heavily on Design Patterns.
Data Structures
Application Structure
UI Interface
Commands/Installable Libraries
UI Implementation
Graphic Framework
Data Structures (Sheets, parts, etc)
Application Structure (I use an idiom of Jobs comprised of sheets with parts, with a separate Shop Standard that is refered too by all Jobs, and a list of installable libraries ).
UI Interface (nothing but Interfaces)
Commands (these use the command pattern to implement )
Installable Libraries (like reports, part creation, file types, etc)
UI Implementation (implements the UI interfaces with methods accessing commands and libraries).
Graphic Framework (Delphi, Qt, KDE, Gnome, VB Forms, etc).
The reason for UI Interface -> Commands -> UI Implementation is so that commands that just manipulate the UI (switch screens) can be written. The actual implementaion is last because the implementation needs to know what commands are available to assign to various screens and widgets.
I hope this helps
GOF Design Patterns (Score:3, Informative)
Then The GOF Design Patterns [hillside.net] may be what you're looking for. The case study used for most of the pattern illustrations is that of designing a word processor -- which is no simple feat. A lot of these can be extended to any type of a UI architecture.
Fitts's law (Score:3, Informative)
Kai's Power Tools? (Score:2, Informative)
It was sold by MetaCreations to Corel/ProCreate, and you can get info here:
http://www.procreate.com/product/kpt/ [procreate.com]
Good luck!
A|W, SIGGRAPH (Score:2)
You should probably also go through past issues of the SIGGRAPH annuals, there is a ton of GUI discussion in there, albeit scattered around everywhere, sometimes buried in nonGUI-related articles.
create multiple granular controllers (Score:2, Interesting)
When implementing semi-complex interfaces, certainly not on the level you require, I've created multiple controllers and not just relied on one. I've placed the controllers at the process level so that not only processes know how to manage and update themselves and their views but they know how to interact with other processes sending messages back and forth for other processes to update themselves and their views. In fact, on a number of projects I've started with a base class ProcessManager and created specialized managers from there.
I know this is only cursory information. Perhaps it will help you while you think about your direction.
Interesting GUIs (Score:2, Interesting)
One example of this (among many, I'm sure) is SolidWorks. It's an expensive (few ~k$) piece of design software for drawing 3-D pieces and assemblies. What makes it distinct from AutoCAD is that, rather than keep track of where each vertex is, you keep track of relationships between parts. It turns out this is a bitch to learn but a real pleasure to use. When doing a mechanical drawing, the relationships are the critical piece. The genius comes when you want to change one aspect of a design (the length, say), and it automatically ripples through the entire thing.
I mention this long winded example only to point out that an interesting GUI is one that tackles an interesting problem. And these are often found in software that is sold to designers and engineers (smaller market, bigger cost). The few times I looked at an interface and thought it was very well done, it was because it was well tailored to the particular problem at hand.
Scripting is a popular choice (Score:3, Interesting)
Good Question - Lots of Answers (Score:3, Informative)
I appreciate the original authors appeal. There aren't any good books on complex GUI design and implementation, unlike for instance the UNIX Operating system. In the Demon Book ( The Design and Implementation of the 4.3 BSD UNIX Operating System, Karels et al) they delve into all the ugly detail of the design, the history, the mistakes and the many attempts to fix the mistakes (particularily in the memory manager). The strengths of the Linux kernel derive significantly from this book and other similar tomes (there is one for System V whose name escapes me at the moment).
However in UI design if you've got a map and compass you can consider yourself lucky, but you still have no idea of the terrain or the topography. Throw the concept of MVC at a novice user interface designer is about as useful as saying "demand paged memory" to a budding OS designer. It just doesn't reveal the true challenges of the problem.
In order to get your head around that you need to consider what the users conceptual model is e.g. how are they going to approach the problem you software plans to solve. Both AutoCAD and Word have a head start in this regard as they could draw on the experience of the users who lived in those domains (technical drawing, and writing and editing) prior to the entrance of those programs. (AutoCAD also has Ivan Sutherland to thank for his ground breaking work in Computer Graphics, this is the man that invented rubber banding as a line drawing concept). Visicalc on the other hand had to invent a concept from scratch in order to provide the desired utility.
Once you understand the basic model you need to understand that the model changes as you move from user to user and also changes as users try to achieve different things with the software. It also grows with their experience. The stuff you need to get started as a novice Word user you almost never use once you are proficient with the program which is why all us dyed in the wool slashdotters constantly bemoan the Word animated paper clip. However the big bad world of first time users love that stuff.
Therefore you program needs to grow with your users, starting simply and revealing itself slowly as their knowledge grows. At its most complex it must allow skilled users to perform their jobs effectively while still remaining true to the unifying paradigm defined by its conceptual model.
The best research in this area can usually be found in the ACM conference proceedings particularily those associated with User Interface design. You should also check out Mark Lintons work on "Interviews" (try http://www.berlin-consortium.org/docs/papers/toolk it.pdf for starters)
I have to admit tho' its a hole in the technical literature in general...
Architecture Answers (Score:2, Informative)
Check out Martin Fowler's Enterprise Architecture Patterns [martinfowler.com], some of them can apply to any type of GUI. The MVC pattern does not just have to apply to single components of a window. But there is a difference between creating the GUI architecture for a CAD type program as opposed to a Business type program. For example: CAD programs can have thousands (or more) of objects on the screen at the same time; so modelling each as an object will bring your program to it's knees (using the Prototype pattern [c2.com] can help here).
You might try searching google for 'CAD GUI' or something similar; I've seen articles / web pages that discuss GUI's that are not database backed / business related, but I don't know the addresses off-hand.
Scalable Application Guidelines (Score:2, Informative)
my 3 cents (Score:2, Informative)
Right click menus are a major part of the GUI's in Maya (which otherwise has a very poor interface due to the excessive menu switching and poor menu item organization) and 3ds max, with Maya's being its trademark "hot box", displaying tools in a radial fashion and letting users access sub-groups of items just by rolling over them. 3ds max simply displays a whole lot of stuff in its right click menus, plus pretty colors. Right click menus are in my opinion still under-used... I find it incredibly convenient to access stuff in a single level menu accessible through a single click rather than searching through endless menu items, among different menus and different menu sets (in the case of Maya and Softimage, the former even having a menu item search tool).
One thing to avoid imo is a too linear GUI design. Lightwave features such a thing, in which one must frequently switch between different tabs of different tools depending on the situation. The scapegoat might be that Lightwave has clear and numerous keyboard shortcuts, but that does not alleviate all of the problem. A user should be able to use the software efficiently in whatever way appears intuitive, and not have to suffer learning some specific, somewhat esoteric and assumingly "better" method in order to be the most productive.
Avoiding that though could lead to redundancy in interface, which is another problem. In 3ds max, there are about 3 ways to create a parametric primitives I believe, cluttering the UI unnecessarily with menus, toolbars and tabs. In many other 3d graphics packages similar situations exist.
Overall, I would say the best GUI for very complex software would be one which makes extensive use of automation (context-sensitivity), clear unambiguous methods (make the user aware of what the workflow should be, without making it too strict), and simply a direct and clean organization (no superfluous crap, don't display many tools that can't be used at all in the situation).
simplify ruthlessly (Score:2)
if you apply Occam's Razor at every opportunity, take every chance you can to cut down on the number of degrees of freedom, eliminate all choices that are not absolutely necessary, you will usually end up with something that is more intuitive, more powerful, easier (= cheaper!) to implement and has fewer bugs to boot.
in these days of 20 million LOC word processors, and "pile on every feature that we can think of" applications, simplicity is an underrated virtue.
think minimalist!
I wrote an abstract on this. (Score:2)
What I wrote [google.com] (try to
I know it's a brilliant idea, because the thread on Usenet has total of 8 posts, 1 of which is asking if comp.human-factors is the right group, 2 telling me that it is, 1 is the abstract and four are replys relevant to the abstract.
Can't beat that kind of feedback, can you?
User Interface Group @ PARC (Score:3, Interesting)
My tip: (Score:3, Insightful)
what to read (Score:3, Interesting)
Then burn them. In a big roaring bonfire. Okay, don't -- donate them somewhere, but pretend you burned them. Picture 'em burning in your mind.
You are not designing an interface for the common person. Those are designed to be immediately accessable, with a slow gradual learning curve, with lots of consistent easy to grasp metaphor. That is the mac, and usually they do pretty well at it. Metaphors and graduality will drive your power users insane, and you're designing an app for them.
You want something more like emacs. Or, if you're doing CAD, you want something more like AutoCAD. You want an interface with power. You want one with usability. You want consistency, you still want to keep things like Fitt's Law in mind, but by no means should you feel compelled to make the damn thing intuitive. Neither vi nor emacs are in the least bit intuitive, but boy are they usable, meaning the interface really squeezes maximum use out of itself.
If I did have to throw in one piece of pithy advice, I'd say that since you're probably going to have to implement some sort of language to express the actions of the interface in, make the API self-documenting, like emacs. I can't tell you how amazingly useful the apropos command is in emacs, how it just searches through the names and documentation of every function and every var in the system, and I don't have to rely on compiled API documentation that may or may not tell me what I need.
GUI architectures (Score:5, Insightful)
Emacs is the right programming architecture for GUIs. The Emacs command set and visual appearence are, obviously, not that great for many users -- but the programming architecture is right.
By being interactively extensible, emacs makes it easy to fine tune an interface while you play with it.
By being lisp based and by having many fine abstractions, emacs let's you do a lot with very little code.
The emacs architecture provides some very fine bits and pieces for achieving excellent accessability features.
By being interactive and self-documenting, Emacs is good at helping people teach themselves to program.
View-tree toolkits, such as underlie Gnome and KDE are inflexible dogs that leaded to bloated yet feature-anemic tools. You know what they're good for? They're good if you have a command-and-control army of drone programmers who can write reams and reams of code. That's why Microsoft apps will remain far more featureful than their free competition until that competition switches to an architecture that works for a society of free individuals.
Yes, it's true: the way you structure your programs has political implications. It defines jobs. It defines the power of managers and project managers. It establishes the degrees of freedom your users have to extend or customize their tools.
Re:GUI architectures (Score:3, Insightful)
So, yeah, it's feasible.
Rules, rather than patterns (Score:3, Insightful)
A philosophy I build into all of my GUI applications is "show the user as much useful information as possible". Users make thousands of decisions a day and informed decisions are easier to make. To that end, I eliminate useless information as much as possible to make room for the good stuff.
There are simple facts that need to be remembered while designing a UI:
- eyes move more easily than fingers
- buttons don't provide useful information (but can!)
- scrolling is useless and should be avoided
- minimize clicks, mouse moves and keystrokes
- informed decisions are better decisions
- context-based mouse clicks make sense
- keyboard shortcuts save time
- don't invent new keystrokes for old functions
- everything should work as expected
- file managers should show more files, db apps should show more data
- people can't choose from more than 7 items unless they are grouped
BTW There's no such thing as information overload. There's only useless information. If everything you show on a GUI is well organized it's all useful.
Congratulations! (Score:3, Insightful)
A good question that can't be answered without advice, that doesn't score a bazillion howto-hits on Google and that isn't shure to be absolutely above the heads of the slashdot crowd.
Nice to have some good question asked. Thanks.
Now for my shots at closing in on answers:
I have no larger mentionable expierience in UI design apart for the fact that I do have some webdesign expierience and a professional artist training, but I have used and operated a wide range of professional tools in the professional manner in which they were meant to be used and operated!!!
And that's a very important part of my/the answer allready:
All extremly complex professional GUI-tools each have their very own distinct, standards-pushing look and feel acustomed to their application family more than, let's say, the CUAS. And that's what makes up a good tool.
People who use Avid use it almost exclusively and for hours and years on end - and often on special hardware too. Same goes for Softimage or Houdini. Or check out the difference between Freehand, Illustrator and Corel Draw. The distinct, special funtionality of vector-drawing apps is approached in a different way by each. That's the same reason why you've got a wider range of Video NLE apps that do all the same but with often different workflow aproaches.
See what I'm saying: If you're tool is gonna be complex due to very special funtions that only a few people will need or even know, there is no point in trying to find a standard for GUI design. You won't be able to apply it properly.
What to use? Photoshop layers or Photopaint objects? How to join vectorcurves: Corel connect and combine or Freehand extend and join? The latter is a very good example: 2 totally different but valid approaches to a very important problem. For those that need solid vector graphics power.
Bottom line:
Programms that are so complex that they are most likely to become stand alone tools (maybe even with custom hardware!) *can't* follow design standards - because there are none! Such a programm gains recognition by having a distinct character and one team of professionals in it's userfield that really know what they're doing and set up their own set of rules and preferences as to which way the app has to work, behave, look, feel and is intended to be operated.
And believe me, nothing sucks more than trying to make a complex powerapp like, let's say, a 3D modeler, instantly 'usable' for people who only know office gui standards. Check out kpovmodeler to see what I mean.
Re:AutoCAD (Score:2, Insightful)
I don't think he's asking this either though. He seems to be asking how to properly stucture your internal data and the appropriate design patterns to use to cleanly access this to make it easy to fit to a complex GUI, a GUI where the same data is viewed from several different perspectives and needs to 'look' and 'act' different depending on how it's being viewed.
He listed autocad (and others) only as examples of complex GUIs with no judgement on whether it's good or bad. And he's not looking for good GUIs or bad GUIs or how to make either. He's looking for how to go about connecting the GUI to the underlying data.
or that's how it reads in braille.
Re:Don't forget Rule Number One (Score:3, Funny)
Assign points over time (which can be done since modern computers have sequential ability, rather than just a set of combinational logic gates).
Why not attempt (or adapt) the following measure? --
User Ability: {Charisma + Determination + Discipline + Raw Intelligence + Logic + Wisdom)/[ln(Pi*timeSinceInitialInstall)]}
Develop a few simple tests and embed them into some questions (perhaps an inital registration script that loads upon first run) to find each value, and then run the numbers based on the above equation.
Or just have a grad student do it for you!
Re:Don't forget Rule Number One (Score:2, Funny)
Isn't that in the D&D manual somewhere?
Did I miss my saving throw against not being able to install Word?
Re:The gui acid test (Score:2, Interesting)
MS GUI is ok (Score:2)
Users are probably quite accustomed to the Microsoft look and feel (without the bluescreen look-and-feel) would probably do quite well using a GUI of this variety.
Building a modular program with a GUI frontend would work nicely if done right, but it's good to keep in mind that this is what made some of the earlier windows suck. If the back-end is designed to accept the GUI it should work nicely however.
Re:GUI is Part of an APP but not the whole thing. (Score:3, Informative)
Re:KISS & MISS (Score:2)