Aza Raskin released a new project today called Algorithm Ink. For the full story check out his explanation and video. The app is basically a “grown up version of Logo”—a front-end to a simple programming language for creating fractal images. While the fractal art is the main attraction, I was more interested in the unconventional UI.
Algorithm Ink continues the style that Aza demonstrated six months ago with Songza. His UI comes from another planet where Microsoft Windows never caught on and Hypercard rules the world. There are no native form widgets, no scroll bars, and nary a “ or Cancel” in sight. Normally this is a recipe for confusion, but in Aza’s case the results are often models of clarity and intentionality.
On Songza, the most noticable break from convention was the mouse-flower. Traditionally, a web UI for playing a song would consist of the song’s title, a widget to play/pause, and some adjacent links to share, rate, etc. Instead Songza only shows the song title. When you click the title, a flower opens with an action on each petal like “Play” or “Share.” You can click a petal or mouse away from the flower to dissolve it. The jury’s still out on mouse-flowers, but the clutter-free UI they enabled should raise an eyebrow.
On Algorithm Ink, the header is what interested me. Each of the grey buttons (Edit, Save, Browse, etc.) is actually a toggle between an “on” state and an “off” state. When a button is “on”, a panel appears on top of the canvas with the functionality for that button.
The grey buttons toggle overlaying panels
For example, when you click “Edit”, the button turns on and a panel is revealed with the code for the current artwork. You don’t “Save” or “Cancel” to leave edit mode. Instead you click the red “Draw” button to apply your changes, or click Edit again to hide the panel.
The Edit button is on and the panel is visible
Each of the buttons has its own custom panel. Edit displays a long narrow sidebar, while Save displays a thin horizontal strip. It’s note-worthy when different features of an app actually look different. We’re all guilty of leaning on our templates to the point that each screen in our apps looks a bit like the others. In Algorthim Ink, the Edit mode is tall and narrow. The Save mode is wide and thin. These differences give the app character and also help users develop a kind of “muscle memory.” They can remember the screens by shape as much as by name.
The Save button is on and the panel is visible
My favorite thing about these grey buttons is that they don’t just turn panels on and off. They also exclude each other, so that if you are using the Edit mode and you click the Save button, the Edit panel will disappear and the Save panel will replace it. You could say the buttons are “mutually-exclusive modes”. A simpler way is to say they act just like tabs.
Look closely at how a typical tabbed interface works. You click a tab, and the whole screen reloads to a new screen. The tab bar on the new screen has the same options and position as the old screen, except the tab that you clicked changes appearance to indicate that you are “on” this tab to the exclusion of the other tabs.
In Algorithm Ink, the buttons work in exactly the same way. Except there’s a twist. The “tabs” (grey buttons) don’t replace the screen, or even replace part of it. Instead they hide and reveal panels which overlay a single screen that never changes. Your art never goes anywhere, but the panels which allow you to perform actions come and go.
These overlay tabs may not be as eye-catching as a mouse-flower, but I think they’re very interesting. It’s hard to put my finger on what exactly I like so much about Algorithm Ink, but it’s plain to see that the approach is different. And in our current UI climate, well-executed difference is itself enough to deserve some thought.
Aza Raskinon 30 Jun 08
Thanks for the wonderful writeup, Ryan. You articulated the design decisions better than I could have. P.S., I like the inline use of the Submit element in your post. It’s simply lovely. Let’s hear it for direct manipulation!
Tanner Christensenon 30 Jun 08
The problem with creating such innovative UIs is that you lose some users. On Songza, for example, a novice may be intimidated by the simplistic-yet-original navigation and decide against using the website.
Then again, maybe the audience for Songza doesn’t include web novices.
Regardless, both interfaces are beautifully done and extremely inspiring. Aza clearly has a knack for creative interfaces.
Brian Morykonon 30 Jun 08
The buttons in Algorithm Ink remind me of the Browse and Artwork buttons in iTunes: hiding and showing panes.
It has often been said that web apps should look and behave like web sites, not like desktop apps. But I wonder, are we entering a new era where desktop-style web apps is the norm? There are several desktop-style web apps out there already, but on the whole this design philosophy hasn’t picked up a lot of steam. I can see MobileMe being a trend setter here.
Jamie Stephenson 01 Jul 08
As many Web apps start to look the same, it is nice to see people like Aza going against the grain. These are beautiful.
The buttons-as-tabs reminds me of how buttons used to turn certain parts of a page “on” and “off” in Backpack. I always thought they were pretty intuitive and was bummed when they were retired.
Noam Almosninoon 01 Jul 08
I like these ideas; the mouse flower is more interesting than the traditional players, but it goes against Aza Raskin’s concept of “don’t make me click”.
Wouldn’t it be easier if those options were represented in text form along side the link, and occur on rollover, so that it saves it the user from being distracted when clicking?
Allan Grinshteinon 01 Jul 08
The execution of the mouse-flower concept is clunky (among other things).
There’s an unnecessarily large amount of Flash and the typography is abysmal.
If you’re going to create brave new UI elements, you have follow through. Your execution should have integrity – and the songza execution is design-y to a fault.
Kalle Perssonon 01 Jul 08
Great post! The Songza UI is really interesting.
Allan: AFAIK, Songza contains no Flash at all – except from the file playing the music itself.
Devanon 01 Jul 08
Aza does some wonderful work with his interfaces. I understand he is seconded to the Firefox project now?? If so, I look forward to the future interface evolutions of FF…
Allan Grinshteinon 01 Jul 08
Kalle, there are actually many more elements in flash than the music player.
Johnon 01 Jul 08
Allan – I’m curious to know where you’ve found Flash UI elements on Songza… I haven’t found any!
(I’m not really familiar with the site though, so I could be missing something)
Tiagoon 01 Jul 08
Aza’s UI elements are really interesting, but the color contrast is really bad. Is it just me, or it’s really hard to read black text on a dark grey background?
Plus, Songza has some nasty black-on-red/orange-on-red fonts.
Non 01 Jul 08
Algorithm Ink: Firefox 3 / Opera 9.5, no wonder it won’t work…
Mika Marttilaon 01 Jul 08
I fell in love with Aza’s UI in the second I saw the petals. This could be a solution for all those repeating icons like trashcans, pencils, drag handles and such. Like Basecamp’s To-Do manager has, but a bit more usable. Think of “recently accessed functions” or something.
Shaneon 01 Jul 08
I loved the “mouse flower” at first. But as I spent about 1/2 hour using the site, I noticed some issues.
Primarily, when I’d click on the wrong song in the search results. I would click, move the mouse to “play” while instantly realizing I clicked the wrong one, then move the mouse to the correct title (usually just one above or below) and go to click that, but the first “flower”, still fading out, gets in the way.
Hard to explain, but the end result was 2 or 3 flowers in various states of fade-away due to 2 or 3 song clicks in the space of 1-5 seconds.
I think if you canceled the fade and hid the flower immediately when another song title is clicked, it would solve this particular problem.
I would say that because of this particular flaw, the interface isn’t forgiving. I make the mistake of clicking on the wrong song, and this UI makes me pay for that mistake with a few seconds of visual disarray and confusion and frustration that I didn’t want 3 of these things fading away and just show me my search results.
I began yearning for a “play” button next to each result.
I think this is a good alternative to a context menu, but why make me click twice to play a song when one click will do nicely?
RSon 01 Jul 08
Yeah that’s a good point. Play is probably the action you use 90% of the time. How often would you share before you play, or rate before you play? In that case it might be smart to move Play out of the flower and keep only the more infrequent actions inside.
Shaneon 01 Jul 08
After digesting it a bit, I think this could be solved very easily:
Keep the flower nearly as-is. When I click a link, begin playing the song AND open the flower. Change the “Play” button on the flower to “Pause.”
Now I’m not wasting a click just to open up a UI element that lets me do what I really want to do, which is listen to the fricken’ Ting Tangs.
And the flower provides simple access to the things a person might normally want to do after playing a song.
Robert Hoekman, Jr.on 02 Jul 08
The “mouse-flower” you refer to is really just a modified version of a “pie menu” or “radial menu”.
This design pattern has been around for quite a while, it just hasn’t hit mainstream appeal. It’s a bit of a risk to use because it’s difficult to discover as a feature, but some simple instructive text or a screenshot example elsewhere in a site can get users past that barrier.
The primary selling point for a radial menu is that it supports Fitts’ Law far better than the menu systems we usually see on the desktop and online. Because a user only needs to move the mouse pointer a tiny bit to hover over an option and click it, it’s much faster and more efficient than dropdowns and such.
As Fitts’ Law indicates, the easiest spot to click in an interface is the position where the mouse pointer currently sits (obvious, right?). Right-click (or “context”) menus are a good example of Fitts’ Law in action, but radial menus require even less mouse movement than context menus.
As monitors continue to get bigger and become less expensive, we’ll likely see radial menus used much more often and get much more complex (hopefully in an intelligent way). For example, imagine using Photoshop and having context-sensitive options available to you in a radial menu instead of having to jump to various panels to configure the current active tool. This would be a huge timesaver, and would make for a much more efficient task flow.
All that said, yes, it does also decrease the need to expose every tool and option via toolbars and panels in software, so a well-designed radial menu could indeed lead to a less cluttered interface.
Simon Scarfeon 02 Jul 08
The point of the pie-menu is that so-called “expert users” know that you don’t have to click twice, but you can rather mouse-down on the song, move the mouse a couple of pixels up and mouse-up. It’s almost like gestures.
I like them, I think that they do work for both first-timers and a new-comer to the UI item. But I can definitely see why people would be skeptical.
Weson 06 Jul 08
Umm, I’m sort of stunned. Did Aza not read his dad’s book? Modes are BAD. And his Ink interface is ENTIRELY mode based.
It might look cool from a design perspective, but it’s awful from a usability perspective.
This discussion is closed.