[132] in Tooltime
re: testing update - we are ready
daemon@ATHENA.MIT.EDU (oliver thomas)
Thu Jun 13 01:44:32 1996
To: "Tim `The Tool Man' Taylor" <tooltime@MIT.EDU>,
"Terry `Mr. Borland' Arnett" <tarnett@MIT.EDU>
Cc: oliver thomas <othomas@MIT.EDU>
Reply-To: oliver thomas <othomas@MIT.EDU>
Date: Thu, 13 Jun 1996 01:44:24 EDT
From: oliver thomas <othomas@MIT.EDU>
good morning,
we had a chance to play around with the solaris scopus client today. here
are some of my thoughts and a run through the check list. things worked
pretty well overall.
it is pretty quick on searches and does ok on startup time. a few basic
benchmarks on loading time (on a "stock" athena sparc 5):
time to login window: 32 seconds
time to map main screen: 42 seconds
here is my checklist:
1. are the required fields obvious?
pretty much.
2. can you open a new log?
yes.
3. can you autofill the client information with your own name etc.?
yes. not to press the point or anything, but it would be nice if the
client did not insist on the user typing in the value in all caps. it is a
pain. if it helps any, 'string toupper "your favorite name here"' will
convert a string to uppercase.
4. can you fill in hardware, o/s, and software information?
yes. as cynthia mentioned, some of the pop up lists could use a few more
choices. if i ask a question in the unix queue, "unix" or some flavor
thereof might be a good option to have in the o/s list ;) same for
hardware.
as a matter of fact, a lot of those popup lists could use an "other"
option.
5. did the pick lists do the right things?
yes. an "other" option would be nice for these as well.
6. can you change the choices?
yes. the pick lists should probably revert to empty when the related popup
menu is changed.
7. did the supported flag work?
yes.
8. did the status tab get updated?
not automatically.
9. can you save the record?
yes. a little weirdness: the "save" button saves the record, but when you
then hit "close" it asks you whether you really want to discard the
changes you've made, even if none were made. clicking "Yes" does no harm,
but until that is remembered the dialog box does make one a bit nervous.
10. can you set the call category, call queue and status fields?
oops. guess i jumped ahead. yes.
11. now can you save the record?
yes again. see (9).
12. can you call up the record created by the person next to you?
yes. (she wasn't exactly next to me, but close enough...)
13. can you call up a record, alter it and resave the record?
yep.
14. can you close a record?
yes.
15. can you find a record, mark it as taken and save it?
yes.
16. can you freeze a record?
yes. so...how come we can parse a date and convert it to a standard
format but we can't do the same thing with the phone number? sorry, i'm
just being difficult...again, in case it helps,
regsub -all {(-|\(|\)|x|X| )} "(617) 555-1212" "" search_me
should return a 'good' phone number in $search_me.
17. can you find and autofill the information from an email address?
yes, but see (3).
18. if you set a record to housecall or netinstall did mail get sent?
no.
19. can you enter information in the tabbed forms?
yep.
20. can you make a date and time stamped entry in the housecall and
netinstall history fields?
no. actually, playing with this crashed the client.
WARNING op_update_rel: dbsqlexec failed.
poof.
21. does the quick button work?
no. i may be missing something here, but it is ghosted out.
22. does the close log button do the right things?
no. same as (21).
a few quick notes:
o i am unclear on some of the fieldnames. i may have missed some discussions,
but what exactly is the difference between "Address" and "MIT Address"?
o as you know if you've glanced over some of the test logs, the "Role" field
is an invitation to be creative. if it is really intended to be used to
prioritze logs or convey special priviliges to them, a popup menu with
predefined values would be a good idea.
o the same goes for "MIT Status".
o there is a problem with the main text ("history") field. entries made in
it do not get automatically time stamped and don't even seem to be tracked
in the history table. i assume this will happen eventually, but just in
case no one noticed...
one of the main problems with the old databases was that there was no
hard, strictly enforced, "read-only" log of who entered what information
when. for a positive example of this, see olc (plug).
o the error messages need some work. for example, "ORA-01401: inserted
value too large for column" leaves a lot of room for guess work, since
it does not tell you which field generated the error.
finally, a few cosmetic things:
o labels are breaking out of their frames (this may be a sun-only
problem).
o if the window is down-sized, no scrollbars magically appear, as they
probably should. makes it difficult to fill in fields beyond the
window borders (this may also be a sun-only problem).
thank you, and sorry if this ran a bit long.
cheers,
oliver.
