renamed to filemanager

Currently there is no support in draftfiles.php (which provides the content for filemanager) for the file picker - this needs to be changed.

A patch to use filepicker in filemanger.
Petr, I have a problem concerning itemid:
when i edit a forum item, I got a item by $draftitemid = $this->getValue(); and this value changed everytime when I refresh the editing page, so after I moved a file from repository (repository::move_to_filepool), the file will disappear after refreshing, is there any incorrect parameters in move_to_filepool?

Patch upload plugin to pass itemid.

committed code, please review

Looking good! (just needs some tiny css tweaking which I'll do)

ALso needs some XHTML strictizing.

Fixed CSS issues.

filemanager worked now, please reopen it if found any problems, Thanks

Just had a fiddle about with this and was surprised to find it wasn't present on the 'add resource' form. I uploaded a few files on the non-js version there, but found that when I made a forum and went to add files there, the js version popped up, but with none of the files I'd just added anywhere to be found. I'm not sure if they're there, but I missed them somehow, but this is currently very confusing.

see MDL-16089 and http://docs.moodle.org/en/Development:Resource_module_file_API_migration

Ah, I see. They'll be there when the resource module is converted.

I suggest the "Add" link is replaced with "No more attachments allowed" when maxfiles reached. Currently, the attachments over the limit are silently dropped.

Good idea, David, thanks, I disabled the 'add' button once reached max files limit and changed text too.

grrr, the latest change causes problem when maxfiles==-1, also it does not work if max number of files already exists before opening the form - committing fix for the first problem

Added UI Mockup: <File manager interface (on root)>

Added UI Mockup: <File manaager interface (on subdir)>

The file manager interface will more or less like https://www.getdropbox.com/

Added UI Mockup: <moving file interface>

Edited UI Mockup <File manaager interface (on subdir)>: Cleaned up buttons a bit

Added UI Mockup: <filemanager>

Edited UI Mockup <filemanager>: Added a sample resource page

Spec in more detail here: http://docs.moodle.org/en/Development:Editor_file_management

(Coming from http://moodle.org/mod/forum/discuss.php?d=127238 )

It does look pretty simple indeed, great work.

One quick note: just like you have in the mockup at http://docs.moodle.org/en/Development:Editor_file_management , do add the "Browse..." label to the button in the TinyMCE image editor dialog.

• At current the button does not really afford at all what its function is, except by the virtue of its location. * But even there it is so small that it may not be perceived clickable at all,
• so make it look like a button.

Browse is the typically used name for this operation, I believe.

I did a quick single user "usability test". I told my girlfriend, who uses the web fairly lot and knows basic HTML but not programming, to upload an image to "this document" from this computer, a TinyMCE already open in a Resource activity already open.

She immediately found the image adding dialog, looked through the first tab, and closed the dialog. Then she proceeded to look through the buttons in the toolbar, after which she proceeded to look through the rest of the Resource configuration form. Then she asked me, "is it really possible?".

When I told her where she should have clicked, she noted:

• The button does not look anything like what its tooltip says (she did not hover to see if there is a tooltip)
• The field says "Image URL" so that is obviously not something you use to upload images for or even for browsing files on the server

I also realized uploading is not browsing so both choose and browse are misleading. It is getting long, but how about "Browse/Upload..." ?

I further usability tested the design. All eight of my test subjects were lost at some point of trying to upload an image to a document in TinyMCE. Some of the issues are easy to solve and are pretty obvious from the problems users were having. The basic issue is though that there are just too many steps.

http://www.pilpi.net/software/moodle/2009/08/19/quickie-usability-testing-file-upload-and-forgotten-password/

This blog entry will later likely be copied to Moodle Docs.

I will also list the solutions that I think are feasible later.

Which design were you testing?

I have been playing with solutions today but some questions are a bit challenging so I will sleep on it and probably post them next week.

To note this here, as well, the tested (http://www.pilpi.net/software/moodle/2009/08/19/quickie-usability-testing-file-upload-and-forgotten-password/ ) design was:
http://docs.moodle.org/en/Image:Adding_an_image.png (with the exception of the "Choose..." button in the first dialog, which just had a tiny icon in the tested UI in Moodle HEAD)

(Please upload mockups (such as those now in the wiki) to the tracker and link to the tracker items also when using Balsamiq stuff in docs. This way everybody can edit each others' mockups as the bmml files stay in the tracker. This time I made a whole new mockup so no need for that at the moment.)

ajax file manager

Agreed about editable mockups here in tracker and linking to them from docs, that's why I had already done it (although not for all in that document):

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

To include the images from docs, all you need to do is write the URL. No tags, no brackets, eg:

http://tracker.moodle.org/secure/attachment/18130/File+manaager+interface+%28on+subdir%29.png

Docs will embed it automatically.

Mockups for non-JS coming shortly.

Improve UI

Added UI Mockup: <suggestion for clarifying the conceptual model in the UI>
To keep context here, too, adding this

• test report: http://www.pilpi.net/software/moodle/2009/08/19/quickie-usability-testing-file-upload-and-forgotten-password/
• design http://docs.moodle.org/en/Image:Adding_an_image.png (with the exception of the "Choose..." button in the first dialog, which just had a tiny icon in the tested UI in Moodle HEAD)

Finally I got around to finalize my thoughts about how we should react to the findings of the usability testing I did a couple of weeks ago.

I am impressed with how reasonable a model you did come up with eventually. Even though the UI is more defined by conceptual system and software design restrictions than direct suitability to user circumstances, each step in the UI does have a meaning. There is a minor inconsistency with usage of URLs in TinyMCE's dialog (see below), but the workflow seems to be pretty okay in general.

Insert/edit image dialog:

Problem: Users seemed confused by the URL field. And now that you have added the new dialog, it essentially abstracts away the URL; in original TinyMCE the URL was the way of adding any image from the web, in Moodle 2.0 it mostly shows unnecessary guts of the system and gets users confused. The current UI has the input field for an URL first and thus says "if you really really need it, you can also browse to find an URL", although in reality the Choose button is the primary way of getting images. Is there a reason to preserve capability to add images from an URL directly from TinyMCE? The site admin can enable the URL downloader if they want (haven't seen this in action though :/ ), right?

• the users who understand what URL means think this is not what they want (it conflicts with the idea of uploading or getting an image from a repository, yet in the UI it is related to mean the same functionality)
• those users who do not understand 'URL' similarly do not see what that has to do with what they are trying to achieve.

Still, if the URLs produced by Moodle work outside Moodle too (i.e. you can paste the URL of an image, uploaded to moodle, into an email and send it to anyone, unhindered by the permissions system?). If users need to find out the URL of an image it is available in most modern browsers through the right click context menu.

Solution:
Remove the string "URL" from the field label.

Is the URL input field actually ever used in Moodle for adding external images? The "Choose/Upload image..." dialog should consistently be the only place for bringing in new images.

Make the input field it a status display with CSS and move the button before it (see mockup). This will help users see the consequences of their actions (naming the image), giving essential feedback. Optimally just show the filename of the image.

Label the button so that it also reflects the primary usage scenario, uploading files. As a rule of thumb, links (to which this button can be compared) should have the same label as their target windows, so change the label of the target window to "Choose/Upload image" as well.

(Screen readers etc. will still read this as an input field incorrectly, but I do not think users with screen readers etc will ever make it to this dialog anyway.)

Choose a file... dialog:

As "Current files" is the current working space for the user, it should open by default as a starting point and a status display of the files already in use for the current resource - apparently all images selected elsewhere are brought here? As file uploading is a primary usage scenario, add a link to that screen here (see mockup).

The label "Current files" meant nothing to users in the usability testing. If this is used for just uploaded files, change the label to "Uploaded files", but if/as I suspect it is used for all files for the current editor, then change it to "Files in use". The "Empty result" it shows by default does not clarify what the tab means, instead use "No files in selected for use yet".

"Local files" are not local files to the user, but files on the server. Name this either according to the Moodle site, or just "Server files". "Local server files" may be confusing since users may not know the concept of a server.

Make the "Upload this file" button an YUI button or otherwise look like a button. It was not recognized as a button by some users in testing.

At a minimum (if a better button label can not be found), add a help icon next to "federated search" since based on the testing that term is not likely to be understood by at least people who are not native.

Toolbar:

Dealing with MDL-20139 is probably the best we can do about the toolbar - plus perhaps keeping the 'add image' item in the right-click context menu. (As soon as drag and drop or copy pasting of images becomes possible on the web, it seems critical to support it.)

support setting primary file

• We do somehow have to retain the ability to enter a raw URL without downloading the file
• So add that in the file picker dialog, either in the same screen as the url downloader (though the name of url downloader may have to be changed to "get from url") with a checkbox "download to [[moodlesiteshortname]] server" or as a separate tab on the left in the fialog? the point is just to not confuse people with multiple mechanisms in multiple dialogs

If you think there is a risk that people would actually expect to enter an URL in the TinyMCE dialog (people who have gotten used to tinyMCE dialog, which is not likely a majority of moodle users):

Another option is to add a link under the "Choose / Upload image... " button ("Use URL") and have it trigger the display of an URL field under the button. But I still think the above solution is better since it is more consistent with itself: there is only one consistent UI mechanism no matter which the source is.

Just had a review of your filemanager form element, Dongsheng. Mostly very good and usable now!

There are still some known problems:

• Can't move directories yet
• Main file picked doesn't always select reliably
• Main file picked doesn't show up as selected when updating a resource
• Downloaded zipped directories should unzip as a folder with the same name exactly (not 0)
• Downloaded Main files directory needs a better default name (draftarea.zip -> Files.zip from lang pack)
• First triangle before the "Files" path should either not be there or be a better icon (perhaps folder icon?)
• Should be able to right-click on the files to get the context menu
• Not all the code files have Copyright info.

... however, I think it's good enough to put into HEAD now and solve all these issues there. Can you check it in please?

Reply to Olli:

Firstly, thanks very much for the testing, designs and feedback.

A. URL field

Yes I think we do need to retain the ability to paste in a URL there, since

1) that dialog needs to cope with all kinds of different ways of getting images in the editor. For example did you notice you can drag and drop into the editor?

2) Power users will also want to include images from external servers sometimes (perhaps an image that changes or a webbug that allows tracking).

https://secure.gravatar.com/avatar.php?gravatar_id=dabb9c64633b953c2d2a4a591aec6d27&rating=PG&size=100

Since the filepicker always COPIES chosen images from the source into the Moodle file system it's not suitable for this.

3) TinYMCE needs a URL to work with in that dialog, to create the proper HTML etc. Removing it will cause more major TinyMCE mods.

However, I'm totally in agreement about making it less important and making a much more visible "Choose / Upload an Image..." button at the top. You should see this soon in CVS.

B) Local files ---> Server Files. Yes, developer perspective. Absolutely makes sense to fix it, now fixed in CVS.

C) "Upload this file" button. Yes, it still doesn't look enough like a button, will be fixed ASAP with more CSS.

