I need to consult a client as to whether we should try to develop our moodle version in-house, or go with an outside host / custom theme creation.
We have staff that is familiar with WordPress, but it looks like Moodle theming is more complicated than that. Am I right that to really have a custom theme, you'd need to modify core Moodle files? Would we be changing one file, or several, or more?
And if so, how hard is that to do? Is there any documentation? We need to take the "content" area of Moodle pages and have the output be in CSS columns, and not in tables.
I like Moodle (it was *very* easy to set up) but would like to find out what you all think before we commit to managing and hosting it ourselves.
Thank you very much.
In a Moodle theme, you control the HTML in the header, down to about the end of the navigation bar, and the footer, but not the content area in the middle. And you have complete control over the CSS.
Most of the content HTML is reasonably well marked up with class names and ids, to apply CSS to.
And gradually we are killing off the few remaining layout tables and other horrors.
Theme docs start at Theme#Creating_your_own_theme, I think. I am a developer rather than a themer.
Why do you NEED to use CSS columns, by the way? I can understand needing to achieve a certain appearance; and I can understand professional pride wanting to have clean HTML.
Most of the content HTML is reasonably well marked up with class names and ids, to apply CSS to.
And gradually we are killing off the few remaining layout tables and other horrors.
Theme docs start at Theme#Creating_your_own_theme, I think. I am a developer rather than a themer.
Why do you NEED to use CSS columns, by the way? I can understand needing to achieve a certain appearance; and I can understand professional pride wanting to have clean HTML.
Some additions: In forum description http://moodle.org/mod/forum/view.php?id=46 we have links
"You can find a list of all available themes in the Moodle Themes repository.
You're welcome to browse and contribute to our Themes documentation and Themes FAQ. "
Read also http://tracker.moodle.org/browse/MDL-9306
Current stable versions of moodle have in index.php
<table id="layout-table" summary="layout">
and 3 rows down
$lt = (empty($THEME->layouttable)) ? array('left', 'middle', 'right') : $THEME->layouttable;
After reading http://docs.moodle.org/en/Theme_settings#Change_column_order you can easily change the order of those 3 columns of content area and with some extra code in index.php you could create a more complex layout. Still most activities have some restrictions for possible layout and use tables so it may be hard to create a layout without any tables. And to make everything more flexible or more difficult (depends on situation) we have different course formats http://docs.moodle.org/en/Course_settings#Format and there
"The CSS / No Tables variant of the Weekly format displays the Weekly course format without using tables for layout. This improves the accessibility of the format, but older browsers have trouble displaying it correctly."
Structure of themes could be more flexible but it is usually not a good idea to modify core files for themes...you should be able to do all necessary design tricks with css. Creating themes for moodle is not difficult but creating really unique themes with tableless more flexible multiple column layout that works with all browsers...that is rather difficult.
To create a certain look and feel for Moodle can be thought in roughly three different complex ways:
- To change some colours and the Moodle header and footer is fairly easy with CSS and some basic web design skills.
- To create a distinct look to for example integrate Moodle smoothly into the online presence following the company/institution corporate design a designer quite experienced with Moodle will need some days. A novice might not be able to accomplish the goal within a reasonable budget.
- To fundamentally change the layout of the Moodle pages needs even more competences. You need a very experienced designer and an experienced Moodle developer. And a good update strategy to handle the necessary updates within a reasonable budget.
Tim asks "Why do you NEED to use CSS columns..."
I think there is no need for anybody to justify the way a web presence is implemented. The question is if Moodle is flexible enough to meet the needs.
With some interesting why questions I am preoccupied for some time now:
- Why do some Moodle developers tend to more and more ask why someone wants to design Moodle in a certain way instead of asking how Moodle developers can support/help to easily design Moodle in many different ways?
- Why does Moodle headquarter not employ a graphic/web designer to bring design competence into Moodle development? And to help Moodle developers understand visual design aspects.
- Why does Moodle still offer "the existing quite crappy" themes? Martin Dougiamas talked about replacing them in July 2007.
- Why do Moodle developers take the "crappy" and overly simple Moodle standard theme as their reference? Hardly anybody uses centered page layouts. The Moodle theme used for development must reflect the design complexity of real world Moodle pages and not lead the developers to believe the pages work in reality when they look ok in the Moodle standard theme.
- Why does the number of depreciated HTML tags in the latest Moodle versions increase? The goal was to remove all for a long time.
1. is just good software engineering. One of the distinctions that it is important to make is between the user's requirements and technical design that implements them.
Technical design is about achieving the requirements that the customer wants within the constraints of what is possible with the available technology.
If someone jumps in to a forum thread in the middle, asking whether a particular technical design is possible in Moodle, and if the answer is 'no', then it is always sensible to ask what the original requirement was. We may be able to suggest alternative designs that are possible in Moodle.
I very good book on requirements is "Mastering the Requirements Process" by Robertson and Robertson, which I studied as part of the Open University course M883. (I recommend that too.)
Technical design is about achieving the requirements that the customer wants within the constraints of what is possible with the available technology.
If someone jumps in to a forum thread in the middle, asking whether a particular technical design is possible in Moodle, and if the answer is 'no', then it is always sensible to ask what the original requirement was. We may be able to suggest alternative designs that are possible in Moodle.
I very good book on requirements is "Mastering the Requirements Process" by Robertson and Robertson, which I studied as part of the Open University course M883. (I recommend that too.)
Found a nice quote on Signal vs. Noise
He who argues for his limitations gets to keep them.
-- Richard Bach
Nice quote - I like this one:
"Limitations are the soil from which creativity grows." - Jeffrey Zeldman http://www.alistapart.com/articles/5k/
taken from
http://collegewebguy.com/2008/04/18/design-limitations-of-the-web-what-limitations/
The ideal theme should allow free styling and positioning of different activities and content - not only header, footer and side blocks - and there should be several ways to do it. It should be easy to modify for beginners and flexible without restrictions for professional designers. Right.
For example http://www.webresourcesdepot.com/19-promising-php-template-engines/ tells that
"PHP template engines are used widely to seperate the code & the layout. This makes a website easier to maintain/update & creates a better development environment by enabling developers & designers to work together easier. It sure has some drawbacks which is generally the performance (most libraries offer great solutions there) & need to learn a new syntax (not always). To mention, using a template engine may not be suitable for every project. A website with few pages will probably won’t need it. But it can improve the development process of a portal, an e-commerce site or another web application easily." (Urs +1p)
On the other hand examples like http://pimteam.net/2008/01/06/stop-using-php-template-engines-once-and-for-all-why-smarty-is-evil/ nullify all this. (Tim +1p)
Urs, all new ideas to make creating themes more flexible and easier are welcome - but in cases like this it's really hard to say anything.
Goalles draw... every coin has two sides.
Interesting links. Thank you.
I just want to comment on one bit: "allow free ... positioning of different activities and content"
We already have the blocks system, that lets you do that (to a certain extent) using just your web browser. No PHP code or templating language required. And extending the capabilities of blocks is certainly included in Moodle 2.0.
Blocks are, of course, different from templates, but they are another part of the jigsaw that needs to be taken into account when working out the complete picture for how everything should work in Moodle. (And we have blocks here and now, so in the short term, it may be easier to satisfy some requirements by extending the blocks system, even if, in the long term, those things would be better to handled by templates.)
Also, I want to link to this bit of a General Developer Forum thread about blocks. People here probably have useful contributions to make there.
I just want to comment on one bit: "allow free ... positioning of different activities and content"
We already have the blocks system, that lets you do that (to a certain extent) using just your web browser. No PHP code or templating language required. And extending the capabilities of blocks is certainly included in Moodle 2.0.
Blocks are, of course, different from templates, but they are another part of the jigsaw that needs to be taken into account when working out the complete picture for how everything should work in Moodle. (And we have blocks here and now, so in the short term, it may be easier to satisfy some requirements by extending the blocks system, even if, in the long term, those things would be better to handled by templates.)
Also, I want to link to this bit of a General Developer Forum thread about blocks. People here probably have useful contributions to make there.
Tim, I'm not complaining about current situation - the ideal case is not the same as current possible case. Yes, we have blocks and it's good to get all those new features to moodle 2.0. And I agree that it's a real jigsaw when you try to create unique themes if you need to make major changes to non standard layout.
I'm not advertising RocketTheme here but I have used some of their themes and really like those features they use - and yes, they could be used in moodle too.
Examples like http://demo.rockettheme.com/labs/akiraka-essentials/index.php?option=com_content&view=article&id=50&Itemid=75 are made with a system (here joomla) where you simply have a list of possible (editable) positions, some of them are used by default, some are custom positions. Most of these module positions are fully collapsible meaning that if there are no modules published in particular area, that module area will not be shown. Each activity (block, module or what ever) can be set to use one specific position and different id specifies the order of content inside each "custom box"
Another thing is those preset styles http://demo.rockettheme.com/labs/akiraka-essentials/index.php?option=com_content&view=article&id=49&Itemid=56 and here we come close to templates - but these are not made with template engines like PHPTAL
Basic Customisation http://demo.rockettheme.com/labs/akiraka-essentials/index.php?option=com_content&view=article&id=57&Itemid=82 is done by changing certain preset variables - old idea but better implemented than before in any other systems.
And you can find some more helpful features from the menu of http://demo.rockettheme.com/labs/akiraka-essentials/
And finally when you add backgrounds etc customization the result looks like this:
Mauno, great links.
In the article you have scored for Tim you read at the end:
"So How Do You Go Without Template Engines?
PHP is template language itself. You don’t need another one. Just separate your logic from your presentation. Keep your logic in a php script, then your presentation in HTML template. When you need control flow in the HTML file, just use pieces of PHP code. It’s really as simple as that. In your PHP script you can use include or require to display the template. All the variables which are in the scope of the script will be available in the template as well. No loading required, no messy presentation code in the controller layer."
That is exactly what I always proposed as "RawPHP" templates and what several projects use. They argue against template engines and for php only templates.
So we may change the votes +2 for Urs and +1 for Tim if he may change his mind and accept that separating logic from presentation may be the right way to go for Moodle too.
Well shot, Urs!
+2p
2. I would guess because many Moodle Partners employ graphic designers, and there is an active theme design community producing many excellent themes, so for Moodle HQ, there are higher priority items to spend money on.
3. Well, any time you try to remove anything from Moodle, there will be some people who complain loudly. Therefore, it is easier to leave the other themes there, as long as the cost of maintaining them is not too high.
It is easy for people to get and use themes from the themes database in their Moodle.
And we have added better new themes like the custom corners theme, as they have appeared.
Last 'summer', one of the Google Summer of Code projects we mentored was to make a new customisable theme: Student_projects/Customisable_theme. I don't know how far that got.
So, we are gradually trying to make things better, including planning further changes in Moodle 2.0. However, like everything, it is competing for a finite resource. Of course, this is open source, so if you care about something badly enough, you should be able to make it happen by working constructively with the community.
4. As I understand it, the standard theme is intentionally quite plain, so that it is a base from which you can build any number of other themes. If most developers worked with one highly styled themes, then they is more risk that they would do things that works really well in that one theme, but which are not general enough to have other themes applied to them. That seems like a good reason for keeping a really plain standard theme.
I think many of us, including Martin and me, would like to see better themes shipped as standard with Moodle, and having it as easy as possible to make new themes. But that does not mean we have had much time to devote to it over the last few years.
3. Well, any time you try to remove anything from Moodle, there will be some people who complain loudly. Therefore, it is easier to leave the other themes there, as long as the cost of maintaining them is not too high.
It is easy for people to get and use themes from the themes database in their Moodle.
And we have added better new themes like the custom corners theme, as they have appeared.
Last 'summer', one of the Google Summer of Code projects we mentored was to make a new customisable theme: Student_projects/Customisable_theme. I don't know how far that got.
So, we are gradually trying to make things better, including planning further changes in Moodle 2.0. However, like everything, it is competing for a finite resource. Of course, this is open source, so if you care about something badly enough, you should be able to make it happen by working constructively with the community.
4. As I understand it, the standard theme is intentionally quite plain, so that it is a base from which you can build any number of other themes. If most developers worked with one highly styled themes, then they is more risk that they would do things that works really well in that one theme, but which are not general enough to have other themes applied to them. That seems like a good reason for keeping a really plain standard theme.
I think many of us, including Martin and me, would like to see better themes shipped as standard with Moodle, and having it as easy as possible to make new themes. But that does not mean we have had much time to devote to it over the last few years.
@2
Web design is not the profession to nice up what developers have created with themes. To create a Moodle theme is a completely different case than to design Moodle pages and the Moodle interface.
Two links to elaborate on this issue
Both articles come to the conclusion "... the web designer and web development programmer are two different people who must work together to create a successful website" or web application like Moodle.
Moodle users get only halve of what they might get when Moodle developers and Moodle HQ would recognize that Moodle suffers from the lack of web design competencies.
Working at the Open University, I did work in teams with graphic designers, and greatly enjoyed it. The results we produced together were always better than what any of us could have done on our own. So:
"the web designer and web development programmer are two different people who must work together to create a successful website".
Yes, please. I would love to discuss with you what it is practically to do in Moodle 2.0 to make things better for designers.
At the moment, your 'discussion' seems to involve simply asking for templates repeatedly, and implying that the only reason developers say that is impossible for Moodle 2.0 is because developers are stupid and stubborn. At least that is how it seems to me.
Do you think it is possible for us to have a more productive discussion than that?
"the web designer and web development programmer are two different people who must work together to create a successful website".
Yes, please. I would love to discuss with you what it is practically to do in Moodle 2.0 to make things better for designers.
At the moment, your 'discussion' seems to involve simply asking for templates repeatedly, and implying that the only reason developers say that is impossible for Moodle 2.0 is because developers are stupid and stubborn. At least that is how it seems to me.
Do you think it is possible for us to have a more productive discussion than that?
Yes - that's exactly what we all need:
productive discussions - no shooting, no flaming, no blaming...
Forget those points, most designers and developers are just "normal" people with different temperament, some may be stuped or stubborn but I have not met any... 
5. Do you have specific examples? The goal is, indeed, to remove them, and I thought we were succeeding there, gradually.
In the tracker issue New moodle.org theme improvements Martin states
"Just a note about the 'font' tags ... yes, we shouldn't have any in our code, though I count less than you: 136 left in Moodle 1.9 and 155 in HEAD."
The numbers show that usage of depreciated tags is increasing.
We have font tags. (vomit)
/me greps. Yes, we do, although counting is hard. Some are in third-party libraries we use which we can't do anything about. Other occurrences of the string '<font' in the code are were we process input from users, and so are not bad.
However, there are still a lot left ;-(
My attempt at counting, trying to ignore the same thing in both branches, has the number going down from 13x to 11x, which mostly corresponds to the exercise and journal modules being deleted.
Still the remaining ones need to be killed.
/me greps. Yes, we do, although counting is hard. Some are in third-party libraries we use which we can't do anything about. Other occurrences of the string '<font' in the code are were we process input from users, and so are not bad.
However, there are still a lot left ;-(
My attempt at counting, trying to ignore the same thing in both branches, has the number going down from 13x to 11x, which mostly corresponds to the exercise and journal modules being deleted.
Still the remaining ones need to be killed.
By asking how can a solution look to circumvent the visual design restrictions in Moodle I worked on two solutions.
1. Templates
One nice solution with maximum flexibility for web/graphic designers is to add templates to Moodle. Templates enable designers to work in their design world with their design tools mostly without the need to involve developers.
So I implemented a template class in Moodle 1.9 as a prove of concept. With this template class I added two template engines: a RawPHP template engine and the PHPTAL engine. You may check the outcome at my lab.unodo-design.com site. This is a real and working Moodle 1.9 site showing how flexible you can implement very different page designs.
My posting about this implementation and the discussion with some Moodle developers you may read in The Future of Moodle Templates?.
In short Moodle developers state that it is not possible to implement themes in Moodle now. Many developers argue that Moodle does not even need templates at all. Most developers argue only from their developer point of view. They don't realize the huge advantage of templates for designers. But we designers are the ones who have the potential to implement great pages and interfaces. Moodle developers have proven to lack design competencies.
2. A few line hack in two scripts for Moodle 1.9
For a client project I started to implement a solution to be able to use sticky blocks on all Moodle pages. With this solution not only blocks on all Moodle pages but also positioning the side columns and content different from the actual page layout is possible. This project has been stopped before it was ready. But this concept may be 75% of the solution Nabha is looking for.
A short explanation of the approach
- Fetch the left and right column into a variable each.
- Fetch the content into a variable.
- Create a table-less page layout. (I used RawPHP templates)
- Output content for the header, the left column blocks, the right column blocks, the content area, the footer in the template.
You definitely can create pages as Patrick had sketched in his Good 1.9 themes posting where he writes "The first example that jumps to mind is the two-column theme with the third "column" of sideblocks at the bottom of the content just above the footer."
When there will be a budget to develop this approach ready and test it and enough support to convince Martin Dougiamas to implement this few changes in Moodle 1.9 we may be able to work a bit more flexible with Moodle than now.
The changes I have implemented in a way that they do not change standard Moodle behavior when not activated.
Urs,
thank you very much for this implementation and your efforts. I absolutely support your arguments and hope that there will be a way at least for some of your proposals to make it into Moodle 2.0.
Many times I have been asked why Moodle is so hard to adapt to the design of modern websites. Why does a classroom have to be like those old 3-columns or two columns websites?!
I followed the discussion you mentioned (Future of Moodle Templates) and was a bit shocked by the nearly categorical refusal of the direction of your ideas.
Just to let you know that you have supporters.
Bernhard
thank you very much for this implementation and your efforts. I absolutely support your arguments and hope that there will be a way at least for some of your proposals to make it into Moodle 2.0.
Many times I have been asked why Moodle is so hard to adapt to the design of modern websites. Why does a classroom have to be like those old 3-columns or two columns websites?!
I followed the discussion you mentioned (Future of Moodle Templates) and was a bit shocked by the nearly categorical refusal of the direction of your ideas.
Just to let you know that you have supporters.
Bernhard
Bernhard,
thank you very much for your encouraging posting.
We need more people to come up and tell their opinion. It will be a huge effort to break up the closed view of the developers who confirm each other that their view on web apps is the only right way.
Ignoring design aspects is dangerous in the long term. People complain about the dull look of Moodle already.
1. Is the code behind lab.unodo-design.com site available for people (me) to look at? I would like to see how you did it.
The claim "it is not possible to implement themes in Moodle now" is entirely independent from the claim "templates are a huge advantage for designers". I think both those statements are true, but sadly, the fact that the second one is true does not magically make the first statement false.
2. Is, I think, close to what I am proposing for Moodle 2.0. We will have blocks, and sticky blocks, on all pages.
Also, as well as printing the header and the footer, the theme will also control the major page layout in-between (whether using tables, floating divs, or whatever). The theme will just need to call a function like $HTML->print_blocks('left') or something like that where it wants the 'left' blocks to appear, so if you actually want the 'left' blocks to appear at the bottom of the page in a horizontal row, that will work.
Also, we will let the theme override functions like print_box, and print_side_block, so you can change the HTML generated for those, if you like.
That just leaves the central 'content' area in the middle of the page as the one part where the other Moodle PHP code, rather than the theme, has control.
By the way. Developers have their own version of "let's rewrite Moodle to use templates". The developer's version is "Let's rewrite Moodle in Java." (or Ruby, or any other favourite programming language.) The difference seems to be that we only say it as a joke, because we realise that it is impossible.
The claim "it is not possible to implement themes in Moodle now" is entirely independent from the claim "templates are a huge advantage for designers". I think both those statements are true, but sadly, the fact that the second one is true does not magically make the first statement false.
2. Is, I think, close to what I am proposing for Moodle 2.0. We will have blocks, and sticky blocks, on all pages.
Also, as well as printing the header and the footer, the theme will also control the major page layout in-between (whether using tables, floating divs, or whatever). The theme will just need to call a function like $HTML->print_blocks('left') or something like that where it wants the 'left' blocks to appear, so if you actually want the 'left' blocks to appear at the bottom of the page in a horizontal row, that will work.
Also, we will let the theme override functions like print_box, and print_side_block, so you can change the HTML generated for those, if you like.
That just leaves the central 'content' area in the middle of the page as the one part where the other Moodle PHP code, rather than the theme, has control.
By the way. Developers have their own version of "let's rewrite Moodle to use templates". The developer's version is "Let's rewrite Moodle in Java." (or Ruby, or any other favourite programming language.) The difference seems to be that we only say it as a joke, because we realise that it is impossible.
Dear Urs, Tim, and everyone, thanks for taking the time to respond. Your answers were definitely helpful.
As it is, we've decided to go with a Moodle hosting company that can do a little theme customization. I'm sure that the theme we'd ideally like to use (which is already completely developed and will be used on another site of ours, a Drupal site) is too complex to adapt, especially in its already-finished state with pure HTML / CSS.
We have a limited budget and even more limited developer hours, so what we'll do for now -- it looks like -- is go with customizing an already-existing Moodle theme.
Tim, what you're describing for Moodle 2.0 sounds great. It is the sort of thing I was looking for, which of course is similar to what Urs was working on, also. I hope it makes it in!
As it is, we've decided to go with a Moodle hosting company that can do a little theme customization. I'm sure that the theme we'd ideally like to use (which is already completely developed and will be used on another site of ours, a Drupal site) is too complex to adapt, especially in its already-finished state with pure HTML / CSS.
We have a limited budget and even more limited developer hours, so what we'll do for now -- it looks like -- is go with customizing an already-existing Moodle theme.
Tim, what you're describing for Moodle 2.0 sounds great. It is the sort of thing I was looking for, which of course is similar to what Urs was working on, also. I hope it makes it in!
1. You continue asking for code examples. Each time I give you sources - what is wrong with them that you continue to repeat your question?
Is this your way of "... working constructively with the community"?
Is this your way of "... working constructively with the community"?
Apologies. I posted after searching a number of forum posts, modules and plugins database, etc, and failing to find any attachments. Then I found the folder of code for slideshowtwo on my desktop. (blush)
Urs's reworking of the slideshow module demonstrates that for a simple module (measured by, for example, the fact that there are only 6 templates - if you count the editing form - and three main scripts) with limited interaction, it is possible to separate the presentation into templates. (Something I did not doubt, although I may not have made that clear, and it is very nice to see how it works in practice.)
How is this done: start with any typical moodle script.php that has only simple logic and is well written to separate the logic from the presentation as much as possible.
a. Move almost everything before print_header into a script_logic.php file. In there, be sure to write all the data that the template will need into a $tpl array.
b. Move everything between print_header and print_footer into template/script_view.inc.php, editing as necessary.
c. replace script.php with a very short script that does include('script_logic.php'); print_header(...); render_template('script_view', $tpl); print_footer(); (I have used a made-up function to reduce the amount of duplicated code.
What are the difficulties with this? (and yes, if you wish to stereotype, this is a typical developer's reaction. However, these are also serious concerns.)
1. It pre-supposes that it is always possible to separate the logic from the presentation, and I am still not convinced of that. mod/quiz/view.php remains my challenge to anyone who claims that this separation is always possible.
2. There is a strong coupling between the logic file and the view. The logic file has to know what data the template is expecting to find in $tpl - or, to look at it another way, the template can only use what the logic file chooses to make available in $tpl.
3. Slicing the code in three like that makes it much harder for developers. It is much harder to see where any variable is used, making any changes required to fix a bug much riskier. It is much more likely that I break something else while fixing one bug. That is why cohesion is important criteria used for judging software design. (And if the code is all in one file, my IDE will actually highlight all the other places where each variable is used. Very helpful for working out what is going on.)
4. There is lots of duplicated code in each template. Suppose you want to make a change like the change from the standard theme to the custom corners theme. That involves replacing every 'box' div with several divs. To implement the custom corners theme (once it had been re-implemented properly, see MDL-12221) we only had to change a few functions like print_box in weblib. With templates, as far as I can see, it involves changing many divs in many templates. "Once and only once" is an important criterion for good software design - I quote PHP in Action, which I am currently about a quarter of the way through.
5. If all the HTML is written out in full in all the templates, then it is much harder to ensure that all similar things (like headings) get consistent ids and class names. As we know, consistent use of ids and class names if very helpful for those theme developers (the majority?) who would like to be able to make a nice theme by only editing CSS.
6. Even if it is possible to separate presentation and logic everywhere, doing so will be a lot of work, and if that happens, other things will not happen until later.
7. All existing third-part plugins will have to be re-written to do things the new way.
Of course, the benefits are:
A. Theme developers who want to go beyond just editing CSS can do so easily.
B. It enforces the separation of presentation and logic in future.
Like every major decision affecting Moodle, this requires discussion with the whole community, and ideally a consensus on the balance of cost to benefit. (Or, as in some cases in the past, someone with deep pockets to adjust the balance
)
(By the way, I am pretty sure that I have not seen the code behind the front page of http://lab.unodo-design.com/. That is a much trickier case, so I would really like to see that code.)
Urs's reworking of the slideshow module demonstrates that for a simple module (measured by, for example, the fact that there are only 6 templates - if you count the editing form - and three main scripts) with limited interaction, it is possible to separate the presentation into templates. (Something I did not doubt, although I may not have made that clear, and it is very nice to see how it works in practice.)
How is this done: start with any typical moodle script.php that has only simple logic and is well written to separate the logic from the presentation as much as possible.
a. Move almost everything before print_header into a script_logic.php file. In there, be sure to write all the data that the template will need into a $tpl array.
b. Move everything between print_header and print_footer into template/script_view.inc.php, editing as necessary.
c. replace script.php with a very short script that does include('script_logic.php'); print_header(...); render_template('script_view', $tpl); print_footer(); (I have used a made-up function to reduce the amount of duplicated code.
What are the difficulties with this? (and yes, if you wish to stereotype, this is a typical developer's reaction. However, these are also serious concerns.)
1. It pre-supposes that it is always possible to separate the logic from the presentation, and I am still not convinced of that. mod/quiz/view.php remains my challenge to anyone who claims that this separation is always possible.
2. There is a strong coupling between the logic file and the view. The logic file has to know what data the template is expecting to find in $tpl - or, to look at it another way, the template can only use what the logic file chooses to make available in $tpl.
3. Slicing the code in three like that makes it much harder for developers. It is much harder to see where any variable is used, making any changes required to fix a bug much riskier. It is much more likely that I break something else while fixing one bug. That is why cohesion is important criteria used for judging software design. (And if the code is all in one file, my IDE will actually highlight all the other places where each variable is used. Very helpful for working out what is going on.)
4. There is lots of duplicated code in each template. Suppose you want to make a change like the change from the standard theme to the custom corners theme. That involves replacing every 'box' div with several divs. To implement the custom corners theme (once it had been re-implemented properly, see MDL-12221) we only had to change a few functions like print_box in weblib. With templates, as far as I can see, it involves changing many divs in many templates. "Once and only once" is an important criterion for good software design - I quote PHP in Action, which I am currently about a quarter of the way through.
5. If all the HTML is written out in full in all the templates, then it is much harder to ensure that all similar things (like headings) get consistent ids and class names. As we know, consistent use of ids and class names if very helpful for those theme developers (the majority?) who would like to be able to make a nice theme by only editing CSS.
6. Even if it is possible to separate presentation and logic everywhere, doing so will be a lot of work, and if that happens, other things will not happen until later.
7. All existing third-part plugins will have to be re-written to do things the new way.
Of course, the benefits are:
A. Theme developers who want to go beyond just editing CSS can do so easily.
B. It enforces the separation of presentation and logic in future.
Like every major decision affecting Moodle, this requires discussion with the whole community, and ideally a consensus on the balance of cost to benefit. (Or, as in some cases in the past, someone with deep pockets to adjust the balance
(By the way, I am pretty sure that I have not seen the code behind the front page of http://lab.unodo-design.com/. That is a much trickier case, so I would really like to see that code.)
Hi Tim,
I am a very amateurish programmer, dabbling in PHP and CSS, etc. and I find it difficult at times to follow these discussions. However I recently had to hack a photo gallery PHP programme which relied on templates and was truly horrified at the complexity and uselessness of separating the logic from the presentation by using templates. I totally agree with all of your 7 points above. Please let's keep away from templates in moodle if we want to retain our sanity.
Joseph
I am a very amateurish programmer, dabbling in PHP and CSS, etc. and I find it difficult at times to follow these discussions. However I recently had to hack a photo gallery PHP programme which relied on templates and was truly horrified at the complexity and uselessness of separating the logic from the presentation by using templates. I totally agree with all of your 7 points above. Please let's keep away from templates in moodle if we want to retain our sanity.
Joseph
Joseph,
You are a real programmer Guru compared to me.
I must admit that the first time I have been truly horrified at the complexity and uselessness of separating the logic from presentation was some years ago when I tried to create totally different themes for kids - and to notice (like Patrick) that it really was not possible in moodle to change the logic of content area without major hacks.
I think Patrick describes the current situation very well. In joomla main code of index.php is given to themes already in index.php itself (or two index files actually). Themes have individual index.php that controls page layout and it allows themes to have any structure designer wants to use. There are common variables, default values etc but basicly themes are just like cloths that you choose and use. With CSS, javascripts, flash and other elements.... so ....
Urs,
the discussion about optional HTML editors fell the same way - and the experimental code to use multiple editors was changed back to one-editor-default-editor system (from HTMLArea to TinyMCE) in moodle 2.0. I was frustrated some weeks but could live with the decision - and finally felt it was a wise decision from developers point of view to keep moodle 2.0 more stable and to not cause too much extra work - to others.
Examples like these only show that modularity of moodle is not perfect and some good ideas can't be used because majority of users does not want them. It's called democracy. We have seen it in selection of standard activities and will see several similar discussions in the future when all kinds of new (or old) ideas pop up.
I honestly believe that all those people who don't agree with you have a good reason to disagree or hesitate - most people may not be sure what to say because most of us have never tried to use PHPTAL or other template engines or some are disappointed at the results with other template engines like Joseph - or template engines may be too hard to use for beginners. If majority of opinions is to bury template engines let's test the other alternatives - and you have plenty of other tools in your pockets, right?
I'd like to propose something that might expose my naivety:
I use Vanilla (http://getvanilla.com/) to power my support forums and it uses a template system that seems pretty straight forward.
The system looks for template files inside the theme folder. If a file is present, it's used. If it's absent, the default is used.
This would a.) keep backward compatibility, b.) allow theme designers to alter the XHTML of any page they would like, and c.) keep things pretty simply for the core distribution.
Would something like this work well in Moodle?
I use Vanilla (http://getvanilla.com/) to power my support forums and it uses a template system that seems pretty straight forward.
The system looks for template files inside the theme folder. If a file is present, it's used. If it's absent, the default is used.
This would a.) keep backward compatibility, b.) allow theme designers to alter the XHTML of any page they would like, and c.) keep things pretty simply for the core distribution.
Would something like this work well in Moodle?
The thing is, the operation of going to the disc drive, and saying 'does this file exist' is relatively slow. Particularly if, say, you have a separate template for each block.
So, if you run a busy Moodle site like moodle.org or the Open University, and you employ lots of developers, you probably don't want that overhead.
But, if you have a small Moodle site that you want to customise, (or if you are a bit site and want to rapidly prototype a new theme that your developers will later implement without lots of separate template files) then the approach you suggest is a good one.
In an ideal world, the theming system might support both approaches. I believe Drupal does. Can Moodle? That is what we are talking about.
So, if you run a busy Moodle site like moodle.org or the Open University, and you employ lots of developers, you probably don't want that overhead.
But, if you have a small Moodle site that you want to customise, (or if you are a bit site and want to rapidly prototype a new theme that your developers will later implement without lots of separate template files) then the approach you suggest is a good one.
In an ideal world, the theming system might support both approaches. I believe Drupal does. Can Moodle? That is what we are talking about.
The thing is, the operation of going to the disc drive, and saying 'does this file exist' is relatively slow. Particularly if, say, you have a separate template for each block.
This makes sense to me? Why couldn't we just specify in config.php which files we're replacing, thereby reducing the load on the server by only having a call for those specific files?
Well, you could, but having to keep manifest files like that up-to-date by hand is really boring.
A better solution is, when you install the theme, Moodle could look at which templates you supply, and which templates your parent theme supplies, and automatically build a list for you and save it to disc. That is, of course, the correct implementation.
A better solution is, when you install the theme, Moodle could look at which templates you supply, and which templates your parent theme supplies, and automatically build a list for you and save it to disc. That is, of course, the correct implementation.
You just reminded me of another thing I wanted to say. So much for stopping rambling.
If you think about some of the changes that have gone into Moodle recently, for example the new Gradebook in 1.9, and Conditional activities in Moodle 2.0. Well, in both those cases there were major customisations (Gradebook plus and Activity locking) floating around in the community for years, with many people downloading and installing them, even though that involved patching core code.
If templates are the best thing since sliced bread, why isn't there a similar download-able hack circulating in the community? From what I have read, I think there was in the Drupal community before templates went mainstream there.
If you think about some of the changes that have gone into Moodle recently, for example the new Gradebook in 1.9, and Conditional activities in Moodle 2.0. Well, in both those cases there were major customisations (Gradebook plus and Activity locking) floating around in the community for years, with many people downloading and installing them, even though that involved patching core code.
If templates are the best thing since sliced bread, why isn't there a similar download-able hack circulating in the community? From what I have read, I think there was in the Drupal community before templates went mainstream there.
Tim,
you have written a very well-grounded list here.
If you have time, take a look at the demo in http://www.limesurvey.org/content/view/15/81/lang,en/
LimeSurvey is the successor of old phpSurveyor ( I used the old program some years ago) and it has some fresh ideas that could be useful when you create new features to quizzes. It has a template system and template editor that are not too complex to learn or use.
It really does not have to be so complicated after all - if common site wide templates are not possible it may be possible to create those alternative workarounds to each activity as well.
- My changes are for Moodle 1.9 now. Your solutions are for Moodle 2.0 sometimes in the future.
You seraiously propose that we tell people to wait till about 2010 when Moodle 2.0.1 or 2.0.2 as a production ready version might be out? Strange view on market needs.
"By the way. Developers have their own version of "let's rewrite Moodle to use templates". ... The difference seems to be that we only say it as a joke, because we realise that it is impossible."
Marvelous joke, I never laughed more
The problem with your comparison is that you compare apples with pears.
You see Moodle being build from developers and to be implemented and extended by developers. So developers are by themselves.
Web designers may merely nice up what developers wonderfully have created if someone thinks it may be absolutely necessary.
This arrogance is a mayor culprit with many Open Source programs/communities where developers confirm themselves to be perfect.
Moodle users are the ones how suffer from this attitude. Inconsistent pages and lack of flexibility will never bring Moodle over mediocrity concerning it's interface.
The majority of proposals to change Moodle 2.0 will make the work of developers easier. Overriding classes is developer heaven. Web designers have no advantage at all. And so the quality of the Moodle interface won't increase.
Tim, I am glad for Moodle that I didn't need to argue with you about implementing custom_corners or the possibility to rearrange the column order.
I am sure that you would have declared these features as irrelevant as you have done with many of my proposals/examples in the last discussions.
The relevance of these two features is clear - moodle.org and several Moodle implementations use both.
Hello Urs,
I'd like to help support your cause by offering this:
http://patrickmalley.com/2009/02/18/the-case-for-moodle-templates/
It's not much, but it's a start.
I'll do my best to come up with more practical reasons why templates are needed.
Overall, though, I'm a.) getting sick of telling clients that they can't change certain aspects of their theme without altering the core code, and b.) seeing a lot of great design inspiration that will never make it's way into a Moodle theme since it's simply not possible.
Let me know if there is anything else I can do to help.
I'd like to help support your cause by offering this:
http://patrickmalley.com/2009/02/18/the-case-for-moodle-templates/
It's not much, but it's a start.
I'll do my best to come up with more practical reasons why templates are needed.
Overall, though, I'm a.) getting sick of telling clients that they can't change certain aspects of their theme without altering the core code, and b.) seeing a lot of great design inspiration that will never make it's way into a Moodle theme since it's simply not possible.
Let me know if there is anything else I can do to help.
Beautiful theme. And nice to have clearly stated requirements.
I would only disagree with your title. Templates (in the sense that Urs is using) are not the only way to meet that requirement. I have already proposed how I think we should meet this requirement in Moodle 2.0, and yesterday I tried to explain my ideas clearly with some pictures. What do you think?
I would only disagree with your title. Templates (in the sense that Urs is using) are not the only way to meet that requirement. I have already proposed how I think we should meet this requirement in Moodle 2.0, and yesterday I tried to explain my ideas clearly with some pictures. What do you think?
Tim,
you are right - templates are not the only way to meet that requirement. When you said in that other thread "Complete flexibility also tends to lead to a lack of consistency" it just tells that you want to create a stable system where you can't change some default settings to be able to control that system does not crash... It's a good vision.
Designers are often dreamers - they want to see all kinds of beatiful, funny, new, experimental things. When developers want to keep order, designers may want to break it.
If themes can use custom positions instead of just left or right and you can define those positions for each "content box" (for blocks or other content it can be given with some optional position in database - the same way as we have custom fields in user profiles) and if you define default positions (let's say left if custoxxx does not exist in theme) it's not yet very inconsistent. It does not break standard theme and you can set to theme config.php for example
$THEME->custompositions = true;
to allow themes check custom positions for content if they are given.
I think the best way to go is to build optional selectors to use different non standard systems - no matter if they are template engines or block positions - and if possible the whole system could be loaded as whole package...
Hello Tim,
Thank you.
I scaled down my blog post quite a bit from my original intention as a way of getting the idea out in one sitting, but I did include this one point:
I think it would be great to be able to alter the forum post layout, and play around with the questionbank layout, and ... I'm sure you see where I'm going with this.
I would like to see wide-scale implementation of templates in the same way that Drupal, Wordpress, or Joomla use templates. If this is something technically different from what Urs is proposing, then I may have missed something, but I think our goals are the same.
In the posts you've linked to, which I've been following with some interest, it seems that you're proposing freedom to alter the page layout (blocks in the middle, etc.), while retaining control over the general format of everything within that layout. I want more!
Here's a practical reason why giving designers control over page templates could be a good thing overall:
Imagine a situation where a client requests design changes to the question bank. In implementing their change, I discover a better way of displaying that content. I share what I've learned with the community. It gets put into the core code.
The way Moodle currently works, designers don't have any input on page layout unless they submit a request to the tracker, make their case in the forum, and hope that it gets priority over other other (admittedly more pressing) issues.
The process isn't fluid enough for designers to work with, so the design has suffered without our input.
By giving designers access to the template files, we (designers) might just find a better way of doing things that could benefit Moodle for the long term.
Thank you.
I scaled down my blog post quite a bit from my original intention as a way of getting the idea out in one sitting, but I did include this one point:
While I would like even more access to the Moodle layout, this would seem to be a reasonable start.
I think it would be great to be able to alter the forum post layout, and play around with the questionbank layout, and ... I'm sure you see where I'm going with this.
I would like to see wide-scale implementation of templates in the same way that Drupal, Wordpress, or Joomla use templates. If this is something technically different from what Urs is proposing, then I may have missed something, but I think our goals are the same.
In the posts you've linked to, which I've been following with some interest, it seems that you're proposing freedom to alter the page layout (blocks in the middle, etc.), while retaining control over the general format of everything within that layout. I want more!
Here's a practical reason why giving designers control over page templates could be a good thing overall:
Imagine a situation where a client requests design changes to the question bank. In implementing their change, I discover a better way of displaying that content. I share what I've learned with the community. It gets put into the core code.
The way Moodle currently works, designers don't have any input on page layout unless they submit a request to the tracker, make their case in the forum, and hope that it gets priority over other other (admittedly more pressing) issues.
The process isn't fluid enough for designers to work with, so the design has suffered without our input.
By giving designers access to the template files, we (designers) might just find a better way of doing things that could benefit Moodle for the long term.
Right, the more you ask for here, which you did not ask for in your blog, is exactly what Urs is asking for.
I don't think Joomla (sorry, Joomla!) is a good comparison for Moodle. I was investigating it today to see what I could learn, and the answer was not much. Some conclusions:
* Whoever thought of calling it Joomla! should be shot. No, that is too good for them! If I see another exclamation mark I am going to scream! More to the point, it really hurts the readability of documentation to have random punctuation in the middle of sentences.
* Oh, and I really hope that Moodle Docs comes across better to a newcomer than the Joomla documentation wiki does. If I see another stub page, I am going to scream some more.
OK, I'll be sensible now ...
When I say Joomla is not a good comparison for Moodle, what I mean is that, from what I could see, if you take Moodle, throw away everything except blocks, and then add the blocks and themes enhancements that I am proposing for Moodle 2.0, then you are very close to Joomla. (That is a very rough approximation.) The one thing that the front end of a Joomla site does not have much of is interaction. Moodle has a lot of it.
Themeing a Joomla site is mostly about making templates for a lot of fairly static content. Then behind the scenes there is a whole lot of editing User interface that most people don't bother to theme, because only admins ever see it, although it can be templated if you want. (Can I just make it clear, this is not a criticism of Joomla. Joomla is trying to be a content management system, and it provides the features required for that.)
But Moodle does have a lot of interaction, and with its social constructivist roots, many more people are use the editing interfaces, so we have to care more about those. Templating in interactive interface is much harder than templating a relatively static one. Particularly when you want to include Ajax to improve usability, which we do. Question: Does the JavaScript code belong to the logic or presentation layer? What about when is making a HTTP request? What about when it is outputting HTML? Does trying to split JS between two layers of the application really help anyone?
So, please stop quoting Joomla as an example. I mean, come on, it does not even seem to offer a forum, just an integration with PHPBB. (How is that themed?) And even I might concede that a forum might be relatively easy to template. What do you need? Forum listing, Thread, Single post and Reply form templates.
Hmm. until you remember that forum posts also have to be output in plain text and HTML emails, both single and digest. And then there are the bits of interface for managing subscribers, and reviewing ratings, ... Is anything easy?
Drupal is a much better comparison, for several reasons. First, Drupal's traditional emphasis on community building, rather than just content management, has a rather Social Constructivist flavour. Second, and probably as a result, there are rather more interactive tools integrated into Drupal.
I do quite like the way that Drupal tries to shove all output through a theme() function - and then there are Drupal theme engines that turn calls to theme() by a developer into the rendering of a template created by a designer. I think it is worth looking into that a bit more to see if we could adapt the idea to Moodle. That might lead to solution that is tolerable to developers, while letting designers do what they want.
When, in my proposals, I talk about turning weblib.php into a class that themes could then override - Well, in Drupal language you would say the theme engine does the overriding, individual themes might not need to bother. Anyway, when I talk about classes and subclasses, you could think of that as trying to take the drupal theme() function and fit it in to Moodle.
(The thing is that the makers of Drupal refuse to use the 'class' keyword (I think because they were trying to come up with an elegant architecture in PHP 4), so they use their strange an mind-bending concept of hooks to effectively re-implement object oriented design without using PHP classes.)
Hmm. I seem to be rambling. What else do I want to say?
Oh yes, of the various difficulties I mentioned with templates in my post above, the one that worries me most is 4. I really hate duplication in code of whatever form, even it it is template code. Dear template advocates, how do you propose to avoid that?
I know one way of avoiding it. That is what Martin Fowler, in Patterns of Enterprise Application Architecture, calls Two step view.
To my mind Moodle comes quite close to implementing that already, although is a rather bizarre way. The first stage is in a rather strange form. It is the sequence of function calls print_header, print_heading, print_box, in whatever PHP script is running. That defines the high-level, structural form of the output. Then phase two is weblib, which turns those function calls into HTML. One of the bizarre things is that we have hard-coded weblib. We don't let themes have any control of what HTML is generated. That is stupid and easy to change. It is the other reason I want to make weblib into a class that theme (engines) can subclass.
And, of course, that view is very much looking through rose-tinted spectacles, because in our step one code we have mixed in direct echoing of strings and HTML tags. Oh, and then there are other bits of code like formslib and tablelib that implement Two step view, but in a different way.
Anyway, I think Two step view is a good pattern for Moodle. To quote Martin Fowler: "If you have a Web application with many pages, you often want a consistent look and organization to the site. ... Two Step View deals with this problem ...". I think that exactly describes the situation in Moodle with all its different modules. But, Two step view means that the overall structure of the content is determined at a higher level than where the HTML is generated, so is not amenable to web designers who want to edit the kind of templates used in many other PHP applications. You have to work at a higher level of abstraction. Which may not be what you want to hear.
I think I really must stop rambling now.
I don't think Joomla (sorry, Joomla!) is a good comparison for Moodle. I was investigating it today to see what I could learn, and the answer was not much. Some conclusions:
* Whoever thought of calling it Joomla! should be shot. No, that is too good for them! If I see another exclamation mark I am going to scream! More to the point, it really hurts the readability of documentation to have random punctuation in the middle of sentences.
* Oh, and I really hope that Moodle Docs comes across better to a newcomer than the Joomla documentation wiki does. If I see another stub page, I am going to scream some more.
OK, I'll be sensible now ...
When I say Joomla is not a good comparison for Moodle, what I mean is that, from what I could see, if you take Moodle, throw away everything except blocks, and then add the blocks and themes enhancements that I am proposing for Moodle 2.0, then you are very close to Joomla. (That is a very rough approximation.) The one thing that the front end of a Joomla site does not have much of is interaction. Moodle has a lot of it.
Themeing a Joomla site is mostly about making templates for a lot of fairly static content. Then behind the scenes there is a whole lot of editing User interface that most people don't bother to theme, because only admins ever see it, although it can be templated if you want. (Can I just make it clear, this is not a criticism of Joomla. Joomla is trying to be a content management system, and it provides the features required for that.)
But Moodle does have a lot of interaction, and with its social constructivist roots, many more people are use the editing interfaces, so we have to care more about those. Templating in interactive interface is much harder than templating a relatively static one. Particularly when you want to include Ajax to improve usability, which we do. Question: Does the JavaScript code belong to the logic or presentation layer? What about when is making a HTTP request? What about when it is outputting HTML? Does trying to split JS between two layers of the application really help anyone?
So, please stop quoting Joomla as an example. I mean, come on, it does not even seem to offer a forum, just an integration with PHPBB. (How is that themed?) And even I might concede that a forum might be relatively easy to template. What do you need? Forum listing, Thread, Single post and Reply form templates.
Hmm. until you remember that forum posts also have to be output in plain text and HTML emails, both single and digest. And then there are the bits of interface for managing subscribers, and reviewing ratings, ... Is anything easy?
Drupal is a much better comparison, for several reasons. First, Drupal's traditional emphasis on community building, rather than just content management, has a rather Social Constructivist flavour. Second, and probably as a result, there are rather more interactive tools integrated into Drupal.
I do quite like the way that Drupal tries to shove all output through a theme() function - and then there are Drupal theme engines that turn calls to theme() by a developer into the rendering of a template created by a designer. I think it is worth looking into that a bit more to see if we could adapt the idea to Moodle. That might lead to solution that is tolerable to developers, while letting designers do what they want.
When, in my proposals, I talk about turning weblib.php into a class that themes could then override - Well, in Drupal language you would say the theme engine does the overriding, individual themes might not need to bother. Anyway, when I talk about classes and subclasses, you could think of that as trying to take the drupal theme() function and fit it in to Moodle.
(The thing is that the makers of Drupal refuse to use the 'class' keyword (I think because they were trying to come up with an elegant architecture in PHP 4), so they use their strange an mind-bending concept of hooks to effectively re-implement object oriented design without using PHP classes.)
Hmm. I seem to be rambling. What else do I want to say?
Oh yes, of the various difficulties I mentioned with templates in my post above, the one that worries me most is 4. I really hate duplication in code of whatever form, even it it is template code. Dear template advocates, how do you propose to avoid that?
I know one way of avoiding it. That is what Martin Fowler, in Patterns of Enterprise Application Architecture, calls Two step view.
To my mind Moodle comes quite close to implementing that already, although is a rather bizarre way. The first stage is in a rather strange form. It is the sequence of function calls print_header, print_heading, print_box, in whatever PHP script is running. That defines the high-level, structural form of the output. Then phase two is weblib, which turns those function calls into HTML. One of the bizarre things is that we have hard-coded weblib. We don't let themes have any control of what HTML is generated. That is stupid and easy to change. It is the other reason I want to make weblib into a class that theme (engines) can subclass.
And, of course, that view is very much looking through rose-tinted spectacles, because in our step one code we have mixed in direct echoing of strings and HTML tags. Oh, and then there are other bits of code like formslib and tablelib that implement Two step view, but in a different way.
Anyway, I think Two step view is a good pattern for Moodle. To quote Martin Fowler: "If you have a Web application with many pages, you often want a consistent look and organization to the site. ... Two Step View deals with this problem ...". I think that exactly describes the situation in Moodle with all its different modules. But, Two step view means that the overall structure of the content is determined at a higher level than where the HTML is generated, so is not amenable to web designers who want to edit the kind of templates used in many other PHP applications. You have to work at a higher level of abstraction. Which may not be what you want to hear.
I think I really must stop rambling now.
Well it's good that you have something good to say about Drupal - you have obviously used it more than Joomla because most of that "rambling" was rather subjective view - your opinion - and nothing more serious. Joomla does have quite many extensions http://extensions.joomla.org/ that you have never used - correct?
If you look closer you notice that both in Joomla and Drupal you can change Forum - there are several Forum programs that can be used - why should it be "build-in" like in moodle? In addition to huge variety of nice looking themes you can change hundreds of thing you can never dream of doing in moodle. It's called a flexible modular structure.
"* Oh, and I really hope that Moodle Docs comes across better to a newcomer than the Joomla documentation wiki does. If I see another stub page, I am going to scream some more." - You certainly need to hope this because guides and whole Joomla documentation are in my opinion very well written - they are easy to read for beginners and I really don't understand how you can find so much negative things about excellent Content Management System that was never ment to be a Learning Management System like moodle.
Running down other software without knowing it at all is not wise - and moodle is the best ever open source LMS on Earth although it is not perfect...
I have not really used either software. For both I have read some of their documentation and look at how some of their code works in order to learn a bit about how they solve the problem what we are contemplating in the context of Moodle. I am aware that is likely to be a superficial knowledge.
On the other hand, making a theme is something that you are likely to want to do quite soon after first encountering a piece of software, so how comprehensible the theming system is to a newcomer is interesting.
In my post, I chose to express my feeling about the Joomla documentation, in a not terribly serious way. I found it very cathartic, thank you very much.
Then separately, I made exactly the point that Joolma is a content management system that achieves it goals, but that is not a Learning Management System, so just because a particular software design technique works in Joomla does not mean that it would work in Moodle.
I don't think that is running down Joomla.
On the other hand, making a theme is something that you are likely to want to do quite soon after first encountering a piece of software, so how comprehensible the theming system is to a newcomer is interesting.
In my post, I chose to express my feeling about the Joomla documentation, in a not terribly serious way. I found it very cathartic, thank you very much.
Then separately, I made exactly the point that Joolma is a content management system that achieves it goals, but that is not a Learning Management System, so just because a particular software design technique works in Joomla does not mean that it would work in Moodle.
I don't think that is running down Joomla.
All good points, Tim.
Watch this quicktime video about easy-to-use theme properties administration, please - I really prefer this kind of systems
In my opinion we don't actually need templates but I don't mind if Urs has found a nice way to implement them.
Oh, one more (last) example from Joomla, Tim - but you MUST check this http://help.joomla.org/ghop/feb2008/task167/index.html and for example http://help.joomla.org/ghop/feb2008/task167/modules.html
It's GHOP material and the link to this page is found from the second row of http://docs.joomla.org/Beginners
demo.rockettheme.com seems dead at the moment. Surely the Moodle Themes forum is not powerful enough to invoke the slashdot effect?
And I was not looking for beginner end-user documentation. I was looking for Theme information, starting from http://docs.joomla.org/Joomla!_1.5_Template_Tutorials_Project, which Julian Ridden sent me; and developer documentation.
And I was not looking for beginner end-user documentation. I was looking for Theme information, starting from http://docs.joomla.org/Joomla!_1.5_Template_Tutorials_Project, which Julian Ridden sent me; and developer documentation.
Thank you for your time, Tim.
It might have been some temporal peak... anyway I checked yesterday http://docs.moodle.org/en/Student_projects/Customisable_theme and http://tracker.moodle.org/browse/CONTRIB-516 which is marked resolved - Akshit Sharma did finish that student project (customizable theme)
We have of course the great Chameleon too but I think I'll try to do something useful for a while and try to implement similar theme/color picker system as you see in http://demo.rockettheme.com/feb09/video/colorchooser.mov (I took the link away because this is mov file) to moodle theme
It may take a month anyway...
I definitely think themes should be able to have a settings page in the admin tree, like most other plugins can now. (And we will need to implement an admin_setting_colour setting type.) That should be relatively easy to do - just look at how settings.php files work for other sorts of plugin.
Yes, it's easy to set common administration and settings for all themes - but we usually need different settings for each theme (unless site uses only one default theme)
This is the same problem as administration of custom editors - you can create a site wide administration for settings of editor or you can create "editor profile" or separate configuration (init code) for each editor - even several configurations for each one.
I think I'll let themes to select their properties and test a custom theme administration - or test a site wide setting page that creates a theme profile like user profiles.
I think this "advanced administration of settings" is relatively easy to do for header, footer and side blocks - other parts may cause more trouble...
Like always - the only way to get somebody to test the result is to write code of this test theme so that other parts of moodle are not changed - therefore I don't touch the core files unless I have no other alternative.
The ability to include theme settings into the Moodle front end would be helpful.
Would it be possible to include an admin page that looks inside the selected theme folder for a file (XML perhaps?) that contains the different settings for that theme?
If no such file exists in the theme, then the output could just be something like "this theme contains no advanced settings."
Would it be possible to include an admin page that looks inside the selected theme folder for a file (XML perhaps?) that contains the different settings for that theme?
If no such file exists in the theme, then the output could just be something like "this theme contains no advanced settings."
Theme admin.php that allows administrators (or other people with proper capability) to change settings of theme but nothing more...
Patrick, I must create some test versions first - it's a small task compared to those changes that Tim and Urs are creating.
Mauno, please, before you go and re-invent the wheel, take my hint and look at how this works for other sorts of plugins. You typically have a settings.php file in the plugin, and there is a little bit of code to include that in the admin menu at an appropriate point.
This is even documented: Development:Admin_settings.
This is even documented: Development:Admin_settings.
I will, thank you. I did not test any new code during the weekend but checked some examples how others created the administration of settings for other cases.
Since the whole discussion started from a need to use tableless layout I found this web page from 2003 amusing http://www.hotdesign.com/seybold/everything.html
Still CSS can't do everything so it's really great that we have people like you, Tim and Urs creating those new ideas for core code of moodle.
Patrick,
"b.) seeing a lot of great design inspiration that will never make it's way into a Moodle theme since it's simply not possible."
Some people tend to say "Anything is possible"
Seriously I think most of that great design inspiration can be done in moodle too but it may take some years to make it possible. 
Keep up your good work, Patrick, and keep dreaming!!!
Hi Patrick,
your clear statements are surely helpful. The discussions started to look as if I am the only one arguing for flexible design for Moodle.
People not deeply involved in design and confronted with design related needs may have difficulties to understand what we talk about. We few need to shout a bit louder to make ourself heard
Thank you, Urs. I apologize for not joining in earlier and will do my best to keep posting whenever appropriate.
This is an important issue and I appreciate how hard you've been pressing for it. Thank you!
This is an important issue and I appreciate how hard you've been pressing for it. Thank you!
During the discussions about the possibility to change Moodle's visual presentation to meet educational and/or corporate design needs the importance of visual flexibility of the learning environment I work with became clear to me.
During the last years I investigated a lot of work to evolve Moodle visually
- present a CSS concept and help to implement it for Moodle 1.5
- create and help to implement custom_corners to offer a base for a more modern web 2.0 look
- create and help to enhance the moodle2 theme moodle.org uses since 2009.
- create and implement templates in my lab environment as a prove of concept that I get the needed flexibility with Moodle
Aspect 4. is the necessary next step for me and probably some other people (for example Patrick, Bernhard) to be able to continue working with Moodle.
I need to stop creating work-arounds for Moodle deficits but investigate in enhancing the look and feel of the learning environment.
Standing at a crossroad
I am very serious about my work and the next steps to achieve the goals I need to reach.
- If it will be possible to flexible design the learning experience with Moodle I can continue to use and suggest Moodle.
- If the needed flexible design opportunities will not be offered in Moodle I will need to go another way.
DrupalEd is a promising project. I did some researches during the last days. Design flexibility is build in. Social engagement is better implemented than in Moodle. Drupal needs some learning tools. I am relatively sure that with some support SCORM and some gradebook can be implemented/enhanced. Then many companies/institutions looking for a learning environment get what they need: learning and design.
What's next?
Tim's Moodle docs article from today Development:Theme engines for Moodle? looks very promising. Tim you get my +1p (all if I may be able to spend more points) and a big thank you for writing it
Martin's posting "Navigation, Layout, Blocks, Themes and Other Stuff Week!" may bring the topics to a broader audience.
I have been really frustrated the last days that all the time and effort I have spent in the last few month to help Moodle evolve in a flexible design direction may have been a waste of time. The flexibility which is urgently needed by the market I work in. Today I see hope on the horizon based on Tim's article and Martin's posting.
We will see if I can continue to go the Moodle way - I would much appreciate it. But a bit more flexibility is not the way to go. Either Moodle becomes truly flexible or not.
Eureka! (well, I hope so anyway).
Development:Theme engines for Moodle?
(I will refrain from posting a picture of me leaping naked out of the bath)
Development:Theme engines for Moodle?
(I will refrain from posting a picture of me leaping naked out of the bath
This looks good, Tim. Thank you for putting so much time and effort into creating this proposal.
It's a little technical, though, so please let me know if I understand things correctly.
I have yet to fully dive into your posts regarding blocks layout and navigation. I think I'll save this light reading for the weekend!
Thanks again for your work.
It's a little technical, though, so please let me know if I understand things correctly.
- By default, all themes will continue to work as they always have and use a core rendering engine to layout the page.
- If specified in config.php, a theme can choose to use a separate rendering engine that will look for templates
- A theme can set a parent template that is different from its parent theme. For example, a theme could use the standard theme CSS, and Custom Corners templates.
- We're going to start small. Only a few pages will be templated in 2.0. As we move forward, and the community needs/makes them, the number of pages that can use templates will grow.
- There will be some pages that, due to their nature, will be "untemplatable."
- Templates could potentially be applied to all blocks, modules, course pages, login, etc.
I have yet to fully dive into your posts regarding blocks layout and navigation. I think I'll save this light reading for the weekend!
Thanks again for your work.
That is a very good summary, just two bits I would adjust:
3. No, I was assuming a single parent theme for everything. Surely the CSS depends on the HTML, so it would not make sense to take CSS from a theme with different templates. However, this is a detail of the design that could be changed later. One of the points of the design is to give themes the freedom to do whatever they like without the rest of the code being affected.
5. Well this is one of the questions that we have been debating. Is it always possible to strictly separate presentation from logic. We won't really know until we get there and try. Better to say 'There may ...'
3. No, I was assuming a single parent theme for everything. Surely the CSS depends on the HTML, so it would not make sense to take CSS from a theme with different templates. However, this is a detail of the design that could be changed later. One of the points of the design is to give themes the freedom to do whatever they like without the rest of the code being affected.
5. Well this is one of the questions that we have been debating. Is it always possible to strictly separate presentation from logic. We won't really know until we get there and try. Better to say 'There may ...'
Tim,
You have written a solution that is most useful for all parts of moodle. For example in editor system - in my first tests two years ago I moved functions print_textarea, use_html_editor and print_editor_config from weblib.php to theme meta.php because it seemed to be the only reasonable way to "liberate" those functions to free use of other than default editor - fckeditor, tinymce and xinha needed totally different functions that HTMLArea. Then Mathieu and people in OU made a lot of work to find another route... and if that wiki page had been there 2 years ago it would have saved a huge amount of our work.
That proposal is worth of 10000 points!
I have played around with theming and in response to the original question, it took me 3 weeks to build on the work of another the first time I did a custom theme and that was pretty basic. Now I can generate a good match to a school site in 1-2 days but there is a learning curve in the process. I would also comment that you don't have to going to an outside host for a theme is like going to an IT guy for digital art. You'll get something and if you are lucky it will be OK. It makes more sense to go to the themes list find something you like and contact that designer if you don't want to DIY.
I'd like to draw the attention to related important aspect of theming (IMO):
"Semantic DIV IDs?"
http://moodle.org/mod/forum/discuss.php?d=121398
Any input appreciated!
Cheers,
Frank
"Semantic DIV IDs?"
http://moodle.org/mod/forum/discuss.php?d=121398
Any input appreciated!
Cheers,
Frank
Hi everyone!
First of all let me say that although I'm just starting with moodle, I'm a web developer who seeks usability but also some design to meets clients expectations.
I believe Moodle to be great as LMS and that's why I want to use it. It isn't certainly the most eye catching LMS ( starting at the 3 collumns layout and ending at the menus feel and presentation) but it ds it's job very welll and for that we have to thank the community and developers.
If I understood correctlyin current moodle version (1.9) the styling for the top header and footer is made by the theme and the rest is delieverd by moodle core, right?
Well althought I really apretiate all your efforts for giving users a better control over moodle style in the next version I would trather not to wait and instead work on moodle as it is (even if I have to work with the core for a while).
So my questions are:
1 - Is it possible in anyway to change the look of the menus? Per example converting the current menus to horizontal ones like seen in regular webpages having the submenus only open on mouse over? Where should I start to look at this?
2 - How and where can I style blocks and the main content section?
3 - Is it possible to remove one of left column containing the menu and make it dissapear? How can I tell the blocks to move from left to right collumn per example?
Sorry if this are lame questions but I would really appreciate if someone could point me into the right direction.
P.S. I know that the core code will be updated but I belive that with the old diff and a lots of patience I can do it.
Best wishes,
João Campos
First of all let me say that although I'm just starting with moodle, I'm a web developer who seeks usability but also some design to meets clients expectations.
I believe Moodle to be great as LMS and that's why I want to use it. It isn't certainly the most eye catching LMS ( starting at the 3 collumns layout and ending at the menus feel and presentation) but it ds it's job very welll and for that we have to thank the community and developers.
If I understood correctlyin current moodle version (1.9) the styling for the top header and footer is made by the theme and the rest is delieverd by moodle core, right?
Well althought I really apretiate all your efforts for giving users a better control over moodle style in the next version I would trather not to wait and instead work on moodle as it is (even if I have to work with the core for a while).
So my questions are:
1 - Is it possible in anyway to change the look of the menus? Per example converting the current menus to horizontal ones like seen in regular webpages having the submenus only open on mouse over? Where should I start to look at this?
2 - How and where can I style blocks and the main content section?
3 - Is it possible to remove one of left column containing the menu and make it dissapear? How can I tell the blocks to move from left to right collumn per example?
Sorry if this are lame questions but I would really appreciate if someone could point me into the right direction.
P.S. I know that the core code will be updated but I belive that with the old diff and a lots of patience I can do it.
Best wishes,
João Campos
Hi João,
Themes FAQ might be a good starting point for finding information on modifying and creating themes.
Cheers,
Frank
Themes FAQ might be a good starting point for finding information on modifying and creating themes.
Cheers,
Frank