Uncategorized

Weighty Asynchronous UI Patterns

I’ve been working a *lot* on the Fedora Community project lately. I’ve been performing a very lightweight heuristic evaluation of the interface so far, and I ran into one issue that I’d like to address but I’m not 100% how to right now. The issue I’m struggling with right now been an annoyance for me on other web sites and web applications, too: how weighty is the link I’m about to click on? Is it going to cost me a full page load?

Here’s a cropped screenshot of the Fedora Planet widget in Fedora Community:

See the Read More link at the end of the post? Would you expect clicking on that link to:

  1. Take you outside of the Fedora Community application and bring you to the full blog entry page for that blog post (in this case, to Greg’s blog) in the same window. Cost: a full page load.
  2. The same as above, but in a new window/tab. Cost: a full page load.
  3. Take you to a page within Fedora Community, using Fedora Community’s UI chrome, that displays just the contents of that blog post. Cost: a full page load.
  4. Open up a lightbox overlayed on the screen with the full blog post. Cost: almost none, super-fast.
  5. Expand the bubble in-place, without requiring a page load, to display a longer excerpt or the full blog post. Cost: almost none, super-fast.

During my evaluation, I found myself naturally avoiding clicking on that ‘read more’ link because I assumed it would cost a full page load. Turns out it doesn’t… it expands the bubble in-place, and is very, very quick. But… how can users tell how weighty a click is?

There are some patterns that I’m pretty familiar with that handle similar situations:

How can you tell that clicking on a email address link in a page will (1) launch your mail client with a new compose window with pre-filled To: field (so slow! *I* hate this!) OR (2) bring you to a web form that will let you send the mail?
Add a little mail envelope icon next to the link if it’s a mailto: link. Possibly add a title attribute to the link tag to say something like “launches a compose window to send email” (less common for sure.) Looking for a screenshot of this in action, I had a hard time finding it so maybe it’s not as common as I thought. Here’s a quick mock to show what I mean:
How can you tell a given link is not going to bring you to another web page but instead prompt you to download a file? How much of a time investment will downloading that file be?
I think it’s pretty common for links to files to have at the least a parenthetical reference to the file extension, and/or how large the file is, and/or how much time in minutes it would take for a given bandwidth rate. Sometimes you’ll see an icon preceding the download link to specify the type of file (e.g., the Adobe PDF logo to specify a download link is for a PDF.)

I don’t know if either of the above type of solutions would work to distinguish between a heavy full-page load link vs. a quick / lightweight expando client-side information expansion. Looking in Jennifer Tidwell’s Designing Interfaces I noticed that she has an example on page 46 (“extras on demand”) that shows a link with a “>>” following it to show that it’s an expando type of link and not a full page load. Here’s what that would look like in the Fedora Planet widget example:

Does that look less weighty than the original screenshot? I don’t know. I’m trying to brainstorm other treatments to solve this issue. Do you know of any good resources for AJAX-y/interactive patterns like this? I did just notice that there’s an O’Reilly book in a similar vein to Tidwell’s called Designing Web Interfaces by Bill Scott and Theresa Neil. I may look this one over. I seem to be having a hard time though finding a good pattern library for this sort of thing online, although ajaxpatterns.org looks promising.

Discussion

