The Accidental Developer » User Interface

University of Michigan jobs site has major browser compatibility issues

Chris Herdt — Thu, 30 Jul 2009 16:05:29 +0000

At the risk of sounding like a one-note, I would like to again talk about browser compatibility issues. These compatibility issues affect an organization’s bottom line, and should not be ignored. In this particular case, The University of Michigan’s (U-M) job web site is unusable to about 10-15% of visitors, by my estimates (they are using Google Analytics on the page, so they should have that data). To me, this says that U-M may be missing out on some of the most qualified candidates for their position openings, undeniably at great cost to the organization. [I am particularly concerned in this case because U-M is my alma mater.]

In particular, the browsers that are not compatible with the U-M jobs site are Safari, Chrome, and Opera — browsers typically used by more tech-savvy users — so U-M may be missing out on the very candidates best-suited for work in today’s web-based world.

The first thing to note is the warning on the interstitial page, the page between the user and the content:
“Supported browsers are: Windows 2000 and XP – Internet Explorer version 7.0. MAC OSX – Safari versions 1 and 2. (Safari 3.0 for Mac is not supported).”

It’s in small type and can easily be overlooked by a focus-driven person who is here to look for jobs postings, not browser recommendations. Not that I think there is any excuse for not supporting all major, modern browsers, but this page could at least include a browser-detection script that would alert users of unsupported browsers in a prominent manner. It might as well also mention that Javascript needs to be enabled. No matter, though, because the next click will let Safari, Chrome, and Opera users know in bold black text on a plain white background:

// Start Req. No 3294 Bug No 21869,21870 This site is designed to work with Microsoft Internet Explorer (versions 5.5, 6.0, 7.0), Netscape (versions 7.0, 7.1) and Mozilla (version 1.7) Web browsers installed with the Microsoft Windows operating system, and Safari (version 1.2) Web browser installed with the Mac operating system. The browser and/or operating system that you are using to access this site is not currently supported. Please access this site from a device with a supported browser and operating system combination. // End Req. No 3294 Bug No 21869,21870

Friendly, isn’t it? It looks more like a browser error than a message from the U-M jobs site. A lot of people might see “Bug No 21869,21870″ and assume the site is temporarily down.

Job searchers are a persistent bunch, though, and presumably many of them will read through the error message and decide to revisit the site in Internet Explorer. Mac users may have a harder time following the recommendation, as Apple likes to push out Safari updates. You can download old versions of Safari, but that’s not something we can expect every job searcher to do, much less be aware of.

Once you do get to the jobs search page in (in Internet Explorer or Firefox), you get a frameset consisting of 5 frames, none of which have titles (from Creating Accessible Frames: “One of the most important things you can do to increase the accessibility of frames is to give each frame a title.”). The links on the footer frame, such as the link to the non-descrimination statement, do not have a target attribute set to “_top” and therefore open in the same frame, one line of text high.

In my recent post about T-Mobile, the cost of browser incompatibility was expensive and avoidable phone calls to customer services. Here, the cost is arguably even higher: missing out on the best job candidates. That might be more difficult to pin a dollar amount to, but if I were U-M I would be worried–and I would fix it.

Edit:
I e-mailed U-M about these issues and received the following in their response: “There are no plans to upgrade this until the system is replaced in June of 2010.” Although that’s nearly a year away, I’m glad to know that they are planning to replace it.

Javascript textarea counter

Chris Herdt — Sat, 15 Nov 2008 19:33:26 +0000

I’ve been thinking more about the textarea counter issue that I mentioned in my previous post (“Users Paste Differently“).

First of all, I noticed that some of the textarea counter scripts date back to at least 2000, so this has been a problem that developers have been looking to solve for 8 years. I checked the HTML 5 specification and found that in HTML 5, the textarea element has a maxlength attribute. Presumably user agents will build in the most elegant solution.

But what is the current most elegant solution?
I checked a couple sites that I know use textarea counters well: Delicious and Twitter.

Delicious

Textarea counters on Delicious.com

Twitter

Textarea counters on Twitter.com

I like how prominent the character count is in Twitter, although perhaps too terse, but if Javascript is disabled it displays nothing at all. On the other hand, in Delicious displays “1000 characters max” if Javascript is off (instead of “1000 characters left”), which is still useful information. (I would avoid using the abbreviation max, though, and use maximum or limit instead, which might be better understood by those for whom English is a second language.)

I like Twitter’s “warning track” that lets the user know they need to keep it concise and wrap it up, although I find it confusing that they used bright red to denote both the “dangerously close to” as well as “over” the limit. The positive bright red numbers could easily be misconstrued as over the limit, since red is a color we frequently use to denote errors.

Twitter’s counter responds to onBlur and onChange, whereas the counter in Delicious is triggered by neither.

Both get one thing right that I think most other textarea counters get wrong: they don’t truncate the user’s text. Deleting something that the user has typed (or pasted) is definitely a bad idea for at least two reasons: the user may not realize the input was truncated and may submit incomplete info, and that the user, upon discovering that the input requires editing, may choose to cut text from someplace other than the end. Instead, both versions alert the user that they are over the limit and provide information on how many characters need to be cut to stay within the limit.

(As an aside, one thing I find curious is that both count an Enter keystroke as one character. I’ve run into issues with this before because a line break on a Windows-based system should insert 2 ASCII characters: a Carriage Return (CR) and a Line Feed (LF). *nix systems, including OS X, will insert a Line Feed (LF). However, I haven’t been able to reproduce this issue with recent testing. If it is still an issue, I imagine they handle this on the back-end by converting the CRLF to LF before inserting it into the database?)

In short, my recommendations are:

Don’t truncate the user’s input; let the user correct it
Let the user know how far over the limit he or she is
Provide guidelines even if Javascript is disabled
onBlur and onChange should also trigger the counter, in case the user is pasting text
Keep the counter message simple and clear

Another idea I had for a visual counter:

Counter - characters remaining

Aside from turning red once past the limit, though I’m not sure how it would visually convey to the user by how much the text exceeds the limits.

How can a counter be implemented programatically?
I would like to set something up so that the appropriate event handlers are attached to textarea elements automatically. I found a jQuery plugin, Char Limit, but in addition to not meeting the recommendations I made above, I don’t like how the developer has to specify the character limit in the Javascript (and apply the same limit for all textarea elements).

I think a clever, although imperfect, solution would be to have jQuery (or any Javascript of your choice) turn any static character limit messages (like the one that Delicious provides if Javascript is disabled) into dynamic character counters. For example, with the following code, the Javascript could find any elements with id attributes matching *_counter, take the numeric part as the limit, and build a character counter:

300 characters maximum

It’s problematic for several reasons: another element on the page could have an id that matches *_counter, the non-Javascript message could contain more than one numeric part, and the developers would have be consistent in naming the textareas and accompanying divs. But I think it is in many ways an improvement over the inline Javascript I’ve seen in some oft-used solutions.

UI Complaint: submit buttons above the form content

Chris Herdt — Mon, 14 Apr 2008 17:39:36 +0000

I have seen numerous instances lately where a web application requires the user to look above the form or content to instigate the next step.

Examples:

On bordersstores.com, a 6-page list of books has the navigation at the top (and only at the top). After you scroll through the 25 items on the page, you have to scroll back up to the top to access the links to the other pages:

Hint: the links should be both above and below the content.
On Wharton’s webCafé, the “OK” button is located above the login form on a toolbar with a different background color:
Hint: it should be underneath the login form, and it should be labeled “Sign In” instead of “OK”.
In Microsoft’s Windows Live, the “save” button is placed above the form in a toolbar with a different background color:
Hint: put the button below the form. (At least the button is labeled appropriately.)

In the latter 2 cases, one could argue that the button placement is similar to what a user would expect to find in a desktop application, such as Microsoft Word. But it isn’t a desktop application: it’s a web app, and users expect to find form/page actions at the bottom of the form.

You could also argue, in the last case, that the user may want to make a quick edit to the name information without editing all the details. Therefore, it is more convenient to put the “Save” button at the top. That’s fine, but why not offer 2 “Save” buttons, and put one in the spot where user’s most expect it?

User Interface Issues

giblfiz — Tue, 08 Apr 2008 17:50:55 +0000

I just recently finished up some pretty cool feature adds to a lightweight CMS that I have built for a client. (they are happy and impressed with it, and It looks like I’m going to pick up another two jobs, where all I need to do is install the code I have written. Yey! I have been trying to get to that point for quite some time now)

One of the major reasons behind the feature upgrade was to fix some huge User Interface problems with “list management”, and they are fixed, but of course now that I’m playing with it, I have discovered that the new UI has some big issues as well. In particular, administrators now see the list exactly as it normally would be, but there are a few links next to each item that allow you to edit it, delete it, or move it up or down. It’s neat but the extra text very much breaks up the visual flow of the list in a lot of cases, and in one case is actually pretty darned hard to access.

One of the core concepts behind the CMS is that when you are logged in as an admin, you can always navigate the site as normal, and edit things from the place where you see them, so getting this right is actually something that I think of as core functionality. It’s also worth mentioning that a good UI is generally much more valuable than good code. (though you get a good UI through testing, and iterative changes, and if you have bad code that becomes much harder)

At the moment, I’m thinking that I will try putting a tiny [chng] div where I have the options listed, and then have that create a pop-up box with the actual link options in it. I’m sure that will have its own drawbacks though.