Usability Patterns for web-based applications

There are usability patterns and there are more usability patterns. In this maze of patterns, I also propose to put in some more interaction patterns. How are my patterns different from others? Well, I will leave it for you to discover.

For some months, each month there will be a new pattern that I have designed and tested (with users obviously!). Yes, they all work and fairly well too! Mind you, these patterns are complex patterns that have emerged out of my consulting experience with many web-based applications--an experienced hand is required to implement them successfully.

I believe that each type of artifact has a spatial relationship with the visual palette (screen). Artifacts in a web application have designated places. Any shift in these places usually causes lot of problems--especially to find these elements by novices and experts alike. To understand the places of each type of element, the introductory pattern that I want to talk about is called "Layout of a typical web application." As we go along in this journey, this pattern will be key to understand other patterns.

Watch this space for the first pattern. Leave a comment with your email address if you want to be notified--I will send a mail.

Apple's troubles start with video iPod

The new video iPod from Apple will definitely be a mild success. It will be riding on the huge success of the iPod family which is used by millions to listen to lots of music, carry data, and occasionally show and tell about great photographs one has taken. However, to make it another iconic product as the original iPod, designers at Apple must think "big" again.

In each coast-to-coast flight or while waiting for connecting flights at the hubs, you would see many avid movie watchers trying to catch up on latest flicks. These guys are just everywhere - parks, restaurants, and trains. These frequent fliers and mass transit commuters like to see their movies on as big a screen as possible.

Roadblock 1
The biggest roadblock Apple's video iPod going to face is the size of the screen. The screen size is a little too small to have a meaningful display of moving images, it is at best a boy's toy to show around and boast about. Movie watchers may not bother to see a new flick or for that matter their favourite TV show on the new video iPod because of the screen's small size (320 x 240).

Roadblock 2
Movie buffs cannot enjoy the movie "Lord of the rings" with its numerous and detailed wide-angle action sequences on a 4:3 format. This roadblock will not make the video iPod more popular than other portable video players like Creative Zen or the Archos. The video iPod suffers from what I call the "hangover from the previous version" syndrome or you can call it "new wine packed in old bottle." But, it still has hope - Apple needs to get these roadblocks cleared at the earliest. The new video iPod could have wiped out all other portable video players out of the market now, it still can! This is how the movie Grease looks like on a regular video iPod:

Design Makeover
Surprisingly, iPod's size is its greatest strength. If the industrial designers at Apple place the iPod horizontally, iPod can exactly fit a 16:9 screen of 430 x 240 pixels - isn't that incredible? This placement will solve both the problems - size and aspect ratio. See how the new improved iPod can look like (did you see what all you are missing with the regular iPod?):

Oops! Where is the magical click wheel gone? I don't like my iPod without the wheel. Apple can magically get back the click wheel virtually, yes virtually! A circular segment of the screen can be touch sensitive and an image of the click wheel below can appear. This image can appear whenever a human touches the wheel part of the screen. It can magically disappear after some seconds of inactivity. A click wheel can look like this when it appears:

With these improvements, I would like the purchase the iPod and enjoy two full length and full width movies from NY to LA. Is there anyone who can take this up with Mr. Jobs?

Movie screen grabs are from http://www.geocities.com/obsessivetougafan/grease.html

Reva Electric Car - no recharge but change

Reva Electric Car is very slowly showing up on Indian roads--mainly on Bangalore roads. It's a treat to see Reva zipping past without noise, huff, and puff. The car is good for young and old couples who need short commute within the city. Young show its Eco-friendliness and old enjoy its economy of running as the gas prices are shooting through the roof.

I would like to see this car making a grand worldwide success. I would like to suggest an idea to my dear friend Samrat Navle, who is an Industrial Designer with Reva Electric.

Provide Battery Change Points A big trouble with this car is a short running distance. Many times the commute becomes unpredictable - its may not be just from home to office and back home. Reva or their franchisees may have to invest in a supporting infrastructure that helps in a quick recharge. Now, this quick recharge is not actually a recharge, but a quick change of batteries.

A set of batteries are kept fully charged at a refill station which can be a gas station. A car can quickly change the set of batteries at a cost. This will ensure that a car is always charged, batteries never have to be bought (even once in three years) by the car owner, and gas stations have another revenue stream.

A change in car design for quick change of batteries (a worker must NOT unwire and rewire the connections each time) and pre-charged batteries at major gas stations in the city will drive Reva sales.

Tree View Removal Surgery

You must have seen and experienced many enterprise software applications that have tree views as primary navigational strategy. These application interfaces mimic the system’s underlying data structure for primary navigation. The underlying data structure may be highly efficient in organizing, sorting, and finding the data by the computer. However, it fails to help users find and manipulate data. It only helps users get frustrated and irritated instead.

A big semantic distance is the cause of this difference. Semantic distance can be described as the difference between conceptual model of the user and the system. High semantic difference makes navigation in these applications cumbersome, awkward, and highly inefficient for novice as well as expert users.

In a multi-hierarchical, deep navigation, and complex workflow based software applications, it is common for users to forget the hierarchy of the element they were working on. Tree view does not solve problems, it, in turn, creates too many problems to solve. As tree views remain an important navigational widget in several interfaces; let’s try to solve the “tree view as navigation” problem.

