The Redesign of LAPACK Final Project Report User Interface Design CSCI 6838, Spring 2000 Sponsored by Liz Jessup

Transcription

1 The Redesign of LAPACK Final Project Report User Interface Design CSCI 6838, Spring 2000 Sponsored by Liz Jessup Fengxia Ma, Thuha Nguyen, Baat Enosh

2 1. Introduction LAPACK (Linear Algebra PACKage) is a collection of software for solving linear algebra problems. The large collection of routines is available on the Web at Navigating through that Website and finding specific routines is a difficult task due to the way they are organized. One needs to be quite familiar with the site before facile navigation becomes comfortable. Hence, the creation of a friendlier user interface to this collection of routines poses itself as a necessary feature in order to attract more users. This goal led to the design of a Graphical User Interface (GUI) to the site by two undergraduates from CU. This Java GUI, while reasonably easy to use, has a very flat layout and is not particularly attractive. In addition, the Java implementation causes it to be slow. The goal of our project was to redesign the user interface to those routines so that it would be easier to use, more visually appealing, and to eliminate many of the performance issues. 2. Related Work To guide our project some external references were used. Following is a list of references and how each of them was applied in the process of redesigning LAPACK. For more information about the references, see section 6 below. 1. User Interface Design Principles [IBM-HCI Group, 1997a] This article, written by the Human-Computer Interaction group at IBM, talks about 11 principles in designing a user interface. These design principles combine traditional wisdom with extensions to make the interface transparent to the task the user is trying to accomplish. Further design goals include making the interface more efficient, satisfying, and fun to use. Below is a brief description of these principles: Simplicity don t compromise usability for function Support user is in control with proactive assistance Familiarity build on users' prior knowledge Obviousness make objects and their controls visible and intuitive Encouragement make actions predictable and reversible Satisfaction create a feeling of progress and achievement Accessibility make all objects accessible at all times Safety keep the user out of trouble Versatility support alternate interaction techniques Personalization allow users to customize Affinity bring objects to life through good visual design We went through the list and made sure the new LAPACK interface embodies all the features that these principles promote. For example, simplicity suggests that the interface 2

3 should be simple and straightforward. The old interface, with basic functions cluttered with more advanced ones, is both poorly organized and distracting. Therefore, we visually separated the basic functions from the more advanced ones by placing one group on the side and the other on the top of the interface. 2. User Interface Design Models [IBM-HCI Group, 1997b] This article, also from the Human-Computer Interaction group at IBM, discusses the use of models in designing and analyzing a user interface. According to the article, we can use models in user interface design to describe an interface in terms of objects, properties, behaviors and relationships between objects. Models are helpful because they provide a framework for analysis, understanding and decision-making. The article gives a discussion of three common models: the users conceptual model (what the user thinks is happening and why), the designers model (what the user is intended to experience) and the programmers model (implementation details). We used the users and the designers models to help us understand the users perspective and perform a cognitive walkthrough. 3. Is Navigation Useful? [Nielsen, July 1997b] This article by Jakob Nielsen discusses the use of navigation in a user interface. According to his studies, users look straight at the content and ignore the navigation area. Therefore, there are some analysts suggesting that navigation is useless and should be removed. Nielsen argues otherwise and provides a description of how to make navigation work. Since most of LAPACK interface is navigation, this article, in addition to others on the same topic, were particularly helpful to us. 4. Designing for Good Navigation [Morris, 1999] In this article, Morris argues that navigation is one of the most critical aspects of Website design. An interface, while very attractive and informative, will chase the users away without a sensible navigation scheme. Morris provides a navigation tutorial consisting of multiple parts: basic principles of Website navigation, using navigation bars, frames, site maps, contact pages, and offsite links. We employed some of his basic principles to design the layout of LAPACK, with basic functions on the side and others on the top. We provided information based on his rules: tell people exactly what is available on your site (available when user first enters LAPACK homepage); help them get to the parts they want quickly (basic functions are always on the side of the interface); and make it easy to request additional info (relevant links are always on the top of the site). We also made use of the navigation bar, and site map according to his suggestion. 5. Navigation What s on Your Visitor s Mind? [Starling, 2000] This article helped us gain a users perspective on utilizing navigation. It also discussed where and how to put our links. Since we have quite of number of links from LAPACK, and according to the article, it is a bad practice to put them all together, we divided the links into groups and placed them in separated places in such a way that they are still visible to the users. 6. Designing Site Navigation [Kirsanov, 1997] 3

