Archive for the ‘Usability’ Category

Newer Entries »

Facebook, UX, & the Tech Priest Class

Thursday, February 11th, 2010

So much has happened in the past few weeks (both personally and in the tech world) that I’m updating twice this week to make up for last week. I wanted to write about the iPad, but I’m going to save it for another day. I had to comment on my friend Mike Melanson’s (@rwwmike) Read Write Web article (read the full thing, especially the comments).

Because I’m a friend to Mike, and I like RWW, I subscribe to their RSS feed via Google reader. I therefore missed all the amazing comments that ensued from users. I’m now very sorry I did. Here’s just a small sampling of what comments a post called “Facebook Wants to Be Your One True Login” got:

ok cool now can I get to facebook (fuccinwayne)

The new facebook sucks> NOW LET ME IN. (John Blair)

I WANT THE OLD FAFEBOOK BACK THIS SHIT IS WACK!!!!! (Nicole Gray)

What is going on? You are totally confusing me. Knock-knock. Anybody there? Let me in. Katherine (Katherine Radway Hegedus)

By now you get the idea: There are somewhere in the range of 200+ comments like these. It took me a while to understand what was going on, but it dawned on me that the RWW article ranked higher in the Google search rank than did the Facebook login page. This means someone did the following steps 100% blindly (or autopilot):

  1. typed “login facebook” into Google
  2. clicked the first link without looking at the link or description
  3. ignored the red color scheme of Read Write Web
  4. dismissed the huge article in the middle of the page until they found a Facebook icon (Facebook connect)
  5. without looking at the address bar or any authentication, logged in as if to Facebook
  6. finding the comment field the only place to post, ignoring all other comments, posted an angry or confused question as if Facebook were a person

David Hayes (@drhayes) has a beautiful shot that it’s much more than Facebook on his blog.

As a user experience developer, this brings up all sorts of questions, concerns, and feelings of dread. As a user experience developer I certainly know that I’m not my audience or even close to it, but I do think I have an understanding of how things work. I had no idea how heavy the reliance on Google to get a user where they wanted to go was. I wasn’t sure that so many users had gotten so adept at filtering out such amazing amounts of noise, they saw Read Write Web as Facebook.

Users seem not to use the address bar, they don’t use bookmarks, and hardly read anything. This isn’t bad, it’s not saying these users are dumb, but it brings up a need to fix these interfaces for users. This is just a time where I feel like a priest in the Dark Ages: preaching the only written word through a language no one understands. It freaks me out when I peer into the actions of users who are using the sites and I can’t begin to fathom the thought process or the use case.

Talking with less tech savvy friends and family, they are amazed that I “know all this stuff” when I myself feel I don’t know much at all until I look at it from the other end: this is my job and my life – I am of the priest class, talking in cryptic language, trying to navigate the dark for my flock. I try my hardest to treat these things as material to learn, to grow in my understanding of the philosophy of the user.

Part of me can’t help but think – did users learn the behavior that caused them to act that way because we trained them that way?

Posted in Accessibility, Advertising, Information Architecture, Usability, User Experience, Web Design, Web Development | Comments Off

User Experience of the Well Made Shirt

Thursday, January 28th, 2010

This week has another drawn out metaphor! Hoorah for metaphors! I’ve been thinking about the user experience with everyday objects lately for a personal project of mine and have been thinking carefully on objects I use and admire. A local men’s clothing store near my work recently had a 50% off sale and I went in to take a look. I’ve learned over the years how to look for certain quality elements in the things I buy for myself and I got to thinking of the years of precision and know-how that have gone into making a high-quality dress shirt. It makes sense, to spend the time and effort (and, by proxy, the cash) on something that a gentleman wears every day (well, almost everyday) if it means a better experience overall. Making a good user experience means the client feels you’ve done nothing at all – that there is a seamlessness to the experience that allows the user to dwell on the task at hand because the interface is so comfortable and easy. I’ll walk through some examples of good user experience in a dress shirt, showing how each piece solves a small problem

Horizontal Buttonholes
Buttonholes serve to keep the garment fastened, plain and simple. The reason buttonholes in dress shirts run vertically is two fold: one one hand, the vertical lines look good with vertical stripes and stitching, and on the other, the vertical buttonhole keeps the button in the middle of the hole while making sure that no stress unbuttons it. Two holes in the shirt, however, have different stress points: the neckline (the collar) and the waistline (at the belt level).

