Proposed update to Growl notification system

October 5, 2007

There’re several things in Growl notification display behavior that I think might be improved.

First of all, it’s a new “close” button implemented in version 1.1. It only appears when you hover a notification and lets you close the message you see no need to react on. Not even mentioning a degraded look of notifications (tastes differ) the button has a serious disadvantage as it requires quite precise positioning that eliminates the advantage. So what? Easily: just recall the Fitt’s law and let one click a larger area like the whole message… By assigning the right click to this action you let the thing be done without extra complexities. Is “right-click to close” an obvious action? No. Just like any idiom it has to be learned, but once learned it may become very handy. Arguments for are that some applications like QIP (Windows) or Google Notifier (OS X) already use the same approach successfully and both have very large user bases.

The second thing is the way Growl displays notification pool. Right now the mechanism is quite primitive, so when there’re just too many messages they may take all the screen space available thus interrupting you from work. Having a dedicated area for displays might improve situation a lot. I.e. let’s say messages can only take a single row with a maximum height of 50% of screen height. Now you may be sure that no matter what happens messages would not cover your workspace if you have it outside a suggested area. Besides, now we know that if notifications come from top-right they bottommost message is always the latest one.

Once again, this approach is already adopted by other applications.

The third improvement would work great with the second one. As we have limited our screen space, let’s make notifications use space more effectively. Now, when one of displayed messages disappear, the “hole” is covered by shifting other notifications, thus making sure the order remains intact and no message would “accidently” get into the hole. As a picture is worth a million words, here’s (270 Kb) a Keynote demo of suggested behavior and QuickTime (2 Mb) version of it for those who doesn’t have the latest iWork. The idea is also not new and is used in applications like Google Talk.

Advertisements

GUI prototyping for OS X: makeing life easier

October 5, 2007

Just for ones who are interested I provide a link to my OS X GUI design stencil I use for my own prototypes. It’s currently work in progress and still retain large portions of WireframeShapesAngles it’s based on (make sure to check the original, it’s pretty useful by itself). Future versions should have more controls, dialogs and other ready to use stuff, but if you’d liked to finish the work, feel free to do so.
stencil preview

So, here’s a link. Download and enjoy, it’s less than 100Kb anyway 😀


Expose 2: improving tab switching logic

September 8, 2007

While working in Mac OS X I got used to Expose feature for rapid window switching. I love it a lot, except for one thing: it simply cannot help if you use tabbed applications. OK, you may switch to the app window and then click a tab you need, but why not saving clicks while being able to review all tabs’ content during switching? Shiira tries to solve the problem by implementing a kind of Expose for its own windows which partly solves the problem.

My suggestion is wider: why not change the Expose itself?
(I know, Apple would doubtly ever do this, but we have Expose-like features in Linux Fusion)

proposed Expose 2

As you may see on the picture, in Expose mode each tabbed app is represented by a tab grid, so you may switch to a certain tab (not just the app!) in a single click. When the numberof tabs is not too large, this feature should work without any problems.

This way we eliminate confusion when user cannot see a page he knows has just been opened in Expose mode just because it hides by the main application’s window.

Related document (PDF, 50 Kb)


Vista, the next “Millenium”?

July 15, 2007

Last week I had a chance to make a test drive of Microsoft’s latest effort in Desktop OS development, Windows Vista. Actually, after reading numerous reviews and/or previews I had a mixed feeling about a need to look at it at all, but my designer’s curiosity has won. So, in short, what do we get on upgrading?

Pros:

  • Vista Aero UI is pretty. Really pretty. Just as much as some people love Wincustomize stuff they would love Aero, especially its clean skin and small details like Window header blur or “file flare” animation on copy.
  • Explorer is redesigned for good. Breadcrumb control (previously actively used by GNOME Nautilus) makes navigation more efficient and file thumbnails are more useful than before.
  • Aero UI has finally got rid of this nasty “GUI art” (redraw problems) and thus looks a bit more pleasant.
  • Gadgets and Desktop search are nice addons to old XP Desktop.

