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.

MVC is the pattern

[Anonymous Coward]

MVC is the pattern at a high level. There are generalized approaches which you mention in your question. The "complicated" UIs you are talking about - for graphics programs etc. are geared towards the sophisticated, committed and very busy professional who is using a vast number of tools and techniques to get their job done. A well designed interface of this type uses the "Direct Manipulation" approach on top of a large complex model (see Visio).

Other common approaches are essentially Use Case driven and can be very directed (see Installshield). Or more generalized (see phpAdmin, /., many others).

Also people are VERY particular about the kind of interaction they like for a given set of tasks. When I design a UI I use MVC (or more usually M VC) and map out my UCs very carefully and in a fair amount of detail. Then I do prototyping to prove the design/UCs (often the users cannot give a good description of what they want until they are sitting down and using something).

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:Carnegie Mellon's Human Comuter Interaction...

[back_pages]

I'm applying to Virginia Tech's grad school in computer science, and they have a HCI program. I'm not really interested in software design, but stuff more along the lines of ubiquitous computing and other projects that break the "computer is the tool and master" notion. Is this the type of thing that is addressed in HCI programs, or are they more of a sophisticated study of where the "Ok" button should go and how to magnify the screen for vision impaired people? Both? Neither?

Re:Human Factors

[Anonvmous Coward]

"I'd recommend starting with Norman's The design of every day things...."

I wish the Slashdot coders had read that book. I got my butt jumped because I used ['s to encapsulate a bold tag instead of the typical HTML greater-than signs. According to some, my being used to VBulletin syntax (used by several forums I vist) is a sign of how truely stupid I am. I think it's a sign of how unfriendly Slashdot's interface can be.

It's not a poke at Slashdot, but rather an observation that book helped me make about UI. Slashdot's just a handy example. Now, when I write web pages, I have a better perspective of the things I should do to prevent mistakes like the bracket example from being irrecoverable.

Anybody who's interested in design should read that book, it helps you understand why humans make the mistakes they do and what you can do to accommodate them. Hint: It's not because we're all too stupid to read a manual.

User Interface Group @ PARC

[north.coaster]

Seems like one possible source would be the User Interface Research Group at PARC. These are the same folks who invented the Windowing user interface.

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.

what to read

[scrytch]

Start by reading every book you can get your hands on about designing user interfaces for the common user.

Then burn them. In a big roaring bonfire. Okay, don't -- donate them somewhere, but pretend you burned them. Picture 'em burning in your mind.

You are not designing an interface for the common person. Those are designed to be immediately accessable, with a slow gradual learning curve, with lots of consistent easy to grasp metaphor. That is the mac, and usually they do pretty well at it. Metaphors and graduality will drive your power users insane, and you're designing an app for them.

You want something more like emacs. Or, if you're doing CAD, you want something more like AutoCAD. You want an interface with power. You want one with usability. You want consistency, you still want to keep things like Fitt's Law in mind, but by no means should you feel compelled to make the damn thing intuitive. Neither vi nor emacs are in the least bit intuitive, but boy are they usable, meaning the interface really squeezes maximum use out of itself.

If I did have to throw in one piece of pithy advice, I'd say that since you're probably going to have to implement some sort of language to express the actions of the interface in, make the API self-documenting, like emacs. I can't tell you how amazingly useful the apropos command is in emacs, how it just searches through the names and documentation of every function and every var in the system, and I don't have to rely on compiled API documentation that may or may not tell me what I need.

Re:Use Cases

[cpt kangarooski]

Sure, but the problem is that the design requirements of even that underlying code will need to be driven by UI demands. If you write a technically sweet filesystem that ignores UI concerns, it will tend to either suck for the user, require even more code to be added in to get it to work usably, or have to be scrapped and redone. E.g. having a filesystem that supports filenames instead of just having inodes that are GUID'd is a filesystem that has been at least in part written to accomodate interface.

Me, I find UI to be king. No one cares if good code or magical elves are making things work; it has to have a good UI. The best UIs appear to be those crafted by skilled UI designers that outrank the developers; they can give the developers an idea of what they want to be able to do, and let the latter group decide precisely how to best implement the UI group's wishes. They don't have autonomy, though.

Computers, and software, have to be developed from the outside in, is what it boils down to.