Interactive Prototype #3

By Haydee Hernandez, Qun Liang, and Hailing Jiang

[ Problem | Solution overview | Tasks and Scenarios | Design Evolution | Final Interface]

Problem [top]

Knowledge management (KM) is an emerging field in business studies that has seen explosive growth in recent years. Despite the many KM resources available on-line, there are various kinds of information needs that are not well satisfied in this field at present. Those skeptical of KM's value as an autonomous subject need to see its integrated picture rather than a simple agglomeration of the numerous bits and pieces that only focus on some of its components. Novices call for a single entry point to the KM world to have a sense of what it is and how to incorporate it within their organizations. Further, information managers managing KM projects are often frustrated searching for specific information, not knowing the right search terms to use. Thus, there is a strong user demand for a web site that offers sufficient novice support, and serves as a KM portal. The Gotcha project is meant to meet this demand.

Solution overview [top]

The improvements we suggest in fulfilling those various user demands are threefold. First, new content was generated and presented to the user. This includes some basic questions about KM and their answers, and a glossary of KM terminology. These content information can serve as a starting point for novice users. Second, We compiled various kinds of resources, such as KM-related web sites, professional organizations, a reading list, case studies and products. All these resources were well-organized and categorized. Lastly, we will integrate the KM thesaurus that we manually constructed with the search engine. The thesaurus can be used not only to organize information items, but also automatically reformulate user queries to improve the retreival performance.

Tasks and Scenarios [top]

The 3 tasks we used for low-fi testing were developed from our task analysis:
Task 1A -- A project manager new to the knowledge management domain wants to find some general information about the subject.

Task 1B -- Find books/articles written by Nonaka.

Task 2 - A graduate student in the Business school working on a class project. A book briefly describing a branch of knowledge management called intellectual capital seems likely to have a lot of information for his project. Find information about intellectual capital.

Task 3 -- An information manager in a company. His boss asks him to do a study and evaluation on the options and issues of developing KM systems. Find information on the existing systems, the companies behind the systems, etc..

For the final usability test, we kept the first two task scenarios from the low-fi testing with only a slight modification. We eliminated Task1B which asked participants to find books by an author since our UI no longer supports bibliographic searches. Because of UI changes, the third scenario also changed since it would be too easy to accomplish. With a products tab, users could just look for products there so we created a more challenging third scenario.

Scenario 1 -- You work as a project manager in a company. You are new to the knowledge management domain and want to find some general information about the subject. (annotated storyboard for scenario1)
We chose this scenario to test if the content information provided in our site can satisfy the novice users' general information need.

Scenario 2 - You are a graduate student in the Business school working on a class project. A book briefly describing a branch of knowledge management called intellectual capital seems likely to have a lot of information for your project. Find information about intellectual capital. (annotated storyboard for scenario2)
This scenario was designed to test our search engines.

Scenario 3 - Your sales staff has not been meeting its quotas and customers are complaining about poor customer service. You heard through the grapevine that a lot of knowledge management projects fix just these kinds of problems, but you are not sure how. You want to find information about these kinds of projects that other companies have set into motion and their results. (annotated storyboard for scenario3)
Scenario 3 was intended to test if the user can accomplish some relatively complex task in our system. He may utilize the content information provided in our site, do searches using our metasearch engine, or combine any information available from the site.

Design Evolution [top]

The interface of Gotcha system has gone through several iterations based on feedback from low-fi testing, heuristic evaluation, and final usability test. Changes were made during each iteration. The final user interface is quite different from the initial sketches.

In low-fi prototyping, we tested our UI sketches on 3 users. All of them are novices on KM. Their feedback led to some major changes in our initial UI design:

Some of the functions or features that we thought helpful turned out to be useless, misleading or frustrating. These were eliminated from the initial design.

Eliminated the "Browse Subjects" page. We thought that Browse Subjects would be very helpful for novice users. But the test results showed that it was hard for users to determine which top-level category to click in order to find a lower-level category. In all cases, users preferred searching for information using the "About KM", "Resources", or "Full Search" pages rather than explore our hierarchy. (Browse Subject page used in low-fi testing)
Eliminated the explanation on the "Home" page of how Gotcha was developed. Users showed no interest in this information. Instead, a link labeled "About Gotcha development" will be placed in an discrete location for interested parties (Home Page used in low-fi) (Final Home page)
Eliminated the Quick Search function from the "Home" page. Users found it useless and misleading (Home Page used in low-fi) (Final Home page).
Eliminated the folder. Even though most users said they might take advantage of the feature, it wasn't visible or intuitive enough for novices to begin using immediately. One user also stated that he just preferred bookmarking interesting sources. (Home Page used in low-fi) (Final Home page).