Step 1: Remove Tree View

“How can I do that?” If this is your immediate reaction, you definitely are a weak hearted development manager. If you have a strong heart to reap long term gains, I am sure you will stay here.

There are two recipes to remove tree view: 1. Just remove it – My recommendation 2. Reduce it, and then remove it – For the development managers who are really not convinced about removing tree view.

Let’s go through these steps to reduce the tree and to help users find things at the right place.

a. Remove the root node: Typically, the root node of a tree is an element that is needed to hold the tree together – it does not have any significance in the project. It will typically be named project, or workplace, or root node, or root, or something else that does not make any sense to anybody.

By removing the root node, you will gain about 30 horizontal pixels and one less click each time user tries to find something. User will gain by less horizontal scrolling and far fewer clicks during the day (my Carpel-tunneled hand is already feeling better!).

b. Freeze top-levels: In our experience, a tree view that have more than 2 types of nested artifacts confuse the users – files in a folder or folder within a folder is okay, but sub-process in a process, process in a business location, business location in a business, and a business in an enterprise in NOT okay - it increases cognitive load on the users and thus confuses the users.

Most users never deal with top level tree nodes, they work with nodes that are somewhere at the bottom of the hierarchy. Most users never change the top level nodes. So, it is wise to move the top level nodes outside the tree structure. These artifacts now become the default for a user throughout the life-cycle of the usage of application – users never have to re-select the default one – the application understands this default for all activities that the user performs. However, in some cases when the user wants to change the top level artifact, it needs one extra click.

Making one or two levels of the tree as default for users will save a lot of confusion and reduce the tree dramatically. Again saving horizontal scrolling, fewer clicks, and less confusion.

Remember to show the defaults always (and way to change them). These artifacts can be shown in dropdown boxes placed above the tree. Alternatively, they can find some place in the header of the form.

c. Keep Nouns, move adjectives and verbs: Many a times, a tree view in an enterprise application contains artifacts like files, actions, tasks, etc. This type of hybrid scheme is confusing as it creates huge semantic difference. To understand what can be a part of tree and what cannot be a part of tree, a tree view must mimic colored marbles in a glass jar. You must keep only artifacts that are nouns and remove artifacts that are either verbs or adjectives.

Move properties (adjectives): You understand that some marbles are small, some are big, some are spherical, some are like footballs, and some are transparent, while others are colored. These are all properties of marbles and properties are not marbles themselves. However, in many tree views, we see that properties are shown as tree nodes. Remove property nodes and move the content to their respective parent nodes.

Move actions/tasks (verbs): New Marble, New Marble Color, and Remove Marble Shape – these are also oft seen tree leaf nodes. These cannot be a part of the tree structure. Move them as a part of the parent leaf node.

d. Move terminal leaves to content area as list: This exercise must be done after you have put your nouns, adjectives, and verbs in place. Terminal leaves are not grouping elements – they cannot be further divided. A further division is only possible if you are showing their properties. Examples: Emails, files, etc.

Move terminal leaves out of the tree and place it as a list or table with properties in the main content area.

e. Remove links to log files, property files, etc. These are never required; however, if it is necessary to show them, do not increase one node in the tree.

f. Change marketing names to generic names: Users really get confused with new names of usually understood artifacts. One company named its checking account as “ActiSave,” while another trademarked business policies as “QuiRule.” And, poor users had to learn their vocabulary again – thanks to marketing guys. Change all marketing names to generic names.

I am sure, after completing the above tasks; your tree would look like a list or a shrub that is just 2-3 levels deep. Are you still in love with the tree you nurtured for so long?

Step 2: Provide an overview screen

Any application that depends on a tree structure for primary navigation cannot be considered as full application. This application is, at best, some forms somehow stuck together within a tree over a period of time. The user is left alone to understand the complexity and make all navigation decisions – whether or not they are right.

In enterprise software applications, the first screen users hit upon is a welcome screen – the only piece of data on the screen is your name – wow! Now you know that the software has recognized you correctly. Some applications go a long way and ask you to select a project (top most level tree node) from a very long list containing “one” project. Couple of pieces of advice – chuck the welcome screen and throw away selecting first level of tree node. Give users what they want to do by using an overview screen.

An overview screen is a great way to upgrade a bunch of web-based forms to a real application (and get rid of the stupid tree too!). To fulfill users personal and professional goals, a real application not just holds a bunch of forms, it helps users (at all times) to begin and complete their tasks efficiently. The user is guided through the task using appropriately placed markers and signs. The overview screen is used to:

a. Guide first time users of the application: First time users of the application must be guided to setup the application quickly so that they can test some major tasks. Guided help in completing early tasks will make users very comfortable with the software and also help users establish a good rapport with the software. This will ensure that there are few early dropouts and far more recommendations.

Many early tasks are dummy tasks that users will never make use of – these will be used for learning and testing the software. Any help in removing the dummy tasks and data, will help users immensely.

b. Show the major tasks that can be done: List the key tasks that users can do using the application upfront. Listing of these tasks will ensure that users don’t search for artifacts first and then act upon them – it will ensure that users find the task first and then select an appropriate artifact.