4 As mentioned before, navigation is a big part of the interface of LAPACK. It was therefore essential for us to come up with a good navigation scheme. This article aided our interface design by providing such a scheme. It talked about the use of navigation bars and panels, and how to design a navigation panel that is both functional and artistic. It also discussed the dos and don ts of designing navigation schemes from real world examples. 7. Problems with Navigating a Web Application [Shubin & Meehan, 1997] This article discussed current navigational problems in web applications. It covered some of the main problems while also providing a solution. Some of the problems were: knowing where you are and where you are going (arranging the information thoughtfully); losing users and losing work (appropriate actions for external links and internal links); and lack of context (for example, placing the page that causes an error message along with the error message). It helps us identify and avoid some of the problems as well as recognize the potential of some others in the new LAPACK interface. 8. Top Ten Mistakes in Web Design [Nielsen, 1996a] Nielsen talked about ten most common problems in designing a web interface. They include the use of frames, gratuitous use of bleeding-edge technology, long scrolling pages, and lack of navigation support. We did our best to avoid these problems in the design of the new LAPACK interface. 9. Ten Good Deeds in Web Design [Nielsen, 1999] Besides the top ten mistakes, Nielsen provided what he believes to be the top ten things to do in web design. They include placing the name and logo on every page, providing a search engine, headlines and page titles, link titles, etc. In the same manner in which we tried to avoid his top ten mistakes, we followed his suggestions and provided all of what he talked about that are applicable to LAPACK. 10. How Users Read on the Web? [Nielsen, 1997c] This article helped us understand more about the users. We learned that users just don t read; they scan the page, picking out individual words and sentences. Therefore, we followed Nielsen s suggestions to make our interface more scannable: highlight keywords, meaningful subheadings, one idea per paragraph, etc. 11. Effective Use of Style Sheets [Nielsen, July 1997a] Style sheet, which is to promote the separation of presentation and content, was extremely handy for us in the design of LAPACK. It saved us much time and effort. Nielsen, in this article, showed us how to use style sheets effectively and provided implementation advice. Some of his advice, for example, included that pages should continue to work when the style sheet is disabled and that we use the same class name for the same concept in all of the style sheets. 12. An Introduction to Cascading Style Sheets [Walsh, 1997] 4

5 While the above article helped us conceptually, this article provides implementation details of style sheets. It helped us construct a style sheet for the LAPACK interface. 13. Why Frames Suck (Most of the Time) [Nielsen, 1996b] In this article, Nielsen provides an extended discussion about the use of frames. In particular, he describes the fundamental as well as implementation problems with frames. According to Nielsen, frames break the fundamental user model of web pages. Some of the problems with frames he talks about are search and print. However, he discussed when it was permissable to use frames and what is a good way to use them. We read his article, taking into account his suggestions about the use of frames, and tried to implement the small frame we have, in a constructive manner. 14. Different Strokes for Different Folks [Usborne, 1999] This article was particularly useful for our team in dealing with one another. It talks about how to resolve conflicts in making a design decision within a team. We had different opinions on choosing the layout and the color for the interface for example. The article helped us compromise and make the best out of our different perspectives. It was very well written and insightful. 15. Why You Only Need to Test with 5 Users [Nielsen, 2000] This final article was very interesting. Nielsen used a mathematical model to argue that as we test with more and more users, we learn less and less. The curve in his mathematical model shows that we need to test with at least 15 users to discover all usability problems. With an iterative design like ours, he suggests that we should do three tests with five users each. In the first test, we can discover about 85% of the usability problems. We should work on fixing these problems and test again. The second test can discover most of the remaining 15% of the original usability problems that were not found in the first test. However, the new interface may produce new usability problems or fail to fix the problem expected. Therefore a third test is necessary to discover the rest of the problems, which comprises about 2% by Nielsen estimates. We did most of what Nielsen suggested with an exception of the third test. We tested the old LAPACK interface with four users, tried to fix the problems they discovered, came up with the new design, had them test it and fixed the problems again. We couldn t conduct the third test because of the lack of time. 3. Our Approach Since this project involved a redesign of an existing interface, we realized we have a base from which we can work. A decision was made that the most important feedback about the existing site and what needed to be changed would come from users of the site. Therefore, the redesign focused on interviewing users about the existing site, and creating a new interface according to their input. It is always much easier to point out what one wants to see in an interface, if there is an existing one to reference. 5

