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