The neck and hips both rotate horizontally while the chest and stomach, when they do rotate, rotate vertically along the spine. This causes stress to be placed in the opposite direction from the position of the vertical buttonholes at these locations. Tailors, being the designers they are, came up with a nifty solution:

horizontal button holes

Horizontal buttonholes at the waist and neck now distribute the pressure from twisting motion! But wait, doing so suddenly ruins the nice, clean centered button everytime force is applied. The button will slide from the middle, to the opposite side of the force and back again. That wouldn’t look good, except these buttons are hidden from view by the tie at the neckline and the belt and trousers at the waistline. Brilliant!

Gusset Reinforcements
Speaking of pressure, the shirt has pressure applied anyplace that two pieces of fabric meet. Normally seams take all this pressure, but what of areas that require openings such as the cuffs and the space where the front and back tails meet along the coronal plane of the body? Over time, tailors found these meeting of the folds took much of the stress of the garment. To solve this and make the shirts last longer, tailors employed gussets: small pieces of fabric and stitch that held fast like so:

gussets on shirts

These reinforcements are not that noticeable, but they add long-term value to the shirt while solving a fundamental problem, which keeps the user happy as their shirt secretly holds up throughout the day

Undercollar Construction
The collar of a shirt is arguably one of the most distinctive aspects to the shirt. Button down, point, or wing collars all give a clean line to the face of the gent wearing it. Tailors know this but they also know that men sweat and need to wash the shirt over and over again in its lifetime. The problem with washing is the shrinking effect it can have on fabric. To keep the points clean and the collar looking sharp, Tailors build in undercollars. Undercollars are woven differently than the top collar to not pull on the top fabric if they shrink:

Undercollar fabric

The undercollar really highlights a good user experience in that the shirt, despite repeated cleaning, looks great everytime. The undercollar is almost never, ever seen, much less noticed, yet it just works to make the user appreciate the forward-facing part of the shirt.

Buttons and Stitching
Buttons and stitches are the main reinforcements of the garment, and as such, need to be sturdy and many. Buttons on well made shirts are generally pearl, rather than plastic. Though Tailors found that it was cheaper to use plastic or resin buttons, they cause the buttons to slip from their holes easier and can chip and crack more often than their stronger pearl counterparts. Stitches hold all the pieces of the garment together, so the more per square inch, the more the shirt feels like a single piece, moving as one.

pearl buttons and 20 stitches per inch

The phrase, “A stitch in time, may save nine” is literal here. This translates to any user experience developer: by spending the time and effort to make the experience better up front, the system becomes easier to maintain and by thinking of the details, the major pieces are already in place.

When developing a user experience, think about the ways the user will operate the system. Where will the user notice problems? Where will the pain points be? By gathering feedback and thinking critically, we can reinforce the way the user interacts to ensure a seamless and brilliant feel for our users. By taking care of the problems the user might run into, be provide an interface that the user feels is bespoke, made for them. When we do things right, the experience is as nice and comfortable as your favorite shirt.

Tags: , , , , , ,
Posted in Fashion, Sartorial, Usability, User Experience | Comments Off

Live Blog from John Slatin Access U 2009

Tuesday, May 12th, 2009

Live Blogging from @pat_ramsey ‘s talk on “Accessibility and Social Media”.

SMS is primary social tool in Sub Sahara Africa – only data the infrastructure will support.

Problems: When there’s no way to skip repetitive content, no text equivilents for images when the sites are super image heavy, when you can’t identify inputs and controls – the rush makes accessibility fall by the wayside!

Problems arise when users who don’t know about accessibility can create content without the tools available for accessibility information. 15 year olds on YouTube don’t know about captions on their home movies – how to handle the user-generated content question?

How to make Web content accessible to peopele with disabilities. Education is key!

Text alternatives are important to image heavy sites: Thumbnails in discussion threads, avatars in forums, images in user galleries.

CAPTCHA: The questionable best way to handle bots. Turing Test Alternatives are better “Is fire hot or cold?”. What about audio files? They are, by definition, hard to hear! Look at Blogger’s audio CAPTCHA.

