Usability Heuristics for Rich Internet Applications

1. RIA is somehow a new ballgame. I remember a time when we first began with websites. We were busy trying to convert print brochures into branding websites. The same was true about designing applications we tried hard to bring desktop functionality to the browser. We failed miserably with the content driven browser functionality of the time.

   We learned the hardway to design and to implement for the browser. Now RIA’s are making us rethink a lot on these approaches. From a multi-page metaphor to single screen applications.

   This article is a good starting point to discuss implications of moving from the multi-page view to RIA’s.

2. Well, when I first saw this article, being somewhat disappointed at the lack of literature on RIA business applications, I was hopeful and my kudos to the author. This article is now over 3 years old! However, dear fellow readers, it seems that the discussion degenerated into an argument about the pros-cons of animation technologies and Nielsen’s heuristics. I think the point was well made in the article that a) a deep understanding of users is required to build them an RIA that is going to be used to get a job done and b) the user is already engaged in accomplishing a specific goal (or goals) when they come to the application in order to get that job done. I was under the assumption the author was talking about work here, not play or looking up things on the ‘net on advertising sites. So what if the technology team has to use Flash as a means to an end to provide the users with an efficient way to accomplish their work goals? As if HTML or DHHTML or AJAX or whatever is any better. The browser has some serious limitations. As long as the user is engaged, and gets from point A to point Z quickly, easily, and efficiently, what is all the fuss about?

   As for Nielsen, we have to keep in mind that he is being paid by people who hire him to help build websites that sell things, not by businesses or government agencies who are creating web-based applications to be used as tools to get things done, often in mission critical environments. He is STILL, three years later, stuck in that same mindset. I don’t bother to look at his website anymore because all he has in there are more articles about web sites, web portals, home pages, etc.

   Since I’m now in 2007, RIAs are more the norm than not, and Flash is no big deal. Maybe the author could grace our eyes with a follow up article to see how far we’ve come in the meantime? It’s a very interesting and relevant topic – thanks for writing about it!

3. Nice article and some good takes on the old heuristic chestnuts. It’s interesting to watch the Flash world via the bookshelves: there are fewer and fewer Flash books coming out these days, and a higher percentage are really good, such as Hall and Wans OOP in Flash, or some of the stuff around the Flash Communication Server.

   Also worth looking at is the efforts Macromedia’s making around “Flash Central”, a centralized OS-like environment for hosting RIAs on the users machine which forces some consistency and UI standards for RIAs.

4. Where Usability rules are concerned I say to the community, PLEASE STOP THE MADNESS! As design professional who works on both sides of the user experience profession (as a creative director and as a practicing IA), I see our profession being reduced to that of being gatekeepers and rule-enforcers. I read Jakob Nielsen’s (expensive) treatise on Flash usability and what I came away with is the sense that Mr. Nielsen has no sense of imagination, nor design. He is like the color-blind curator of a modern art museum who only likes monochromatic impressionism.

   This article is less egregoius than most on usability, as the authors tend to deal in broad general principles rather than in gratutious “rules.” But then they clearly step over the line with:

   “Animation and transitions should also be used sparingly. While animation and transition can make a great demo in the boardroom, gratuitous animation will provoke user frustration. The time to animate an element interrupts a user’s concentration and engagement in their task. Disrupting task flow significantly impacts usability and user satisfaction”

   Without knowing who the user is, what the user’s task is, the context of the task, or anything else about the user, how can they make a statement like that? Teletubbies Flash applications on the BBC web site and other games are full of gratuitious animation, yet they are completely appropriate for my delighted 3 year old. Having a quick and timely exit would be inappropriate for a user who is only learning to transition from activity to activity. Context, folks, context.

   Rules of thumb are good. Heuristics are good. they allow us to share our experiences as UE professionals and discuss ideas and principles. (and I know this is what the authors intended) But the dark side of heuristics is that we rely on “the rules” where we should be spending the time and resources on understanding the user. If I had a dollar for every time an engineer waved the blue and green book at me and told me that navigation MUST go down the left side….

   The design process is a structured inquiry that solves problems. As UE professionals we are part of the design process. We should provide flexible frameworks for designers to work within, not blunt rules to follow. Those IA’s who wish to make a name for themselves in developing better Flash apps should work in broad principles. Let’s seek to understand what goes into a successful experience. Let’s not start an arms race to apply HTML-style “usability heuristics” to what should always be a disciplined inquiry.

   Flash is a new world. RIA’s marry the flexibility of desktop software with the currency and dynamism of the internet. the limitations imposed by HTML are gone and with it, many of the rules we’ve followed to make what was a document retrieval language work for online banking will be gone too. We should consider this to be a wake-up call and an opportunity to redefine our profession.

   I have little to quibble with in what the authors have presented here, other than point 8. My problem is with the rush to define rules, before we’ve fully understood the medium.

5. First, let me say thanks for the great comments so far…

   The intent of the article (and of heuristics in general) is to help people think about what makes good design. It isn’t to decree a set of unbreakable rules, but to provide a framework and some guidance when you have limited opportunity to do user research.

   However – we meant what we said when we said

   “Animation and transitions should also be used sparingly. While animation and transition can make a great demo in the boardroom, gratuitous animation will provoke user frustration. The time to animate an element interrupts a user’s concentration and engagement in their task. Disrupting task flow significantly impacts usability and user satisfaction”

   The key in that sentence is “gratuitous” and “disrupting task flow”. That’s the context, and if animation are done just for animation’s sake, and interupts the user, then it isn’t a good thing.

   Also – a Teletubbies game is probably *not* an RIA by our definition (ie about data manipulation). My own 4 year old loves Flash games, but she’s not manipulating data.

   Finally, I’ll reiterate – RIAs aren’t about getting attention, they’re about getting things done. That task focus means that animation should be used when it helps users accomplish their tasks. And that often means less is more.

   cheers,

   Jess

