Down (err, Up?) with Bottom Bars August 11, 2006
Posted by dllh in flock, ui.8 comments
First, let me take a moment to revel in the past. Once upon a time, we had a thing called the shelf that lived in a happy little sidebar. This was way before Flock was even Flock. (Disclosure: I wrote that version of the shelf and so may have an overzealous fondness for it, though I’ll say right now that many of the things in the current version of the shelf are hands-down better than in the first version; it’s just the user interaction that I find unpalatable.) We later moved the shelf into a popup window, and then into a topbar and ultimately into the bottombar that it currently occupies. Although I like the core functionality of the shelf (seriously, I gushed here about how it helped me to blog more and be more productive), I find it unusable because it’s a bottombar. There are two key issues that make its being a bottombar a big problem for me.
- It doesn’t display horizontal content in a useful way. Only a few items can fit in the bottombar, and it’s difficult for me to differentiate among them if they’re mostly text. As my habit had been to use the shelf (web snippets, whatever) primarily as a scratchpad for blog post ideas, it became unwieldy for me to stick blurbs — even short ones — down in the bottombar with any hope of being able to see at a glance what they were about (I talk about this in more detail here). Earlier versions of the shelf allowed me to preview more of the text at a glance (two or three lines), which made for a more efficient workflow. A vertical orientation of items (as in a sidebar) with the potential for horizontal display of text makes more sense for anything into which text can be dragged.
- I use a laptop, and bottombars are physically painful to use. My hand and wrist muscles are accustomed to the motions associated with darting upward on my trackpad to press application buttons and menus. I do this casually thousands of times a day with no pain. Tracking downward to a small area at the bottom of the screen seems to require different muscles, a greater rigidity of my fingers. It’s difficult for me, and it sort of hurts me to do it. It makes my wrist ache. So moving many of the things I like about Flock into a bottombar will cumulatively cause me enough pain to disincline me to use the browser. Which is a real shame, because I’ve decided I like our photo functionality enough that I’ve started taking more pictures and have signed up for a Flickr pro account. (Also, as an employee, I sort of have to use the browser, so Flock’ll have to invest in some wrist braces for me if we switch to a bottombar-exclusive UI.)
Add to these things the fact that moving topbars to the bottom doesn’t solve the problems Will enumerated with topbars:
- Notifications of new photos
- Being able to see a group of photos (and not just public photos on Flickr or Photobucket)
and I’m dead-set against the move.
So, now we know that bottombars don’t appeal to me, and in the post I never finished the other day, I was going to propose that even topbars weren’t terribly useful. When Flock was starting out, one of our goals was to mix up the browsing experience a bit, and that meant experimenting with things like topbars. They seemed neat at first, but we found some cases (e.g. the shelf) for which they weren’t ideal (well, that’s my opinion, at least), and I’ve begun to wonder if the topbar (and the bottombar) isn’t something we’ve hung onto for the sake of its invention rather than for its actual usefulness in real life.
I’ll admit that for photo viewing, the topbar works pretty nicely because with photos, there tends to be a sense of graphical chronology. The topbar shows photos in what amounts to a timeline, and it’s really a good fit. Arguably, showing avatars of people in a topbar can make sense if you’re showing them either in order of recently-added content or of addition to your people list. And showing thumbnails of videos or saved locations for a mapping program might work fairly well in a horizontal view.
On the other hand, chronology display isn’t limited to the X-axis. Blogs display their most recent content at the top of the page, and nobody’s confused by that. So a sidebar listing your people in descending order of content produced or of addition to your queue stands to work as well as a topbar or bottombar listing. Further, with a sidebar, there’s room for a thumbnail and a narrow column of meta information or for meta information in a couple of lines underneath the thumbnail. Or, if your gripe is that a sidebar can’t show as many photo thumbnails as a horizontal one, there’s always the option of allowing a two-column view within the sidebar (an option we already allow to be toggled in the news reader). Further, sidebars are a user interaction paradigm that everybody understands. If you read email, you’re comfortable using sidebars.
In reading feedback to Will’s post, I see that opinions are pretty mixed. Some love the idea of moving topbars to the bottom. Others think it’d be awful. Still others want photos on the bottom and snippets on the side so that both are accessible at once. I’m leaning toward a sidebar view of everything with optional horizontal displays of some types of info.
Flock, we’ve often said, is about choice. We let you choose Flickr or Photobucket, Shadows or Delicious, whatever blog platform you want that uses one of several standards. It can be bad to offer too much choice (you know the old sketch comedy gag wherein the waiter unfolds tiered set of choices upon tiered set of choices for the diner who simply wants a glass of water or a cup of coffee). Providing too many ways to access your people-centric content stands to make it very hard to create discoverable features and to support them. Applications like Photoshop and The Gimp can be confusing with all
their palettes, and we should avoid that sort of experience for simple
web browsing and basic people management.
Still, I wish there were a way to let users define their experience to a degree, perhaps with sensible default placements of content views but with the option to move them around and dock/pin them as you see fit. I think I would keep photos anchored at the top (toggleable with an access key, of course) and snippets on the side (where I’d actually start using them again to jot down quick notes). A view of people I would probably also keep on the side because I’m accustomed to my vertical GAIM listing of people.
What kind of workspace would you set up? Will, is anything akin to what I’ve proposed even remotely possible if it seems to appeal to people?
New Flock Buttons May 22, 2006
Posted by dllh in flock, ui.4 comments
 |
