Spears mostly. And if you got in their way, they stuck 'em inter ya face.
Your users don't know what they want: they have lots of ideas for what they might want. They don't know how they are going to use the system: they have lots of ideas for how they might use the system.
While developing the system, run it from a workspace, or from the simplest GraphicalUserInterface you can create. Then when it works well enough to actually test, sit down beside the user and be the computer. Ask the user what s/he wants to do next. Make a note of it. Do it, show the results. Repeat until the real use of the system is a bit clearer.
Provide then the simplest interface you can create. No bells, no whistles. Sit down and watch the user. Make the things they find hard easier. Move the features they don't use off into the boonies. Repeat until you have a system that really does what the people really need.
It takes nerve to use this strategy. People will panic. But remember, GUIs are easy - you can even do them in VisualBasic.
See also ModelFirst. -- RonJeffries
Imagine you have a large, heterogeneous group of users spread around the world. You then need to FakeItConvincingly, watch them use it, and iterate, iterate, iterate. For high-risk products, this is a project in itself. -- SusanJohnson
GUI layouts in Visual Basic are not easy, unless you're willing to throw something together willy-nilly that doesn't resize or scale well, and you don't spend time making sure everything looks nice.
Ugly GUI layouts in Visual Basic are not easy, except if you don't care how usable your users find the application.
Ugly GUI layouts that aren't useful to the users are easy... in Visual Basic.
(I agree with the principles described in SpartanUserInterface, but I think the "GUI's are easy" statement is unnecessarily condescending and misrepresents the amount effort that goes into creating a quality GUI.)
Pretty user interfaces can help to build support for your project, ugly ones can kill it. Perception is all.
Another argument is this: some users and customers cannot differentiate between "the same program with a new front end" and "a completely new product". Sometimes this is useful, sometimes this is deadly: know your customer.
However, there is sense in SpartanUserInterface. The hours spent building a component that is not used in the final release can leave a developer very upset.
My view: be careful who you show your SpartanUserInterface to, it may be the last thing that you show to anyone!!!!!
-- Simon Thompson.
What about HtmlUserInterfaces?, then? Would YOU build the user interface to a large application using HTML?
No, I would not. HTML interfaces might allow you to quickly build a stylish(?) but simple interface. However, it brings along problems that I would prefer to avoid as most simple interfaces grow.
I would. HTML is great for SpartanUserInterfaces. HTML is bad for "stylish" interfaces.
Not necessarily so - as always, it depends on your project. The project I currently work on essentially only supports IE5+. Granted, we are not a commercial entity and automatically have a captive audience, but it makes our job a lot easier...
If you bump into browser specific issues, your HTML interface is not spartan enough. Of course, you can do bells-and-whistles interfaces with HTML, but that's as complex an issue as any GUI programming.
Using HTML puts constraints on usability. Getting a whole page at a time makes it difficult to check any user input until (s)he has completed the whole page.
Input validation is overused in most applications. It should be done only when it's really critical that the data be in a certain format. Also, often it can be replaced with automatical normalisation to a form (for example, delete all non-number characters from a phone number field but don't complain).
It also takes away the ability to add helpful finder buttons, , and hide or grey controls that are not relevant to the settings the user chooses. In fact, anything beyond the basic form makes the page large to download and the pauses interrupt the user's flow of work.
Again it depends on your project. We don't have long download times in ours, but then we don't have 50-field forms - IMO those should be converted into multiple-page "wizards" (ugh) anyway. As for greying out controls, IE4+ supports the "DISABLED" attribute on form elements. This is an HTML 4 feature (see http://www.w3.org/TR/html4/interact/forms.html#h-17.12) and should be available in the latest version of Netscape as well.
Using web browser clients forces a certain type of architecture. The openness (menu->view->source) of the client forces the business logic state onto the server, then for the server to scale properly ("Oh and while we are at it make it work for 1000's of users") it has to be stateless for load balancing software used on the web-server to work. The non-persist HTTP connection forces the client to do something akin to a login for each message, and assume that lack of messages is a logout. Eventually most of the code that is written is not for the business logic or UI, instead it is for maintaining the session.
''Once again, depends on your implementation. If you are using a server application that supports sessions natively (IIS, and I believe JSP as well as several others) then you eliminate the worry about sessions. HTTP 1.1 supports "Keep-alive" connections, but nobody uses it that I've seen. Also, which is better:
Keepalives are more like a norm than an exception, but they're not meant for sessions. Session functionality, as other such facilities, make your computing environment. It would be nonsensical to blame Unix as a programming environment of the fact that "you have to do many things to properly execute a program", because this is a facility provided by the environment.
HTML has its place. Where the application is for use on the internet by people who do not have complex requirements from your software. But please don't make us re-write all our pretty thick clients just for a marketing whim (Damn - too late). -- Reg Whitton
Agreed. I'm not necessarily arguing with your claims, just reiterating that these problems vary from one project/implementation/platform to the next, so making such a broad statement as "Using HTML puts constraints on usability" can be misleading. It does work fine for certain types of applications, but I would not use it for an Air Traffic Control situation -- even though that's exactly what they made us do in "Advanced Comm-Computer Programmer" school... :( Yay Air Force. Thankfully the people that really build those things know better. :) -- DaveCantrell
XWT is something of a middle ground. Quoting from its web page: "XWT is the XML Windowing Toolkit. It lets you write remote applications - applications that run on a server, yet can "project" their user interface onto any computer, anywhere on the Internet.". I haven't used it personally just yet, but I'm seriously evaluating doing so. Find out more from its site: http://www.xwt.org/.
Now about Sparta -
The recent dot-com show proved that the cluttered, feature rich interface is not a good idea - that it doesn't help users at all but, on the contrary, tends to confuse them. Good interface design means to know what the user has to do at every point in the navigation tree, and to provide just that and only that.
Now some ideas for spartan interfaces, mainly for business systems -
The UserInterface can be regarded as a contract, being it's parts the program and the user. Each new clause, worse if in small print, means a possible source of conflict, so the shorter the better. It's the developer's work to make the program comply with what the contract states. For example, a text box and its related label: the label must *always* be located to the left, or *always* over the text box. Changing the relative locations will make the user stop and evaluate instead of acting intuitively, and this will give them a chance to make mistakes. When the focus enters a text box its contents are always selected, or never selected, so the user can be confident.
I've developed several applications without those Windows drop-down menus (using VB). It works fine. There is only one menu program which shows initially and has a list of the available tasks. The tasks are implemented as a stack of modal forms. In each form the user has (almost always) two options: "OK" and "return". It works fine, the users get used to the applications very fast and they make very few errors.
About double click:
For a lot of people it's difficult to double-click the mouse. It requires some practice and muscle coordination that not everybody has. Think of older people. In my interfaces, I avoid it completely.
Juan Lanus firstname.lastname@example.org
See GuiGuidelines for more user-interface principles.
Let me just add that creating a beautiful GUI in Java is one pain... Spartan Gui's are easy, but once you have to get the different items nicely lined up with some nice openspace in between.... That's one of the most painful things to do in Java; their LayoutManagers suck.
GraphicalUserInterfaces are complex by nature. Where a C++ system library might have an Integer type, a GUI library has TextBox?, Label, Title, EntryBox?, Combobox, RadioButton?, CheckButton?, Button, Icon, EnterWindow?, LeaveWindow?, KeyPress?, ButtonPress?, SpinButton?, Menubutton, MenuPopup?, and ScrollBar? - all with their own distinct semantics, syntactic knobs, and synchronized distributed behaviors, but all might end up being used to set or report the value of a plain old Integer. Oh, and I forgot to mention LayoutManagers... -- ZygoBlaxell
There is a US Patent (reference please?) which spends three whole pages explaining in excruciating detail how to draw a histogram on a computer screen (to give you an idea of the level of detail, the description covered everything from the arrangement of bit values in memory to magnetic fields and electron beam currents, and used color lookup table-driven frame buffer devices as an example, and did so with precise legal definitions of all of the technical terms used). Suddenly, in the last paragraph of the background of the invention, the patent mentions "a horizontal scroll bar" with absolutely no definition or explanation, as if 'horizontal scroll bar" had some well-known legal meaning while 'computer monitor' or 'application window' or 'bitmap' didn't. Never mind that the details of making a horizontal scroll bar work the way a human user expects it to work in most real systems are thousands of times more complex than a simple bitmap display. Scrollbar implementations in generic UI frameworks involve asynchronous message passing between several architectural components that execute concurrently. If a CRT can be described in 3 pages, a scrollbar needs at least 30.
This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006