Llarc

PART I

Media sites - they are beasts. From an IA perspective they run so deep, with a breath of content, partner sites, parent sites, ad space requirements, related links, tools….exhale…just to mention a few. Navigation and visibility of where you are is incredibly important on sites like this. I’m referring of course to news sites - Globe and Mail, The Star, CBC News, New York Times, Huffington Post, etc etc. 

In my opinion, one of the worst Canadian news sites is The Toronto Star. I decided to start documenting some of the issues I have with it in a sort of ongoing journal series - call this part 1. I’ve captured my first set of screenshots below, with commentary. 

Global Navigation

• 4 visually different styles of navigation that seemly have no connection to each other on first glance. It took a while to for me to figure out that level 1 and 3 are connected (what?)
• Is ‘Autos’ a navigation item? It doesn’t look like ‘Blogs’ but is on the same navigational element. Is there a reason for this and will the user know?
• 2nd level navigation - is this related to the top navigation? (it’s not), am I on ‘Hot Topics’? It looks like it’s an onstate.
• 3rd level of navigation - Is this a breadcrumb? If so why does it show links past the page I am on, are they related? This actually seems to be a combination of a breadcrumb and internal page navigation (sub nav for category)

I am not sure you can make it out in the above, but on the homepage there is no separation of categories (news types). Labels are there, but there is no clear order or hierarchy to the content. With a long scrolling page such as this one, visually separating or arranging content by type/category is necessary so a user can quickly identify what they are interested in. Some may argue this is an exploratory approach? Personally I find it confusing, and it leaves me feeling that I am without direction.

Most Popular Right rail widget

Is content filtered for today, this week, this month? The widget filter defaults to ‘today’, however the highlight is so faint that you can’t easily recognize it’s onstate. What complicated the issue even more, is that on Chrome, clicking on any filter resulted in no response from the site. 

Orphan Pages

It may just be me - but I really hate orphan pages. This page can be accessed by a banner ad on the homepage, but now that I am on the page, I don’t know what section I am in. Clearly this page of content does not have a home - poor little guy….he just wants a roof to live under!

For the record, a site of this magnitude would be very challenging to design - from volume of content, to stakeholder input, and dynamism of the content, this is not an easy task. I know I’d make my fair share of mistakes! 

Stay tuned…

Usability simply defined on two hands.

New book finally arrived…I’m excited about this one!

Often analogies around blueprints are made when trying to explain to someone what user experience professionals do for a living, but recently I have been thinking back to my fashion design schooling and realized that pattern drafting has a lot of similarities as well.

Having participated in many different roles throughout my career to date, I have come to the conclusion that all of my experience in completely unrelated fields have a strong influence on how I work as a UX designer now. When I was in the process of getting my Fashion Design diploma, my favourite thing to study and work on was pattern drafting. It is synonymous with putting together a puzzle - much like designing an interface is.

In this post, I am going to try and put my theory to the test…

User research vs trend analysis
Before sitting down to design your architecture for a website or application, you start with researching your user and identifying needs and tasks. In pattern drafting, you research historical and current fashion trends and identify the garment features. A website user may require a shopping cart, whereas a person wearing a dress may require a pocket. The architecture and design has to accomodate this functionality.

Wireframe vs pattern draft
A wireframe identifies functionality, navigational and content requirements so that a developer can build what is being designed. A draft (pattern) identifies functionality, cut lines, orientation and sizing details so that a person constructing the garment can produce it. Wireframes show hierarchy and content weighting, drafts show dimensions and important design elements (ie zipper or button closure?)

Responsive vs pattern grading
Responsive design in the world of the ‘interwebs’ means designing an interface that is device agnostic. Meaning a design is created using a grid that can be resized and adjusted for smaller/bigger screen sizes (I am completely oversimplifying here as this gets more complex - but that is a whole other post). Grading is a technique used in pattern drafting where you adjust and mark the pattern for various sizes. Just as viewports in the online world have some set standards (ie 320, 600, 728, 1024), so does grading (ie for women’s garments size 8, 10, 12, 14).

Prototype vs muslin
Prototypes are often used in conjunction with an agile development and design process, whereby a simple version of an interface is created to test the design - generally a stripped down HTML site with no CSS or functionality. Often times a prototype can be very close to a fully functioning site depending on the project/approach. A muslin, in fashion land is a way to test the design of a garment. You use the cheapest material (simple weave, almost like a bedsheet), and sew your pattern. Often the zippers and closures are not finished and the design is fitted to ensure the design works as intended.

Development vs garment construction
During construction, a developer will use functional specification documentation in order to guide them on how the site/application should work, and thus how they need to build it. During garment construction, a machinist uses markings on the patterns such as dart ends (shaping that requires a distinct construction method) , notches (for lining up your fabric once it is cut, and determining front from back pieces), and grading. The pattern speaks the language of the person sewing the article of clothing, as the functional specifications speaks the developers language (onClick, onHover, on load events).