37 thoughts on “Weighty Asynchronous UI Patterns

  1. I think you’ve identified some core annoyances that people have with website interfaces. The debate goes on and on and has linkages not just to usability and technical aspects of a browser, but also increasingly to marketing and promotion (does anybody enjoy the transparent overlay ads on YouTube?).

    I personally like the “mouseover” option that you find in a lot of software apps– gives me insight into what I might do with the link (or what it might do) without committing to clicking on it.

    At any rate, there’s a decent discussion on the “new window” topic here:
    http://www.problogger.net/archives/2007/06/26/should-links-open-in-a-new-window/

    T

    Posted by Todd | April 14, 2009, 10:31 pm
  2. Hi!

    I’d say that putting a “>>” after is a good start, however, this has also been corrupted by general use on the internet where clicking a link like that often causes a full page refresh.

    From a brief mental workout, the key one that I can think of almost never means jumping to a new page is is a down arrow. I mean the type seen on a combo box usually. Of course, this then runs into the confusion that perhaps readers will think this offers a menu of some sort…

    One other possibility is to reword it. Don’t make the link “read more”, which generally means go to a new page… instead, make it a nice soft button, with a name like “page down” or similar perhaps..?

    Posted by Philip Peitsch | April 14, 2009, 11:07 pm
  3. Just to add some more justification to the previous statement, a horizontal arrow usually means to me that the link is a jump to a new place. A down arrow however means that the jump is contained in-page somehow… e.g, a link to an internal bookmark or similar.

    Posted by Philip Peitsch | April 14, 2009, 11:08 pm
  4. I think I would expect the following:

    “Read more” followed by a downward facing arrow icon: expand the bubble/frame.

    “Read more” followed by “>>”: go to its own page for that article and comments on the same site, same look and feel.

    “Read more” followed by a little box and arrow icon (like on the Ajax page you referenced): go to a new page off-site.

    “Read more” by itself: no idea. :)

    Posted by Mike | April 14, 2009, 11:12 pm
  5. Not sure if a real user would be thinking in terms of expense or anything, especially if she or he needs to perform a task. Like – if the excerpt caught my interest, i don’t care in which form it comes, i’d click it.

    As for the emails – if that would be a web form, having full email address just makes no sense if you are offering web form. I mean – if it is over the web, you don’t care about coordinates, do you? So, whenever i click on email address, i expect it to be forwarded to my mail application.

    About your original bubble widget thingy question – i think it could be solved using alternative wording – how about using a verb that describes the interaction with the link instead of wishful thinking on action. How about, “Expand” (if it expands) or “Jump to blog” (if it does that) – in other words, i’d suggest to disambiguate.

    Lastly – i think your questions do not have much to do with AJAX or web design particularly.
    It’s just general user experience. Don’t have any particular books in mind though.

    Posted by Toms | April 14, 2009, 11:42 pm
  6. For me changing “read more” to “expand [+]” indicates that it is going to not refresh on the page. Maybe even “expand to read more [+]” if you want to get more obvious.

    Posted by Kevin Breit | April 14, 2009, 11:49 pm
  7. I think that the ‘>>’ makes the link feel a less weighty, and sort of implies that the bubble will expand. Let me know if you want make that change; it should only require tweaking the arguments to our jquery.truncate usage.

    One thing that is quite common in the desktop world is appending menu items with ‘…’ to denote that clicking it will open a new window. Maybe we need to bring this pattern to the web to imply that a link will cause a full page load?

    Posted by Luke | April 15, 2009, 12:05 am
  8. hmm to me it seems like if its going to drop down with the rest of the post, it might be better as something like

    expand for more +

    just a suggestion :D

    Posted by sulfide | April 15, 2009, 12:13 am
  9. Some things that might help:
    - Use “show more” instead of “read more” – it implies that it will be shown right here.
    - Have an explicit link for the off-site page – this will imply that the other link must be local somehow.
    - You can use small icons to represent pages that will open in new windows, like a box shape with a “new” star-shiny-lens-flare-kind of thing, or one box on top of another one.
    - The direction of an arrow is important. A “show more by filling this box downwards” might be best represented by a down arrow, and a “go to separate page” might be best represented by an arrow to the right (for users accustomed to the forward/back kind of idea – I assume users with LTR languages have also become accustomed with this convention).

    Posted by codebeard | April 15, 2009, 12:43 am
  10. Wouldn’t it look less threatening if it read “expand” instead of “read more” ? Or maybe just the “expand concept” in form of an icon similar to those used to represent the full screen action in media players …

    Posted by simo | April 15, 2009, 12:45 am
  11. The >> definitely helps for me as it gives the same sort of happy feeling that disclosure triangles do. But I’m likely off in a case that’s far from the normal web user there.

    Posted by Jeremy Katz | April 15, 2009, 12:58 am
  12. I would suggest an arrow pointing down. Arrows to the right often seem to mean a full page load (e.g. lifehacker.com or the Wikipedia external link icon).

    Posted by michael_nz | April 15, 2009, 1:04 am
  13. I’ve found that I do two things to emeliorate the effects of full page loads:

    1. Open links in new tabs (middle click the links), and continue reading the current document while the new document loads.

    This effectively side-steps the full page load problem, as it’s happening while I’m paying attention to something else.

    2. Have the statusbar visible, and glance at the url that the link refers to. If it’s full of JavaScript, it’s possibly a “fast” link (and won’t load into a new tab anyway), so I’ll directly click on it.

    This will also often tell me if it’s a PDF/etc. file and not HTML (yay file extensions), or a mailto: link, etc.

    Still, these two solutions aren’t perfect; I’ll often neglect (2) and always use (1), then find out that the new tabs are empty (as the link was JavaScript), or the URL is non-sensical.

    Also, I believe that links should _never_ specify that they open in a new tab/window/etc. I already have the means at my disposal to open in a new tab/window; if I want them in a new tab/window, I will do so. It’s *really* annoying when they open new windows and I don’t notice (e.g. because my browser is maximized, and the new window appears underneath my current window, so I never see it, and reclick the link…multiple times…until I have ~20 new windows. Grr….).

    Posted by Jonathan Pryor | April 15, 2009, 1:14 am
  14. That’s the work I’ve long been a fan of you doing. In case you ever wondered. Keep it up, because it matters way more than you’ll ever get credit for.

    But I’m sure you know that.

    Posted by Marland Pittman | April 15, 2009, 4:19 am
  15. I think the “plus on a square” sign if often associated with expanding sections. On GNOME, there is the spinning triangle that expands directories and such. Either one could work as a way of conveying a lightweight bubble-in-place as you said.

    Posted by Rafael | April 15, 2009, 5:45 am
  16. A little symbol that represents something will unfold is really common! That is the + expand button or > (triangle) thing that expands/hides stuff in both web UI’s and in Gnome. That is what they should be using in the site you refer to also otherwise it is definitely unclear. If there is an expand thing (I don’t know whether to call it an icon or button or what since it really isn’t either) then it is very clear that it will expand in place with lost cost. If it does a full reload or opens a whole new window then *that* is a UI bug.

    Posted by foo | April 15, 2009, 6:15 am
  17. Instead of “read more” you could just use the existing buzzword everyone understands “expand” so in your second mockup you could just have “expand rest of comment >>” instead of “read more” which doesn’t paint a very definitive picture of what to expect.

    Posted by foo | April 15, 2009, 6:17 am
  18. Perhaps just changing “Read More” into “Expand…” ?

    Posted by Søren Hauberg | April 15, 2009, 6:22 am
  19. I would suggest a down arrow ⱽ, and maybe the words ‘expand’ or ‘show more’ instead of ‘read more’.

    Your example with >> doesn’t do it for me, I am still confused whether it will open a new window or just show the missing text.

    Posted by a | April 15, 2009, 6:39 am
  20. Hey,

    I would write something like “expand” because anytime I read this (actually: “aufklappen” in German) I would assume that it just expands in a ajaxish way. Otherwise I usually click on “open in new tab” because I want to avoid that I loose focus of the current page.

    By the way, I like your work and allways enjoy your posts!

    Posted by Christoph | April 15, 2009, 6:43 am
  21. I guess I am an old-fart with a pre-”web 2.0″ style of thinking, completely different from yours… I rely on the status bar to provide much of this info and I am unhappy then it fails to (mostly due to JavaScript implemented links).

    For the “Read More” the case I hate the most then I right click and use “open in new tab” just to end with an empty new tab with a JavaScript command as URL.
    I hate the lightboxes(4) and want the new page to open when and where I want(1). This is why I also hate the case (2), forced new pages.
    For case (3), page within the same chrome, I am unhappy just a bit: it needs an additional click and two full page loads *if* I want to get to the original page to leave a comment or something like that (important use case for Planet posts).
    For me (5) is about as bad as (4), so my choice is an solid old-styled (1).

    For email links I also rely on the status bar to tell me if the link is an email or a contact form and prefer opening the compose window of my mail client (1), is fast enough as the application is always open, does not chance the content of my bowser window and the most important, after sending the mail I have it archived in the “Sent” folder, I have the address automatically added to the address book and everything is traceable, in the case of a follow-up I have the entire conversation for reference. Ah, and there are additional benefits: the mail client will auto-complete my name, my sender address and the signature.

    Posted by Nicu | April 15, 2009, 7:18 am
  22. @Nicu

    “For the “Read More” the case I hate the most then I right click and use “open in new tab” just to end with an empty new tab with a JavaScript command as URL.”

    Full Ack! I totally hate that, too. That’s why it is so important to name the link to something that makes it clear that I don’t have to open it in a new tab. Its ok to click on it as long that I know, that it will open in an ajaxish way and won’t move my current location. Especially for example, if you are currently entering text into a form and then just suddenly get interupted by something interesting you read which has that “read more”.

    Posted by Christoph | April 15, 2009, 7:25 am
  23. perhaps you should rename ‘read more’ to ‘expand’. no one would expect to open a new window or tab then.

    Posted by k.l. | April 15, 2009, 7:48 am
  24. To me, a link with just “>>” (i.e. no “read more”) would indeed look more lightweight than “read more”.

    Posted by . | April 15, 2009, 8:21 am
  25. Some thoughts on the specific UI problem you mentioned:

    I’d expect a simple “read more” link to open the original blog post on a separate site. That’s what I’m used to when reading aggregate blogs, and is also usually the default action with links on news sites. Maybe this will continue to be the default action as the full article is often too long and can contain images or formatting or something else which would make it difficult to display in a smaller feed box.

    Anyway, I would use an arrow (or triangle, or something) pointing downwards to show that the bubble will expand (down). This is what Facebook does for long comments in a thread.

    I think the “>>” sign could mean anything. As the web in general evolves (to more web-2.0-like), the users might start thinking that an extra graphical hint like that indicates a link to a separate page.

    Posted by Matti K. | April 15, 2009, 9:18 am
  26. To me a “>>” indicates that it’s going to send me to a new page, i.e. full page reload.

    How about renaming the link to “Expand”?

    Posted by Hongli Lai | April 15, 2009, 10:52 am
  27. Just like Nicu, I like to be able to open the link in the current tab or in a new tab if I want (so no javascript, just a real link)

    Also, this particular case is about reading articles from community members, on their blog. And one of the feature of blogging is that the reader can interact with the writer by writing comments. So a link to read the post should really point directly to the article on the writer’s blog, so that the reader can let a comment right away and not click again and load another page.

    However, it can be nice to simply read quickly the article.

    Maybe we could imagine the following:
    - one “read more in place” link to have the article fully displayed in an expanded bubble (5)
    - one “read the original article” link (maybe on the title of the article ?) to go directly to the writer’s blog (1)

    I have a strong preference for (1), but having a (5) can be a nice bonus (and please, no (4), that thing can sometimes take a long time to load only for the animation, when the text would be much faster to display).

    About (2), are you speaking about using something like target=”_blank” ? If so, that’s just an awful way of doing things. Let the reader choose if he wants to open in a new window / tab. If you were talking about something else, well, I’m sorry I misunderstood :)

    Posted by bochecha | April 15, 2009, 12:18 pm
  28. @Toms: I was in a rush writing this post (had to catch the bus home) so you point out a mistake I made and have since corrected – I meant to say that if there is an envelope icon, I’ve found that it commonly signals a mailto: link, and if there is no envelope icon, it usually means you’ll get a web form to send the message. Thanks for pointing this out!

    Posted by mairin | April 15, 2009, 1:45 pm
  29. @Marland Pittman: what a nice thing to say! Thank you so much!

    Posted by mairin | April 15, 2009, 2:48 pm
  30. @codebeard: great summary, thanks!

    Posted by mairin | April 15, 2009, 2:50 pm
  31. @Jonathan Pryor: I get annoyed about the javascript links in the same way. my middle-click behavior is the same as yours. And usually I’m too lazy to check out the status bar, so I’ll end up with a bunch of empty tabs that were javascript thingys :)

    Posted by mairin | April 15, 2009, 2:51 pm
  32. @nicu & @Christoph: I get burned by javascript links that look like real links too! and I get a ton of empty new tabs because of it. I think maybe we could offer both (and we do, the title of the post in the screenshot takes you to the full post, it is only the ‘read more’ link that expands in-place) and it could be a good compromise. the main problem here i think though are javsacript links that look like real links, i think by default people assume a link is a real link, so if it is javascript it needs to be identified as such.

    Posted by mairin | April 15, 2009, 3:03 pm
  33. @bochecha: thanks for the thoughtful comments! I agree with your assessment – and by #2 i did mean target=”_new” but I HATE HATE HATE when sites do that. Some still do though so that’s why I listed it as a possibility.

    Posted by mairin | April 15, 2009, 3:05 pm
  34. @Toms: I missed this point:

    i think your questions do not have much to do with AJAX or web design particularly.

    They actually do. With the introduction of AJAX in web applications, there are new possibilities for link behavior that didn’t exist before. They don’t need to be AJAX particularly, they could just be javascript, but either way it’s the rise of AJAX that has really caused this conundrum, I think.

    I think web application and rich client applications, while they obviously deal with similar user situations and patterns, still have different limitations and possibilities and should be treated separately. I can’t stand web apps that look and behave just like rich client apps… the web is a different medium and I personally feel it should be respected as such.

    Posted by mairin | April 15, 2009, 3:09 pm

Trackbacks/Pingbacks

  1. Pingback: Patterns for Expressing Expansion Link Weights in Web Applications « mairin - April 15, 2009

  2. Pingback: More Link Treatments « mairin - April 16, 2009

  3. Pingback: No more paintain. « mairin - June 11, 2009

Follow

Get every new post delivered to your Inbox.

Join 58 other followers

%d bloggers like this: