Helping visual designers affect Moodle.

Helping visual designers affect Moodle.

by Ian G -
Number of replies: 46
Hi Everyone,

I hope that this doesn't sound too negative. I basically would like to give a short critique of Moodle and offer some possible solutions. I recognize that Moodle.org doesn't have an visual interface designer working for them. I recognize that the priority has been to get programming and functionality in place with mind for a future evolution to improve how they look and work. As well, I recognize that Moodle is rather a gift to humanity right now, allowing many institutions that could not afford WebCT vista to offer online courses. However, visual design needs to be considered early as part of the workflow in order to properly be implemented and to build a basic design "intelligence" into the software interface.

I hope that they are getting tired of hearing people complain about how Moodle looks and are ready for it to evolve into a more professionally presented package. Good visual design will ennoble all of the good open source programming work that has gone into Moodle. In many ways, I wish I was more of a programmer so that I could offer better back-end solutions.

It would be great if we were able to affect Moodle and make it as attractive and usable as a site like this. http://www.bbc.co.uk/radio4/ Hey, when you compare a lot of sites to Moodle it really must be obvious that it should look better.

Visual design tends to be like a lens that people look through. They don't often don't notice the lens but just see the object of their gaze in a sharper way. I find I usually have to take off the glasses and explain how they are working for people so that we can all speak the same visual language.

PART 1

I think one of the big challenges with doing visual design for Moodle is that designers are rather hamstung in their ability to do their job. Yes everything can be affected from the back-end of Moodle but is better to have trained programmers with a system view coding the PHP so that it is properly done and will not create problems in the future. Besides, it's rather a waste of work to go in an opposite direction than upstream Moodle development. It all needs to be redone with an upgrade and a whole new set of conflicts creep in.

I'll give a brief critique of Moodle and visual design so that you know what we'd like to do. Four basic principles of visual design are contrast, repetition, alignment, and proximity. The big thing that results from using these principles is flow. They eye and the mind flow through the information pleasantly and effortlessly. Just like the Ying-yang logo, white space needs to be considered as an active element and shape as opposed to a space that is empty. Whitespace is a powerful tool for applying these four principles.

1. Contrast is used to set up hierarchies for importance and helping direct the eye around the page. Right now Moodle has very poor contrast, it's mostly text links with icons that are all the same size. What that means is people have to keep reading and rereading to know what to do. There are ways that designers can help. Different images, buttons, and ways of presenting interactivity can use people's visual memory to quickly communicate a function (and make a more visually interesting and engaging page).

2. Repetition is basically consistency. Like elements and functions are grouped and presented in a consistent way which reinforces a positive user experience. Tabs are a type of repetition in websites. It also related to thematic elements which get repeated to create a consistent environment. Curved corners on boxes are a type of repetition.

3. Alignment is a way of grouping like-information together and creating flow. It does relate to readability. One simple example is that people in the West are used to reading from left to right. Hence aligning text to the left is easier to read because it's easier for the eye to find the start of each line. Moodle has lots of alignment problems once you get off the front pages of courses and with modules.

4. Proximity is a really important one that is often forgotten. Basically, a mark on a blank page that is off center will have a magnetism for the side that it is closest to. Two marks on a page have a visual magnetism for each other and that visual magnetism increases as the marks move closer to each other. This is the principle use between the fingers of God and Adam in Michelangelo's sistine ceiling. The little space between the fingers creates electricity. How does this relate to Moodle? There are lots of proximity problems, especially with the displays of tables. There are many points of tension that inappropriately draw the eye. Proximity can be used well to help the eye flow through the page or it can keep fighting against it. Alfresco uses proximity well. It's a basic design intelligence that should be built into the base Moodle system. Proper use of whitespace and considered proportions is a key to using proximity well.

PART 2

Most of the web designers I know have a very good knowledge of HTML and CSS but usually have a passable knowledge of PHP, Javascript, XML, XSLT...but programmers are really trained differently than visual designers and it's unusual to have a lot of masters of both worlds.

Enable designers to do their work with javascript, CSS, and HTML directly in the browser rather than having to go through the server side. This will allow greater flexibility, iterative design, and separate visual designers from the programmer's workflow. Separate presentation from content, right? wink I'm not talking about removing what's capable now with the theme folder, this would be an additional customization element.

1. Just how in Moodle 2.0 you are planning to enable people to add images from Flickr or Google docs through a web interface, allow people to link to CSS and Javascript through their web browser. If you're moving towards Moodle and Alfresco integration the CSS and Javascript can reside in Alfresco and be imported into the Moodle file system as needed.

2. Allow designers to wrap their own tags around the content of blocks. We can add div tags that will allow us to add background images and transform links into buttons. Does a link to a Moodle book always have to be a text link with a little icon to the left? Why could it not be a small image that shows what the content of the book will be? Give me a big open block and I can design my own columns for course content.

3. CSS can be made specific so that it does not affect the HTML of Moodle itself, for example:

(css)

#mystuff h1 {font-size: 1.8em}

(html)

<div id="mystuff">

<h1>A title that's mystuff size</h1>

</div>



But, is there a better way to do this?

Thanks for considering this,
Ian
Average of ratings: Useful (3)
In reply to Ian G

Re: Helping visual designers affect Moodle.

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
Hi Ian!

Thanks so much for rolling up your sleeves and getting stuck in! It's really very much appreciated.

Yes, I think most people would love to see designers empowered to make Moodle life more beautiful. That's a big part of the push towards a more consistently implemented page/blocks/theme framework in the Navigation 2.0 work.

Moodle is in a unique position compared to other web sites because it allows so much customisation at different levels. Unlike any particular web site (eg Radio 4) which have a design based around a constant data structure we need to provide a system where ordinary teachers without any design experience can completely create and customise their own web site. A large part of the design is left to the teachers.

Let me just respond to your points (my intention is not to sound defensive but to get further feedback from you!):

PART 1:

We really need some examples from you of these. The examples may be obvious to you but we need screenshots with arrows. smile My guess is that a lot of the smaller issues (like whitespace) are easily solved with a bit of CSS in the current themes.

PART 2:

Have you seen the Chameleon theme that Urs developed? It lets you edit the CSS directly in the web browser (using a GUI!) and then save it to the server. It's pretty amazing but I don't think it's widely used because it's quite complicated. Surely it's better to use custom tools for the job (like CSS editors and Firebug on a local copy of Moodle)?

There is also a "custom" theme developed as part of the GSOC (still a bit rough code-wise) which was designed to a) allow users to customise their own very basic colors etc using menus and b) allow admins to easily add raw CSS. Yes, it could easily be modified to use the new Repository support I suppose ..

Possibly this is just a workflow issue about where/how to edit the CSS, the restrictions you may be feeling could be due to institution access and policy rather than Moodle itself.

About using id and div tags: over the past few years we've added hundreds of these hooks all over the place already (are you using Moodle 1.9?). Each page has its own unique id, each block of info is surrounded by one or more divs ... I think it's generally possible to get your CSS pretty much anywhere ... specific examples would help here.

The example of "could it [a link to a book module] be a small image that shows what the content of the book will be?" ... are you proposing this be done purely through CSS? Wouldn't that be a huge amount of manual work for teachers?

Thanks for engaging, please keep doing so!
In reply to Martin Dougiamas

Re: Helping visual designers affect Moodle.

by Ian G -
Hi Martin,

Thank-you for your thoughtful response. You've given me some things that I need to chew on for a while, but here are my immediate responses.

...we need to provide a system where ordinary teachers without any design experience can completely create and customise their own web site.

Your implying in this statement that me, as a professional visual designer, is not an intended audience for Moodle, that it's more a self publishing tool. Firstly, nothing I've suggested is meant to take away capabilities for self-publishing, but rather to enable regions where users can have more direct control of the html through the browser. This would likely move towards enabling repositories of code that can be applied through the interface. If you want to remove visual designers from the work-flow then you have to move toward having more visual design built into your software, a "design intelligence". A basic example of this is all the design intelligence and user experience built into an iphone.

PART 1: [Moodle design issues] We really need some examples from you of these.

What I hear you saying is you would like me to help fix the problem rather than just complaining. big grin That is not a quick thing, but I will try to be more involved with the community.

Have a look at this page and see what you think. I know what you mean about "hooks" in the code. There is a fairly easy to implement fix for how tabular data is displayed. This work is very conservative, but it's a little step towards the issues I identified.

http://moodle.org/mod/forum/discuss.php?d=121947

On the navigation 2.0 discussion topic, Ralf was getting into part of the alignment situation. I think there is even better solutions, but the problem is clearly identified. I see quite a few pages that look like that in modules.

http://moodle.org/mod/forum/discuss.php?d=116936

Have you seen the Chameleon theme that Urs developed?

Yes, that is pretty impressive work. I looked at it when it came out. I should look at it more closely again. It's not Safari friendly and when I was recently on the test site I saw the user example screen captures posted and felt rather discouraged.

Even though I mentioned background images, it's not really, literally, about that adding background-images and changing colours. Ever since the days of using tables and spacer images for laout designers have been using "tromp l'oeil" techniques to get away from making everything look like its in a grid. We use drop shadows, curves, gradient, open and closed shapes, and beveled 3D shading, all to break out of the flat plane of the screen and grid.

Because Safari doesn't work with the Moodle WYSWIG editor and allows me to add link tags, script tags, and embed tags, we have been able to move Moodle books quite a bit towards the BCC site. There's a wonderful script called thickbox which we've been using for adding links to large images, flash slideshows, and video into the flow of text. Copyright makes it hard to share these things but we're trying to move towards some way of getting it out there. I'll try to come back with some screen captures.

Possibly this is just a workflow issue about where/how to edit the CSS, the restrictions you may be feeling could be due to institution access and policy rather than Moodle itself.

Yes, you may be right about that. It's hard to develop and institutional workflow that includes visual design unless it's identified as a priority.

The example of "could it [a link to a book module] be a small image that shows what the content of the book will be?" ... are you proposing this be done purely through CSS? Wouldn't that be a huge amount of manual work for teachers?

Yes and no. I would like to be able to affect those links, but essentially what I am talking about is allowing a Moodle course to have an image interface if wanted that is just like the moodle.org homepage. In a Moodle course, how do you actually add an image with a rollover to the homepage of a course? Does a course homepage have to look like the old way the old "sitemap" pages look where it's a really long list of links?

I know that there are classes and ids everywhere. There was also some hard-coded css. I got burned a few years back with customizing at too detailed a level. I made one change and it affected other things in Moodle unexpectedly. I'm not an expert user of Moodle. You put 500 minds of professors into it and they are going to use Moodle in a way that I didn't anticipate. It's hard to test with out having content. I'm afraid of rearranging Moodle DNA for fear of it breaking with upgrades and holding back my institution with problems that need to be solved. I suspect things have gotten better, but I'm gun shy!

Warm regards,
Ian
In reply to Ian G

Re: Helping visual designers affect Moodle.

by Ian G -
Ok, I have attached some screens of our courses using the book Module and showing what can be done when you allow linking to CSS, javascript, and embed tags into the book. We're storing the source files in the Moodle file section. The MAIS typography was based on the typography of Alistapart and it's only a mock-up site. The HERM course is my own work and as students are seeing it now.

Ian

-edit-

My file was too large to upload to the forum. You can see it here in Slideshare.

http://www.slideshare.net/grivois/screen-captures-of-au-moodle-courses

P.S. I don't think I was very clear in my comment about background images above. I meant that I'd like to use background images not just as a picture behind a block but as an interface element that helps to break-down the boxiness with the techniques described (like they do on the BBC site).
In reply to Ian G

Re: Helping visual designers affect Moodle.

by Ian G -
Correction, Chameleon does work with Safari. I just have to read more closely mixed I'm still not sure I really get the concept.
In reply to Martin Dougiamas

Re: Helping visual designers affect Moodle.

by Ian G -
re: ...provide a system where ordinary teachers without any design experience can completely create and customise their own web site

Hi Again,

I would suggest something like Wordpress does for their blog entry interface. When a user arrives at the edit block interface, you could have the simple interface on the front that has all that a teacher needs. There can be a tab for "advanced" users who can enter more indepth CSS, etc...which would be attached to that block's ID and follow it around without affecting anything else.

Or, the advanced tab could be associate with a role and seen only by people who would use it.

Ian
In reply to Ian G

Re: Helping visual designers affect Moodle.

by Patrick Malley -
Hello Ian,

I like this idea a lot - having a hidden text box that allows custom CSS to be entered at the block or module level - but would be concerned about adding yet another text box to what is already a rather full user interface.

Great idea if it accompanied an interface cleanup/organization using tabs or something similar.
In reply to Patrick Malley

Re: Helping visual designers affect Moodle.

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I was wondering about adding this as part of the Moodle 2.0 work, or at least making it possible as a plugin that people who need can install.

The simplest (from a code point of view) way to do this would be as a text filter (that does not actually change any text, but does get to inject extra CSS into the header). However, that would put the place in the UI you need to go to enter the extra CSS in a rather un-intuitive palce However, it would only be a few tens of lines of code.
In reply to Tim Hunt

Re: Helping visual designers affect Moodle.

by Ian G -
Hi Tim,

Here are some ideas.

There is a very nice javascript called Thickbox which degrades nicely if javascript is turned-off. It has a lovely way of isolating an interface from its surroundings. The link is below and look at the red section for examples. We use this a lot for putting images into Moodle courses which enlarge when clicked. I've seen this used very nicely on websites to call-up a login screen.

http://jquery.com/demo/thickbox/

As well, the Yahoo User Interface library has a lovely script for using tabs on a page without having to load a new URL. It's called TabView.

http://developer.yahoo.com/yui/tabview/

Here's an example page.
http://developer.yahoo.com/yui/examples/tabview/frommarkup.html

Below is an example from how Wordpress does it. It looks like they use similar scripts to above. Follow the arrow cursor to see the actions. With the final screen capture below, that tab could be an "advanced" editing screen.

regards,
Ian
Attachment adding_interface.jpg
In reply to Ian G

Re: Helping visual designers affect Moodle.

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Have you tried adding a new question to a quiz in Moodle 2.0 dev?
In reply to Tim Hunt

Re: Helping visual designers affect Moodle.

by Ian G -
Hi, I'm on a Mac that doesn't have intel processors. So, there is no Moodle 2.0 download for me to try out yet, but I will look for it when I do eventually get to see it.
In reply to Tim Hunt

Re: Helping visual designers affect Moodle.

by Ian G -
Since Safari doesn't work with the WYSWIG editor, which removes link tags, I've been able to link to CSS files uploaded to the Moodle file folder in a course. It appears directly in the html code, written like this <link href="http://www.url.com/custom.css" rel="stylesheet" type="text/css" />

