The first thing to do is to create block categories, similar to the var categories that exist already. This is mostly just because it would be really useful, and also because it would make themes a bit easier to deal with.
The question of interface I haven't answered to my satisfaction, though I have narrowed it down to two options: display all blocks and their descriptions on one page, like the vars do it, or keep the same interface but filter the list of blocks you can select to the ones in that category. I dislike the first option because blocks, by necessity, have large text boxes, and will therefore make for extremely long pages; however, I dislike the second option because it could be confusing that the boxes you can select are not all there at the same time, so it doesn't act similarly to the site controls interface. I'm currently leaning towards the first option.
The categories I will create for the default blocks will be (subject to change if someone suggests something better):
- site_admin
- advertising
- ad_templates
- boxes
- content
- display
- email_content
- forumzilla
- misc_bits (I don't like this name; what could I call a category for stuff like |dot| and |header| and |footer|, as well as the various other miscellaneous bits of html that are inserted into the page)
- page_templates
- rss
- submission (covers voting as well, or seperately?)
Any blocks that are not assigned to a theme are considered to be part of the 'default' theme, so that scoop sites that don't want to use themes can keep their blocks exactly as they are and have everything still 'just work.' A new theme will be created by giving it a name and choosing which theme to use as a base, or 'parent'. A new theme does not have to duplicate all of the blocks; any blocks it is missing will be taken from its parent theme, and the default theme is ultimately the parent of all themes. It will also be possible to 'copy' a theme, ie to make a duplicate of the theme but with a different parent. This could be useful if you wanted to make a couple of main themes, each with a couple of possible colour schemes; the main themes could contain most all the changes, while the 'colour' themes would contain only colours, and have one of the main themes as a parent.
Some changes will be made to the blocks table to allow this; specifically, the fields "description", "category", "theme", and "parent" (parent theme) will be added.
To work with a theme as a whole, the blocks would be filtered such that the blocks for that theme only are displayed, plus blocks from the parent theme where the theme is missing a block, so that a full complement of blocks are available. While working with the theme, any changes made to a block that the theme does not explicitly have a version of causes a new block to be created inside that theme, and the block from the parent theme is left unchanged.
When not working with one theme specifically, selecting a category will show the blocks in that category for all themes; this makes it easy to, for example, add a new item to all the theme-specific versions of one block at the same time and in as consistent a manner between themes as desired.
The admin will be able to select which theme is served by default, for example to a given user-agent; ie, the 'light' theme could be given to user-agents matching known PDA or console web browsers, a 'netscape' theme using tables for layout could be given to netscape 4.x users while the default theme uses CSS positioning. The admin will also be able to select which theme is served to non-logged in users, and to newly created accounts as well.
The users will be able to select which theme they want to use at any time, out of any of the options. The heirarchy of the themes should be clear in a simple to understand way; for example if the site had a 'beginners' and an 'expert' theme, the beginners theme having extra help text (such as 'scroll down to see the comments' at the end of a story) and each having a sub-theme consisting only of changed colours, the user would see:
in their display preferences and could choose any of those options, including simply 'beginners' or 'expert' or even 'default'. Note that 'default' is the only theme that must be fully defined, as it is the parent to all other themes. So admins would set up the default theme to their satisfaction, similar to what they do right now without themes, and only then start adding additional themes.
Eventually, when all the HTML is ripped out of the scoop code and placed in blocks, it would be relatively simple to add internationalisation by creating a new theme then, while leaving the structure unchanged, translating all of the text to the new language. To facilitate this, a way for admins to set themes based on the language content negotiation could be added with an interface similar to that for selecting themes based on user-agent, if I managed to figure out how to recognise content negotiation.
