Essay Topic User Interfaces-By Pouyan Kazemian

From SoftwarePractice.org

Essay Topic: User Interfaces By: Pouyan Kazemian ID: 101 969 31

The construction of the user interface is one of the most important steps in any software development lifecycle (SDLC). It determines how the users and stakeholders of a system judge its performance, mainly based on how easily and efficiently they are able to interact with it. A goof user interface can save time and money in many ways, while a bad one will only result in loss of user confidence in the system and in extreme cases huge amounts of money to fix the flaws of the system interface Unfortunately more often than not, developers leave this rather important step until the late stages of the Software Development Lifecycle (SDLC). Often poor interfaces are produced as a result of sub-standard investigation into the requirements of the user interface early in the SDLC. This can be prevented on many occasions if more attention is given to the initiation phase of the user interface in the Miniature Unified Process (MUP). To prove this, a group from the University of Technology used the MUP In a project called Assignment Scheduler, to create a user friendly interface for their users and stakeholders with some success.

It comes as no surprise that we often interact with sub-standard user interfaces mainly in the form of Graphical User Interfaces (GUI). This is because more attention is given to how a program is supposed to work and perform as opposed to how it is supposed to be perceived.^[1] Many designers try to modify the user to suit their user interface rather than the other way around. Often programmers are more concerned about fixing code errors than actually measuring the needs of the user.^[2] . As a result the needs of the user are ignored during the early stages of the SDLC. During its initial phases of MUP, commonly called Inception and Elaboration, the MUP lists a number of important issues that need to be dealt with early in the writing process of software and system development. In inception the scope and purpose of the project are investigated and in elaboration the structure and requirements of the project are determined, including the inputs and outputs of the system. ^[3] They clearly sum up what a system needs to do and that the needs of the users and the clients should be investigated thoroughly, through the use of many tools, including questionnaires, observation of the users, interviews and so on.^[4] Sometimes the needs of the client may clash with the needs of the user, which can result in poorly constructed software and user interface. One such area of disagreement is the cost involved with each project life cycle. The client may feel that the cost of each life cycle is not justified and too expensive. This is where a good designer must involve the client in the early stages of the project lifecycle as much as possible, so that such disagreements will not cause the ultimate end product of the process to be something no one really wants.^[5] While it is true that some of these processes may take time and money, in the end they assure the developers of the system that their proposed solution to the initial problem at hand addresses the needs of the users and the stakeholders. Without this information, what is system is supposed to do and how it is meant to be used for and perceived by the user may become a guessing game for the development team. This is extremely risky, since it can result in the development of a poorly constructed system and user interface. Therefore testing the user interface at every possible level of the software development stage to assess its useability is extremely important.^[6]

It is paramount that the proposed software adheres with the initial objectives set during the Inception stage of the software life cycle. However, many designers tend to go overboard, and give more options to users than they should. Options are important, while too many options confuse the user. When it comes to a user interface, often it is better if the designer makes the choice for the user, instead of creating endless menus and tool bars for the user to decide. For example in Image1 below, taken from a Windows based application, the user clicks on help, but instead of getting help they are confronted with a wizard about the size of the help database.^[7]

Image 1: Microsoft's Help Wizard which pops up when the user clicks the Help Menu^[8]

This is unnecessary as it confuses and delays the user form getting what they really want, help with an aspect of the software. This decision should have been made by the designer early in the development lifecycle of the project. If they spent time talking to more users and understood their needs clearly when it case to the help menu, they would have prevented this nuisance in the form of a help wizard. In Image 2 it is clearly evident that too many options are provided and this can only confuse the user.

Image 2: Too many options becuase of the desiners inability to make simple decisions ^[9]

It is very easy to develop a bad user interface, because it costs less money to develop it in the first place. If no attention is given to the user and stakeholder needs which ultimately determines the structure of the user interface, then less time and money is spent during the early stages of the MUP. A good interface can save money in the long run. If the user feels that they users understand how a user interface works, then they are less likely to ask for extra training sessions to use the software. ^[10] If everything is clear for them to learn how a user interface works, then they tend to be much more productive, instead of burying their heads into user manuals. This can be achieved very easily, through such tools as tabs and 3D buttons. In Image 3 the user can see where the tabs are and they afford the user to push them. The tabs create a representation of real life filing tabs, and the user knows how to get around them. These representations of real life objects help users to understand the software better

Image 3:Internet Exploerer use of tabs make things easier^[11] Making imaginary assumptions about the user and even creating imaginary profiles for the users of a system is an important way of understanding how a system is precieved by the user. For example, even though it is a stereotypical statement, a designer must always assume that users may have disabilities, such as the inability to read. This is because sometimes the developers tend to get too detailed and include too much information for the user to read as part of their user interface. For example, below is a window which has too many words on it. Most users would not even bother to read most of it. However in comparison with Image 4 is can be seen very clearly that too many words need not be on screen for the user to understand how to use a window. This problem associated with too much detail can be avoided through, researching the existing packages in the market and the user input.^[12] In Image 5 It is clear that the under interface itself can be clear enough not to warrant the use of paragraphs to describe a process. Therefore making assumptions about the user and even going to the extent of creating imaginary users for a project is an important way of addressing its useability.