6 For the actual design we came to the conclusion that flattening out the layout and having many of the menu items visible at all times would be the best approach. This meant that there would always be a table of contents (navigation bar) on the site allowing access to any of the pages on the site with no more than two clicks [Morris 1999]. The reasoning behind that decision came from the realization that LAPACK s purpose is to allow easier navigation through an existing library of routines, and easy navigation includes faster and more consistent accessibility. The existing Website was designed with a deeper hierarchical layout (one would need quite a few clicks to get to the desired page, with no easy return to where they came from). It seemed like the different approach of navigation bars might help resolve the problems of accessibility and knowledge of location. In addition, new navigation bars, implemented with HTML will dismiss the use of the Applet menus that are currently used and which caused the load-time of each page to be much higher. 4. Our Process The process of redesigning LAPACK included: - studying the site - interviewing users - analyzing the results of the interviews - coming up with multiple prototypes - walking through some tasks with each prototype to select the most appropriate one - creating the design - testing the design with users - finalizing the design Each of these steps is discussed in further detail in the following sections. 4.1 Studying the Site The first step of our redesigning process was to study the site and its contents, including learning about the solution it offers to its users. None of the team members were very familiar with the topics of the site, which made it a little more difficult to feel comfortable navigating through it. Once we felt familiar with the site, we started thinking up tasks and performing them, jotting down any problems we encountered along the way [Shubin & Meehan 1997]. Problems encountered with the site included its layout, its labeling, its presentation, and its load-time. These cognitive walk-throughs were done as a group and were the basis for our definition of the tasks we would ask our users to perform. The idea behind the redesign was to accumulate as many problems as we could find, either from our walk-through, or from user interviews, or from our sponsor, and then put them together to figure out the best approach in designing the new site. 4.2 Selecting Users and Performing Think-alouds 6

7 LAPACK is a collection of software for solving linear algebra problems. The potential users would be those who do a lot of linear algebra work, such as students in mathematics, and professional mathematicians. Based on this fact, on user response, and Jakob Nielsen s article about the adequate number of users to test [Nielsen, 2000], we ended up meeting three students from the department of mathematics and the sponsor to discuss the existing design. Two of the students have seen LAPACK before (but are not avid users), and the other has not, but was a potential user. During the meeting, we asked the users to think aloud while performing their given tasks. We gave them six tasks, ranging from simple to more complicated ones, and in addition, asked them some general questions about the existing site. The easy tasks included things like finding what LAPACK is about, whereas the more complicated ones challenged them to locate certain routines and to use the search engine (the use of the search engine was not obvious). The order of tasks was designed such that the user would first get a basic idea about LAPACK and only then start performing advanced tasks. These tests helped us in understanding how different users use the site and what are the expectations of each [Nielsen 1997c]. The original LAPACK user interface has a deep tree structure. To find the About page was easy for all users since it is located on the front page. We found the biggest problem was that even after the user read the Help page, it was still hard for them to follow the correct link to the specific routine if they had never used LAPACK before. There seemed to be a labeling problem even when the user knew the mathematics terminology. At the end of performing the tasks we asked our users some basic questions about the site. These included their impression of the site, their likes or dislikes of colors, layout, load-time, etc. Besides the three students from the department of mathematics, we also met with our sponsor to discuss the existing design. The meeting was conducted differently than the one with the other users. Since the sponsor was involved in building and maintaining the site, there was no point in performing tasks. The focus was geared towards her likes and dislikes about the site. In addition, we were also given some design suggestions from her. 4.3 Analyzing Interview Results At the end of all the tests, we summarized the problems that were found by the users, our sponsor, and ourselves into the following categories: Visibility, labeling, and organization of the links Shortcuts easy exit or back Limitation of the search engine Appearance 7

