Just curious here, but how is the theme project different from the Chameleon theme?
I've done some work myself toward this, at http://magic.simpler.ca/ which is why I thought such a project would be a good fit for me, but I don't want to re-invent the wheel.
I've lots of other ideas for projects, however. And I can see how a few of the "proposed" projects would be good ideas. Somehow the two RSS ones aren't as appealing to me, though. I can't see my friends at university using RSS that much, let alone the faculty. Everyone here is used to email, at minimum, and RSS doesn't seem to offer that much more over email, if its meant to be private.
How is Theme project different from the existing Chameleon theme?
by Louis St-Amour -
Number of replies: 44
In reply to Louis St-Amour
Re: How is Theme project different from the existing Chameleon theme?
by Louis St-Amour -
Sorry, it seems the link (magic.simpler.ca) won't work for 12+ hours, as my web host, DreamHost, is moving the server cluster I'm on to a new location.
Sigh.
Well, to describe the page, I'm using jQuery UI to drag-and-drop colours from Adobe Kuler's RSS feed API to apply to different parts of the page. I also added a JavaScript colour contrast detection function to compare colours (I found it online, the credit's in the source code comments, which are of course unavailable) and used that to determine whether white or black text would look better against one colour or another.
Also, a bit about me: I'm a first-year student at York University in Toronto, Canada. I'm 22, very involved in web design and interested in UX (User Experience) design in general. I work for the Faculty of Arts here at York, as a Student Technology Assistant.
We use Moodle, but honestly, we're not that updated or hip with this stuff. Most courses are powered via Dreamweaver templates and Contribute. I'd really like to get more involved in Moodle and other ways to enhance learning with a student- or faculty-focus, but work isn't quite oriented that way. So I'm hoping helping out via GSOC will counter-balance the "realistic" perspective I have from work.
One idea I had was to turn Moodle into something closer to a CMS that understands educational items like Syllabuses and Reading lists. It would try to emulate existing websites, perhaps even offer a way to import them raw, and then add links to them for quizzes, etc. As in, one day faculty would visit their website like normal, and they'd see a sign-in link, offering the ability to add quizzes or edit their site in-line, etc. The idea is that you would try to work within how people already use the internet to share course materials, rather than upset the current methods by forcing a new three-column layout on things, with functions they won't use right now.
Sigh.
Well, to describe the page, I'm using jQuery UI to drag-and-drop colours from Adobe Kuler's RSS feed API to apply to different parts of the page. I also added a JavaScript colour contrast detection function to compare colours (I found it online, the credit's in the source code comments, which are of course unavailable) and used that to determine whether white or black text would look better against one colour or another.
Also, a bit about me: I'm a first-year student at York University in Toronto, Canada. I'm 22, very involved in web design and interested in UX (User Experience) design in general. I work for the Faculty of Arts here at York, as a Student Technology Assistant.
We use Moodle, but honestly, we're not that updated or hip with this stuff. Most courses are powered via Dreamweaver templates and Contribute. I'd really like to get more involved in Moodle and other ways to enhance learning with a student- or faculty-focus, but work isn't quite oriented that way. So I'm hoping helping out via GSOC will counter-balance the "realistic" perspective I have from work.
One idea I had was to turn Moodle into something closer to a CMS that understands educational items like Syllabuses and Reading lists. It would try to emulate existing websites, perhaps even offer a way to import them raw, and then add links to them for quizzes, etc. As in, one day faculty would visit their website like normal, and they'd see a sign-in link, offering the ability to add quizzes or edit their site in-line, etc. The idea is that you would try to work within how people already use the internet to share course materials, rather than upset the current methods by forcing a new three-column layout on things, with functions they won't use right now.
In reply to Louis St-Amour
Re: How is Theme project different from the existing Chameleon theme?
by Mauno Korpelainen -
Nice scripts, Louis!
They seem to work ok in Firefox, Safari and Opera but not in IE7 - some IE specific bug maybe (Theme is not defined...)
As far as I understood the customisable theme ( http://docs.moodle.org/en/Student_projects - Mentor: Shane Elliott ) that includes a configuration page should have some preset options that users can select (like colors on your site), it should be a little bit similar as Chameleon theme but administrators should be able to allow also users to select some properties to their user theme (but not edit css). Something between Chameleon, http://www.yvoschaap.com/wpthemegen/ and http://www.bbc.co.uk/home/
In reply to Mauno Korpelainen
Re: How is Theme project different from the existing Chameleon theme?
by Ger Tielemans -
To answer your question about theme Project and Chameleon.
There is no relation between theme project and chameleon. To make it more complex. There is a theme project AND a modul project. Modul project is a very rich modul to handle rather complex project activities. You can find information on the modules & plugin pages of Moodle.
You can see Theme Project as a child of the parents topic theme and week theme. How it works:
- choose project theme and set the number of sections you need
- in first view you will have a topic view course with an empty gantt chart in section zero.
- then you can "Turn" each topic card and "change it" into a project peiod card by setting the start date, end date and the deliverables with their milestones.
- only activiteis count as deliverables with milestones
- The gantt chart in section zero echoes the periods and the milestones
- The gantt chart also echoes the status of the milestones:
- it offers a visible ointer for today in the gantt chart
- it colors the to late deliverables red inthe chartt
- You can keep topic cards between the period cards with other course releated stuff
- you can paste other activties and resources in the project perid cards without disturbing the view on the milestones in the gantt chartt.
I love this theme for the elegant solution it offers for such complex activitity as a "my first project approach."
On this moment the code is broken for 1.7 1.8 and 1.9. The maker of the theme is still using Moodle 1.6 and is not working on the repair for the higher releases. We are working on a workaround and have it almost solved now for 1.8 and 1.9 BUT without adding the new roles models: that needs a complete rebuild with knowledge of the role-engine.. Something for a summer of code?
In reply to Ger Tielemans
Re: How is Theme project different from the existing Chameleon theme?
by Mauno Korpelainen -
I'm perplexed.
In reply to Ger Tielemans
Re: How is Theme project different from the existing Chameleon theme?
by Mauno Korpelainen -
Ger,
I thought Louis asked about http://docs.moodle.org/en/Student_projects#New_customisable_theme
In reply to Mauno Korpelainen
Re: How is Theme project different from the existing Chameleon theme?
by Louis St-Amour -
Yes, that was what I was asking about. Though what he wrote did sound interesting, it doesn't seem to match the earlier desc. I'd be willing to work on other ideas, of course. I was hoping to clarify the approved one first though and hear back from the mentor as well ...
In reply to Louis St-Amour
Re: How is Theme project different from the existing Chameleon theme?
by Ger Tielemans -
I see, you are right, I missed that page in this overcrowded information sea. I was triggered by the word project
Interesting project, yes.
In reply to Mauno Korpelainen
Re: How is Theme project different from the existing Chameleon theme?
by Martin Dougiamas -
Yeah, the idea is to make it very SIMPLE for people to add a logo, some colours and perhaps tweak the header and footer a bit. It's all about usability for those not inclined to dive into CSS and HTML.
In reply to Martin Dougiamas
Re: How is Theme project different from the existing Chameleon theme?
by Tim Hunt -
Isn't this project about copying the idea the 'Garland' theme that was introduced in Drupal 5? Screenshot here: http://buytaert.net/garland. It gives admins a simple configuration page to make a theme with their own choice of colours, and an uploaded logo, and it looks really, really nice.
In reply to Tim Hunt
Re: How is Theme project different from the existing Chameleon theme?
by Martin Dougiamas -
Fantastic, that should save us some time! 
Making it our new default sounds like a good idea too.
In reply to Martin Dougiamas
Re: How is Theme project different from the existing Chameleon theme?
by Louis St-Amour -
Drupal was what I was thinking of when I first saw this project.
Lately, though, I've been wondering if perhaps a better approach would be to try and work with an existing theme of some kind - e.g. many universities and other organizations have existing web templates and standards to follow. It would perhaps then be nice if a theme could be "generated" based on a template HTML file of some kind. Perhaps you could interactively drag and drop the required Moodle elements into the theme. Or a new way of looking at courses, so that they feel more like traditional webpages rather than three-column CMS busy-ness.
I feel so inspired after seeing designs like "future vision: Microsoft knowledge-driven health" concept video, which you can
So yes, this is terribly exciting stuff for me, and all I can think of is how I'd love to see Moodle on my iPod Touch, in context. For example, as the week progresses, it could highlight various assignments or things I've told myself to study or read. And in-class, I could see just what's relevant to that class, along with any related sources I might need during discussions, or perhaps a spot to take notes during lectures. Suddenly, Moodle feels more like a trusted home for my studies and interactions with classmates, a place that encourages me to do better and organize my studies, rather than a website with all the functionality but none of the focus context can provide.
Moodle right now feels designed for the professor posting information, not the student trying to learn such information. How else to explain how natural the interface feels when signed in as a professor, and how odd it feels when signed in as a student? If you're not given the flexibility to change topic or week content for a course, all you see is a button to show one topic or many inside the topics. That's more confusing than helpful, I would argue. And do students really think like that, one topic or week at a time? Myself, I find I always need to hunt for something, and there are things I know and things I don't know. I wish I could just group together stuff naturally, and set goals to study material.
Another problem is that Moodle is in some ways too strict. It assumes you already know the system, and it prefers a three-column layout, with different role levels and few individual customizations. To that end, it reproduces a university-stye environment online, where everyone is stuck with the same system. Why not allow for personal creativity?
And I think multi-class interaction also needs work, from a student perspective. I generally think of all my classes at once when considering what work to do, and it irritates me that only some of my classes use Moodle. It should be easier for students to create their own private Moodle sessions, where other professors haven't done so already. Perhaps by seeing such content, or by using Moodle for study groups, this could then encourage further growth on campus within classroom settings. But Moodle still feels too institutional for such consumeristic influence.
To me, a new theme, and a new way of looking at some aspects of Moodle would go a long way to perhaps solving the above problems. Assuming, of course, that they are problems in current versions of Moodle ... the one York University uses right now is 1.8, and 1.6, so ... perhaps 2.0 has a lot more flexibility in this regard. But even so, there's likely room for improvement.
Do you think any of this is ripe for inclusion within my Summer of Code proposal for the Theme project? Or should I perhaps think it through more, and submit it as a separate application? Or mention this as what I might get started on, after working on a Drupal-style Moodle theme? :p
Comments? Questions? Love the Microsoft video?
Lately, though, I've been wondering if perhaps a better approach would be to try and work with an existing theme of some kind - e.g. many universities and other organizations have existing web templates and standards to follow. It would perhaps then be nice if a theme could be "generated" based on a template HTML file of some kind. Perhaps you could interactively drag and drop the required Moodle elements into the theme. Or a new way of looking at courses, so that they feel more like traditional webpages rather than three-column CMS busy-ness.
I feel so inspired after seeing designs like "future vision: Microsoft knowledge-driven health" concept video, which you can
. The original is from a MIX 08 presentation by Daniel Makoski, the Interaction Design Manager for Microsoft Surface. You can see the video at 0:19:10 of his presentation, although the quality isn't that much better, so don't bother, unless you want to hear more about "Natural User Interfaces" and "Designing for Experiences".
So yes, this is terribly exciting stuff for me, and all I can think of is how I'd love to see Moodle on my iPod Touch, in context. For example, as the week progresses, it could highlight various assignments or things I've told myself to study or read. And in-class, I could see just what's relevant to that class, along with any related sources I might need during discussions, or perhaps a spot to take notes during lectures. Suddenly, Moodle feels more like a trusted home for my studies and interactions with classmates, a place that encourages me to do better and organize my studies, rather than a website with all the functionality but none of the focus context can provide.
Moodle right now feels designed for the professor posting information, not the student trying to learn such information. How else to explain how natural the interface feels when signed in as a professor, and how odd it feels when signed in as a student? If you're not given the flexibility to change topic or week content for a course, all you see is a button to show one topic or many inside the topics. That's more confusing than helpful, I would argue. And do students really think like that, one topic or week at a time? Myself, I find I always need to hunt for something, and there are things I know and things I don't know. I wish I could just group together stuff naturally, and set goals to study material.
Another problem is that Moodle is in some ways too strict. It assumes you already know the system, and it prefers a three-column layout, with different role levels and few individual customizations. To that end, it reproduces a university-stye environment online, where everyone is stuck with the same system. Why not allow for personal creativity?
And I think multi-class interaction also needs work, from a student perspective. I generally think of all my classes at once when considering what work to do, and it irritates me that only some of my classes use Moodle. It should be easier for students to create their own private Moodle sessions, where other professors haven't done so already. Perhaps by seeing such content, or by using Moodle for study groups, this could then encourage further growth on campus within classroom settings. But Moodle still feels too institutional for such consumeristic influence.
To me, a new theme, and a new way of looking at some aspects of Moodle would go a long way to perhaps solving the above problems. Assuming, of course, that they are problems in current versions of Moodle ... the one York University uses right now is 1.8, and 1.6, so ... perhaps 2.0 has a lot more flexibility in this regard. But even so, there's likely room for improvement.
Do you think any of this is ripe for inclusion within my Summer of Code proposal for the Theme project? Or should I perhaps think it through more, and submit it as a separate application? Or mention this as what I might get started on, after working on a Drupal-style Moodle theme? :p
Comments? Questions? Love the Microsoft video?
In reply to Louis St-Amour
Re: How is Theme project different from the existing Chameleon theme?
by Mauno Korpelainen -
Beautiful scenes of the Future...and not so easy to implement. Separating student view from the current fixed theme structure would be a nice goal. "Simplified flexibility" of themes can really improve usability but you would need some kind of a "skeleton" or flash style time line to add activities to different places without layout restrictions.
In reply to Louis St-Amour
Re: How is Theme project different from the existing Chameleon theme?
by Martin Dougiamas -
Moodle and LMSs in general are mostly an extension of existing institutions onto the web, so it has a lot of assumptions and structures and *control* that come from that. Many institutions are still in our rear view mirror struggling with even the idea of having computers involved in education. So right now, an easy-to-customise theme is a good step.
Some of the kind of stuff I think you are talking about is more the domain of the PC or the mobile computer. You can use them now and customise them now to suit your own learning with different apps. A Moodle site is just where you "visit your school" but that is obviously just one aspect of any person's learning. Moodle doesn't have to do everything.
That said there is a LOT that can be improved about the Moodle interface and it's an increasing focus for me and a lot of other people now. What we need are concrete suggestions, followed by consensus and development. Perhaps you want to help out on a long term basis! http://docs.moodle.org/en/Development
Thanks for the video. I hope that hospital doesn't get a virus!
Some of the kind of stuff I think you are talking about is more the domain of the PC or the mobile computer. You can use them now and customise them now to suit your own learning with different apps. A Moodle site is just where you "visit your school" but that is obviously just one aspect of any person's learning. Moodle doesn't have to do everything.
That said there is a LOT that can be improved about the Moodle interface and it's an increasing focus for me and a lot of other people now. What we need are concrete suggestions, followed by consensus and development. Perhaps you want to help out on a long term basis! http://docs.moodle.org/en/Development
Thanks for the video. I hope that hospital doesn't get a virus!
In reply to Martin Dougiamas
Re: How is Theme project different from the existing Chameleon theme?
by Louis St-Amour -
True. So I'm not totally hung up on designing some super-UI, but it's interesting how right now people are improving things incrementally, like at http://moodle.org/mod/forum/discuss.php?d=92797
Honestly, I don't know enough yet about Moodle Themes to know if larger customizations are possible (such as even removing the three-column layout) but I do think that after getting a theme going, like Drupal's, where you can customize colour and logo easily, the next stage would be to try and mimic or incorporate an existing design.
Considering there are just over 60k of results for a search like "standard web template site:edu" in Google, I suspect I'm not alone in thinking most people would want to start just by applying such a template to Moodle.
Consider this example, from the University of Kansas Medical Center:
It has aspects that you would want to remain static, e.g. 1a, the Masthead and its navigation, it has elements that would be mixed - e.g. 1b, the search box, where Moodle could be added to the existing options - and then has further suggestions for secondary navigation formatting (2), breadcrumb use (3), title (4), body (5) and footer (6).
Perhaps one way forward would be to develop a theme that makes it easier to integrate Moodle within such templates. I imagine Moodle adoption would skyrocket if nobody knew Moodle was running As in, the conversion was done so successfully, people thought it was the same old site, until they saw the option to add quizzes or sign in.
To this end, it would perhaps also benefit from further functionality suggested for GSoC, such as tracking reading list material, which is hard enough to do on current static webpages. And that brings up the idea of integration with library services for e-lookup.
But back to the theme, it would be fantastic if such options could somehow be automatically interpreted based on existing HTML code. So if I were to point the theme at a blank template, I could click on parts and see Moodle fill in the details. So I could select the title area and tell Moodle that's the page title, etc. Or I could just "quick-start" somehow from the HTML, and see steps on how to integrate Moodle further, via source code editing.
Perhaps all people would initially want, beyond specifying colours and logo is to add a standard HTML header and footer, leaving navigation and the rest up to Moodle. That sounds more logical and faster to code, I think. :p
It sounds also as if I'd want to follow closely the discussion and results evolving out of the Usability review project ... at least insofar as this theme could help implement or be affected by its suggestions. Fluid also sounds intriguing. Perhaps I could work on more of the practical suggestions arising from the Usability review, at least where the theme is concerned.
Honestly, I don't know enough yet about Moodle Themes to know if larger customizations are possible (such as even removing the three-column layout) but I do think that after getting a theme going, like Drupal's, where you can customize colour and logo easily, the next stage would be to try and mimic or incorporate an existing design.
Considering there are just over 60k of results for a search like "standard web template site:edu" in Google, I suspect I'm not alone in thinking most people would want to start just by applying such a template to Moodle.
Consider this example, from the University of Kansas Medical Center:
It has aspects that you would want to remain static, e.g. 1a, the Masthead and its navigation, it has elements that would be mixed - e.g. 1b, the search box, where Moodle could be added to the existing options - and then has further suggestions for secondary navigation formatting (2), breadcrumb use (3), title (4), body (5) and footer (6).
Perhaps one way forward would be to develop a theme that makes it easier to integrate Moodle within such templates. I imagine Moodle adoption would skyrocket if nobody knew Moodle was running
To this end, it would perhaps also benefit from further functionality suggested for GSoC, such as tracking reading list material, which is hard enough to do on current static webpages. And that brings up the idea of integration with library services for e-lookup.
But back to the theme, it would be fantastic if such options could somehow be automatically interpreted based on existing HTML code. So if I were to point the theme at a blank template, I could click on parts and see Moodle fill in the details. So I could select the title area and tell Moodle that's the page title, etc. Or I could just "quick-start" somehow from the HTML, and see steps on how to integrate Moodle further, via source code editing.
Perhaps all people would initially want, beyond specifying colours and logo is to add a standard HTML header and footer, leaving navigation and the rest up to Moodle. That sounds more logical and faster to code, I think. :p
It sounds also as if I'd want to follow closely the discussion and results evolving out of the Usability review project ... at least insofar as this theme could help implement or be affected by its suggestions. Fluid also sounds intriguing. Perhaps I could work on more of the practical suggestions arising from the Usability review, at least where the theme is concerned.
In reply to Martin Dougiamas
Re: How is Theme project different from the existing Chameleon theme?
by David Scotson -
If you're thinking of copying the look of Garland it's worth bearing in mind that despite being GPL'd and now available for Wordpress and other CMSs and blog engines, the original Theme developers got a bit peeved because Wordpress took their theme and released it before they had unveiled it along with Drupal 5. They thought of it as an important part of their brand.
Link for reference: http://acko.net/blog/wordpress-com-copies-drupal-theme
Of course that was a while ago now so maybe it's not so much of an issue.
On another tack, I just spent 20 minutes doing a quick and dirty port of Garland to Moodle and there's going to be some major stumbling blocks if the Moodle HTML isn't able to be changed to match what the theme needs.
For example the stretchy middle column with the overlap onto the header and the gradients fading into the white background requires 3 images: a top-left corner, a repeating horizontal background, and a top-right corner. With current IE level CSS support you need 3 containers to attach these to, 9 if you wanted to do things vertically as well (Safari and--probably Opera now/soon--support CSS3 border-image for doing this more easily). You can nearly fudge the horizontal effect with the one and a half containers that exist at the moment but not quite and it's a lot more work even for a less satisfying result.
It would be good if identifying theme issues like that was the subject of a summer of code project. However there's not much to show for your work unless you also fix the identified problems and then create at least one theme that makes use of the fixes and that's probably way, way outside the scope of a summer project.
Link for reference: http://acko.net/blog/wordpress-com-copies-drupal-theme
Of course that was a while ago now so maybe it's not so much of an issue.
On another tack, I just spent 20 minutes doing a quick and dirty port of Garland to Moodle and there's going to be some major stumbling blocks if the Moodle HTML isn't able to be changed to match what the theme needs.
For example the stretchy middle column with the overlap onto the header and the gradients fading into the white background requires 3 images: a top-left corner, a repeating horizontal background, and a top-right corner. With current IE level CSS support you need 3 containers to attach these to, 9 if you wanted to do things vertically as well (Safari and--probably Opera now/soon--support CSS3 border-image for doing this more easily). You can nearly fudge the horizontal effect with the one and a half containers that exist at the moment but not quite and it's a lot more work even for a less satisfying result.
It would be good if identifying theme issues like that was the subject of a summer of code project. However there's not much to show for your work unless you also fix the identified problems and then create at least one theme that makes use of the fixes and that's probably way, way outside the scope of a summer project.
In reply to David Scotson
Re: How is Theme project different from the existing Chameleon theme?
by Martin Dougiamas -
While we can always add more containers if we have to, I don't think we need to restrict ourselves by copying Garland exactly. I was just thinking we'd use the back-end GUI part as inspiration for a Moodle equivalent.
In reply to Martin Dougiamas
Re: How is Theme project different from the existing Chameleon theme?
by David Scotson -
It would be good if the project was to create 2 very different themes. In fact it probably fits the summer of code better if 2 (or even 3) existing themes were ported from a blog or CMS system so that you're not relying on someone having artistic vision as well as image editing, css/html and PHP codings skills.
The core of the project would then be to create the hooks (like multiple containers) necessary to hang different themes on which would hopefully generalise to all themes. Sub-tasks would probably include:
The core of the project would then be to create the hooks (like multiple containers) necessary to hang different themes on which would hopefully generalise to all themes. Sub-tasks would probably include:
- splitting the $meta, $menu, $navigation etc. in the header and footer into something like echo print_css($css) so that the theme developer can decide when, where and if each individual element gets shown and also mess with the raw data before it gets passed into the print function rather than have to replace or deconstruct the HTML output to make changes (which I was doing yesterday to add a category to the navigation breadcrumb)
- doing a grep -r "style=\"" and replacing the 1000 or so hits with either a semantic HTML tag, an #id, one or more .class names, or a mixture of the above as appropriate. This is a task that would be done much better by someone actually trying to port 2 or more actual themes at the same time so they wouldn't just be working in a vacuum. Particularly if one of the ported themes was something like The Sandbox
- similarly removing all the embedded img tags in the code and moving them to the CSS. This would probably have the biggest visual impact for the least work.
- If they're feeling bold they could move all the javascript into the header, and then into external libraries and replace the user, course and category themes with a CSS based equivalent (maybe next summer for that one)
In reply to David Scotson
Re: How is Theme project different from the existing Chameleon theme?
by Louis St-Amour -
What, I can't possibly have design knowledge + programming skills?
I tell ya, it's hard to find a place for someone like me. I think I'll take a Digital Media degree next year, as it's offered jointly by the Faculty of Fine Arts and that of Computer Science & Engineering (CSE) at York. It sounds like a mixture between existing Fine Arts and CSE courses, which suits me much better than having to choose between them.
As for the project idea you mention, it sounds ... interesting. It's more of a theme refactoring. I'm surprised at the lack of flexibility you mention in terms of the HTML output. Obviously I haven't really dug into Moodle enough to figure out its strengths and weaknesses. (I opened up a few files, liked what I saw, but haven't yet changed things much.)
But the rest sounds fine and will likely offer visible speed improvements as browsers can cache external CSS and JS files, and less HTML markup doesn't hurt either. Especially if using classes, where styles can be repeated effortlessly compared to img tags.
I'm up to the challenge.
I tell ya, it's hard to find a place for someone like me. I think I'll take a Digital Media degree next year, as it's offered jointly by the Faculty of Fine Arts and that of Computer Science & Engineering (CSE) at York. It sounds like a mixture between existing Fine Arts and CSE courses, which suits me much better than having to choose between them.
As for the project idea you mention, it sounds ... interesting. It's more of a theme refactoring. I'm surprised at the lack of flexibility you mention in terms of the HTML output. Obviously I haven't really dug into Moodle enough to figure out its strengths and weaknesses. (I opened up a few files, liked what I saw, but haven't yet changed things much.)
But the rest sounds fine and will likely offer visible speed improvements as browsers can cache external CSS and JS files, and less HTML markup doesn't hurt either. Especially if using classes, where styles can be repeated effortlessly compared to img tags.
I'm up to the challenge.
So I was grepping for 'global $THEME' and discovered lib/weblib.php, a "library of all general-purpose Moodle PHP functions and constants that produce HTML output" - it's over 7000 lines!
So I think I'll need to hunt down a good PHP IDE, as I'm worried TextMate won't cut it. Something like Zend's function listing feature would be nice. I wonder if there's a shortcut for that in a Textmate bundle. Either that or I'll just use Eclipse, like everybody else (it seems).
I'm impressed that there's already functionality like 'css constants', such functions might make life a little easier.
-------------------------------------
And so, as I'm starting to write my GSOC application now, I think it's fair to say, then, that the main goal for this "New customisable theme" project is to out-of-the-box encourage Moodle administrators to make Moodle look less like Moodle and more like their existing site or brand - and secondarily, to allow Moodle users the ability to customize the theme also, within possible administrator constraints?
It feels as if, to some extent, we are duplicating the theme system within itself - the custom theme is flexible, but could essentially start holding sub-themes (customizations by or for users).
Perhaps instead we could think of this as something of a theme-creation tool? In which multiple themes can be "generated" and customized? This may provide more flexibility for manual changes, as you wouldn't have to deal as much with configuration code when trying to edit a theme, and it could serve as a kick-start or tutorial system to guide people to creating exactly the look they want.
Although... it's true that as a user, without access to the theme files itself, I might still want to customize a theme, the question is how much customization would be allowed? Most admins might prefer just offering a list of pre-made themes, with generated colours and layouts.
I think where people might want to customize their own theme is if user profile pages and blogs, etc. could have their own theme. Imagine if your forum postings showed up in white-on-black with flowers or stars behind? Themes, at that point, become tools to show your uniqueness to the world.
From an accessibility standpoint, however, allowing font-size changes or minor modifications to the theme does make sense, though.
I also like the idea of revising current themes to clean up the CSS and JS and redundant code, moving them to externally-loading files. But I wonder if perhaps caching theme files, like CSS and JS, might work best for performance, as an option - especially when dealing with CSS constants and other customizations. I'm not sure yet if someone is already working on this, or if there's a builtin caching mechanism, but I haven't seen one yet.
So I think I'll need to hunt down a good PHP IDE, as I'm worried TextMate won't cut it. Something like Zend's function listing feature would be nice. I wonder if there's a shortcut for that in a Textmate bundle. Either that or I'll just use Eclipse, like everybody else (it seems).
I'm impressed that there's already functionality like 'css constants', such functions might make life a little easier.
-------------------------------------
And so, as I'm starting to write my GSOC application now, I think it's fair to say, then, that the main goal for this "New customisable theme" project is to out-of-the-box encourage Moodle administrators to make Moodle look less like Moodle and more like their existing site or brand - and secondarily, to allow Moodle users the ability to customize the theme also, within possible administrator constraints?
It feels as if, to some extent, we are duplicating the theme system within itself - the custom theme is flexible, but could essentially start holding sub-themes (customizations by or for users).
Perhaps instead we could think of this as something of a theme-creation tool? In which multiple themes can be "generated" and customized? This may provide more flexibility for manual changes, as you wouldn't have to deal as much with configuration code when trying to edit a theme, and it could serve as a kick-start or tutorial system to guide people to creating exactly the look they want.
Although... it's true that as a user, without access to the theme files itself, I might still want to customize a theme, the question is how much customization would be allowed? Most admins might prefer just offering a list of pre-made themes, with generated colours and layouts.
I think where people might want to customize their own theme is if user profile pages and blogs, etc. could have their own theme. Imagine if your forum postings showed up in white-on-black with flowers or stars behind? Themes, at that point, become tools to show your uniqueness to the world.
From an accessibility standpoint, however, allowing font-size changes or minor modifications to the theme does make sense, though.
I also like the idea of revising current themes to clean up the CSS and JS and redundant code, moving them to externally-loading files. But I wonder if perhaps caching theme files, like CSS and JS, might work best for performance, as an option - especially when dealing with CSS constants and other customizations. I'm not sure yet if someone is already working on this, or if there's a builtin caching mechanism, but I haven't seen one yet.
Note all CSS output is already designed to be cached by browsers, and pretty much all static Javascript is also already in separate browser-cacheable files.
Hmm. While it may be true that the Javascript and CSS are mostly external, it appears that there's still a ton of inline CSS markup contributing to the slowness of the rendering.
I've just started applying the techniques from High Performance Websites (O'Reilly), in part via YSlow, an addon for FireBug written by Yahoo! people that works in conjunction with the book (It's definitely not a replacement, it's a tool to assist initial inspection and verification of tips explained in further detail in the book)
One tip that is surprisingly useful, is to place all CSS at the top (duh) and all JS at the bottom. I used to think placing JS at the bottom was more myth than practical, but it turns out that while technically the page loads slower, the JS at the top will slow down rendering, whereas placing it at the bottom ensures that the JS executes last, and the page loads "faster" first.
So here's a quick analysis of the Using Moodle homepage:
Note that most of the list above is actually server-side, to some extent. We can control how many HTTP requests are sent, but the host has to have the CDN, not us. However, we can add expires headers to all content, via PHP, instead of forcing the admin to do so via Apache. Stripping ETags and Gzipping everything is something I suspect needs to be configured on the web host's end ... although I've seen some PHP scripts with the option to enable Gzip, so perhaps we can do that too? Where we put CSS/JS is of course up to us, as is Minifying the JS.
So why does paying attention to HTTP requests matter? And why would you perhaps want to spread such requests over 2-4 domain names? That's because according to the HTTP 1.1 spec, a browser should start downloading 2 requests per domain at the exact same time, leading to page loads like the following:
As you can see, having the limit of two means it can take awhile. But if you spread requests over two domains, you can effectively reduce load times by half, as the browser loads 4 items at a time. The book recommends sticking to four domains maximum, likely because any greater than that and your DNS lookups are more expensive than your time savings.
An alternative to doing this, and one we can control from the theme level, is to use image sprites and combine CSS + JS downloads to reduce HTTP requests. As noted, Reducing HTTP requests are Rule #1, as while Gzipping is effective, the fewer Gzipped files, the better.
Of course, reducing the amount of CSS and JS sent inline, and reducing the amount of HTML markup sent, is important as well, since you can cache external files -- or at least clump together the CSS at the top and JS at the bottom instead of putting style and onclick attributes everywhere.
Why does all this matter? As demonstrated within the book, you can easily and simply speed up 80% of your application just by focusing on the frontend experience, rather than backend improvements. Specifically, referring to the earlier image of HTTP requests on Yahoo.com: "In this case, only 5% of the end-user response time is spent fetching the HTML document. This result holds true for almost all web sites. In sampling the top ten U.S. websites, all but one spend less than 20% of the total response time getting the HTML document. The other 80+% of the time is spent dealing with what's in the HTML document, namely, the front-end. That's why the key to faster web sites is to focus on improving front-end performance."
So while I can't fix everything myself within this new Moodle theme, I'll keep it in mind, and work with everyone on following up on possible solutions for these performance concerns. I personally find all this very fascinating, especially to see some of the secrets behind Google and Yahoo's performance techniques.
I applied them to http://magic.simpler.ca/ and the load time went from 5 seconds to 2 seconds.
I've just started applying the techniques from High Performance Websites (O'Reilly), in part via YSlow, an addon for FireBug written by Yahoo! people that works in conjunction with the book (It's definitely not a replacement, it's a tool to assist initial inspection and verification of tips explained in further detail in the book)
One tip that is surprisingly useful, is to place all CSS at the top (duh) and all JS at the bottom. I used to think placing JS at the bottom was more myth than practical, but it turns out that while technically the page loads slower, the JS at the top will slow down rendering, whereas placing it at the bottom ensures that the JS executes last, and the page loads "faster" first.
So here's a quick analysis of the Using Moodle homepage:
Note that most of the list above is actually server-side, to some extent. We can control how many HTTP requests are sent, but the host has to have the CDN, not us. However, we can add expires headers to all content, via PHP, instead of forcing the admin to do so via Apache. Stripping ETags and Gzipping everything is something I suspect needs to be configured on the web host's end ... although I've seen some PHP scripts with the option to enable Gzip, so perhaps we can do that too? Where we put CSS/JS is of course up to us, as is Minifying the JS.
So why does paying attention to HTTP requests matter? And why would you perhaps want to spread such requests over 2-4 domain names? That's because according to the HTTP 1.1 spec, a browser should start downloading 2 requests per domain at the exact same time, leading to page loads like the following:
As you can see, having the limit of two means it can take awhile. But if you spread requests over two domains, you can effectively reduce load times by half, as the browser loads 4 items at a time. The book recommends sticking to four domains maximum, likely because any greater than that and your DNS lookups are more expensive than your time savings.
An alternative to doing this, and one we can control from the theme level, is to use image sprites and combine CSS + JS downloads to reduce HTTP requests. As noted, Reducing HTTP requests are Rule #1, as while Gzipping is effective, the fewer Gzipped files, the better.
Of course, reducing the amount of CSS and JS sent inline, and reducing the amount of HTML markup sent, is important as well, since you can cache external files -- or at least clump together the CSS at the top and JS at the bottom instead of putting style and onclick attributes everywhere.
Why does all this matter? As demonstrated within the book, you can easily and simply speed up 80% of your application just by focusing on the frontend experience, rather than backend improvements. Specifically, referring to the earlier image of HTTP requests on Yahoo.com: "In this case, only 5% of the end-user response time is spent fetching the HTML document. This result holds true for almost all web sites. In sampling the top ten U.S. websites, all but one spend less than 20% of the total response time getting the HTML document. The other 80+% of the time is spent dealing with what's in the HTML document, namely, the front-end. That's why the key to faster web sites is to focus on improving front-end performance."
So while I can't fix everything myself within this new Moodle theme, I'll keep it in mind, and work with everyone on following up on possible solutions for these performance concerns. I personally find all this very fascinating, especially to see some of the secrets behind Google and Yahoo's performance techniques.
I applied them to http://magic.simpler.ca/ and the load time went from 5 seconds to 2 seconds.
Good reflective thinking here.
We've had gzip on and off here recently (search forums for gzip and moodle.org) ... it was switched off recently because there were some performance problems (real and apparent). However some other bottlenecks were recently fixed so I might try it on again for a while.
That inline CSS you pointed out is a special case (it's for the icons in the nav menu) which could not be properly implemented cross-browser using external CSS. You can disable these icons in the theme using: $THEME->navmenuiconshide = true;
For this project it might perhaps help to first think of this theme as a skin, rather than an overhaul of the bones.
We've had gzip on and off here recently (search forums for gzip and moodle.org) ... it was switched off recently because there were some performance problems (real and apparent). However some other bottlenecks were recently fixed so I might try it on again for a while.
That inline CSS you pointed out is a special case (it's for the icons in the nav menu) which could not be properly implemented cross-browser using external CSS. You can disable these icons in the theme using: $THEME->navmenuiconshide = true;
For this project it might perhaps help to first think of this theme as a skin, rather than an overhaul of the bones.
True, it's more than enough work just thinking about and implementing how people will change colours, etc. and making it dead easy for them to do what they want to the theme.
But along those same performance lines, you could send along less HTML if the code is written with less duplication in mind. E.g. instead of:
... you could use JavaScript to hook up the onclick, rather than embedding it in the HTML. It would be quite simple to look for all links with the class glossary or autolink and add the onclick function to all via JS, inspecting the link value or HREF for the URL to use. Or at the very least, make a function that does the popup, since I doubt certain terms need a wider screen width, or require the URL to be repeated. Xonclick="return glossary('usability');" is less code :p Though I suppose I'm really, really nitpicking here.
And while Google.ca skips it, Google.com does some interesting pre-loading after highlighting the search field (sf):
[Edit: I suppose as a security feature, moodle adds X to the onload reference above, as I can't remove it otherwise.]
Which is yet another sprite-based idea, used on the results pages:
It expires in 2038. Amazing the tricks sites use to ensure pages load *really* fast, eh?
But along those same performance lines, you could send along less HTML if the code is written with less duplication in mind. E.g. instead of:
<a class="glossary autolink glossaryid5" title="Usability" href="http://moodle.org/mod/glossary/showentry.php?courseid=5&concept=Usability" Xonclick="return openpopup('/mod/glossary/showentry.php?courseid=5\&concept=Usability', 'entry', 'menubar=0,location=0,scrollbars,resizable,width=600,height=450', 0);">usability</a> ... you could use JavaScript to hook up the onclick, rather than embedding it in the HTML. It would be quite simple to look for all links with the class glossary or autolink and add the onclick function to all via JS, inspecting the link value or HREF for the URL to use. Or at the very least, make a function that does the popup, since I doubt certain terms need a wider screen width, or require the URL to be repeated. Xonclick="return glossary('usability');" is less code :p Though I suppose I'm really, really nitpicking here.
And while Google.ca skips it, Google.com does some interesting pre-loading after highlighting the search field (sf):
<body ... Xonload="sf();if(document.images){new Image().src='/images/nav_logo3.png'}" ... > [Edit: I suppose as a security feature, moodle adds X to the onload reference above, as I can't remove it otherwise.]
Which is yet another sprite-based idea, used on the results pages:
It expires in 2038. Amazing the tricks sites use to ensure pages load *really* fast, eh?
Louis,
I have used many css "tricks" with moodle and themes and could probably give you some testing support. For example these image sprites are a great idea to make pages load faster but they can't be used for all icons of moodle. Why? Because most icons are not named separately in code (or do not have css hooks) but they are named with loops and tags like
$icon = "$CFG->modpixpath/$mod->modname/icon.gif";
where mod name can change but name of icon is always icon.gif
To use sprites you would need to give module/icon specific css (background-position in sprite file) for each icon.gif
or change code of files like weblib.php, course/lib.php, blocks/block_activity_modules and course/modedit.php
I think Urs knows well the benefits and restrictions of sprites, more info about sprites is for example in
http://www.alistapart.com/articles/sprites and
http://css-tricks.com/css-sprites-what-they-are-why-theyre-cool-and-how-to-use-them/
The original idea can be made really simple...or we could try some new starting point like creating a module for administration of user editable themes. Themes could simply use the code found from theme folders and some (one or a couple of) field(s) of user profile (settings as a string exploded and imploded with php). Still it is better to let administrators to upload images to site files or theme folders and let users to select images from that set.
On the other hand no lib file code is taboo if new code works better than previous code. Latest tinymce editor changed also separate default theme icons to sprite some time ago as one part of performance tuning http://wiki.moxiecode.com/index.php/TinyMCE:Performance_tuning_TinyMCE
In reply to David Scotson
Re: How is Theme project different from the existing Chameleon theme?
by Martin Dougiamas -
I think you might be making this a bit confusing, David
A complete overhaul/breakage of page output and themes is an entirely different kind of project and should be done by core developers rather than a GSOC student. There are plans to turn weblib into a class for example, that any theme can override, as well as an overhaul for the $PAGE class and blocks.
Yes sure it would be nice to refactor the world in the next couple of months, but in the meantime this is supposed to be a student project that can help people even on Moodle 1.9.
A complete overhaul/breakage of page output and themes is an entirely different kind of project and should be done by core developers rather than a GSOC student. There are plans to turn weblib into a class for example, that any theme can override, as well as an overhaul for the $PAGE class and blocks.
Yes sure it would be nice to refactor the world in the next couple of months, but in the meantime this is supposed to be a student project that can help people even on Moodle 1.9.
In reply to Martin Dougiamas
Re: How is Theme project different from the existing Chameleon theme?
by Louis St-Amour -
Ahh, Moodle 1.9 ... That clarifies quite a bit. I think all students could benefit from learning what release they should aim for covering in their projects, otherwise some, like me, initially, might assume trunk CVS for all of them.
In reply to Martin Dougiamas
Re: How is Theme project different from the existing Chameleon theme?
by David Scotson -
Sorry for the confusion. I'd actually come looking in the forums to see if there was any work being done on refactoring the themeing code so I had a bit of a one track mind. Any more info on those proposed changes you mention?
The main reason I posted was I don't think it's possible to create a theme like Garland for Moodle at the moment and didn't want to see anyone getting set up with false expectations of what a student could produce.
As long as the student concentrates on the bits that are actually themeable (the header, footer and background mainly, blocks to a lesser extent) you can make some good early progress. It just becomes an uphill struggle once you move onto the fiddlier bits because of the things I listed above (which were what I was wanting to see if anyone was fixing for 2.0), amongst others and I thought that was worth flagging up.
Taking a look at this selection of themes (using the selector on the top right) that I found the other day gives you an idea of what can and can't be changed easily.
http://www.newschoollearning.com/moodle/?&theme=convertible_colored_pencils
You can get a similar idea from looking at themes in general but note that it looks like he's put a fair bit of effort into covering up the gaps and pushing the boundaries e.g. for the black theme ("stealth") he's gone through and added a black background to all the icons because they're gifs not pngs so you can't just use transparency. Or rounding the corners in the banner image so it looks nicer but it's not as easy to replace.
Getting back on topic, for themes that allow users to select colours/images you might want to automate such image manipulation in PHP with gd (as I believe the Garland theme does).
You might also be interested in the challenge of building an automated palette choosing tool like this:
http://blog.dabbledb.com/2007/04/white--or-green.html
It fits in with the idea that most educational organisations already have a 'look' or theme of their own.
Having that I still think that refactoring the themes especially the first three bullet points would make a good summer of code task. I've seen some pretty advanced stuff being suggested for other projects and those aren't exactly rocket science, more on the boring drudgery that no-one wants to do side of things to be honest. But as you say, it wouldn't be available for 1.9 since it would involve touching a lot of different parts of the code.
The main reason I posted was I don't think it's possible to create a theme like Garland for Moodle at the moment and didn't want to see anyone getting set up with false expectations of what a student could produce.
As long as the student concentrates on the bits that are actually themeable (the header, footer and background mainly, blocks to a lesser extent) you can make some good early progress. It just becomes an uphill struggle once you move onto the fiddlier bits because of the things I listed above (which were what I was wanting to see if anyone was fixing for 2.0), amongst others and I thought that was worth flagging up.
Taking a look at this selection of themes (using the selector on the top right) that I found the other day gives you an idea of what can and can't be changed easily.
http://www.newschoollearning.com/moodle/?&theme=convertible_colored_pencils
You can get a similar idea from looking at themes in general but note that it looks like he's put a fair bit of effort into covering up the gaps and pushing the boundaries e.g. for the black theme ("stealth") he's gone through and added a black background to all the icons because they're gifs not pngs so you can't just use transparency. Or rounding the corners in the banner image so it looks nicer but it's not as easy to replace.
Getting back on topic, for themes that allow users to select colours/images you might want to automate such image manipulation in PHP with gd (as I believe the Garland theme does).
You might also be interested in the challenge of building an automated palette choosing tool like this:
http://blog.dabbledb.com/2007/04/white--or-green.html
It fits in with the idea that most educational organisations already have a 'look' or theme of their own.
Having that I still think that refactoring the themes especially the first three bullet points would make a good summer of code task. I've seen some pretty advanced stuff being suggested for other projects and those aren't exactly rocket science, more on the boring drudgery that no-one wants to do side of things to be honest. But as you say, it wouldn't be available for 1.9 since it would involve touching a lot of different parts of the code.
In reply to David Scotson
Re: How is Theme project different from the existing Chameleon theme?
by Martin Dougiamas -
I (and Urs) totally agree with you about lots of work to do.
Just a quick note as a I rush through: GIFs support transparency!
Just a quick note as a I rush through: GIFs support transparency!
In reply to Martin Dougiamas
Re: How is Theme project different from the existing Chameleon theme?
by David Scotson -
As soon as I typed that, I thought someone's going to pick me up about it! That's what I get for being lazy and not going back to edit.
GIFs support 1-bit transparency so it works, sort of, for simple squarish bitmap art like most of the the standard Moodle icons. But you need png for alpha-transparency which will blend things into the background regardless of its color.
That's why the current help icon doesn't look particularly smooth. If you blend it in with the background then you need to pick a color in advance. That's what was done for the Nuvola iconset (you can see the sample with a white background attached) but then if the background isn't the same color as the one you chose you get either a box or with a bit extra work a less noticeable 'halo' effect. It may seem like a minor thing but it basically stops you changing the background color either in different places within a theme or even just creating a dark theme without a lot of work. All the little things add up.
And while I'm correcting small misunderstandings, there was talk earlier about CSS being cached. While the main .css files are cached, I was pointing out the amount of CSS that is inline with the HTML and outputted with every page view. As well as not being cached it mucks up the CSS cascade as it overrides the .css files.
And once last thing, I don't particularly think there's an amazing amount of work that needs to be done to make Moodle very themeable. It's just that the work that does need to be done will disrupt both developers and themers and also requires that they work in concert to a certain degree and so really needs to be done with consensus and a plan for how to get from here to there so that everyone is "singing from the same songsheet" as it were.
Stealth help image
Nuvola help image
GIFs support 1-bit transparency so it works, sort of, for simple squarish bitmap art like most of the the standard Moodle icons. But you need png for alpha-transparency which will blend things into the background regardless of its color.
That's why the current help icon doesn't look particularly smooth. If you blend it in with the background then you need to pick a color in advance. That's what was done for the Nuvola iconset (you can see the sample with a white background attached) but then if the background isn't the same color as the one you chose you get either a box or with a bit extra work a less noticeable 'halo' effect. It may seem like a minor thing but it basically stops you changing the background color either in different places within a theme or even just creating a dark theme without a lot of work. All the little things add up.
And while I'm correcting small misunderstandings, there was talk earlier about CSS being cached. While the main .css files are cached, I was pointing out the amount of CSS that is inline with the HTML and outputted with every page view. As well as not being cached it mucks up the CSS cascade as it overrides the .css files.
And once last thing, I don't particularly think there's an amazing amount of work that needs to be done to make Moodle very themeable. It's just that the work that does need to be done will disrupt both developers and themers and also requires that they work in concert to a certain degree and so really needs to be done with consensus and a plan for how to get from here to there so that everyone is "singing from the same songsheet" as it were.
Stealth help image
Nuvola help image
In reply to David Scotson
Re: How is Theme project different from the existing Chameleon theme?
by Martin Dougiamas -
I do agree we should move to PNG and even specifying all the icons via CSS. The reason for GIF in the first place (back in 2001) was that IE never supported PNG alpha transparency well ... and from a quick search it appears to still be a problem for IE7. Can that be right? I know about the JS hacks you can do to make it work and there's even a function in weblib for that, but blech....
In reply to Martin Dougiamas
Re: How is Theme project different from the existing Chameleon theme?
by Mauno Korpelainen -
We can always have different stylesheets for IE6 or even different theme if we like...but the most odd thing is that IE8 will be the only browser to not support any form of opacity, and "break" A LOT of exisiting websites, tools etc. that rely on this (including several of Microsoft's own websites and API's)
Sprites can still be gif images and transparent or not. In RocketTheme's Chromatophore administrator can select from control panel if he/she wants to enable IE6 warning. Maybe the best solution would still be that default themes use gif images and custom themes can select other image sets...
In reply to Mauno Korpelainen
Re: How is Theme project different from the existing Chameleon theme?
by Mauno Korpelainen -
In IE8 Strict Mode of course...fortunately IE8 has IE7 Emulation button for those users who want to use IE7 style browser (and IE8 can also change compatibility mode to IE5 Quirks with IE8 Developer Tools).
EDIT: Moodle could also use png by default and let IE6 and IE8 use gifs...or IE6 Theme and IE8 Theme
In reply to Mauno Korpelainen
Re: How is Theme project different from the existing Chameleon theme?
by Louis St-Amour -
What's with all the fuss?
You can easily serve 32-bit alpha transparent PNG files to Internet Explorer 7+8 and the rest of the modern browsers via background-image (sprite) techniques in CSS, and then use Conditional Comments to load GIF or 8-bit/24-bit PNG files for previous versions of Internet Explorer. From what I glanced at in Google, the only problem reported with IE and transparency in IE8 is actually the lack of CSS3 transparency specification plus the removal of IE's proprietary CSS filters in IE8's strict mode, which let you use an extremely slow method of transparency setting. At this point, if I wanted to make a background colour or image alpha transparent, I'd save it as a 32-bit PNG file and use it instead.
For a full list of IE8 problems so far, see:
http://www.quirksmode.org/blog/archives/2008/03/ie8_beta_1_firs.html
http://www.quirksmode.org/blog/archives/2008/03/ie8b1_tests_and.html
(Not that I've read all of the above right now, but it's a handy reference.)
You can easily serve 32-bit alpha transparent PNG files to Internet Explorer 7+8 and the rest of the modern browsers via background-image (sprite) techniques in CSS, and then use Conditional Comments to load GIF or 8-bit/24-bit PNG files for previous versions of Internet Explorer. From what I glanced at in Google, the only problem reported with IE and transparency in IE8 is actually the lack of CSS3 transparency specification plus the removal of IE's proprietary CSS filters in IE8's strict mode, which let you use an extremely slow method of transparency setting. At this point, if I wanted to make a background colour or image alpha transparent, I'd save it as a 32-bit PNG file and use it instead.
For a full list of IE8 problems so far, see:
http://www.quirksmode.org/blog/archives/2008/03/ie8_beta_1_firs.html
http://www.quirksmode.org/blog/archives/2008/03/ie8b1_tests_and.html
(Not that I've read all of the above right now, but it's a handy reference.)
In reply to Louis St-Amour
Re: How is Theme project different from the existing Chameleon theme?
by Mauno Korpelainen -
Thanks for the link, Louis!
Try yourself those links with IE8 and press then IE7 emulation button to see the difference... here attached an example found from your link (opacity)
http://www.quirksmode.org/css/opacity.html
http://www.quirksmode.org/js/opacity.html (js does nothing)
In reply to Mauno Korpelainen
Re: How is Theme project different from the existing Chameleon theme?
by Mauno Korpelainen -
And the following list of non functional things may break some code in moodle:
Stuff that works in IE7 but not in IE8:
<ol>numbering may be wildly and weirdly off; see the Core Table index, for instance.scrollTopandscrollHeightare off (test page). Still have to determine how much off and if there's any rule.- :first-line and :first-letter don't work.
- The
attributes[]array doesn't seem to have alength. - The cells[] and rows[] nodeLists don't work.
letter-spacingdoesn't work in this page. (The test is about thetag[customAttribute]selector, which works fine.)- Opacity doesn't seem to be supported (unless there's some odd syntax; I tried
-ms-opacity, but that doesn't work, either). - A really minor one: Some CSS selectors, such as the + selector, should also work when the page content is changed by JavaScript. In IE8 they do, but only after you remove the focus from the link that changed the page content.
+ the whole list: http://www.quirksmode.org/css/contents.html
Check also this: http://moodle.org/mod/forum/discuss.php?d=94344 for other effects of IE8
But the good parts are here: http://www.microsoft.com/windows/products/winfamily/ie/ie8/readiness/DevelopersNew.htm
In reply to Mauno Korpelainen
Re: How is Theme project different from the existing Chameleon theme?
by Louis St-Amour -
Haha, wow. I like Activities - It's Smart Tags for Web 2.0, I suppose. And Web Slices sounds suspiciously like Safari/Leopard's Web Clips But at least there's a standard behind it (yay)
I love the printing enhancements too. Firefox still has trouble with live previews ... sigh. Six connections per host (under AJAX!), that's interesting. And they've added Cross-Domain "Requests": let's hope that's secure enough to use regularly.
Thanks for the Microsoft link, it's a positive counterpoint for Koch's um ... more realistic and standards-focused QuirksMode. :D I still haven't gotten around to installing the IE8 beta yet, sigh. (Just finished my exams yesterday and I'm at work right now; forgot my laptop at home ...)
I love the printing enhancements too. Firefox still has trouble with live previews ... sigh. Six connections per host (under AJAX!), that's interesting. And they've added Cross-Domain "Requests": let's hope that's secure enough to use regularly.
Thanks for the Microsoft link, it's a positive counterpoint for Koch's um ... more realistic and standards-focused QuirksMode. :D I still haven't gotten around to installing the IE8 beta yet, sigh. (Just finished my exams yesterday and I'm at work right now; forgot my laptop at home ...)
In reply to Louis St-Amour
Re: How is Theme project different from the existing Chameleon theme?
by Mauno Korpelainen -
You MUST try it - and try first ZOOMING...
In reply to Louis St-Amour
Re: How is Theme project different from the existing Chameleon theme?
by Mauno Korpelainen -
Opacity and png alpha transparency are two different things but it is sad if we loose all these nice effects in IE8:
http://www.mandarindesign.com/opacity.html
My IE8/IE7 ( PC / Vista ) has no problems with png images test page http://entropymine.com/jason/testbed/pngtrans/
Okay, so ... I'm in the middle of writing my "detailed description" and I just realised the one thing I'm unclear about is "select a parent theme". If this theme has to be compatible with a wide variety of parent themes, as Chameleon can be applied, then that severely constrains the amount of customization to any given theme, since they would have to have standard *something* to be controlled from one UI. Either that, or you would need to work more directly with the elements of the theme, like Chameleon does, instead of abstracting back to basic colours and such.
I can understand wanting to make sure this interface can be applied to many themes, but I was under the assumption that there would need to be modifications to the theme to support this, to some degree. Unless ... by parent theme, did you mean parent customizations? As in, you would start customizing with this theme, and then save, and further customizations could be made later, starting from a "parent" theme? E.g. first you customize logo and header/footer, later you customize inside contents, as might be useful for course-specific themes as mentioned in [MDL-230]?
Well, it's a minor enough detail. My goal, though, is to allow for live previewing, and to do that, you would need to know what CSS elements you're changing, ideally via JS directly, without contacting the server. And you might want to set up the customizations so they're more built-in to the theme, or offer previews of specific important parts of a theme that people would want to customize. Perhaps a theme might want to offer different "styles" within itself, e.g. rounded-corners and non-rounded. All this lends itself to thinking more of this as customization being an integral part of a theme, and not something you can add on as you would with Chameleon. The more natural and understanding an interface is, the more restraints it applies to the data (or in this case, the theme) underneath, to match user expectations rather than give in to how an existing theme may be set up. That way "thinking in CSS" can be avoided entirely.
Here's my abstract:
Primarily, I will create a new theme (theme/custom) that includes a configuration page so that the theme can be easily edited directly via Moodle (such as the colour picker in Drupal's garland). The page would include at least the ability to:
* Select a logo from the site files and/or interface to upload a file
* Several input fields to customise various CSS elements such as block headings, text colour, background colour, headings, header, footer, extra custom CSS etc.
* Select a parent theme
I will also include the optional ability (admin-assigned) to let users customise part or all of the elements of the theme. The theme should be usable in Moodle 1.9 (although I will look into how it can work better in Moodle 2.0).
Documentation and usability is very important to me, so throughout the process, I will release versions for testing, ideally live, to ensure I can receive and incorporate feedback from the wider Moodle community and thereby produce a more useful theme. I will also attempt to maintain help documents for getting started with this theme and an FAQ or perhaps a gallery of configurations. I hope, however, that such documents will not be necessary, as my theme would ideally be self-explanatory and simple to customize, out of the box.
If there is time remaining, I will work on improvements to the theme in other areas, such as integration with Adobe Kuler for easy theme colour suggestions or a way to export the customized theme as a new partially-customizable theme. (Perhaps by bundling previously saved customizations with a copy of the custom theme, as might be possible via the “XML templates for admin settings” project.)
To ensure the best outcome for all of Moodle’s Google Summer of Code projects, I would like to work closely with the other projects: such as working on/with Usability review suggestions and the Automatic accessibility tool or perhaps adopting the RSS reader project for the Kuler API. As a future project, it might be nice to adopt theme customizations to be user-specific yet public such as for the new blog assignment type, etc. This way pages could be individually customized, allowing for more personal self-expression within the more institutionally-oriented current Moodle theme practices.
I can understand wanting to make sure this interface can be applied to many themes, but I was under the assumption that there would need to be modifications to the theme to support this, to some degree. Unless ... by parent theme, did you mean parent customizations? As in, you would start customizing with this theme, and then save, and further customizations could be made later, starting from a "parent" theme? E.g. first you customize logo and header/footer, later you customize inside contents, as might be useful for course-specific themes as mentioned in [MDL-230]?
Well, it's a minor enough detail. My goal, though, is to allow for live previewing, and to do that, you would need to know what CSS elements you're changing, ideally via JS directly, without contacting the server. And you might want to set up the customizations so they're more built-in to the theme, or offer previews of specific important parts of a theme that people would want to customize. Perhaps a theme might want to offer different "styles" within itself, e.g. rounded-corners and non-rounded. All this lends itself to thinking more of this as customization being an integral part of a theme, and not something you can add on as you would with Chameleon. The more natural and understanding an interface is, the more restraints it applies to the data (or in this case, the theme) underneath, to match user expectations rather than give in to how an existing theme may be set up. That way "thinking in CSS" can be avoided entirely.
Here's my abstract:
Primarily, I will create a new theme (theme/custom) that includes a configuration page so that the theme can be easily edited directly via Moodle (such as the colour picker in Drupal's garland). The page would include at least the ability to:
* Select a logo from the site files and/or interface to upload a file
* Several input fields to customise various CSS elements such as block headings, text colour, background colour, headings, header, footer, extra custom CSS etc.
* Select a parent theme
I will also include the optional ability (admin-assigned) to let users customise part or all of the elements of the theme. The theme should be usable in Moodle 1.9 (although I will look into how it can work better in Moodle 2.0).
Documentation and usability is very important to me, so throughout the process, I will release versions for testing, ideally live, to ensure I can receive and incorporate feedback from the wider Moodle community and thereby produce a more useful theme. I will also attempt to maintain help documents for getting started with this theme and an FAQ or perhaps a gallery of configurations. I hope, however, that such documents will not be necessary, as my theme would ideally be self-explanatory and simple to customize, out of the box.
If there is time remaining, I will work on improvements to the theme in other areas, such as integration with Adobe Kuler for easy theme colour suggestions or a way to export the customized theme as a new partially-customizable theme. (Perhaps by bundling previously saved customizations with a copy of the custom theme, as might be possible via the “XML templates for admin settings” project.)
To ensure the best outcome for all of Moodle’s Google Summer of Code projects, I would like to work closely with the other projects: such as working on/with Usability review suggestions and the Automatic accessibility tool or perhaps adopting the RSS reader project for the Kuler API. As a future project, it might be nice to adopt theme customizations to be user-specific yet public such as for the new blog assignment type, etc. This way pages could be individually customized, allowing for more personal self-expression within the more institutionally-oriented current Moodle theme practices.
Here's the so-called detailed description, although honestly, this topic probably offers more along those lines:
Okay, so this Detailed Description is rather short, as I've already written a lot elsewhere, including at http://moodle.org/mod/forum/discuss.php?d=93163 ...
I'm still a little unclear about one aspect of the original project suggestion, the "select a parent theme" bit. But I think I understand all other project requirements.
The hardest part for me, in doing this project, will be setting up constraints for the functionality, as I could spend forever dreaming up new ways to implement this functionality.
I think the best way to develop this theme will be to focus on getting the user-interface done right, as if I need to, I can likely borrow or work with Chameleon's backend for some of it.
So in developing this, I plan on creating many publicly-accessible prototypes of Moodle pages, to ensure that the access points and customizability are clear and easy to use. E.g. in one prototype, I could create a version that uses hovering to let people change items, in another I could keep a static sidebar and drag and drop or click-to-select.
But I would also have to focus on the initial customization/install workflow - E.g. people may want to customize the logo immediately after installation, and then later only change colours, or they may be unsure about which design to use and want to create many alternatives. A third example might be someone with an HTML template who wants to integrate it with Moodle's header and footer, something that may be more of a documentation/help enhancement rather than code-driven requirement.
Ultimately, I want to place the focus on the individual person doing the customization. What are their goals in changing the Moodle interface and how can I help them get to the best result, in the fastest way possible? So that means starting from the basics of changing a logo, working (eventually) to making it easier for people to create custom themes, perhaps also adding such customizability to them. The last bit is of course more about documentation than code, in my mind. I'm not afraid of writing or illustrating with screenshots. I like helping people.
Thanks for your consideration. I look forward to helping improve Moodle. I'll now start to add further details and ideas to http://moodle.simpler.ca/ ...
Louis St-Amour.
Okay, so this Detailed Description is rather short, as I've already written a lot elsewhere, including at http://moodle.org/mod/forum/discuss.php?d=93163 ...
I'm still a little unclear about one aspect of the original project suggestion, the "select a parent theme" bit. But I think I understand all other project requirements.
The hardest part for me, in doing this project, will be setting up constraints for the functionality, as I could spend forever dreaming up new ways to implement this functionality.
I think the best way to develop this theme will be to focus on getting the user-interface done right, as if I need to, I can likely borrow or work with Chameleon's backend for some of it.
So in developing this, I plan on creating many publicly-accessible prototypes of Moodle pages, to ensure that the access points and customizability are clear and easy to use. E.g. in one prototype, I could create a version that uses hovering to let people change items, in another I could keep a static sidebar and drag and drop or click-to-select.
But I would also have to focus on the initial customization/install workflow - E.g. people may want to customize the logo immediately after installation, and then later only change colours, or they may be unsure about which design to use and want to create many alternatives. A third example might be someone with an HTML template who wants to integrate it with Moodle's header and footer, something that may be more of a documentation/help enhancement rather than code-driven requirement.
Ultimately, I want to place the focus on the individual person doing the customization. What are their goals in changing the Moodle interface and how can I help them get to the best result, in the fastest way possible? So that means starting from the basics of changing a logo, working (eventually) to making it easier for people to create custom themes, perhaps also adding such customizability to them. The last bit is of course more about documentation than code, in my mind. I'm not afraid of writing or illustrating with screenshots. I like helping people.
Thanks for your consideration. I look forward to helping improve Moodle. I'll now start to add further details and ideas to http://moodle.simpler.ca/ ...
Louis St-Amour.
Oh and something I'd like to look at in future is borrowing the theme concept ideas from Joomla! to Moodle. For instance, rather than having fixed columns, as most CMS software uses, Joomla! instead uses named "blocks", and by default has 6 of them, including left, right, top, etc. I really like this idea, as it means you can have a great deal of flexibility as a theme designer in how your theme operates, while allowing for modules to do what they like. If width or style is a concern, Joomla! also allows a theme to override any module's output, allowing for a painless transition to clean CSS-driven markup with just one theme. (Beez)
I'll be working heavily with Joomla! themes and code this summer, so it's something that will be constantly on my mind, as I mentally wrestle with the restrictions of Moodle's tables and columns approach :p Not that customizing colours has much to do with tables ... I suppose I could offer the option to have just left or right columns ... but then, if we used blocks, it would be a lot cooler to just drag and drop components of a page from one block to another, as SharePoint allowed even back in 2003.
I'll be working heavily with Joomla! themes and code this summer, so it's something that will be constantly on my mind, as I mentally wrestle with the restrictions of Moodle's tables and columns approach :p Not that customizing colours has much to do with tables ... I suppose I could offer the option to have just left or right columns ... but then, if we used blocks, it would be a lot cooler to just drag and drop components of a page from one block to another, as SharePoint allowed even back in 2003.
We have had some a little similar discussions in theme forum with Urs - for example in http://moodle.org/mod/forum/discuss.php?d=89911
Current structure of moodle is just about 10 times more complicated than structure of Joomla...
One example of rockettheme module position system is in http://demo.rockettheme.com/apr08/index.php?option=com_content&task=view&id=25&Itemid=44
"These module positions are fully collapsible meaning that if there are no modules published in particular area, that module area will not be shown. This provides you with the maximum amount of flexibility possible."
New rocketthemes have some other interesting features like color chooser http://demo.rockettheme.com/apr08/index.php?option=com_content&task=view&id=61&Itemid=81
In reply to Mauno Korpelainen
Re: Borrowing Theme structure ideas from Joomla!
by Mauno Korpelainen -
Main colors can be selected with color pickers like in this joomla template with Mootools Rainbow http://moorainbow.woolly-sheep.net/ and theme is also using styleswitcher to select transparent background. Color Chooser can be shown/hidden and basicly this is just a form with input fields that get values with javascript.
Usually this kind of selectors save settings to cookie - but I like the idea of saving some user theme settings to database...