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."

Comments

For UI Reference

[airrage]

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.

Carnegie Mellon's Human Comuter Interaction...

[fosh]

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

Observers and Adapters

[paulfwilliams]

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.

For UI logic design...

[bubbha]

...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.

UI Resources list

[tbonium]

I found this list to be very helpful:

• UIWeb.com
• UIWizards Reading list
• Hack the Planet 2.0 discussion

Unidraw has what you're looking for

[Scott E. Johnston]

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

The Question is NOT about Human Factors

[jaaron]

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.

Some references here

[JAS0NH0NG]

Here are some references:

• Dan Olsen's Developing User Interfaces. Dan Olsen is a professor of Human-Computer Interaction, formerly at Carnegie-Mellon, now at Brigham Young. his book describes the nuts and bolts of the internals of GUIs, including rendering models, event queues, event handling, graphics, and so on. Depending on your level of expertise, it may or may not be useful.
  
  
• If you have access to ACM's digital library, check out the proceedings of CHI and UIST. CHI stands for Computer-Human Interaction, and is the main conference in that field, and looks more at design issues and evaluation. UIST stands for User Interface Software and Technology, and looks more at the implementation issues. There are several papers there describing the design and implementation of several complex systems.
  

  
  (If you have access to a university library, you can find those proceedings there as well)
  
  

• Following up, check out the work of Bill Buxton. He and his students at Toronto have done a great deal of work with 3D interfaces. In fact, Bill Buxton also works at Alias | Wavefront, who create lots of tools for 3D modeling and rendering.
  
  
• I'd also suggest looking at the Virtual Reality work done by others. I suspect that they have many issues in common, although the interaction is clearly different. Check out Alice by Randy Pausch and others (at Carnegie Mellon). Alice is sort of like Logo for 3D worlds. Fred Brooks, of Mythical Man-Month fame, also does work in this field. (I don't study virtual reality, so I'm not as familiar here)
  

Re:Mac gets it right.

[ZxCv]

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.

GOF Design Patterns

[jimmyCarter]

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.

Fitts's law

[golrien]

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 :)

Re:GUI is Part of an APP but not the whole thing.

[MaxVlast]

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.