« June 2003 | Main | August 2003 »

July 2003 Archives

July 1, 2003

Apple UI Requirements: Apart from the Crowd (Again)

The long list of appleisms in the Aqua UI go on and on. apple seems to pride itself with these quirks but when they are subtle they can lead to user confusion. The subject of today's abuse is the ellipses in menu items.

What? There are ellipses in menu items? You mean just randomly? No, ther actually is are very intentional time they are added to the end of menu items. Genearally they are used when selecting the command from the menu alone won't finish the command. Go ahead and look at the File menu of the browser you are in. Close and Work Offline are commands that just suddenly work. Save As and Open do have the ellipses because you need to enter the name of a file or page to finish it.

But let's say you had an item on the menu "Crash Browser" (in Netscape 2.0 this was accomplished with complex javascripts). As a good UI since the command has potentially sever effects dialog pops up asking "Crash Browser: Are You Sure?" So should this menu command have ellipses? On Gnome, Java, KDE, and Windows, yes. On MacOSX, no.

Label the menu item with a trailing ellipsis ("...") only if the command requires further input from the user before it can be performed. Do not add an ellipsis to items that only present a confirmation dialog (such as Delete), or that do not require further input (such as Properties, Preferences or About). [ GNOME Human Interface Guidelines ]
Ellipses (...) are punctuation marks that indicate the omission of one or more words that must be supplied in order to make a construction complete. In your menus, you can use ellipses in a similar way: to indicate that the command issued by a menu item needs more specification in order to make it complete.
  • If a menu item does not fully specify a command and users need a dialog box to finish the specification, use an ellipsis after the menu item. For example, after choosing Save As..., users are presented with a file chooser to specify a file name and location.
  • Do not use an ellipsis mark simply to indicate that a secondary or utility window will appear. For example, choosing Preferences displays a dialog box; because that display is the entire effect of the command, however, Preferences is not followed by an ellipsis.
[Java Look and Feel Design Guidelines]
Notice that every item in a menu that first opens a dialog requiring additional information must be labelled with a trailing ellipsis (...) (e.g. Save As..., Open...). There's no space between the menu item and the "...". A simple confirmation dialog is not considered a dialog that requires additional information. [KDE Standards]
However, not every command that results in the display of a window should include an ellipsis. Do not include an ellipsis for commands that simply display a window or view or change the existing view within a window. Similarly, do not use ellipses for commands that display a collection of objects or options, unless the intended action requires that the user select or confirm the selection of one or more elements of the collection. Also, do not include an ellipsis for commands that may result in a confirming message box. [Microsoft Windows User Experience]

Java comes the closest to no explicitly prohibiting it, but it is a very long stretch to say that a confirmation dialog is "more specification." And What about Aqua?

An ellipsis character (…) after a menu item or button label indicates to the user that additional information is required to complete a command. You should use an ellipsis in the following cases:
  • An action that requires further user input to complete or presents an alert allowing the user to cancel the action. Examples include Find, Go To, Open, Page Setup, and Print.
  • An action that opens a settings window. The main function of settings windows is to allow the user to change some aspect of the application, not the document content. Examples include Set Title, Preferences, and Options.

A very long wided debate can be had about where ellipses means "not done yet" vs. "window coming" (and I am sure at some point they had one or more of those in Cupertino), and if someone was determined to make their app behave properly on Apple they might consider changing the text when an Apple platform is detected. But that's just too much effort for a subtle cue that most users probobly miss anyway.

July 3, 2003

Do Your Homework! (UI Standards)

Anyone remeber the (sometimes contentious) debates on software teams about coding conventions? Tabs vs. spaces, two space vs. four space vs. eight space indents, curly braces on same line vs. a new line, braces for all control structures vs. only where explicitly needed. You could probobly go on and on about what the little nits are in formatting your code. That's why coding conventions were invented; Apache, Sun, and GNU are just a few of the conventions that come to mind.

But if people get up-tight over stuff the end user dosen't see you'de think there would be a lot of demagauging going on in larger organizations where the UI is a seperate team entirely separate from the core of the applications. Well, there isn't as much mostly because codified standards do exist in what the user should see and how they should interact. Most of these standards deal with low level controls and widgets, but do address higher level concerns. Here are a few that I have found on the web.

Of course none of the ones I've found (or for that matter looked for) deal with web page design. That may be a bias on my part that web pages should be content and not a full featured applicaiton. But the idioms and patterns for interacting with and developing a page at a time system are quite different than a "rich" applicaiton.