Revised Search page. First we eliminated the bibliographic search options and simplified the search interface. Second, we expanded the search target from just the Gotcha site and the Gotcha library to include the entire web and uncrawlable KM specific web sites. For searching the entire web, we submit the users' query to multiple search engines and then merge the results before presenting them to the users. Before searching, users can choose to refine their original query by adding related terms suggested by Gotcha's thesaurus. (Search page used in low-fi testing) (Final Search page)

Users found that some terms used in initial sketches are confusing or misleading. They were replaced by better terms or some definitions or explanations were added to make them clearer.

Define each of the topics on the "Resources" page, e.g., websites, publications, organizations, companies/products. Users had difficulty understanding what to expect. Therefore, a definition is critical (Resources Page used in low-fi) (Final Resources page).
Rename "Organization" to "Professional Organizations". The latter term was less confusing to users than the former. (Resources Page used in low-fi) (Final Resources page)

More content information were added.

Add additional topics to the "Resources" page. Because novices were attracted to this page, we have added company/products, case studies, and reading lists as topics. They represent other typical information needs mentioned by other users. Rather than force them to formulate a query, they can refer to this page instead. (Resources Page used in low-fi) (Final Resources page)
Add Products tab. Novice users wanted to see a list of products by category rather than search for them.

Most of the problems brought up by Heuristic Evaluation are aesthetic or of personal preferences. So we only made some minor changes based on the HE results:

A Glossary was added to the Resources page to address the problem of technical terms brought up by HE. (Final Resources page)
A help page was created. (Final Help page)
The search interface was enhanced.

In the final usability test, We tested the interactive interface on 2 novice users and 1 KM professionals. The problems exposed were mainly on search pages partly because we could not really test the search on paper sketches in low-fi testing. The changes based on usability test results are (Final search page):

Eliminate the pop-up windows on the search page that present tips and definitions. Users find them too distracting or they can not understand how to control them.
Rename the search option on the search page from "the Web in general" to "Search the Web." This is more clear.
Change the default sources searched on the search page to just "Search the Web" to minimize overwhelming users with too many results.
Change the sorting of search results. Instead of ranking and then sorting alphabetically, rank and then interleaf different sources with the same ranking e.g. one result from Gotcha, then one from CIO, then one from the Web, etc. It eliminates dependency on one source and prevent us from looking biased (hence untrustworthy).
Add a quick explanation on the types of results a source will return e.g KMWorld retrieves product and events information.
Select query enhancement as a default on the search page. This forces users to familiarize themselves with its power the first time they use search instead of ignoring this novel feature. But users can still unselect query enhancement if they chose.

From the above discussions, we can see that low-fi prototyping was most valuable to our UI design. It led to some major changes to our initial sketches which HE and usability test only exposed some minor problems.

Final interface [top]

Final UI Overview

The final user interface is comprised of 14 web pages on the Gotcha web site. The table below shows that the site is relatively flat with no page more than two levels deep (excluding users conducting a search which would be no more than three levels deep to present search results). The topmost pages are always available to users in the form of an image map at the top of each page which looks like tabbed folders. The children of topmost pages are accessible by clicking the desired selection from an image map in the left hand blue column.

Topmost Pages	Home	About KM	Resources	Products	Search	Help
Children		Gurus	Web sites Periodicals Professional Orgs Case Studies Reading List Glossary		Tips

Home page
The home page provides users a short guide to our site, including what content information can be found in our site and what functions or features we provide can help users find information. The users can click on the links of their interests which lead them directly to the corresponding pages. There is also a link to "about Gotcha and its creators" on the bottom of the page for the users who might be interested in our project.

About KM page
In "about KM" page, we compiled several basic questions about KM and the corresponding answers, such as "what is KM", "what is the difference between KM and other disciplines". This page can serve as a starting point for novice users, especially someone who knows nothing about KM.

Resources page
In "Resources" page, We have lists of external KM web sites, periodicals with a KM focus, professional organizations, KM-related case studies, a recommended reading list and a glossary.

Web sites
Web sites page provides links to external web sites with either general information on KM or its specialities. The sites are organized into several categories, such as collections/reference guides, publications, organizations/communities.

Periodicals
In "Periodicals", we recommended 5 good periodicals on KM based on our review. There is also a list of non-reviewed periodicals on this page.

Professional Orgs
In "Professional organizations" page is a list of organizations with a KM interest.

Case Studies
This page provides links to case studies or publications that provide them.

Reading List
In the "Reading list", the users can find the top picks we recommended, and other readings well-organized by categories. For online resources, we provided links which can direct the users to the corresponding sites. For some books which has no information available online, their bibliographic information was provided instead.

