Search

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?

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

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.

The same as above, but in a new window/tab. Cost: a full page load.

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.

Open up a lightbox overlayed on the screen with the full blog post. Cost: almost none, super-fast.

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.

Rate this:

Share this:

Like this:

LikeLoading...

Related

About Máirín Duffy

Máirín is a principal interaction designer at Red Hat. She is passionate about software freedom and free & open source tools, particularly in the creative domain: her favorite application is Inkscape. You can read more from Máirín on her blog at blog.linuxgrrl.com.

Discussion

37 thoughts on “Weighty Asynchronous UI Patterns”

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.

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..?

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.

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.

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?

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).

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 …

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….).

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.

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.

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.

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.

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.

“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”.

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.

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 🙂

@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!

@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 🙂

@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.

@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.

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.