c. Help users when they come back to use the application: Application is most used by repeat visitors, first time visitors are few are far between. The application must be optimized for repeat visitors. These visitors need to complete their incomplete tasks, start new tasks, find information about other elements while completing tasks, etc. On the overview screen, to help these repeat visitors:

Provide a list of incomplete or pending tasks: This list is critical for workflow based enterprise software applications. Without this list, users will have to go through tree hierarchy to find out what tasks are either assigned to them by others, or automatically by the system, or tasks that were saved for later by the users themselves. In this list, provide the name and basic identification information of the artifact, the type of task that is due, the date that is due or overdue, and links to finish the task.

Provide a task history or screen history list: Typically, there are few fresh starts – at most times, users try to finish or continue tasks that are pending or were saved for later. A linked task history list will help users continue working on artifacts or tasks that they were working on last time.

Step 3: Predict user behavior

There were many Java development environments, but IntelliJ and Eclipse revolutionized Java programming. The reason is simple, they facilitated user behavior. If a file was changed by the user, the user could immediately see and change all dependencies – they did not have to compile the code to know if there were any problems. Result – few compilation cycles, very early detection of problems, facilitation to solve problems, and therefore good user productivity (happy users).

In workflow based enterprise applications, behavior of users can be predicted with fair degree of accuracy. This can be done by understanding the current user practices, organizational practices, and through meticulous contextual inquiry and observation techniques.

As mentioned earlier, applications that use tree view as primary navigation cannot be considered as web applications, they are just a bunch of forms sewn together. To make it an application, the application must predict user behavior and facilitate that behavior.

Step 4: Provide an efficient search mechanism

Having said that users are predictable, we understand that many times user interface designers are unable to predict what users are going to do next. There are situations that users must find old artifacts to refer to or other such tasks. In situations like these, it is important to support user activities by helping users find the required artifacts or information.

Many a times, the search information that the user provides the search engine is sketchy – contains peripheral information, contains information about properties of the artifacts, or contains information about the relationships of the artifact. The last thing you expect a user to remember is the name of the artifact (that too with correct spelling and case!).

a. Provide a text field and a search button. Avoid categorization of search criteria here. Search everywhere – not just in names of artifacts. b. Search results must be shown with artifact name, description, and key relationships of the artifacts. c. Pardon and help users who cannot write correct spellings or are case handicapped.

Step 5: Provide a way to bookmark places

There are places in an application where users regularly visit. There are also users who seldom use the application and when they use they need to reach some places quickly – not through the navigational maze. A way to bookmark a place is a good way to get users going pretty fast. Provide a one click way to bookmark the current page and provide a link to quickly see the hyperlinked and alphabetically organized bookmark list.

And, don’t hesitate to show tree view too The tree view may not be the navigational metaphor, but in certain circumstances it may be necessary to show a tree view to facilitate understanding about the relative grouping. You can show a hyperlinked tree view too if needed. Remember to hide it again as fast as the task is done.

Why is a tree view a poor navigational choice in software applications?

Recently I found myself staring at another Enterprise Software Application (ESA) that uses a tree view as primary navigation. A tree view on the left is usually not the right choice for navigation in such applications. Here are some reasons why tree views make a very poor choice in an ESA:

1. Many types of artifacts: Typically in ESAs, the tree is composed of artifacts like actions, files, and tasks. This type of hybrid scheme is confusing as it makes it difficult for users to make a consistent mental model.

2. Non consistent mental model: A non-consistent mental model increases memory load and makes learning difficult. Even experienced users make mistakes if there is a hybrid scheme.

3. Many points and clicks: To find any action, file, or a task, a user usually takes many points and clicks.

4. Clicks are actually slow: Though pointing and clicking seems lightning fast, but remember Fitt's Law - each point and click takes a whooping 1 to 1.5 seconds! Each find and final click may take anywhere upwards of 10 seconds.

5. Poor navigational help: A tree structure offers poor help to find and select next logical task after completing the current one. It forces users to learn the next logical step.

6. No use of spatial memory: People use spatial memory to find artifacts on a screen. However, the tree structure does not support spatial memory - makes it harder to find artifacts. It also increases the time to find artifacts.

7. Poor location information: A tree typically provides poor navigational clues - does not tell where the user is now, what is clicked, and what is open. To provide all these clues, a software developer spends a lot of energy.

8. System model differs from user mental model: A tree helps software developers put artifacts as in the systems model. This model is usually very different from the user's mental model.

9. Takes too much of space: The tree typically takes more than 20% of screen space. This amount of space for navigating from one point to another is a waste of precious screen area.

10. No corresponding content: Software developers believe that each "leaf node" in the tree must be associated with a corresponding screen. These corresponding screens typically dont contain any content and are shown blank or with content that users never need.

11. Vertical and horizontal scrolling: In most cases the tree is open. In this position the actual content is hidden behind the scrolls. This does not help users to find out where they are.

12. Difficult to implement: Contrary to popular belief, implementing a tree view by a developer is very difficult and time consuming. The basic implementation is fast, however, tweaking the tree view for good user experience is time and resource intensive.

