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."
I'd recommend starting with Norman's The design of every day things. Then, if you're still interested, look over human factors resources. There are very large books that have been written on this question.
C:>
Kiss.
... whenever a text is transmitted, variation occurs. This is because human beings are careless, fallible, and occasiona
Open up WordXP, turn on EVERY toolbar, then make your app look like what you see. User Friendly to the nth.
How are you going to keep them down on the farm once they've seen Karl Hungus?
I wouldn't call their interface 'good' by any means.
Lots of research on Human Computer Interaction. Google it and also check out the digital libraries at ACM. (acm.org)
I've liked The Humane Interface: New Directions for Designing Interactive Systems, written by Jef Raskin. He was one of the early Mac engineers. This maybe a little higher-level than you are looking for though.
"This isn't a study in computer science, its a study in human behavior"
Macintosh gets UI design right with Interface Builder (which came from NeXTSTEP). I cannot recommend it enough.
But what do I know. I'm just looking for anonymous gay sex.
Use self-organizing maps for clustering.
These work well with the visualization needs that you and your group have as well for the upcoming project; search the Web for the Kohonen learning algorithm and apply a simple summation over each term in the respective vector, remembering to square each quantity as well.
This way, the topological view of your program's user interface will be well-refined, easy to navigate, and of a very high resolution (for CRTs, at least -- LCD monitors refresh too quickly and you may get relics [blurs] from high-oscillating models).
Department of Physics and Atmospheric Science, Dalhousie University, Halifax, N.S., Canada, B3H 3J5
So you wrote into Slashdot expecting that? Please!
"the usability engineering lifecycle" is a good place to start, as is "the inmates are running the asylum"
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
Yet another application whose interface is covered in buttons with no labels, tooltips, or any other form of pre-click information or post-click feedback. Perfect.
I suggest that people look into the books that have been suggested, not into the creators of applications designed to be used only by people who already know how to use them - in other words, their creators.
Check out various Smalltalk books or Apple's development documents for more info on this.
We have developed some very large applications that can have multiple views and editors attached to one object.
The main useful point is that every change to the model causes a unique message to be broadcast and all interested parties listen for particular messages and then update their UI if needed. This leads to code that is very loosely coupled and easy to alter with few side effects.
I think the "white dune" interface is excellent.
Rather powerful for being so clean.
Y'all should check it out when designing 3-D
interfaces.
--happy white dune user
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.
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.
...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
Aren't you a chipper fellow.
Happy Noodle Boy says "F###ing doughnut! Mock me? You fried cyclops!!"
If your average grandma can sit down and use it the first time, then it's userfriendly.
Simple but true.
... 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.
That is all.
Welcome to slashdot.google.com!
Too lazy to do a search yourself?
Just have a thousand geeks search for you!
Windows and Mac aren't designed for idiots, they are designed for the AVERAGE, big difference. Having the memory to memorize linux commands doesn't make you intelligent, and using windows doesn't make you stupid. The average person just wants to accomplish his goal as easily and quickly as possible. Good design helps this, bad design hinders this.
Things should be as easy to use as possible, no matter the IQ of the user. That doesn't mean ripping out options, but it does mean logical flow and organization. Frankly you can't be the sharpest knife in the drawer if you think otherwise.
This is true for other things as well, the UI focus on those McDonalds cash registers is designed to allow people with little training to quickly sell and transfer orders of food, while that of a jet cockpit is designed to allow pilots with lots of time in there the ability recieve information about and control almost every feature on an airplane.
Degaussing scares the bad magnetism out of the monitor and fills it with good karma.
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 think some of the other suggestions miss your point. Peruse some of the Ben Shneiderman's books. They will probably give you more practical, specific, and useful help in this case than some of the other experts cited so far. Stuart Card deals with complexity as well, but some of that would be less practical.
I think you're referring to the DOS command prompt, which I believe is referred to as a "text-based interface", or TBI, if you will.
Or you could adapt a currently-existing user interface so that it allows for a rating of user intelligence, based on a simple scale.
Assign points over time (which can be done since modern computers have sequential ability, rather than just a set of combinational logic gates).
Why not attempt (or adapt) the following measure? --
User Ability: {Charisma + Determination + Discipline + Raw Intelligence + Logic + Wisdom)/[ln(Pi*timeSinceInitialInstall)]}
Develop a few simple tests and embed them into some questions (perhaps an inital registration script that loads upon first run) to find each value, and then run the numbers based on the above equation.
Or just have a grad student do it for you!
Department of Physics and Atmospheric Science, Dalhousie University, Halifax, N.S., Canada, B3H 3J5
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.
*Mwwwwwwwwwwwwwwah*
Any better?
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).
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;-).
Regards, Tobias
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.
it must be something that we ate.
Is he asking about discussions of designing a complex UI, or discussions of designing the code for a complex UI? I thought it was about the latter.
Keep It Simple Stupid & Make It Simple Stupid.. key words to head when trying to make your mark in this computer world. Frankly.. having been in it for over 10 years now.. I want something that will listen to me and work with gestures... I'd wear a glove.. get rid of the keyboard and mouse.
(1st sig) If this were a snappy sig, you'd be reading it right now. (2nd sig) I'm a karma whore. >Insert FUD here
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.
Tt just won't support a complex GUI: no drag & drop, no modal windows, stateless client model, weak widget set, poor window-to-window interaction, poor browser-to-OS interaction, etc.
my $.02
there's no place like ~
Dear Sir Grad Student,
Please do this for me.
I shall be willing to pay you
with this shiny new farthing.
Also, if at all possible, you should modify
your equation to allow for dreams.
These "dreams" are something new that is found
only on the super advanced P4 arcitechture.
These dreams happen during the periods when
the processor should be idle. You can tell
that a dream is occuring when the amber or
green light on the front of the CPU is blinking.
This is known as RBLED.
Please keep me informed of your progress in
this field.
Yours Truly,
Sir Guana
Emacs
"Academicians are more likely to share each other's toothbrush than each other's nomenclature."
Cohen
Isn't that in the D&D manual somewhere?
Did I miss my saving throw against not being able to install Word?
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
last I checked:
Windows has IIS or apache
Mac OS has apache
of course, I'm running gentoo... go fig
Go Back to GBS!
Look at science software. It generally is chock-full of weird acronyms and has unexplained buttons. Or consider Linux, which is well-known for being ugly and unusable. These kinds of "blunders" are fine when you are creating software for genius-level IQ people who don't mind taking a few minutes out of every day to learn how to use their most vital tools.
Makes me wonder what the intelligence level of users of a certain, recently open-sourced 3D modelling program is.
pretty big HCI lab at univ. of maryland, college park, with lots of research publications and such. check it out at http://www.cs.umd.edu/projects/hcil/index.html
This is an fantastic idea, but shouldn't Charisma be in the denominator?
Ideally, your system would also support "artifacts" like Unix Guru Suspenders (+1 Determination) or the Beard of Stallman (+3 Logic).
What I'm listening to now on Pandora...
I'd check out material from Google, Amazon, The HCI Bibliography, NASA, the W3C, and Joel for starters.
While some may scoff, the ACM has an article on the Windows 95 interface, a little bit aged by now. Though many in this forum dislike Microsoft for its other faults (the constant crashes, draconian business practices, etc.), a big part of their current success comes from the fact that their user interface is simply easy to use. They do their homework when it comes to that.
My mom couldn't spell WWW when I set up my parent's computer for them a couple years ago. She complained that IE wouldn't go to the website after she typed in the address. It took me a while to realize that she wasn't pressing Enter when she finished typing the address in. That's why they have that little "Go" button next to the address box that I always get rid of right away.. Duh!
This is a noble quest, young hero. God speed.
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
Thank Heaven somebody is finally trying to fix Blender ;-)
Table-ized A.I.
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?
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.
(If you have access to a university library, you can find those proceedings there as well)
Well, I've found -- for me, at least -- that if I can make a good GUI if I stick my pinky up my ass.
It's quick, simple, and gets the job done.
Be warned, however, that if you plan any serious gooey ass exploration, don't go smoking any Madagascar Robusto cigarillos. My mom's boyfriend brought some of those home from Bermuda and those things *require* an industrial air mover near any bathroom.
Yes, this is sick and disgusting -- and will most certainly be mod'd off-topic by the do-good-imps, but sweet mother of god, sometimes the truth needs to be spoken. Even if it is poopee humor.
Other posts have mentioned the many sources of information available, I myself am also partial to Don Norman's work (The design of everyday things). I would also study the work of his associate and a usability expert, Jakob Nielsen. Although he focuses mainly on web interfaces, the core concepts can be applied to any UI design.
After all the patterns and charts, you'll have to start somewhere - and simple is better. Here I think you can derive some benefit from agile methods like eXtreme Programming, which, among many other things, emphasize continuous user-involvement and development over many iterations, with each iteration resulting in a product that can be touched and observed by users. Breaking down a hugely complex UI into interlocking pieces, then developing it piece by piece, testing all the while, will definately help.
Then kick in your usability program. Although emulating successful interfaces (many have been mentioned in these posts) can get you a certain ways, the biggest mistake I've seen in projects is that the end-user of the application is NEVER consulted during development. Certainly you won't let your users design the UI, but you should set up a program whereby you observe them attempting to use what you have designed, keep a thick skin, and be willing to change things that don't work.
Usability testing does not have to be complex, expensive or even terribly scientific, there are plenty of resources (Google is your friend). You could start with the Nielsen Norman Group
"That naive cube! How long must I suffer this!" --Sheldon J. Plankton
Why do you want to design a "complex" GUI architecrure?
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.
The problem here is you're talking about monolithic applications which are designed to be used solo. The very reason it takes to long to learn how to use these interfaces is due to the fact they are designed and run in a vaccuum.
The larger problem with human interfaces in computing is when using more than one application where their interfaces suggest they are each running in their own emulator. Even applications which use the same API suffer from this problem. I prefer to use Carbon apps in Mac OS X because of this. All the Cocoa apps I use behave differently from each other. For example some of them use drag+drop wells which really suck and are inconsistent with each other.
>80 column hard wrapped e-mail is not a sign of intelligent
>life
Actually, most people hate MS for crashing, and don't mind the GUI. MS also tends to rip their ideas off from the best of others anyhow.
Users are probably quite accustomed to the Microsoft look and feel (without the bluescreen look-and-feel) would probably do quite well using a GUI of this variety.
Building a modular program with a GUI frontend would work nicely if done right, but it's good to keep in mind that this is what made some of the earlier windows suck. If the back-end is designed to accept the GUI it should work nicely however.
I think they call it gcc and sourceforge.
DCMonkey
Carnegie Mellon has a Human-Computer Interface group, I'm sure some other univerisities do as well but I don't know of any off the top of my head. If you wrote a few faculty members there I'm sure one of them would reply with the information you're looking for, I'm certain they've run into the problem. http://www.hcii.cmu.edu/
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 have been searching for intelligent discussion
ok then why did you post on slashdot...?
PAC (Presentation-Abstraction-Control) is an architecture specifically designed to address some of the scaling problems with MVC.
Well you might want to check out two sets of interaction patterns written by Jenifer Tidwell:
. html
http://www.mit.edu/~jtidwell/interaction_patterns
http://time-tripper.com/uipatterns/
There's also a number of web sites that discuss HCI patterns that include pointers to other relevant sites. E.g. http://www.hcipatterns.org/
And anyone interested in displaying information should read Tufte's 3 books on the subject.
But again, the original question was not "how should my UI look" but "how should I architect my complex GUI application?" A previous poster mentioned Observers and Adapters, which I think is the best way to go with a multiple viewpoint app like his. I'd work to make this division occur at the highest level possible. I'd have Observers "register" with the viewed object requesting updates only when it changes. And I'd want this separation be so wide that it would even be possible to have the Observers running in a different process, or even connected via sockets from a different machine.
Of course, that's just my opinion. I could be wrong.
John
to reach the single menu bar, all you have to do is throw the mouse up, no aiming needed on the vertical axis. With a menu bar attached to the window, you have to aim.
And yes, the difference in speed is measurable and significant.
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
I guess I am looking for a sort of 'Design Patterns applied to a big deskptop application' sort of discussion.
Then The GOF Design Patterns may be what you're looking for. The case study used for most of the pattern illustrations is that of designing a word processor -- which is no simple feat. A lot of these can be extended to any type of a UI architecture.
-- jimmycarter
This is the ultimate GUI:
[foo@izumi bash]$ _
I haven't seen this URL posted yet (I thought it came from Slashdot a while ago, but I guess I was mistaken :)
Be sure you can answer all of these questions before you even start to think about GUI design. I agree with pretty much everything the guy says.
One other thing, be sure to keep to conventions wherever possible. For example, people are used to having the Exit command at the bottom of the File menu, so (unless you're doing something completely different, as you may be) don't stick it anywhere else. Little things like that make programs more intuitive.
And one other thing: make it as unlike Blender as possible :)
And no one knows that you're trolling...so beautiful *sniff*...everyone responding HBT. They HL. I hope they do not HAND.
There will probably be a million posts appearing saying the same generally bad information, much like in the "What makes a good web site design?" story. Linux users and pure coders are not exactly the best people to ask about GUI design.
KPT (an Adobe Photoshop plugin) had a revolutionary GUI illustrating some of what you mention. Unfortunately, it wasn't as intuitive as one would hope, but, like anything after using it for a while you get used to it. Somethings actually worked more intuitively than others. Perhaps you should give it a look.
It was sold by MetaCreations to Corel/ProCreate, and you can get info here:
http://www.procreate.com/product/kpt/
Good luck!
You should check out the developer docs for Alias|Wavefront Maya, it is the most complex GUI I know of, and their hotmenus and marking menus are totally awesome (and patented so you can't use em, unfortunately). I think there's some docs in there on APIs for the menus and the overall design structure, but there's so much junk in there, I've forgotten.
You should probably also go through past issues of the SIGGRAPH annuals, there is a ton of GUI discussion in there, albeit scattered around everywhere, sometimes buried in nonGUI-related articles.
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.
Interface builder lets you place buttons and assorted widgets in dialogs. It doesn't design software architecture for you.
Congratulations. You didn't understand the question at all.
This is like somebody asking "Speilberg makes great movies - how do i learn how to do that?"
And you reply "get a Panavision camera. Thats what he uses. They're the best."
A tool is a tool, not a solution.
The other thing I would suggest is to pattern it as much as possible after other products the end user is likely to use. If you are trying to woo people away from AutoCAD, make your interface similar to AutoCAD, etc. When I asked my wife what she wanted for her icon to launch mozilla from her gnome desktop, guess what she said? Yep, a big blue 'e'. People want to have a familiar interface until they learn the application enough to do 'power' customizations. Unless your interface is extremely intuitive, don't change it too much from what is familiar. What if a new word processor mapped control-s to 'quit without saving?' No one would use it.
Talk to people who use competing products. They always have something they don't like about the interface, like "why do I have to click through 2 dialog boxes to type a superscript?" Or my pet complaint, "Why can't I use vi editing commands when typing a slashdot post in my web browser?"
This space intentionally left blank.
I'm working on a similar home-grown project. Since it's not an email client or web browser, I say forget about the way things have been done in the past and what the user "expects" and MAXIMIZE EFFICIENCY. Make sure you understand the way the user will actually use it for day to day tasks and absolutely minimize the amount of mouse gymnastics to get that job done. Sacrafice ease of lesser used features to maximize efficiency of the most often used features. I absolutely despise Dia for exactly this reason. They make zooming in and out and panning around a total PITA just to make it "compatible" with the way the Gimp and Gnome in general does things. I use Cadence's layout and schematic editor at work every day, and though their software sucks ass in general, they've done an excellent job making their layout and schematic editors quite efficient.
Check out Martin Fowler's Enterprise Architecture Patterns, some of them can apply to any type of GUI. The MVC pattern does not just have to apply to single components of a window. But there is a difference between creating the GUI architecture for a CAD type program as opposed to a Business type program. For example: CAD programs can have thousands (or more) of objects on the screen at the same time; so modelling each as an object will bring your program to it's knees (using the Prototype pattern can help here).
You might try searching google for 'CAD GUI' or something similar; I've seen articles / web pages that discuss GUI's that are not database backed / business related, but I don't know the addresses off-hand.
Years ago Bruce Tognazzini of Apple wrote a couple of books "Tog on Interface" & "Tog on Software Design". It's been awhile since I read them, but the thing that stood out for me was that he was reasonably critical of the MacOS. He also has a website: http://www.asktog.com/ Useful if you haven't seen it yet.
I think Wolfgang Pree's Design Patterns for Object-Oriented Software Development and to a lesser extent Framework Patterns provides patterns and meta-patterns suitable for complex, dynamic GUI designs. The trouble is that I have never been able to find these books anywhere where I could browse them (being part of of the Addison-Wesley professional series) they struck me as too expensive to purchase site unseen.
That and the contract I was going to leverage them for come to a sudden end.
If anyone wants to offer up their impressions of these books, I'd be interested. At the moment, they rate my someday/maybe list.
~~ What's stopping you?
Take a look at the OpenAPI's exposed by great tools such as Borland's JBuilder, JetBrains IDEA, JEdit and Emacs for an idea of how these marvels are built. Common techniques used to produce a product with complex functionality include: 1. A plugin design. It must be possible to "add/register" new functionality without changing features. The core concepts should be small and form a stable core. 2. Observer/MVC pattern (of course). Decouple that sucker... 3. One thing in one place (avoid duplication). If you've a toolbar button, a menu item, a context menu item, and they all invoke the same functionality using the same presentation names, icon, etc - all of these on-screen locations should be contrived from a single source "action" object. 4. Internal languages Use scripting languages to expose common components (both for internal and external consumption) so that they may be reused in unforeseen ways. Good luck...
Context sensitive seems to be a significant trend. Macromedia relatively recently revamped their GUI's in their software to make heavy use of a primary context-sensitive panel, allowing them to remove several superfluous panels. Adobe in Photoshop 5 I believe added the context sensitive top bar, which displayed some options for whatever tool was being used. 3ds max is perhaps the piece of software featuring the heaviest usage of context-sensitive interface- the righthand bar automatically displays the relevant tools for what you're working on, i.e. polygon tools if you've selected a polygon object, inverse-kinematics settings if you've selected an IK-related object etc. Context-sensitivity is a great help since it basically does work for you, finding the stuff you need when you need it.
Right click menus are a major part of the GUI's in Maya (which otherwise has a very poor interface due to the excessive menu switching and poor menu item organization) and 3ds max, with Maya's being its trademark "hot box", displaying tools in a radial fashion and letting users access sub-groups of items just by rolling over them. 3ds max simply displays a whole lot of stuff in its right click menus, plus pretty colors. Right click menus are in my opinion still under-used... I find it incredibly convenient to access stuff in a single level menu accessible through a single click rather than searching through endless menu items, among different menus and different menu sets (in the case of Maya and Softimage, the former even having a menu item search tool).
One thing to avoid imo is a too linear GUI design. Lightwave features such a thing, in which one must frequently switch between different tabs of different tools depending on the situation. The scapegoat might be that Lightwave has clear and numerous keyboard shortcuts, but that does not alleviate all of the problem. A user should be able to use the software efficiently in whatever way appears intuitive, and not have to suffer learning some specific, somewhat esoteric and assumingly "better" method in order to be the most productive.
Avoiding that though could lead to redundancy in interface, which is another problem. In 3ds max, there are about 3 ways to create a parametric primitives I believe, cluttering the UI unnecessarily with menus, toolbars and tabs. In many other 3d graphics packages similar situations exist.
Overall, I would say the best GUI for very complex software would be one which makes extensive use of automation (context-sensitivity), clear unambiguous methods (make the user aware of what the workflow should be, without making it too strict), and simply a direct and clean organization (no superfluous crap, don't display many tools that can't be used at all in the situation).
The nipple is the only intuitive interface, everything else is learned.
I want to congratulate you for your fine troll.
Keep up the good work!
" Welcome to slashdot.google.com!
Too lazy to do a search yourself?
Just have a thousand geeks search for you!"
The truely funny thing about the slashdot (geek) search engine, is that the hit & miss ratio's lower than the real thing.
if you apply Occam's Razor at every opportunity, take every chance you can to cut down on the number of degrees of freedom, eliminate all choices that are not absolutely necessary, you will usually end up with something that is more intuitive, more powerful, easier (= cheaper!) to implement and has fewer bugs to boot.
in these days of 20 million LOC word processors, and "pile on every feature that we can think of" applications, simplicity is an underrated virtue.
think minimalist!
I worked (years ago) on the Pilot-Vehicle Interface for the F-22. There are techincal papers in Psychology describing how to measure perceptual and cognitive complexity. Perceptual complexity describes how much visual information is displayed. Cognitive complexity describes how
difficult it is to grasp the message being conveyed by the display and how much information is being shown. I think this would be a good place to begin.
Well, not quite, but still close enough to qualify I think.
/. Google Groups :-p) was an idea of how to be able to use any computer to interface with any other computer (adhering to my ideas), without having to change your habbits with regards to Window Managers, shortcuts, mouse gestures and so on, wether the computer is running Mac OS X, Windows 3.1, BeOS or if its a CLI only. If correctly implementet, using Wordperfect shortcuts in VI on a system, you've never accesed before should be possible to the extent that VI supports the features, you're trying to access. Heck - if you were patient enough to set it up, you should be able to replace your entire keyboard with a mouse and use gestures for everything including typing. Weird, but possible.
What I wrote (try to
I know it's a brilliant idea, because the thread on Usenet has total of 8 posts, 1 of which is asking if comp.human-factors is the right group, 2 telling me that it is, 1 is the abstract and four are replys relevant to the abstract.
Can't beat that kind of feedback, can you?
We do not live in the 21st century. We live in the 20 second century.
The problem you describe is one that is run into more often than folks realize, and ignored more often than it should.
I personally would recommend Constantine and Lockwood's books and other information available at this site.
The movie "lost in space" regardless of its
flaws had some interesting circular touch screen
user interfaces. I thought that this must have
been the result of some influence by a design
group from within SGI but I never located any evidence supporting this idea.
A coworker and i joked that some SGI
managers dropped in on a neglected R+D guy and
said "johnson, we like your ideas" pulled his
prototypes and shipped him and them to hollywood.
Then the guy is horrified when he realizes that
his stuff has been sold to be a special effect
instead of being the next GP UI.
Anyway, I thought that those touch screens were
pretty cool.
In exchange for $$$, Slashdot runs an Ask Slashdot with the chosen Google Question. Free answers from Geeks, $$$ for Slashdot, exposure for Google Answers. HMMMMM.
Or not. What was the question again?
http://uml.tutorials.trireme.com/x .com/uml/_ central.asp
http://www.dev
http://www.embarcadero.com/support/uml
http://www.omg.org/uml/
I'm surprised that UML isn't being mentioned.
It's a very useful tool in conjunction with some of the other sources being mentioned for so many reasons. Complexity and UML are made for each other.
You have a document that holds the data, and different views that display the data contained in the document. The document has a defined API that the views can use to find out about the data that the document is storing.
The document could store the data itself, get it from a database, it does not matter. As far as the views are concerned, they don't know and they don't care. The document itself knows nothing about GUIs or windows, or checkboxes or anything. All it knows is how to find/store its data, and make that data known when a veiw asks for it.
You need to decide if your application can handle more than one document at a time. If not, you have a SDI (single document interface) application. If so, you have an MDI (multiple document interface) application. MDI is a little more complex, because your application has to know something about how to best organize views of different documents (using tabs, splitters, etc).
One thing to watch out for - make sure you never store your data in a view. That defeats the whole purpose of the document/view design. The view always gets the data from the document. That way, if you have multiple views on the same document, they are always showing the same data.
Example: You're making a portfolio tracking application. You have a document that stores all your transactions in some data structure. Then you have multiple views of the same document - a graph view, a spreadsheet view, and a report view. The data is only stored in one place -- the document -- and all 3 of these very different views access the same data from the same document.
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.
this book to be of interest.
...but if you find out, please forward the information to whoever is coding bryce now that meta sold it to corel...
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.
The computer is not both the "tool and master". The programmer is the master and the computer is his trusted henchman. The users are the tools.
So you want to architect a complex GUI? Good for you. Here are two simple steps to get you started.
1) Study the Microsoft Foundation Classes to see how they architected their framework.
2) Take what you've learned from MFC's guts and do exactly the opposite at every turn.
You make some very good points. But I don't know if the distinction you cite ever leads to good design. The software I've found most usable started with the UI, and then created the code to accomplish what the user desired. Don't get me wrong, I'm not saying that all designs can work that way, I'm just saying the easiest to use seems to have been designed that way. The absolute most Harry Horsesh*t designs were the ones that took every possible mechanism in the underlying engine and just exposed them to the user. (I have actually seen a program targetted at industrial printing that exposed all font choices to the users. Not just point size and style, but also the things you almost never see, like seperate horizontal and vertical adjustments for the height. The target printer had rougly the resolution of a nine pin dot matrix! The target audience was minimum wage, english as a second language, computer illiterate operators who needed to put a one line description on a product!)
about complex GUI's is: don't! :) I still like pov-ray because I can just enter what I want in a text editor rather than a modeler like 3D-S. Several smaller GUI's built for specific purposes would probably be better than one big GUI. Just break the GUI down into easy ways to do specific tasks. Try to have a consistancy among them. Really, this would be a great place to put object-oriented methods to use. Make consistant components that are groups of other UI elements. It's easy to do in Java using interfaces, but you can do it in C++ as well with inheritence and virtual functions, or call-back functions in C(ech!). I'm sure .Net has a sane way to do it(err, no I'm not really... they probably want you to drag components to a form and use cut and paste, but then you have to update every component to fix a bug, add font settings, etc.), but I really don't know. Any GUI architecture worth it's size in bits has some kind of control grouping whether it's OO, or just faking OO.
Karma Clown
viewtouch.com
You say you "absolutly loath vi" after having read this book. Did you like it before? Because I find vi to be an excellent editor; it lets me keep my fingers on the keyboard where they belong and gets a lot of work done with relatively few keystrokes. And if you also liked it before reading the book, I would think it's sad to change your opinion just because a book told you so.
"Hardly used" will not fetch you a better price for your brain.
"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"
Now you know why I have degrees in psychology and sociology. Classes in Logic also help a great deal in cutting through the chatter.
Designing from Both Sides of the Screen: How Designers and Engineers Can Collaborate to Build Cooperative Technology
Aimed a bit more towards smaller cooperative apps - but it has a lot of REALLY good things to say.
About Face: The Essentials of User Interface Design by Alan Cooper
His examples are windows-centric but he has a lot of very important things to say about where modern interfaces go wrong as well as things that are done right.
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.
So does this mean I shouldn't get a Panavision camera? I am confused.
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.
Why are ask slashdot question painfully obvious and very easy to research! This is a reasonable question but not for ask slashdot! It is incredibly easy to research these materials it should've never been posted. Someone is just being a lazy ass.
I don't really do much reading up on GUI architecture so I can't point you to any resources, however...
I've found that to really create a complex gui environment but keep the code manageable that you should seperate the GUI from the data it's accessing by intermediary layer of code.
What you are really asking (I think) is how to develop the 3 layers (processing, intermediary, gui) so that that cleanly interact.
I typically develop the top and bottom layers seperately. The bottom layer (processing) will accept data and return data. The top layer (gui) will determine what the user does and what the user will see. The itermediary layer bridges the gap.
The top and bottom layers will only be concerned with the type of data they need. If they are done correctly (gets easier with experience) then the intermediary layer will fall into place somewhat naturally:
The GUI wants something, the intermediary layer figures out what all it needs to do to satisfy the GUI's request, gets that data from the processing layer and turns it into something for the GUI. It's really quite fun.
The Common Lisp Interface Manager is far from perfect but it does use a very nice multiple inheritance scheme in CLOS to implement specialized methods based on both the object and a point-of-view of the object.
CLIM has been used to implement complex interfaces as the poster described and requested.
One example architecture... Google will point farther down the path.
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.
What you're talking about here are often referred to as "Use Cases" under the Rational Unified Process for software development. Basically, the idea is to first think about what the product will be used for and who will use it. This involves at least some simple design of the UI. However, at this point in larger projects, the work is divided between several developers. Usually one or two developers or a small group will work on the User Interface, while other groups work on other logical structures (such as database access, or file system access or graphics processing or whatever). If I'm a developer doing this "back-end" work, then I really shouldn't care about the UI at all. That's up to the UI developers. What I do care about is the interface between the UI and my backend code.
I believe the original question was about how to design complex software so that this sort of development is possible (whether by a group or an individual). You're correct that good UI code and a proper understanding of the audience is crucial to a polished application. But without properly organizing the coding process, you end up with logic code mixed in with display code that becomes a mess to maintain and upgrade. Using this sort of architecture allows those who do understand good UI and Human Interface Factors the ability to focus on making the application suitable for the audience.
Who said Freedom was Fair?
The problem with this test in this particular case it that he's not desiging a kiosk or some one-time-use thing.
The people who will be using this app are going to be using it often for long periods of time. If you make it "dummy friendly" it will only hamper the productivity of the "power users" - this is no excuse for poor design, but in this case, it is worth it for the users to go through a learning curve inorder to have an *efficient* interface for the long run.
http://www.opendx.org/
Isn't IBM's Open Visualization Data Explorer along the same lines?
I don't know about source code though.
...reading Alan Cooper's book about face will really enlighten you about what it gets right and the many glaring examples of where it falls down.
I haven't found design patterns to work as well as rule-based coding.
A philosophy I build into all of my GUI applications is "show the user as much useful information as possible". Users make thousands of decisions a day and informed decisions are easier to make. To that end, I eliminate useless information as much as possible to make room for the good stuff.
There are simple facts that need to be remembered while designing a UI:
- eyes move more easily than fingers
- buttons don't provide useful information (but can!)
- scrolling is useless and should be avoided
- minimize clicks, mouse moves and keystrokes
- informed decisions are better decisions
- context-based mouse clicks make sense
- keyboard shortcuts save time
- don't invent new keystrokes for old functions
- everything should work as expected
- file managers should show more files, db apps should show more data
- people can't choose from more than 7 items unless they are grouped
BTW There's no such thing as information overload. There's only useless information. If everything you show on a GUI is well organized it's all useful.
The ad that appeared when I went to read the article was for MS's Visual Studio.
I think the MVC concept is mostly interpreted as a simple design pattern. But it is a much older (measured in IT eons) concept than a design pattern.
MVC is about separating data and behavior (Model) representations (Views) and user input (Controllers).
It can be applied to command prompt operated programs, batch processed tasks, web apps and GUI's. IMO, the narrow interpretation stems from the use of Observer-Observable-Event implementations of GUI widget libraries (Smalltalk, Java Swing/AWT, MFC, VB,...)
But MVC can be applied as an architectural pattern to. Implement and identify objects that are conceptual, logical parts of the application. That embody state and behavior. They have to make up the top level 'model'. Every view that is implemented must use the same basic Model, and register different listeners/observers to it or to parts of it.
The most complicated part is to figure out what kind of event messages to send from the Model (and it's parts) to the registered View(s) and their parts. (the idea of a queue I read in one of the responses seems very good, must try it sometimes)
Controllers can be unique for each user input source (keyboard, mouse, joystick, drawing tablet...) but when using GUI libraries, a dedicated Controller for each View is probably more natural to implement.
In this way it is possible to implement very different views on the same Model. Let's take a 3D drawing program. Objects as 'Car' 'WheelFL' 'WheelFR' etc. would be part of the Model. What kind of views can be implemented ?
- GUI for drawing 2D x-y
- GUI for drawing 2D x-z
- GUI for drawing 2D z-y
- GUI for drawing 3D x-y-z
- reporting view, web based
- reporting view pdf
Each 2D view can represent a wireframe/rendered image constructed from 'WheelFL' in the same application. The pdf tool can be a batch process that opens all drawings and iterates over all of it's objects and creates a pdf with names, coordinates, etc. User input (controller) can be nothing more than a command line argument, or a configuration file, in the last case.BTW, I have learned most of this the hard way, but I'm more than ever convinced of the necessity of MVC on different levels (app -> widgets) to make maintainable large (GUI) applications.
I know others don't think HCI is the place to be looking here, but I really like Jenifer Tidwell's stuff at Common Ground This is a great start at a Pattern Language for UIs.
The only model I've seen in actual programs, seem to be the "hairy ball of mud". Basically, everything is integrated into the GUI-code, and changing one line somewhere breaks 10 things elsewhere.
I had high hopes when Tcl/Tk became somewhat popular, because a scripted GUI seems to be the way to go. There was however three reasons it didn't work out in practice. 1: People didn't like Tcl. 2: Interfacing Tcl and C was still too much work. 3: Tk wasn't enough to build a good GUI, and didn't grow fast enough.
On the other hand, I still believe in separation of concerns. Heavily. I've just spent almost a week(!) hunting for one buffer-overrun in a all-to-large program. The lesson learned: "Don't write large programs" (well, not that I didn't know that in the first place).
The only place we have somewhat maintainable code for large GUI's at my workplace is where we have written something in small pieces. If you have complex data to manage, make that a separate application. If you need some (or many) ways to interact with it, make it separate applications. If you need to save and restore it, make it separate applications. If you need a GUI to coordinate it all, make it a separate application. This way, you can easily separate responsability of different parts to different people, and you can use simple unit-testing to ensure correctness of each part. And you can replace stuff that doesn't work, and add new stuff without breaking old things easily.
Secondly, don't build complex interfaces. Keep interfaces down to a minimum. There is a danger in giving each developer their part to play with. And that is, that their overblown egos will quickly assume their part is the most critical, and needs to be the most complex. I've seen interfaces with as much as 60 interface-functions to just get a simple stream of data. It should be four (connect, unconnect, send, receive).
What should then be your "glue"? Well, I would prefer a scripting language, but as of today, there are still no easy alternatives (they all suck in one way or another). So we use CORBA. It's too complex. It's too easy to be locked into a vendor. But it's here, and it works. If you know of something better, please tell me... (I guess XML-RPC, SOAP, etc... might be an alternative in some cases)
As usual, Dilbert has already solved this problem.
I create an application manager that creates and manages the highest level processes. Processes know how to create and manage other processes. As processes are created they register themselves with appropriate processes so that dependent processes can update their models and view accordingly on change. Then the processes send the messages back and forth.
Of course I'm speaking from the 10,000 ft level, you have to know how to define and implement each specific process so that update( ) knows what to do for each case or each user defined process etc.
I'd actually been searching around for something like this too and havent' found it, so it's been a trial and error thing figuring out a pattern for my app.
/r
What i've found to work is to use MVC in spirit but split up my application into
+ Tasks
+ Models
+ Controlers
+ Actions
+ Views
That's supposed to be a tree. This design came out of planning, reviewing the app's purpose, and environment constraints. I am developing my app in java/swing and i took the strengths it had but combined them into higher-level structures to help me make the app more modular.
Basically,
Tasks are general tasks that the user will perform. For example, an administrator managing customers of a web store.
Views represent the actual UI: trees, tables, text areas, fields, etc. Views register with the Tasks for appropriate model change notifications. I can provide a variety of views for my tasks and data, and incorporate tasks into higher tasks with complex views.
Actions represent the actual actions that a user will perform in that task's domain. for example, in the Administer Customers task, the user can "Delete", "Add", "Search For", "Edit" customers.
An object for each of these tasks is created and given a string representation, an inconic representation, and it implements the ActionPerformed function. this is taken straight out of swing.
Actions are then registered into the views and ui elements.
for example, in my customer manager window i provide a menu, but also buttons across the bottom. So now one action can provide the title of the menu or button text, the icon for the button, and the state for both menu and button.
finally, when either the item or the button are selected my one action gets the notification.
The action then trickles the command up into the task where the logic for enabling/disabling ui elements resides.
The Task then notifies the model (my data) so that proper manipulation can take place. Finally the model notifies the task and the task notifies the uis and actions for appropriate state change (enable disable commands) and view updates (change data in tables, etc.)
it works pretty well, and i've managed to extend things without having to code complex application state notification or validation so close to the UI. it works nicely in java/swing because up until recently most UI coding had to be done programmatically (didn't use resources like a windows rc) so i can tie UI objects fairly easily to controls. but i'm still not happy with it. however, it was the best i could come up with in a pinch.
hope this helps.
Such as that implemented by Libero.
State machines are very good at handling large numbers of events and treating them in context.
The biggest different over classic event-driven GUIs is that the UI states - being your different views, perhaps - are well-defined and seperated, unlike a classic CUI in which there is just one big event loop.
In my experience, using FSM models to define the UI logic (and then turn this into code automatically, like Libero does) makes it easy to build very complex UIs.
Lastly, I think the problem is the same as faced in many situations, namely that of dominating a complex problem.
The key technique is to turn the problem into a hierarchy of solutions rather than to handle it as a single large flat issue.
Abstraction is your friend.
Sig for sale or rent. One previous user. Inquire within.
I am surprised that almost nobody has mentioned Mozilla. Take a look at the Cross Platform Tk documentation and its architecture. They must have a discussion group as well, search for it.
:)
Dude, somebody even put out a DOS prompt
I am not advocating that you do your application in Java, but have you looked at the Java Swing classes? The guys who came up with Swing appear to be total design pattern freaks. There are probably some ideas (like the Observer pattern a few other posters have mentioned, and Listeners) worth stealing and implementing in your language of choice. All the source is available, too.
Jeez you are such a troll. And it never fails to amaze how many moderators fall for this crap. One merely need look at the Nethack source for the correct equation ;-)
:Co:16 In:18 Wi:12 Ch:8 Neutral
Lorelei the Metatroll ST:15 DX:15
Dlvl:5 $:1734 HP:71(71) Pw:42(98) AC:4 Xp:9/3171
Then the second level of the design -- how do I reveal an overview of the complex issues behind the simple display? For example, assume that in an "executive dashboard" type GUI, you have a bar graph showing the status of some part of a mission critical project as "yellow", i.e. may be in trouble but isn't "red" yet. Assume that by clicking in the GUI, the executive can get an overview and that further clicks drill down to the details of why the project is at risk.
Similarly, maybe the project manager for the component sees a similar dashboard, but instead of the higher level view, it shows the parts of the project, including the critical yello piece. You can progressively use the same type of display for different job functions, and the meaning behind the yellow bar changes, but the GUI doesn't. To the data entry person logging parts into the warehouse, maybe yellow is how he looks for back orders, finds the missing component that the widget group needs, scans it in, and the effect up the chain is to "lower the amount of yellow" because it was the critical piece. The GUI code to make this happen is complex, but the design and analysis make the meanings simple to comprehend.
The best example I can think of is the heads up display in the later versions of the USAF and USN fighter aircraft -- the pilot's had way to much data to handle, so they simplified the "GUI" and projected to where it could be seen as part of the pilot doing the job without nearly as much effort. The same type of data could then be fed back to the commanders, etc. in displays so that without bothering the pilot "how much fuel do you have left?" they have a heads up that in essence tells them to get the "next set of patrol aircraft ready because Viper needs to come off-station in 20 minutes" -- because Viper two shows up yellow on the commander's head's up display. So The "++" is that if you do the design right, you can eliminate a whole lot of extra (e.g. opportunities for bad) coding and/or business decisions in the systems interfacing between between the executive level and the data entry clerk --or whatever the particular user sets might be.
...Open Source isn't the only answer -- but it's almost always a better value than the alternatives...
Just a quicky,
If you're interested in exploring the field of human computer interaction further try the HCI Bibliography. If you're particularly interested in user experience, user interaction, and the "stuff below the iceberg" then take a look at the book "Interaction Design: Beyond Human-Computer Interaction" (ISBN 0-471-49278-7) which has a website. Also the IBM Ease of use site is pretty good.
Something to whet your appetite!
--
iDler seemed like a good name when I used to be bone idle (ie: a student)...
I think defining an architecture for GUI design should be a matter of finding/writing the right tools.
HTML is a huge improvement over writing C code for every window individually. Style sheets are a large improvement over using <font> all over the place in HTML. LEX and YACC are improvements over coding parsers by hand.
I guess a rephrasing of your question could be: Open an Excel Spreadsheet. Open a graph window depecting the data that is in that spreadsheet. Change a number in a cell. See the graph redraw in realtime. How do I do this realtime updating in my app?
Our app does something similar: When the user opens a file, they are put into a default view (tree navigator), but they can elect to open additional windows into the same file. These windows may be viewing the same data, or the data in one view might influence what is shown in the other view indirectly. We have developed a messaging architecture whereby a view can broadcast to the rest of the app that a piece of data was {created|deleted|modified}. Other views listen for these broadcasts, and if interested, act on them in order to refresh their currently-displayed data. As an earlier poster mentioned, the trick here is in pinning down the granularity. We have a heuristic that says, if the update list is beyond a certain size, then don't bother broadcasting discrete update changes--instead broadcast a "refresh everything message". So, when deleting one or two items or modifying their contents, the update list is small, and only those items are updated in other views. But if the user does, for example, a copy/paste of 100 items from a different file, or does an import operation, we detect that this is a big operation and tell the other views to wait until the big operation is done, then do a total "refresh-all" off of the database. Our system is crufty, and has grown organically as we have stumbled over performance problems and ugly GUI repaints, but it does work--quite well.....
It does get hairy. View1 is showing data item "A". "A" is related to Data item "B" which is related to "C", and "C" is shown in a second window. If I change "A", then it will have a ripple effect and cause a change to the "C" shown in View2, indirectly. This is a big issue for you: Your data model has to understand all of the interrelationships between your data, and has to be able to calculate (recursively?) the total ramifications of every change. BUT... note that if your app is dealing with structured data, you probably are already having to deal with this issue for your Copy/Paste support! If you copy an item and paste it into a new file, you probably need to be able to drag along all ancillary data related to that item. So, you can look at what your copy/paste code is doing to handfle the data relationships, and possibly you can model your update logic similarly. Or, if you are starting from scratch, you might end up having to write copy/paste too....
Javaone had a presentation on writing real world applications. It's short and very java centric (as you'd expect) but it got a lot out of it. It mentions signs of a poor UI infrastructure of which I had all..(c: You can find it at http://servlet.java.sun.com/javaone/sf2002/conf/se ssions/display-1703.en.jsp . I think you need to be a member of the java developers connection to read it.e .gif.
Also, www.jgoodies.com has some nice gui stuff (java again), but the block diagram of his architecture may be useful and can be found at http://www.jgoodies.com/inside/images/architectur
Computer Language Magazine, January 1990
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
(hi tessa!) nick
I've designed UI for many years, and was the main architect of the GUI framework for a major Java app. The company died two years ago (.com bust), so I don't think there is any problem sharing my insights.
MVC is good. Have your data abstraction implement observable interfaces. Make the GUI listen for change. This is the easy part. But the devil is in the details.
First have the observed object specify what has changed. It is important that the change-message be standardized and be able to carry information about mutltiple objects having changed and what field of each object has changed.
Now you have a GUI that is always in sync. This is Bad! Why? Refreshes: every major update will trigger hundreds of events. If your GUI updates are synchronous, your app will flash continuously and be slow as molasse. The solution: have a centralized asynchronous dispatcher (use a thread) for update events. This centralized dispatcher keeps an hash table of objects that have changed and a hash table of listeners to be triggered. Because the update messages are standardized and can keep track of multi-objects, you can coalesce multiple updates in a single message. Be careful: the coalescing must be done either listener-centric or object-centric, since not all listeners may be listening to the same set of objects.
Then you have to design when messages are dispatched. This can vary from 10ms to 500ms, it depends on how much interactivity you need. This is where a centralized dispatcher helps: when the user grabs a slider that will change some value interactively, you can easily switch the update rate to 10ms for fast response time!
It gets better: having a centralized dispatcher means you can easily stop dispatching (during major data updates) or stop delivering messages (during major GUI modification). For example, when a window opens, you can disable updates until all widgets have been initialized. This avoids ugly race conditions cleanly.
The next step is how to deliver user action request. Again, standardization is your friend. Have an action class. Each user-level action that you have determined to implement in you UI design (menu items, buttons, etc) has an associated action class, which encapsulate all elements related to the action (data item that will be affected, what is the current setting of knob X and checkmark Y). Here the important thing is to have the action class be problem-domain, not UI-domain. So an action called ButtonPressed is bad. An action called SpellCheck is good.
Next you make a work queue where all actions are put. Now, again, you have a centralized place to temporarily freeze all actions during major GUI modifications. You also have an easy point to set your debugger to to see the sequence of actions.
Then you create work threads that fetch work items from the queue and execute them. The big decision here is how many work threads to put in the app. A single thread avoids all multi-threads problems in your data domain. The downside is that the user can only do one thing at a time. If you put multiple threads your application is more flexible but you may have trouble with corrupted data or deadlocks. One way to cut the apple in half is to have multiple specialized work threads, where each thread only work on one type of data. So your user can spell-check the document while changing the toolbar. Or you can have one work thread per document. But the main thing is, if you decide to put multiple threads and your project is getting behind schedule due to major deadlock problem, you can easily go back to a mono thread design until revision 2.0.
This design also buys you easy undo/redo and automation. Just record the action objects store them, replay them, do as you wish!
Remember to use try/catch (or better: RAII if in C++) to always restore the freeze, etc. in the event of an exception being thrown.
That is enough for now, I believe...
On the screen, you usually have some arbitrarily complicated 3D scene. Just selecting something can be tough. It might be too small to point to. It might be so big it doesn't fit on screen. It might be behind something else. So you need to be able to pan and zoom, and maybe clip in the Z direction, even during selection. Selection may have to be multistage, where you first indicate the general area and then select a specific item. This tends to lead to a clunky selection paradigm.
Then there's the problem of specifying what you want to select. Points? Surfaces? Polygons? Objects? Subtrees of objects? Classic Mac-type subject-verb selection becomes a problem here. You need either verb-subject selection, or a palette of selection modes. Both are clunky.
There's the redraw problem. You can't assume you can redraw the whole scene at a high frame rate; the user may have a really complicated scene. Today, this means level of detail processing; it used to mean manual requests for redraw. Everything has to scale up well. No algorithm can be slower than O(N log N). Getting this wrong drives users with big jobs up the wall, or, typically, to a competitor.
Maya, Softimage|3D, 3D Studio, Blender, Poser, and AutoCAD all deal with each of these problems, but in entirely different ways. And we haven't even dealt with drawing or animation yet; this is just selection.
While I don't know the guts of the system, I appriciate the fact that Kai and co. have managed to come up with a great front end to some really complex software. I like the fact that you can get down and dirty with the texture editor (based on the ideas behind audio synthisizers) or just have quick fun with the basic front end.
I drank what? -- Socrates
Sorry, you've lost me. Every serious bit of UI code I've ever seen insulated the actual presentation to and interaction with the user from the manipulation of the underlying model, rather than interlacing UI code with model management code. Is this, or part of it, what you're objecting to? Or are you perhaps referring to the separation of view and controller, as if it implies that presentation and modification of the data must be independent? Or something else? Could you give an example of these smaller problems where MVC breaks down, and why you think it's inadequate?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Nooface also might be a useful resource. If you do change your mind and decide to wade through code, check out Squeak, a Smalltalk VM/environment with a really consistent and fast GUI.
In the great CONS chain of life, you can either be the CAR or be in the CDR.
I have been working on projects like this for the last 5 years, 3D applications used to synthesize and analyze relatively large dental simulation models. I am currently working on complete revisions of the first iteration of my departments software, intended to correct many of the design mistakes made with the first versions (and lots of mistakes get made with software designed and implemented by undergrad and grad students). These new versions are designed to be more modular, extendible and portable across multiple platforms, and maybe most importantly have completely redone interfaces.
I think one of the most important concepts in this kind of software is making clear the difference between data and presentation in your interface. This is somewhat of a departure from a lot of software like word processors where what you see is what you have, most things you can do to change how a document looks actually change the document. This is not what you want to do in many CAD-style scientific apps. This means basically throwing the document-view style architecture out the window, because for the most part you won't be using a document metaphor.
What I use might be called a database-workspace-multiview architecture. All of the data objects are stored in a single structure, in my case a hierarchical tree with each object accessable by a name or handle. This named hierarchy makes it easy to group related data objects and add additional metadata later. The most important objects in this core that the user will interact with (depending on the design this structure may also include a lot of internal framework objects) should be exposed to the user in some sort of workspace view. In my software these major data objects may consist of dental patients, which in turn are composed (mainly) of 3D models representing the upper and lower jaws. This workspace allows the user to interact with and modify the data directly.
The other major interface are the views. My software deals mainly with 3D display but also utilizes 2D "slices" of surfaces. The user should be able to create these view on demand. The display settings available for each view should be tied onyl to that view and use metaphors indicating that they only affect display but cannot modify the "database" (e.g. a surface can be shown or hidden by a view, but never deleted). When a user can modify actual data through a view interface it must be with tools that clearly distinguish between visualization mode and modification mode.
To tie all of these things together we created are own messaging framework. We felt this was necessary to ensure future portability and not tie ourselves into Win32 messaging (currently Win32 is the only platform being actively developed). We use essentially two types of messages: commands which are sent to a single target (and work like ordinary functions, but more generically), and notifications, which are broadcast to all objects that want to receive them. Example #1: a project is loaded into the app. Many tools are only available if a complete project is available, so these tools listen for this message and enable themselves when the project is loaded (or a new one is created). Example #2: a section of a 3D surface is trimmed. All tools responsible for rendering surfaces in views listen for the message and redraw their views if the model trimmed was visible in their view.
There are a few other advantages to usingour own messaging system. It enforces good programming habits be requiring a little extra through to go into the interface for various objects. By making it text-based we enable scripting capabilities, anything that can be done through the GUI can be done (or at least simulated in terms of mouse and keyboard input) through scripting. Our core data hierarchy can be easily inspected using debugging dialogs, as can most of the internal metadata, which is stored in primarily text format when possible and streamable to XML.
Basically I think it comes down to good modular design with a UNIX philosophy. Start with core utilities, data structures and algorithms, keeping in mind the importance of algorithms being able to suspend or be canceled in many cases, as well as reporting progress. Layer a messaging/scripting-style interface on top of that, and complete with a GUI that makes the distinction between data and visualization.
The ultimate plays for Madden 2006
Look at the works of Michael Jackson, who used to be well-known as the source of 'Jackson Structured Programming' and has more recently looked at workflow issues. With JSP, he explained how there is usually a clash in data structure between input and output, and how the job of programming was to resolve the structure clashes. In the UI case, the clash is between the units of human work that users bring to the machine and the transactions that the computer knows how to process. Use the machine to resolve the clashes; don't make the user do it.
I'm looking into designing/discovering a general framework+API in one or more languages/toolkits to implement complex graphical interfaces. All GUI code is a conglomeration of state machines and widgets, but how to organize those objects is left to the programmer. Swing has plenty of flexibility for example, but no guiding principle on which to build a multi-JFrame application - all of the published examples through you into a main method which points to a single hypothetical JFrame subclass or something. Anyway, language and toolkit aside, you are right on the money in terms of identifying a deficiency in tooling. If you'd like to start up a dialog on this issue, please let me know via e-mail at daniel@psionik.com. This issue has been tackled for writing Perl/Java-CGI/JSP applications, via callback controllers and server mappings, but surprisingly, desktop app toolkits/gui libraries are behind the times in terms of frameworks, I feel.
This is my humble opinion on how to design a good interface:
1. Define your 'document', i.e. the data you're going to work with as a set of classes.
2. Define a user interface that lets you access these classes (their methods and properties) when they are relevant.
3. Make sure to analyse what functions that are going to be used most, make them one, or at worst two-click commands.
There are a number of ways of showing information to the user. I list a few good ways here, no special order:
* Show global information in a status area that is globally (read always) visible.
* Show local information in a special area, so that the options for a line and a box appear in the same place even though they may contain different options.
* Provide two interfaces for complex operations, one wizard (with an 'don't show this again'-option) and one dialog (possibly with tabs) allowing the advanced user to pick the items that he/she needs.
* Use context menus (right clickable or automatically appearing in the menu bar).
* Make frequently used commands (let the user choose, but supply an intelligent default) on a toolbar. Let these buttons simply trigger a standard command, i.e. no extra code here!
If you have done your document classes right it shouldn't be too hard to add all the inteface classes around them. Perhaps you will have to handle some states in a view, etc. But otherwise it should just be a matter of wrapping the document into something UI like.
As for tools I must say avoid MFC (i mean *run* if you hear it mentioned, it is not a serious option). The same applies to Borland's alternative (I cannot remember what it is called). If you are forced to write in C, use GTK and perhaps Gnome, but be prepared to write OO code in C, and a huge dependency problem if you use Gnome. Also, portability is not always what it aught to be. If you have the freedom to use C++, use Qt. It is portable, beautifully designed and works flawlessly.
I must also say that the implementation 'method' I presented above fits very nicely into Qt. I think (haven't tried any big projects with it yet) that it is quite easy to do in GTK too.
Good! Now see if you can make Maya's interface usable to grandma. Bet you can't without avoiding the learning curve.
As far as I can tell, many of the prominent HCI researchers argue that you should place the UI at the centre of your design and munge everything else to fit.
This goes against the common wisdom amongst software developers, particularly in the Un*x world, that you should design the cleanest, simplest, most modular backend possible, and graft a wetware translation module over the top. If you don't do so, you're likely to end up with a nasty, unmaintainable mess, and the bugginess of GUI systems when compared with systems without such complex UI code tends to give credence to such an argument. But if you do it this way, is the UI going to end up compromised? Probably.
So how do you find a way through this? Evolutionary software models seem to help. Talent and experience tend to assist a bit :) But as for a systematic way to cope with the problems this culture clash raises, I've no idea.
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
The Interface Hall of Shame looks at the worst cases. Good for a few laughs, at least. :)
A)bort, R)etry or S)elf-destruct?
You've brought a rare thing to "Ask /.":
A good question that can't be answered without advice, that doesn't score a bazillion howto-hits on Google and that isn't shure to be absolutely above the heads of the slashdot crowd.
Nice to have some good question asked. Thanks.
Now for my shots at closing in on answers:
I have no larger mentionable expierience in UI design apart for the fact that I do have some webdesign expierience and a professional artist training, but I have used and operated a wide range of professional tools in the professional manner in which they were meant to be used and operated!!!
And that's a very important part of my/the answer allready:
All extremly complex professional GUI-tools each have their very own distinct, standards-pushing look and feel acustomed to their application family more than, let's say, the CUAS. And that's what makes up a good tool.
People who use Avid use it almost exclusively and for hours and years on end - and often on special hardware too. Same goes for Softimage or Houdini. Or check out the difference between Freehand, Illustrator and Corel Draw. The distinct, special funtionality of vector-drawing apps is approached in a different way by each. That's the same reason why you've got a wider range of Video NLE apps that do all the same but with often different workflow aproaches.
See what I'm saying: If you're tool is gonna be complex due to very special funtions that only a few people will need or even know, there is no point in trying to find a standard for GUI design. You won't be able to apply it properly.
What to use? Photoshop layers or Photopaint objects? How to join vectorcurves: Corel connect and combine or Freehand extend and join? The latter is a very good example: 2 totally different but valid approaches to a very important problem. For those that need solid vector graphics power.
Bottom line:
Programms that are so complex that they are most likely to become stand alone tools (maybe even with custom hardware!) *can't* follow design standards - because there are none! Such a programm gains recognition by having a distinct character and one team of professionals in it's userfield that really know what they're doing and set up their own set of rules and preferences as to which way the app has to work, behave, look, feel and is intended to be operated.
And believe me, nothing sucks more than trying to make a complex powerapp like, let's say, a 3D modeler, instantly 'usable' for people who only know office gui standards. Check out kpovmodeler to see what I mean.
We suffer more in our imagination than in reality. - Seneca
One of the most promising approach to help the problems when making UIs is Naked Objects framework http://www.nakedobjects.org made in Java language. The idea is that developer just make classes that end users can understand and object viewing mechanism (OVM) will show objects to the user including attributes and methods. You can have a drag-and-drop GUI without writing a single line of UI code. And if you are not satisfied with current look and feel, just modify the OVM to suit your needs - it is in LGPL license. I recommend to take a look if you like object orientation and agile software techniques (extreme programming).
For a lighter-weight approach to the same problem check out the MSDN article on MotLib.Net (with plenty of C# examples) It's the start of a bare-bones XML based Winforms framework, but it is simple enough to understand in a single sitting. You can extend it fairly easily.
Everyone talks about MVC/Observers-Adapters, but I find that the Command pattern is underrated. Implement all actions using objects: this makes state management a lot easier, and makes scripting and consistent security a lot easier to handle. Having commands decoupled from the UI also lends itself to unit testing, something which becomes difficult to manage once the user interface starts waiting for input.
MVC is cool. But with a GUI, the V and C are usually combined (delegate model?). It sometimes is useful to split the view and the controller logically but combine them in actuality each time, so you have the possibility of a controller-only or view-only component.
One key thing is to ensure that the talk between the M, V and C is all asynchronious - that way, you can go put parts in different threads, or even on different computers, without having to rethink things too much - that should prove scalable.
The question is "which pattern?", and the answer is MVC. The reason it is so used is because it works. If it kills responsiveness at first, consider optimizing your graphics; it is usual to write early versions of your view that do complete updates each time, where later you might have more conservative redraw-what-is-needed logic in there. It usually is the view that is the slowest bit! Especially in the examples cited like CAD.
This is all language-agnostic, works equally well in Java, C++, object-pascal (neat), etc.
One useful thing if you start small but want to scale big is to abstract the message-passing between components-part. You can write a model object, then later when the model is on a remote system you can write a shim that looks like a local model object but infact defers everything to a server; another approach in a truely massive distributed network is for the local shim model to cache a large chunk of the model, and defer only modifications to the server, using the cache for local visualisation. At that point you want to go looking at patterns for this bit, and thinking about syncing all your distributed model shims. But you see how it scales and scales and scales..
I know only its name, so go here tp learn more.
BugBear
Ignorance is curable. Stupid is forever.
There is only one way to write a proper GUI application: the model-view-controller paradigm.
The application logic should be encapsulated in a set of objects that implement all functionality of the program. This logic includes the dynamic behaviour and the static behaviour. The end result is the 'object model' of the application, which contains all the stuff that the app must do.
After you construct the object model, it is easy to construct a UI. The app widgets will use the object model in order to achieve the desired functionality. If then you don't like the gui, you can modify it, but the core part of the app would be there.
You can later change completely the front end, and maybe put a console interface, if you thing it is needed.
There are two special rules that you should obey:
1) avoid putting any app functionality in widgets at all cost; this is an often mistake of Visual Basic programmers: they put all code inside a form, and later when they need to perform non-gui actions, they must load the form first!
2) put events in your objects that notify the outside world of there state change. This allows for true componentization. See Qt's 'signal and slot' mechanism, Java's listeners, Delphi's events, etc. You can later connect these events with the various widgets very easily and flexibly.
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 :-)
I read quite a few of these comments and didn't find anything mentioned about Cognitive Dimensions (http://www.thomas-green.ndtilda.co.uk/workStuff/P apers/introCogDims/ ) or Ontological Sketch Modeling (http://www.thomas-green.ndtilda.co.uk/workStuff/P apers/OSMsIntro/OSMsIntro.html ) ... both very good places to start depending on how far you want to go with the analysis before you start introducing design patterns ... Definately recomend starting somewhere like this
Liquid oxygen is more dangerous than liquid nitrogen. Put a hand in N2 it falls off, in O2 it falls off and catches fire
Be sure to study the Lisp de-facto standard UI system, CLIM 2.0, closely. It's great for complicated GUI systems for OO Lisp projects.
Alsom, be aware that the best GUIs tend to be the ones that let the user do most anything your underlying program code can, and combine things in unexpected ways. Make sure to read up on Naked Objects
Speaking requires something like 80% brain activity. Reading, Pointing, Clicking and single key hitting alltogether only round abouts 20%. :-) ) with no sweat.
You can operate a fluid/consitent GUI setup that makes good use of possible short fingermovements (forget that waving about in "Minority Report", it's a dead concept) on mouse and kb and still think deeply on what is just on your mind (your actual work maybe?
There is no way in hell you can do that while talking (or boxing the air).
We suffer more in our imagination than in reality. - Seneca
there is an interesting look at how not to design an interface at http://www.iarchitect.com/index.htm
I think we should all be working on the technology that allows us to shove a socket into the back of our heads, like Keanu Reeves, and then make the computer Do What I Want.
Always keep a sapphire in your mind
I design COTS desktop apps for living. Here are two patterns that have proven themselves many times so far:
1. Lazy evaluation of almost everything. Whenever one or more data objects change, they fire notifications that they have changed which are passed through the object graph to the views. The view then doesn't do _anything_ except invalidate itself. When the paint message comes later, it re-computes everything on the fly. (In case you are worried about performance: lazy evaluation and eager evaluation speeds are generally equal.)
2. Your event handlers shouldn't do anything by themselves. They should just call a function that actually does the job. This gives you a nice split between functions that are called as a direct result of users' actions and functions that are called internally. Very useful for undo/redo, traces and testing.
Dejan
ohhhh, that's such a bad example.
outlook has good HCI until you want to implement productivity improvements, like tree based tracking of email, and decient contact management that links into a database. The GUI just can't handle supporting a well intergrated office productivity app.
First, try not to spread around all the code that changes the GUI. For example, if you're displaying a dialog box, I like to have one function that basically computes the entire dialog's appearance -- fills in all the fields, enables/disables everything, sets labels correctly, etc, etc. Think of the entire GUI as the result of a computation that takes your "model" as input -- and make that computation centralized. It's easier to correctly handle one or two different "something changed" events than one or two hundred.
If you take that to the extreme, then you'll eventually run into slow update times, since you're basically redrawing everything whenever anything changes. So if you start noticing slow response time, then you can start separating the update code into pieces that do less work. But avoid premature optimization.
Second, always make sure that your GUI accurately reflects the contents of your model. For example, if you're working on a GUI that controls some hardware, and the user hits the Shutdown button, then don't immediately display that the device has shut down -- instead, just send the shutdown message to the device, take whatever precautions you need to in order to make sure you don't let the user hit Shutdown a second time, and then wait until you hear back from the device before you display to the user that it has shut down. In fact, I wouldn't even display to the user that the device is "shutting down", since for all you know it never got the message.
In general, when updating the GUI, try to update everything that MIGHT have possibly changed, instead of trying to do the least work possible. An example of a program that fails to do this correctly is Abiword when it uses red under-squiggles for misspelled words. If you scroll so that part of the squiggle is off the page, and then you scroll back up, then sometimes the squiggle gets displayed incorrectly -- it looks sheared.
It's been a couple years since I did GUI work, but off the top of my head those are a couple of the most useful techniques.
What the... Why the hell was this post modded to "offtopic"? I'd really like to know... I've read Alan Cooper's "Essentials of User Interface Design" partly based on his earlier "About Face" and I think it is a fantastic piece of work for those who want to seriously write a good graphical user interface..
Then about 2 1/2 hours later, somebody came in and modded it down one as Offtopic. I have no idea why.
It does point out a bug (IMHO) in the moderation system. You can get 4 or 5 mods up, but if somebody wants to come in at the end and declare "troll" or "offtopic" then thats the word that gets pasted on the end of your moderation total. Of course its still scored 4 so its very visible, but I wonder how many folks see "Offtopic" and skip, regardless of score. Always taking the last choice as the name doesn't make sense.
Ironically, this post is technically offtopic.
Not hard at all...I'll just use its own scripting language to create something simple that even she can understand: A button to create a ball, one to create a cube, one to create a checkerboard pattern, and one to render. Presto.
If you're talking about making the art of 3D production easy to learn, it isn't going to happen - at least for a while.
interesting topic. this variation on mvc might be useful: http://www.atug.com/andypatterns/mgm.htm also perhaps: http://www.appdevadvisor.co.uk/Downloads/ADA5_9pdf s/Hunt5_9.pdf, http://www.jaydeetechnology.co.uk/planetjava/tutor ials/swing/The-Visitor-Framework.PDF, http://st-www.cs.uiuc.edu/users/droberts/evolve.ht ml,
http://www.rolemodelsoft.com/patterns/javaextend.h tm
hth
hth
vice chair orange county java users group (ocjug.org).
I'm currently designing a GUI application that has to deal with an SNMP-manageable device that has a lot of specific features.
I decided to use a "physically" modular architecture based on MVC paradigim.
Each module (which can be dynamically loaded by the application) implements its own MVC but each controller doesn't speak directly to its model.
I use the main application as a public dispatcher which each module Model (in MVC paradigm) has to subscribe to, presenting the high-level messages they want to receive.
In an MVC way, the main application acts as a meta-controller.And i can achieve full architecture openess (each part of the application is a real plug-in)
But MVC doesn't cover the underlying window system programming model.And things can become somewhat confuse.
So, the module insertion protocol has to specify a way to handle GUI integration (like inserting menu entries into the main application menu) Moreover,the MDI (Multiple Document Interface) programming model complicates a little bit. (Better Not speaking about the Microsoft MFC Document/View approach !)
So, doing an efficient GUI application architecture requires integrating good OO paradigms (like MVC, plugin architecture) with often inconsistent system GUI pseudo programming model. The main problem is here.
MVC is efficient if the messages/orders between the M,V and C are of the highest possible level with detailed information associated.
IMHO,A good approach is to make autonomous,reusable GUI components which are only System GUI compliant but highly customizable (with callbacks).
Thus you can implement MVC by using a View (in MVC meaning) Adapter Object for giving a view behaviour to your GUI component, then configuring or subclassing your GUI component to insert the controller behaviour via the callbacks.
All simple interactions are held into the component, all interactions impacting application logic are transfered to the controller via the configured callbacks.
You have a main form, and you have widgets, and widgets are pretty much only able to fire events that notify the main form -- the main form is the mediator. So if you want to link a bunch of widgets together, they cannot talk directly but have to signal their main form (mediator) by firing events, and the main form has to sort out which widgets need to be updated in response. So the main form acquires this blob of spaghetti code that ties all the widgets together.
There are instances when you want widgets to be in an observer/observable relationship -- to communicate with each other and sort out their differences without telling Mom (i.e. the main form mediator). VB makes this difficult to do. Delphi/C++ Builder allow this to be done -- one widget can have a reference to another widget as a property to set up and observer relation, although not many widgets use this capability. The Anders Hejlsberg-influenced C#/Visual Studio .NET also has this capability.
You may say, why the whole purpose of mediator is to avoid a rat's nest of multiple observer relationships among a network of widgets. Yes, and the whole purpose of giving employees a supervisor is that expecting a company to run on an ad-hoc network of relationships without the ability to get direction from a boss is the same thing. On the other hand, if the boss is the pure mediator pattern, the boss is overwhelmed by employee queries and the boss will wish that the employees could talk to each other and not involve the boss in every last decision.