Image 4: Too many words to descibe the process to the user^[13]

Image 5: Equivalent dialog from Microsoft makes it much easier for the user to understand what the window does^[14]

Even thought many popular packages out there are not perfect, many users are used to them and understand them better than other packages. Research into exiting products helps designers understand what users like in the user interfaces of popular packages and implement them in their own user interfaces It is a mistake to get creative, something than many developers and designers are guilty of, and change some of the tools that users love in user interfaces. ^[15] For example in Image 6 it is clearly obvious that the designers of the product wanted to create something different from existing Microsoft packages.

Image 6: Use of ill-chosen symbols instead of those that users understand through other software packages is confusing^[16]

Instead of Using the word “OK”, the designers have used a circle with a line across it. However it has only resulted in more confusion for the user to deal with. Is the figure No or is it OK? Being creative is good up to a point. The mentality that “just because they do it doesn’t mean it’s right” can backfire on the designers of the user interface. It is better to keep existing ways which users understand. For example, if Ctrl+S is for saving documents then it would be mistake to use it to spell check the document as most users use this command combination to save documents.^[17]

Despite the fact that designers and developers cannot predict every user need, there are fundamental steps that should be performed early in the life cycle process, which can directly effect the quality of the final user interface. Even though the user needs are important, information should be derived form other resources during the inception and elaboration phases of the MUP. Such areas include other disciplines, such as psychology and technical communications, and constant evaluations of the processes completed. This ensures that the designers are always on top of the project and understand which direction to take the process next. It will also ensure better understanding of the final user interface.^[18]

In a project called Assignment Schedule, the MUP was used to look into the final User Interface. During the Inception phase of the project the group began discussing the user interface and how they wanted to display certain information on screen. During elaboration this process was taken further and graphics were produced to convey how the final user interface was to look. In Image 7 the group produced the user interface for the assignment progress window. This helped them understand the final product, as shown in Image 8, which is very similar to what the group had in mind originally. The needs of the user and how important it was to accommodate for all kinds of users, including those with limited technical knowledge was discussed in detail. The group also looked around at the existing software and their user interfaces, including various Microsoft products. However, it was impossible to interview actual users, since the project had no actual users. Hence the group had to create imaginary users and document usage scenarios that reflected their views.

Image 7: Initial User Interface Idea

Image 8: Final User Interface SHowing Progress

Despite the fact that the user interface was discussed in detail on many occasions during the early stages of the MUP, not the whole project user interface was produced the way the group envisioned it originally. Image 9 is the introductory page of the project, which could have been done better through the use of 3D buttons and tabs. However due to time constraints and overall programming knowledge of the group, the user interface envisioned could not be produced. The group overcame this problem through use of more text and menus.

Image 9: Final Welcome Project Page

In conclusion, the MUP processes early on in the form of Inception and Elaboration are important in understanding how the final user interface should perform for the user and the clients. Even though there may be disagreements between the two parties, it is important for designers and developers to document and research very thoroughly what user interfaces should be capable of in favour of anyone who uses them. Good user interfaces backed up with good documentation form the early stages of the software development cycles can save money in the long run, despite appearing to cost more in the beginning.

References:

1. ↑ Sommers. A, A Trio of Implications for Software Interface Design, http://www.sm.luth.se/~david/papers/animate.pdf#search=%22%22MUP%22%20AND%20%22user%20interface%22%22, pp34.
2. ↑ Sommers. A, A Trio of Implications for Software Interface Design, pp 34-36.
3. ↑ Bennett.S, Marobb. S, Farmer. R, Object-Oriented Systems Analysis and Design Using UML, 2006, Third Ed, McGraw Hill, UK, p 57-58.
4. ↑ Bennett.S, 2006, p 129-159.
5. ↑ Bennett.S, 2006, p 141-145.
6. ↑ Spolsky.J, User Interface Design for Programmers, 2001, Apress, NY, p1-13.
7. ↑ Spolsky.J, 2001, p15-22.
8. ↑ Spolsky.J, 2001,p17.
9. ↑ Spolsky.J, 2001,p17.
10. ↑ Sommers. A, A Trio of Implications for Software Interface Design, pp 37-38
11. ↑ Spolsky.J, 2001,p30.
12. ↑ Spolsky.J, 2001, p61-66.
13. ↑ Spolsky.J, 2001,64.
14. ↑ Spolsky.J, 2001,p64.
15. ↑ Spolsky.J, 2001, p43-48.
16. ↑ Spolsky.J, 2001,p47.
17. ↑ Spolsky.J, 2001, p43-48.
18. ↑ Sommers. A, December 16 Program Summary, http://www.slostc.org/events/dec16.html