13. Only IT users understand deep hierarchies: In our experience, we have experienced that only IT (read developers) understand deep tree structures. Others just refuse to understand tree structures with more than 2 types of artifacts (like files and folders). So, files in a folder or folder in a folder is okay, but sub-process in a process, process in a business location, business location in a business, and a business in an enterprise in NOT okay - it is confusing.

And, here is a solution you may want to look at: Tree View Removal Surgery

Usability in Elearning

This post appeared some weeks back at IDiot. As the conversation is between me and the owner, I am shamelessly copying the converstion here.

Kern offers two kinds of services -- usability and elearning. Often our clients inquire about this holy matrimony of usability and elearning. I think usability lends itself naturally to any elearning solution. This got us into an interesting discussion about how usability impacts learning solutions.

Geeta: How do we apply the learning from usability to our elearning projects?

Ripul: Usability is a measurable attribute where we measure the usefulness of a product. We can apply the same concepts to elearning where we measure the learning ability or "learnability" of learners. The basic premise of usability is to make something easy and useful. At times, things may be easy to use, but may not be useful for the user. So, applying the same principle to elearning, we can make things easy to access as well as more learnable for learners.

Geeta: That's right. But often usability is limited to UI issues where the focus is more on the "ease to use" of elearning. For example, the focus is more on making the interface student-friendly, make navigation simpler, and reduction in download time. Whereas, usability in the real sense should focus on the "learnability" aspect of the courseware. So, how do you think usability can enhance "learnability"?

Ripul: Learnability can be enhanced by designing a courseware based on learners' needs, goals, and aspirations. To do this, first, we need to have a clear understanding of the learner; analyze their demographic and psychographic profile; understand their needs and motivations; and then come up with a design that best suits them. elearning organizations can adopt user research processes and techniques like contextual inquiry and observation to understand the learners, their learning goals, learning motivations, and the current learning patterns. This will also help organizations understand how learners use learning while working.

Geeta: This is exactly what must be done in the analysis phase of traditional elearning. Sadly, in a real world elearning scenario, the analysis phase is a mere formality, more so when content development is outsourced (will blog this sometime). In such a situation, the client is God and the subject matter expert (lovingly known as SME) is demi-god! They drive the requirements, provide the learner details, and define what strategies to follow. Amidst all this, we forget the plight of the poor learners who are left with no choice but to wear sweaters in summer! (as exclaimed by Sow!) More often than not, instructional design is decided based on: - the engine capabilities - standard successful strategies - client's preference - budgetary constraints, and - SME's diktats

Ripul: That's precisely where the problems come up regarding the effectiveness of learning. The course has to be designed as per the learner and not based on client requirements alone. Business stakeholders play an important role in the process, however they should not drive the design. We must design for our learners. There can be no "one size fits all" in instructional design. Gagne's nine events are not the holy grail of instructional design -- all learning challenges cannot have a single solution.

Geeta: To get back to our discussion, we can apply our learning from usability optimally. We can offer good UI solutions, make navigation intuitive, simpler, and reduce dependence on secondary instructions. We can use contextual inquiry process to derive learner requirements to complement stakeholder requirements. We no longer need to hide behind "interpassivity" to engage learners, we can ensure that the learner really learns. But tell me how do you measure actual learning?

Ripul: Learning can be easily measured using usability testing methods. However, I feel, these methods need to be adapted for learnability testing. Current usability testing methods are highly skewed towards correct navigation and completion of tasks, which is not the main focus while learning. The usability protocols must be designed to measure effectiveness of learning.

Geeta: The effectiveness of learning is in achieving the learning objectives that the learner has set out to achieve in the first place. Therefore, learnability testing should ensure that there is a one-on-one mapping with the learning objectives at the learners' workplace and not just in a laboratory setup.

Ask your employer these questions - Freshers

In the past few months, I have been asked a million times about how to choose a suitable company for a usability job. Most people who have been asking me are fresh graduates from NID, IDC, or from a US university. In India, the choices are few, and making a choice is very difficult. However, each company offers different usability jobs and has a different hidden job description. Here I want to demystify some of these things.

Companies looking for freshers dont expect freshers to contribute from day one. They want bright freshers who can learn and can apply usability principles in projects later. So, show that you want to learn, want to experiment, and can ask questions. You also have to show that you are willing to do any kind of usability work that is given. Anyway, you will not be pushed into a big project in the beginning. The company will not take that risk - however good your academic scores or academic projects are.

There are two types of companies that offer usability jobs in India - usability consulting companies and software companies. In India, you will may not find financial companies, insurance companies, call centers, or manufacturing companies offering usability jobs. So, which type of company would you choose? Ask all these questions, I am sure you will be able to find answers yourself.

1. Mentor As a fresher, you would need a friend in a mentor to help you learn the ropes of usability. During your first interaction with the prospective employer, you must find out who may be your mentor:

a. how many years of usability experience your mentor has? Usually more years the better, however, more experienced people are either hard to find or are not accessible. So find a mentor who has good work experience and not a fresher. A person who has worked in a software company as a usability engineer may understand "ground-level" usability. A person who has worked all her life in a consulting company may not relate to ground-level implementation issues. On the other hand, people who have worked with a software company may not have any usability testing experience.

