But now, I’ve decided to start teaching myself Ruby on Rails.  I’ll see how this goes…

Been working on a new YA book series for at-risk students so I let the blog slip a bit. I’m back now, however, so let’s get back to one of the topics I was focusing on regarding Human-Computer Interaction: Hick’s Law.

Hick’s Law talks about how long it takes a person to make a choice based on the choices they have available. I’ll do a little bit of math later but the gist is that we can figure out how long someone will take to make a choice, assuming that the choices are sorted in some fashion.

Choices, Choices…

Ever go shopping for ice cream at a place with dozens of flavors?

How long does it take you to pick?

This is Hick’s Law in action. With so many choices, the people making the choice have so much information that it takes longer and longer to choose. Considering that one of those choices is ‘forget this!’ and walk out (no action), this is not ideal.

The Math

Mathematically, we express Hick’s law as

Hick’s Law: T = b*log₂(n + 1)

How long it takes to choose (T) is based on the number of choices we have (n). We have a +1 in place because there is an an additional choice: do nothing. It’s logarithmic, so log₂(16) =4 since 2⁴=16  . The (b) represents the set amount of time it takes to make a choice, which we can measure by mapping data to points on a grid.

What does this show us? That (for suitably small sets of numbers, such as the number of choices on a website), after a certain point it will take progressively longer to make a choice based on the options available. To combat this and allow people to make choices more quickly and confidently, we need to do a few things.

Limit Choices

Anything more than 6 to 8 choices in a menu is going to confuse people. We see this in everything from restaurant menus to store aisles. Presenting a limited number of choices and leading them to a choice makes it easier for people to decide what they want.

Nesting of Many Choices

Even if you offer many choices, you can take advantage of limiting choice by nesting the choices inside each other. For example, Amazon’s menu options start with Shop by Department, then expand out to choices within the department. Likewise, a food aisle in a store will have headers as to what they contain, then present the different products under each heading. A restaurant menu will have listings for chicken, fish, and beef. My own site has headings which guide people to the different sections such as Portfolio, which has nested within Case Studies, Code, Print and Web.

Less Clutter

Ever try to read the ingredient list on the back of the food in the store?

Fortunately, I (with the help of my contacts) have good eyesight. However, this is not ideal for navigation. Limiting the choices actually lets us expand the usable area for each menu choice. Going back to Fitts’ law, we can see that if we increase the space of our target, it actually makes choosing the target easier.

But What Does This All Mean?

This isn’t just about how many links we present to a user or how big they are. Rather, the application of Hick’s Law and Fitt’s Law is meant to do one thing: presenting the suitable amount of choices to the user so they can choose in comfort and confidence. Even before the user clicks on a link, the user has to make choices. Simply the act of coming to the site in the first place is a choice and this is why information needs to be presented in a organized and consistent manner. Requiring a user to follow certain paths that are easy to understand and navigate means that lets the user enjoy the ride rather than having to concentrate on how to operate the vehicle.

A Persona is a story about someone. We are telling the tale of a user of our site, either an actual user or our projected audience. Before we even start wireframing, we need to know who will reach out to with our site. Otherwise, why take the time to create a site?

One of the pitfalls of development is that we look at what we want rather than what our audience wants. Our experiences color our perceptions and what we consider to be ‘easy to understand’ may be anything but easy (especially to my 73 year old father who gets frustrated with computers easily). Thus, the need to step into the shoes of another, to empathize with them.

The Personae of Caias, Recoded

When I set about to create Caias, Recoded, I had a particular audience in mind: those who would seek me out for my coding and UX experience. But just who are these people?

Fortunately, my background in creative writing helps me in creating personae so I was able to make a short list. I’ve had the advantage of dealing with each of these in real life so I can construct this person from actual people. So, without further ado, I present to you…

• The Recruiter
• The Hiring Manager
• The Fellow Creative
• The Networker

The Recruiter: Sarah