8 The first problem of the links included understanding where each link goes, and that the Help button is not accessible from every page. For example, one of our tasks asked the user to find the routine for QR factorization. The user who was not familiar with the site took a very long time to perform that task, mainly because the name of the link they needed was not obvious. The second problem of shortcuts was also found during the interview. The users found that getting back to the Home page in order to perform a new task meant clicking on the Back button until they get there. Or, for example, when we asked the users whether they could find the meaning of SGGHRD (acronym for a routine), they had to click many times to access the Naming Scheme page. It became obvious that having links to general information and the Home page accessible at all times would be a good idea. The third problem was the limitation of the search engine. Some users did not like the search engine provided by the existing site (which allows you to search only acronyms of routines), instead, they preferred a different search engine that exists on an external site, Netlib (this is the site where the original routines reside). It became clear that adding a link to Netlib s engine would be useful. The last category of problems found was the appearance of the site. Aside from the usual subjective matter of colors, there was an objective problem of usability caused by links whose color was not readable over the background color. In addition, having most of the site using a black background, might result in printing problems. Another problem encountered was the size of Applets that are used on the site. At times, these Applets were very wide forcing a user with a narrow browser to scroll to the right to see all that is available. It was discovered that scrolling sideways is considered less convenient than scrolling up and down and should minimized where possible. 4.4 Prototyping After categorizing and summarizing the problems, we delved into the next phase of prototyping. There was a basic design idea that guided us when coming up with the prototypes there are certain links that should be accessible at all times. Three design prototypes started developing. One had of frames at all, only HTML tables. The second one split the page vertically into two frames one narrow frame on the left with a navigation bar, and one with a wider frame on the right with the content of the page. The third prototype divided the page horizontally into two parts using frames as well. There would be a top frame with links in it and the rest of the page would be dedicated to content. The third prototype later evolved into dividing the main frame vertically into a sidebar menu and content. This time, HTML tables were used rather than frames. 8

9 It was discussed earlier which of the main links should be available at all times [Kirsanov 1997]: Home (shortcut to go back to the Home page), Netlib (home page of Netlib), Search (accessing both search engines), Help, and Sitemap. As for the sidebar menu, it would include the main menus from the original LAPACK, the ones used to actually navigate between the different sets of routines. Since these menus are not too extensive, it was decided to flatten the layout by making some of the sub-menus accessible at a higher level. For example, in the original LAPACK, one would click on View/Copy Individual Routines to be presented with five categories of routines from which to choose. In our third prototype, these five routines are already accessible through the menu that is one level above. The design of our three prototypes came from the results of our site study, the interviews, and the sponsor. Most of all, it came from our knowledge of how a good user interface should look like from this course. A cognitive walkthrough is going to be done for the three prototypes so that the best one can be selected as the final result for this project. The walkthrough will be described in the next section. 4.5 Cognitive Walkthroughs Selecting the Best Prototype After developing the three prototypes, we had to select one model to follow through to a complete design. Our selection was based on cognitive walkthroughs on selected tasks. We started with some of the tasks that were given to the people we interviewed, but realized they were too simple to make a clear distinction between the different prototypes. To have a better evaluation of each of the prototypes, we came up with some different and not as common tasks to test the designs. For example, we tested a case where a user would search for a routine both on our website and on the original repository of routines (Netlib s website). Observing how many windows will remain open on the desktop after such a task, and the accessibility of both searches, helped us advance towards deciding which prototype would result in better behavior. Many other tasks were tested. Ranging from short and simple to more complicated ones. In the end, we realized that although the use of frames is not as popular nowadays, and sometimes even not recommended [Nielsen 1996b], we still want to use them, in a minimal way, just to ensure that certain selections for the user are always maintained at the top of the window. Careful thought should be put into ensuring that the frames will not hinder the site, and are implemented in a constructive manner. Therefore, the design that was selected was the one with a small frame at the top, featuring some basic links, and the rest of the menus built as tables splitting the window into a left-side menu bar, and a right-side content area. This design seemed the most usable for both displaying menus and tables of contents and the actual applets that retrieve the desired routines. 9

10 4.6 Creating the Design To implement the design, the use of HTML3.2 and CSS1 (W3C s Cascading Style Sheets Level 1) was selected. The reason we decided to use Cascading Style Sheets was for easier maintainability and the idea of separating content from presentation [Nielsen 1997a] Design Priorities Redesigning LAPACK included the reorganization of menus from which the user can select in order to simplify the process of finding desired routines. The focus for the redesign was to make the user familiar with the site in a relative short period of time so that finding specific routines will become a simple task. Our priorities included: Maintaining all the information from the original site. Having a set of options always visible on the site for quick access (e.g., help, search, etc..). Maintaining a consistent look within the site. Flattening the layout of the menus for locating routines (i.e., so the user has to use less clicks to get to desired routine). Replacing as many Applets as possible with HTML to reduce load-time. Distinguishing between different types of links (e.g., a link for saving a file locally should indicate as such). Making the page with explanations about the different menus more visible. Adding certain outside links to the site (for easier search) Design Rationale After figuring out what issues were important for the site, which features we wanted to keep and which to discard, arriving at the final design was not a difficult task. Things just fell into place. The priority of keeping all the core information of the original site in the new design made us realize that not much change can be made to the Applets that serve as forms for the user to input his request for the desired routine. The major items that will be changed are the format and presentation of the menus that will lead to those Applets. The priority of having a set of menus always accessible to the user, led us to splitting the window into a top, narrow, horizontal frame with some core links (Help, Search, Sitemap, Home,..) and another frame with the rest of the information. The bigger frame was to include a sidebar navigation menu, built as a table, with the actual browsing functionality that leads a user to the desired routine. It was realized that to maintain a consistent look, the sidebar will have to appear on every single page, allowing the user to jump between categories of routines without having to 10

11 use the Back button at all. The sidebar will be implemented in HTML rather than as the existing Applet, helping reduce the load-time. Also, because there aren t many top-level categories, the sidebar will be expanded to include one more layer of menus, thus flattening out the layout of the Website. Top frame Sidebar Navigation Menu Bottom frame divided as a table The last important part in the design was creating the actual look of the Website. That would include colors, fonts, background, graphics, etc. It became clear that these things are a matter of individual taste and that it will take a while to reach an agreement on the desired look [Usborne 1999]. On top of that, after reaching a decision among the developers, it might get overridden by the sponsor. Therefore, it became obvious that the use of Cascading Style Sheets (CSS) was inevitable. CSS allows you to manipulate the presentation in multiple pages by changing definitions in a single file [Walsh 1997]. By separating content from presentation, we will be able to develop the site focusing on the content, and later on spend the time deciding about the most appropriate look. 4.7 Testing the Design After implementing the chosen design, it was time to have external people comment on its usability. The first person to review the new design was our sponsor. Her comments were mainly concerned with consistency issues, and changes were immediately incorporated to the site to satisfy these issues. The next step was meeting again with our original users to go over and test the new design. Only two of the original users were willing to meet with us, but the results of 11

