3 Things you Wish you Knew

6
3170

There’s a great conversation occurring at Moodle.org discussing the three things a Moodler should know.  The entire discussion can be found here: http://moodle.org/mod/forum/discuss.php?d=140902.

The original question, posed by Stuart Lamour was

I’m spending the first week meeting front end users to get their perspectives, and having a look through the moodle code… I’d like to do a bit of crowd sourcing and ask everyone here to tell me 3 things they wish someone had told them in their first week using/developing moodle?

Here is the collective wisdom so far, parsed by info relevant to Students, Teachers and/or Administrators/Developers:

Students:

  • user name is a nick, not your whole name . . so don’t use spaces or complicated strings 😉
  • “OMG my picture is not centered, I only see my arm” If I know it could be better upload a square picture at top 300 X 300 px
  • If I know that everywhere I saw my name I could click on it to edit my profile . . .
  • Use the (?) buttons.  These have a wealth of information that is often untouched.
  • updated 1/8/10: use the ‘reply’ link next to the message you’re actually replying to. This allows threaded discussions to evolve. (or the course creator might instead consider setting up multiple ‘single question’ forums)
  • Having a personalised environment is important – such as choosing different theme colour schemes and using My Moodle (see below for welcome message).
  • On the courses, make everything clear – avoid links to folders. Use indenting and colour in the topic title.
  • Set up an ‘Ask the teacher’ forum in each course.