The Recruiter is 28 years old and is Irish. Single but in a long term relationship, she involves herself in a number of outdoor activities and is considering a Masters degree when her schedule frees up a bit. She’s technically savvy in a broad sense but often bumps heads with her clients over what a position actually requires versus what they are requesting and with people she is recruiting over what their skill set actually covers. In a portfolio site such as Caias, Recoded, she wants easy access to what the client needs to see from her recruits.

The Hiring Manager: Amit

Amit is in his mid- to late-30s and is from India, married with one child. Much of his free time is spent decompressing after long work hours and with his family. While he has a degree in Computer Science, his experience on the job drives his success. He has a depth of knowledge regarding his focus of Web Development as well as broader knowledge in related disciplines (design and UX). He’ll come to Caias, Recoded to evaluate my work and think of questions to ask me.

The Fellow Creative: Jenn

Jenn is in her early thirties, a self-taught freelance artist with a husband and young daughter. She is incredibly prolific in her output and easily makes deadlines. A fan of alternative music styles, her first works were for a band which has reached some minor fame throughout the years. She is a high school graduate along with some technical education but much of her skill comes from self-education; much of her work is done on a Mac. She comes to Caias, Recoded to see what I’m up to and make suggestions and comments.

The Networker: Steve

Steve is 51 years old and divorced, with no children. A vice-president at a financial services company, he is well-off and his hobbies reflect this; camping, extended vacations to exotic places and fine dining. As well, he owns a small company which produces hobby and board games for adults and spends time promoting his games at trade shows. Steve has an MBA and extensive experience in technology as well as design. He’ll seek out my site to see what I’ve been working on out of both curiosity as well as to match people up with each other.

So what did we cover in our personaes? Well, we have the following:

• Name
• Age
• Gender
• Occupation
• Personality
• Technical Expertise
• Why they would use the site or application?

For a portfolio site, creating personae isn’t that difficult. The major focus is on what information they will see from the site and how to present it. For a more interactive site, we can ask more specific questions, such as:

• Expansion on technical background (Hardware vs application experience, web use, etc)
• Physical limitations (accessibility issues, for example)
• Ability to accept change
• Work environment (office, field use, etc)
• Learning style
• Roles (a supervisor may not only interact with a program to analyze data but also grant permissions to other users)

By developing authentic personae, a site developer can see his audience before a single wireframe is drawn out. In giving a real face to the users of the site, developer and designers (either a single coder or a large team) can see the user experience through the eyes of another.

Cleanness, at least to me, is the idea that your elements on screen do not distract from each other. While this may seem just a user interface issue, this cleanness has a huge impart on the experience of the user, just like coming home to a uncluttered and vacuumed house or a sink free of dirty dishes after a long day at work is a welcome sight.

Cleanness encompasses a number of ideas:

1) An organized presentation of display elements

I am a fan of the 960 Grid System for just this reason. Being able to take the elements and reorganize them not only lets you pick the best element layout for display, but lets you have the flexibility to reorder elements quickly based on feedback and testing.

2) A sufficient amount of white space between elements

Leaving enough space between sections of content not only lets it stand out, it will also impress upon others a level of professionalism. To take a note from the print side of design (where I started in design and where I still go back to for ideas), look at a lawyer’s business card. Most of them aren’t full bleed multi-colored displays but have elegant branding and present contact information in a concise manner. White space is an element of design all its own; rather than just a hole, it’s a bridge between elements.

3) A color palette and font selection which complements the purpose of the site.

White space is not just white; in this, the appropriate use of color to compliment the image you are trying to portray will carry you a long way. Depending on the use of the site, you will need to choose a color palette which convey your message such as professionalism (more sedate but saturated colors) or friendliness (more vibrant and warmer colors). As for fonts, not only do you need to consider readability but access; using nonstandard fonts may fail for you based on the wide array and version number of browsers available.

4) Menus which walk the user to their destination

Your menus should not be a site map. Rather, each selection should guide the user to the appropriate sub-category of choices. This is why card sorting is important to the user experience; you must use road signs that the intended user will recognize and the best way to do that is to have similar users walk the road for them first under your guidance. Most important in this is not to use your terms for the menus but those with which the users will be comfortable.