Glossary
"Glossary" provides brief definitions to some key terminology in KM domain area. These terms are ranked by alphabetical order. This page is linked to our meta search engine by "view records related to this term". The user can click on "view records related to this term" to search for resources on this term. It is the same as typying the term in the search page to conduct a search.

Products page
In "Products" page, we provide lists of KM systems, products, and the companies behind them. They have been categorized according to their predominant use in the KM field so that the users can locate the products that suit their needs easily and quickly.

Search
The users can type in any keyword they want to conduct a search. The system provides several search options:

Search target

The users can choose searching Gotcha site, Gotcha library, the Web, three KM-specialized web sites - KM world, CIO, Brint or any combination of the above resources. By default, the system searches only the web.

Query enhancement

The system suggests Thesaurus term related to the user's keyword. The user can then choose to add these terms to the original query to achieve better search results.

Result display format

The user can set the desired display format: Number of results per page and long or short display format.

SearchTips
"Search Tips" gives some brief information on how to use the meta search engine.

Help
"Help" page provides some assistance for new users to navigate the Gotcha site.

What was left unimplemented

Basically all the initial ideas for our UI design have been implemented. The next step is to maintain and improve our system, such as keeping the content information on our site updated, increasing the search speed by multi-thread programming, etc.

Tools used

The tools used for prototyping and UI implementation were Macromedia Dreamweaver, Adobe Photoshop, and Perl.

Dreamweaver was used as the predominant WYSIWYG web design tool. It worked fairly well for most of the tasks needed to construct web pages. Its ability to create image maps within the application was the most useful feature of all. It was simple to use and quick. Without such a WYSIWYG tool the total amount of time to complete the task would have easily tripled. None of the fancy features
helped us decide which layout would be the most user-friendly. This creative process occurred completely in the minds of our group member's minds and from user testing. Dreamweaver only helped us instantiate our ideas faster than if we had to code it by hand. Dreamweaver demonstrated difficulty in performing some operations like creating / modifying complex tables (tables within tables) and creating /setting anchors. Consideration was given to using Frontpage for more complex tables but the application's interoperability problem defeated that idea. Instead, Amazon.com's site was edited and used as the basis for Gotcha's pages. This eliminated the need to create our pages from scratch. Netscape Page Composer was used to compensate for Dreamweaver's weakness in creating / setting anchors because it has a more intuitive procedure for creating and setting anchors.

Adobe Photoshop was used as the exclusive graphic design program. Photoshop was used to create the GIFs that serve as the image maps at the top of each page (tab folder image) and any image maps appearing in the left hand column of most pages (navigation feature to the children of topmost pages). Six separate tab folder images were created because the visible page has its tab highlighted in blue whereas the non-visible pages have their tabs in yellow. Even though Photoshop provided a great deal of flexibility in moving portions of the images around and changing font and image colors, it didn't provide a guide on how to choose colors. That decision was left completely to the group's discretion. This could be disastrous to people with no sense of coordination. The one feature that was invaluable was the text edit feature introduced in version 4.0 enabling users to edit text layers separately. This is a valuable time saver given the previous version required users to delete the text layer and create a brand new one even if the change was something as simple as changing the spelling. Photoshop is a complicated application to grasp and use, but no better alternative exists. It doesn't show how big (e.g. KB) an image is within the context of the application. A user must open the directory in a separate window and check. This is very distracting if a user wants to compare image sizes based on formats. Modifying images is also a time-intensive and tedious task. After changing the total number of tabs from five to six, all five images were changed after hours of work. Despite the availability of macros, the detail-oriented nature of the work couldn't take advantage of macros to speed the process. The other main difficulty was Photoshop's inability to support the drawing of circular or elliptical figures. This required us to modify pre-existing images instead of creating our own.

Perl was used to create the cgi scripts to implement search. Perl is a language for easily manipulating text, files, and processes. It provides a simple and fairly readable way to do jobs. Perl was used to parse the user search query, identify the phrases. If the user chooses to enhance the query, then the program matches the terms/phrases against the Gotcha thesaurus, and a query enhancement form is created and returned to the user. The form allows the user to choose any term/phrase they want to include in the enhanced query. Then the submitted enhanced query will be processed and the program will use the enhanced query to conduct the search. Otherwise, the original query will be used. The program then does an inhouse search and/or passes the query along to other search engines. All the results will be processed, merged and presented to the user. The problem with this programming language is that it is quite easy to introduce bugs, and quite time-consuming to fix all the bugs. Also, it takes more processing time than languages such as C and C++.