Details

    • Affected Branches:
      MOODLE_20_STABLE
    • Fixed Branches:
      MOODLE_20_STABLE

      Description

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

        Gliffy Diagrams

        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

            Petr Skoda created issue -
            Petr Skoda made changes -
            Field Original Value New Value
            Link This issue has a non-specific relationship to MDL-16596 [ MDL-16596 ]
            Martin Dougiamas made changes -
            Summary ajaxify areafiles formslib element Forms element: areafiles (JS)
            Martin Dougiamas made changes -
            Summary Forms element: areafiles (JS) Formslib element: areafiles (JS)
            Hide
            Martin Dougiamas added a comment -

            renamed to filemanager

            Show
            Martin Dougiamas added a comment - renamed to filemanager
            Martin Dougiamas made changes -
            Summary Formslib element: areafiles (JS) Formslib element: filemanager (JS)
            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.
            Dongsheng Cai made changes -
            Assignee Nobody [ nobody ] Dongsheng Cai [ dongsheng ]
            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?
            Dongsheng Cai made changes -
            Attachment MDL-16597.patch [ 15783 ]
            Hide
            Dongsheng Cai added a comment -

            Patch upload plugin to pass itemid.

            Show
            Dongsheng Cai added a comment - Patch upload plugin to pass itemid.
            Dongsheng Cai made changes -
            Attachment MDL-16597.2.patch [ 15784 ]
            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
            Dongsheng Cai made changes -
            Status Open [ 1 ] Resolved [ 5 ]
            Resolution Fixed [ 1 ]
            Dongsheng Cai made changes -
            Resolution Fixed [ 1 ]
            Status Resolved [ 5 ] Reopened [ 4 ]
            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 Skoda 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 Skoda 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 Skoda 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
            Dongsheng Cai made changes -
            Attachment File manager interface (root).bmml [ 18064 ]
            Dongsheng Cai made changes -
            Attachment File manager interface (root).bmml [ 18064 ]
            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>
            Martin Dougiamas made changes -
            Attachment resourcebottom.png [ 18137 ]
            Attachment resourcetop.png [ 18138 ]
            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
            Dongsheng Cai made changes -
            Attachment filemanager-v1.patch [ 18297 ]
            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
            Dongsheng Cai made changes -
            Attachment filemanager-v2.patch [ 18309 ]
            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
            Dongsheng Cai made changes -
            Attachment filemanager-v3.patch [ 18344 ]
            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.
            Dongsheng Cai made changes -
            Link This issue is blocked by MDL-20082 [ MDL-20082 ]
            Dongsheng Cai made changes -
            Attachment filemanager-v1.patch [ 18297 ]
            Dongsheng Cai made changes -
            Attachment filemanager-v2.patch [ 18309 ]
            Dongsheng Cai made changes -
            Attachment filemanager-v3.patch [ 18344 ]
            Dongsheng Cai made changes -
            Attachment filemanager.patch [ 18401 ]
            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.
            Dongsheng Cai made changes -
            Link This issue is duplicated by MDL-20071 [ MDL-20071 ]
            Dongsheng Cai made changes -
            Link This issue is duplicated by MDL-3372 [ MDL-3372 ]
            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)
            Dongsheng Cai made changes -
            Status Reopened [ 4 ] Resolved [ 5 ]
            Resolution Fixed [ 1 ]
            Martin Dougiamas made changes -
            Status Resolved [ 5 ] Closed [ 6 ]
            Martin Dougiamas made changes -
            Workflow jira [ 28560 ] MDL Workflow [ 60944 ]
            Martin Dougiamas made changes -
            Workflow MDL Workflow [ 60944 ] MDL Full Workflow [ 90124 ]

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: