The solutions are not always obvious, and I'd really like to see more of the community engaging with these issues and helping to define the best way forward.
It would be nice to come to some consensus for at least some of these by 2.0, and so with this aim, let's make next week "Navigation, Layout, Blocks, Themes and Other Stuff Week!" (NLBTAOSW - catchy isn't it?)
Your homework starts here on this evolving overview:
http://docs.moodle.org/en/Development:Navigation_2.0
Your assignment next week is to engage in the discussions and vote on proposals as they come up!
To resume, I wanted to see a new segmentation of the whole Moodle Platform. I know there is Moodle Net already, but this may be far beyond the possibilities of a little or medium sized school.
So this is the hierarchy of our University of Applied Sciences:
- University of Economics
- Section 1
- General Courses for all
- Courses of Specialization 1
- Courses of Semester 1
- Courses of Semester 2
- ...
- Courses of Specialization 2
- Courses of Semester 1
- Courses of Semester 2
- ...
- General Courses for all
- Section 2
- General Courses for all
- Courses of Specialization 1
- Courses of Semester 1
- Courses of Semester 2
- ...
- Courses of Specialization 2
- ...
- General Courses for all
- Section 3
- ...
- Section 1
- University of Psychology
- Section 1
- ...
- ...
- Section 2
- ...
- Section 1
- University of Business Informatioin Systems
- University of Social Work
- University of Life Sciences
- ...
As we have a lot of courses, siteNavigation has an option to only display the categories as folders. If you set the option to display all courses inside the folders, rendering of more than 500 courses becomes very slow. Probably there is better code than the original library used there (and it was intended to display only myCourses anyway as is done in the according block). I planned also to rewrite the code so that it can be used in the center pane of the Front Page like the built in course list.
I added also URL-rewriting in apache so that the universities have own direct links to their category, like this https://moodle.fhnw.ch/hsw (university of economics) which is rewritten/redirected to https://moodle.fhnw.ch/course/category.php?id=10
With some more tricks, it is even possible, that every university could have an own Home Page as entry point to the eLearning system. And if I am not mistaken, there is also a trick to use the Moodle category pages as such Home Pages.
So far everything seems quite well as for the segmentation of big sites and the global navigation between categories, subcategories and courses.
Now there is another point I mentioned in my original post: the administrator of the server would really like to have things separated one step further, maybe something like a virtual Moodle Server for every university. This would mean that the database and the Moodle-Admins, the themes and all the rest with its individual settings would run as an own instance, and if there would happen to be a problem, it would probably concern only one university and not any other. Still the php-code base of Moodle should be only one to reduce maintenance. I know there are some solutions to achieve this or to install more than one code base on one or different servers and to keep them up to date separately. And I know also that putting all those instances on one same physical server will not really separate things if apache or mySQL or the OS or a disk happens to fail. There are other solutions to achieve redundancy at that lower level.
From that point of view MNet is probably the best way to go and I have to study the according docs first. I guess that there is one code base to maintain on every different physical server and that there could be some solutions to automate this, e.g. by rsync on linux boxes. The advantage being of course, that database, apache, php and os are really separated and that, this way, you can also solve load balancing issues on a real large scale school.
So, if there is also an overall consistent navigation between the different MNet Servers, and all those servers can be configured to use the same LDAP Authorization servers for the same user base and the function get_my_remotecourses() can gather all the courses spread over different MNet servers of the users and the user has to login only once to navigate from one course on one MNet server to another course located on another MNet server, there is really nothing left I would wish to be implemented.
I think I am quite lucky for the moment. If content can be placed into any category page so that it can be used as Home Page for any University, or even Section I listed at the top, with individual content, I would really be happy, Rosario
Over the last days I marked in two screenshots some problems in pages for example assignment. Vertical lines are very meaningful for orientation and understanding. They give a first orientation what is the same context and what is an other area or context, what is on top level and what is a level lower. The centered layout (in assignment) don't give this orientation for anyone.
Every week I'm discussing with teacher that Moodle is to complicate to understand it. And this is a relevant critic. I know, no teacher says we don't need functionalities, but what we really need is a more consistent use of functions and orientation.