Another thing I've found interesting is the widly varying level of depth that each standard goes into. For example the Microsoft standard (and to a lesser extent the Java standards) goes into pixel level counting and positioning, while others merely make mention of the screen size and don't address pixel level positioning. They all do have some basic overall usability principals that drive the desicions that are addressed before they get in to the sometimes arbitrary rules. And they all (at least now) say Multiple Document Interface (MDI) bad, Single Document Interface (SDI) good (although Microsoft's take is "MDI bad, but if you're doing it here's how it's done").

Of course the down side of following a standard is that when using one to justify design decisions you are bound to pretty much the whole standard. You cannot just bring up standards when it helps your decisions but ignore it when you disagree with it.

July 7, 2003

How Would You Like Your Three Panes?

Diego is considering going to a different three pane layot for the next release of Clever Cactus (a java based PIM/Mail application). The old school of three paned navigation was useherd in by Netscape Communicator's e-mail program, and Outlook and Outlook Express lead the charge. It is now such a common idiom that almost all off-line rss aggrigators use the old school three pane navigation of channels on left, news item summary on the top right, and the full news items on the bottom left. The new trend seems to be to left middle right three panes. FeedDeamon defaults to three column, and the betas of Outlook from the new Office Betas start out in three column view. Diego is considering going that rout for Clever Cactus and has spent Another weblog entry hashing over more of the detals. However I am of the opinion that three column navigation won't fly. Why?

The most importiant issue in my eye is the issue of the center point. Like a fine piece of art, the content in a gui window should draw our eye to the most relevent or used area. The middle (actual middle or precieved middle) of the window should contain the most used window in the applicaiton. In the three column layout that is going to be the level 2 navigation, not the content pane that is going to be banished to the right side of the pane. Which for western readers the right side is the side most likely to be ignored. (Theater and broadway musicals use this fact to great effect). But there are other areas where we are trained to focus on the middle column of a three column layout. Look at most weblogs out there, most either put perifiery information to the left or the right of the main entry, and some put the info on both the left and the right, even Diego's own weblog uses three columns and places the most relevent content in the middle. Most (all?) modern software IDEs follow this ideal as well: the main editing pane tends to be in the middle while all of the auxiluary informational panes are scattered around the left, right, bottom, and top. It's BorderLayout to the extreme.

Another issue is that a usable three column layout requres a lot of horizontal real estate. We don't all have 16:9 apple cinema layouts so we have to deal with the 4:3 layout of most monitors. And not veryone likes to run every application maximized. About the only application I maximize is NetBeans, and that is because there is usually a lot of non-linier information I need accessible at once. Everything tends to take up about half to three quarters of the horizontal space with the widest content pane taking up about a half of the real sceen space. All the windows also take up 75% to 90% of the vertical space. By adding more horizontal exclusive space it requries me to widen my window.

It also adds more un-needed information to the window. I don't need to see all 30 options on the second level of navication, I am almost exclusively intereted in the top few from that stack. And the few time I do need that space in outlook (usually when I am seraching manually) I tend to make the preview pane much shorter. But as long as the current item is focused in the level 2 navigation I can minimize the needed space to use that level.

Finally it's been tried before. NeXT tried it first and moved it to early builds of the Aqua interfaces and there moans and moans of how hard it was to use. Part of it may have been resistance to new stuff in the new MacOS but if you look at all of the other UIs apple has done since basically none of them do what the NeXT finder did. Russ posted a bunch of GUI links to modern mac applications put out by apple and none of them do a three column layout left to right. All of the main content panes are large and take up the center point. In places where this represents a third level of navigation either the first pane is not shown or it is done where the panes are top left, bottom left, and center-right.

If any new direction in Clever Cactus should be taken perhaps it should be the TL-BL-CR format, with multi-line rows (like quicken or palm's versa mail) containing the second level navigation items. Three column just dosen't float my boat.

July 8, 2003

Interface Modes, Fitt's Law, and the Menu Bar

I've been reading Jef Raskin's book The Humane Interface and he has a big section about how modeless interfaces are a goal yet a few chapters later he discusses Fitt's Law and is ravings and how wonderful the Macintosh menu bar is WRT ease of use with a mouse. The problem is that while being an glowing example of Fitt's law the menu bar violates modelessness.

First let's address Fitt's law. Fitt's law says that the expected time to perform a gesture is directly proportional to the distance traveled by the cursor and inversley proportional to the size of the target area. A big button close is quicker to click then a small button far away. The arguement goes that since the menu is at the edge of the screen the vertical dimensions of the menu items are essentially infinite and thus easier to move the cursor to the menu from a greater distance. Once you become familiar with the interface you don't look at the menu as much as you just remeber how to move the mouse to get there quickly.

The issue of modality however is can be technically argued away in Jef's two part definition of modes. The second part essentially requires that the same gesture does two different thing at two different times for the interface to be modal. In this case clicking at 100, 0 (or thereabouts) bringing up the Foo menu. Where the entire Macintosh UI creates one huge mode shift is in the treatment of the menu bar. Depending on the application whose window you have focused (or just closed) the menu bar is the menu bar for that application. So the menu at 100, 0 could be wildly different between applcation. A team Jef was on was once so obsessed with removing a mode from a computer that they even designed a computer without a power button! (Engineering was convinced it was an error in the spewcification and put a power switch on anyway.)

But then there is the second part of the modality definition that starts to break down this paradox: "the current state of the interface is not the user's locus of attention." If you are selecting a menu clearly the locus of attention should be the menu. Also the window you are looking at should be a locus of attention just before the menu item is selected.

But let's go back to how you interact with th system once yoar familiar with it. It's the ability to go to a menu item from "memory" that indicates the fact the locus of attention is not the menu bar. It's this interaction that makes the menu bar modal. It's not a non-recoverable error either, because no commands are really supposed to be invoked from a single click of the menu bar the user will have to focus attention on the drop down menu. So before any command occurs the user will realize that the menu bar was in a different mode.

It seems then that the bashing other windowing systems get for attaching the menu to the window is only half deserved, since by being less efficent with Fitt's law they are less likely to be subject to accidental user mode-based mis-gestures. Fitt's law may allow the menu to be brought up faster, but that is at the risk of modal user-errors.

July 10, 2003

SWT: I Still Don't Get It

The lone programmer blogged about my old entry on SWT claims referring to it as a "short critique." I think he was being kind, it was a rant all the way. But his entry reminded me of the old saying "If all you have is a screwdriver everything looks like a screw."

I find it kind of funny that he almost admits that SWT sucks on GTK and Mac OS right now. And then he continues to defend the native widgets of SWT by saying it grants "consistency between the apps on a particular platform." News flash: SWT widgets are normalized across platforms just like swing widgets are. And swing provides the same native client look. Have you seen the new XP look and feel in JDK 1.4.2? It looks just like windows themes, and it even keeps up with arbitrary changes. Why? It gets it's UI painting resources from the native OS DLLs. That's one big reason you won't see it do XP on Win2K, the theme information Java needs isn't in Win2K. With SWT you do get native widgets, complete with slow table re-draws.

But this brings me back to my screwdriver argument. If you want native cool thingies like Mac OS dock integration, sliding accessory windows, windows notificaitons, balloon help, Linux GNOME panel integration, etc. etc. Use the right language! (or at the very least the right APIs). You want all those slick dock integration APIs? Use Objectve C and the Coca APIs. You want Gnome panel integration? Use the Gnome APIs in their particualr language (C, Python, Perl, or Java-GNOME) . You want neeto-skeeto integration with Longhorn? Use C# (but that may make you part of the problem). Just because it can be approximated in Java dosen't mean that you have to use Java! Use the right language for the task. If platform specific features are essential to the user experience use the tools designed to deliver that integration.

Jeez, it seems that Java is a religion. I just hope that they don't start refering to people at java conferences as "the faithful."

July 15, 2003

Moving Tip: Hire Professionals

James Duncan Davidson is moving very soon and has come to the same conclusion that my wife and I did when we moved int our house a couple of years ago: Hire Professional Movers. It's not just a cost effective money thing. You'll be tired enough from packing and unpacking your stuff and by the time you pay the movers you will find it is money well spent. Especially because when you get friends or family to help, you owe them and get to help them move as well.

July 16, 2003

Straw Man, SOAPy Water

Here we have a piece of RDF advocacy masquerading as a SOAP RPC vs. Document Encoding article. The problem is that once you get past the first section the arguments the author uses supports in no way the contention made in the opening setction, they are in fact blasting some unrelated topic that he has vaugle associated witht he original contention.

This is a common argumentation fallicy referred to as a "Straw Man Arguement." The layman's definition is that the arguer brings in some unrelated issue (the straw man) and proceeds to destroy it, and then claim that he was actually destroying the original argument, while actually not addressing the issue in any tangible fashion.

Here's the essential summary of the technical porton of the article: "Using RDF is more descriptive than a real bad tree encoding stored in a hash table." A slightly longer version is "Using RDF (let's demonstrate this with a document encoding) is more descriptive than a real bad tree encoding stored in a hash table (let's use RPC encoding for this example)." The issue of SOAP binding encoding has absolutely nothing to do with the real philosphical issue at hand, and instead he is beating the RDF drum. His "perfect" RDF example could just as easily been done with the <soap:binding style="RPC" ... > . But that would have ruined his groove, so he ignores that fact.

Despite the misplaced direction there are some good practices that we can draw from this example. Fist, use the WSDL file as the master definition. In the first example he uses a .jws to deploy the first web service, which is quick and dirty, with an emphasis on the dirty. Despite how hard you try you cannot separate the quick from the dirty using .jws files. By using a WSDL as the master in the second he has also increased the interoperability of the entire system since leaky abstractioins from Java to WSDL won't get translated into any third language, with second level abstracton leaks. With the WSDL as the master each client has to only map the WSDL issues and not inherit old Java issues.

Second: some data structures jus plain old suck. Anything is better than the encoded mess that is the hashtable/tuple mapping with encoded data. Not to mention that using a tree path as a string is so LDAP. Even RDF was better than the first example (it wasn't that hard).

Third: If you have data format already in XML Schema, just go ahead and use it in the WSDL. You don't need to re-invent the wheel if you already have your data format. If you want to use RDF as your message parts in a WSDL call go for it! This issue is totally unrelated to whether the client should consider this an RPC or document/literal call (which they can freely ignore if they choose).

Lots of good issues in that article, but it fell prey to the trendy RPC vs. document debate in the SOAP community while having nothing to do with it. And why the blind allegence to document, is he applying for a job at Microsoft?

July 22, 2003

I is for Integrated

One of the principal features if an IDE is the Integrated part. What it takes to be integrated has gone up from the days of the first IDEs. The way it used to be was you had the compiler and the editor running from the same binary and that was what constituted integrated. Slowly the IDE became more and more integrated. Features like next compiler error and code context highlighting brought the editing and the compiling closer together. Now the bar for integrated is high, and if you know how to use the environment it can speed up your coding time. While it's true that if you don't know how to use the environment that it can slow you down there are some capabilites that could not exist without wich integration.

Lets take NetBeans for an example, and three rather un-related tasks: Source Control, Internationalization, and GUI design. The IDE intrgrates these three facets without making you switch to three differnt applicaitons or even three different panes in the IDE. First I open up the GUI designer and I add some components. However, I cannot just hard code some of the label names in since we plan on selling it outside the US (one of the few places you can get away with monolingualism, and that too is changing). So I click on the label I want to internationalize, and I bring up the property editor for the "text" property. I select a drop down box tha says I want to get the value to be internationalized. Now I am doing some rather common Java I18N tasks: I need to identify the resource bundle I will get the text values from and select the key. I can either create a new bundle or select an existing bundle in my code base. For the keys I can select from one of the existing keys or create a new one as well. The value of the key in the current language is also displayed to me so if I don't unerstand the key name I can select an appropriate key based on it's value. I can even add a new key and it will be added to the bundle for me. Resource selected, key selected, time to press OK. Here's where the source control comes in. If I've selected an existing resource bundle and I've either added or chagned a key NetBeans will save the changes. But if the resource bundle is in source control and is read only NetBeans will also ask me if I want to open it for edit in the source control. All this without me having to navigate pop-up menus and I am prompted only when I need it. When all this is solved and I am back in the GUI designer, the label I just internationalized has the value from the resource bundle shown right in the designer!

Source Control, Inernationalization, and GUI design, all dealt with in the same application in a logically connected fashion. And when you are done no visible warts are sticking out at you. Without these tools the work would have taken me mutliples of time longer because I would have to switch in and out of three seperate programs and mental contexts, where instead the IDE deals with the warts for me and only brings these issue to my attention when being dealt with.

A truly integrated experience is very seductive indeed.

July 24, 2003

another test

this is another test

July 31, 2003

Open Position at My Employer

My employer will soon have an opeing for someone with general J2EE skills (no it's not my position.... sheesh!). The typical J2EE stuff like EJB, XML, Web Services, Servlets, and JMS are what we are looking for (although you don't need all of them at once). Additional skills that are nice to have are Ant, JUnit, Perforce, WebLogic, and WebSphere. Don't forget the gems like "Works Independently," "Is a Good Team Player," and... I'm starting to get hives so I better stop. Also if you are familiar with networking stuff like switches and routers that is a big plus, but don't sweat it if you don't have it. I barely know that acronymns like MPLS, BGP, and IGRP vaugeley relate to routers and I'm doing fine.

The position is in downtown Colorado Springs, CO and AFAIK there is no relocation expenses. You could post your resume on our web-form but because of a couple of recente articles (one in the Denver Post and one in the Colorado Springs Gazette) there's a lot of unsolicitied resumes floating through that account for every position imaginable. A better approach would be to e-mail me at danno.ferrin@intelliden.com.

The person doing the hireing for this position also wants me to keep an eye out for "opportunistic hires" with testing and/or systems integrations skills. "Opportunistic Hires" means we don't have a req for it but having a very good candidate makes it easier to go get one. So smoke 'em if you got 'em!

About July 2003

This page contains all entries posted to ... And They Shall Know Me By My Speling Errors in July 2003. They are listed from oldest to newest.

June 2003 is the previous archive.

August 2003 is the next archive.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.33