Don’t make it harder for your users to sign up than it is for bots and phishers! This should make you think long and hard about access barriers.

LABEL YOUR FORMS! The and attributes are important for those hitting your form in JAWS form mode.

Facebook Mobile: m.facebook.com, simpler, easier and faster loading. Much easier for screen reader use. beware – login and other forms still not labeled!

Twitter: “what are you doing?” is labeled correctly, most images have alt text. Skip nav is enabled. Use greasemonkey scripts to enhance accessibility. There is a third party accessible alternative.

WordPress: problems are two fold: admin interface and published interface. Templating on the front end works great for the 6 files (wrap your content in an accessible package). With admin panel – edits are lost on upgrade! Look at /wp-admin/ folder to see the admin template files. Login form in properly labeled for accessibility. Admin section has problems, but know issues are getting better. Alt+Z drops right to content editor! Those need to be told to users!

Developers know things can be better. WAI-ARIA used to send info back to blind twitterers about how many characters were left in their tweets (TPG Notifier).

“Great kid, now don’t get cocky” – There is a need to get content from developers about what does and doesn’t work. Open source can help with all this. Rather than feel overwhelmed, try to submit patches, find the accessibility hooks, share findings, communicate! WordPress IRC is always open, Facebook loves feedback!

Tags: , , , , , ,
Posted in Accessibility, Copy Writing, SEO, Usability | Comments Off

Ch-Ch-Ch-Changes!

Tuesday, February 10th, 2009

All too often, as developers we’re struck with changes. It’s much harder on designers (everyone has had a single creative thought once, so people often try to wrestle design from the professionals), but it still impacts developers when changes are made after the site’s been coded, the information architecture’s been signed off on, and the design is finished. I’m going to discuss a few ways to handle each.

INFORMATION ARCHITECTURE

Why do we fuss and preen over this stuff? Because it works. A recent A List Apart article by Keith LaFerriere details why we need to educate the client on IA, it’s place in the construction of their Web project, and what it does for them down the road. Bringing the client in at this stage allows them to see what the shape and functions of the site will be ahead of time.

This doesn’t mean we sacrifice flexibility of the project – we all know change is good – but it allows the flexibility to be controlled: the sitemap needs to be changed and re-signed every time a change is encountered, navigation schema is signed off on once taxonomy and site map are decided, etc. We use this framework to teach the client why it’s important. One of my favorite Creative Directors put it this way: “You don’t do design without a plan. It won’t matter how pretty, how amazing and flashy your site is; without a clear navigation and structure to your content (one that your users will enjoy using and find intuitive) your site will always fail.” I like that way of thinking, it puts the client in a frame of mind that A comes before B comes before C, even if all they understand is C.

DESIGN CHANGES

Let’s face it – design changes suck. Knowing that, these are most common, but often easiest to quench. Because every client’s a junior designer, they all want little tweaks. It’s important as a designer and developer that the client understand that every comp and wireframe is its own entity: every piece of that comp works with every other piece of that comp to make a working model. I know tons of creatives and they all say the same thing: don’t change the design, don’t tweak anything. Tell them what the root problem is and they’ll find the best solution. Often times clients want to make changes because things present deeper problems. Why did the client change the color? If it was hard to read, then there might be a better solution than the awful crap they did.

Because changes will and do happen, what is to be done? If the changes are page level, sure (barring a design destroying idea) it’s not too bad. A template level change is much worse – we’re looking at much larger, time consuming changes. Education, again, is the best medicine. Ask why a client likes or does not like an element. Explain why you made the design choices you did. It’s a shame that many designers must justify their designs, but there are a lot more people who don’t get it than do.

INTERNAL ISSUES

This is what the clients never see. This is the changes that get made in house. These are many times beneficial to making a great product go live, but often times the team cannot get a party line, cannot get with the whole program. In these times it’s best to follow workflow protocol. When good workflows are put in place this step rarely gets bogged down. Being as buttoned-down as possible internally with reflect on the work you do for the client as well as the perception of the group in the marketplace. Keep a consistent workflow and procedure in place and this will be the least of your worries when it comes time to change.

Tags: , , , , , , ,
Posted in Information Architecture, Usability, Web Design, Web Development | Comments Off

Newer Entries »