6. “The key in that sentence is “gratuitous” and “disrupting task flow”. That’s the context, and if animation are done just for animation’s sake, and interupts the user, then it isn’t a good thing.”

   If you meant what you said, then the rule should state:

   “Gratuitous animation and transitions should also be used sparingly. While animation and transition can make a great demo in the boardroom, gratuitous animation will provoke user frustration…”

   The point Eric made, which I’m not clear you either got, or just simply disagree, is that animation should not neccessarily be used sparingly in the general context. The actual user context matters too much to make a broad sweeping rule like you did.

   Changing the rule to how I stated would then force you to define what you mean by “gratiutous” rather than statiung that all animation should be used sparingly.

   Here’s an example of how animation for animation’s sake might actually be fine by the way… In the new Mac OS X Jaguar, Apple added an ever so slight four frame or so transition to all dialogs that switch preferences. Like the System Preferences control panel. It happens fairly quickly, and is quite nice to look at actually.

   It adds next to nothing however in overall usability, and there might be some who feel it adds a small amount to help people know the contents of the dialog switched. but the dialog changes shape and you just clikced on a button, so how much does it really add?

   Andrei

7. I’d like to throw in my two cents on this whole animation debate. Animation can be very benificial to the user’s ability to comprehend the UI of an RIA. Is a collection of data is ‘moved’ through an interaction, some animation can help the user to ‘follow’ the location of that data. In OSX the animation of windows minimizing into the dock allows users to follow where the window is going when they click the yellow traffic light icon. This type of animation is ok, with limitations. Animations that are used to convey UI features or state changes should be quick so as not to delay the user from their next task. In the Home Automation UI I am developing all animations that relate to state change take less than a quarter of a second (and they are few in number). At that speed there is almost no delay in the use of the UI and the animation are just long enough to register with the user.

   Now, animation for animation’s sake is different than using animation to address changes in the UI’s state. Animation for animation’s sake means elements like ‘flaming 3D company logos’ and the like. This type of animation has been shown to distracts the peripheral vision and draws the user’s eye away from the content. Of course, this type of animation is also fairly common in many Flash sites, but not Flash RIAs.

8. Hey Andrei,

   Maybe I am missing something, but I don’t disagree particularly with you or Eric. I think this is largely a semantic quibble about the intent of “sparingly”….next we could ask “what is IA”. Just kidding.

   We’re not saying never use animation. Just don’t prioritize animation over user goals and tasks. The Aqua transitions (and Windows XP transitions) don’t get in the way of user tasks and provide subtle continuity and feedback. Another case where animation can *assist* the user would be in information visualization apps.

   I’m a big fan of animation, and think it’s one of the advantages of the Flash platform. However, I still would argue that the *default* assumption about elements is that they are not animated. Then when the decision is made to use animation it’s informed by user goals and tasks, instead of a technology-centric “we can so we will” mentality.

   Here’s an example of the kind of animation & transition I’m talking about (it also has hide & seek issues)
   http://www.kcount.com/nutrition/index.asp

   Where’s the global navigation? Hiding. Why? I’m not sure, but I suspect the reason is to display a cool animation.

   Animation is like bold type. When animation is used indiscriminately throughout an application, it loses its impact. It’s a powerful tool that will benefit users most when applied (here it is again) sparingly 😉

   Instead of trying to reword that paragraph by moving “gratuitous” around, maybe it would be clearer if we reframed it as a suggestion when to use animation, rather than when not to use it…

   How about:

   At their best, animation and transitions can provide powerful information visualization, functional cues, and a sense of continuity through subtle feedback. However, animation’s impact and value can be significantly lessened through overuse. Use animation when it will support user goals and tasks. A focus on goals helps ensure that the decision to use animation improves the user experience, instead of interrupting it.

   Thoughts?

9. To take Jess and Grant up on their closing sentence: “We’re looking forward to great new things— if you’re already doing them, drop us a line in the comments.”

   I gave a presentation at the UPA (Usability Professionals Association) conference last month highlighting some of the ways Flash can actually help increase usability. I’ve grown tired of hearing statements like “well, Flash has it’s place. Its good for things like games and advertisements.” Hats off to Grant for his work in pushing Flash into the realm of serious applications.

   A meager site with some of my examples can be found at http://www.usableflash.com. If anyone has an example they want showcased, please drop me a line. The example that is probably of greatest interest to readers of BoxesAndArrows is our web-based card sorting application (www.websort.net). I consider a compliment when people don’t realize it’s done in Flash.

   Finally, as per CHris’ comments regarding animations that are less than 1/4 of a second- I agree. I’ve been amazed at how a very fast fade-in can really help direct the users attention better than instantaneous appearance, which can sometimes be confusing.

   -Jed

