That page tries to summarise the changes we will be making and gives some examples of how code will look once everything has changed. It is probably the clearest summary to date of the proposed changes, so if you have not already engaged with this, now would be a good time.
The other reason to engage with this now, is that I am about to start writing code, so if there is anything there you hate, it is about to be too late to do anything about it Please don't hold back with any questions, if there are problems with this proposal, I would like to find out about them sooner rather than later.
My page is a view of the changes from the point of view of the code. Martin has just added some mock-ups to Development:Navigation 2.0 which show what we hope the consequences of this will be for users.
I also want to say that I like the plan the lot - I think it addresses all the concerns that I've ever heard about Moodle navigation and theme design. And it does it in an evolutionary way so there shouldn't be any shocks.
I'm quite looking forward to seeing what site designers and theme designers will be able to do with this!
Tim, the implementation plan looks promising. I look forward to implement great learning environments with Moodle 2.0.
mike
The point you were trying to make on the wiki page was something about flexibility for course formats. I know very little about course formats, but I suspect that in Moodle 2.0 you will be able to do a lot of what you want if you are prepared to write a custom theme.
Also, what we are proposing to do is Moodle 2.0 is already a mountain of work, and the last thing I want to do now is expand the scope further.
Can I suggest we wait until Moodle 2.0 is released; then think about how course formats relate to the more flexible themes and blocks; and then improve course formats in Moodle 2.1.
I actually wonder whether, in Moodle 2.0 terminology, a course format isn't mostly a renderer, but with the added ability to get some settings?
Sorry about leaving comments in the wiki, but the heading was there with a question (as below) seemingly inviting collaborative input.
"Course view
What do we need on top of the existing course formats?"
This also sounds to me like something that is intended for 2.0. I think it would be a mistake to ignore this (unless it is already being handled somewhere else as you suggest).
But, I don't think you should have to write a theme to make a course format do what you want, should you? If that's the case, what is the point of the course format plug-ins?
Can you point me to where you think the 2.0 code already deals with course formats?
mike
Well, 2.0 already deals with course formats in that they work in Moodle 1.9 and give developers certain degrees of flexibility (look at flexpage format and OU studyplanner). And I propose that my changes in Moodle 2.0 will be sufficiently backwards compatible that none of that breaks.
In addition, the general features for more flexible handling of blocks will probably be quite useful for people creating certain sorts of course formats.
But beyond that, I am not aware of anything.
One way to view a course format is that it is just a way of rendering the data from the course_sections and course_modules tables, with a few hooks for settings, etc. So, from a code point of view, it may overlap a lot with the Moodle 2.0 notion of a renderer, which is part of the themes framework.
On the other hand, in the UI (at least at the moment) teachers can make separate choices about what course format they want and which theme they way, and that is quite logical.
Like other plug-ins, the course format should be able to display its entire page - header, content and footer. In the current situation it cannot.
The settings issue and the course object issue are probably not specific to the discussion on "Navigation 2.0" but are pertinent to the course format.
mike
- Controlling the display flow. Currently, course formats can only write out the main section of the page (right, centre and left). The header and start of the page are all written by '/course/view.php' before the course format gains control. We could allow course formats to optionally override this using some sort of course format variable (eg a file like /course/format/something/view.php) that course/view.php could detect to work out when to pass control to the course format).
- The course object is currently loaded by a database call. To optionally allow course formats to add data from their own tables into the course object we could easily change this to call a standard function like $COURSE = get_course($id); that detected a file or variable in the current course format and used that (eg /course/format/something/data.php)
- The edit course function is currently not controllable by the course format, making it difficult to provide custom settings screens for a specific format. In Moodle 2.0 we could easily, as above, make this page look in the course format for additional settings. (eg /course/format/something/edit.php)
Most of this is independent from the blocks/pages/themes stuff we are talking about here, but I do forsee a bit of a problem if course formats are insisting on rendering their own headers and footers, in that it could clash differently with different themes. Course pages would not remain consistent with the rest of the site. For example, imagine if the theme defines new regions. That would be your risk as a course format creator though.
>> Most of this is independent from the blocks/pages/themes stuff we are talking about here
Well, yes and no. A course format is a page so it would be affected by whatever page code we create (or should be).
>> but I do forsee a bit of a problem if course formats are insisting on rendering their own headers and footers
Likely, most would never do this any differently than a module page does. Modules are responsible for outputting the entire page, and it makes sense then that a course format should be too.
mike
The work with templates will become more consistent when Moodle creates content the same way everywhere. And working with pages as a whole is easier to understand.
My +1 to change courses to handle complete pages like modules do.
If we turn things into an all-encompassing API, we end up removing flexibility. A good example of a bad API within Moodle right now is Blocks, which tries too hard to do things that are naturally simple.
As things stand, Blocks has a very fancy API, obscure documentation and overly complex API to... print out a few cell tags.
I am happy that you're doing this, but I am not keen on a complex rich API... can I vote for something minimalistic that gets out of the way?
Most of your plan reads good and minimalistic (a $PAGE object that holds a few props, has some simple methods)... but I'm not sure how smart you're planning on making the class
Some notes:
- I'm not sure that $PAGE should be generated always. Not all PHP hits are pages, and not all invocations of config.php are pages.
- Functions that generate HTML should just return it, so the calling convetnion is 'echo $PAGE->foo()' which makes the source code that uses $PAGE fairly obvious as to what's happening, and allows for trivial buffering.
- I assume that most of the methods will just generate a bit of HTML. It'd be nice to say so in the docs. And so simplify and remove any magic. I suspect the methods of $PAGE don't need to have any side effects, which means it can all be fairly simple and transparent
- If $PAGE is going to complain (about already printed headers, for example), it should do so in the error logs. Please please please...
- Consider that we may be building significant chunks of HTML outside of what you may call a page. Keep in mind forum posts to be mailed out...
2. Actually, my though was that for every method $OUTPUT->something(...) there would be an equivalent $OUTPUT->get_something(...) to return it. Just syntactic sugar, but I think it is worth it. Obviously, something(...) is just echo get_something(...). Have not yet chosen between implementing this by hand or using PHP5 __call.
3. Note that $PAGE stores info. $OUTPUT renders stuff, and the two are separate. $PAGE should be simple. $OUTPUT should be side-effect free.
4. $PAGE will use the existing debugging('...', DEBUG_DEVELOPER) or throw new coding_exception(...) mechanisms, depending of the severity of the problem we detect. Both of those already go to either the screen or logs, depending on your choice on Admin -> Server -> Debugging.
5. See 3. - and yes, I had remembered about forum post mail-out.
dan
echo $OUTPUT->header(); // or possibly
echo $RENDER->header();
It's a bit longer, and less nice than using OUTPUT as that verb, but I think we gain on clarity for developers with simpler renderer classes and less methods.
And suppose also, that as well as methods like $forumrender->post(...) to output a single post, we also have $forumrender->thread(...), so that themes can control the overall rendering of a whole thread.
Then suppose you do
echo $forumrender->thread(...);
on a thread with a couple of hundred posts. That will build a huge string in memory. Is that a performance problem?
I don't think the large string in memory will be an issue -- and we _can_ always implement an explicit print_thread() method for the very few locations where html buffering is a problem.
One thing does bother me: expecting that theme creators will subclass stuff. Theming is very loosely coupled --- asking a theme creator to write a subclass that is tightly coupled to the internals of our code... ouch.
For example, we might find a performance problem on large sites and tweak the SQL to get a slightly different recordset.
I am not so worried that your templating system would allow it... I am worried that someone will actually use it, and then complain because it broke in a weekly update. Or in a 2.0 -> 2.0.1 update.
There is something to be said for maintaining local patches -- in that if there's an upstream change, you see a conflict. Clear, transparent, and right in the place where it all belongs.
Tight coupling obscured by OOP abstractions makes it harder to notice that it's broken, and far less obvious to figure out why.
IMHO, advanced theme+moodle hackers like Urs can put their "safe" theming bits in the theme proper, and their "risky" theming bits as local changes to the code.
No amount of hooks -- OOP or otherwise -- will ever satisfy the hardcode themers and my take on this is that... it is OK. They have the source, and can change it.
There are risks in trying too hard to formally support "risky" theming changes:
- It expands enormously what we expose as APIs. We cannot actually maintain those APIs longterm, so the themes will break with our bugfixes and updates.
- The moment we add those "risky" hooks to theming, lots of users will take them as safe, and use them. When they break, the users will (quite reasonably) complain that we exposed an API and we broke it.
There _is_ a higher barrier to changing how a forum thread is displayed. And I'd argue that it is the right thing to have -- if you want a significantly different way of displaying and printing the thread (one that mere CSS cannot help with) you also probably have to change the SQL, so roll up your sleeves, get dirty with the code, and get ready to maintain a minor patch long-term.
If there are low-risk hooks that we are happy to expose and add real value, that would probably be a good thing. But the examples discussed so far IMO merit a patch.
I actually can't think right now of a good hook example where the core code has all the data needed and is not using it, or could use it differently/better without significant re-flow of the code.
Certainly, the one time I tried to hack a templated system (adding the commit comments to pages like http://cvs.moodle.org/moodle/lib/moodlelib.php?r1=1.960.2.125&r2=1.960.2.126&pathrev=MOODLE_19_STABLE) I had to hack to core code to make that data available too.
However, I also lost this argument. One of the more convincing arguments for hooks like this is that some hosting providers will not allow their customers to hack core code, but will allow them to install third-party plugins and themes, so the more you can do with standard plugins the better.
Anyway, it is certainly true that the changes I am embarking on do not merely make it easier for people to shoot themselves in the foot if they are not careful, but they also hands them a howitzer with which to do so.
But, such is progress. I think we just have to say caveat hacker. And none the changes prevent people from hacking the core code if they prefer.
It is a good strong argument that hosting providers only allow plugins -- but a strong point of reputation of the plugins themselves and of moodle itself is that the API is relatively stable.
As long as we offer well defined (and hopefully thought-through) entry points we know we can maintain, that's swell. But if we support subclassing and overriding of any methods as a valid strategy, we (developers) paint ourselves in a corner. From some functions and data structures being the (unchangeable) API we go to every object state is part of the API.
How do we react when bugfixes in the core of the module cannot be done because it changes the recordset we get? Or any of the datastructures in the object?
It is ok to have limits in what plugins and themes can do, I'd say.
As a 'hosting provider' I am not too concerned that themes might be broken these sort of the things as its at least clear to see where the breakage occurs a simple swap to the standard theme. (What I am more concerned about is increased overhead in inspecting 'powerful themes' to ensure they aren't going to $DB->delete_records('assignment_submissions'); )
Let's assume that your forum thread XHTML is very good semantic XHTML + CSS. Let's think about htings that you cannot do with plain CSS manipulation.
These are some examples that come to mind, of things that you cannot do even if you have good XHTML+CSS:
- You might want to change how the thread is constructed, the nesting, the order of the posts. That is within the data you have, but our SELECTs are bringing the data out in the right order. That's one of the reasons that's not a "themable" change and we actually have various threading modes.
- You might want to change what CSS classes some bits have, based on data in the DB. Maybe you want to add twitter links right next to the name. Alas, you need to grab more of the user record
- Urs, perhaps there are better examples?
One of the associated questions is: can we make our XHTML+CSS setup better?
http://en.wikipedia.org/wiki/RDFa
That's not going to help with the scenarios you describe, Martin, but I think it might be interesting.
1. Suppose in nested view you wanted to link each post to its children with some lines in the graphic design, and you need to tile different joint images depending on the post tree structure. That only relies on the $post->id and $post->inreplyto fields (or whatever they are called), which you can probably rely on.
1.b. a simple variant on this is that after rendering the whole thread, you want to go back and put a class="maxdepthN" on the outer div, so you can make the depth on indenting in the thread view dependant on the deepest nesting level.
2. This is the cool one. Suppose you want to research ways to encourage inclusive discussion, and discourage two people having a flame war with each other. As the thread progresses, you want to adjust the border colours of posts, so if two poeple, say Tim and Martín just keep gong back and forth replying to each other, the border posts to gradually get more and more red; while if more and more different people reply to one person, the border colour gets more and more green.
You can do this just tracking $post->id, $post->userid and $post->inreplyto (all quite stable) as you render the thread, and if you are just fiddling around and experimenting, it may be safer and better to do it in just one theme that is used in your research course, without affecting anyone else on your site. Or perhaps you want to try out different algorithms in different courses at the same time.
OT, but an earlier idea I had for forum software is a method of ranking 'thread quality' a bit similar to this. It's interesting, because a thread that has a single post and many replies just at the top level is a low-quality thread (as nobody is interacting with each other), and so is a thread which contains a very 'deep' reply chain but it's all 2 people replying to each other. A high-quality thread is somewhere in the middle. One way to calculate a ranking might be to count the number of interactions between different pairs of people, but where each person may only appear in the 'parent post' end of up to, say, 5 pairs. Anyhow that's nothing to do with this but.
--sam
BUT I think the problem we have is the 'evolutionary' nature of the system you are being forced by the history of the project to develop. In an ideal world you could design a templating system to handle the view in a mvc application and the templates could purely control the xhtml/xml/etc sent to the client device, but it seems to me you are developing a system based on subclassing so as to enable theming within moodle as it is currently strctured.
Imho subclassing is a very good solution when there is no option to re-structure the entire application - and the power that a subclassing system gives to the template designer may be a neccessary evil given the situation we find ourselves.
Hope that made sense!
Dan
My suggestion involved changing the border colour of something - certainly part of the style - based on the content of the page. How about alternating colours on even and odd rows of a table, would you object to a theme doing that?
And yes, we can only evolve Moodle starting from where we are now.
"you can do this just tracking $post->id, $post->userid and $post->inreplyto (all quite stable) as you render the thread"
Now I am quite new to Moodle and certainly do not yet know the inner workings of the forum code, so my first reaction to tracking the above properties of $post as someone who is used to working with cakephp or zend framework was that maybe this is not work for the view? But like I say, I am new to Moodle and I do not fully understand how it is structured.
I suppose what I'm struggling to grasp is how this sub-classing override system would work from the point of view of the theme? Would $post be the object that is always passed to the forum renderer? And then the theme would be free to do whatever it wanted with the data held in that object if it sub-classed the forum renderer? That would certainly allow the theme creator a lot of control! It could be cool.
I think you would see themes that would really be different and create unique user experiences. There would be an issue of themes breaking on upgrades, but that would be for the theme designer to maintain as you would a package. I personally think it would be better to see this code maintained as a package called a theme than to have a load of custom code being maintained as patches and so forth floating around Moodle forums and blogs.
I guess themes could come with some kind of rating like standard and advanced. Standard themes are less exciting but they are guaranteed not to break on upgrade, advanced themes come with a health warning that if they are not maintained then upgrade may not be possible.
A few more random thoughts for you at any rate. So glad to gear you are working on this, can't wait to test drive it for you!
dan
$templatepath = find_template('forum_post');
$param1 = $value1;
$param2 = $value2;
$post = get_records('forum_posts', 'id', 123);
include($templatepath);
Whereas, in Moodle 2.0, the kind of code we will have will look like
$forumoutput = get_renderer('forum');
$post = get_records('forum_posts', 'id', 123);
$forumoutput->post($value1, $value2, $post);
The only difference there is purely superficial.
As Tim describes the process you work with all templates/renderers. You need to know something about the content and then output the details in an adequate loop.
People working that way know how to handle the output properly. And with main changes in the content you need to update your CSS as now and the renderer.
header.html and footer.html in Moodle 2.0 themes?
In Theme engines for Moodle "header.html" and "footer.html" are listed as part of the theme folder. Are they really necessary in 2.0 themes?
In a page header and footer are areas like the content area. So why handle them different? With the new page concept and the "slots" they look more like a relic from the current way themes are built.
Top and bottom of the page may probably be slots too. Header and footer content may be placed there similar to the blocks. The content of the XHTML <head> will surely be created and output by a function. All page content including header and footer may then be a page slot within the <body> part of the page.
Something like slots for header and footer better integrate into the page concept. What do you think?
It probably makes sense to keep these existing templates working by default so that pre-2.0 Moodle Themes don't need so much work to upgrade.
Headers/footers don't have to have much in them, and yes blocks in "top" and "bottom" will be possible most of the time (though they will need custom CSS to make them not look like blocks and place them exactly).
Render blocks
In Use blocks for most navigation the top navigation is described as "a block containing a menu of hierarchical items ...".
The top navigation does not look like a block, how will it be rendered?
- Will there be a special block renderer for blocks not looking like blocks?
- Will the block renderer be capable to render the block content without the sideblock specific parts like container XHTML and block header?
- Are those elements supposed to be hidden by CSS?
3 would produce unnecessary overhead.
(1) seems a little strange to do in core, because the whole point of this was about separating the core logic from the display and theme. I suppose a theme could choose to output blocks XHTML differently depending on the "region" they are going into.
Basically I had been thinking (3), perhaps this can easily be done with one common CSS that affects everything inside a given region container.
Something like:
.region#top div.sideblock div.header {
some css to hide headers ...
}
However, it will certainly be set up so that it is easy for a theme to specify a different renderer for any block appearing in 'top' or 'bottom', say, if it chooses.
And it will also be easy to specify a different renderer for a specific block. For example, suppose you want to use a custom rendering for the login block, wherever it appears.
From Martin's and Tim's answers I conclude
- The "easy" but more likely "dirty" way will be to hide "sideblock" specific elements like block header with CSS.
- The "clean" way will be to use a specific renderer.
Sounds reasonable.
Admin theme
Course content can be easily handled within the smaller 2 column pages or pages with fixed page width often used in actual web pages and Moodle pages. Admin pages with for example wide information tables with several columns or statistics need much wider pages. A possibility to offer an "Admin theme" would be very handy.
In the "Page object" section of the "Navigation 2.0 implementation plan" the $PAGE->generaltype ('normal', 'popup') is described.
In the "Navigation" section $PAGE->settingspages is described as "all the 'settings' pages (like roles, settings, filter, files)".
I wonder, if $PAGE->generaltype set to 'adminpage' or $PAGE->settingspages as a filter may be used to offer such a special "Admin theme"?
To handle admin pages and content pages different makes much sense as I have experienced in a Drupal setup I worked with the last days. Drupal offers to use a different theme for admin pages and you can handle clean small user pages and clean admin pages with wide content without hassle. In Moodle I most the time struggle with the admin pages when working with fixed width themes.
There are certainly some issues, like what are the right rules for setting $PAGE->generaltype that I think will be very hard to guess up-front with 100% accuracy.
We need people to experiment during the Moodle 2.0 beta period, and even after the release, to try to do interesting things like this. They should be possible, preferably easy, and so if they are not, we need feedback so we can refine things.
(Another tricky bit that may need to be adjusted in light of actual experience is the details of how we determine which blocks appear on which pages. That is in the details of the sticky blocks proposal.)
I will obviously try to structure the code to follow the DRY principle, making it as easy as possible to tweak certain details as we learn more, without impacting other things.
thanks a lot for that implementation plan. It looks really well thought and mature! In any case, far better than current output system, IMO
I've been spending some time today reading it and thinking about the things I don't like in the plan, and also what could be missing or undefined.. and here it's my summary (directly pasted from my temp document and not reviewed too much, so I hope it will be understandable).
Note there isn't any "-1" to the plan as is, but some comments / ideas that IMO should be clarified and decided before any coding. Here they are (numbered for easier reference later):
E1 - "A key point to all this is backward compatibility. All of this will only affect pages that are coded for it. Older code will work as before, using deprecated functions." -> Seems that proposal will break BC is various parts, isn't it? Or is the key point 100% still valid and embraced? Else, which parts will be broken?
E2 - Why do we need $OUTPUT globally used everywhere? And potentially $PAGE too. Cannot everything be wrapped into raw functions, and hidden from the masses? Just an alternative to reuse current weblib functions providing transparent BC. Not sure about other renderers different from $OUTPUT (modules...).
E3 - In the example, I don't get the idea about how $OUTPUT and other renderers (modules...) will coexist. If module renderer has precedence over $OUTPUT... we can end with a nightmare of modules ignoring $OUTPUT and overriding it, making themes (and core) renderers unable to decide appearance (and that's a nono, IMO). It seems that, while theme renderers can override OUTPUT_renderer completely, other renderers, like modules... shouldn't be able to override it at all. Two different type of renderers needed, I guess.
E4 - Blocks positioning... 100% free? Each page can create "slots" in any place? Any idea about how to move blocks around? And how to identify those slots properly?
E5 - My +1 to use verbal function names: print_xxx() get_xxx(), render_xxx() or whatever, instead of simple xxx() ones. Seems a bit reiterative but needed IF those objects (PAGE, OUTPUT) have methods for non-rendering functionalities.
E6 - My +1 to have the print_ and get_ duality applied everywhere. 100% Although I'm not sure if best implementation is duality of functions or extra param... or some sort of $OUTPUT->enable|disable_capture() to instruct functions to return instead of print... different alternatives to achieve the same thing each one with its own pros|cons. Personally I prefer always to have getters and then output them via echo, as ML stated above or, the lesser evil, 100% separated functions.
E7 - Some way to improve printing in general, in a centralised way? Perhaps related with all this PAGE and OUTPUT stuff? Being able to disable output of some parts (blocks...) completely, not only by hiding them with CSS? A general "print mode" link available for all pages, calling same URL (same than original) + "&printmode=1", but causing PAGE/OUTPUT to know they are in print mode.
E8 - How will some pages, sometimes displayed in popup, sometimes in normal page... skip printing some parts like headers, breadcrumbs and so on (message pages, glossary filter.... and some more here and there). Any chance to get $PAGE->inpopup or so filled in a standard way, similar to prev point (aka + "&inpopup=1") ?
E9 - Any chance to get those renderers not printing only XHTML but other output formats? Crazy idea I know, bur perhaps could be considered for future expansion of the whole thing and could be supported in a transparent way since day 0 (defaulting to XHTML).
Hope this helps... ciao
E1 The aim is to be backwards compatible as far as possible. So far, I do not see any major problems, although there may be minor visual glitches for pages that do no update their code. For example, if a page echos a layout table with left, middle and centre columns, there is nothing the new code can do to stop that appearing. (However, we will suppress the printing of left and right blocks when the page asks for them.)
E2 why do we have a $DB everywhere? Partly it is just a design choice. The two big wins I see are it makes it much easier to do things like the db transfer script that needs to talk to two databases; and and it makes it much easier to do unit testing, because you can make $DB point to a test double for the duration of the test. Also, it is something easy to grep for.
I would argue that variables like this are not evil global variables, but actually a nice implementation of the thread-local registry pattern using PHP language features.
E3 I think you have misunderstood. Module renderers do not subclass $OUTPUT. Module renderers are a new sort of renderer base class, so themes can choose to override them if they like.
E4 block slots will be identified by a short string name, like 'top', 'left', 'mymoodlecentre', etc. We probably need a simple coding guideline so that ones owned by the theme and ones owned by the content don't clash.
Block moving UI will be like rearranging activities in a course. When you click the move icon, you will see a drop-target in every gap in every block slot.
E5 Well, I vote for saving 6 chars per function name on the print_ version by taking advantage of the fact that $OUTPUT can be a verb in English, but perhaps I am trying to be too clever. Renderers should not have many other methods. Anyway, I am happy to change the function names if people want (it will be an easy search an replace. Alternatively, I can resort to argument by authority, and point out that the current naming evolved as I was discussing all this with Martin D.
E6 I hate the current $return parameters in weblib. Although they consistently started as the last paramter, that did not last as new parameters were added to some functions. Separate functions is simple, and makes the code clear. The only person it makes more work for is people writing a renderer base class, which is done rarely. Enable/disable modality is unnecessary, and a potential cause of bugs, if someone leaves the renderer in the mode you did not expect, so your output is either lost, or duplicated.
E7 Interesting idea, but I don't have time to consider it now. I think my changes should only make that sort of thing easier in future though.
E8 That is the whole point of $PAGE->generaltype. At the moment it will be up to the script to set this appropriately. (I can't think of a reliable way to set this automatically, but suggestions welcome.)
E9 We can only do that if we are sure that no Moodle code outside of renderers ever echos raw HTML. That may be true some time in the future, but there is a lot of cleanup first. Also note that I intentionally called these classes renderers, not views. In a classic MVC architecture, views are responsible for more things than our renderer classes do. Therefore there is a limit to how good a non-HTML output you could do. Search for a Martin Langhoff post in this forum about 'leaky abstractions'.
Thank you very much for your detailed comments Eloy.
To do AJAX like this consistently I think we really have to separate AJAX completely from the course formats and the themes.
This logically means that we need to enforce some guidelines on the themes to always define regions in a certain way with specific CSS class names for regions, sections and activities.
A good starting point is Javascript FAQ. That will guide you to all the other resources as well.
hth
Frank
For comparison, bbc.co.uk has already implemented this very nicely. Click on the 'edit' buttons in the block headers to see what other blocks can be added. Nice touch.
the existing ajax drag-drop functionality is nice for admin & editors. the proposed navigation and mockups for moodle 2.0 look excellent for usability! reminds me of iGoogle.
i might have overlooked this smwhr & apologies if this is beyond scope, but has there been consideration given to enabling students to customise the appearance ie. block layout of their learning environment (front page, mymoodle &/or course)? this wld be a victory in terms of personalisation.
Cheers, Chad
mike
Frank
- the public login page
- the front page on login
How would these pages be sculpted in the new theme system?
many thanks,
dan
Login page I had not thought about yet.
For index.php I was thinking we would let people put blocks in the central column (including HTML blocks). That immediately gives you lots of flexibility.
And probably in Moodle 2.1 we will write blocks that display all the things you can currently choose to display on the front page at Admin -> Front Page -> Front Page settings (Front page and Front page items when logged in) then the site front page can be all blocks, with nothing hard-coded.
Probably something similar for the My moodle page in 2.1 too.