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

I will be starting a thread for each of the current applications in the .LRN distribution. This is to provide feedback to the user advisory board. The first application is "file storage" What is the state of file storage? What improvements need to be made?

Hello Al,
this is really good idea, well, probably ain't the best person to suggest UI improvements, though I dont like that much the UI of FS, probably I'll need to look at other UI's for comparission.

I expect to get some end users together and link them to the UAB so we can get feedback from them, which usually are the most valuable comments.

I've just sorted a few dozen files in a class where students had not followed consistent naming conventions, where a half dozen files are being added each week, and where I faced a basic problem of organizing group work. I created some directories and, to move things around, ended up doing a lot of clicking and dreaming of drag-and-drop, or at least of selecting bunches of files and then making one move. Is drag-and-drop difficult to do with openacs? Are there other simply sorting principles/methods we might consider?

I also think notifications are the cat's meow, and I'm wondering if others think adding a notification feature to the file storage makes sense: that when you add a file you are given a choice to post a notice in an existing forum, for example, so you don't have to go to all the trouble of copying the url, then going into the forum and building a link. I also like this idea as it suggests further integration of existing communications functionality, and specifically, with notifications, the encouragement of timely responses as a conversation moves forward.

The latest release of file-storage 5.1.2 support bulk moving and copying. I will see if there is a publicly available site for a demo.

The new file-storage also uses listbuilder so that is already taken care of. It also support WebDAV which allows for drag and drop operations from your desktop.

Thanks to MIT Sloan for supporting these improvements to the file-storage package.

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.

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.

Please install or try out the same version of the file-storage package. Perhaps we can install a demostration somewhere so we are all talking about the same thing.

All,

At http://oacs-fs.baasbartels.org/file-storage/ you'll find a brand new, clean oacs-5-1 install, with a file-storage instance up for testing.

Rgds,
Jeroen

I think the content creation as it was mentioned by Michael should not be part of File Storage. Either you can create content using e.g. the Reload Editor and stuff the result into LORS, which should keep track of the relative linking.

Alternatively it might be nice for LORS to be able to import a ZIP file of HTML content, relatively linked, and generate the SCORM package that is generated out of this, automatically.

A totally different approach would have to be taken if you plan to use this not as course material but e.g. for your personal website. In this case, it might make sense to get ETP (or whatever CMS you fancy) to take the contents of the Zipfile, upload all images into the content repository, store the HTML internally and provide the linking this way.

Last but not least, I think the naming of file storage in 5.1.4 already supports this. If you use relative linking it should not break if you upload a ZIP file. If it does, this is a bug :).

<blockquote> Alternatively it might be nice for LORS to be able to import a ZIP file of HTML
content, relatively linked, and generate the SCORM package that is generated
out of this, automatically.
</blockquote>

Although possible, this could be a bit tricky. Say for instance you have the following files in a zip file that you want to share with your students:

[ root folder]
|-> default.html
|-> intro.html
|-> flash_animation.swf
|-> xmlfile.xml
|- [ images folder ]
    |-> randompic1.jpg
    |-> randompic2.jpg

Given this structure, LORS can't really guess or know where the entry points are. We could say, well, maybe the default.html might be the entry point, but again, that's an assumption that we would make.

Now Michael has a very good point here and probably we should clarify the difference between learning objects and plain content.

LORS is good to handle learning objects aggregations (courses) and/or individual learning objects. But if the zip file represented above isn't a learning object neither a course, but a piece of content that I want to share with my students, I shouldn't have to convert it into a learning object by using Reload, creating a content packaging, edit metadata, etc, etc... that'll be rather tedious if I have to do this for each hand out in my class.

Probably an example can ilustrate this better. Say for instance I'm a teacher for a class and on the way to uni on the bus I read this article that relates to the subject I'm teaching today. I might want to add this article as "suggested readings" for the subject. This is not necesarily a learning object as such, but just a random article that might content various pieces that you want to share with your class.

I know -for sure- that File-storage works well linking different pieces of content together using its index.vhu. As a matter of fact LORSm relied on it until recently for all its content delivery -now LORSm has its own.

So summarizing, I think it's good that file-storage still maintains its index.vhu for linking random content that might not necesarily need to be part of a course. It's always good to have that as a choice.

Thanks,

Ernie

From the UI perspective I would agree that it is a major bug.

Technically it is a rather minor issue - something like two mandays. All you need to do is to add the "j" option to the unzip comment (which was there at some point, but then commented out) and then declare all the files in file-storage.

I had some code that was halfway finished but threw it away. Somebody else may have solved this problem though. Anybody out there?

<blockquote> Yeah, I'll do it. I've done a function in LORS that basically given a directory it adds all the directories and files recursively into the CR.
Show I add this to file-storage on HEAD?
</blockquote>

As this is a bug (not working recursive directories in file uploads) please fix it in 5-1 as well.

Furthermore we need to make sure that File-Storage and WebDAV work exactly like Windows Explorer to avoid user confusion. This means if you add a file in webdav that depends on other files in a subfolder (e.g. a large word document, HTML pages) it should work regardless if you add the file cum directories via WebDAV or File-Storage and the view should work as well. This includes Bug #2157 (https://openacs.org/bugtracker/openacs/bug?bug%5fnumber=2157) which seems to me to be a leftover from the name/title misconceptions and changes that happened within FS.