That is a design decision that was taken years ago, and is obviously not something that individual developers should change on individual pages. Instead, we should have HTML with consistent use of class names, so different themes can choose different alignments.
I personally dislike centred layouts, but it's not my call.
I guess the initial reasons for the default centered layouts was to make Moodle work and look similar on the widest variety of screens (from very small to very large).
I agree and it's obvious that some default layouts can be improved - there are quite a few places that strongly irk me too, but it's not at all obvious what the better layouts are...
The decision what's a better design for the learning process can't be answered generally. Its a local decision in a special context.
But exactly this is the best argument to segregate consequent code, design and content. And design has different aspects here: colors, fonts size, boarders on one hand (all the CSS stuff) and on the other side the arrangement of elements on a page. In different contexts it should be possible to arrange elements in quite an other way as Moodle defines actually. A simple argument is that it should be similar like an other application an organiszation is using. Doing this it is much simpler to work in the Moodle processes because a user thinks he can use it in the same way like other programms.
The growing success of Moodle has a consequence. More and more users are not from the so called net generation or developers. They are ot familar with web interfaces like other ones. If you or I look on a web page we mostly see with one view where the relevant elements and settings are and what we have to do. We see a structure, because we know a lot about patterns that are mostly used in web applications.
Our experience to differentiate is an exclusive knowledge. More and more Moodle users don't have the experience and intuitive knowledge. As experts we have mostly a tacit knowledge and can't transfer this to others. In lots of situation user don't have a contact to an expert when using Moodle.
So we have to create interfaces within Moodle that are respecting the different needs, experiences and contexts of users in Moodle. The problem is that we can't define all the situations in the discussion here or at an other place. We need options to define and design it with a special client or user in his context.
An other aspect of the same issue: At several places we had discussions about simple Moodle systems for starters.
We can configure a moodle system in different ways: preconfiguration of course settings and blocks in new courses, hiding some course administration functions for different teacher roles. What we can't do is an in detail definition of functions and activities that are available for a special role. Its an often discussed question: can we create a teacher role for teachers starting with Moodle that only have access to some learning activities.
Petr told me that this would create a lot of workload for the database. May be it is possible to create different templates/views for different roles.
I don't know if templates are a good way to create the options for a flexible presentations of Moodle pages in the hand of admins or designers. Tim and Urs discussed this some weeks ago.
I don't really have knowledge about coding, but I can see that there are lots of lines of code outside the themes that define how a moodle page looks like.
Yesterday I worked a little bit at the assignment module and changed some 'center' definitions to 'left'. I found CSS definitions in assignment/style.php and several definitions of placements 'center, left, right, float' (with differences between 1.9. and 2.0 code). Why are they located there?
If we are consequent in a first step, we should put all the CSS definitions into the standard theme. But I expect that this won't be enough to create the flexibility for the different needs.
Lets try to find a strategy to define visual outputs consequent in themes and perhaps in templates. So it will be possible to define some standard visual use cases for often used scenarios and the flexibility for individual designs for special needs without coding in the core.
Hopefully that this will create a good base for the cooperation of teachers/learners, core code developers and designers. We need all these professios together, not in one person, but in discussion and teamwork.
I disgree that users are confused. That's too general. Students don't have a problem at all. These are kids who don't know of a world without the internet. They grew up in MySpace, Facebook and Twitter. It's the teachers and older students that find it hard.
CSS can be used to position objects on a page, not just for colours and fonts. That is the whole crux of this discussion; how to structure the code so the CSS of the theme can choose the layout.
I agree that the CSS code definitions are often the problem. But it seems to me that deleting the CSS definitions in code and adding to theme is not enough.
Then there is a strong need for modern user interface techniques like:
"Empty states that tell you what to do" -> (5) http://www.smashingmagazine.com/2009/01/12/10-useful-web-application-interface-techniques/
"Display help messages that attract the eye" -> (7) http://www.smashingmagazine.com/2009/01/19/12-useful-techniques-for-good-user-interface-design-in-web-applications/
It would also be nice to see "design decisions" like 37signals do... not just: "Ok, we fiddle it this way by now... and refine it later".. NO! Plan, and describe the decision process, pls.
happy reading/planing,
Sven
See http://moodle.org/mod/forum/discuss.php?d=108993 for the extensive discussion on that topic and Development:Theme_engines_for_Moodle%3F for the result.
Cheers,
Frank
I read in the forums though, that not everything is controllable via CSS and themes yet, correct? I'm thinking of formatting of all text, forms, buttons, placement of meta data, etc. There's just some quirky stuff that we'd love to cleanup.
Thx for all you do for the Moodle community!
Chris : )
Than are dreamt of in the forums."
Please use CSS FAQ and Themes FAQ as a starting point for further details.
And feel free to ask specific questions (but preferably in a separate thread...).
Cheers,
Frank
Also, if you have any other constructive suggestions, please share them. There have been some interesting recent threads in the Themes forum. For example http://moodle.org/mod/forum/discuss.php?d=126009.
atw
I think Moodle needs a set of style guidelines that are as clear and rigid as those governing coding. The iPhone is a great example of how clear and consistent styling can make the difference between excellence and mediocrity.
The last attempt never took off: http://docs.moodle.org/en/Development:Interface_guidelines
The very best document I have seen on user interface guidelines comes from the Apple Human Interface Guidelines. I think there is a difference between user interface design and coding best practices.
http://tinyurl.com/cygyps
Here are the principles:
• Metaphors
• Reflect the User’s Mental Model
• Explicit and Implied Actions
• Direct Manipulation
• User Control
• Feedback and Communication
• Consistency
• WYSIWYG (What You See Is What You Get)
• Forgiveness
• Perceived Stability
• Aesthetic Integrity
• Modelessness
• Managing Complexity in Your Software
I think the second point is probably one of the most important elements. Later in their document the go one to summarize it.
"Briefly, you should discover your users' workflow, expectations, and real-world experiences and mirror them in your application's terminology, window layout, menu organization and hierarchy, and toolbar contents."
One of the challenges I have seen in open source software it that it is almost too generous in its thinking. It wishes so much to do everything the users could want to do that it can loose the ability to help focus on the user's way of completing tasks.
I know this is very vague still, but I will try to make some more concrete suggestions soon from a visual design and visual usability perspective. I must say that a lot of the things you showed as planned in the Moodle 2.0 really take a leap forward in user interface design.
In new editing page for quiz its similar. I know its in an early level of development, but it didn't give orientation. Colours and font sizes are mixed. White fonts on dark background are a problem related to accessibility.
One detail: Update this quiz is there two times as text link and as button. People don't know if this are different or same functions.
Page Order and paging
This page has different types of functions. There are buttons. links, underlined links, menus, click boxes, fill in fields, linked symbols.
Every week I'm discussing with teacher that Moodle is to complicate to understand it. And this is a relevant critic. I know, no teacher says we don't need functionalities, but what we really need is a more consistent use of functions and orientation.

