Monday, June 14, 2004

What is usability, beyond all the cool phrases?

It sounds like it's more complicated than it is. This post is based on all the comments, regarding my RIA post.

So let's take it to the next step usability.

Irregardless of what the guru's say, and I do not pretend to be a guru, just one coder talking to other coders.

Our applications have to be designed/developed for who our end users are. And based on their know-how they have reasonable expectations of the web app, and the browser in which they interact with that app.

Browser Usability: Must not intefere with list

1. Link colors should stick to standard link colors, so there is no confusion as to what is a link and what is not a link.
2. The paging of back/foward should not be intefered with, because they have a reasonable expectation of going back and forth.
3. Right-click context menu's should work for easier printing, view source, etc.

I am not saying you can't do things to protect images and etc, but it shouldn't overwhelmingly so replace the browser experience.

Now I do like how the display of flash, but it too much replaces the browser experience.

I wish there was a good way to convert flash to javascript vector graphics, then you can have the great interface that does not interfere with browser experiences.

http://www.walterzorn.com/jsgraphics/jsgraphics_e.htm - Interesting site about javascript vector graphics


7 comments:

  1. Anonymous2:57 AM

    Well now, let's see if we can't dissect this a little...

    'Link colors should stick to standard link colors'

    This one is hardly worth commenting on it's so obviously wrong. If you'd said links should be represented by something that the user would normally recognize as a clickable element I would probably agree, but to suggest keeping all links in their default pure blue is just plain insulting to anyone who works as a designer for a living. I don't by the way, I just happen to think many of them do a fine job of making some sites look excellent and work intuitively. It would also be remiss of me to point out that the only two links on the page where this blog entry is posted are in the blogger advert over which you have no control. Maybe a bit of practice what you preach would let you see the folly of what you're suggesting.

    On to your next point

    'The paging of back/foward should not be intefered with'

    Why not?

    Some applications do not have a reasonable concept of back and forth. They are not stories, they are complex interfaces that allow you to perform complex actions such as filtering information inline, or asynchronously view changing information such as stock market trends, or the flow patterns in a processing plant. For these sorts of applications the concept of having a back and forward button is as silly as the concept of trying to print an entire novel on a single wide tall page. Back and forward makes sense when there is a back and forward to the application. The whole need for RIAs evolved out of situations where there often isn't a back and forward. Where there are several parts of the user interface that are being updated independently of each other. Even in relatively simple applications you often don't want to allow a user to go back because if they do, they will mess up the steps in a multi-step process. You can of course code around this, but coding around it doesn't prove that it isn't a problem, only that it's a solveable one. One that is sometimes best solved by using a RIA. Of course, if you are only building HTML 'story' based sites back and forward make perfect sense.

    Next point

    'Right-click context menu's should work for easier printing, view source'

    If I want a user to be able to print the page I'll provide a link to a printable version so they can see what they are about to print rendered more or less as it will appear on a sheet of paper. At the very least I'll provide a style sheet that provides a paper friendly rendition of the page content.

    View source is probably not really high on the list of requirements for anyone other than the developer of the page, or someone who wants to learn something about how it was constructed. That is very unlikely to cover a large proportion of the user base for most applications.

    Besides, what do you get when you right-click in outlook?

    I don't remember seeing either a print or view source option last time I checked. The context menu should be doing something that is useful and related to the context of where the user is in an application if anything at all. Not forgetting that people using Apple machines won't have the faintest clue what your context menu might or might not do.

    This is effectively a moot point anyhow. Since Flash MX 2004 came out, the context menu is just as customizable as it is in any browser with the added benefit that you know exactly what will happen in any browser and have the ability to fire events and fully control the application.

    I have certainly seen plenty of bad uses of flash, but that is down to poor design decisions. It is not a fault of the underlying technology any more than a poorly written ColdFusion application is the fault of ColdFusion and HTML. The key thing is that there are good applications of many technologies including Flash. There are plenty of situations where Flash makes much more sense than HTML as a user interface, but many of those are full featured applications rather than simple page based sites. The problem up until now has been that the tools simply did not exist to create those applications because of their inherent complexity. Now that Flex and ActionScript 2 are around those applications are starting to become more approachable from a development point of view. That combined with the experience of those who toughed it out with ActionScript 1.0 and the Flash IDE should lead to a number of much better designed and more usable Flash applications because the developers and designers can concentrate more on usability and interface design and testing and less on how to get the Flash IDE and ActionScript to do what they want.

    Spike

    ReplyDelete
  2. Anonymous6:23 AM

    spike hit the nail on the head. RIA's were created because of the statelessness of HTML. I usually find it best to open RIA's in a window without a toolbar or menus, just in case the user decides to click forward/back.

    ReplyDelete
  3. Design can be great, but you have to make sure your end user will want what you have to offer..

    Too often I have seen design taken on blindly, ignoring completely that the user will have no clue what the heck this design is, or how to use it.

    I am not saying I am in charge of ugly web apps, I like them pretty as the next person.

    But the highest priority should be in this order:

    1. Functionality-Error Free and Bug Free whatever this app is supposed to do
    2. Usability-Can the average end user EASILY figure out how to take advantage of the functionality, that they can here for????
    3. Design-Make it look nice and professional of course, but it is always the last consideration, but still a very important one.

    Don't look at me like I'm anti-design, I'm looking at most but not all of designers, clients and customers who have lost the clue of who their end users are.

    It's not easy, but it takes work, and it's not like i have a magic bullet, of how exactly to make sure a page/app is usable and functional, it really depends on the work you do, in understanding who the real end user is.

    That's why RIA's suck, because they have lost touch with who their end user is, because, unless it's for some intranet, or some fancy media company, RIA's have no real practicality.

    Let me explain why.

    1. Most visitors, who have had some experience surfing the internet, build up a mental image of how things should be. Just like after years of walking the streets, we have reasonable expectations of what will be on each street and streetcorner and building.

    But what if a building was in the middle of the street, or the building had no streets or access points. I am not saying that we can't rethink things, but that we must do so carefully so that in our innovation, we aren't confusing the heck out of the end user.

    ReplyDelete
  4. I don't understand you. According to my understanding of your statements, most everything we've done over the last 5-6 years is all wrong. I'm guessing that you just LOVE html, and like using a plain text editor(not an IDE), and nice looking applications really don't matter (at least when they use the browser).

    The only reason that all this change has happened is that this is what people (customers) want. HTML is not very good for graceful UIs and seemless server interaction. That's not what is was designed for. HTML is a document presentation language that just happens to be easy to manipulate (because is is text based). It has serious limitations as an application platform. This is where Flash come into play.

    I basically disagree with just about everything you have to say--and I've been listening--so I'm not really sure what to say.

    ReplyDelete
  5. If the client is their own end user, then they can choose whatever they want.

    But most of the time they are two seperate groups of people.

    1. The client wants the fanciest interface to their x application.

    2. The customer just wants to buy x product, and since he's bought x product at quite a few other x sites, he reasonably assumes the interface should reasonably be the same.

    The problem is that flash doesn't go along with the browser interface, it supersedes it.

    Which can be fine for some application, as along as the end user can easily figure it out.

    But the biggest point is that customers don't like learning new interfaces to do what is a common every day activity.

    ReplyDelete
  6. Anonymous4:30 PM

    Regardless... Please use the word correctly. It's regardless, not irregardless. Thanks.

    ReplyDelete
  7. What did voltaire say????

    I may disagree with what you say,
    but I'll defend to the death,
    you're right to say it.
    -Voltaire 5th century philosopher

    I agree technically, irregardlessly is not a correct english term, but it so correctly invokes the imagery I want to present, since i am both front user and end user, at this time, I shall continue to use it.

    ReplyDelete