This is a post about tooltips - those little labels which typically appear after a short while if you leave the mouse pointer over a UI element.
I need to check my facts but I'm pretty sure tooltips appeared with Windows 95 and, while Microsoft have many good ideas, they don't tend to take sensible UI design into account. This is probably why the Close gadget in a Windows window has a "Close" tooltip.
I'm a big fan of consistency when it comes to UI design but I don't believe consistency equates to replicating the same thing everywhere: you should apply sensible logic.
Tooltips are great but I think they should be bounded by visual clues so a UI element with a label that doesn't fit within the bounds of the element might read "Washin...". It's therefore sensible to assume that moving the mouse pointer over it would result in a tooltip containing "Washington DC", but why should moving the mouse pointer over a button containing the word "Cancel" require a tooltip that says "Cancel"? This is over-use of a feature and therefore dilutes its effectiveness in my book.
So, tooltips where strings are truncated are a good thing, but what about the traditional home of tooltips - label-less toolbars? Well, ideally, the icon should convey enough information to make a tooltip unnecessary but that's not always possible given the restricted amount of space a toolbar button usually has to play in. One solution to this might be to borrow from newer iOS apps and have an overlay display when a certain key is pressed.
Many iOS applications have, as part of their tutorial system, an option that overlays a graphic which shows what each UI part does, or is for. Back in Amiga days there was an actual "Help" button on the keyboard but evolution (IBM) did away with that. Traditionally, however F1 is used to provide "help" nowadays (the quotes are deliberate).
I would personally love it if tapping F1 would generate an overlay over the current active window showing what does what. This, to me, is the happy medium behind introducing a new user to functionality and not distracting a well-versed user with semi-random tooltip comings and goings.
Sunday, 24 February 2013
Tuesday, 12 February 2013
Monday, 24 December 2012
New Notification Model
The next major release of Snarl (after 3.0) will feature a completely revamped way of assigning styles to notifications.
The current model takes all the applications that have registered with Snarl and allows styles and redirects to be assigned to each class the application has added. This is perfectly good but as the list of applications grows, it's not the most effective way of customising Snarl, especially when research has shown that, generally, the most common use of Snarl is to set a standard style for 80% of classes, and then customise the other 20%.
The new model uses the
"when (stuff happens): (tell me)"
approach so, instead of simply assigning styles to classes, the user creates rules which define the event (stuff happens) and the style or redirect to apply (tell me).
Under the new model, there will be one rule by default:
When "anything happens" tell me "using default style"
You can then add rules to Snarl, for example:
When "SysInfo" says "memory exhausted" tell me "using prowl"
You can add more than one rule for the same class so you can have memory exhausted notifications sent to the screen and to Prowl, for example. You can edit or even delete the default rule if you want to take an exclusive rather than inclusive approach.
Rules can also be configured to only apply when you're away or busy, and advanced features such as not displaying the notification when the app is foreground will still be retained.
Other features such as prevent further rule processing are being considered but are further down the line.
The current model takes all the applications that have registered with Snarl and allows styles and redirects to be assigned to each class the application has added. This is perfectly good but as the list of applications grows, it's not the most effective way of customising Snarl, especially when research has shown that, generally, the most common use of Snarl is to set a standard style for 80% of classes, and then customise the other 20%.
The new model uses the
"when (stuff happens): (tell me)"
approach so, instead of simply assigning styles to classes, the user creates rules which define the event (stuff happens) and the style or redirect to apply (tell me).
Under the new model, there will be one rule by default:
When "anything happens" tell me "using default style"
You can then add rules to Snarl, for example:
When "SysInfo" says "memory exhausted" tell me "using prowl"
You can add more than one rule for the same class so you can have memory exhausted notifications sent to the screen and to Prowl, for example. You can edit or even delete the default rule if you want to take an exclusive rather than inclusive approach.
Rules can also be configured to only apply when you're away or busy, and advanced features such as not displaying the notification when the app is foreground will still be retained.
Other features such as prevent further rule processing are being considered but are further down the line.
Sunday, 2 September 2012
Nostalgia
Recently I've been pulling together some screenshots of early versions of Snarl, the current results of this can be seen in the Screenshots page.
Alongside this, I've also pulled together details of the releases of Snarl over time, including information about Betas, Alphas and the very beginning of Snarl. You can find the list here.
Alongside this, I've also pulled together details of the releases of Snarl over time, including information about Betas, Alphas and the very beginning of Snarl. You can find the list here.
Monday, 27 August 2012
Saturday, 25 August 2012
Subscribe to:
Posts (Atom)