Educational outcomes
Student:
- explains how to take into account the principles of usability through natural language (understanding);
- identifies and corrects errors in projects that violate usability rules (understanding);
- designs user interfaces according to known rules (application);
Justification
Modern programming languages ββare mostly based on the object paradigm. Therefore, its practical understanding is a necessary basis for working in this profession. Moreover, programmers often make systems based on analytical materials. And these largely use object-oriented graphical notations (such as UML). During this and the next lessons, you will deepen your theoretical bond, but first of all you will learn how to implement different concepts from object-orientness. This will allow you to design and implement modern business applications.
Graphical User Interfaces
Let's start with the question: what is (or was actually) the most underrated component of the software produced? This is probably the user interface, which for most modern software means: Graphical User Interface (GUI). Why is it like that? Why do programmers mostly focus on business application functionality by treating the GUI as a necessary evil? It is even more weird because users evaluate the application just through its interface, especially nowadays when programs with similar functionality are very common. Which one would you choose if their features are very similar? Probably the one that will be more suited to the price and the one that is easier to use. Fortunately, for the past few years, there has been an increase in the importance of application interfaces.
Graphical user interfaces are a cross-cutting topic in computer science (eg programming), psychology, ergonomics, and probably a few areas we did not mention here. Due to its interdisciplinarity, this subject is quite complex, and worst of all, sometimes difficult to measure. We mean here that it is not always easy to judge which solution is better. Fortunately, for some time, in computer science, and more specifically in software engineering, there is the usability concept.
There are many web portals devoted to this area. The most interesting ones would be http://www.uzytecznosc.pl and http://www.useit.com . Therefore, we will use some of the information contained there.
Usability
Generally speaking, usability is the ability to meet user needs by:
- a device
- an application
- an interface.
It concerns the combination of factors shaping the user's experience of working with the product. These include:
- Practical usefulness. Does the system perform tasks that meet the needs of the user?
- Easy to learn and operate. How fast can you learn to use the system? Is it easy for most people to operate the system?
- Effectiveness. Will the system ensure the outcome of the task as expected by the user?
- Efficiency. Is the desired result attainable with moderate effort from the user?
- Satisfaction. Does the user like to work with the system and recommend it to others?
As we can see, these factors cover many different aspects, ranging from utilitarian (practical), educational, to subjective (such as satisfaction).
Shaping usability
How can we shape usability? In general, we can say that the key is cooperation with users. During the entire development process we must have good contact with the people who will use our software. For this purpose it is worth:
- Conduct frequent user feedback surveys while working on the project
- Test prototypes (because they will be more then one) with target users - see below
- Observe the way users work with the system under real conditions
- Use survey techniques: interviews and questionnaires.
Usability tests
Once we have a piece of the testable item (usually some version of the application, but may be a paper GUI design as well), we need to perform a usability test. How to do it? Follow these simple rules:
- Testers must be representative. In other words, if we are doing an application for lawyers who are not computer experts, then we need to form such a test group. Usually, we pay for these types of tests (in the end, people do some work for us).
- Tests consist of performing specific (typical) tasks, eg for a text editor it may be writing a specificaly formatted letter.
- The essence of these tests is watching users. We evaluate, among others, the following aspects:
- What users do?
- Where are the difficulties?
- The whole test procedure should be recorded. We can use a video camera and/or special programs. Usually it is best to use both methods because simply recording the content of the screen will not provide us with full information on the reactions of users.
- To get as close as possible to the real working conditions, testers should be left alone. Therefore, during the entire test, it is strictly forbidden to give advice, help, etc.
Fortunately for us, in this type of test, unlike in statistical surveys, it is usually not required a large numbers of people (see the below chart). Typically, a group of 5, 10 people are able to capture the main problems of usability. People in more groups usually identify the same problems. Therefore, it is better to iteratively improve the project and test it in small groups (eg 10 times in 10 people) than do one test per 100 people.
You can also risk saying that it is more important to observe what the testers do than to listen to their later comment (which of course can also be useful). The reason for this is that the "current" reactions of people are more spontaneous. Later their opinions may change, for example due to the fact that we pay them (and they do not want to talk bad about our product).
Usability and business
As you can see from the above description, usability tests can be quite expensive. With a professional approach you need to have a special laboratory equipped with computer desks, a Venetian mirror, cameras and specialized software. Is it worth it? Let's get back to what we said earlier. In today's world many applications have very similar functionality. In that case, what criteria do the customers follow? They certainly take into account the price, but also ease of use of the system. And this comfort translates into satisfaction with the use of the application. And that, hopefully, will translate into our profits. For couple of years, we can observe a new trend: updated versions of applications do not focus only on adding new features, but facilitating access to existing ones, such as Microsoft Office 2007. You can discuss whether this new interface appeals to you or not. But the fact is: the main reason given by Microsoft to buy a new version of MS Office is a new, more useful interface.
Are there any ways to reduce usability costs? Of course! Before we start a new project, let's test its previous version (when we had one). Identify positive and negative elements. Let's strength the first and eliminate the latter. It is also worth to look at the solutions of competition (because usually we have one). In our work we should use (many) prototypes. They may also be "paper", but in the age of RAD tools it is not a problem to quickly produce a "fake" system prototype. In the case of iteration work each of them should end with tests. And do not forget to check the project in the context of known usability recommendations (see below).
And what are the benefits of high usability? We can certainly include:
- Shorter time to complete a task
- Reduce the number of mistakes made by the user
- Shorter learning time and less effort needed to master the product
- Confidence in the product and its willingness to further develop
- Persistent product satisfaction and the intention to recommend it to other buyers
Let's summarize optimistically: good usability just pays off!
GUI - good advices
Basic and general GUI guidelines can be summarized as follows:
- Consistency. The entire application should look and be used in the same way.
- Transparency and intuitiveness. In most cases, this means referring to existing GUI habits.
- Follow the guidelines for a specific platform. Every platform (such as Windows, Linux, Mac) has its own rules for building applications. In general, they are similar, but may vary in detail, such as treating application windows or using context menus. For this reason, they should be taken into account. Otherwise, the user will be annoyed that the application is not working properly. It seems that this principle must be applied especially in business applications. While the program is more "entertaining" (eg game), the greater the deviation can be made (up to a completely own GUI).
- Proper management of the screen space. Usually, this is down to the proper scaling of windows. Naturally, this does not always make sense, for example, when we only provide a few short information (eg login window), there is no need to resize the window. Nevertheless, this is a very important aspect of GUI quality evaluation, but sometimes it is quite difficult to implement.
- Smooth work. Users do not like when the computer does not respond to their commands. This may happen when it is busy doing complex calculations or for example waiting for a response from the database. In such situations, it is useful to inform the user about the progress of the operation (eg, current percentage, remaining time) or even to display a simple animated image of the occupancy.
GUI Checklist
Below is a GUI checklist (partially taken from http://www.uzytecznosc.pl) broken down into categories. Follow it during designing of your interafces, and when the implementation (or design) is complete, recheck that all elements of our interface are compatible with it. Some of these recommendations may seem obvious and trivial, but unfortunately you may come across solutions that break many of these rules.
Functional requirements
- Are you paying close attention to the functionality and appearance of the application?
- Is your window 100% consistent? Does it correspond to the design?
- Does it have all the designed functions?
- Does it have only designed functions? Do not place any additional (not included in the project) functionality.
- Do you help the user avoid common mistakes by skilfully designing the window? Is wrong data being handled properly?
- Is your window compatible with other windows of the same application (layout, controls, conventions)?
Platform Requirements
Is your project fully compliant with the interface/operating system guidelines?
- Uses appropriate controls, fonts, colors
- Proper window dimensions (including minimum)
- Correctly aligned elements
- Behavior of windows and controls
Deviations from the above recommendations may indicate a faulty GUI operation and/or lack of "system" modifications. As a result, for example, it may not work to scale the font size or change the graphic theme.
Requirements for windows
- Does your window have a title? Windows without or with a default title are difficult to identify, eg in the taskbar.
- Is this title the same or similar to the button name or option from the menu that opened the window?
- Are there buttons in the title bar (including minimize, maximize, restore, help)? If so, do they work properly?
- Is it possible to change the size (maximize, minimize) the window? If yes, is this justified? Is the entire contents of the window properly scaled?
- Is there a contextual help button?
- Have you selected the right frame type for your window (eg dialog)?
- Is your window properly placed in the hierarchy?
- Do you use modality (blocking interaction with other windows programs) where it is required?
Dialog window requirements
- Is there a default button in your dialog? Is it marked?
- Can your window be closed in the standard way? E.g.:
- button in the title bar
- Esc key
- "Cancel" button.
- Is it possible to close the window or select "Cancel" without making changes?
- Are the "OK" buttons, "Cancel" and other related window manipulation separated from other buttons?
Remember that the user always has an emergency exit from any, even the strangest situation. In other words, he/she does not be afraid to work with the program.
Widget requirements
- Do you use the intuitive layout of the controls and choose their types accordingly, instead of artificially describing activities and creating instructions?
- Are the controls positioned according to the way the user reads or scans the screen?
- Are the most commonly used options placed "at the earliest"?
- Is the number of controls in the window not too large? If so, is it better to delete some less frequently used or to show them only after pressing the corresponding button?
- Are you using the controls according to their purpose as described in the guidelines and used in popular applications? Eg.
- exclusive options: radio buttons
- multi options: check boxes.
- lists with multiple choice.
- Are your controls responding in a standard way? e.g.:
- press the buttons to execute the command or open the window
- radio buttons or check boxes should only change status.
- Are semantically-related controls grouped using frames or related interface elements?
- Are you not using frames excessively to group only individual controls?
- Does the software properly enable or disable inactive controls when needed?
Menu Requirements
- Is there a default option in the menu (and in the combo boxes)?
- Is the opening list large enough (vertically) to save user scrolling?
- Is the opening list wide enough so that each item is visible in full?
Label requirements
- Are there appropriate labels/descriptions (labels) that describe their purpose or content (especially for lists)?
- Are all the displayed data described?
- Are the descriptions aligned equally (in relation to the text of the control and to other descriptions)?
- Are colons in descriptions are consistently applied or not used?
- Do you use tooltips to explain some of the interface elements? Remember that the tooltips that repeat the standard description of the control do not make much sense.
- Do you use national (e.g. Polish) letters? Descriptions and names of controls without them look sloppy and less readable.
Keyboard requirements
- Are there any shortcuts in the window that allow advanced users to take advantage of some of the options?
- Can the user navigate the cursor using the Tab and Shift-Tab keys?
- Is the order of movement consistent with the layout of the box?
- Can you reach all the controls in this way?