b. what is the type of usability experience does the mentor have? Check if the mentor has complete lifecycle projects experience - from contextual inquiry to real-life usability testing. I am sure this is going to be a tough one, but this is really important for your first job. The wider and more project experience your mentor have, you will be productive quickly.

c. how accessible is your mentor? Many organizations boast of best people in the field of usability. And, freshers fall for their credentials. However, these people are never accessible. You will never learn anything from them. They are as good as not being there. You need to find mentors that are accessible regularly. In some organizations you may find mentors who have relatively less experience but are very accessible - that's what you may want to look for.

2. Type of work As a fresher, no company will risk putting you on bigger projects. They would rather start you with small projects and judge you periodically. But, many companies promise you with big projects in the beginning - dont fall for those promises - they will never be met! Find companies that promise you good learning and put you on projects progressively as you perform better.

I know of some companies which will only make you perform "heuristic evaluations" for years (and I really mean it!). They will not let you do any other kind of work - no contextual inquiry, no design, no testing, no nothing. They work on low cost India model for getting heuristic evaluations done - they will not move most guys to design or testing. Beware of such companies.

Usability consulting companies are good if you already have some years of usability experience and you want to broaden your experience. However, they may not be a right career choice while you are starting your career. The reason is that you will never get to see the light of day of your projects.

Find software companies that are usability focused. They are ideal breeding ground for budding usability engineers. However, find out about your mentor(s) and find out if you will be able to talk to users and do usability testing.

3. Access to development teams A complete architect is the one who can visualize the building and can supervise the construction too. However, in Usability, most projects go out of usability person's hands after usability testing of wireframes or mocks. You never get to see how programmers develop the mock. You never get to see what problems are coming up because of design. You never get to juggle between technical difficulties and usability issues. So, find out about access to development teams and how much access you may have with them after you create mocks or prototypes.

4. Location Some people say location does not matter. I say, it does matter a lot. Cost of living in Hyderabad is half of that in Mumbai. Quality of life is better in smaller cities because you can stay within 5 minutes of your office and not spend 2.5 hours one way just to reach office. You can work more or meet up people more often in smaller cities. And, you can catch up with films without waiting for the weekend.

5. Travel Entry level jobs will NOT have travel. If someone tells you that there will be a lot of travel involved, take it with pinch of salt. Travel will happen only if you can show that you are capable of doing projects well.

Some words of caution for experienced usability professionals - Some usability consulting companies in India will require you to travel to the US on a business visa. They send you on pretext of "training." However,they will expect you to "work" on projects there. They dont want to spend too much money on work visas - as long as no one gets caught by US authorities, its perfect by them. If you travel to US on business visa and "work" there, you are very likely to be "caught" by authorities. So insist and ensure that you go only on a work visa to work. Business visa is only meant for meeting clients, meeting users, and training.

If you have a spouse in India and you are required to travel for longer periods, please ensure that the company you join must have spouse friendly policies. Ensure that the company pays for your spouse's visa application fee, return airfare, and provide decent accomodation for a couple. Also ensure that the money that you get (per diem) is sufficient for both of you to "survive" in expensive countries like the US and UK.

6. Remuneration Yes, your favorite subject! Someone told me if she gets Rs. 6 Lakh (0.6 million), she will join a company. I asked her why do you need 6 lakhs? She replied "If my friends at Veritas and Oracle can get 6 Lakhs, why can't I?"

Good remuneration is good for you, however, if a company can offer you good learning at the beginning of your career, you can sacrifice remuneration. You will have ample opportunities to earn more - better you are at your job, better remuneration you can command later. You must strive to learn and perform in your first job.

Talk to your users

Talking to users is the first and the most important aspect of designing a software product or application. Talking to the users can be done in many ways - Ethnographic studies, contextual inquiry and observations, questionnaires, card sorting, affinity diagramming, etc. All these user research techniques help in user interface analysis, design of appropriate scenarios, help in layout and visual design, and design of protocols for usability testing. User research also helps the product development team arrive at appropriate functionality and prioritize it.

However, in small and medium-sided software product companies, it becomes very difficult for usability professionals to conduct any meaningful user research. Software product companies create many barriers between the usability researchers (or developers) and users.

1. The Chief Technology Officer of a small sofware product company in India was of an opinion if users can talk to the development team, they will disturb the development process. The users will constantly call or email them with bugs, discuss ideas, give suggestions, and would want them to solve all support queries.

2. Sales and marketing departments don't want the product team to talk to the users. They don't want the team to talk to satisfied users because such talks may make users dissatisfied with the current product. They also don't want the product team to talk to dissatisfied users because the users may feel that the product is really bad.

With the above excuses, even a good product idea can see a slow death. First commandment of usability is "know your user."

You may want to see how McAfee understood their users to fuel a successful product.

Where is the learning?

Companies are moving their instructor-led training material to self-paced elearning (first generation elearning) to save costs, manage learners, manage scores, manage multiple courses, and feed this data into the human resource software for employee performance appraisal.

But, what happened to the learner and the quality of learning? Earlier, learning was instructor- led and it had pedagogic roots of classroom training methodologies. However, the same methodologies cannot be replicated to a self-paced learning system. The instructor also used to keep tab of individual learning needs and styles. Moreover, adult learners prefer instructor-led face-to-face learning than learning through the use of electronic media.

As learning moved to elearning, the variety of methods earlier used by the instructor reduced drastically to rudimentary instruction methods (read Jurassic age!) provided by an LMS. Now, e-instructors have to confine to drag-and-drop or 3-answer MCQs to test learners' procedural knowledge. As the manageability of the learning increased, the quality of learning suffered.

Corporations have also started singing LMS tune - the score of the course is directly proportional to the learning, which is directly proportional to employee remuneration. Corporations fail to realize that learning must be measured by measuring the quality of output at work and elearning score is no indication of performance. Training managers and HR managers must understand that learning and training is in context and must be measured in context - the context being the work environment.

Ranking features in functional requirements

System functional requirements is a laundry list of all the requirements and features of the proposed system. It conveys that all functions and features are equally important. The reality is that the features that requires minimal coding are taken up first. Features that require a lot of coding or that cannot be achieved using the current API are also delayed.

There is much written about feature prioritization - Coad proposes a technique of ranking features according to customer satisfaction if the feature is included. Moreover, ranking them by customer dissatisfaction if the feature were ommitted. This will give a clear ranking of the features.

On the other hand, the feature list is the first step for a Usability Specialist. They need to order the list to rank each feature. Each feature is ranked according to the functional necessity and frequency of use. This ranking can be achieved after the task analysis process. The ranking is required to understand where the Usability team should concentrate on - the 80/20 rule.

Cracked Programmer Creole!

Are not abl;e to see this slide. this slide has mainly bullets and the link opens site. If you can see the site which opens in a diff window the QuickStart/Control Practices can be seen. You cant understand any specific thing we will send thiss to Jen.

Crack: We are not able to see this slide. This slide mainly has bullet points as links. Each link opens a new window. If you can see the site, you will be able to see Quickstart/Control Practices. If you can not understand anything, we will send your query to Jen.

I spent about half hour to crack this - fast! Am I am qualified to be a programmer now?

Web-based applications' data entry guidelines

For designing a data entry system, the guidelines differ according to these key parameters:

1. Domain knowledge of the user (for semantic errors)
2. User training and experience of the user (typing mistakes, cultural conventions)
3. Data source (paper, scanned, another program window, audio, etc.)
4. Data entry technology

While using paper (or similar) based source, a very strong co-relation exists between the layout of the data entry forms and the structure of the associated data entry screens. To require a user to scan and re-scan in input form to locate (and re-locate) various data entry fields invites significant errors.

Regardless of the technology used, there are various techniques used to reduce data entry errors:

1. Long string reduction (from 146734678453 to 1467 3467 8453)
2. Mnemonic re-structuring of semantic data
3. Co-related screen layout for paper based entry
4. Elimination of social amenities like please, do you wish, and if you want among others.
5. Native language input cutomizable according to demographics
6. Standardization of terms, abbreviations, and conventions accoriding to users' domain knowledge
7. Early identification and structured display of errors either inline or spatial
8. Empirical default entry strategies for greater than 80% chance of selection
9. Automation of entry completion
10. Inclusion of error toleration like synonyms, homonyms, and vowel elimination or replacement in spellings among others.

Design of rich internet applications

Rich Internet Applications, in my experience of building large call center applications (yes! web-based), are a mix of page-centric HTML and the GUI applications. They trying to achieve the rich interactivity of GUI applications in a web scenario.

As we all know, 80% of usability is navigation. RIAs are breaking the paradigm of "navigation metaphor." Moreover, navigation is changing its meaning -- it has got many visible layers now.

The first layer has closed or partially open windows (sliding windows). These metaphoric windows contain information needed for successful completion of the immediate sub-task. These can take shape of a tooltip, a layer for quick selection, etc. It can also be quickly show the contents so that users can make a decision. This is information "on the fingertips."

The second layer has open windows. This layer consist of information or subtasks that are needed or performed by the user "regularly." For example, in a call center application, name of the customer is needed all the time by the user to address the user many times during the call, while the user also changes the customer address/phone numbers most of the times during the call. This navigational layer must always be visible and "accessible."

The third layer is a door that leads to another room - usually another page (or screen, or pop-up window, or similar artifacts) where the user must "go" to perform a task. These places are usually reached when the user performs tasks that are either not regularly performed or have information that is not needed in most scenarios. This layer is also usually reached navigating through layer two, however, shortcuts for advanced users do exist (depending on the personae).

In such navigation scenarios, the challenge is that the information and tasks must be findable on a screen (or page) vs. finding them on other pages. The scent of information through appropriate grouping, visual hierarchy, and spatial placement of artifacts on the screen gets very high importance.

My questions are: 1. How much support do popular webserver platforms such as Weblogic, Websphere, or Macromedia's JRun provide for RIAs? 2. How do RIAs cope with thousands of users logged in together, asking far more data than simple cookie based applications (page by page navigation approach)?

Joel and Napster's Affordance

