We have discussed the filestore UI in the UAB, and my
conclusion is as follows.
The main source of end user confusion is the application's
conflicting pursuit of two objectives:
1. Lightweight content delivery / presentation. This is
- why filestore is using so called "titles" in addition
to file names;
- why its default action (when clicked) is displaying the
content in a dotLRN framing (of navigation bars) rather
than in a clean window with its own layout, and
suppressing the original html title of html files;
- why filestore's focus is far away from the files'
originals, e. g., URLs without their proper locations,
and files with unfamiliar long mime-type names
("application/vnd.ms-powerpoint") rather than their
proper extensions (".ppt") and icons;
- why filestore uses its own version administration,
confusing not only people who use their word processors'
built-in revision tracking for collaborative editing, but
also ordinary users asked to enter revision descriptions.
2. Storage, and interfacing to more sophisticated content
delivery and presentation, which needs
- relative LINKING (e. g., from a lesson overview html file
to indvidual html pages and embedded pictures,
- granular addressability of the reusable objects (e. g.
instead of just entire pdf dumps, individual slides to be
discussed in the forums during the constructive
understanding process, or for interactive exploration
of slides being clickable maps).
- shorter URLs, to have at least a chance to handle them
without intervening line-breaks.
The conflict between these two approaches is not only reflected
in lots of terminological and other confusion in the user
interface (e. g., names vs. titles,
https://openacs.org/forums/message-view?message_id=135270
but especially in various bugs like
https://openacs.org/bugtracker/openacs/com/dotlrn/bug?bug%5fnumber=929
https://openacs.org/bugtracker/openacs/com/dotlrn/bug?bug%5fnumber=2072
where the designed behaviour is controversially disputed.
If the two above approaches cannot be combined in a common
behaviour design, it is IMO necessary to separate them at site
setup time using a configuration parameter where the
administrator could specify "Switch all the confusing title and
versions handling completely off and use native filenames and
relative linking".
This principal conflict is IMO so important that I wanted to
post the issue before we turn to other and minor problems, among
which there is another cluster of problems grouping around
permissions (questionable defaults and wording for the group's
and uncovered folders, and permission setting dialogue).
Minor UI distortions (like line breaks in byte counts) are
not yet enumerated.