Interactive Prototype #1

By Haydee Hernandez, Qun Liang, and Hailing Jiang

[Home| Problem & solution| Tasks| Revised interface | Prototype overview| Screen Dumps| How to run the interface]

Problem and solution overview [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. There is a strong user demand for a web site that offers sufficient novice support, and serves as a KM portal. The Gotcha system is meant to meet this demand.

Tasks [top]

3 representative scenarios:
Scenario 1 -- John works as a project manager in a company. He is new to the KM domain and wants to find some general information on KM. [annotated storyboard]
Scenario 2 -- Mary is a graduate student in the Business school, working on a class project related to KM, particularly a branch of KM called intellectual property. She wants to search for more information about this subject. [annotated storyboard]
Scenario 3 -- Susan works as an information manager in a company. Her boss asked her to study and evaluate different products to create an enterprise KM system.  on the options and issues of developing KM systems. She needs to find  information on the existing systems and  the companies who developed them. [annotated storyboard]

Revised interface design [top]

The user feedback from low-fi testing leads us to make a number of changes.


Storyboards of the 3 scenarios

Prototype Overview [top]

UI Overview

The user interface is comprised of 15 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
Tips
Results1 
Results2
Enhancement (on the fly)

Eliminated Information

In the course of creating the first interactive prototype, certain pages were not created due to time limitations a Help page was not written.  Ultimately, the Help page will contain a site map and background on the site's functionality. This information can be worked out better once the whole site is up rather than write a Help page that will be out-dated with the next iteration.

Rather than write high quality content for some pages and no content for others, mediocre content was written for all pages.  In the proceeding days, the compilation of information on the pages will be filtered, organized better, or rewritten.  We recognized this as a trade off but at least with some information on all the pages, prototyping testing will be more realistic.  This addresses the difficulty we had in the low-fi prototyping test where the "wizard" had to tell the user what she would see if content had been written.  Telling users what they would see is less consistent than having at least a little bit available.
 

"Wizard of OZ" techniques

Currently, the search engine does not function.  To simulate the feeling of a search, dummy pages have been created to approximate the look and feel of the process.  All three paths in the search process have been accounted for - search with no suggested terms requested, search with terms suggested, and search with no suggestible terms available.  Regardless of the terms inputted, the same search results page will appear.  If users ask Gotcha to suggest terms to enhance the query, the same set of terms will appear.  A dummy page has also been created to simulate a page of search results which has produced no suggested terms.  This gives users feedback by apologizing for no suggestions.
 

Tools

The tools used to build the interactive prototype 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++.
 

Screen Dumps [top]

Home page
About KM page
Resources page Products page
Search page
Search Results1
Search Results page2
Enhanced Query Page (created on the fly)
Search Tips
Add search terms page