While paving my way through the blogiverse trying to find familiar people, I stumbled upon Hejip, an old colleague and friend. In his blog about usability, he did mention Joel - who has now become the de-facto usability guru among software developers - Cooper is another. However, Nielsen and Eric do not find too many software takers as they talk about public websites and intranets and not real software applications.

Coming back to Joel and his old blog Its not Just Usability, was affordance of Napster really that bad? I don't think so. There are many reasons why the buttons on Napster are as good as tabs:

1. Position: The position of the button was at the top to mimic the position of the tabs. If the buttons were either on the right or bottom of the screen, Napster may not have a story to tell. Buttons on the right or bottom mean that they are action buttons and are clicked "after" the user feels that the action is complete. These buttons are never perceived as navigational elements. However, buttons on the top and on the left are typically perceived as navigational elements and are not confused as action buttons.

2. Shape: The Napster buttons were rectangular and placed horizontally - the approximate shape and the placement of tabs as we know them. The size of the buttons also was very similar to a regular tab.

3. Mutually Exclusive Affordance: The buttons gave good feedback that only one can be selected at a point of time - only one button (the selected one) was depressed. If any other was selected, the selected become the depressed on while the previously depressed came back to normal position. The affordance of buttons being mutually exclusive was very good.

So tabs could have been better? I don't think so - they would have been as good. Napster confirmed to good Usability principles while using buttons. However, that was not the reason that Napster was popular (Joel would agree too!) - the popularity of Napster solely lies with the usefulness of the software in social settings. Even if Napster's usability was bad, I am sure it would have been as successful.

Cutting edge product idea - a conversation

One of my regular client contact who works with a "cutting-edge" technology company invited me for an informal chat about a revolutionary new product idea. According to the client the product idea could potentially be a gold mine. I said wow! I also quickly landed up at their now-impressive office - once again. The earlier state of their office and the state of chairs is definitely bloggable sometime, I promise.

Powerpoint presentation with a cup of machine made coffee was my introduction to the grand new product idea. We will use the latest technology. Impressive! I must say.

So who are your users for the product? Hmm... let me think... the users is the XXXX industry in general.

No, I mean, who in the XXXX industry will use your product? The XXXX people who design new products will use it.

I think I need to make myself clear - what is the designation or job role of the person who will use this product? He is definitely the person who is an industry expert. I think he may be a VP or something...

What do you think this person will do using your proposed product? He will design new XXXX programs.

How many times do you think these programs change during a day? I dont think they change daily. Weekly? Nah. Monthly? May be, but I dont think so. 6 Monthly? I think so. 1 Year? Some may change... actually it depends on the XXXX company.

How do you think these products are designed? They analyze previous data, put in their hunches, see if the hunches are true, then they simulate the data, and then propose a new product.

Can I call up my XXXX manager, he may have some information about this industry? Sure... let me pick up another coffee... the office AC is working today.

Hey Jayram (my XXXX manager), can you tell me how XXXX products are designed and who designs them? In my company, a new product team designs these products and the team report to country head directly as these products are crucial to our bottomlines.

That's cool, but how do they think of new products? Market pressures, competitors, government policy changes, the reasons can be many. I can get you in touch with one of my friend's who works with that group, interested? Yup, I said.

So where are we? Can we meet up tomorrow, I have a meeting planned up before lunch. I will try to get all the user information that you need. Why dont you start thinking about the user interface. See navigation is simple, I have worked it out...when do you think wireframes can be ready? I need to show proof-of-concept in June and a beta launch by October... I am sure you will come up with something really nice looking...I liked the one you did with our web-based console some time back. Ok see ya tomorrow.

But... but... users?

User-centered innovation

Understanding users (different from "customers") is a critical part of the innovation process that most technology companies in India either miss or are ignorant about. Today, this is one of the key reasons why Indian software services companies like Wipro and Satyam cannot produce innovative software.

Organizations believe that customers are users, however, in reality most customers are NOT users. As service companies, we focus on our customers but we completely ignore the users who will use the application or the product.

Typically, customers have no understanding of their users. This leads to:

• Open ended functional specifications that change during the development lifecycle
• Most functions get similar priority. Or, arbitrary allocation of priority so that functions that require least time to develop are developed first rather than those critical to the users.
• Non-use of many functions by users
• Non-completion or partial implementation of critical (read day-to-day) functions performed by users - leads to user dissatisfaction and huge number of support issues.

What do innovating companies do to understand users?

• They ensure proximity and access to users
• They make Ethnographic studies, contextual observations, and inquiry techniques a key part of software development process

Customers who are geographically near their users and have understanding about users' day-to-day functioning, motivation, goals, and environment are the only ones who provide innovating ideas - understanding users always trigger innovating ideas. Innovative technology companies understand the users directly or by employing user research consulting companies.

How will understanding users lead to innovation?

Any innovation can be traced back to change in the style of work or leisure. This leads to positive changes in the users' life. The process of innovation begins with deep understanding of what the users actually do, their characteristics, their needs, their motivations, their experiences with the world, and what they care about. Successful collection, analysis, and synthesis of user data triggers innovative thinking. The insights that businesses get about their users help them make innovative applications and products that users enjoy and recommend.