D) Toolbar -----> MDL-20139

Thanks.

1) Users indeed tried drag'n'drop, but they tried to do this directly to the editor. This did not work, neither did copy/paste (of images), as expected since I guess it is not supposed to be possible in current editors. What does this have to do with the dialog? Sorry, I do not follow.

2) So the file picker dialog is incapable of just linking to an external resource instead of just linking to it? Seems to me this is a flaw designed into the file picker, since I can not imagine a reason it would make sense to any user group that linking to external files happens in one dialog, whereas downloading/copying files happens in another. Whether a resource is linked to or copied is not a separate functionality to users, it is a parameter of "just let me have the d*mn image in my document", and most of the time it is a parameter irrelevant to users - it should be there, and it should have a reasonable default value so that it can be ignored if needed. The file picker should be capable of doing both, if not you are just jumping the users around.

You do not really respond to my suggestions about what is the problem with this? Or is this a case of glueing design for users on after doing the implementation and realizing that design should have been done beforehand since now it is too much work to change it to work right?

3) I am not saying you should remove the URL field, I am saying that in that context, to the user, it is irrelevant system guts and it should not be shown to users. As you know, there are quite a few ways to hide it without messing with tinymce's inner workings.

1) Open two browser windows. Have an editor in window 1, and an external web site in window 2 (eg flickr.com). Drag images from window 2 into window 1 editor. it works. Now click on the image to select it, then click on the "Edit Image" button in the toolbar. The fields contains the foreign URL.

