General help

Current file manager and file picker is not compatible with subdirectories in file areas. Listing of files is relatively easy, the tricky part is how to choose where you want the picked file to land. Depending on what type we choose we might have to implement it in both file manager and file picker somehow.

The Current files is not a true repository plugin because it may also allow write access and file management. I think it should be also visually separated from the repositroy plugins which allow only read access. I agree that the current files section does not always make sense - it should be enabled only when useful (multiple files allowed)

The popup file manager could be also linked from the filemanager formslib element. I guess that could solve the subdirectory issue, unzipping, etc.

I think we should implement both full current files support in picker and also pop-up file manager. The text editor integration should be flexible enough to allow multiple image plugins installed at the same time. Administartors could define several editor set-ups and users could then specify which set of plugins/icons they want or even switch set-ups on the fly.

What do I vote for? Combination of B and C and at the same time giving contrib developers an option to create new A image plugin easily. Users should have an option to specify their own preference too.

Thanks, Martin, for pointing me here.

Oh, a need for design. Oh, but not a chance. If only there was data about what the dialog is most commonly used for.

(Disclaimer: the below is purposefully from a user standpoint and does not discuss the limitations of how much work it is to do something. To design for users the starting point has to be the users and only then look at to what degree the ideal UI can actually be designed, given the technology restrictions.)

To make a bunch of guesses like everyone does, the basic use case is pretty simple: Primarily give users a chance to just pick an existing file from their computer with as little fuss as possible. Other alternatives, such as getting images from other servers are important, too, but in any case the most prominent first step should probably always be uploading. It will take time for the general public of web users to learn to expect that "adding an image" can also mean getting a file from server B (flickr or whatever) to Moodle server A: most users are not aware of the concept of a server, to start with.

So in my opinion, the priorities would be:

1. Most of the time people expect an 'add image' button to allow uploading something they already have. Make this dead simple. The next step is to optionally define the properties of the image, such as the ALT text.
   
2. Users may make a mess and delete a file from a document (and need to get it from the "files already uploaded for this document/whatever")
   
3. Sometimes people may want to find just any suitable image (search flickr) or use something shared in their group/classroom/school.

The Wordpress dialog I uploaded screenshots of seems to meet these priorities quite nicely - although Moodle needs to extend that model by having multiple repositories. See: http://demo.opensourcecms.com/wordpress/wp-admin/page-new.php (user:admin, password:demo). It also supports prominent enough deleting of files from the server. In general, if I were brave enough, I would suggest mimicking Wordpress' version of tinymce and everything related, since they just seem to have so many things taken account and in balance, and are in general praised for usability. Even copying their TinyMCE (especially the toolbars) and file uploading dialog seems a good starting point for our design.

Also, do profit from the fact that media items can be selected: when this happens, provide an option (a button overlay on a selected image) to edit its properties - the user case here is different, so we probably should not have the same dialog but a simple one to just modify the properties and a button to switch the image for another.

Sidenotes: Visibility of system status, Error prevention (heuristics): When the number of files to attach is limited (such as in the forum), do not make users go through the file picker and find a file to find and only then tell them that their work was in vain. When the limit is full, "Add" link should be removed, and a text explaining that the limit is full should replace the link.

Also, in the file picking dialog, the label of the command button to finally select a file (and closing the file selection window) should be a context-sensitive command - "Add to document" for adding the file finally found to the document the user's click originated in, but something else for another context ("Add attachment to forum post"). This helps users stay aware of the context they are in and the task they were doing in the first place, since the file picker is quite engaging in itself. Also, the disappearing of the file picker does not come as a surprise (like it does now) when the target of the command is mentioned in the button: when I click "add to document" I expect to see the document, when I click "select this file" I expect the file to merely become selected for further action.

OK, after some thinking and discussing I think the best and most practical route for Moodle 2.0 is the one now described here:

http://docs.moodle.org/en/Development:Editor_file_management

This plan seems to hit all the requirements and keeps things simple so it's the one we're going ahead with now.

Please feel free to track/comment/help on MDL-16597 (and MDL-14589)

i have made some changes (patch) to the way images are uploaded into the Image Dialog in moodle version 1.9.x (not totally related to your initial post but still...)
http://tracker.moodle.org/browse/MDL-19849

i like to hear your comments on that