Cleanness allows the user to easily flow from one element to the other, as dictated by the design of the site. Like a lazy river, they are carried along to where they need to be rather than crashing up against dead-end design elements.

One of the major elements of human-computer interaction is the time it takes to make and execute a choice of options on the screen. Not only must a person reach a decision about their options, but they must also use the interface to perform that choice they just made. In this, we come across two interrelated standards. The first, Fitts’ Law, I will cover below. Next week I’ll write about Hick’s Law.

Fitts’ Law

Do me a favor. Get out a piece of paper and a pen.

No, really. Go, now…

One one side, I would like to draw 16 circles of the same size, in a 4×4 grid. Make them roughly two inches by two inches.  Push the paper away from you a bit and use your pen to pick the circle which is third to the left and second down.

Now flip the paper over.

Draw the same set of circles. Only this time, fit the same 16 circles in the space what one circle on the previous page would take up (2 inches by 2 inches). Push the paper away across the table or desk you are at and from where you are at arm’s length, use your pen to pick the circle which is third to the left and second down.

Did you see how it took longer to pinpoint the circle you wanted in the second case? That is Fitts’ Law in action (yes, I know the original law only dealt with a single dimension… you get the point).

Fitts’ Law shows that the both how far away the object is and the size of the object determine how quickly we can choose the object. First based on a single axis, graphic user interfaces greatly expanded the use of this law as well as others derived from it. It’s the reason why menus are at the edges of the screen or workspace and why context sensitive pop-up menus rate much better among users than drop-downs.

It’s also why we have bigger links in the middle of a web page than at the edge. You see, the edge of a page acts as a boundary, as I’ll show you.

Take this picture of circles above. I want you to drag your browser so that the left edge of the circles lines up with the left edge of the screen. Now, move your mouse around a bit and do the following:

1) Select the right-most circle in the 5th row
2) Select the left-most circle in the 1st row

See which one was quicker?

Before computer interfaces, Fitts’ Law and variations therein came into play in regards to untrained and simple equipment operation (such as a phone keypad, which consolidates the numbers into a grid). It, along with Hick’s Law (which I’ll talk about next week), form one of the foundations of how humans interact with computer interfaces.

Now to see what this thing can do.

By narrowing down elements and presenting different choices of a single variable, the tester can determine which choice produces the desired result.

What To Test?

Anything and everything! Certain ad copy, placement of a graphic, even the color of a Buy button can have a huge impact on a final purchase or use decision. By presenting choices of a single variable and measuring the responses, greater response results can be had, with a real time testing group who are already users of the site. As well, we don’t have to limit ourselves to simply two choices in our testing. We can present several options, in real time, and let people create the data that shows us the best results.

Likewise, A/B testing doesn’t necessarily need to present an equal split between the old and the new variable(s). While showing new features for an internal company information site won’t cause employees to flee their jobs, you certainly won’t make a radical change in an element on an outward-facing site and present it to half your users. This shock could result in a significant drop-off in users and sales. Rather, you can present the new feature being tested to a certain percentage of users; perhaps have the website show the new feature to a certain range of IP addresses.

Combined with tracking software such as Google Analytics, the choices present can be quantified and the results that give the best response implemented immediately. Rather than using an opinion from a meeting, trying to learn a ‘lesson’ from what is presented or make a ‘best guess’, we can let actual proven data guide to the best choice.

Today, I talk about .live() and .delegate(), two jQuery functions that get lots of use. Both let you attach event handlers to elements. Although similar in application, I find .delegate() to be a much more precision instrument.

Let’s look at .live() first:

$(selector).live(event,data,function)

.live() is great. However, you can’t use live on child elements. Going deeper in the DOM isn’t just an option with .live().

However, as jQuery 1.4 rolled out, we were introduced to…

*drumroll*

.delegate()!!! (OK, the !!! aren’t part of the method, but I want some emphasis).

