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."
Kiss.
... whenever a text is transmitted, variation occurs. This is because human beings are careless, fallible, and occasiona
"the usability engineering lifecycle" is a good place to start, as is "the inmates are running the asylum"
Microsoft (I know, you don't want to hear this)
has some very good books on GUI design.
A complex architecture such as an Autocad or
a Corel Draw is a GUI that is the front end
of pieces of robust code that run without the GUI.
Perhaps what you really need to do
is to study application design because if you focus on GUI then you get something that lets you see and interact, but not something that will be fault tolerent and robust. IE: The application is made up of a lot of pieces only some of which are GUI pieces.
If the parts that do the number crunching are coupled with the GUI than a problem with your GUI will bring down your whole application;
Here are the names of the two MS books:
Microsoft Windows User Experience
Developing User Interfaces for Microsoft Windows
You can say a lot of bad things about Microsoft, but you can't say that they don't get the GUI thing right.
PS: I picked these up for $10.00 each at a Dollar book store. They were worth the price. Also, the second book gives a list of other (non MS) books to refer to.
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.
no, i think that would be "idiot-friendly"
Life sucks, but death doesn't put out at all....
--Thomas J. Kopp
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).
/., many others).
Other common approaches are essentially Use Case driven and can be very directed (see Installshield). Or more generalized (see phpAdmin,
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).
it must be something that we ate.
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.
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?
If my experience is any indication, people who implement complex applications are not necessarily the best people to figure out what the user will do with them or how the user will wish to interact with them. You can write an initial GUI, but expect it to be lacking.
One strategy to address this is make your whole GUI scripted. Implement all GUI commands with script language bindings, and implement your GUI as a script in this language (this can be done with Perl, Python, Tcl/Tk, etc.). Provide hooks for your users to create their own comands and extend the GUI as they wish. Now you don't have to figure it all out, because your users will.
This model is used by many complex applications, such as IC design CAD frameworks (with which I am familiar). Just make sure you don't fall into the trap of thinking you need your own scripting language. Use an off-the-shelf language.
"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.
When implementing semi-complex interfaces, certainly not on the level you require, I've created multiple controllers and not just relied on one. I've placed the controllers at the process level so that not only processes know how to manage and update themselves and their views but they know how to interact with other processes sending messages back and forth for other processes to update themselves and their views. In fact, on a number of projects I've started with a base class ProcessManager and created specialized managers from there.
I know this is only cursory information. Perhaps it will help you while you think about your direction.
What do you define as a large, complex program? A lot of enterprise software work done for F500 companies are built as web applications (Struts-esque) using the MVC pattern. These applications scale to 10,000 users (and more) and obviously run on some serious hardware setups. Most of the applications aren't that sexy...they really just streamline business processes and help (hopefully, but the cynic in me says doubtfully) save money.
Anyway, back to the original question by the OP, there really is a dearth of information on the areas between architectural level patterns(MVC, blah blah blah) and the high level interaction-design/usability/experience world. I've found that in the software industry most of the nuts and bolts tend to be one-offs and specialized solutions, sort of whatever-it-takes-to-build-the-bridge. There are definitely existing toolkits, but when in comes down to it there's a buttload of unrefined work that needs to be done. Of course this is the case in any part of a significantly complex application.
In my experience I've built some pretty nifty ways of building UIs and in some cases I've abstracted out a lot of the nitty-gritty. The interesting part, though, is that most of the clever stuff I came up with was already pretty much expressed in existing design patterns (GOF) or done the same way decades ago, just with different paradigms (web vs. mainframe, which addmitedly aren't too different). I guess my point is that these problems have been repetitively solved over time, but so little of it has been truely formalized in the same manner that other aspects of computer science and software engineering have.
But honestly speaking user interfaces have really taken 2nd (or 3rd, or 4th, or -gasp- Nth) place to other topics in the ivory tower of computer science. Most kids coming out of CS undergrad programs are more excited about things like optimization, scalability, or building complex software like OSes and databases. After all, these are the hardcore, tried and true, well formalized product hallmarks of computer science.
To get back on topic again, the OP mentioned being reluctant to wade through the source of KWord. It's a tedious activity, but studying how existing or even historical applications were designed can be highly beneficial. As I said above I've invented a new wheel quite a few times only to find out that it only mirrored a previously built solution.
Well, there is nothing to prevent some of your views also being models.
n %2 0Presentation%20Abstra/
Also, as an alternative to MVC, take a look at Presentation Abstraction Control.
Google yielded this site, among others:
http://www.vico.org/pages/PatronsDisseny/Patter
"We can't solve problems by using the same kind of thinking we used when we created them." -- Albert Einstein
Most of the replies have focused on web based, thin clients. The poster is talking about thick clients where the user has a lot more functionality than a typical web page.
He needs answers to questions such as:
- Do I multithread communications between client and server so that the user can still interact with the UI, or do I use a single threaded model where less things can go wrong?
- Do any patterns exist for editing data models via the UI and implementing undo/redo ( * see the Memento design pattern)
- Exception handling: how to manage errors in communication and data and inform the user in an elegant, consistent manner.
I deal with these issues in my current project - they're pretty common on client side applications, but I haven't been able to find any useful sources to help answer them either.
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.
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.
Note to ACs: I won't mod you up, even if you are being funny or insightful. So take a chance! It's not real life!
Visual and direct manipulated systems, such as 3D editors, are implementational beasts. Semantics of the user input does not happen in the traditional GUI. Mouse events just fall through the viewports and you have to figure out the semantics yourself starting from the most primitive level. There is no well defined GUI to do this for you, by doing something visual and direct manipulated you have given that task to yourself. You have to map from 2D space to 3D space. You have to implement constraints on what the user can do. Direct editing of 3D models usually gives the user freedom to do all kinds of evil operations, such as deleting complete hierarchies or maybe accidentally removing a single vertex which pretty much wrecks your meshes and cause all kinds of dependency problems. And, gasp, you need to implement such features as undo and redo. You also need the traditional GUI (windows, images, etc), and you have to implement the glue between it and the direct manipulated system. And so forth on.
In my opinion, most common implementational models, such as MVC (you probably mean MVP or MVC++ because the original MVC is quite SmallTalk dependent), are designed for implementing form based apps and are not directly usable on other kinds of apps. Also, most GUI architectures or implementational component models tend to focus on how to glue the user interface to the app's logical model. When implementing a complex GUI the problem is not really how to map between the model's and GUI's data. The problem is how the whole hierarchy of interdependent GUI elements, not components but bigger units, is constructed and coordinated. That is, of course, application specific and cannot be fully solved by some standard architecture. But still, it would be nice to read something else than "the interaction, hierarchy and dependencies of controllers is left undefined".
So, do I have any solutions? Well, nothing beats doing specs and implementating (big suprice). Gamma's Design Patterns is once again a good read. My current project is using most of Gamma's patterns and "pattern paralysis" is not even nearing. Forcing a complex UI to follow some "standard" architecture is not a good idea. You are better off by designing your own UI architecture which reflects the concepts of your application and borrows the best ideas from other architectures. I, for instance, have not implemented a pure MVC-style architecture for a long time. Umm, trees and graphs are structures that pop up everywhere.
Cheers.
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.
I've finally had it: until slashdot gets article moderation, I am not coming back.
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.
-- This and all my posts are in the public domain. I am a lawyer. I am not your lawyer, and this is not legal advice.
First off, let me apologise for trying to answer your question, as that doesn't seem to be the done thing around here.
The paper Advanced Control Flows for Flexible Graphical User Interfaces discusses how to write GUIs that have the same flexibility as web applications (back and forwards motion between states and multiple views of the application). If you have a programming language theory background the technique is continuation-passing style. If that means nothing to you just read the paper :-)