10. Ok, I can’t resist. I have to speak up. (I also invite people to take this conversation to my webGUI list which while stale has a good # of people subscribed who would find this discussion incredibly interesting: webgui.htmhell.com to subscribe, webgui@htmhell.com to post. I will reiterate my comments there.)

    Ok, my points.
    1. Animation: I think there are TONS of good examples out there that show that transitional animations are an important aspect in usability and probably one of the main reasons why RIA’s are better than both client/server and previous HTML thin-clients. The phrase is “gratuitous” a vague sentiment, so lets not get all bent out of shape about it.

    2. The article itself: There is NOTHING in this article that is about RIAs. Sorry but its true. As someone who is a HUGE advocate of RIAs I was so excited that someone was continuig the discussion on B&A in this way, but I was duly disappointed in the content of the article in that there isn’t anything I can’t do in an IE based DOM2 system that you mentioned in a context of saying this is about Flash. Look at the work that MS is doing w/ their Sharepoint 2003 environment and you’ll see so much richer an environment than even many of what Macromedia calls an RIA (I bet they are loving that we are using this acronym as if it is real). I would say that if you took RIA out of this article EVERYONE should read it to be reminded of what they should be doing in all of their apps. Thick, then, RIA, mainframe, other.

    3. Examples of good usable flash. The favorite demo I have seen of late is at http://www.laszlosystems.com. Their calendar demo rocks and shows the real power of a Flashbased RIA in terms of using transitional animations for usability AND in terms that Flash affords us the one thing that most people complain about, namely the ability to build your own pattern language instead of being stuck in either previously bad webForms or Windows/MacOS X based forms. Yes, it is NOT perfect, but it is a great example that takes the iHotlier model that is used as the centerpiece of RIAs by most articles writing about it and then pushes it a step further by increasing contextual cues and making a much more engaging environment.

    4. Engagement. RIAs are about engagement more than anything IMHO. This is something that is so missing from Nielsen’s vocabulary it is ridiculous. Engagement is what makes an application’s user experience move to the next level. This is the stuff that can’t be tested for in the lab b/c engagement is about use over time. Is this application a fast-food restaurant or not? Word, Outlook, even the web browser are fast-food restaurants. They work, I go there often, but I don’t want to stay there. MacOS X is an attempt to create a space to live in, not just visit and to me this is the next area to explore and RIAs are one way to begin to do this, for apps that require ease of deployment, networked inter-communication, engagement and ease-of use.

11. >The article itself: There is NOTHING in this article that is about RIAs.

    >Look at the work that MS is doing w/ their Sharepoint 2003 environment and you’ll see so much richer an environment than even many of what Macromedia calls an RIA.

    Just to point out – RIAs don’t depend on Flash. We talked about Flash because it’s Grant’s expertise and it currently dominates discussions of RIAs. However, go to Forrester and read up on their X-Internet coverage (executable internet) and you’ll see a lot of alternatives.

    However, Dave’s point that our article could apply to a wide number of situations is true…as could Keith Instone’s article about the heuristics applied to the web. I hope that the article does help as a springboard for more discussion about RIAs and user experience, and provide some simple starting points for folks outside the UX community who are developing rich apps.

12. Back in 1995, I wrote an article listing 7 ways in which animation can be good for user interfaces: http://www.useit.com/alertbox/9512.html

    Our more recent project testing how children on two different continents used 27 different websites certainly confirmed that kids often (but not always) like animation: http://www.nngroup.com/reports/kids/

    The fact that animation sometimes works doesn’t negate the bigger point that applications are only engaging (or useful, or profitable, or whatever criteria you use to judge them) if users can successfully perform their task.

    Remember that we tested 46 Flash applications on three continents and found an average success rate of only 45%. Violations of basic usability principles will prevent users from being able to use an application, particularly if it’s something people haven’t paid money to acquire. (Microsoft Office can get away with more usability problems because of its higher price and lower level of competition; neither of which are typically true of Web-based applications.)

    See:
    http://www.macromedia.com/newsletters/edge/december2002/a3.html
    and
    http://www.nngroup.com/reports/flash/
    for more details of this user research.

13. What I was hoping w/ my previous article here in B&A is to form a community of people who are interested in doing RIAs, who need support in convincing their groups of their value, and sharing solutions that RIAs offer that other mediums don’t.

    But I also want to not create yet another niche b/c of a buzz term. To me, whether it is mainframe, web, client/server, RIA it is all software and the while the technologies and methods change, the end-user’s goals and motivations are pretty much evaluated the same way and thus the experience directive is the same.

    What is particular about RIA (regardless of technology) that is going to allow us to address the question of experience (utility, usability, and engagement).

    Something that Nielsen’s criteria regarding Flash assumes is that Flash exists in the browser. What happens in the world of “Central”? Does that change expectations so considerably that we should re-evaluate the Heuristic criteria? Specifically the issue of “backward Navigation” is an interesting one. It is a pure web concept, though it basically translates to the thick client equiv of cancel.

14. I think there needs to be a clear distinction between usability issues and / or design issues and the technology itself.

    It is not a fair statement to say that RIAs have usability issues by nature. Usability issues are caused by design, and not by the technology used to create a design.

    I agree that poorly trained flash developers, or designers that are unskilled have created work that is highly unusable.

    The same case can be made for the use of HTML, C, Visual Basic, etc. Having made this point, RIAs are more than just a product of Macroemedia Flash. RIAs are the future, and it is the responsibility of the design community and the leaders in our industry to guide the use of RIAs. They are indeed the future of thin clients and design practices should adapt to the technology.

    You MUST acknowledge that human computer interaction must be a fluid topic. As humans become more skilled in their use of computer systems, their interactions and ability to interact becomes much more sophisticated.

    Best,

    Dave

15. Jess, et al:

    It’s hard to disagree with your definition of “gratuitous” animation, but I think it is like saying, “don’t design anything bad.” Yes of course, gratuitious anything should be avoided if it does not contribute to the experience. It is why our friend “Skip Intro” is more reviled with each passing day. (poor Skip…). And I want to make it clear that my intention is not to pick on you or your article, which was pretty good, all things considered. But I’ve been thinking a lot about this subject ever since I asked Don Norman (at Living Surfaces, 2000) “Are you ready for the Usability Backlash?”

    My problem is the problem of rules. Like guns, fission and other potentially dangerous ideas made manifest, the problem is not the rules in and of themselves. It is what happens when they fall into the hands of people who don’t understand the rules in context to what they represent and who then go on to use them in irresponsible ways.

    We live in a society of lists. We think in Powerpoint bullets. Look at any magazine cover, and you’ll see what I mean. Lists and bullets become a substitute for thinking and rhetoric. At my workplace we used to do these Heuristic reviews where we would rate a web site based on criteria like usability, brand, design and so forth. The numbers would be averaged into a score and the client presented with that score. The number was worthless (IMHO) and though I did my duty and filled out the form, I always, always included a 3-5 page written critique along with it. I felt that my years of design experience would be more valuable to a client than a score based on how well they followed the rules.

    Rules are great until they restrain our thinking, or worse, substitute for thinking. (see Terry Gilliam’s film Brazil for extreme yet entertaining examples of rules gone awry and what happens when design thinking is constrained by rules.) Though I understand the intent is that the rules become a jumping off point for discussion and serve some usefulness, we must be aware of how rules, once codified and released into the world can be misinterpreted and misused. My caution for the community as a whole is that we must be careful when we write them, and only do so when we absolutely need them, and when we write them we do it carefull and with posterity in mind.

    Like I said, I don’t have much to complain about in the rules you did present. I am asking a bigger question as to whether we need rules at all?

    For example, you write, “While RIAs can offer novel metaphors, novelty often slows usefulness and usability.”

    I would suggest that novelty does not slow usefulness, rather confusion and lack of clarity hampers usability. Novelty is what makes us want to pick up something and play with it, examine it. For RIAs this is extremely important, because unlike a website I am directly manipulating data. As a designer I *want* to entice you to play with it. I want you to watch the interface build so you learn where things are and what they do, without me having to explain them with “documentation.” Is such animation gratuitous? I would say no, the animation is educating the user on how the interface is laid out and used.

    Problems arise if I make assumptions about what has meaning for the user without investigating or testing, and my metaphor does not entice and engage, but instead confuses and alienates. We are humans and humans thrive on novelty. Novelty can be an essential contibution to usefulness. The trick of design is to balance novelty with familiarity. Perhaps rather than a rule we could come up with characteristics of good RIAs and say that good RIA design balances novelty with familiarity. Go too far in one direction and you alienate me. Go too far in the other and I will be bored and fatigued.

    Now back to the rules. So some client gets hold of the Heuristics and says, “I don’t want novelty. Novelty will slow usefulness.” Does that really serve usability? Or does it just further constrain designers from creating somehing really useful? We must be careful about how we make rules, and what we do with them.

    OK, one more thing–about the animation issue. I agree with you Jess, and in your reply to Andrei, you summed it up in a very elegant way: you wrote, “don’t prioritize animation over user goals and tasks.” THAT should be the rule. It is so much more elegant and empowering than “use animation sparingly.” Especially to a cranky designer like me. 😉

    Eric

16. I love it.

    “The fact that animation sometimes works doesn’t negate the bigger point that applications are only engaging (or useful, or profitable, or whatever criteria you use to judge them) if users can successfully perform their task.”

    Well… of course.

    “Remember that we tested 46 Flash applications on three continents and found an average success rate of only 45%.”

    Meaning? Poor design? Is Flash inhernetly the culprit? I could easily test any arbitrary mix of 46 desktop applications on three continents and get an average success rate of 45% as well.

    The point?

    “Violations of basic usability principles will prevent users from being able to use an application, particularly if it’s something people haven’t paid money to acquire.”

    Well… yeah.

    And then you post two links, one of which takes us to a page on your site where you want us to pay money to read a report that somehow tells us something less obvious than what you posted here.

    I’m *REALLY* doing my damndest to hold back on saying something that I know will get me booted off these boards.

    But you are making it real hard Jakob.

    Andrei

17. Good application of some old work, but the limitations of Mr Nielsen’s heuristics have not been addressed or expanded on.

    1. These ten heuristics by and large ignore any emotional aspects of design and interaction. Instead, they are firmly rooted in a cognitive HCI perspective. Research in emotions over the last few decades, however, shows a tight connection between feeling and thought. Don Norman – the other half of “NNG” – has certainly picked up on this. Unfortunately, these heuristics do not address affective concerns of UI design.

    2. They do not account for a larger cultural context and may not apply universally. They instead reflect Mr Nielsen’s western cultural perspective. Not everyone in the world values a minimalist design, for example. Or, high uncertainty avoidance cultures (a la Hofstede) may or may not require more control and freedom, but instead the opposite.

    (Don’t forget the first two “w’s” in “www” stand for “World Wide.”)

    In the end these heuristic are concerned with the syntax of UI design and not with the sematics of the application in question from a contextual user perspective.

    Cheers,
    Jim

18. My apologies for my silence here thus far – it’s been a busy few days. Thank you everyone for the comments, they have been an interesting read, and I hope to apply some of the arguments to my upcoming presentation on this topic at SIGGRAPH.

    Discussion so far seems to be following 2 threads:
    1) The value of animations in RIAs.
    2) The differences between RIAs and desktop animations.

    I’d like to briefly address my views on both threads, and then provide some links to noteworthy RIAs that are publicly accessible.

    1) In retrospect, I would agree that our wording for “rule” 8, could have been better. I think it was, in part, a knee jerk reaction to the predisposition of many RIA designers to use excessive animation simply because they can. There are many scenarios in which motion and animation can enhance a user’s understanding of an interface – the trick is in determining when, and ultimately this must be left to the discretion of the individual designer/UX expert.

    I think it’s very important to note that these are heuristics, not rules – they serve as guidelines, and as with everything in the UX field, they must be applied within the context of the project, users and brand. Really, that should be the only concrete rule for UX experts: There are no rules, everything is subject to context.

    2) In my recent talk at FlashForward on RIA Usability (session notes at: http://gskinner.com/talks/ffny2003/ ), I identified 3 major areas of differentiation between RIAs and traditional desktop applications – environment, user expectations and branding requirements. A brief explanation of each is below:

    – Environment: obviously, we are working inside a different environment. RIA designers need to deal with browser chrome, limited system resources (RAM and CPU), the volatility of having a user’s data lost when they close the window, or hit back, etc.
    – User expectations: users have less of a commitment to the app, which has a large number of ramifications. Users also have expectations from a navigation standpoint, which include items like a back/forwards button, searching, bookmarking and autofill.
    – Marketing/branding: RIAs are often funded with marketing dollars (because user’s don’t expect to pay for an application). This often leads to competition for resources (time, money, screen space, etc) between branding and functionality/usability.

    Obviously this list isn’t all-encompassing, and I welcome input on it.

    3) Lastly, I would like to provide some links to note-worthy RIAs, to serve as examples or catalysts for discussion:

    http://examples.macromedia.com/petmarket/flashstore.html
    http://guest.metaltracer.com/
    http://www.ihotelier.com/
    http://www.gmodeler.com/
    http://www.laszlosystems.com/demos/
    http://www.shaker.hu/

    And just because I’m lazy:
    http://www.actionscript.com/archives/00000535.html (a list of RIAs)

    Thanks again for the comments. I look forwards to more informed discussion on this topic.

    Cheers.