In addition to the event, the data passed and the function to be triggered, .delegate() adds the ability to select child elements.

$(selector).delegate(childSelector,event,data,function)

This way, you can select elements within other elements (such as <li> elements inside <ul>) and only affect the <li> element.

So Why Not Use .live() For Everything?

It would seem to save a lot of effort to use .live() for everything; just add a selector to narrow down .live() rather than use .delegate(). However, doing means that every time we click a link, .live() would have to check to see if it should trigger, moving upward from child elements all the way up to the top of the document. Every link, every time, even with a selector in place. However, .delegate() doesn’t have that issue. Rather than move all the way up to the document level, it will stop at the child selector indicated (for example, <ul>).

In a nutshell, .delegate() is less resource-intensive as it lets you narrow down the local section of the page, while .live() must process events in the entire page.

Agile software development is a series of processes where programmers use short development cycles to create, test and roll out software. This greatly speeds up the process, lets you catch issues that may not appear until much later in development under other methodologies such as waterfall and gives you the chance to adjust your software quickly to end-user desires.

While great from a development standpoint, documentation in an agile environment can be difficult.  ”Working Software Over Comprehensive Documentation” is the call and to do otherwise will bog you down in snapshot paperwork that no one will bother to look at either from the user or team standpoint. However, there are a few things you can do to have effective agile documentation:

• Develop documentation from requirements

It’s a simple matter to work from functional product requirements to develop documentation. This gives you a good jumping-off point since the FPR are the points the clients are most interested in seeing in the product.

Unlike non-agile projects, you probably won’t have a huge set of FPR to work from to start. This is OK; just take what the team and the project owner have put together as bullet points. Break it down depending on the type of user (Administrator, site user, job seeker, employer) and list what functionality they should be able to get out of the software (“As a project manager, I can assign workers to different tasks in the project” ).

• Use the tools you already have in place

By this, use the backlog to determine what you need to document or revise. Each user story will tell you what needs to be documented and in what detail. As well, each set of tasks associated with a user story will give you more insight into how the software works.

• Listen to your users 

Your end users are going to ask questions. Rather than go crazy trying to anticipate their every request, reach out to the most vocal and find out what they need in terms of documentation. Some processes that are intuitive for developers and document writers may not be so for the end user. Let them ask questions; as the software goes through different iterations you’ll be able to fine tune what needs more explanation.

• Get to know your team

Your team is going to be one of the best sources of what the software does. Sit down with them, ask them about how the software works. You should be interested in what the team is doing anyway, so it’s a simple matter to leverage that into gathering information about the software.

Let the developers show you their work in action. The work they do is amazing and you really need to let know.

• Cut away, then cut away more

You should only document the core functions of the software. Anything else is going to muddy the waters of your documentation. This is where the functional product requirements can come in; compare what is most important in the FPR to what is currently being developed.

Once you have a core of your documentation, focus on what won’t be intuitive. Save functionality is fairly intuitive if the programmers follow best practices, for example, so you really don’t need to keep that section other than a brief note for menu walkthrough.

As you go through iterations of software, you’ll be able to mark what will change from version to version based on the backlog and see what needs to be documented.

• Sit in on the code review

I’m making the assumption that your software development teams do at least a weekly code review, either formally or over-the-shoulder. These are some of the best times to ask questions about version changes, tasks and software functionality. As I stated before, showing an active interest in the programmers’ and developers’ work will generate a lot of goodwill.

• Don’t get hung up on format

Documentation isn’t just product manuals and formal papers but code comments and development notes. I find a database system works wonders for organizing the information on each project. You can easily pull information from the backlog for this purpose, then create custom reports when specific information has to get to decision makers or end uses.

With the tools in place in agile environments, there is less need to have a standard documentation process. Much of it is replaced by backlog reporting and tracking burndown. However, documenting agile processes becomes more a matter of being able to filter information depending on the viewer’s needs, rather than mass document creation. In effect, you are equal parts writer and archivist, not only effectively creating information to share but finding the best way to sort it for the appropriate audience.