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

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.

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.

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.