19. regarding the #2 above in Grants comments: I actually disagree w/ almost everything you said:

    I think at the core of my disagreement is in all of what you said. It really shows me that we are not thinking of the same things at all.

    I’m not thinking about how I want to improve Expecia or eBay (though that is noble and could use RIAs to do just that).

    I’m talking about how would I improve all the web-based apps that have been made in the last 5 years that were desktop apps first. Library services, digital asset management, document and web content management, e-mail/groupware/collaboration, etc. All those places where an architectural decision was made that a thin client was necessary to reduce costs. Even if that meant sacrificing user experience.

    That being said, I disagee w/ your 3 items listed above.

    Environment: does not have to be in the chrome of the browser at all. In fact a good RIA would hide the delivery mechanism as much as possible and just look like an app.

    User Expectation: Users live in these applications. It is the heart of their business process management so they do LIVE here. Thus they expect these to be the best in class apps and compare them to their desktop brothers and sisters.

    Who owns it? Well quite frankly whoever is paying the bill and this for me is less marketing and more IT. To me if Marketing was owning it, I would have greatest success, but b/c IT has such a backlash to Flash it is very hard to move from where we are.

    The key to an RIA is to take the interaction behavior we expect from install apps and then bring that to the distributed models that IT requires.

    The advantage here is that Flash (as an example technology) offers easy ways of further advancing the user experience of previous desktop apps in ways that the OS models that those apps were built on don’t consider.

    I say this to explain that RIAs can be used to build desktop apps that are w/in a distributed GUI, but the reality is that RIAs even at their best will be much more than any desktop apps we currently have out there b/c they are not (so far) tied to the OS (if they were, their major advantage of x-platform would be lost).

    — dave

