Previous | Table of Contents | Next |
We put an autofilter button on the opening window. Not only did this serve to alert users to the filtering functionality, it provided easy access to an example of a filter. All a user had to do was to select a story displayed in the story window and press autofilter. The auto filter window (shown in Figure 9.5) then opened to display a filter which would capture a story just like the one the user had selected. This filter could be saved as is or it could be modified by the user slightly to capture more or fewer stories about this particular topic.
Figure 9.5 The autofilter windows that appears when a story is selected and the autofilter command is given.
The filter creation window (shown in Figure 9.6) provided several aids to users. Keywords were provided and were divided into different categories. We worked with CNN to ensure that these same keywords would be used for classifying and capturing stories. As users entered keywords and supplied the proper AND or OR connectors, a summary window gave feedback in natural language about what the filter would capture. For example, a response might say this filter will find stories with the industry classification of government and the subject classification of aviation and the key words of jet propulsion. In addition, we predefined some filters that could be used as is or could be refined slightly according to users requirements. For example, high tech, defense, and environmental regulations could serve as predefined filters.
Figure 9.6 The window for filter creation.
We knew that users went to certain sections of the newspaper or certain television channels to find pertinent news. We needed to support this functionality as well. In addition to allowing users to define filters based on keywords, we provided a way to define time-based filters. We also predefined filters for various segments of CNN to use as is or to modify. The window for creating time-based filters was similar to the dialog window for creating keyword filters. Figure 9.7 shows the dialog window for creating time-based filters.
Figure 9.7 The window used to setup a time based filter.
We provided users with a way to manage the filters they had created. This is an example of new user tasks being created as a result of automating other user tasks. The filter manager dialog allowed users to activate and deactivate filters and to save or delete deactivated filters. The filter manager (see Figure 9.8) provided an easy way for users to view the status of any filters. The filter manager also provided users with the ability to select a given filter and modify it to create a new filter.
Figure 9.8 Filter manager.
Another problem encountered during design testing was how to convey to the users where the captured stories were saved. We wanted to create our own storage area so that stories could be saved by their title, rather than automatically creating one or requiring the user to create a title for each story. We created a Save to Inbox button on the main window to accomplish two things. First, users could see where the captured news items could be found. Second, users had a method for capturing a story on the fly. We had wanted to develop a wizard to walk users through the filter setup process, providing advice if users attempted to define filters that would not capture any stories. We were not able to implement this feature due to time constraints. However, we did design the user interface for a wizard that could be incorporated into subsequent versions.
It is important to note that we started with an original set of goals and used them to evaluate different design alternatives. The goals were readily available to use as scenarios for design testing with users. As we proceeded with design testing, we also verified our original set of goals with participants in the design testing. After the actual testing, we asked them about different functionality and how important this was to their particular job.
5.4. PRODUCT IMPLEMENTATION
Designs often get modified during product implementation with only a local view. That is, modifications are made for only a small part of the application without looking to see the affect on any other parts of the application. Perhaps an initiator for an action is changed to be more useful for a particular object. If the developer were looking at the global level, he or she would make sure that this change would be a positive one for all objects on which this action is defined. While several small less-than-optimal decisions rarely affect the overall usability of the product, many such decisions can have a negative impact. It is impossible (and most likely not even safe) for human factors engineers to stand over the shoulder of every developer and check every decision made or to do usability testing on every decision. We needed a way to convey information to developers so that they can make implementation decisions within the global framework. We feel that the Systematic Creativity framework facilitates thiscommunication. Developers can use the framework to see the effect that a decision will have on the entire product. If this decision affects a high priority goal or many goals, then a human factors expert should definitely be called in. If the decision is at a lower level and affects very low-priority goals, the developer can use the framework to help evaluate his decision.
Previous | Table of Contents | Next |