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

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.

Learn from other successful software GUIs

[VisualVoice]

Find a good model and see where your needs diverge. When we started on a project like this, the UI was a mess until we based the initial design on an existing piece of software where the user interactions were similar in nature (e.g. office productivity app, multiple views of data = MS Outlook). So if your app has similarities to AutoCad, Photoshop, or any other commercially successful UI, use it as a starting reference model for your UI, and see where the needs of your users diverge from the UI model that app presents. To do this you need to generate typical usage cases, and rank them in terms of how often they will be performed, and make sure those operations are obvious and easy to perform. The other advantage to this approach is users will appreciate that it works just like "software app X" and won't need much additional training.

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.

Don't think of it as a GUI

[frank_adrian314159]

... especially if it is a very complex application that exists to do a single logically coherent - but complex - task. Instead of trying to fit into a WIMP/Menu/Command line paradigm, think of yourself building a control panel for the action. Look at information on industrial designs. But for God's sakes don't look at GUI guidelines for the platform you're building it for. The main argument for this is that you then have to train the user in your GUI. But, if the task is complex enough to need a complex interface, it's complex enough to require training to use. Finally, link the panel to conceptual actions, events, or information in the conceptual task space.

/. search

[Anonymous Coward]

Welcome to slashdot.google.com!

Too lazy to do a search yourself?

Just have a thousand geeks search for you!

GUIs are at times more elaborate than back end

[sapgau]

I'm amazed sometimes on how easily a GUI is considered trivial or non-critical.

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

[Angst Badger]

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.

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

[captaineo]

My experience definitely agrees... I've found that constructing an interactive (not necessarily graphical) interface to non-interactive code takes 2-10 times longer than writing the non-interactive code itself.

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

[servo8]

Why not use accessor methods instead of exposing the variable directly? Then you could call your notify method in the setter for toolbar_visible.

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:Mac gets it right.

[Faggot]

iJesus God, please don't look to Emacs and vi for insight into good UI design.^[ZZ^J

The Humane Interface

[t_hunger]

I really like the book "The Humane Interface" from Jef RAskin.

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

Anything by Alan Cooper

[Krelnik]

Check out anything by Alan Cooper. His "The Inmates are Running the Asylum" is more of a rant than a guidebook, but still excellent reading. "About Face" is probably more of what you want.

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

[jukal]

a couple of days ago we ended up thinking something like this with my work mate. This might be sci-fi, sorry :) but: What if, in the beginning, there would be no GUI at all. In the beginning, all of the users would only work with shell - they would whip in commands like "useradd -u 120 -g dls -d /apps/dls -s /bin/ksh -c "comment" -m dls " and after doing this they would tell the computer: I did this to achieve this. There would be some kind of fuzzy logic to make the computer understand how to utilize this in future - to make it generic. Then suddenly, you would only need to tell the system: do this. Well, the discussion did not end here, it included a kind of evolution model in which the operating systems would be connected in kind of P2P network - the new things that each of the computer users had taught would be distributed, evaluated and ranked. Some ideas would be killed, some would stay alive and evolve... the discussion did not end here either: how about, if in the beginning there would be no operating system at all - just the very raw beginnings of a kernel, and then the users would for example teach the system to boot....

it must be something that we ate.

Re:The revenge of the clippy

[Big_Breaker]

That is a great idea but its implementation would be extremely difficult.

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.

Pick a rule and stick with it.

[chaboud]

Whenever you are visually representing data, and providing a means by which to manipulate the representation, consistency is paramount. If you have three object types: A, B, C that are represented in the same visual space, an action on A should have an equivalent effect if taken on B or C.

This was the primary concern we had when I was working on Vegas Video. 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.

[sahala]

Just to piggy-back on the parent... Whenever you are visually representing data, and providing a means by which to manipulate the representation, consistency is paramount. If you have three object types: A, B, C that are represented in the same visual space, an action on A should have an equivalent effect if taken on B or C.

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.

One Word

[Quirk]

Emacs

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.

Re:The Question is NOT about Human Factors

[badavis]

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.

Not an HCI question...

[Fnkmaster]

Okay, the moderators are on crack today. Read the question - it's NOT a question about "where to put the buttons" (i.e. HCI/UI design) from a UI designer's perspective. The question is about proper development and coding practices (including design patterns more interesting and complex than just MVC) for building complex GUI apps, presumably from the perspective of a software developer working with a designer, or given a UI design that is already known to be good.

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

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

Architecture -- not interaction design

[tswaterman]

Look guys, the question was about application architecture, not about GUI design, button layout, color schemes, etc. So, in that vein...

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

[bLanark]

Just been through all of the current posts, and no-one mentions H-MVC - hierarchical MVC. There's an article on it here. It's an interesting adaptation of MVC for complex guis, and can go right through the UI/client from the base to the smallest, tip-most configuration dialog.

Re:Human Factors

[bhforj]

Read his F'ing post man: "I am not interested in 'where to put the buttons', but rather the nuts and bolts..." [Do you moderators even read the posts carefully?]

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.

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.

My thoughts

[estar]

I am a designer for a CAD/CAM program that is used to control and make parts for metal cutting machines. The first thing you will need to realize that these types of application are considered vertical market applications.
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

GUI architectures

[tomlord]

It's a shame the post with the correct one word answer got categorized as "funny".

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.