« May 2005 | Main | July 2005 »
June 20, 2005
Meet my partner in crime
Just wanted to introduce you to a new blog by Mark Anders. Mark and I co-lead the Zorn team here at Macromedia. He's brilliant and great to work with, and I'm sure he'll have lots of insightful things to say about Flex and RIAs in weeks to come.
Posted by sho at 4:39 PM
June 8, 2005
Seven ideas for building better RIAs
RIAs have the potential to be better than HTML-based apps, but there aren't any good guidelines for building better apps. In fact, the whole topic of creating guidelines often meets with skepticism. It is hard to come up with a recipe for how to make an RIA "better", especially given how different all RIAs are from one another.
So what would the "UI guidelines for Flex" look like? Is it even possible to make such a thing? This is not a complete list, but I have seven ideas for how to make RIAs better than traditional Web apps.
1. RIAs should embrace the idea of "selecting" things.
Being able to select things is really important in desktop apps. You can't do anything in most apps without creating a selection. Selecting things is how you tell the computer what you care about. On the web, selections virtually don't exist. To select pieces of mail on yahoo, you have to click on a checkbox next to the piece of mail. Ugh.
fig. 1 - In this view, I am tempted to select things, even though there are controls in each item. Don't they look almost like icons? Wouldn't it be great to tweak this design so you could drag select five things and click "add to wish list"?
2. Come up with a consistent way to let people know what actions can be performed on selected things.
Computers were created to perform actions. The web, meanwhile, de-emphasizes performing actions and blurs the line between actions and navigation. On the Web, there are no menus or toolbars, only links and buttons. And yet the Web is the most successful app delivery platform known to man. Go figure. I think we can improve on this. All RIAs look different, but to be usable, I think we should aim to be consistent in how we show available actions. This could happen by fiat (e.g., UI guidelines) or by evolution and consensus (e.g., nav bars on websites.. remember the early days of the web when every website looked different?) Why is this important? Imagine what would happen if desktop apps didn't consistenly use menubars, and every desktop app had a different way to show you what actions were available. Ack!
For RIAs, we could expose actions as menubars, toolbars, context menus, navbar-like things, or something entirely new. I almost don't care which way we go, but if everyone does things differently, it will be that much harder for people to understand the basic operation of each app they come across.
3. Working with documents in a "one screen" app is hard. We need a way for users to conceptualize "documents".
Intranet apps often deal with documents of one kind or another (think order tracking, CRM, etc), and they are often a pain to use. In general, people who put together internal applications don't have the luxury of having design gurus on staff, and I think the impoverished UI vocabulary of the Web makes things worse, especially when it comes to dealing with multiple documents. Flex can change all that. "One screen" apps are inherently mysterious when dealing with context switching. When you work with multiple documents in a desktop app, they open in multiple windows. When you deal with multiple documents in a web app, you often lose context as you go from an index page to a specific document, or from one document to another.
I believe we can take a lot of the mystery out of it by creating a few simple rules for how to visually communicate the concept of multiple documents in a single screen app. One product I worked on that accomplished this well is Contribute. It's a desktop app, but all work happens in a single screen, and the product does a good job of giving the user a sense of what documents are being edited, and what state they are all in.
fig. 2 - The wrong way to represent "documents" within a web app. Documents need to feel physical, which means that they need icons and you need to be able to select them. This looks more like a report. Furthermore, when you drill down into a particular document, the list goes away so you lose context. BTW, there are other documents on other tabs in this app (in en route and completed), but some people never find them.
fig. 3 - Contribute is a one screen app, and they have found a good way to (a) work with multiple documents, (b) provide a space for actions, (c) provide contextual information. The list of available documents is on the left, and the contents appear on the right as you select them. All of these UI ideas would translate well into Flex. For larger, more process oriented apps, the documents on the left could be grouped in user-defined groupings ("Travel expenses") or app-defined groupings ("For my review", "Awaiting approval").
4. Managing space is important; screen real estate is expensive.
Managing space usually means packing more information in less space. In some shops, managing space may also mean using negative space to guide the eye. In any case, space is important.
HTML-based apps already surpass desktop apps for incorporating design into applications. They're like a cross between catalogs and applications. RIAs can take this to the next level because (a) you have much more flexibility and control over design, (b) you can pack more into less space by relying on interactivity, and (c) you can give the end user more control over how the screen space is to be used.
fig. 4 - This is Zagat's new site. It's beautiful, but isn't it a bit frustrating how little space there is for each section? Wouldn't it be nice to resize "Cuisine" to take more room if that's what you are interested in?
fig. 5 - In this case, I believe the best way to use the space would be to use an accordion, although a panel group would also have worked well.
fig. 6 - Callouts and tooltips are a great way to pack a lot of information into a small amount of space. By default, Flex uses these for form validation errors, but we don't give any guidance for other ways to use tooltips. Should there be a more general guideline for when to use callouts and tooltips?
5. Getting rid of page refresh is not about the blank white screen; it's about reducing the number of steps to accomplishing your task!
When people talk about page refresh, they're not talking about screen flicker. I bet our customers don't even notice the blank white screen anymore. If you took any of the popular sites - Amazon, eBay, etc., and did nothing other than get rid of the blank white screen, no one would notice. The flash of white between web pages is like the dial tone of the web. It's almost reassuring.
When people complain about page refresh, it's really about losing continuity (where am I now? what happened?) and losing time (why do I have to keep bouncing around between pages?).
Case in point: In the early days of Amazon, you had to go to a separate page to rate each individual product. Now, you can do it all on one screen. What used to take lots and lots of steps can all be done from a single page. What used to take minutes of back and forth now takes seconds. As a consequence, I now rate a bunch of things on Amazon whereas before, I never did.
6. Direct manipulation - This used to be the buzzword for desktop UI. Why isn't it the buzzword for RIAs?
There are lots of opportunities for us to add direct manipulation to the web. Unfortunately, some of them are gimmicky. For example, asking people to drag things into a shopping cart is a bad idea.
One obvious use for drag and drop is for rearranging things. There are lots of times when the user needs to specify the order of something. Rearranging might be the end goal, as in a photo album, but just about any list that the user creates is something that potentially needs rearranging. It might sound trivial, but I think these kinds of broadly applicable ideas are the most powerful. "Always allow the user to rearrange any lists that they create themselves" would be the slogan, and the framework should make that easy.
7. Provide feedback to help users make sense of the network
Apps on the web have the potential to be confusing because there is a server piece and a client piece.
Generally, people have figured it out for HTML: everything happens on the server, not my local machine (i.e., I can visit the site again from any other machine), except that sometimes, I need to log in again or redo some stuff.
In HTML, the blank white screen tells me that the website has been contacted. This tells me that my instructions have been sent to the website, or that new information is being downloaded.
Ironically, RIAs have the potential to make this world more confusing if we are not careful. Without guidelines for user feedback, we may not know when information is being submitted to the website (is it really looking for my flight info?) or when we have received new information.
At the very least, you should consider giving the user an indicator when something has been updated on the server. You would never think to change someone's password without saying "password changed". But smaller updates may also merit feedback. Ironically, the smaller the change, the more unsure you are whether anything happened.
fig. 7 - Take a look at the Amazon star rating widget. As soon as you click on the Amazon rating widget, it tells you that it has saved its info, which is very reassuring.
Summary
RIAs are incredibly promising, but we're still in the wild west phase of the technology. As people experiment, we should expect lots of great innovation as well as lots of confusing and weird RIAs.
Eventually, the best practices for RIAs will become clear, but that will take a few years. In the meantime, I'd love to start a discussion of how RIAs can help make better ideas. I've put down some of my thoughts. I'm sure you have thoughts as well.
Posted by sho at 2:26 PM
June 7, 2005
Why I started working on Zorn
Before working on Zorn, I oversaw development for Dreamweaver and several related products. I'd been working on Dreamweaver for years (started as an engineer on 1.0), and in a lot of ways, I'd come to feel like Dreamweaver was my baby.
During that time, I had kept a healthy skepticism about Flash-based apps. Being a strong HTML advocate within the company, I kept pushing for the possibilities of HTML.
At a certain point, though, my point of view shifted, and I decided that I could do more by joining forces with the Flex team to help push that technology forward.
We all go to work for different reasons. For me, I like to feel that what I do every day makes a difference to as many people as possible. Writing software can be gratifying in that way. I've had the opportunity to work on Dreamweaver, Contribute, and other tools which hundreds of thousands of people use every single day.
The feature decisions matter. The late nights matter. It is fun to come into work when what you do matters.
Having said that, the larger picture of the Web world had changed a lot since 1.0.
When we first did Dreamweaver, the Web was still in its very early years. It's hard to say what impact we had on the Web as a whole (some people would say that we had a negative impact on the Web!), but I like to think that we did our small part to help foster the growth of the early Web.
On balance, I think the Web has made the world a better place. Once you've bought your own airline tickets or shared photos of your kid with your family (mine is 9 months old!) you never want to go back.
In recent years, though, I've come to feel that the Web has stabilized. Yes, innovation keeps happening (Ajax in particular is interesting.. more on that in a later post), but fundamentally, it is no longer the catalyst for change in people's lives.
Will Flex/Zorn change the world? I don't know. But I do know that there is so much potential out there. HTML/JS/CSS has some incredibly frustrating limitations. I believe that the next wave of connected applications will be more functional, usable, and engaging, and that the combination will change the world in whole new ways (take a look at Breeze, for example...).
Our goal with Flex and Zorn is to change what is possible on the Web.
So anyway, I've thrown my lot in with the Flex folks. It's fun and it's nerve wracking. In the Dreamweaver world, we were always chasing technology. We would spend all of our time trying to understand what people were doing as deeply as possible. In the Flex world, we need to imagine what people will need to do, and invent it. Are we getting everything right? Probably not. But hopefully we are getting enough things right to make a difference.
Posted by sho at 10:59 AM
June 6, 2005
Macromedia announces Zorn
Well, I've been quiet for the last several weeks (things got busy), but the cat is out of the bag. The project I'm responsible for is code named Zorn, and it's a Flex development environment based on Eclipse.
I've got tons to say about this, but I'm already late to a 3 hour meeting (ack!)
In the meantime, feel free to leave comments about anything you're curious about. I'll answer as best I can.
Posted by sho at 9:41 AM