Day3
Day 3 of daily blogging.
Yesterday there was much discussion about usablity that I was not to pleased with. It is a constant battle to help people understand something that they neither have the capacity or desire to comprehend.
A logger pane was added to the experiment window in an effort to present more information to the user easily. This is a completely redundant pane as all the information is displayed in the Logger Window. The logger pane was added to bring the info and warning messages to the forefront. However I do not suspect this in itself will assuage any user issues as no one has adequate awareness of what is happening to read or comprehend the logger messages.
Another Tab should be added to the logger pane for Critical messages. I added
a method to logger_setup called set_exception_handler which hooks into
sys.excepthook. set_exception_handler takes one optional argument func.
func should be a callable that takes three arguments exctype, value, traceback,
where exctype is the Exception Class exctype is the Exception object and traceback
is a traceback object (use traceback.format_tb or print_tb to format the traceback object
for printing or logging). If no func argument is supplied a default exception_hook is
used. The default simply logs the exception as a critcal log message and calls the
original sys.excepthook using sys.__excepthook__
Some other mechanism could be added for presenting additional information to the user. Users apparently are having a difficult time interpreting failure states (in my opinion because of a lack of desire, experience and capacity to understand). Typically users do not recognize 1) what the problem is or 2) what solution to use. All of the failure states should be laid out in the documentation but again since no one uses the documentation, this is unrecognized work. An effort, however, to make info, confirmation, and warning messages more descriptive, less esoteric and jargony is desirable.
There are three cases in which users appear to have the most trouble 1) program launch 2) experiment launch 3) intra experiment failures. In all cases a dirth of information and messages are supplied to the user for diagnosis. In all cases improving the readability of the information would go a long way. The location of all the information remains a problem and I do not yet have a good solution. One would think the logger window and popup dialogs would be sufficient but 1) users are incapable of navigating and managing multiple windows on the desktop and 2) not interested in learning the meaning, cause, and solution to problems.
Program Launch
Experiment Launch
Intra Experiment Failures
This may seem like alot of whinging about users but this has been a continuing problem and appears that only myself is make a significant effort to rectify. It would be best if users could meet me 10% of the way, which at this moment appears unlikely. End users have explicitly stated they do not want to understand but want to be competent users. This is totally contradictory and makes the teaching and documentation process difficult, time-consuming and ultimately completely unrewarding.