The thing that I like about this approach is that I can design iteratively. I can have one window open with the css from the file section and another with the page that it affects. I can make a change, refresh the other window and see the results. It lets me fiddle until I find a good fit.

I'm fearful of what's going to happen if the WYSIWIG ever starts working with Safari! I'm hopeful that our developers can turn-off the filter that removes <embed>, <object>, <script>, and <link> tags for the "course creator" role we have. I know that it's a security risk to leave open to all users.

It would be nice to have this browser-based ability to affect blocks!! Then I could do so much more like make links look like buttons or have an image with a roll-over! Ooh, the possibilities make me quiver....Eventually we could get a collection of scripts stored in Alfresco and could browse and link (import) them into Moodle. Oooh!
In reply to Ian G

Re: Helping visual designers affect Moodle.

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
What I don't understand is why you are developing themes on your live server.

Surely you should be doing development on your own machine, and your private copy of Moodle. (Just install one of the Moodle for Mac OS packages.) Then the CSS files are on your hard disc, where they are easy to edit with whatever editor you like, and any screw-ups you make while working do not break things for other people. You can always transfer particular courses form your live system using backup and restore, if you want to work with particular example courses.

Then, once everything is finished and tested, you can deploy it to the live server.
In reply to Tim Hunt

Re: Helping visual designers affect Moodle.

by Ian G -
Hi Tim, that is a very insightful question.

The short answer is that form needs to evolve from the content (which I would not have on my desk), we work collaboratively as a team, and the courses that we work on are not open for students (they are either new and or in revision). Here's the long answer if you are interested.