2) In fact the filepicker is designed to allow linking as well as copying and it's up to the plugin (see Youtube plugin for example) but most of the core plugins don't do it because:

• it's almost always bad news ... teachers will select things they have access to but students don't. The security of the external resources will be different from the internal and not subject to the roles/permissions of the internal activity that contains the media.
• teachers usually want pages to stay as they made them - not be subject to breakage from outside changes in an increasingly dynamic internet
• you'd have to have a checkbox to select link/copy behaviours every time you select a file (extra complexity)
• you would have to remove all this behaviour from the interface for attachments (---> inconsistency)

3) We can probably hide the URL field by default and put it in a checkbox to 'Show URL', sure.

The point about users usually wanting to download is a good one: "when you do not know what you are doing, download." Still, as linking needs to be possible sometimes, the fact that this functionality is in a different dialog where nobody expects to find it does not seem to help. Even at current users have to guess if availability of content is subject to the deletion from the website they took the content from (Youtube), or controllable (also in terms of permissions) from the local Moodle site, so in any case the consequences of implicit linking should be made clear in the process at some point.

"You are about to link to this image.

• If the remote site where the image resides goes offline, the image will not show here, either
• Moodle cannot control access to the image, so for example even students without access to your course may see this image.

Uncheck the checkbox above to download the image instead (usually recommended)."

