Slashdot Mirror
Complex GUI Architecture Discussion?
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."
Lots of research on Human Computer Interaction. Google it and also check out the digital libraries at ACM. (acm.org)
I've liked The Humane Interface: New Directions for Designing Interactive Systems, written by Jef Raskin. He was one of the early Mac engineers. This maybe a little higher-level than you are looking for though.
"This isn't a study in computer science, its a study in human behavior"
Here at CMU they have a whole school in the school of computer science to deal with this issue. Check them out at http://www.hcii.cs.cmu.edu/ .
They seem to have a bunch of projects relating to what you are doing here
Good luck,
--Alex
Check out various Smalltalk books or Apple's development documents for more info on this.
We have developed some very large applications that can have multiple views and editors attached to one object.
The main useful point is that every change to the model causes a unique message to be broadcast and all interested parties listen for particular messages and then update their UI if needed. This leads to code that is very loosely coupled and easy to alter with few side effects.
One common theme I've seen is observers and adapters. Your application components can be Observable. Observers register interest in them to get notified when the object changes. One problem of this approach is specifying the extent of a change. Just saying "I've changed!" isn't specific enough if that update would take a long time to process. If you can specify exactly what changed, then the Observers can process only what has changed.
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.
...try "Constructing the User Interface with Statecharts" by Ian Horrocks. If the complexity you are dealing with is logic complexity rather than "...put the buttons here" then this methodological approach to UI/application state design may interest you.
I want to be alone with the sandwich
Apple's got some great stuff in their Human Interface Design guidelines. And before anyone screams about hating Aqua, there is a lot of general-purpose information there regarding why things should be done certain ways.
I think some of the other suggestions miss your point. Peruse some of the Ben Shneiderman's books. They will probably give you more practical, specific, and useful help in this case than some of the other experts cited so far. Stuart Card deals with complexity as well, but some of that would be less practical.
pretty big HCI lab at univ. of maryland, college park, with lots of research publications and such. check it out at http://www.cs.umd.edu/projects/hcil/index.html
I'd check out material from Google, Amazon, The HCI Bibliography, NASA, the W3C, and Joel for starters.
While some may scoff, the ACM 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 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.
Looking for Design Patterns for complex interactive applications with multiple views? Take a look at the thesis work of John Vlissides, one of the Gang of Four: http://www.ivtools.org/ivtools/unidrawinfo.html
I've seen about 50 comments so far and all think the question is about User Interface design in terms of "Human Factors" as you mention. While Human Factors (and the book you mention) is important this is not what the poster is asking.
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.
Who said Freedom was Fair?
(If you have access to a university library, you can find those proceedings there as well)
Look at what you shouldn't do, it is funnier.
http://www.iarchitect.com/mshame.htm
They also vary the theme between aqua and brushed metal seemingly at random in their apps collection. This goes flat against their own HIG.
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.
Perl - $Just @when->$you ${thought} s/yn/tax/ &couldn\'t %get $worse;
I guess I am looking for a sort of 'Design Patterns applied to a big deskptop application' sort of discussion.
Then The GOF Design Patterns 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.
-- jimmycarter
I haven't seen this URL posted yet (I thought it came from Slashdot a while ago, but I guess I was mistaken :)
Be sure you can answer all of these questions before you even start to think about GUI design. I agree with pretty much everything the guy says.
One other thing, be sure to keep to conventions wherever possible. For example, people are used to having the Exit command at the bottom of the File menu, so (unless you're doing something completely different, as you may be) don't stick it anywhere else. Little things like that make programs more intuitive.
And one other thing: make it as unlike Blender as possible :)
KPT (an Adobe Photoshop plugin) had a revolutionary GUI illustrating some of what you mention. Unfortunately, it wasn't as intuitive as one would hope, but, like anything after using it for a while you get used to it. Somethings actually worked more intuitively than others. Perhaps you should give it a look.
It was sold by MetaCreations to Corel/ProCreate, and you can get info here:
http://www.procreate.com/product/kpt/
Good luck!
The hell you can't! Have you ever talked to a GUI person about the taskbar? Or the system tray? Or the start menu? Or their filesystem approach? Or the Explorer? Or their common file dialogs? Every place they've had to come up with an idea on their own (i.e., every time they couldn't copy part of Win95 from System 7) they screwed it up.
There should be a moratorium on the use of the apostrophe.
Max V.
NeXTMail/MIME Mail welcome
Check out Martin Fowler's Enterprise Architecture Patterns, 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 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.
Take a look at the OpenAPI's exposed by great tools such as Borland's JBuilder, JetBrains IDEA, JEdit and Emacs for an idea of how these marvels are built. Common techniques used to produce a product with complex functionality include: 1. A plugin design. It must be possible to "add/register" new functionality without changing features. The core concepts should be small and form a stable core. 2. Observer/MVC pattern (of course). Decouple that sucker... 3. One thing in one place (avoid duplication). If you've a toolbar button, a menu item, a context menu item, and they all invoke the same functionality using the same presentation names, icon, etc - all of these on-screen locations should be contrived from a single source "action" object. 4. Internal languages Use scripting languages to expose common components (both for internal and external consumption) so that they may be reused in unforeseen ways. Good luck...
Context sensitive seems to be a significant trend. Macromedia relatively recently revamped their GUI's in their software to make heavy use of a primary context-sensitive panel, allowing them to remove several superfluous panels. Adobe in Photoshop 5 I believe added the context sensitive top bar, which displayed some options for whatever tool was being used. 3ds max is perhaps the piece of software featuring the heaviest usage of context-sensitive interface- the righthand bar automatically displays the relevant tools for what you're working on, i.e. polygon tools if you've selected a polygon object, inverse-kinematics settings if you've selected an IK-related object etc. Context-sensitivity is a great help since it basically does work for you, finding the stuff you need when you need it.
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).
The dock came from NeXTStep which predates Windows use of the start bar.
Basically, Apple bought NeXTStep rather than develop a new OS. System 7.5 was showing its age, and it was cheaper to purchase than develop a new OS. They grabbed one that is pretty solid, and made the interface very nice.
> These are the same people who think having one
> common title bar that is shared by all people is a
> good thing
It is easier to hit - shove the mouse forward, no clicking on some stupid 30px high menu.
this book to be of interest.
Designing from Both Sides of the Screen: How Designers and Engineers Can Collaborate to Build Cooperative Technology
Aimed a bit more towards smaller cooperative apps - but it has a lot of REALLY good things to say.
About Face: The Essentials of User Interface Design by Alan Cooper
His examples are windows-centric but he has a lot of very important things to say about where modern interfaces go wrong as well as things that are done right.
By the way: There is a project trying to realize the ideas of Raskin on SourceForge: look here.
It is for macintoshs only IIRC.
Regards, Tobias
Just a quicky,
If you're interested in exploring the field of human computer interaction further try the HCI Bibliography. If you're particularly interested in user experience, user interaction, and the "stuff below the iceberg" then take a look at the book "Interaction Design: Beyond Human-Computer Interaction" (ISBN 0-471-49278-7) which has a website. Also the IBM Ease of use site is pretty good.
Something to whet your appetite!
--
iDler seemed like a good name when I used to be bone idle (ie: a student)...