Old, round Flock buttons |
 |
Newer buttons I’ve been griping about because they look too much alike and aren’t very depictive. |
 |
Buttons as of May 22 |
Buttons have been on my mind of late, and there’s a new development. Thanks to a comment from Thomas Stache, I downloaded a new build this morning and saw that we’ve got new buttons for the photo and news features. I haven’t seen either in the lit up state yet, but I think the unlit states are a big improvement. I’m still not convinced that users new to Flock will know exactly what the icons are for, but that they look substantially different from one another makes the user experience 100% better for me. I still might advocate a camera image for the photo button, but I can live with the icons as they currently look. Now that I compare the new icons to the original round buttons (thanks to Lloyd for suggesting that I post a shot of them), I think I do like the newer type of icons better; they look less clunky.
Thus endeth this installment of the button chronicles.
Argument for some button changes in Flock May 21, 2006
Posted by dllh in flock, ui.9 comments
I'm going to lobby here for a button icon change. After several days of using a version of Flock with the round Dippin' Dots-like buttons removed, I've more or less gotten used to the photo and news buttons, but I think I've done so more out of habit and use than because they're useful buttons. There are several problems with them.
First, the photo button is too generic to accurately depict what it means. I suppose I could figure out as a new user that the button looked like a picture of some sort, but it also looks rather book-like. I could think it was a print button (as it looks rather like a printed page). I could even reasonably think it was a button that would take me to sites for shopping for art (not likely, but plausible) or to a more general image search than what we actually build in, or I could think it would perform some sort of desktop action. It's just problematic. I think going back to a camera image makes sense. It follows the model of print icons, attachment icons, and even folder icons, all of which depict an object that facilitates the given action rather than the object upon which an action is taken. One might conclude that a camera button could make people think they were going to visit camera shopping sites (again, not likely, but plausible). It's also possible that people might think a camera icon signifies interaction with the camera itself (ie, that the browser includes dialogs that walk you through the actual image download process), and perhaps that's what drove the icon change in the first place. I nevertheless think it's better to stick with a camera, as I believe people are more likely to click an icon whose picture they can clearly identify than one they can't, even if they know what neither does.
Second, the news button doesn't really look like a newspaper, and as has been pointed out sometime fairly recently (maybe in a blog comment somewhere), the old newspaper model maybe isn't what we should shoot for anyway. In any case, it's not clear what the icon means. I read a comment in irc in which a long-time user of Flock saw the icon and was thrilled at the prospect that we had integrated some sort of iPod interactivity into the browser. I tend to think it looks sort of like a calculator. I'm ok with the non-candy buttons we've got now, but I think that if we stick with the newspaper icon, something closer to what we had on the old button does a better job conveying the idea (my wife proposes that making the photo live in only one column might help). I can't really think of an alternative icon that would convey what the button leads to, unless we go with the standard RSS icon that appears in the urlbar. This would be problematic because that icon probably doesn't mean much to most people (neither does ours, I argue), but at least there would be consistency, and people would be better equipped to conclude that there's a link between the toolbar button and the urlbar icon. So consistency between the two ui areas might make sense, in any case.
Third, the photo button and the news button look enough alike that it's hard to distinguish between them visually. Thus I find that I distinguish between them based on position rather than on depiction. This seems like poor usability to me. Even if we continue to use vague, unidentifiable icons, I hope we provide broader differentiation between these two. One user has commented that he thought they signified a landscape/portrait distinction, and it occurs to me that they look enough alike that one might think the photo button shows only a preview or only images on a page, while the news button shows the full text or adds captions or annotations to photos. They look, in other words, as if they signify slightly different views of the same information rather than two utterly distinct browsing functions.
Fourth, I don't think the "lit" states of the buttons are bright enough, and having them be different colors for the different buttons seems bad. It's like reducing the brightness of traffic lights and letting different cities or even different intersections define which colors (and positions) signify which signals. When looking at the old buttons, I didn't even have to try to notice when my photos or news were updated because the bright complementary orange jumped out at me. I now have to do some cognitive processing to determine whether or not the buttons are lit up. Standardizing the color of the lit states would cut some of this processing, as would making them brighter. I now find myself back in the position of having to think to check for updates to my photos or news. Admittedly, the check is easier than it was before we had buttons that lit up (I visually scan the buttons, look for subtle green or purple shading, and behave if/as needed rather than having to click a button to go to my bloglines account or click a few things to look around in the photo topbar), but it's harder now than it was in builds from a week ago. My vote is for bringing back bright orange states that alert me to changes.
I say all this, of course, as a user and not as a certified usability guru, so take it for what it's worth.
Buttons May 21, 2006
Posted by dllh in flock, ui.3 comments
So say you happened to fire up a new browser named, say, "Grock," and up there beside the "home" and the combined "reload/stop" buttons, you saw the two buttons pictured here. What would you think they meant? What would you expect them to do? If you already know, no fair.
Wil Wheaton and Tagging March 17, 2006
Posted by dllh in buzz, flock, ui.9 comments
The science fiction child actor everybody loves to hate gave Flock a brief review today. To be fair to Wil, not everybody loves to hate him anymore. In fact, droves of people have enjoyed reading his blog for years, and I remember being impressed, when I first encountered it during my Fark phase a few years ago, that a celebrity had bothered to learn how to code and had written his own blogging software. It seemed so down to earth and cool and dorky in a way that appeals to me. But enough fan-boying. As a little aside in an entry about retooling his web presence, Wil mentioned Flock (along with Performancing and Ecto) as a blogging tool he had tried out. His verdict?
Flock is pretty cool. It’s got a nice editor, and I especially like how it seamlessly integrates Flickr images and del.icio.us bookmarks into your blogging experience. It integrates lots of tools and appears geared toward blogging and anything which involves a tag. If I was all about that sort of thing, I’d be really into flock, but since I’m not, I can’t see myself using it.
And a perfectly reasonable and fair verdict it is on the surface. We’ve known all along that we’re not going to appeal very much yet to the general web user. Of course, part of what we’re doing is trying to change the way people think about and use the web, so we’re hoping to expand our audience over time by improving the way the web works. We can do this in part by helping to showcase the usefulness of things like microformats, tagging, etc.
In that vein, let me posit that the whole tagging thing need not be as scary or as web-2.0-trendy as it sounds. I don’t care about tagging for tagging’s sake, but I do find it to be a useful ad hoc way of categorizing things. If we built some auto-completion into Flock’s favorites tagging UI (and I don’t even mean auto-complete that taps into social networks; just a list of tags I’ve applied to links), it’d be all the more useful and would help me build consistent taxonomies around my favorites without having to rely on my memory (e.g., I can never remember whether I tag things “javascript” or “js”).
From a technical standpoint, using tags isn’t different at all from using categories. In each case, you have a database row tying a taxonomy term to another piece of data. The difference between tags and categories, as far as I can tell, has to do strictly with user interface (some would argue that it requires a different mindset). I find tags in Flock useful not because they’re trendy and web-2.0ish, but because they help me streamline how I manage my favorites. Here’s how:
- When I’m adding a link, rather than traversing a many-tiered series of nested menus to find a folder, I just type a tag. Adding auto-complete or a clickable list of likely candidates for tags would make this even more useful to me.
- When I’m looking for a link in the favorites manager, I just type a likely tag in the search widget at the bottom. It almost instantly narrows my list of favorites down to links I’ve applied a given tag (or fragment) to. It also happens to do a full text search and show matching links.
Part of the beauty of this approach is that even though we call the tool the favorites manager, I don’t actually have to do any management of my favorites. I save a link, and I can find it easily without being daunted, after months of browsing, at the prospect of having to navigate through six layers of menus to get to a link that legacy bookmarking systems allow me to categorize exactly one way without duplication of effort. If I’m not inclined to tag my links, I don’t have to, and Flock still provides a full-text search that lets me find relevant content I’ve visted more easily than otherwise. Which means that I don’t have to bother pruning old favorites or finding complex ways of categorizing them hierarchically in order to make it eaiser from a UI standpoint to find them.
So, Wil, if you happen to follow the trackback and read this, you don’t have to be a tagaholic to find Flock’s favorites features useful. If you (plural, generic you) don’t find the features useful, fair enough, but our goal — in spite of any buzz that may circulate about us — has much more to do with making it easier to use the web than with jumping on any bandwagons (though some bandwagons are heading in what we think are good directions). In order to find tagging in Flock useful, you don’t have to know much about tags or web 2.0 or whatever — you just have to see the value in the simple application of labels to links and the easy retrieval of those links later. In other words, you don’t have to be a fanatic about tagging, though it makes sense that our core audience for the time being is composed primarily of those for whom the novelty of tagging is appealing.