When I say developing iteratively, that's not just a closed loop with myself. The course professor and other team members need to be able to see things and have input in how they are working. It's really handy to be on the phone (we're distributed) and have a professor be able to refresh their browser and see a change directly. Content also evolves as a course get developed. For example, video takes a long time to produce so it comes in later in the cycle and needs to be incorporated into the interface.

Our professors submit the course in Word (currently), editors work with them using track changes. Learning designers work with professors when they are writing the course, and once it's in our department, to develop the assessment, interactive, and communal aspects of the course and tools (and there are aspects of teacher training in this role). Once the course has been edited we have people who convert it into xhml with agreed upon class and id tags and put it into books (that all depends on what type of content and how it best needs to be organized).

Once the course comes into the department I read it and form a list of ideas for imagery and visual design approaches which I send to the professor. They will add to, edit, or revise my ideas. I go and start researching image sources which eventually get processed for the course. In the mean time, our typesetters will have a couple units formatted and in Moodle and I'll go in and start doing the typography CSS and interface elements for the course. Once it's done it's easily applied to different parts of the course.

We also have a copyright person who works throughout the whole development process securing permissions mostly for readings, but sometimes for images. The editor again needs to go through the Moodle site to check all the non-course related instructions, etc..., and to see if any errors have crept into the course. Then we sign-off and it's ready for our students and tutors.

We're a distance education institute, so Moodle is our virtual classroom and campus. There are parts of the course that are left open and changeable, and parts that are carefully edited and produced. We really would like to keep allowing professionals to be able to work on the development of courses.
In reply to Ian G

Re: Helping visual designers affect Moodle.

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Ah right, so your job is really that of designing specific content, not authoring a generic theme that could be used for any course. (At the OU, the equivalent role is Media Developer - Graphic Design.) So I now you explain, I do understand what your role is.

You are right that that sort of role is not well catered for by Moodle at the moment, but it is probably only a few places like Athabasca and the OU who can afford that level of expert design for individual courses. (And the OU has recently tended towards imposing consistent design on all content, so our graphic designers mostly don't have that much freedom.) Actually, some commercial training providers may want that sort of course-specific design.
In reply to Tim Hunt

Re: Helping visual designers affect Moodle.

by Joseph Rézeau -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers Picture of Translators

Tim > ...it is probably only a few places like Athabasca and the OU who can afford that level of expert design for individual courses...

Your are right, Tim. When I was reading Ian's lengthy description of online course design in his university I was wondering whether he was living on a totally different planet from the one French public universities are located on. We certainlly don't have that sort of resources nor that sort of money.wink

Joseph

In reply to Joseph Rézeau

Re: Helping visual designers affect Moodle.

by Ian G -
We're a unique institution, but it's because we're not campus based. We've always been distance education, with a print publishing model before online. (We used to own Heidelberg presses!)

I'm just trying to get more access for visual designers who understand HTML and CSS but are not trained programmers and can not take apart the complexities of a web-based application through the back-end.

Unfortunately, this is an audience that Moodle doesn't serve very well either. Please don't dismiss me because you feel I'm too specialized! I do themes as best I can too.

Joseph, thanks for reading it all...
In reply to Ian G

Re: Helping visual designers affect Moodle.

by Thomas Hanley -

While I can understand Joseph's point that not all educational establishments have access to the resources that a distance learning institution such as Athabasca has I still think Moodle should be flexible enough to allow those institutions who do have staff members with these skills to be able to use them.

I agree with Ian that as far as possible (I know the Moodle development team also has limited resources!) it would be nice for front-end designers (XHTML, CSS) to be able to improve the visual appearance and the usability of content and interactions within Moodle.

For me the reason I think it is important to make the front-end code as accessible as possible is primarily for reasons of usability, the secondary reason is aesthetics (although sometimes of course the two can be linked). Sometimes Moodle creates a confusing user-experience (for example when the pseudo breacrumb navigation had a link to a resources page that the user had never been to). I know this issue has now been resolved. I guess the point I am making is that as far as possible control over content and navigation mechanisms should be achievable by altering the XHTML and CSS rather than trying to hack PHP. With the more functional modules within Moodle I think that the interactions need to be designed and user-tested and then developed. People who have been doing rapid prototyping recently using Balsamiq are I believe onto a good thing as it makes sense to design the interactions and think them through before implementing.

Average of ratings: Useful (1)
In reply to Joseph Rézeau

Re: Helping visual designers affect Moodle.

by Ian G -
I think there is really a cultural difference in how programmers and visual designers work. None of my comments are meant to say any way is better or less than the other. Your work is quite magical to me. What I would like to see is a way to get visual design values incorporated into the development process.

I like Moodle and feel it is quite intuitive. But, I think there are some ugly and not so easy to use aspects to it. I chock it up to avoiding making visual design decisions in the development.

The developers put lots of hooks into it thinking it will be fixed later by someone who has visual design skills and some ninja programming skills. Well, the flexibility is nice, but if it was designed right in the beginning it would likely not need to be "themed" later!!

It's twice as hard because the the designer has to analyse the original interface goal and work through the mental model of the programmers.
In reply to Ian G

Re: Helping visual designers affect Moodle.

by Patrick Malley -
I really have to applaud you for your efforts here and I hope that the Moodle programmers really listen to your ideas because good design is the next logical step for Moodle to take. I've spent the past two years designing themes around Moodle.

I'm very excited about the work that Tim Hunt is currently doing to give theme designers more control over the layout for Moodle 2.0. I hope that the trend is that the core programmers will continue to listen to people like you who can explain their design vision quite well.
In reply to Ian G

Re: Helping visual designers affect Moodle.

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Other possible explanations of the ugly parts of Moodle is just that they were done a long time ago when the available technology and web design norms were less developed; or that they were done in a rush.

Hopefully we are getting better when it comes to new developments. If you have not read Development:Overview recently, it is worth rereading from time to time to remind yourself how things are supposed to work. Also, Martin is actively re-writing the coding guidelines at the moment, and they now include usability and such-like issues.

One part of the development process I would like to highlight is the "Seek and absorb community feedback" step. Even if the person writing or implementing the spec is not a visual design expert, they should be inviting reviews, so there should be a point in the process where you can step in to help.

Also note that one of this summer's Google Summer of Code projects, is Olli Savolainen working on fixing some of the ugliest parts of Moodle, and at the same time producing some guidelines to help all developers do things better in the future. See Development:Usability/Improve Moodle User Experience Consistency. Again, you might like to follow what Olli is doing, and suggest particular pieces of ugliness for him to think about.

So, that point is, suff is happening. And please continue to give us your perspective on things, but at the same time, we can make Moodle better one step at a time.


In reply to Martin Dougiamas

Re: Helping visual designers affect Moodle.

by Ian G -
Hi Martin,

Here is a pretty simple example of a proximity issue. wink
Attachment proximity.gif
In reply to Ian G

Re: Helping visual designers affect Moodle.

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
What do you mean by 'proximity issue'?
In reply to Tim Hunt

Re: Helping visual designers affect Moodle.

by Ian G -
Hi Tim,

See Part 1, point #4, in my original post. Martin asked for some examples. Basically, that first sentence is stuck to the ceiling. It must have been quite a party!!

Sorry for being so verbose with my postings!

Ian
In reply to Ian G

Re: Helping visual designers affect Moodle.

by Mauno Korpelainen -

Ian - you can't blame code of moodle in that case. This example shows just that some possible css hooks are not used in (standard) theme css. If you look at the source

<div id="page">

    <!-- END OF HEADER -->
    <div id="content"><div id="redirect"><div id="message"><p>Your post was successfully added.</p><p>You have 30 mins to

edit it if you want to make any changes.</p><p>Person X will NOT receive copies of 'test' by email.</p></div><div

id="continue">( <a href="discuss.php?d=1#p2">Continue</a> )</div></div><script type="text/javascript">
//<![CDATA[

  function redirect() {
      document.location.replace('discuss.php?d=1#p2');
  }
  setTimeout("redirect()", 7000);
//]]>
</script>
</div><div id="footer"><p class="helplink"></p></div></div>


You can fully control divs with id redirect and message in themes and give css for those divs in file styles_layout.css and

#redirect {
  text-align: center;
}


#redirect #message {

}


#redirect #continue {

}