QA vs QA
Can you guess? Yes, just as we have quality assurance in testing beta launches of sites, there is also quality assurance in fashion products as well (or any product for that matter). For websites you are looking for bugs and broken functionality, for clothing you are looking for functioning zippers, structural issues like a poorly hemmed skirt, bad seams, loose buttons, etc.

So there you have it! If you ever want to experience designing a ‘GI’ (garment interface - yes I just made that up), here is great resource that I used: Patternmaking for Fashion Design

I am thankful that I had the opportunity to learn these skills as it makes me think about designing websites/applications just a little differently…

My Retro Microwave - 7.7

It’s hard to rate this one because I am now so familiar with the interface that being critical of it is challenging. Generally ‘start’ appears under the number pad and ‘cancel/reset’ is close by - providing contextual placements. Power level and Timer are well recognized in terms of their functions as well. Points for my fancy radiation heating friend. Where things start to go awry is the awkward reheat and auto cook buttons. What does ‘popcorn’ vs ‘baked potato’ mean? Why is it always 4 minutes? How does it know how much food I put in? (I think/hope new ones have some sort of sensor now).

Overall, the microwave is fairly intuitive from one make to another, but many have some serious UI flaws.

Most points given to: 
System status - Users input is clearly shown, time left provides feedback to the user and sets expectations for time to goal completion.

Potentially overlooked?
Defrost and Reheat - does anyone know who came up with the times for these and the rationale behind it? It’s always confused me. (and Google provided no answers unfortunately - it will remain a mystery)

What you may not have known

The first commercially available microwave was called ‘Radarange’, and was first sold in 1947. It was invented by Dr Percy Spencer and applied radar technology used during the war (WW).

Google “usability”, “user experience”, “information architecture”, or “wayfinding” and you will get results that speak primarily to websites, web applications and software design. But what about documents? Yes, I know this sounds silly but let’s think about document uses for a moment…

Documents are used by businesses everyday for providing:

• Information for internal and external stakeholders
• Guidance and help
• Overviews and solutions to business problems
• Roadmaps for projects/programs 
• Orientation and training information
• Legal records and policies

Given the importance of documentation, shouldn’t we be considering overall usability of documents as well? I started thinking about this when I received feedback on my portfolio about presenting the work in a user interface that demonstrates my knowledge as an IA/UX professional. Then, subsequent to that, I came across a post about what HR professionals look at on a resume - how they literally spend 6 seconds scanning the document, and what are the key areas they spend that time on.

More recently, I have been working on a lot of documentation at work - both internal and external - and have constantly had this in the back of my mind. I started to think about the principles that get applied to website design and realized these same principles can help craft the perfect presentation/document.

Know your user

Know who your audience is and how they will be digesting the document. Is it being presented? Are they reading it on their own with no guidance?

Discovery and research

Not only should you research who will be reading the report/presentation/etc., but also the content that is going in it. Just as you would reference sites and past projects for competitive or user research, the same thing should be done when creating a deck or reference document.

Set expectations for the user

Provide an overall objective and purpose for the document. Why should they read it and what will they get out of it?

Provide help and navigation

All sorts of help and navigation elements are used in documentation, we just don’t think of them in the same way we do a global header or footer in a website. Table of contents, page numbering, and chaptering provides orientation and wayfinding in documents. Bibliography, resource links or sources, and summary slides provide contextual information about what the user is reading.

Scannable and digestible content

No one reads anymore, we scan - making your content easy to scan, and ultimately pick up on the meat of the document helps the user digest content easily (just like online). Use of bullets, bolding and headlines can help create content that can be consumed easily. Also avoid using extensive language and overcomplicating simple ideas/points.

Flow of information

Content should flow in a logical sequence, allowing your audience to organically come to the conclusion of what is being presented. 

Language 

The language you would use on a leave behind document versus a powerpoint presentation would be very different. Also, if presenting a difficult concept to stakeholders that may not have experience in a certain area, your language would need to be simplified. This goes back to your user and context of course.

Visuals

Just like browsing a website, images can have impact and break up wordy and extensive content. 

An older post on useit.com outlines some key points about how we read online that are still applicable now, AND can be applied to laying out any documentation as noted above.

So just in case you are working on the presentation deck for the next client meeting, or an internal training guide for new employees, start thinking about them as more than just a ‘document’ - they too require us to lead the user through an experience…

documents photo credit:Daniel Y.Go
table of contents photo credit:Greg McMullin

After you have checked out my hot new digital signature above, you should check out this fabulous site.