20. Dave,

    Thanks for the input. It seems as though we’re discussing different incarnations of RIAs.

    You seem to be referring to RIAs as they could be some time in the future, whereas I am talking about RIAs today. Right now, RIAs are deployed via a web browser. Right now, users do have a different set of expectations. Right now, most RIAs are paid for with marketing dollars, in part due to those same user expectations (not paying for online content).

    To address your points individually:

    Environment: regardless of the lengths you go to to hide the chrome, you are still operating within a browser, which is a far different environment, with much different limitations (and advantages) than a desktop app. Central will change this somewhat, but it is still a different environment.

    User expectations: I think it’s naive to say that users don’t have different expectations, and a different mentality when using RIAs. I’ve found users are much more distanced from RIAs than the desktop applications that they “own”, and they come to the table with a somewhat different set of navigation and functionality expectations. As their commitment grows, the difference in expectations and hence behaviour diminishes, but we usually still have to overcome that initial resistance. Mimicking desktop application functionality and controls often helps reduce this transitional period.

    Marketing: In my experience – which obviously differs from yours – very few RIAs are funded by the IT department. In fact, every example I listed in my post above is more a marketing project than an IT project. I’d appreciate it if you could post some links to RIAs that have been developed at the behest of IT departments – I’m genuinely interested.

    Perhaps our real disagreement is in the definition of an RIA? I wouldn’t consider an application to be an RIA unless it is internet-delivered. Currently there is only one way to do this – through a web browser. Are you ommitting this from your definition?

    Looking forwards to reading your response.
    Cheers,
    Grant.

21. User Expectations:
    Actually even DHTML based applications that I have developed show that users do not differentiate desktop apps from browser-based apps. Yes, there is definitely confusion, but it seems that the interactivity of the app, the behavior of manipulating data and content, and not just gathering and transacting causes users to arrive at specific expectations. Put a user in front of groupware program like Convea (completely done in DHTML) and they instantly expect it to interact like Outlook or Lotus Notes. Put a user in front of a wizard that takes them through a step by step process and they assume it will act like an installer app.

    My usability tests have confirmed this in the environments that I work in which are completely browser based and completely DHTML based. Even when we tried to create a UI that didn’t break (too many) web standards for interaction users still went straight toward standard desktop conventions such as drag & drop and context click.

    Now that being said, the browser as you noted has one advantage that users do not seem to want to leave. In our UI tests where a desktop application model was used (instead of the web navigation model) we found that users still relied heavily on the back button and bookmarking.

    My point is that users will expect what they think is the best of both breeds of interactions. Where one fails they expect the other.

    Most importantly I think it is false to do what Jakob Nielsen did back in his “Flash is 99% bad” days when he thought that users would only respond in a browser to using web conventions.

    Environment:
    What is a web browser? Isn’t it just a VM? If MS has its way there will no longer be a Browser anymore. It is just a control. That control can carry other controls and controls can be delivered remotely over the network (Internet or otherwise: btw, I agree that the network is a key component) via a VM. Marimba’s Castanet in its earliest incarnations was the first attempt at an RIA, which I would define as a network distributed GUI used for interacting with network accessible data (structured and unstructured) and/or network enabled communications.

    As for Now vs. later … I don’t see the relevance to the comment. RIAs are in such low use throughout the web, even the examples you gave are pretty weak when we both know the real potentional here. To have a discussion about RIAs and not be concerned about the 2 year path to me is irresponsible of the discourse necessary in order to bring more an better uses of RIAs to the fore.

    In fact I would say to focus on the “marketing” side of RIAs as you have suggest you are doing is actually focusing on the elements of RIAs that most people are afraid of when trying to make the conversion to IT based RIAs and thus hurting the “Movement” if you will. Even in the most marketing centric environments IT still needs to build RIAs and have that veto power due to lack of developer adoption.

    As for IT based examples. I know of few in the works, but none that are live as examples. But again, is that b/c of lack of utility or lack of adoption? I would suggest again that marketing is a misplaced focus for a discussion of RIAs on so many levels. The only real way to bring RIAs to real potentialed fruition is by concentrating as companies like Laszlo has done towards the developer community and less to the design community.

    With all this disagreement being passed back and forth, I want to state that this discussion is of the utmost importance and relevance to what we need as a community to be thinking about.

    It is clear that usability and good user experience of networked applications is never going to be achieved with thin-clients the way they currently are, and with the business requirements as they current are: x-browser/x-platform/x-device. It is imperative for the industry to work towards a system that deals with this issue. I see two possibilities in the current environemnt: 1. MS rules the world, long live MS and a combination of DHTML and ActiveX controls dominate the networked application environment. I’m sure that most of the readers of this zine don’t want that. 2. Flash or a similar runtime VM succeeds in cracking that armour. More so than any VM Flash has the closest thing to the type and volume of ubiquity (is that a real phrase?) as IE and Windows combined. Flash has the added advantage of running on all major platforms and in all major browsers.

    I still beg for a continuation of this discussion, but more in line w/ the direction of discovery rather than particulars of defintion. The only way to make RIAs happen at a faster rate is to have a better story of ROI and a better discourse as to real effect on usability issues.

    1. How do RIAs make applications better? Not just thin-client applications, but all applications and I do believe they do do just that.

    2. What is still missing in the standard RIA environments that we need to make them work? Better desktop interop? a consistent pattern language to standardize around?

    What I don’t think we need are new heuristic analysis that attempt to separate RIAs from other software as many have tried to do with thin-clients and web sites thus far, b/c in the end (and this I very much believe) an app is an app is an app from a CHI perspective of cognition and response.

    Anyway, I think it is time for me to fade back and let others join in.

    — dave

