Laserfiche WebLink
<br />. <br /> <br />. <br /> <br />. <br /> <br />Issues concerning the various hardware and software combinations should be addressed <br />in order to determine how to accommodate as broad a range of users as possible, These <br />accommodations should be such that nov:ce users will be able to use the system and, at the <br />same time, the system will be efficient enough to provide advanced users with sufficient <br />operating comfort. <br /> <br />A range of solutions will be evaluated, including those which imply a system with a <br />single set of operations to meet the needs of the majority of users, as well as designs which <br />will offer both novice and advanced user facilities. <br /> <br />An additional issue which needs resolution is the choice of a hardware/software <br />platform and how choices affect the functionality and/or operation of the system. For <br />instance, a user with a workstation would likely have a fully functional Graphical User <br />Interface, whereas a user with a non-graphics terminal may be provided only some <br />non-graphical subset of that functionality. <br /> <br />Approaches which provide for full functionality for a large number of different <br />platform~ are also available. At least two approaches can be considered. One approach <br />allows developers to code their software using a single neutral graphics language. Users can <br />then specify their individual "look and feel" at run-time. Another option is to develop a user <br />interrace- independent kernel on which user interrace shells could be added when needed. <br />Either of these options would allow the system to be used over a diverse set of platforms. <br /> <br />. <br /> <br />If either of these options proved prohibitively difficult or expensive. it may become <br />necessary to associate specific platforms with specific functionality, First. the functionality <br />e::.ch platform could reasonably support needs to be determined. For instance, a <br />monochrome, non-graphics terminal would nor be a good choice for the display of GIS map <br />dat2. On the other hand. such a terminal would be perrec:.ly capable of displaying the <br />numeric data stored in a relational database, Thus. it might be appropriate to provide a <br />form-based database retrieval system that would allow access to the inrormation stored in a <br />relational database for non-graphics terminals. It wiil be clear that as part or the feasibility <br />study, these and other options will be evaluated. <br /> <br />Another important issue concerns the effect that system architecture will have on <br />useability. A number or possible options e;(ist for set-up of a system such as CDRSS. These <br />range from designs where all data management and processing are accomplished locally, to <br />designs where all data management and some or the processing are done remotely, There are <br />advantages to keeping all data and processing locally; the main one is processing speed. In <br />addition, the data can be altered as desired by the local site, This ability, though, has <br />disadvantages, in that the integrity of the data cannot be assured. Thus, local users could <br />alter their own data and not be assured of correct simulations. Also, if the data needed to <br />be changed for all sites, it would be a potentially difficult and error-prone task to insure that <br />all data was accurately updated. <br /> <br />Another option is to store the data in a central location and allow machines running <br />locallv to access the information as desired. This has a number of advantages. as well as at <br />- -- <br />. least one disadvantage. The main advantage is data integrity, Since data would be stored in <br /> <br />.10- <br />