I would really like your feedback and extension to the ideas here to help us decide the best path:
Feel free to add new ideas to the document or just reply to this discussion.
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.
* two tabs, second tab would be hidden if more then one file or subdirectories allowed
* list and thumbnail display controls moved right of the repository
* uploading into subdirectories possible - choose dir and switch to first tab
* selection of "main" file possible - needed for new resource module
* search and federated search replaced by All checkbox
* moved personal files and recently used files to separate repo plugins, the local files could default to old course files in course which were upgraded from 1.9
* file count and size restriction info included
PS: hmm, there should be Unzip command insted of Zip and maybe Resource content area name which is more likely to contain subfolders.
I think I grasp Petr's idea which uses tabs instead of different icons on the tool bar. Assume that would be trigger by one icon. Unzipping is important. I upload a series of images zipped in a file all the time and did Petr delete feature? Maybe it would appear as an action item on the file name line as it does in 1.9.5 and was left out of the conceptual drawing. Petr's idea is logical to me and not too shocking (as a stick in the mud)
Appreciate all the thought that goes into this kind of thing. At the moment, I can barely grasp the filters and or link buttons that will go to places or view certain file types in a search for linking. Need to get my hands on it. The transition is important, a piece has to be there that looks similar to "the old way" of adding and linking files in a content area.
I suppose unzipping should not be that important any more, depends on your favourite workflow:
* upload zip file to directory in your personal files and then "use" it in any editor instance
* transfer your images directly to personal files via WebDav and use them anywhere
* upload all your file to some web other repository and maintain them there
* use built-in image editor plugin (not yet there) and copy paste images from other applications
Now that I think more about this, it would be really nice to have some online image editor in the 3rd tab
(pixlr.com OR aviary.com) . see sample link:
there are APIs for each service.
so, after editing we can upload the image back to moodle.
here is a tracker: http://tracker.moodle.org/browse/MDL-18970
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:
- 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.
- 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")
- Sometimes people may want to find just any suitable image (search flickr) or use something shared in their group/classroom/school.
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.
Wordpress has a much simpler task because it generally has one author posting blogs with images, video and sound.
- Moodle needs to manage all kinds of files, including hierarchies of html files or word documents, for example, as well as attachments.
- Moodle has to be able to support the many new types of repositories (with browsing and searching) that we want to support.
- Finally we are trying very hard not to modify core TinyMCE at all (just adding plugins), so that we avoid the forking problems we got into with the old HTMLarea in Moodle 1.x.
For all these reasons the filepicker part where you choose a file to use is separate from the settings and preferences about where the file actually ends up. So I can't see the filepicker that we currently have in 2.0 changing much in functionality, we just need to fit it all together in the best way.
However, I do agree with the priority list and your sidenotes.
And yes, I totally agree that good data would be very useful, unfortunately it looks like we need to create some draft solution first so that people can understand the full extent of the issue in practice.
I think this adding-plugins-approach is the best way to go if we want to be able to update TinyMCE regularly in the future. The pluggable editor system that Petr added allows also different configurations for several editors with different plugins so we don't necessarely need to have / show same editor plugins for all users.
Moxiecode itself (team that made TinyMCE) is using different plugins (Ajax based interface using a JSON bridge) for filemanager and imagemanager in addition to standard image and link plugins that can be seen and tested in full version demo http://tinymce.moxiecode.com/examples/full.php
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)
This blog entry will later likely be copied to Moodle Docs.
I will also list the solutions I think are feasible, as soon as possible, at MDL-16597 .
"Except for the [Choose...] button in the Insert/Edit Image dialog, this diagram/mockup is a very close image of the functionality in Moodle 2.0 HEAD I tested."
and relevant to this part of the discussion. (i think)
i saw the new file picker some time ago (since, i am working with a local moodle 2 dev version, fixing hebrew issues) and i personally like it allot.
we teach K12 teachers (Israel) how to use moodle and how to build courses, on a face-to-face tutoring sessions (classes).
so we have the luxury of teaching them what is the right sequence of actions you need to take when adding a new image to an HTML text box. and not have them use intuition to figure it out.
on the other hand, when instructing at Collages and Academic...
the old academic stuff (Prof and Drs) prefer simple (very simple) sequence of actions
to load an image into the system. they do not like all the functions and abilities. (it is an old generation)
so this link: http://docs.moodle.org/en/Image:Adding_an_image.png
actually shows what they do not like to do. and get confused doing.
they like to...
1. click on the image(icon) on the toolbar of the html editor
2. get a local computer file chooser (and choose a file/image)
3. after pressing OK on the previous dialog. have the image automatically upload into the course's storage. and immediately displayed back into the html editor. (no entering of ANY properties and no choosing of where to upload it into)
please see my patch for this kind (very similar) of behavior for Moodle 1.9.x
i saw you suggestion : http://tracker.moodle.org/secure/attachment/18312/suggestion+for+clarifying+the+conceptual+model+in+the+UI.png
and it is too complicated. (sorry) no for me but for a regular user.
it reminds me that (some time during the last year) i split the resource "add a file or a url" to "upload a file" and "insert a weblink" (because i was ask to!)
here is a link to them: http://www.tikshuv.org.il/moodle/contrib/mod/resource/type/ (if you like to try) and the file upload is uploading an image into the course's file repository with one click. quick and simple. no questions asked.
the users do not want to save UI space or make it more technically optimized or sophisticated (really)
they want it short (sequence of actions) and similar to what they already know.
(that is what i am told by all the Teachers, Professors and Drs i teach to use Moodle.
not the youngsters! they can use anything you throw at them )
i suggest we add a new button to the html editor toolbar for "instant file upload" and embed. no question asked. nothing.
the uploaded file should be place in the course main storage folder and all its properties set initially as best we can.
if they want advanced file upload... this is another button.
i like to hear your comments on that