How do our users use moodle?<\/em><\/span><\/h4>\nWe began by conducting a series of one to one sessions with some of our expert users – those tutors, lecturers and researchers who regularly create fantastic e-learning experiences for their students. In these sessions we visited theses expert users in their own\u00a0environment, observing their daily use of moodle. \u00a0We also asked them how they would like it to work, and to show us other websites or applications they commonly use to do similar tasks.<\/p>\n
How do other ‘products’ do file upload & \u00a0management?<\/em><\/span><\/h4>\nWe looked at some other web based CMS (content management systems), commonly used websites (facebook, twitter, google docs, dropbox etc) and applications our tutors use (word, powerpoint etc).<\/p>\n
Initial findings<\/span><\/h2>\nOur first finding was to do with the different ways users can add a file in moodle. There were two different methods – both with very\u00a0different\u00a0workflows – our expert users\u00a0commonly\u00a0used to add files.<\/p>\n
1. Add a resource – Link to a File or Website<\/span><\/h4>\n![\"\"](\"http:\/\/blogs.sussex.ac.uk\/elearningteam\/files\/2010\/08\/Screen-shot-2011-03-15-at-16.25.39.png\" "\\"linktoawebsite\\"")
<\/span><\/p>\nWhen editing is on users can select from the dropdown menu an option to upload a file called “Link to a File or Website”. From a developer perspective this seems perfectly legitimate – a link in html does not care if its to an asset on the same site, or another website.<\/p>\n
From a language and user aim perspective our users had a great deal of difficulty with this concept and the\u00a0labelling.<\/p>\n
Users\u00a0suggested\u00a0“Upload a file” would be a more appropriate label. It should be noted that these expert users use moodle every day, but\u00a0unfortunately\u00a0still find it a\u00a0struggle\u00a0to remember how to do some of the common, repeated activities. This would indicate a more\u00a0intuitive\u00a0process – based on the language and tasks the user needs to carry out – would be more\u00a0appropriate\u00a0for our interface we give to users.<\/p>\n
Adding a resource form<\/strong><\/p>\n![\"\"](\"http:\/\/blogs.sussex.ac.uk\/elearningteam\/files\/2010\/08\/Screen-shot-2011-03-15-at-16.28.48-600x529.png\" "\\"adding")
<\/strong><\/p>\nThe standard form for adding a file resource in moodle brought up some interesting usability\u00a0challenges\u00a0for our tutors.<\/p>\n
Window & other form elements<\/em><\/p>\nThe form itself has a large number of options for opening the resource in a frame, a pop-up window, showing navigation, menu bars, location bars, the size of the window etc..<\/p>\n
Many of our users were unaware of the implications of these setting for the end user, the usability and\u00a0accessibility\u00a0problems associated with setting these options\u00a0incorrectly, what the size in pixles of there resource – or indeed a page is, what a status bar is etc…<\/p>\n
As developers we know most of these options can be ignored. We know that best practice tells us never to use frames and to open files such as pdfs and word documents with the appropriate\u00a0application\u00a0and not with a browser. \u00a0We know that images, movies and audio can be displayed in most browsers. This is a complex set of web content rules we learn, but we found most of our users had no conception of these rules or (understandably) any wish to\u00a0learn them.<\/p>\n
For users with limited time, trying to complete a\u00a0relatively\u00a0simple task\u00a0which\u00a0other systems\u00a0allow\u00a0them to easily,\u00a0presenting this hi-level of\u00a0control and complexity was unwelcome.\u00a0This generally applied to all standard moodle elements of form.<\/p>\n
Generally we found our users just wanted to add a file, and for it to work.<\/p>\n
We looked at some other web based CMS (content management systems), commonly used websites (facebook, twitter, google docs, dropbox etc) and applications our tutors use (word, powerpoint etc).<\/p>\n
Initial findings<\/span><\/h2>\nOur first finding was to do with the different ways users can add a file in moodle. There were two different methods – both with very\u00a0different\u00a0workflows – our expert users\u00a0commonly\u00a0used to add files.<\/p>\n
1. Add a resource – Link to a File or Website<\/span><\/h4>\n<\/span><\/p>\nWhen editing is on users can select from the dropdown menu an option to upload a file called “Link to a File or Website”. From a developer perspective this seems perfectly legitimate – a link in html does not care if its to an asset on the same site, or another website.<\/p>\n
From a language and user aim perspective our users had a great deal of difficulty with this concept and the\u00a0labelling.<\/p>\n
Users\u00a0suggested\u00a0“Upload a file” would be a more appropriate label. It should be noted that these expert users use moodle every day, but\u00a0unfortunately\u00a0still find it a\u00a0struggle\u00a0to remember how to do some of the common, repeated activities. This would indicate a more\u00a0intuitive\u00a0process – based on the language and tasks the user needs to carry out – would be more\u00a0appropriate\u00a0for our interface we give to users.<\/p>\n
Adding a resource form<\/strong><\/p>\n<\/strong><\/p>\nThe standard form for adding a file resource in moodle brought up some interesting usability\u00a0challenges\u00a0for our tutors.<\/p>\n
Window & other form elements<\/em><\/p>\nThe form itself has a large number of options for opening the resource in a frame, a pop-up window, showing navigation, menu bars, location bars, the size of the window etc..<\/p>\n
Many of our users were unaware of the implications of these setting for the end user, the usability and\u00a0accessibility\u00a0problems associated with setting these options\u00a0incorrectly, what the size in pixles of there resource – or indeed a page is, what a status bar is etc…<\/p>\n
As developers we know most of these options can be ignored. We know that best practice tells us never to use frames and to open files such as pdfs and word documents with the appropriate\u00a0application\u00a0and not with a browser. \u00a0We know that images, movies and audio can be displayed in most browsers. This is a complex set of web content rules we learn, but we found most of our users had no conception of these rules or (understandably) any wish to\u00a0learn them.<\/p>\n
For users with limited time, trying to complete a\u00a0relatively\u00a0simple task\u00a0which\u00a0other systems\u00a0allow\u00a0them to easily,\u00a0presenting this hi-level of\u00a0control and complexity was unwelcome.\u00a0This generally applied to all standard moodle elements of form.<\/p>\n
Generally we found our users just wanted to add a file, and for it to work.<\/p>\n
When editing is on users can select from the dropdown menu an option to upload a file called “Link to a File or Website”. From a developer perspective this seems perfectly legitimate – a link in html does not care if its to an asset on the same site, or another website.<\/p>\n From a language and user aim perspective our users had a great deal of difficulty with this concept and the\u00a0labelling.<\/p>\n Users\u00a0suggested\u00a0“Upload a file” would be a more appropriate label. It should be noted that these expert users use moodle every day, but\u00a0unfortunately\u00a0still find it a\u00a0struggle\u00a0to remember how to do some of the common, repeated activities. This would indicate a more\u00a0intuitive\u00a0process – based on the language and tasks the user needs to carry out – would be more\u00a0appropriate\u00a0for our interface we give to users.<\/p>\n Adding a resource form<\/strong><\/p>\n The standard form for adding a file resource in moodle brought up some interesting usability\u00a0challenges\u00a0for our tutors.<\/p>\n Window & other form elements<\/em><\/p>\n The form itself has a large number of options for opening the resource in a frame, a pop-up window, showing navigation, menu bars, location bars, the size of the window etc..<\/p>\n Many of our users were unaware of the implications of these setting for the end user, the usability and\u00a0accessibility\u00a0problems associated with setting these options\u00a0incorrectly, what the size in pixles of there resource – or indeed a page is, what a status bar is etc…<\/p>\n As developers we know most of these options can be ignored. We know that best practice tells us never to use frames and to open files such as pdfs and word documents with the appropriate\u00a0application\u00a0and not with a browser. \u00a0We know that images, movies and audio can be displayed in most browsers. This is a complex set of web content rules we learn, but we found most of our users had no conception of these rules or (understandably) any wish to\u00a0learn them.<\/p>\n For users with limited time, trying to complete a\u00a0relatively\u00a0simple task\u00a0which\u00a0other systems\u00a0allow\u00a0them to easily,\u00a0presenting this hi-level of\u00a0control and complexity was unwelcome.\u00a0This generally applied to all standard moodle elements of form.<\/p>\n Generally we found our users just wanted to add a file, and for it to work.<\/p>\n<\/span><\/p>\n<\/strong><\/p>\n
![\"\"](\"http:\/\/blogs.sussex.ac.uk\/elearningteam\/files\/2010\/08\/Screen-shot-2011-03-16-at-09.43.13.png\" "\\"choose")
<\/a><\/p>\n