But it's a good example about tiny things in layout of theme that can stick out for designers like you.

In reply to Mauno Korpelainen

Re: Helping visual designers affect Moodle.

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Tiny thinks like that that could be fixed by adding some simple CSS to the standard theme, please file a bug/improvement in the tracker with your suggested code.
In reply to Tim Hunt

Re: Helping visual designers affect Moodle.

by Mauno Korpelainen -

I don't see how this kind of issues could be called bugs - as I mentioned to Ian the current code makes it possible to use any css for those two divs - and this is only a design issue that can be solved in each theme separately.

For example

#redirect {
height:250px;
width:250px;
position:absolute;
top:100px;
left:230px;
text-align: center;
background:url("http://moodle.org/theme/moodle2/pix/news.gif") no-repeat center;
}

#redirect #message {
width:200px;
text-align: left;
position:absolute;
top:40px;
left:200px;
}

#redirect #continue {
height:150px;
width:200px;
background:url("http://moodle.org/theme/moodle2/pix/community.gif") no-repeat bottom;
position:absolute;
top:180px;
left:200px;
}

gives absolute position for those divs with some background images but it is not reasonable to use this kind of tags in standard theme. I am pleased with the current code - hooks are there and they can be used. If those hooks were not there I might file a bug... wink

Attachment tim.gif
In reply to Mauno Korpelainen

Re: Helping visual designers affect Moodle.

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I think they are bugs.

Moodle's codebase is a combination of .php, .js, .html, and .css.

And Moodle should work properly out of the box.

And I think everyone here agrees that visual design is important, and should be included in the definition of 'works properly'.

So, the standard theme should look and function well - if it doesn't that is a bug.

(And the same time, there needs to be the flexibility so that people can make their own themes.)
In reply to Tim Hunt

Re: Helping visual designers affect Moodle.

by Mauno Korpelainen -

It's good that You did say this. I have always concidered standard theme to be a sort of set of available css rules - almost like "empty standard model document" that could be used for designing more interesting themes and that should work on all environments, all browsers, all screen widths and heights, with or without javascripts or other scripts.

From the aspect of visual design standard theme has never really "looked good" and therefore standard theme itself is obviously the biggest bug ever in moodle - wink - no, I am joking. Finding the perfect balance between different aspects is impossible.

We have been using that bbc site as an example of good design combined to flexibility, usability etc but although most of the power of attraction comes from jquery etc the most amazing thing is that those pages are flexible also without javascripts. I turned javascript off from FF and clicked "Add more to this page" (BBC main site)... and yes it still worked. The charming feature is those user selectable and editable blocks, colors and different versions of themes for different needs. It looks like accessibility is not a part of main theme of BBC but you can select and change the actual files that make BBC site more accesible - with presets  http://www.bbc.co.uk/displayoptions/presets.shtml?url=www.bbc.co.uk/home/ - and user can reset the whole design and positions/visibility of blocks with one button: Reset homepage http://www.bbc.co.uk/home/ 

It looks easy but if I take my old example - http://demo.rockettheme.com/may09/index.php?tstyle=style1#

the structure is near to BBC site structure, some nice effects are used and basic design is ok - still something is missing... selectable blocks, colors etc. OK, they are there but available only for administrator of that site and theme.

I truly appreciate your valuable work with blocks, themes, navigation and all those combinations of settings, Tim. To my eye it is not a big issue if some message is at the ceiling of a box but it is certainly easier to see it from the middle of screen or box and therefore all this kinds of smallish issues are important...

The key is how to use "user profiles", different types of themes or cookies for customized settings for different users.

Keep up your good work, Tim!

Attachment bbc1.gif
In reply to Mauno Korpelainen

Re: Helping visual designers affect Moodle.

by Joseph Rézeau -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers Picture of Translators

Mauno "... standard theme itself is obviously the biggest bug ever in moodle..."wink

I doubt that many moodle sites stick to standard theme. It would be interesting to have a survey on moodle.org asking moodlers which of the "out-of-the-box themes" they use, whether they use a slightly modified moodle theme or use their own totally different personal theme.

What I think is needed in the Moodle standard distribution - besides standard theme and a couple of others - is a "default theme". This could be based on formal white or customs corners or the forthcoming "anomaly" theme (which might be shipped with Moodle 2.0?). Oh, and I'm sorry to say that the word "anomaly" sounds pretty negative and disparaging to my ears. I would certainly like to see it renamed in a more positive way.

Joseph

In reply to Joseph Rézeau

Re: Helping visual designers affect Moodle.

by Mauno Korpelainen -

Yes - I suppose most moodle sites have a slightly customized version of some of those available free themes or some commercial themes on their production sites.

We all want to change something in themes - logo, colors etc - so that it would look more like we think it should look - and finally nobody can create a perfect theme that all of us like.

Default theme could as well have some preset styles and some preset display options that can be selected by user and saved either to cookie or user profile. Administrator on the other hand could have direct access to basic settings of preset styles from (theme) administration panel and could change some basic settings of those selectable styles like colors, preset images (logos, buttons etc). And even non-professional designers could edit the available images, css or effects that administrators could offer to users. That's how many new theme packages work - they are not anymore one theme or several themes but sets of selectable styles and settings.

Standard theme could be a simple "theme selector" that just shows the presentation style that user (not administrator) selects - or  mobile style version http://www.bbc.co.uk/mobile/i/  or  accessible style version or ... and each style could use common css for printing the pages.

It just sounds VERY complex.

The list of cookies used in main bbc.co.uk is impressive - http://www.bbc.co.uk/privacy/cookies.shtml - but moodle has also user profiles so we could as well store some more information than just selected user theme to user/course/category profiles instead of 100 different cookies

And professional designers would still (most likely) want to use their creativity, custom styles and ideas.

In reply to Mauno Korpelainen

Re: Helping visual designers affect Moodle.

by Frank Ralf -
I think Moodle should be shipped with a simple, well documented, standard conform default theme which should be easily customizable. IMO a revised version of the Standard theme could serve that role.

For Drupal there's the ZEN theme (http://drupal.org/project/zen) which ships with two simple layouts and a starter kit to build your own (sub) theme. (http://drupal.org/project/zen).

Of course there's also a lot of discussion going on what in terms of theme should be provided by a core installation. (See "Project Plan for a new default Drupal 7 theme" http://groups.drupal.org/node/16200 .)

Cheers,
Frank




In reply to Joseph Rézeau

Re: Helping visual designers affect Moodle.

by Patrick Malley -
Joseph,

It gets tough naming themes after a while. smile

I'm certainly not stuck on the name "Anomaly." Can anyone suggest anything better?
In reply to Patrick Malley

Re: Helping visual designers affect Moodle.

by Frank Ralf -
What about "Anewmalley"? smile
Average of ratings: Useful (1)
In reply to Frank Ralf

Re: Helping visual designers affect Moodle.

by Patrick Malley -
That's clever, Frank. I can't put my finger on quite why, but I don't think it will work.
In reply to Tim Hunt

Re: Helping visual designers affect Moodle.

by Mauno Korpelainen -

If some tiny changes are needed it can be something as simple as

#redirect {
  text-align: center;
  margin-top:10%;
}

in standard theme styles_layout.css

... or

#redirect {
  text-align: center;
  margin-top:25%;
}

In reply to Mauno Korpelainen

Re: Helping visual designers affect Moodle.

by Ian G -
Mauno, thanks. I realize it's minor, but it's one of a lot of little things that add up to some piles of dirty laundry lying around the moodle house.

My point was only that there are things like that that should be fixed in the base moodle to make the base interface be more (visually) clean. Theme designers shouldn't have to first scrape things off the ceiling before moving in. big grin

Gaawd, if you saw my house you would realize the irony in what I'm writing.
In reply to Ian G

Re: Helping visual designers affect Moodle.

by Ian G -
Whoops, we cross-posted, Tim.

Ok
In reply to Martin Dougiamas

Re: Helping visual designers affect Moodle.

by Leo Thiessen -
@Martin, in response to "... need some examples of these" - let me make an attempt at this:

I have a situation where courses are growing very large due to duplication of the same resource in different formats. For example a presentation as an swf, then again as an flv, then mp3, etc. The problem is that the content is really 1 resource in multiple formats, but due to the repetition in a forced list format, it is starting to get difficult to find stuff for students. We have a little over 5000 enrollments and a lot of materials, so splitting things up more for clarity has limited value.

Attached is a screenshot showing the current state vs what we would like to see. How can I accomplish this? (I have yet to implement a solution.) If I were a designer, not a coder, how could I do it?

In looking for a simple solution, I would've tried css hack, (e.g. get nested UL's to show as icons only in line with parent UL, but the indented items are *not* nested UL's but rather spacer images. Hmm... I debated making a course format plugin that processed the html before spitting out to the browser... but that seems quite "hacky" to me and liable to break. So far I haven't found code to give me a list without html (e.g. compare wordpress xyz() functions vs the get_xyz() functions - one version for html, the other just to get data arrays or objects, note that xyz() would make use of get_xyz()).

I'm quite new to really digging into moodle code, but having had opportunity in the past 2 weeks to do so (on the mrcutejr repository plugin), my impression is it seems that html code is liberally dispersed throughout & tightly ingrained into the core code, without alternative means to obtaining the desired code (barring running a custom queries - I'd prefer to rely on built-in queries rather than creating my own, with all associated risk in doing so if one is not careful). If I'm incorrect here, let me know - thanks!!

Some ideas "off the cuff" for resolution (again, not trying to criticize, just some thoughts/opinions):
  • Where possible, leave html out of the code, or cleanly separated
  • Slowly replace functions that have html hard-coded with versions, perhaps by:
    • Add complimentary functions that generate clean data without html; then the original functions could use these functions internally so there is no duplication of code - less lines of code is good!
Personally, I really don't like making modifications to core files like course/lib.php and resource/lib.php, etc. to accomplish something (... ok, I'm a little scared to do so big grin).

---------

A second real-life example is the association of icons to resources: if a url points to a .jpg it doesn't show the jpg icon. Additionally, if a url is complicated, the icon fails to be detected. For example, I have a folder, outside of moodle but on the same domain at something like "/resources/myfile.swf?a=b&c=d" - to make the icon show correctly I hack the url to look like "/resources/myfile.swf?a=b&c=d&.swf" so moodle will recognize it. Maybe that's a glitch, I don't know. Now, there is a patch to allow modules to have their own "icon.gif" file - this is good, but not fully adequate. For example what if a resource type can return various different media? For example if I make a web service that can do "a" and "b" and "c", then make a resource type plugin to easily link those into a moodle course as a resource; then in order to use different icons, even with the patch, I would have to add 3 entries to the "add a resource..." select list - making things get cluttered very quickly. What I did for my plugin (where this scenario sort-of occurred) was make a patch for moodle that allowed me to use a get_icon.php script in place of "icon.gif" --- the point here is not the specific problem really, so much as the general tendency to hard-code (in this case "icon.gif") things in, leaving little "wiggle room" for either designers or coders. Not saying my coding is better - just working with moodle it's plain to see we need to start chaning our thinking while we are developing - we generally don't have a software architect handy (nor a designer), so we gotta be on our toes & carefully think this stuff through - "no hard-coding stuff" if at all possible. (Hope some of this made sense?)

Ok, this is a long post.... sorry about that, I'll stop now! thoughtful
Attachment MoodleCourseSectionLayoutMockup_1r1.gif
In reply to Leo Thiessen

Re: Helping visual designers affect Moodle.

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Links should pick up the correct icon. There is already code in the resource module that handles it, and it is more sophisticated than the icon.gif mechanism. See resource_get_coursemodule_info in http://cvs.moodle.org/moodle/mod/resource/lib.php?view=markup&pathrev=MOODLE_19_STABLE


Re: "* Slowly replace functions that have html hard-coded with versions, perhaps by:
* * Add complimentary functions that generate clean data without html; then the original functions could use these functions internally so there is no duplication of code - less lines of code is good!"

This is already planned, and we have taken the first, low-level steps in Moodle 2.0. Separating HTML from other code everywhere will take longer than that however. See Development:Navigation_2.0_implementation_plan#Themability


As for what you desire to do with your course format - well you appear to want to build mystery meat navigation. Is that really a good idea? Having intelligent handling of alternate formats of the same resource would be good, but displaying a forum as an alternate version of a video seems weird.


Average of ratings: Useful (1)
In reply to Tim Hunt

Re: Helping visual designers affect Moodle.

by Leo Thiessen -
Hi Tim,

Thanks for your useful reply and especially the helpful links! I'm liking this moodle.org setup more every day smile.

I appreciate the icon mechanism improvements. They work well for the 'file' type resource. Handling URL's is still tricky (not accurate) because, for example, something like http://a.com/?x=y could return anything - no way to tell without calling it (but a human can generally tell you what it should be). My thinking for this particular issue is that the 'file' type specific code should be at /resource/type/file/_here_ But I think I'm branching from the original topic here. See what I did for this this patch - let me know your thoughts! (should this item belong to a different forum post or email though, since it seems to me this particular item is getting more into software architecture rather than visual design?)

You're right about potential "mystery meat nav", (I got a chuckle out of that - nice term big grin). I've attached a modification of the concept, hopefully it's a bit better (I'm not a UI designer...).

Bear with me for a bit and pretend that the attached concept is a good idea... how would I do this? (I really do need to do this at some point...). For discussion sake (relevant to this forum topic), if I were not a developer (zero php) how would I do this?

I see some great discussion on themeing in the link you gave me for 2.0; will this be fairly easy to do in 2.0? Can I do it in 1.9.5 some relatively simple way? (The only way I see so far is to write a page-format plugin.)

Thanks for your input!

Regards,
Leo Thiessen
http://visionsencoded.com/
Attachment MoodleCourseSectionLayoutMockup_1r2.gif
In reply to Martin Dougiamas

Re: Helping visual designers affect Moodle.

by Leo Thiessen -
I believe here is another real-life example of where a UI/visual designer needs more/easier control:
In reply to Leo Thiessen

Re: Helping visual designers affect Moodle.

by Thomas Hanley -

Hi Leo,

Just like to add that I agree with your point on having the ability to modify the "You are logged in as...(Logout)" link text.

Of course in the big scheme of things this is a small detail, but as Ian Grivois and others have pointed out these small details add up to a cleaner, more usable interface. These kind of details are exactly the ones that interface designers such as myself notice and try to improve. For me this is not just a question of aesthetics but also a question of  user experience; making it easier for users to separate out the different functions of logging in and out, by placing them on a different line. Obviously it is not ideal to have to hack the PHP to achieve this.

Thanks also to Tim for his work on Moodle 2.0.

~thomas