Spartan User Interface
Spartan User InterfaceI don't know what kind of UserInterfaces they had in Sparta. Short swords, I think. Right to the point.
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
This would work well when you are designing an interface for a few, internal users who understand their domain. Or it works well in the early stages of a project to flesh out how a subset of users see their task.
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's are not easy, except in Visual Basic. That's because Visual Basic is specifically designed to make GUI layout easy.
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.)
Prototype GUIs are easy. While I find Tk widgets excruciating as a user, I still enjoy working with the the Python TkInter? because the widgets are very quick to arrange - using the "Pack" layout system you can even figure out resizing automatically. Still, for final product I wouldn't touch it. Same with VB - yes, it will take a lot of work to complete the polish on your GUI, but the basic layout and user issues can be found with a skeleton.
It sounds more like the SpartanUserInterface are meant to be fairly ugly, quick, GUIs, not something that is pretty (and thus not requiring a huge effort to create). Also, it's infinitely better that your UI actually do what your customer wants than having it look pretty (except when trying to sell it!).
With VB5/6, good GUI's *are* easy; they can also be fast and robust as long as you are staying within the bounds of MS-Windows standard look-feel. This is not the place for GUI creation tool discussions though.
SpartanUserInterface are fine if you are operating in a nonpolitical environment, however most developers are not. Typically software is developed in house for in-house uses. There are very many reasons why projects can be canceled, and very many people who want to cancel them so that they can get the budget to do what they want. Even absolutely business critical projects are vulnerable.
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.
Using HTML implies support and testing for multiple web browsers and their multiple incompatible JavaScript/HTML/DHTML implementations. (The managerial belief that web browsers are all compatible and give zero-installation benefits drives this.)
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.
Use JavaScript to validate form controls as the user leaves them, or as they focus on another section of a form.
Never use JavaScript. Echo back a misfilled form with clear explanation of what is wrong. Actually, this is often more user friendly than validating on the fly, because the user can fill the form in peace and then correct the errors in one batch.
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/.
A good non-thick HTML interface is a thing of Spartan beauty. The point of an HTML app is missed above "Getting a whole page at a time makes it difficult to check...". HTML is a major paradigm shift. There are certain things a user will put up with in a Web browser they are unwilling to accept in a thick GUI. It seems every GUI project I've ever worked on, people tried to cram as much as possible on the screen at one time - everybody wants to leave an imprint. Leave JavaScript out, just stick with very basic HTML. It's beautiful not having to check the keyboard and trap a gazillion different events. That being said, I would also say, never start a Web App project from scratch. Always use an existing base framework that manages sessions. ... Kimball C. Sampson 3/28/01 (Contract Developer at Discovery Channel).
- Update - 12/17/07 by Kimball. Well, now I'm very pro Javascript (for the past few years). Not so much to create complex user interfaces, but, more for Ajax calls. Times have definitely changed.
First, some comments- "... users don't know what they want": They *yes* know WHAT they want. What they don't know is HOW they want it. It's our job as IT professionals to interpret their needs and to develop the interface that will let them do what they need. "GUIs are easy - you can even do them in Visual Basic": It's not a matter of language. Along many years of software development, I've seen good and bad things done with every available tool.
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 -
Be regular:
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.
About menus:
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 jlanus@interar.c0m.ar
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.
See also: PettinessWillKillYou, NakedObjects
EditText of this page
(last edited December 17, 2007)
or FindPage with title or text search