Teachers:

  • I wish it were more obvious that to have a space on your front page to give information/add an image (rather than have a long list of courses) you have to go into front page settings and tick add a topic section
  • I wish I had known earlier on that where possible it’s better to add a resource as a web-page than laboriously to upload a word doc – saves time, avoids program compatibility issues and students prefer the “one click and you’re there” aspect as opposed to opening/saving/waiting to load etc
  • I wish I had started organising my course files in folders from the start rather than just uploading any old resource directly – you end up with a really messy course file area a few months later
  • you don’t have to upload each resource one at a time; you can upload a zipped folder and unzip within Moodle
  • online text assignments and advanced uploading of files assignments are very useful for those who wish to replicate their offline practice of making comments directly onto students’ work
  • that there is a box to the top right of a topic section “show only this topic” and people don’t realise they need to click on the other box to get back to displaying all the topics on the page (this is likewise important for students)
  • when presenting Moodle to your [students] I find that nothing helps more than running [them] through one or two short videos on how to use Moodle.
  • I got scared when went to Assign roles and saw all site users.  Nobody told me: don’t be panic!! not all of them are enrolled in my course
  • Why nobody told me that there are a place where I can learn and share at moodle.org called ‘using moodle‘ ?
  • Finally I discovered in a tutorial that I should create questions through administrator block and then build questionnaires
  • Make a “quick links” block…add an html block and create a named link to each section using the anchor names (#section-1) instead of the default “sections” block which only shows the section number. VERY useful for long Moodle courses – scroll of death.
  • Show teachers how to zip their current file directory (where all their current files are nicely in folders and organized) and upload it to Moodle so you don’t have to upload one at a time and you can keep the structure.
  • You cannot break Moodle (repeat after me, “I cannot break Moodle”).  I say this to try to put them at ease, so they’ll click around…
  • updated 1/8/10: Great questions lead to great online discussions
  • organise file and folder structure and naming conventions – saves tears later on
  • Moodle forums can solve almost anything
  • Have no fear and if in doubt, do not be afraid to ask.
  • Use all of the good guides available – http://docs.moodle.org/en/Using_Moodle_book, UsingMoodle and the question mark icon.
  • Plan your courses before you create them, work out what resources will be there, what teachers are on the course and who can update what, what groups if any your require and what format it should be – weekly, topics etc.
  • Set up a ‘Don’t Panic’ course for staff to contain all of the useful resources and guides that you find and create.
  • Start with the basics and repeat as much as possible. You may use the techniques day in and day out, but staff you do not, forget easily.
  • Cover the concept of Groups, Groupings and Group Enrolment as soon as possible – http://www.youtube.com/watch?v=aIxP00gtEpU
  • Sell Moodle from the start with the following clips – http://www.youtube.com/watch?v=QdP4_7xXXVw, http://www.youtube.com/watch?v=XjLukDNtf3k, http://www.youtube.com/watch?v=d8RuxnXeBos and http://www.youtube.com/watch?v=WvCIv5KCbeE

Administrators/Developers:

  • Moodle has lots of capability that is hard to find sometimes due to unusual ways of navigating and invoking features. I would wish for a room full of monkeys that type and click away and then make a note of all approaches that produce a useful result.
  • Finding some particular data in the SQL database can be an adventure.
  • There is almost always someone [online or at Moodle.org] willing to answer a question you ask.
  • There are a lot of 3rd party Modules and Plugins developed by Moodle community already (see http://moodle.org/mod/data/view.php?id=6009), and WeBWork, TurnItIn Moodle integration, etc.
  • There is a free Moodle Developer Course that you could sign up: http://dev.moodle.org/
  • If you are running a large Moodle site (or have some really large courses, like 1300+ students in one course), you might want to pay special attention to some performance, scalability, and usability issues (especially in the quiz, mdl_log table, and gradebook areas).
  • The only way to really get the front end user’s perspective is to be one yourself.
  • If a user has a problem, the easiest way to see what they mean is to log in as them (“Login As” button on the user’s profile).
  • Cron jobs and import scripts can save you a hell of a lot of work (see flatfile enrolments, /admin/uploaduser.php etc.)
  • Moodle managed to miss the curse of MVC architecture. So, the URL in the address line shows you (mostly) exactly which bit of code is being executed and where to find it.
  • Learn ‘git’ version control
  • If you want to write an add-on of some sort, you can do a surprising amount with blocks and the coding is relatively easy to understand.
  • After originally setting up the test environment for Moodle I started working on developing the theme. I wish I had known that there where a variety of download-able themes at http://moodle.org/mod/data/view.php?id=6552 where I could find one that suited more of my needs than the standard themes, minimising the need for customization.
  • I wish I had looked into/read more about the back end database system/software that manages and houses the data within the Moodle application. This is because I have encountered several issues where I have had to go into and query the database, and have been unsure of what to do.
  • If you know where to look (and people here are always willing to point you in the right direction) that there are many helpful video tutorials all over the web which really help if you get stuck (As I am a firm believer that a picture speaks a thousand words).
  • I felt a little lost looking forward allow embed (security -> sites policies-> allow embed) so simple
  • I didn’t know how to use ‘admin bookmarks’ block (it is awesome)
  • Finally I found how to change font size for Blog Tags Block (blocks–> blog-tags–>block_blog_tags.php).
  • Installing some PHP extensions and settings early is required for some of Moodle’s functions (e.g. GD, PCRE….) and will save you the trouble of re-compiling PHP later.
  • Understanding Moodle’s roles and permissions system is very important, a bit confusing at first, but later proves as very powerful in managing your Moodle site and users.
  • It is good practice to provide and encourage teachers and course creators to use a standard “Template” and conventions for a course structure and content – e.g. how to design Topic 0, which things should folllow which, font styles, sizes and colors, etc. Moodle’s flexibility + people’s desire to be creative can lead to a cacophony colors, design and course structures…
  • visit another ‘like’ institution. This can be enlightening, like others that have posted here – someone, somewhere is 6 months ahead of you, another 12 months ahead and enviously, someone is 5 years ahead. Learn from others mistakes, rather than your own.
  • Be thorough in your design/setup, take your time, get it right, test it in micro before going macro.
  • Don’t let the name “block” restrict you to displaying things in a literal block on the page. The blocks API allows you to easily create entire subsystems which can do some very powerful stuff. Look at the MRBS and ILP blocks for examples of this.
  • Add the “book” and “questionnaire” modules from the start (we added them later on and many did not get trained/are aware of it)
  • sometimes, there’s a global setting hidden away (site wide unenrollment of inactive users after X days) that can really frustrate you.  Explore the administration tools available.
  • updated 1/8/10: there’s no right or wrong way to use Moodle; it’s there to do what you need it to do. Some swear by the inbuilt activities like the ‘Book’ and choose to upload all of their resources to each course folder. Personally I prefer to link to multimedia assets that reside on a separate server.
  • Bring makers and users together to make sure everyone is on the same page (you can never have too much feedback).
  • Gareth Barnard also posted an additional 10 tips for administrators (including custom code to welcome users depending on the day).  This link will bring you directly to his post: http://moodle.org/mod/forum/discuss.php?d=140902#p616277

There’s a ton of great information accumulating there, so go contribute: http://moodle.org/mod/forum/discuss.php?d=140902

On a personal note, I’d like to acknowledge the countless times I’ve used Moodle.org to find an answer to an elusive question/issue or to find more training and examples of a specific Moodle activity, resource or block.  It’s the definitive resource for all Moodle-ness.

  • Thanks for compiling these!

  • Pingback: Updated – 3 Things you Wish you Knew | Moodle Monthly()

  • Brian Swarthout

    This is a great list. Especially thinking about file structure before uploading resources. If you move resources after they have been linked it creates big problems.

  • Pingback: October 2010 « S.A. E-Learning Newsletter()

  • lax-goalie

    “Moodle managed to miss the curse of MVC architecture”

    Huh? In my judgement, that’s one of Moodle’s greatest weakness – it’s damn near impossible to build a Moodle site that doesn’t look like a, well, “Moodle site”.

    Yeah, there are themes, but basically they all look alike, albeit with different headers and color schemes. From a UI and UX perspective, there’s not a lot to recommend it.

    The biggest problem is that, for Moodle, data and presentation are intimately intertwined, which is exactly the problem that MVC solves.

    The Moodle back end is pretty nice, and my company considers it every now and again. (And in fact, I have a local install on my workstation to do SCORM validation.) But until we can get better control of what a user sees, it’s doubtful we’ll ever use it for anything serious…

  • “Moodle managed to miss the curse of MVC architecture. So, the URL in the address line shows you (mostly) exactly which bit of code is being executed and where to find it.”

    If you learn MVC e.g CodeIgniter, ASP.NET, and others, you will see that the URL actually tells you exactly where to find the code.

    In ASP.NET the url Issues/Edit tells you to go to the controller folder called “Issues” and look for the function “Edit”

    Things like Drupal that use clean URLs is not the same as MVC.