Surprising, but I, too have in fact been thinking about hiding extra controls of a question until an user gives them focus (moving questions controls showing onmouseover, grade save button showing when the text field is given focus). Now I found they have it presented as a pattern, too: this is point 9 at 10 Useful Techniques To Improve Your User Interface Designs (thanks to Sven, above for the link to this site) However, the problem here is that it will introduce Yet Another interaction style currently in use nowhere else in Moodle.
It is also way cool that you seem to have found Balsamiq!
Thanks for this mock-up editing screen. I rather like it, as I lament the incredibly vertically long editing screen in current moodle. However, what it does not show is what would happen if the "use wysiwyg editor" box was ticked? Would we then have each and every text box displayed with the HTML editor?
I've always been wondering why Quiz did not adopt the (to me) sensible approach of the Lesson edit screen where you can individually select to have the HTML editor only where you want/need it?
Joseph
I agree that the question editing forms need work. I just have not had time, and will not have time in the foreseeable future, so if anyone wants to tackle it themselves, that would be brilliant.
@Tim: Didn't thought about accessibility when creating the screen. A class will be fine. If this is not possible its not a problem to add clear labels without breaking the idea.
@Joseph: Lesson editing pages have similar problems. I never understood why the fields for Buttons are so big and why it is such a long page.
Which fields use the editor is a definition? Rembering teachers behaviours some only need it for the question text, some also for the answers or for feedback. Most often they use it in this way:
- question text: formating, linking to documents/including pictures, adding 'no link'
- answer text: text formating, including pics
- feedback: adding course links
Do you think its helpfull to add three options to activate editor? One for question text, one for all answers, one for all feedbacks.
However, using font sizes and colors to direct user attention is, in my point of view, something often required to provide guidance, as per Bastien et Scapin (1993). That is, the main features are highlighted in order to give users clues about what the main workflow of the application is.
"White fonts on dark background are a problem related to accessibility. "
Please tell me more about this, it does not seem at all obvious to me? Again, this solution was related to guidance, as in usability testing the window was left unnoticed by users.
I do agree that the UI uses quite a few custom UI elements and consistency across Moodle should be worked on.
Something like this Wordpress-Mockup: http://konstruktors.com/examples/wordpress-dashboard/01/
S.
but you have to be careful so its still usable without JavaScript...
I think in terms of alignment there could be much improved as mentioned by Ralf...
Should not the onus be on the assistive technology people to take Javascript into account rather than to deny its use from those users who do not need assistive technology? What is Moodle's policy in this matter?
Joseph
Moodle's policy is clear. Accessibility is important. Everything should work with JavaScript off. (Of course, some things will work in a way that is better for most people if JavaScript is on.)
And of course, assisstive technology makers should be working to make their tools better, just like we work to make Moodle better. The responsibility is shared.
Jakob Nielsen has an interesting article about Mega Drop-Down Navigation Menus Work Well in "Alertbox".
Seams to be worth to consider to use "Mega Drop-Down Navifgation Menus" for Moodle.
Oli what differences do you see between web sites and Moodle when looking at the pages Moodle users work with?
And is the Yahoo web catalog or Amazon a web site or a web app? Or is an ecommerce site a web app or a web site?
For me Moodle is an application using web pages for the interface. So all web site interface aspects are valid for Moodle.
Moodle doesn't work with typical web app interface concepts like "Stay on the Page" as a chapter in Designing Web Interfaces, 1st Edition is called, which do more clearly distinguish web app interfaces from web site pages.
May be finding a consensus for the question if the Moodle interface needs to be a web app interface or can work with web site pages is one good starting point for the Navigation 2.0 discussion.
As I see it Moodle has a web page based interface and I think that is ok.
Even if mega drop downs are a way of introducing a lot of links usably and saving screen real estate, it seems to me it is useful to engage the user to the task at hand by not having all the navigation but only to the navigation relevant to the task at hand. When the task at hand is editing a quiz, the user does not need direct links everywhere in the course or in Moodle. When the task at hand is navigating, as it can be on the pages higher in Moodle hierarchy (moodle/course front page, ...), a mega drop down might work.
Just because we have the means of adding loads of links everywhere in a usable manner per se, it does not mean it is good for the user experience in any context - there is no excuse for not getting to know the real user needs, and seeing what links actually are needed for a given task. Of course you need to know user needs for a successful design, even in a situation where a mega drop down is decided beneficial.
That is: when a page is clearly more of a web application than a web page, it is good to reflect this fact in the UI as well. Moodle currently does this pretty well, and typically only includes a breadcrumb and some basic links on such pages. Even for fairly web page style functionality such as Lesson it is still beneficial to have some immersion.
Of course we could draw some benefit from just organizing principal functionality into the menus, but the main benefit from Mega drop downs comes from being able to present more content, in a findable manner. The content in Moodle is in the context of courses. The added findability of a Mega drop down comes from analyzing the semantics of the content and user (teacher/student) needs.
- Navigation choices structured through layout, typography, and (sometimes) icons
- Chunk options into related sets, such as those you discover after doing a card sorting study of users' mental model of the features.
- Keep a medium level of granularity. Don't offer huge groups with numerous options that require extensive time to scan. Conversely, don't make the individual groups so small that the drop-down has an overabundance of groups that users have to spend time understanding.
- Use concise, yet descriptive labels for each group. Remember the standard rules for writing for the Web: enhance scannability by starting with the most information-carrying word and avoid made-up terms.
- To keep words short and direct, the base form of verbs ("shop") is usually better than gerunds ("shopping").
- Differentiate labels. Action Envelope's "Ways to Shop" and "Shops," for example, don't work well together.
- Order the groups. You can do this using an inherent order among the features (as for a workflow) or according to importance, putting the most important and/or frequently used group on top (in a vertical design) or to the left (in a horizontal layout, assuming a left-to-right language like English).
- Show each choice only once. Duplicating options makes users wonder whether the two occurrences are the same or different. Also, redundancy makes the entire interface bigger and more cumbersome.
Of course, with or without Mega drop downs, it is still a big issue, how to make sure course content is organized sensibly and usably by teachers.
I found your link *very useful* - and to my eye Mega Drop-Down Navigation Menus are not at all bulky. In the first example site http://www.foodnetwork.com/ is using "list of lists" instead of normal lists which still allows you to use normal lists if you don't like "bulky" lists. For example element Healty Eating makes the vertical alignment simply with ul tags and if you want to use normal lists all you need to do is use one ul tag instead of two or three...
<li class="nav-w"><a rel="gh-t1s2" class="healthy-eating" href="/healthy-eating/index.html">Healthy Eating</a>
<div class="drop">
<div class="hd"><!-- FOR CAPS --></div>
<div class="bd">
<div class="content clrfix">
<div class="inside clrfix">
<h3>Inside Healthy Eating<span>Close</span></h3>
<ul>
<li><a rel="gh-t1s2-1" href="/monthly-meal-makeover-lasagna/package/index.html">Meal Makeovers</a></li>
<li><a rel="gh-t1s2-2" href="http://blog.healthyeats.com/">Healthy Eats Blog</a></li>
<li><a rel="gh-t1s2-3" href="/ellie-kriegers-healthy-recipes/package/index.html">Ellie's Healthy Recipes</a></li>
<li><a rel="gh-t1s2-4" href="/topics/low-fat/index.html">Low Fat</a></li>
<li><a rel="gh-t1s2-5" href="/conscious-cooking-healthy-and-fast/package/index.html">Healthy & Fast</a></li>
</ul>
<ul>
<li><a rel="gh-t1s2-6" href="/heart-healthy-foods/package/index.html">Heart Healthy Foods</a></li>
<li><a rel="gh-t1s2-7" href="/ellie-kriegers-healthy-recipes/package/index.html">Ellie Krieger</a></li>
<li><a rel="gh-t1s2-8" href="/winter-ideas-from-eatingwell/package/index.html">Winter Meal Ideas</a></li>
<li><a rel="gh-t1s2-9" href="/topics/low-cholesterol/index.html">Low Cholesterol</a></li>
<li><a rel="gh-t1s2-10" href="/whole-grains/package/index.html">Whole Grains</a></li>
</ul>
<ul class="cta">
<li class="cta-title">More in:</li>
<li><a rel="gh-t1s2-11" href="/healthy-eating/index.html">Healthy Eating</a></li>
<li class="last"><a rel="gh-t1s2-12" href="/recipes-and-cooking/index.html">Recipes & Cooking</a></li>
</ul>
</div>
<div class="shows clrfix">
<h3>Shows</h3>
<ul>
<li><a rel="gh-t1s2-13" href="/healthy-appetite-with-ellie-krieger/index.html">Healthy Appetite with Ellie Krieger</a></li>
<li class="more"><a rel="gh-t1s2-14" href="/shows/index.html">More shows</a></li>
</ul>
</div>
<div class="products">
<h3>Products</h3>
<ul>
<li><a rel="gh-t1s2-15" target="_blank" href="http://www.foodnetworkstore.com/c-0+91%201314-Bar-Blenders.aspx?hid%3d91?ccaid=FNFNDDHE1">Blenders</a></li>
<li><a rel="gh-t1s2-16" target="_blank" href="http://www.foodnetworkstore.com/c-0+91%20399-Griddles-Grills.aspx?hid%3d91&ccaid=FNFNDDHE2">Indoor Grills</a></li>
</ul>
<ul>
<li><a rel="gh-t1s2-17" target="_blank" href="http://www.foodnetworkstore.com/c-0+89%20574-Steamer-Inserts.aspx?hid%3d89&ccaid=FNFNDDHE3">Steamer Inserts</a></li>
<li><a rel="gh-t1s2-18" target="_blank" href="http://www.foodnetworkstore.com/c-0+91%201219-Food-Processors.aspx?hid%3d91&ccaid=FNFNDDHE4">Food Processors</a></li>
</ul>
</div>
</div>
</div>
<div class="ft"><!-- FOR CAPS --></div>
</div>
</li>
-------------------
Very smart use of simple css

Some sites seem to use large tabs (divs) particularly on front pages to give a lot of data available with a few clicks - no scrolling or multiple links after links.
For example http://welcome.hp.com/country/us/en/welcome.html#Explore is nice but sadly all links go elsewhere from the front page that looks more like a site map.
Microsoft is using interesting approach in their Products tab http://www.microsoft.com/windows/ - it might be useful to get some extra info of the link in a layer/div/popup or near link (if given) but not everywhere... some kind of selectable user info option - if user has selected to show help/info/learning path/etc details they could be visible (on hover), otherwise hidden or not loaded at all (Some kind of "Guide me" button...)

Drop-Down menus seam to be widely discussed in the moment: Designing Drop-Down Menus: Examples and Best Practices by Smashing Magazine.
It's always good to have a broad and well considered base of information when we are going to work on proposals for Navigation 2.0 for Moodle.
A List Apart published an interesting article yesterday. In The Elegance of Imperfection David Sherwin writes about "Wabi-sabi and making websites".
He writes: "Leonard Koren, in his book Wabi-Sabi for Artists, Designers, Poets & Philosophers, describes the following material qualities of wabi-sabi: asymmetry, asperity, simplicity, modesty, intimacy, and the suggestion of a natural process."
I recommend to closely look at and understand those qualities when discussing Navigation 2.0 for Moodle.
It is interesting how other OpenSource projects work on the user experience topic. Drupal works with a professional design team. One of them, Mark Boulton, blogs about the Audience Matrix: Our thoughts on the Drupal 7 audience.
Not to mention that Drupal's goals are not in all aspects different from those of Moodle.
Thank you!
Defining User Experience
Luke Wroblewski gives a short overview about aspects of and professions possibly involved in creating "User Experience"
Information architecture
+ Interaction design
+ Visual design
= User experience
There is a lot to consider when talking about "Navigation 2.0".
I think it would be helpfull to transfer this to the Moodle environment. We have different levels of usage and design:
- Moodle Navigation and interface design by themes (including options for variation)
- Didactical design made by teachers (differs by topic, target group and teachers personality)
- Content creation (wording, structuring, visualisation, tasks, etc.)
- Didactical design made by teachers (differs by topic, target group and teachers personality)
I told you that I would try to put my thoughts into writing on this topic. Please have a look at this thread and see if there is anything useful for you there.
http://moodle.org/mod/forum/discuss.php?d=122021
kind regards,
Ian Grivois
How do you see this working with themes? I imagine that there will be one parent theme and then a child theme for a course, but does that mean that there will be a single theme for every course?
How do you see that working with a large institution? We have 700 courses, sometimes with multiple instances, instructors and groups. That sounds like a pretty long list on the theme selector page.
From a selfish perspective as the person who does themes. I'm feeling a little boggled at the thought that all of our instructors will be wanting to customize their courses at this level through the theme. I don't know who will be making the decisions about themes with all this flexibility.
Ian
If you need per-course CSS, then you should not do that with separate themes. I can think of two options.
- Every page in Moodle has a bunch of class attributes added to the body tag. One of which is course-123. So you can write style rules that apply to a particular course, and then add all those rules to a single theme. This way does not involve changing Moodle core code, but does involve constant changes to that one theme.
- You could make a customisation to your Moodle that stores some custom CSS for each course, and provides an easy way for people to edit it. That involves changing Moodle core code, but is easier to work with in the long run.
Although I am not planning to switch over from Moodle (!) I have been just been playing with a relatively new LMS at:
http://www.haikuls.com
I was at a Moodle conference in Wales recently where Martin did a video-link presentation about Moodle 2.0 where he mentioned having drag and drop of blocks to anywhere you want them on a page. This new LMS by haiku has a very neat drag and drop approach also with some very easy to use page layout tools (specifying number of columns on a per page basis etc.)
In terms of features, Moodle has more, but the power or the haiku approach is in the simplicity of its use. If we had this in our college, staff training would need to be very minimal.
I'm sure the Moodle 2.0 dev team are fully aware of haiku.... but if not it may be worth checking out and setting up a FREE account to play with it?
Mark
We really like the built-in skins approach and the page-arrangement flexibility.
Best of all, Haiku is MUCH easier for our faculty to learn and use.
We tried Moodle for four years and I certainly promoted the heck out of it, but in the end, simplicity and ease of use won out.
Plus, Haiku just makes it much easier to set up pages, navigation bars (where oh where are they in Moodle? I got so tired of the endless scrolling on one page!) and the ease with which Haiku integrates Web 2.0 streaming and iFrame content.
I know many of these things can be accomplished in Moodle--but it just takes too much effort!
David Huston
Haiku beats moodle in this case.
Its this : we concentrate more on functionalities than ease of usablity and friendliness for an end user ( I would say we underuse the YUI's capablities).
I took this into mind and wrote a list of things which has to be changed or improvised to meet the easy usablity factor and have implemented few small things which matter to end users a lot,Need more time to get it to perfection and will contribute them.
I also know that moodle is now concentrating on the improvisation of usablity factor ,it would be awesome if we could get that kind of usablity and friendliness on our product.
at the end of the day when clients use it, it takes lot of training time associated with product hand over.
I've found at our university that most people handle it quite well with little/no training. The biggest problems I've had are with bugs (which get fixed), people are absolutely unwilling to even try (seriously, they won't even log in), and one person who used to use Blackboard and is now unable to accept anything different. She thinks that the ability to bookmark forum posts is absolutely critical, I've told her how to use browser bookmarks, but apparently that's not good enough and Moodle is obviously from the stone age.
I'm not saying things are perfect, far from it. But in my experience "Reports of Moodle's difficulty have been greatly exaggerated".
Have to confess, I wasn't expecting anyone to say that... but it is interesting to know!
I have been using Moodle for 5 years now and still find it time consuming, and as a result have only ever got as far as using assignments, some quizzes and for posting resources. All with embedded video & audio etc so I am very happy with it!.... but getting a whole college to do much more than simply post resources is still a massive challenge.
I was therefore VERY interested earlier this month, in Martin's mentioning a real improvement to simplify usability and the 2.0 'drag & drop' (Flash based?) interface for putting blocks anywhere. Is there a demo/beta of this yet?
Mark
http://www.haiku-os.org/
What is this - a haiku website but running in Moodle? Looks like it to me!?
That's really interesting. Actually the site is done in Drupal (see http://groups.drupal.org/drupal-showcase-by-type). And that is a different Haiku, the operating system, not the LMS (http://www.haikuls.com), but that one's also in Drupal.
Frank
I know this is a bit late, but this is a question about Navigation in 2.0. Does anyone have an comments?
Here is what seems to happen:
- I load a video (say an FLV) Upload file > leave it as Automatic.
- Click on the link
- Flowplayer opens up, seems a nice size, with scrubber etc.
- Then when finished playing there are two (clickable) options in the breadcrumbs.
- Course name (takes you back to the top of the page and you need to scroll down to get back to the section with the video)
- The link to the video. All it does is reload the video.
The middle link of the two is not clickable.
Is this a feature or a bug? I think it needs to be clickable. Otherwise, there is no way to get back to the section you came from.
-Derek
I might be very late too, but I work as System Administrator more than I work as Teacher in Moodle-Courses.
But why the sections/weeks/topics still continue to appear in a long vertical list making it very long to scroll through course pages even in Moodle 2.x?
And the new navigation in Moodle 2.x allows for faster access as it lists all the topics/weeks in a vertical list. But again, this list can grow long, so that you have to scroll down vertically anyway.
Of course the teachers or the students can show/hide one desired topic/week but would it not be better to have ONE HTML-Page per Topic/Week or have a toggle to show the whole list vertically and to have another display mode like the pages of a book? Something like the dockable blocks in Moodle 2.x ?
List-view (as it is actually in Moodle 1.9 and 2.x course pages and in the navigation block of 2.x):
Topic/Week 1
-----------
Topic/Week 2
-----------
etc.
Book/Page view:
T1/W1
T2/W2
T3/W3
etc. all on the left or right edge of the course page. This would allow for a better navigation and shorter course pages. Of course a solution should be found to only show the three or four Topics/Weeks around the Topic/Week the user is looking at, so as not to produce a vertical long long page again. Someting like the Buttons/Links in long lists like <first>, 2, 3, 4,...98, 99, <last> but maybe in a vertical order like this:
<first>
T3/W3
T4/W4
T5/W5
<last>
And if you click on Topic/Week 5 you get a new slider:
<first>
T4/W4
T5/W5
T6/W6
<last>
Rosario