And in case this is added (when the checkbox is selected), then there needs to be a corresponding note when it is the check is removed, to reassure the users about the consequences in that case.

"You are about to download this image to the Moodle site [servershortname].

• The image will always be available when this Moodle site is online
• Moodle control access to this image, so students without access to your course cannot access to it

*Link to this image instead"

If there is an issue of users needing to be aware of the consequences of whether a resource is linked to or downloaded, that issue is there regardless of whether the UI is designed to be consistent with itself in the first place. As you state that editing the URL is sometimes a feature required by the advanced user, so having the "show/edit address (URL)" link there is probably appropriate.

But yes, if downloading is the default action, then the linking functionality should probably be hidden with progressive disclosure ("Advanced: link to the resource") to not clutter up the UI and slow down novices, by making them read notices of the consequences of their actions (as the consequences are assumably safe in case of downloading).

1) Oh, that's sweet. I was surprised though that users even try dNd from desktop to browser, since all research I have ever heard about says users do not use drag&drop on the web since it is usually not possible. Thus, it usually requires extra affordances in the UI for users to become aware of it. Of course, if universities teach their users to use this, then that is an affordance to use the feature. As even the concept of having multiple browser windows can be a challenge to many, the motoric exercise of putting two windows side by side to facilitate the dragging, I it is kind of hard to see this becoming a popular feature, though in some contexts it might.

Back to the point, seems to me in this case it is not at all obvious whether the dragged image should be linked to or downloaded. Obviously only resources that are downloaded are reliable in the context of the local moodle site. So if the image is only linked to, the teacher should have warning about this anyway.

(In Google Chrome on Linux it creates a link to the image, though that link can not be seen in wysiwyg since it is empty)

2) The only difference between the concept of attachment and a link is the same one as that between a downloaded file and an attachment. If it is clear in some context that only downloading makes sense, then disabling (not deleting!) the checkbox to make a link instead, is keeping the UI consistent. Of course, if it cannot be assumed that it is clear to users why a given context only allows attachments and not linking, then the user may need to be made aware of why linking is not possible (tooltip over the disabled checkbox and its label?) - again, regardless of whether there is a checkbox to allow linking or not. That is: if it is possible to link in one context, regardless of what that UI looks like, then the situation of not being able to do that is in any case a special case that needs to be taken into account in the interaction design.

3) If it is "edit URL", then don't have a checkbox "show URL". As non-techies do not understand URL anyway, it should be "show/edit image address", or if you can't have the name of the type of the resource there, show/edit address (URL). And if you do not plan to have a submit button next to the checkbox to actually make the selection happen, do have a command link with that text instead of a button. Having checkboxes without forms (=auto-submitting forms) equals violating the HTML standard and is usually an accessibility issue. (yes, I am looking at your navigation dropdown menus, too! -> see http://developer.yahoo.com/yui/3/examples/node-focusmanager/node-focusmanager-3.html but with links instead of command buttons in the source)