Cons:

  • It’s damned slow! On a modern PC with an excellent video card, modern processor and 2 Gb of RAM it’s visibly slower than XP. The difference is subtle at first, but the more you work, the more you notice annoying control delays. Besides, “eating” half a gigabyte of RAMjust after start…
  • Aero is annoying. In a few hours “wow” effects stops and you understand all its ugliness. All this sexy animation, stripes and highlight is very impractical and non-functional. The difference between active and background windows merely exists, soaped backgrounds make you mad, rolodex view is merely usable and taskbar hints are sometimes lost. You may return to the simplified non-transparent version of UI, but it’s times less eye candy and just ugly. Even with hardware acceleration minor graphical quirks exist, like windows, slowly restoring its content after minimizing…
  • The new UI is very inconsistent. You’ll have to learn things anew and controls seem to be located in the most bizzare places…

Overall, it’s disappointing. After 5 years of development we come up with a merely usable product (software, unwilling to operate properly, “are you sure?” anti-user protection on each step, slow operation…) with very arguable advantages over XP. Do you really want Vista? Try Mac or Linux first… Seriously. Macs had most of this stuff in Tiger for years and they’re more functional. Linux offers a competing Desktop with a much less price. And what about Vista, I’m not even sure Microsoft would be able to fix all the quirks with its service packs, so we may probably have to wait for the upcoming Windows 2009 or whatever it delivers next.


Close me not: Camino usability glitch

July 2, 2007

Even though I do like Camino browser a lot it has a glitch sometimes making me mad.

Just like Firefox, Opera and any other modern Web browser it uses Tabbed UI for navigating page sets. That’s generally OK (I wouldn’t discuss tab-related problem here, besides many users get used to this style of working).

Camino tabs

So, what’s wrong with the picture above?

First of all, the “close” button on each tab is located on the left, just like it is on any Aqua window. Nothing special, actually, especially as it’s quite an expected behavior and Safari (OS X bundled browser) does exactly the same:

Safari tab

The problem comes when you try to do something with tabs. One of possible features includes easy bookmarking by using drag’n’drop technique, familiar to any modern OS user and widely popular on OS X:

drag and drop

The thing is that in order to bookmark the site you must drag it by the site’s icon. Ooops. What happened? You just clicked “close” instead of bookmarking?

The cause of the problem is simple: Camino developers have just placed destructive (close) and non-destructive (site favicon) controls too close to each other. Strange enough, as this principle is largely covered by Apple HIG.

So, what possible solutions might be?

The first and non-elegant one is placing “close” on the right part of the tab (Windows way). Non-consistent, not “Aqua”, but it works. At least, Opera and Firefox find no problems doing so:

Opera tabs

A kind of “who cares?” solution.

Another one might be a bit more elegant. It doesn’t solve the problem completely, but creates a good workaround: just instead of using favicons for drag’n’ drop operations Camino developers might have made the whole tab draggable, so users may avoid dragging tabs by favicons in favor of other, less “dangerous” areas.

Edit: submitted as bug 386574.


Smart grid control idea

June 20, 2007

Enough talking of fruit operating systems: there’re some other interesting things to discuss.

A couple of years ago, when working on some applications’ UI I’ve found out that existing grid controls utilize space very ineffectively. In fact, they waste it: even if there’s enough space to display all needful data, user must manually adjust columns’ width each time:

iTunes grid

Annoying? For me, it is.

So, in order to solve the above problem, I tried to describe a rough draft of  the new control’s logic.

As a result I’ve got the following document: Smart Grid Control mock-up (PDF, 200kb).

To my shame, this document has never been finished and so far I know no implementation of similar logic in real life. So, if you have any interest in this work, pick it up and feel free to share your ideas.


Hall of shame: File moving progress dialog in OS X

May 17, 2007

Copying or moving?

Copymove

“copymove” dialog from OS X (moving file in Finder)

OK, I’m moving the file. But why does the window header tell me about copying?