Forum .LRN Q&A: Re: LRN Application Status Discussion - File Storage

Collapse
Posted by Matthias Melcher on
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.

Collapse
Posted by Alfred Essa on
Matthias: "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."

Collaborative editing is not the same as version control. It's a strength of OpenACS | .LRN that it provides version control i.e. the ability to manage multiple versions of arbitrary objects, including document, through the content repository. Collaborative editing is something different entirely: you can see who made which changes but you are still working with a single document.

IMHO this is not a UI issue, but a user education issue. We don't see this as a problem among our users.