Oddly enough, despite egregious advertising placements, it’s pretty clear what the main task is…

Visual noise defined.

City of Toronto Waste Bin - 7.4

This bin scores higher than I would have thought given the amount of broken ones I come across, but the initial design did take usability into consideration. There are easy to follow instructions for users, recognizable iconography, intuitive (mostly) controls, and fairly good system feedback when there is an error (ie the flap doesn’t open). 

The addition of the cigarette disposal, was not widely recognized - but this is due to the service not being available prior to this new installation. 

Most points given to:
Iconography - no wording was required as the symbols clearly indicate which flap is for garbage and which one is for recycling (and even what types of things can be recycled).

Potentially overlooked?
People expected, that to toss trash, they needed to push the flap with their hand. Initially users were not noticing the foot pedal and instead used their hand. We have since adapted to the new design so we can all benefit from ‘contactless’ disposal! (well when they are in working condition of course)

What you may not have known
These bins are part of the Coordinated Street Furniture program the City of Toronto started in 2007 when they awarded the program to Astral Media Outdoor. This program includes the new bus shelters and public bathrooms (plus, plus…). So yes this is why you are getting rained on while waiting for TTC.

“Is it usable” is a series I’ll be starting shortly that looks at everyday objects and interfaces and rates them based on usability.

How will I come up with my ratings? I’ve created a matrix based on Jakob Nielsen’s 10 Usability Heuristics. For each of the ten heuristics, I will assign a score between 0 and 10. The average for all 10 will become my star rating.

Here is a nice little video that sums up the criteria mr. Nielsen came up with - in case you don’t already know.

10 Usability Heuristics explained

Stay tuned…

We have all heard that designing for context of use is the best practice, however, sometimes this idea can get lost.  We often forget the WHERE and HOW. And to further complicate the matter, as users we come to expect things – we are demanding and spoiled.

When designing products, interfaces, services, etc. there are three levels that need to be considered. Let’s use a mobile phone as an example:

1. The most important thing – does it do the task it is supposed to do? A mobile        phone should be able to make a call and text.
2. The second most important thing – does it meet my expectations? Now a days we expect a phone to have a camera through experiencing previous products.
3. Intangibles – does it satisfy my desires, and does it exceed expectations? The 4GS has an outstanding camera with multiple lenses and high resolution. This wasn’t a must have but certainly makes the selling job easier.

Designing interfaces and applications is not an easy job because of these factors. It’s remembering these elements that lead the way to something that is truly usable.

I thought a personal anecdote would be the best way to illustrate this point, as I am sure while you are reading this you are thinking to yourself – “Ya, so what? That’s obvious!” Well it’s not.

Last weekend at Canadian Music Fest (formerly Canadian Music Week). I was preparing for the night’s activities and wanted to set my schedule. Having been to a few festivals in my time, the first thing I do is go to the app store and look for the festival app.  To my surprise, my search came back thumbs down.  Hmmm…I think – questionable. Well all is not lost, I’ll just go to the website – surely they have a mobile version of the site. <insert that Price is Right ‘you’ve won nothing’ buzzer>. Now what? I am on the go with only a mobile device to direct me and I have no tools to help me.

After getting annoyed with pinching and panning to see the shows (and I might add, a separate search for artists and venues; why not give me one search?), I head over to the magazine stand and pick up The Grid and Now.  Luckily Sneaky Dee’s has about 5 different publications you can pick from, right at the front door. The Grid has a wonderful little infographic map, but it doesn’t list all the bands – just the buzz bands. Now magazine has a booklet presumably published by the folks at Canadian Music Fest, and it has a full schedule – yesssssss! BUT the publication is the size of an iPad. A pocket-sized schedule would have made more sense right?

The point being, once you have been to one festival and experienced it with an app to set your schedule, research bands and in some cases preview the music, you expect the same out of every festival. Even a pocket-sized schedule would seem like a step down. Your context of use is that you are not sitting at home on your laptop researching on the website a week before (well at least I don’t geek out that much). You need relevant information about the festival while you are running between venues/stages.

In my opinion, Pitchfork Festival (2011) did a great job with their application and must have had the user and their use scenario top of mind. The app was simple and addressed the most common user tasks – read about the band, add it to my personal schedule, find the stage on a map. And further to that, it worked offline so I didn’t get charged hefty data fees (I was using a Toronto service plan in Chicago).

#cmf/#cmv maybe next year will be the year for users. It was a great festival none-the-less, so I thank you for that.

FYI incase you wondered, the dragon photo I found while doing a Google image search for the keyword “context”. I think it’s pretty fabulous and was actually part of a good post on mobile context. Give it a read if you are feeling curious. Thanks Rachel Hinman.

Mobile Context - The Chapter that Nearly Killed Me