12 their testing made us feel sufficiently comfortable with our results. The users were given similar tasks to the ones they were tested on three months ago, and think-alouds were conducted for those tests. There was also a section testing their overall impression of the site, questions asking about features they would still like to see included, and things they miss from the old design. The results of the tests were very positive. The tasks were performed much easier, with less searching for the right link or going back and forth between different pages. There were a lot of comments about how much nicer it is to have most of the menus available at all times. As for the presentation side of things, one user mentioned he liked the color scheme very much, whereas the other said he would have chosen different colors. Since colors are a matter of personal taste we decided to leave the colors as is and let the sponsor decide on the scheme. No comments were made about the usability of the colors. The faster load time was also mentioned as a positive change, but there were still comments made over the load-time of the remaining Applets. Since it was beyond the scope of this project to make changes to those, we left things as is. The main complaint that came from the users had to do with regards to the existing search engines. Even though there are two engines on the site, none of them behaves in an optimal way and users thought they were not very helpful. Their main request was to have a search engine that allows string searching on the actual routines. Since most of the problems encountered in the testing had to do with issues beyond the scope of our project we decided to leave most things as is, and concentrate on optimizing the existing design and making it into a final product. 4.8 Finalizing the Design After the testing, a few minor changes needed to be made to the design. Some additional comments came from our sponsor that needed to be incorporated as well. In general, the conclusion was that the design was a good choice, and the implementation - including the presentation, was what our sponsor was looking for. Overall, the users thought the changes were an improvement. 5. Conclusion Redesigning a Website by starting with an existing design seems like an easier task than starting from scratch, although there are some caveats that need to be mentioned. One should always consider that when using an existing design, there might be a person who feels protective over that design, and a sensitive approach should be taken. Also, when dealing with a sponsor who is a part of the development team, the same issues should be taken into account and the most scientific and professional approach should be taken. 12

13 One of our fears when starting the project included the lack of knowledge we had in the area of Linear Algebra. Making use of user interviews was very helpful in understanding what they were looking for when using such a site. On the other hand, there are certain guidelines to be followed when designing a Website, regardless of its contents. Our objectivity might have even been to our benefit, seeing that it was easier for us to follow good design rules, than maybe someone who is involved in the area. Had we had more time, we would have delved into the actual redesign of the form-like Applets that take user input to produce the desired routine. That would include reprogramming the Java that currently exists. It was decided early in the project that time will not permit us to redesign that part of the Website. Another topic we would have liked to be able to cover would be the search engine on the site. But building a useful search engine can become a project by itself. 13

14 6. References IBM Corporation, Human-Computer Interaction Group, 1997a. UI Design Principles. World Wide Web Journal. IBM Corporation Human-Computer Interaction Group, 1997b. UI Design Models. World Wide Web Journal. Kirsanov Dmitry, Designing Site Navigation. Web Review Journal. Morris Charles, Designing for Good Navigation. Web Developer s Journal. Nielsen Jakob, May 1996a. Top Ten Mistakes in Web Design. The Alertbox: Current Issues in Web Usability. Nielsen Jakob, December 1996b. Why Frames Suck (Most of the Time). The Alertbox: Current Issues in Web Usability. Nielsen Jakob, July 1997a. Effective Use of Style Sheets. The Alertbox: Current Issues in Web Usability. Nielsen Jakob, July 1997b. Is Navigation Useful? The Alertbox: Current Issues in Web Usability. Nielsen Jakob, October 1997c. How Users Read on the Web? The AlertBox: Current Issues in Web Usability. Nielsen Jakob, October Ten Good Deeds in Web Design. The AlertBox: Current Issues in Web Usability. Nielsen Jakob, March Why You Only Need to Test with 5 Users. The Alertbox: Current Issues in Web Usability. Shubin Hal & Meehan Margaret, Problems with Navigating a Web Application. Text Matters. Starling Andrew, April Navigation What s on Your Visitor s Mind? Web Developer s Journal. Usborne Nick, Different Strokes for Different Folks. Direct Marketing Journal. Walsh Norman, An Introduction to Cascading Style Sheets. World Wide Web Journal. 14