Details

    • Affected Branches:
      MOODLE_20_STABLE
    • Fixed Branches:
      MOODLE_20_STABLE
    • Rank:
      33305

      Description

      current areafiles is suitable works without any JS,
      it needs to be a bit prettier and should use ajax & new file picker

      1. File manaager interface (on subdir).bmml
        5 kB
        Martin Dougiamas
      2. File manaager interface (on subdir).bmml
        5 kB
        Martin Dougiamas
      3. File manaager interface (on subdir).bmml
        5 kB
        Martin Dougiamas
      4. File manaager interface (on subdir).bmml
        4 kB
        Martin Dougiamas
      5. File manaager interface (on subdir).bmml
        4 kB
        Dongsheng Cai
      6. File manaager interface (on subdir).bmml
        4 kB
        Dongsheng Cai
      7. File manaager interface (on subdir).bmml
        3 kB
        Dongsheng Cai
      8. filemanager.bmml
        3 kB
        Martin Dougiamas
      9. filemanager.bmml
        4 kB
        Martin Dougiamas
      10. filemanager.patch
        46 kB
        Dongsheng Cai
      11. File manager interface (on root).bmml
        4 kB
        Martin Dougiamas
      12. File manager interface (on root).bmml
        4 kB
        Martin Dougiamas
      13. File manager interface (on root).bmml
        3 kB
        Dongsheng Cai
      14. File manager interface (on root).bmml
        3 kB
        Dongsheng Cai
      15. File manager interface (on root).bmml
        3 kB
        Dongsheng Cai
      16. MDL-16597.2.patch
        12 kB
        Dongsheng Cai
      17. MDL-16597.patch
        10 kB
        Dongsheng Cai
      18. moving file interface.bmml
        3 kB
        Martin Dougiamas
      19. moving file interface.bmml
        3 kB
        Dongsheng Cai
      20. moving file interface.bmml
        3 kB
        Dongsheng Cai
      21. suggestion for clarifying the conceptual model in the UI.bmml
        14 kB
        Olli Savolainen
      1. File manaager interface (on subdir).png
        66 kB
      2. filemanager.png
        78 kB
      3. File manager interface (on root).png
        59 kB
      4. moving file interface.png
        37 kB
      5. resourcebottom.png
        53 kB
      6. resourcetop.png
        47 kB
      7. suggestion for clarifying the conceptual model in the UI.png
        165 kB

        Issue Links

          Activity

          Hide
          Martin Dougiamas added a comment -

          renamed to filemanager

          Show
          Martin Dougiamas added a comment - renamed to filemanager
          Hide
          Martin Dougiamas added a comment -

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

          Show
          Martin Dougiamas added a comment - Currently there is no support in draftfiles.php (which provides the content for filemanager) for the file picker - this needs to be changed.
          Hide
          Dongsheng Cai added a comment -

          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?

          Show
          Dongsheng Cai added a comment - 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?
          Hide
          Dongsheng Cai added a comment -

          Patch upload plugin to pass itemid.

          Show
          Dongsheng Cai added a comment - Patch upload plugin to pass itemid.
          Hide
          Dongsheng Cai added a comment -

          committed code, please review

          Show
          Dongsheng Cai added a comment - committed code, please review
          Hide
          Martin Dougiamas added a comment -

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

          Show
          Martin Dougiamas added a comment - Looking good! (just needs some tiny css tweaking which I'll do)
          Hide
          Martin Dougiamas added a comment -

          ALso needs some XHTML strictizing.

          Show
          Martin Dougiamas added a comment - ALso needs some XHTML strictizing.
          Hide
          Dongsheng Cai added a comment -

          Fixed CSS issues.

          Show
          Dongsheng Cai added a comment - Fixed CSS issues.
          Hide
          Dongsheng Cai added a comment -

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

          Show
          Dongsheng Cai added a comment - filemanager worked now, please reopen it if found any problems, Thanks
          Hide
          Matt Gibson added a comment -

          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.

          Show
          Matt Gibson added a comment - 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.
          Show
          Petr Škoda added a comment - see MDL-16089 and http://docs.moodle.org/en/Development:Resource_module_file_API_migration
          Hide
          Matt Gibson added a comment -

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

          Show
          Matt Gibson added a comment - Ah, I see. They'll be there when the resource module is converted.
          Hide
          David Mudrak added a comment -

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

          Show
          David Mudrak added a comment - I suggest the "Add" link is replaced with "No more attachments allowed" when maxfiles reached. Currently, the attachments over the limit are silently dropped.
          Hide
          Dongsheng Cai added a comment -

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

          Show
          Dongsheng Cai added a comment - Good idea, David, thanks, I disabled the 'add' button once reached max files limit and changed text too.
          Hide
          Petr Škoda added a comment -

          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

          Show
          Petr Škoda added a comment - 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
          Hide
          Dongsheng Cai added a comment -

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

          Show
          Dongsheng Cai added a comment - Added UI Mockup: <File manager interface (on root)>
          Hide
          Dongsheng Cai added a comment -

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

          Show
          Dongsheng Cai added a comment - Added UI Mockup: <File manaager interface (on subdir)>
          Hide
          Dongsheng Cai added a comment -

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

          Show
          Dongsheng Cai added a comment - The file manager interface will more or less like https://www.getdropbox.com/
          Hide
          Dongsheng Cai added a comment -

          Added UI Mockup: <moving file interface>

          Show
          Dongsheng Cai added a comment - Added UI Mockup: <moving file interface>
          Hide
          Martin Dougiamas added a comment -

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

          Show
          Martin Dougiamas added a comment - Edited UI Mockup <File manaager interface (on subdir)>: Cleaned up buttons a bit
          Hide
          Martin Dougiamas added a comment -

          Added UI Mockup: <filemanager>

          Show
          Martin Dougiamas added a comment - Added UI Mockup: <filemanager>
          Hide
          Martin Dougiamas added a comment -

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

          Show
          Martin Dougiamas added a comment - Edited UI Mockup <filemanager>: Added a sample resource page
          Hide
          Martin Dougiamas added a comment -
          Show
          Martin Dougiamas added a comment - Spec in more detail here: http://docs.moodle.org/en/Development:Editor_file_management
          Hide
          Olli Savolainen added a comment -

          (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.

          Show
          Olli Savolainen added a comment - (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.
          Hide
          Olli Savolainen added a comment - - edited

          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..." ?

          Show
          Olli Savolainen added a comment - - edited 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..." ?
          Hide
          Olli Savolainen added a comment -

          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.

          Show
          Olli Savolainen added a comment - 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.
          Hide
          Martin Dougiamas added a comment -

          Which design were you testing?

          Show
          Martin Dougiamas added a comment - Which design were you testing?
          Hide
          Olli Savolainen added a comment - - edited

          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.)

          Show
          Olli Savolainen added a comment - - edited 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.)
          Hide
          Dongsheng Cai added a comment -

          ajax file manager

          Show
          Dongsheng Cai added a comment - ajax file manager
          Hide
          Martin Dougiamas added a comment -

          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.

          Show
          Martin Dougiamas added a comment - 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.
          Hide
          Dongsheng Cai added a comment -

          Improve UI

          Show
          Dongsheng Cai added a comment - Improve UI
          Hide
          Olli Savolainen added a comment - - edited

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

          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.)

          Show
          Olli Savolainen added a comment - - edited 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.)
          Hide
          Dongsheng Cai added a comment -

          support setting primary file

          Show
          Dongsheng Cai added a comment - support setting primary file
          Hide
          Olli Savolainen added a comment -
          • 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.

          Show
          Olli Savolainen added a comment - 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.
          Hide
          Martin Dougiamas added a comment -

          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?

          Show
          Martin Dougiamas added a comment - 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?
          Hide
          Martin Dougiamas added a comment -

          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

          Show
          Martin Dougiamas added a comment - 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
          Hide
          Olli Savolainen added a comment -

          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.

          Show
          Olli Savolainen added a comment - 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.
          Hide
          Martin Dougiamas added a comment -

          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.

          Show
          Martin Dougiamas added a comment - 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.
          Hide
          Olli Savolainen added a comment -

          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)

          Show
          Olli Savolainen added a comment - 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)

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: