Cross posted from the database module forum for maximum exposure
--
Currently the export form for the database module is rather confusing, and with the portfolio support in Moodle 2.0, it becomes more so.
There needs to be a way to ask the user to select both an export format, and a portfolio instance. There are two problems:
1. The export format is dependent on the portfolio (and the other way around too) - whichever you select first restricts the availability of the second. For example if you choose Leap2a portfolio format - you can't export to flickr, and similarly if you choose the portfolio first, if you choose flickr, you can't select Leap2a format. We normally get around this by putting these controls in a wizard with different screens.
2. The current form has a selection to choose which fields from the data module you wish to export, and while this works at the moment, it is inappropriate for Leap2a, which is what I'm looking at adding. (For example for CSV you can't export image fields, but you can in Leap2A)
The best solution I can see, is to convert this tab into the start of the portfolio wizard, and go through the following steps:
- Select the format you want to export
- Select the portfolio plugin, and if necessary, ask which fields the user wants to export.
This retains BC, because there is a 'file download' portfolio plugin, which means the user can download their CSV file as normal, it just goes through the portfolio API, where before it didn't.
However, this has the downside of making the file download portfolio plugin available for everyone, which may not be wanted at all. Also it means that the administrator must enable portfolios, and enable that plugin.
Can anyone see an elegant way to solve this? If we can come up with a clever screen design to include both the normal export to file (no portfolio API) *and* the export to portfolio, where the formats are the same, but the above problems are solved, then I think that is preferable to forcing the data module export to go through the Portfolio API which may or may not be on.
Usability: cross post: database export usability in moodle 2.0
by Penny Leach -
Number of replies: 4
In reply to Penny Leach
Re: Usability: cross post: database export usability in moodle 2.0
by Olli Savolainen -
Assuming you are talking about sth like this
http://qa.moodle.net/mod/data/export.php?d=1
I have no ready solution for you but perhaps the below will help.
A tab seems like a bad place for putting a wizard in - I imagine there is a risk that users confuse the location expressed by the active tab with their location within the wizard (=the step of the wizard they are currently in). This is worsened by the fact that Moodle wizards do not thend to express the step in which the user is in (see, for example, http://tracker.moodle.org/browse/MDL-20036 ). Once opportunity is to have just a button in the tab for launching the wizard (= popping out of the tabs), but waiting for the browser to load another page with very little additional information may be frustrating if you have to export often.
Your above suggestion for wizard steps may lead to a situation where user has chosen leap2a, and if that means flickr just is not in the list in the next step, the user has no information from which to deduce that it was a result of their selection. So keeping flickr in the list and having it disabled + explaining in parenthesis why it is disabled might alleviate this. (What I don't know is if any user has any reason to want to export leap2a to flickr so this may or may not be a problem:I am just saying that it's probably safer to keep the consequences of choices users have made as obvious as possible.)
I seem to have some gaps in my understanding of the problem, so bear with me if I make no sense at all.
Is there a reason in the context of the database module for someone to use the file download portfolio plugin if no portfolio API file export is available?
Seems like export as file (or to rephrase, save to your computer) and export to external service (send to external site) may be two quite separate scenarios and the selection should indeed first be made between these. If the usage of tabs in the database module made any sense in the first place, I might be tempted to add a separate tab for exporting to a service - but then again, the processes are so similar that separating them seems banal, too (How scientific!).
It does seem from what I understand now that the form is a bit too simple to be turned into a wizard. What comes to mind from what I understand from what you say is that a more dynamic view might work, one that would allow users to test the dependencies (Leap2a -> no flickr, etc.) live, and not have to go back and forth to find out what they can and can not do.
Of course, more dynamic means javascript and the requirement for graceful degradation, so more work.
If I was not escaping here from something else I should be doing, I would at this point fire up balsamiq and just play around with the elements and their relationships, wondering how to make the dependencies as obvious as possible. Perhaps I'll just challenge you to try doing that and offer to give you feedback for what you are thinking.
Please beep with a moodle.org message or something if you want me to do that or to otherwise return to this discussion - I currently can't regularly follow the forums.
http://qa.moodle.net/mod/data/export.php?d=1
I have no ready solution for you but perhaps the below will help.
A tab seems like a bad place for putting a wizard in - I imagine there is a risk that users confuse the location expressed by the active tab with their location within the wizard (=the step of the wizard they are currently in). This is worsened by the fact that Moodle wizards do not thend to express the step in which the user is in (see, for example, http://tracker.moodle.org/browse/MDL-20036 ). Once opportunity is to have just a button in the tab for launching the wizard (= popping out of the tabs), but waiting for the browser to load another page with very little additional information may be frustrating if you have to export often.
Your above suggestion for wizard steps may lead to a situation where user has chosen leap2a, and if that means flickr just is not in the list in the next step, the user has no information from which to deduce that it was a result of their selection. So keeping flickr in the list and having it disabled + explaining in parenthesis why it is disabled might alleviate this. (What I don't know is if any user has any reason to want to export leap2a to flickr so this may or may not be a problem:I am just saying that it's probably safer to keep the consequences of choices users have made as obvious as possible.)
I seem to have some gaps in my understanding of the problem, so bear with me if I make no sense at all.
Is there a reason in the context of the database module for someone to use the file download portfolio plugin if no portfolio API file export is available?
Seems like export as file (or to rephrase, save to your computer) and export to external service (send to external site) may be two quite separate scenarios and the selection should indeed first be made between these. If the usage of tabs in the database module made any sense in the first place, I might be tempted to add a separate tab for exporting to a service - but then again, the processes are so similar that separating them seems banal, too (How scientific!).
It does seem from what I understand now that the form is a bit too simple to be turned into a wizard. What comes to mind from what I understand from what you say is that a more dynamic view might work, one that would allow users to test the dependencies (Leap2a -> no flickr, etc.) live, and not have to go back and forth to find out what they can and can not do.
Of course, more dynamic means javascript and the requirement for graceful degradation, so more work.
If I was not escaping here from something else I should be doing, I would at this point fire up balsamiq and just play around with the elements and their relationships, wondering how to make the dependencies as obvious as possible. Perhaps I'll just challenge you to try doing that and offer to give you feedback for what you are thinking.
In reply to Olli Savolainen
Re: Usability: cross post: database export usability in moodle 2.0
by Penny Leach -
See, at the moment there isn't an issue because there is currently 100% crossover between exporting to a normal file (what was there in 1.9) and exporting to a portfolio - because the list of formats is the same.
The problem exists now because I'm adding Leap2A to the list of export formats.
I actually wonder if the better thing is to just leave the export tab completely alone, and just put an portfolio icon in the view list tab, similar to how there is one in the view single tab and use that to distinguish between export one entry and export all / export own (Depending on permissions)
The problem exists now because I'm adding Leap2A to the list of export formats.
I actually wonder if the better thing is to just leave the export tab completely alone, and just put an portfolio icon in the view list tab, similar to how there is one in the view single tab and use that to distinguish between export one entry and export all / export own (Depending on permissions)
In reply to Penny Leach
Re: Usability: cross post: database export usability in moodle 2.0
by Martin Dougiamas -
I'd love to consolidate ALL exports and downloads etc into one system (portfolio basically) just like the repository model did for imports but I think we're out of time for 2.0 so perhaps 2.1.
In the meantime, just little links on views that are supported by portfolio API would be fine (leave the export tab as is).
In the meantime, just little links on views that are supported by portfolio API would be fine (leave the export tab as is).
In reply to Martin Dougiamas
Re: Usability: cross post: database export usability in moodle 2.0
by Olli Savolainen -
Very good then.
If there is a chance someone looks for exporting to external service in the export tab (as it seems there is), I would have that shortcut link there, as well.
If there is a chance someone looks for exporting to external service in the export tab (as it seems there is), I would have that shortcut link there, as well.