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