Tag: ui

If you’re in higher ed web development, you probably saw this article making the rounds criticizing university web sites. Melonie Fullick put this together along with the feedback of other Twitter users after trying to research some information from various sites. I, too, recently had some complaints doing some research on programs at institutions and finding it infuriating at times trying to get relatively simple information. I’ve talked with a couple folks about the article as well, and thought I’d give some additional commentary. Not necessarily counterpoint, or refutations, just an additional viewpoint as someone who spent years behind that curtain. Read More

On its face, Filtrify is just another jQuery plugin that you can use for atomic control of a collection of DOM elements. Which is cool enough I suppose. But check out this example on their demo site. Now, instead of movies, imagine it’s student action photos from different programs, or some other visual representation of the program. Instead of genres and actors and directors as filters, you have schools and interests and jobs. It would leave you with an interactive program listing that invites a user in to play and explore. In this particular case, Filtrify is serving as an extension of the live filter design pattern – enabling a user to see all the available options, and then selectively removing that which isn’t relevant to them. People like toys, and they are inherently curious. Create an environment that promises an opportunity for exploration, and you’ll net some explorers.

But wait, it doesn’t have to be Filtrify per se, either – that’s just one idea. Something likefiltering blocks would work just as well. As would something you come up with entirely on your own. The trick is, you need to start rethinking the UX of the program listing (and probably a lot of other stuff on your sites, too), and really consider how your tools may be impacting prospective students’ ability to see you as the right institution for them. Jakob Nielsen pointed out how bad lists could be nearly a decade ago (see #7), yet schools seem to be married to them for lack of the desire to construct a better way. People don’t find long, unfilterable lists to be user-friendly at all. We already know that 17% of students will drop a school from their list if they can’t find what they want on your site. Even more will mark a school down if they have a bad experience. What is that risk worth?

The underlying issue here is that schools need to start putting more effort into the next step of their web design processes, and start looking at the user experience of what they are making. It’s easy and fast to slap stuff together and move on, but there is enormous value in usability testing. It’s part of the overall process that is too frequently skipped, since a webpage published is frequently seen as “good enough.” While the old fashioned linked list may be functionally adequate for the data being displayed, it’s a terrible way to encourage interaction and leave a good impression on your visitor.

Even if you didn’t want to use a library like Filtrify, you can still come at the problem of filtering content in a user friendly way by falling back on some basic principles like LATCH. LATCH is a content filtering methodology that most users are, consciously or not, readily able to adapt to. That makes it a great place to start when trying to solve the problem of helping people find what they need in any large archive of structured information.

So how could we apply LATCH to a set of link filters for our program listings? Here’s one example (and there are plenty others):

Location: This could be a physical campus location, online programs, or a more meta concept like a college or school.

Alphabetical: This pretty much goes without saying. But keep in mind your taxonomy might not be the same as the visitors. Don’t be afraid to overload topics and point them to the same overall detail page.

Time: This one can be harder, but could be length of the overall program, number of credit hours, or number of total semesters.

Category: Think generalized subject or job areas here. For instance, “teaching” will likely return a number of different specializations.

Hierarchy: You could use this to break down by schools and departments, or requirements, or to set up graduate tracks

The insane part about all this is that in many cases it would only take a little work to make fairly significant usability improvements over the current lists of programs. Something as basic as a live search filter would provide users with at least a little empowerment over the current model for many schools. Empowered users will be engaged users. And it’s much easier to get an engaged user to fill out an application. And on the other hand, if the technology you’re employing on your website doesn’t instill them with faith in you to be modern and student-centric, then they’ll move on.

Majors, minors, and programs are just one of many examples that could benefit from a little of this kind of TLC. I mention it as the focus of this post mainly because it tends to be really high in the funnel though. But how about:

Student organizations

Offices and departments

Faculty listings

Events

Courses

How many things could you improve with just a few hours work, and a little focus on the overall UX of the content you are trying to present? Which do you think your visitors would get better use out of? Are you particularly proud of your program listing page? Share it in the comments below for others to see. And if anyone actually does build a site based on Filtrify, let me know, I’d love to see how it turns out!

Did you by chance read User Interface Engineering’s article “Design Cop-out #2: Breadcrumbs?” I’ll admit that I am a little bit late getting back around to this topic, which I originally read sometime back in… oh… August? October? Regardless, right after reading it I knew that I needed to offer a counterpoint, because while not completely incorrect, I felt that the original author was not entirely even handed with the topic, and in some cases sort of dropped the ball.

Here’s the recap/summary of the original article linked above: Crumb trails, like many things, are a tool. You use them like a localized site map, helping to expose your site’s information architecture to the user in a useful manner. Creation of a crumb trail is not a good use of time, however, because they take resources to create. These resources could be better used determining WHY a user needed to use it in the first place. In other words, they either aren’t really needed, or are a symptom of a larger problem. When they aren’t needed, time isn’t really taken to craft them “right” or “well,” and if people are using them a lot, then you have to wonder why your site is designed so poorly that they are so necessary. That was the basic point of the article, and in some ways, it is a good point. In most other ways… not so much.

“So, Michael,” you might be asking yourself, “what do you disagree with then?” Well steady reader, I’m so glad you asked me that! The thing is, I agree with them that you should pay attention to their usage, and if a lot of people are turning to them, you might take some time to ask “why?” But, the answers can be many: maybe they are awesome useful, for example. That’s possible. Maybe they don’t get used at all, except by a few people, but if those few people use them, I’ll lay money that if you removed them, you’d hear about it fast. This is a similar case to the idea of a “quick links” drop down menu on a home page. I HATE these and feel that if there’s one tool that qualifies as a cop-out, that’s one, because it’s just a link dumping ground. But when we removed it during our redesign, my how we heard about it. Ceaselessly. And still are. You could also think of it like an A-Z index. It amazes me how many people I work with who will turn to it before anything else to go places on the site. As the original author mentions though, I live in the IA of our site, the users don’t. What they will do however, is find a tool that works, and stick to it. These types of navigational tools are secondary aids, and what people tend to do is use them in cases where it gets them where they want to go. Many times, they will mix and match. It’s rather fun to watch them do live, while you stand there behind them pulling your hair out as they butcher what you thought was a smooth, flowing information architecture. Not that it isn’t still nice, it’s just that users will find a way that they think works best, and even if you show them a faster, simpler way, a lot of people don’t like it because it is both different, and not something they did on their own.

Crumb trails are just such a tool. The fact of the matter is, if 11% of your users are hitting them (as Jared mentions in that original article), it’s because they are a useful tool. To them. The original author goes on to mention this:

“The idea behind how breadcrumbs should be used is simple: the user ignores them until they get to a page that isn’t quite what they wanted. They discover the trail of links and click on the one most likely to contain the correct path to what they were originally seeking.”

Which I think is patently incorrect. A user doesn’t necessarily click on a bread crumb because they think it will take them somewhere better or put them on a correct path, nor is there any reason to believe they are used only by lost visitors in the first place. They click them so that they can surface up in a web site and potentially begin navigating anew. It’s almost like zooming out on a picture. Maybe they’ll look for the same thing somewhere else, or maybe they want more information on a related subject that is in that same basic branch of the site, and then again maybe they want to surface quickly to look for something new all together. I will agree that they might use it to take a new path, but the purpose and destination could ultimately be entirely different. Assuming you have taken the slightest modicum of care with building bread crumbs, users will recognize them as a reflection of the hierarchy of your site’s information architecture, making them a tool that users have no reason to ignore if they are viewed as an aid to going where they want to go. Using the previous example, it’d be like saying users ignore an A-Z index until they simply have no other recourse than to look there for something. Theoretically that might be true, but in practice, there are a lot of people that view such a page as their primary navigational element (even though to us, technically speaking, it’s secondary). Unfortunately in analytics, we can’t really measure intention or perception. In the index case though, it’s our 7th most visited page, with 60% of entrances coming straight from the home page, and the top 10 pages from there being things that are not hard to find. The end conclusion then is that there’s no reason to believe this generic navigational tool is a cop-out. (note: I wish I had stats on our crumb trail to share, but unfortunately I do not, at this time. I’d love to see stats from others though, either for or against this opinion.)

“Many users don’t recognized them and, therefore, don’t take advantage of them. They may recognize them, but become confused because the elements in a location breadcrumb doesn’t represent any path the user thinks they’ve traversed.”

This is another statement that sort of sits sideways with me. I don’t know whether it is true or false, but the author doesn’t give any kind of research to back it up, leading me to believe that he might think this is true, but doesn’t actually know it. I’m probably hardly one to criticize that, because I do the same thing, but to say most users don’t recognize them and therefore don’t take advantage of them is a pretty bold statement, especially when early in the article he directly references some informal statistics claiming that 11% of users are clicking them. That’s certainly a big enough group for me to pay attention. I admit that I’ve done no usability testing on crumb trails, but my lack of testing is not something I’d use as a basis of discounting the feature. Lucky for me, others have. Further, analytics certainly can’t tell you a user’s opinion on the tool, and if that idea came from a usability study, I would like to read it. On the contrary side, I highly recommend Jakob Nielsen’s article “Breadcrumb Navigation Increasingly Useful” from last year which lays this matter out far better than I could hope to.

“We’re recommending that when teams see users needing breadcrumbs, they look for other holistic design solutions. They’ll need to watch users and see the circumstances leading up to how the need arises. In almost all cases, they’ll find a better way to solve the problem than traditional breadcrumbs.”

Here I will switch case and agree with him. If your users need bread crumbs to navigate your site, I think you have some design/layout and information architecture issues to address. The key to successful bread crumbs is that they should be a secondary navigational tool. But, I would argue that people don’t use them because they need them, they use them because they see them as a means to get to where they want to go. As far as the user is concerned, that might be a quick link, an A to Z index, a menu, or a bread crumb (and all of these, minus menus, are generally secondary tools). The thing is most users neither know these terms nor care about them. All they care about is “I click here and go where I want.” I agree with Jared that given perfect IA, smart menus, and intelligent visitors, bread crumbs are a waste of time. In reality, few people run sites that function in such a static bubble that one person has control over every facet of how information is disseminated. This goes triple true in higher ed, when we’re lucky people can even put the right information anywhere, and you’re relying on 100 different people to do it all. It’s like saying “In a perfect country, we wouldn’t need laws to punish robbers, because no one would steal from each other.” The reality is, people do steal. That doesn’t mean we shouldn’t strive to stop them, and shouldn’t minimize the problem, but you still must address the issue. So what do we do? We create a ton of secondary navigational elements, build them nicely into our layout, and let the user decide how they want to combine them to go where they need.

This is why the last thing I believe a crumb trail is, is a cop-out. Frankly, I think it’s our duty to give visitors as many tools as we can to find their way around the site. To say a crumb trail is hard to “get right” kind of dumbfounds me. There are only a few ways to do them, and none of them are particularly “wrong.” The original author never even gives you an example of what a “bad” crumb trail is. Admittedly, not every site needs a crumb trail, but certainly in higher education where we deal with sites that have tens of thousands of pages, the more paths we give to find information, the better. Things like microsites, portfolio sites, or any sites that serve fairly singular purposes don’t really need them, otherwise, slap that puppy on there. All we’re talking about is one line of text, basically, and any design worth their salt can find room for that in a layout. Does it need a top level featuring? Heck no. Maybe it ends up falling to the bottom of the page, almost an afterthought, but it’s there for the people that want it. Just remember to keep things consistent, and meet users’ expectations.

Here’s an analogy: Say I have a paint can. One could argue that the right way to use it is to run it through a paint shaker, and then use a paint can opener on it. Sometimes though, it’s just faster, easier, and more convenient to shake the crap out of it myself and use a screwdriver to open it. Is that the perfect solution? Nope, but I always get the can open, and it’s no worse for the wear. Crumb trails are the same thing. They might not be the most perfect, elegant way to get around the site, but there are a lot of times where it’s a tool that can just as easily get the job done.

On a more minor note, it’s worth mentioning that good bread crumb trails can also be an SEO boost for pages that use them, which never hurts the ol’ analytics. Bread crumbs can also help users develop a mental map of the site and view it in a hierarchal manner. Both of these can help boost a user’s perception of your site. If they see your pages higher in search results, obviously that helps credibility (not to mention the accuracy of the results, if you’re using keywords in the crumb trail). If users mentally understand the setup and organization of your site, it will improve their opinion of the site’s usability, and also aid them when searching in the future. Ultimately, the usability should be the primary concern for a crumb trail, but these are nice side effects to weigh as well.

What are the takeaways from this, in my opinion?

Not every site needs a crumb trail

Crumb trails are simple to implement

Crumb trails are hard to “do wrong”

Usage of crumb trails does not necessarily imply a problem in site architecture

There are a lot of reasons we should use crumb trails on higher ed sites

Crumb trails are not a “cop-out,” they are just one more in a list of ways to get around a site