Caller tunes feature usability evaluation

I like caller tunes (or hello tunes) as much as I like powder coated metallic blue hand cuffs.

1. Poor Feedback - The earlier tones give clear feedback about the state of the call. In caller tunes, the caller does not get any feedback. They don't know if the called phone is ringing or busy. The result is quick and multiple hangups by callers.

2. Mental Model Mismatch - The caller expects a familiar ring or a busy ring. Any other type of ring is a surprise and frustration.

Mobile companies' revenues may go up. There are two reasons:
a. More missed calls to the called number as callers hang up in surprise. The called person then rings back the "familiar" numbers thereby increasing the mobile company's revenues.
b. Revenues from caller tunes feature subscription.

Mobile companies' revenues may also go down due to lost revenues in calls that never connected.

There may be a user population that will use this feature - there is enough literature available on gift giving behavior among young adults. However, I have not seen any ethnographic studies or usability tests published on this. Any links?

Age-old practices in the ‘New World’: A study of gift-giving between teenage mobile phone users
by Alex Taylor and Richard Harper presented at CHI 2002

The Gift of the gab?: a design orientated sociology of young people's use of "mobilZe!"
by Alexander Taylor and Richard Harper Journal of Computer Supported Cooperative Work (CSCW) 12(3), 267-296

Key usability issues (and solutions!) in customer service software

1. A very high percentage of outbound calls land up at an answering machine. Leaving standard messages on the answering machine is routine and takes a lot of user's time.

This task can be allocated to a computer -- an automated message delivery will drastically reduce the call time. In certain cases where the customer decides to pick up the call, the computer can seamlessly give the control to the Customer Service Agent (CSA).

2. Most calls are transferred to another CSA one reason or another. These calls are typically routed through a regular 1-800 number. Each transfer takes between 45 seconds and 2 minutes and this frustrates the customer. Some CSAs use this time for documentation by gaming the called system manipulating their placement in the queue. This helps CSAs to gain official work time. Customers also loose valuable time as the CSAs need to tell the called CSA about the manner in the customer was verified, the account number (or identity information) of the customer, and the reason for the transfer. The called CSA then starts with the routine "hello" that again frustrates the customer.

Find out customer queries that are regularly transferred and ensure that one CSA can answer all queries. This will enhance the customer experience and save expensive call costs. If the call must be transferred then ensure that:
a. The call bypasses IVR menu tree. This will ensure that the CSA doesn’t have to key in choices.
b. The customer verification information is passed transparently to the transferred CSA.
c. The transferred calls take precedence over the customers that are waiting now. This reduces CSAs idle time and reduces double queue waits for callers.

3. Organizations try to ensure that CSAs document everything that happened during the call. CSAs, on the other end don't want to be punished for not documenting. This ensures that whatever actions CSAs take using the system, they also document that. This documentation takes extra time, the CSA needs to remember what actions were taken (some are forgotten if the call was long).

Document only what was talked with the customer. Don't document the actions that were taken using the computer (the computer already knows about it!). The computer can automatically document this information for the next CSA to see. By doing all this considerable amount of effort and time will be saved.

4. Most customer service software is still Unix-based (remember Green Screens?). To navigate to a particular piece of information, the CSA must recall one of about eight hundred codes and key it in correctly. All this must be learned over three months.

Drastically reduce learning time by providing software application that does not require CSAs to remember unrelated codes. Provide software that does not need too much of navigation - for customer service applications 25 to 30 screen applications are enough. And, provide software that does not need much navigation as 80% work could be handled by the Main screen.

We dont require costly usability labs

We may all agree that most big-ticket usability problems lie in poor navigation - insufficient scent of information, poor organization, poor understanding of tasks and subsequent task design, etc.

To test navigation, in most cases, we do NOT require an elaborate lab setup. There are many low cost testing techniques that can be effectively used to understand navigational problems. These techniques do not require costly lab set-up or monitoring equipment.

Lets look at the list of activities that common usability tests have, and see if they really require an elaborate setup.

Pre-Test

1. Participant Screener - No
2. Participant Consent Form - No
3. Participant Demographics - No

Tests

1. Test of Self Evidence / Structure Evaluation - No
2. Label Wording / Task Wording - No. In cases where the users may have to initiate a task among many tasks, you may require a computer.
3. Card Sort - No
4. Task Completion - No. For hi-fidelity prototypes, you will need a computer for simulation.
5. Task Efficiency/Performance - YES an elaborate setup is needed.
6. Test of Brand Values - No
7. Test of Affordance - No

Post Test

1. Comments - No
2. Likert Scale Rating of usefulness, ease of use, learning, efficiency, and satisfaction - No

A tree on the left 2

• A tree typically provides poor navigational clues - does not tell where the user is now, what is clicked, and what is open. To provide all these clues, a software developer spends a lot of energy.
• A tree helps software developers put artifacts as in the systems model. This model is usually very different from the user's mental model.
• The tree typically takes more than 20% of screen space. This amount of space for navigating from one point to another is a waste of precious screen area.
• Software developers believe that each "leaf node" in the tree must be associated with a corresponding screen. These corresponding screens typically dont contain any content and are shown blank or with content that users never need.