[94] in Tooltime
More notes from the 5/8/96 meeting.
daemon@ATHENA.MIT.EDU (Steven Wade Neiterman)
Wed May 8 22:33:39 1996
Date: Wed, 08 May 96 22:38:44 EST
From: wade@MIT.EDU (Steven Wade Neiterman)
To: tooltime@MIT.EDU
Cc: pakulat@MIT.EDU, jwl@MIT.EDU, endriga@MIT.EDU, tarnett@MIT.EDU
More notes from the 5/8/96 meeting.
For the record, here's all the fun stuff (that I was able to capture)
from the screen/process walkthrough on 5/8.
----------------------------------------------------------------------
Terry handed out new screens from the previous days comments. Lots of
changes, including secondary person search/display, larger display, now
showing "hits' (open calls for a person), and the "thrashing" index.
Walkthrough started with discussion of Mac/PC customer interaction.
These notes capture the process and shows that the basic needs of the
consultants can be met when moving from Filemaker to Scopus.
- Customer calls, consultant asks if calling on existing log, if so,
asks for log number, record in Scopus would then be retrieved.
- If customer does not know log number, name lookup (against log file)
is used. If this fails, location is used, and then hardware/software
information. While there are failure points (e.g. location, name or
phone is different, one of the above searches should locate record).
- If multiple records are found, a result set is returned (this is an
excel like window, where columns can be sorted, a record selected and
retrieved). Result set stays open until consultant closes window,
thus, consultant can pick another record if needed.
- Record is retrieved, history field is updated. After call,
consultant may continue to fill out the history field and then save
the record.
- Log number is allocated when asking for a new form to fill out, prior
to a database commit. Possible gaps is log number if record never
stored. This was decided to be ok if reports can generate activity
for a period without using a starting and ending log number for the
count.
- Discussion issue: What fields need to be shown at all times? A
number of ideas were generated. It's possible that this will become
refined over time as the system is used.
- Question: Can search be done across multiple tabs (multiple forms
are represented by screen tabs in Scopus)? For example, type in
location in the primary form and software in the hw/sw form. Answer:
Yes, but takes a lot of work for this to happen (approx. one week of
effort). Decided to add hardware/software fields to the primary
form.
- Decided that 17" monitor would be recommendation for the Help Desk
and Scopus screens would be built to this standard. There may be
some impact to local consultants. Data would not be lost on smaller
screens (e.g. laptops), there would be a need to scroll. For the
June release, the consensus was that 17" would be fine. (wade - how
would this work on a Macintosh?). Building 16 lab will get a 17"
monitor for testing (Lynne to facilitate).
- Upon entering a new record, telephone number would be the first
lookup item. Name would be second. Searches would be done against
the user table (warehouse feed). Need to understand what fields will
be indexed for the search (username, lastname, phone). All lookup
fields use the "like" clause for wildcarding as well as allowing an
asterisk.
- There were issues of when to search against the user table and when
to search against the log table. It was decided that some manual
method (press buttons were preferable to radio buttons) would be used
such that the user could chose the table of choice for lookup. Some
training would be involved to understand the difference.
- Decided not to update log file with warehouse data as will be done in
the user table. Thus, a name in the log file could be different from
the user table for the same MIT ID. However, this it was preferred
that we do not do automatic updating.
- There were a number of comments on screen field names, position, need
to have present, when drop down list boxes would be used, etc.
Walkthrough shifted to the network installation.
- Network installations have different needs for the consultant since
- There is one (or two) people who fill out the forms
- Others create logs by copy/paste from the net-help meeting. These
"unseen" logs need attention, sometimes appending information to
an existing log.
- An installation may have many people as a contact, relies on a
drop location more than the customers location.
- Gets email messages, different than PC/Mac consultants.
- Needs to review location to see if duplicate, decided to use drop
location for search (before entering new log). Drop location should
be a mandatory field.
- Network consultant (Cynthia?) would need to review the "unseen" logs
entered for the Network installation category. A new log would need
to be created if it was not found to already exist via a search. The
"unseen" log would need to be closed out.
- Discussion of searching history field for information. Since history
field is not indexed (and can contain gobs of data), this was not
recommended for a search. If possible, use existing fields in the
form, such as drop location.
- Future. Would be nice if an incoming email would be automatically
entered into the right queue.
- Many other comments about how to search.
- Peter felt strongly that the summary field (e.g. probably like the
short description field in OLC) should be part of the result set, and
should be a field on the form. After some discussion, reached
agreement on both accounts. Will add the summary field near the
history scrolling field.
- Result set discussion, needs more work.
Installs need seperate result view, let's work on general result
view first.
- Will work on mainframe tabs (form) today.
- Questions on Scopus email interface. Answer: This function and
the Web interface will not be available on the release 1.0 rollout
date. The Web architecture needs to be reviewed, with SSL a
possability for implementation. The email interface needs better
definition, as well as a design review. Issues include how the email
gets automatically posted to a queue.