22. Here is an example of a next gen UI for a Service-Oriented Architecture from salesforce.com, called sforce. This is a complete front-end for a SOA that deploys an application-like experience with a web page like deployment & maintenance profile.

    http://www.dreamfactory.com/salesforce/sforcedeveloper.html

23. Interesting discussion going on here for sure. It seems that Flash has found a whole new area for usability people and designers to disagree about! Yay! (And we thought it had ended with the skip intro debates of the late 90’s…)

    Grant has been modestly not linking to his own remarkable work with Flash RIAs, in particular the excellent “gmodeler” tool, which manages to incorporate animation which might be called either gratuitous or engaging in an application which is genuinely useful. It’s more appealing to me than the lazlosystems demos, which seem largely to replicate existing apps in Flash (not to downplay the Herculean development effort that seems to have gone into that stuff though).

    http://www.gskinner.com/gmodeler/

    (Ok, I now see he linked to it in a comment above, but it’s worth calling out.)

24. One more link:

    I think that http://www.onmodular.com/ (“onModular”) is a fascinating RIA-like application. Certainly it’s a complex manipulation of (sound) data, with an interesting UI. Probably a poor choice to illustrate usability, I guess.

25. David,

    1. How do RIAs make applications better? Not just thin-client applications, but all applications and I do believe they do just that.

    There’s a number of ways that RIAs make the ‘application experience’ better in terms of web deployment. First off, we should recognize that the interactions available within the framework of an HTML page, and I’m including DHTML, XHTML and other variants of HTML, are just not that robust (or they are robust but too unstable). When developers look to using CSS and JavaScript to provide a little more control over the interaction on their pages then there are all kinds of compatibility issues. Frequently web developers have to jump through the hoops of browser and platform compatibility and server connections just to be able to get a round peg through a square hole. There’s nothing like jumping through browser hoops to drive up the cost of developing an application for the web.

    One of the biggest issues with the overall usability of the web is that there are too many non-standard interactions out there. Some menus pop up, some pull down, some fly out and some expand down the page. Buttons may activate on a click or a roll-over or not seem to work at all. The end result is that users are completely confused as to what they might be able to expect on a web page.

    Now, interactions in Flash can fail for the exact same reasons I’ve cited above (except the browser compatibility issue – with Flash you just need the current plug-in). I think you will agree that much of the criticism leveled against Flash in terms of usability has focused on the fact that developers have been creative with interactions in their Flash content for so long. The flip side to this is that developers have control over how the interactions actually work in Flash. An RIA developer can build better interactions for the specific tasks their users are presented with. The interactions we build can step away from the limitations of HTML and provide a more task-specific interaction to the user. This ability, which only comes as a result of user testing and iterative design, can make a complex task easier to accomplish within a Flash based RIA interface for the user.

    Creating these customized interactions that are highly focused on assisting the user to complete their task is where RIAs really deliver in terms of ROI. Take the case of the Yankee Candle Company’s Corporate Candle RIA (here: http://www.yankeecandle.com/cgi-bin/ycbvp/cfg_index.jsp?category=%2fRetail%2fCustom+Candles ). This RIA harnesses the strengths of Flash to walk users through a potentially confusing process. Initial reports on the impact of this RIA have been all positive for Yankee Candle; 25% increase in product revenue and average order size, 70% decrease in call center calls for custom candles and a reduced order time from a 20 minute phone call to a five minute online experience. Talk about strengths! These are figures that will turn heads in corporate office across America.

    2. What is still missing in the standard RIA environments that we need to make them work? Better desktop interop? a consistent pattern language to standardize around

    A consistent pattern language would be a great help to RIA developers – but I wonder if we are still too early in the field for this type of pattern language to be settled on. A better understanding of usability, and respect for user testing as part of the development cycle is certainly called for. The problem is that usability testing is hard to convince clients to pay for.

    There’s also a lack of interaction models available to RIA developers. Flash MX helped to address these issues with their components, but we are only now starting to see the results from these efforts. A central ‘interaction’ repository for scripts, prototypes and components would be a great resource – but no one seems to be building it.

    What I would like to see is more case studies about how RIAs are impacting the bottom line of the corporate world. Yankee Candle’s ROI data is stunning, but there’s not a lot of other companies that are releasing this type of data publicly (Webvertising’s iHotelier also has great ROI figures). What developers need to do as part of our projects is to record the ‘before’ statistics when replacing a traditional form based online application with a RIA. With strong ROI figures in our back pockets, we should not have any trouble convincing our clients or IT departments to take a serious look at RIAs and how they relate to the company’s Internet strategy.

    CHris

26. That was so perfect, Chris. Let’s get started. 😉
    — dave

27. Chris, have you ever looked at this?

    http://www.macromedia.com/cfusion/resourcecenter/resourcecenter.cfm?pagename=idc%5Freports

    Joshua Duhl analyses some kind of ROI data…

    PS Macromedia has released the june flash adoption statistics!! A bit less than expected, I think..

28. Chris, have you ever looked at this?

    http://www.macromedia.com/cfusion/resourcecenter/resourcecenter.cfm?pagename=idc%5Freports

    Joshua Duhl analyses some kind of ROI data…

    PS Macromedia has released the june flash adoption statistics!! A bit less than expected, I think..

29. Guido,

    I actually have read that report you linked too (it’s where I got the Yankee Candle ROI data in my post). It’s a good start, but the data to ‘marketing’ ratio of the report is too high. The real issue is that we Flash developers are not doing the leg work *before* the project starts to find out how our RIAs impact the bottom line. I once worked for a lady running a fairly large web team who impressed on me “If you don’t measure how well you have done, then you haven’t done anything.”

    The measurement needs to start *before* the RIA is released. Collect data while you are developing and then after the release. I think that many of us will be surprised how effective RIAs can be with a good user centric development process in place.

    Dave, Haven’t we already started? 🙂

    CHris

30. Sorry to be the one that says this, but there is a misspelling in the article: “everydaylanguage” should be “everyday language.”

31. Yes, Chris we have … you’ve been one of the major proponents indeed. I’m just an impatient fool sometimes who wants my visions on screen now.

    You are right that the RIA developers need to have their act together so we can build better case studies.

    I also think I was being more specific though in regards to creating a pattern language for RIAs that fills in the blanks of HTML and client/servers that we currently use for most of our pattern language in application development. This work like the business side also needs to be part of the leg work we do.

    Something I’m doing in my organization to push RIAs (and mind you its a tremendous uphill battle) is doing prototyping of our current systems. The best thing we can do to “get started” is to take the initiative in our organizations and design prototypes that demonstrate the value of an RIA that speaks to both marketing and engineering (that is quite a tongue twisted task).

    While the battle is uphill, the effect that I’m having is tangible and forward moving.

32. For those who mentioned Lazlo, their demostrations are good but there are still many improvements to be made.

    Most importantly, designers of RIAs must keep User Tasks into consideration all the time – you guys mention User Tasks but the links to demo apps don’t show that people are keeping this in mind (an exception being iHotelier).

    Why do these apps not leverage all the basic WIMP principals people are used to in Aqua and Windows(e.g. such as subtle feedback – status bars, timer cursors etc.)?

    Although Jakob notes that Microsoft apps can afford to have worse usability than RIAs, even Lazlo’s basic calendar app falls behind Microsoft Outlook in various ways.

    I sent the following email of my experience with the Lazlo Calendar demo to Lazlo just earlier.

    I suggest having a go at using the Calendar app, and reading my experience at trying to complete what should be a simple task, adding a new event.

    == to info@laszlosystems.com ==

    Hi,

    Just reporting my experience when first using your Lazlo Calendar.

    Context: It is July 31st 2003. I am Tim Lucas, first time user of your calendar software, experienced computer user and web professional. Previous calendar using experience: Outlook.

    Task: I wanted to add an event for the 6pm-6.45pm, 8th August 2003 to my calendar.

    Description of how I went about completing my task.

    I first clicked the Add Event button, then the > button next to “July 2003”. I was also thinking maybe I should be clicking the > button first, before clicking “Add Event”.
    I clicked the > button and the date changed to 1 August 2003.

    After clicking the “Add Event” button my first idea was to double click on a day in the calendar, but this just expanded the day and didnt change the date in the “Event Info” box – the date stayed as 1 August 2003. I then double clicked on a time slot on that expanded the day, but nothing happened in the “Event Info” box either.

    I then went to the date field in the “Event Info” box directly and clicked the > button, and now August 2 was selected – but the expanded August 8 day was still there and I felt I may have already stuffed it (I couldn’t see a way to close the expanded August 8 entry).

    On the screen is the grey item for 9am on August 8 named “New Event”. I scroll down to 5pm and I can no longer see the grey box on the calendar for my new event, but I can still see the same details in the “Event Info” box.
    I then click on the field that says “9.00a” to type in “6pm” but clicking on the field does nothing. I then repeatedly click the > button until the time gets to “6.00pm”. Happy with the results, I continue to do the same thing to change the other time field to say “6.45pm” (by clicking the

33. I have spoken previously on RIA development and disagree with some of the things Grant states in his talk:

    “Everything should go through the designer! Developers should not talk to marketers!”

    Isn’t this a wee bit sweeping? I’m a developer (with a degree in Mechanical Engineering no less, a real nerd!) and frequently lead the business development and user experience aspect of our engagements. Not only is having a developer involved in conversations with the customer important, it’s a required part of our process. Just as having a designer present when talking about functionality requirements is a requirement.

    Lack of cross-team collaboration is a giant failure among agency design teams. Failing to incorporate the experience, creativity and ingenuity of smart people based upon their job title is a key reason why their work fails to meet expectations and comes out late and over budget.

    Secondly, your approach to process seems to recommend a waterfall development model. Although developing in Flash makes it more difficult thanks to the current I’ve-got-the-FLA-and-you-don’t process, my eyes have been opened to the use of iterative processes such as the Unified Process. My company has their own version that extends UP/RUP for interactive projects ( http://www.iconprocess.com ). The key thing that I pulled away from these processes are in tackling the difficult and risky parts of the project first in the prototyping phase, prior to even committing the project is possible. By building, testing and benchmarking the difficult parts first, only as much time and materials are required as to decide whether or not to keep moving forward and iterating.

    Lastly, I find that users have a better attention span when working with an application (RIA or not) than when “surfing or browsing”. When they care about executing a task, they tend to focus and try “extra hard”. I may be mis-reading your FF preso however, so I won’t comment too much there. While I was working on Postio ( http://www.postio.com ) a web-based Outlook-like mail client, we found in user testing that, as mentioned above, as soon as users start using an application, it had better perform like one! Drag and drop, right click, etc. These were comments that came up in almost every user test. We had to redesign the application to be much more 2D and “feel” more like a web page in order to better manage expectations and improve usability. Be wary of giving users what they want, they’ll never stop asking for more. 😉

    Regardless of the above disagreements, I liked the article here on B/n/A and Grant in particular has done amazing work with Gmodeler so I know he knows how to do high-quality work ready for public consumption. We recently released a demo of RIAs for Retail E-commerce that speaks directly to some of the issues discussed here ( http://www.richcommerce.com ) so I’m thrilled to see public discussion sprouting up!

34. “We recently released a demo of RIAs for Retail E-commerce that speaks directly to some of the issues discussed here ( http://www.richcommerce.com ) so I’m thrilled to see public discussion sprouting up!”

    Interesting demo. Well done.

    My only quibble with it is that the entire demo makes it sound as if RIAs are some sort of new revelation, or were impossible to do in the past.

    This is simply misleading.

    RIAs were not impossible to do before. The fact no one built a real application for WebVan or Amazon.com does not neccessarily mean it was not possible. It’s just that no one did it. They chose the easy (and crippled route) or doing it inside a web browser.

    RIAs, or any desktop application with a network component, has always been possible ever since networking first appeared. All the benefits are obvious. RIAs are simply taking us back to real desktop application design of the late 1980s and early 1990s (thank God!), but we now can assume a network component.

    Whether you build the app in Flash or write it in C is irrelevant to what is and was possible using this model. (Except if you write in C and create a true app, you’ll not be limited by anything except engineering and coding ability. Using the browser flash limits you to dealing with the middleman.)

    Other than that, like I said, nice demo. 8^)

    Andrei

35. In response to the post by Tim Lucas:

    First of all I thought your suggestions were extremely thorough and insightful.

    After reading your post I couldn’t help but feel that you were under the impression that the Calendar app is something that we at Laszlo Systems sell.

    Just to set the record straight, we have a product called the Laszlo Presentation Server (LPS), which is a platform that allows you to build rich internet applications. The Calendar app is a demo of the kind of application you can build using our software. The LPS is free to developers (you can download it today if you like), and all the code for the Calendar app is included.

    That said, I decided to have a go at implementing two of your suggestions (namely adding a status bar and having the date change in the New Event box, when the user clicks on a day), and I documented the process. Read about that here:

    http://www.laszlosystems.com/developers/forums/showthread.php?s=&postid=1158#post1158

    I also put the app I tweaked up online here:

    http://www.mylaszlo.com/lps-v1/antun/calendar/calendar.lzx

    In short, you should feel free to take the Calendar code and play with it until you get the behavior you want. If you get stuck, just ask on our forums!

    -Antun
    Support Engineer
    Laszlo Systems, Inc.

36. Jess and Grant,
    I enjoyed very much to read this article. Your explanations where really simple and clear and at the same time – without insulting the intelligence of the audience.
    Thank you,
    D. Raizman http://www.symula.com

37. Thanks for the recent comments.

    Craig – I’m with you on the fact that a lot of so-called RIAs are unusable and often done for the novelty factor. I’m curious how you figure DHTML somehow has less user experience issues than Flash…

    For what it’s worth, we would define something like Oddpost (www.oddpost.com) to be an RIA, even though it’s built in DHTML.

38. I think it’s interesting to see the idea behind RIA’s is that it is a webinterface built in flash. This is not the case. Although many developers choose flash as their platform for developing such applications, that doesn’t mean their aren’t any alternatives.
    As already mentioned, DHTML creates a lot of the same potential for developing RIA’s.

    It’s not the technique which makes an Internet Application Rich or not, neither is it the amount of blinking icons. It’s the way people can reach their goals and how they can do that a) quicker b) easier c) and probably with a lot more fun in it too. Meaning, an RIA has the potential to increase user satisfactory. Just like Windows had over DOS.

    I do agree with Craig a bit that a lot of RIA’s out there are not doing the best job at meeting the wishes of their users in the best possible way. But remember that RIA’s are just beginning to get foot in the industry and user awareness just as developer awareness has to grow. Developers in general need to get their hands dirty and probably make the wrong decisions often. In doing this they will learn what a better aproach for certain problems might be. In general i could say, what isn’t good today, will not automatically mean it won’t be great in the future. If we kept doing the thing we do, without looking at ways to improve and ‘enrich’ (tadaa). We would still be surfing through the text/’graphic pages we were used toi in the very early days of the web.

    I think now is the time to get involved with RIA’s. Try to do the best with them as you can, learn from the mistakes you made and make sure you keep improving the way you build them. Ignoring the fact that RIA’s hava huge potential is in my humble opinion a mistake.

39. Craig M. Rosenblum said: “Simply said, RIA’s are not usable, intereresting toys, but not meant for real practicality. Because they change the user experience away from what is reasonably expected is the typical web experience.”

    Ouch.

    So, considering that the entire World Wide Web is based on a weak and fragile origin (HTML), building on that forever is what you suggest as an evolutionary practice? Because the user is now familiar with a problematic legacy, should prevent us from exploring new forms of delivering information? And because novelties such as Flash have been employed in specific domains such as gaming and entertainment means we can’t find different and unique uses for them?

    There are as horrible RIAs and horrible Flash implementations as there are horrible DHTML/CSS/JavaScript uses out there. It is precisely by not trying to expand Flash’s capabilities that they will remain like that – limiting the use of a technology like that will only perpetuate its misuse when applied outside its “comfort domain”.

    And as for the users, it’s precisely the good things about Flash & RIAs that can help users with things, such as decreasing learning curves, speeding up task completion and diminishing frustration through new metaphors that are not possible with the other current technologies, like DHTML, CSS and JavaScript.

    P.S: Great article Jess and Grant!

Comments are closed.