CyberGuide Requirements Document
|
Winter Quarter 1996 Document Author: Project Sponsors: |
CyberGuide Team:
Matt Howser (Architect/Programmer/Manager) |
|
|
Winter Quarter 1996 Document Author: Project Sponsors: |
CyberGuide Team:
Matt Howser (Architect/Programmer/Manager) |
In this incarnation of CyberGuide, we are striving to not only recreate CyberGuide on another platform, but upgrade and improve it at the same time. Originally written for the Apple Newton, this incarnation of CyberGuide will be a port to the Delphi language and will be designed to run on a palmtop Intel platform under Microsoft Windows®. This port will not be a direct one in the sense that this group will not have the advantage of the original code, only a knowledge of the interface and purpose. It will, therefore, be a recreation of the system, with changes to make the interface more appropriate for the new platform. The team will not, however, settle for a simple recreation. It is our purpose to enhance the program as well, with features such as determining the user's facing, a rotating map, color-coding the display, and displaying the most appropriate route to a selected destination.
The current incarnation of CyberGuide features a map of a room, currently the GVU lab, with the locations of the demonstrations marked. The user can manually scroll the map, along with having the map track him as he moves. The guide uses crude infrared sensors mounted on the ceiling to keep track of location, using a sensor interfaced through the Newton's serial port. It can determine the direction the user is moving, although not the precise direction he is facing. There are zoom in and zoom out features to give a close or wide view of the room, allowing the user to see as many locations as he wants, or narrow his view down to the closest few. "Clicking" on a location, using a pen on the Newton, brings up in a small window a description of what is being demonstrated at the location.
At this time, CyberGuide is an effective if crude tour guide. The basics of the interface are certainly present, with many good ideas represented. There are, however, areas that are improvable. Although there is not sufficient time to explore all of CyberGuide's possibilities, our goal is to markedly improve upon the existing product. Some facets of the guide which need improvement are hardware-based and outside of the scope of this portion of the overall project. However, there are many areas in which the software can also be improved. With the improved speed and graphics the Intel platform offers, some enhancements will come automatically through hardware, some are implementable on either platform, and some will take advantage of the specific platform. The orignial abstract for the project envisions an interface that is both intuitive and personal. This quarter, we hope to make great strides in this direction.
Much of the information in this overview has been taken from past project notebooks and abstracts. I have linked some of the primary sources through their home pages at the beginning of this plan. The writer is grateful to the project pioneers for their vision and clarity.
Two visiting scientists enter the GVU lab ready to tour the latest Demo Day. Upon entering, they pick up a CyberBuzz® Tour Guide, anticipating a great show. Looking at the map, they press the Zoom Out key a couple of times, trying to get a feel for where all of the projects are. Seeing some close by, they use the TrackPoint® to click on them and bring up short abstracts. After reading the abstracts in the text area, they find a project they are interested in. Clicking on the Show Route button, a line instantly traces out from their current position to where the project is located. Following the trail marked for them, they quickly find the project and being asking obtuse and irrelevant questions to the researchers there.
Bubba and Jim have just arrived at the local Boat, Knife, Gun and Assault Weapon show in Dunlap, TN. Picking up a strange contraption, they are told it is the latest in tour guide technology, the CyberBuzz. "Woowe!," exclaims Bubba, "this here contraption shore do look complicated." The person handing out the guides quickly shows them how to use the CyberBuzz to get around the show. Seeing some kiosks close by, Bubba clicks on one and then clicks the People button. "Hey, Daisy Mae is running that booth! I hear tell she's single! Let's go and check her out!" Clicking Show Route, Bubba and Jim quickly find Daisy's stand and being the process of obtaining female companionship for the evening.
Bob, Jill and their 1.5 kids (one child recently born), decide to go to SciTrek for the day. Upon arrival, they buy their tickets and pick up a CyberBuzz. "Hey, I've used this before! It's a breezee to work!" exclaims Bob. He zooms out the map looking for his favorite on-going experiments. Moving it around, he clicks on a few, bringing up the standard abstracts. "This one looks interesting," he says. Clicking on the Detail button, he gets a full description of the experiment, the science behind it, and the results before even looking at it. Bob decides to go there, but doesn't want to use the Route Finder. Moving and panning the map himself, he quickly leads his family to the experiment, wowing them all with his technical expertise.
The functional requirements were mostly in place before the storyboard was drawn up. The earlier CyberGuide teams had created an interface which we only had to copy. We did, however, come up with some of our own improvements in the database area. In drawing up the storyboard, we decided to have a text area below the map that would permanently reside, showing the project title and a brief description of the selected project. The map will mark the current position of the user, as well as show the projects and surrounding features (such as walls and doors). There will be buttons to zoom, select what kind of information is desired, and move and rotate the map. We also decided to include a hidden button to remove a projected route. This button will only be displayed when needed, after a computer-projected route has been generated. Overall, the storyboard looks a great deal like the current Newton interface. As the program evolves and we become more influenced by our current PC platform, the interface will likely change. A scan of the storyboard will be placeed heere when avaliable.
Display map Display project location Display user location Display route Zooming Zoom in Zoom out Rotate map User scroll map Follow user's position Text display of project info Members of team Abstract of project Full project description Find project based on criteria List all projects Search by staff name Search by subject Show route to target Basic map building Draw map layout Place projects Basic database building Enter staff information Staff names Staff titles List all staff Enter project information Project location Project abstract Full description of project
User base - Mostly computer novices. This will be evaluated in the user testing phase to determine the level of competency required to use the product. If the level is too high, steps will be taken to make the interface more "user-stupid," perhaps by more on-screen help or off-line directions.
Speed - Map movement rate of 10 feet/second
Access time <5 seconds. - This time should be low enough to eliminate user frustration.
If this time is found to be too high during the user-testing phase, either by user complaints or observation of the product in action, the program will be optimized for speed. If code optimization is not sufficient, features will have to be eliminated.
Security - The database will not be writable by the user, eliminating malicious changes by too-smart adolescents. If any user is found to have accessed the database, additional features will be implemented. This feature could be tested directly during user testing by giving the platforms to known security evaders and having them try to break the security.
Fault tolerance - The program should "withstand stupidity," in that is should not break when used incorrectly. This will be closely monitored during and after user testing and debugging to insure that any fault is quickly fixed. We will also endeavor to have people intentionally misuse the product to test all possibilities.
Availability - This is not a great concern, in so much as each individual platform will be independent. There should be enough PC's available for general usage, and they should be kept in good condition to alleviate down time. This will be evaluated in the stability and computed uptime of the platforms during testing. If the platforms are found too fragile during testing, a different platform will have to be employed.
This platform will be a palm-top personal computer running Microsoft Windows 3.x on an Intel CPU. The appropriateness of the platform will be evaluated for its functionality during testing. If the speed or storage of the platform is found lacking, a different platform will be found. Currently, an infrared network is used to calculate position. This will hopefully be upgraded in the near future to a higher-bandwidth technology. The current network only allows the platform to determine its position. A higher-bandwidth network will allow many more features commensurate with the anticipated two-way communication.
The risks associated with the development of this project are fortunately minimal. There are still problems that could erupt, however.
Map display - It is possible that the platform will be too slow to keep up with the map display, making the map difficult to use. If this is the case, the number of points displayed will be reduced. The display code will also be optimized and/or employ a different algorithm. If the reduction in resolution along with recoding is not sufficient, the map will be split into parts and rendered separately to reduce the load on the processor.
Storage - The platform will have to store the operating system (DOS + Windows 3.x), the map program and the project database. Currently, we do not estimate a problem with holding this much information. If problems should develop, however, many solutions could be employed. If a new network is in place, we could transmit some date over the network, reducing he amount of information stored on each platform. If this is not available, we will reduce the amount of data stored, most likely in the database. This information will then be made available separately, perhaps at each station.
Network - Currently, the network is scheduled to be upgraded by the main Cyberguide project team. If this occurs, many network problems will disappear. Because of the object-oriented nature of the code ,the network portion can be replaced at will without affecting the rest of the code. Some allowances will be made in the original code for extra information not now available. If and when the network is upgraded, this portion can be used. If the network becomes faulty, the tour guide function will be curtailed. However, information on projects and projected routes will still be available, without position tracking. The software will be able to deal with this possibility, although of course it will be not able to fix it directly.