Here somewhat late at night I found a quiet moment, grab a beer and tries to put down some of the overall things I'd like to suggest for post-1.0 of CMSms (beware, long post with grammatical errors):
1. Modulization of admin
I had the bad experience recently of proudly showing CMSms to a collegue of mine, advertising for the simpleness as well as power of "our" cms. He browsed through a couple of admin-pages and said to my grief, "It's waaay to advanced, you'll never get ordinary people to use this". Af properly beating him up (no, not really...), we talked about it, and he said that it would put quite a lot of users down having to see stuff like inputboxes saying "Metadata" etc. those things should not be show to everybuddy, and the admin should at least for some user-profile be kept as simple as possible. So I thought about how we could make the admin as finegrained as possible to allow several usertypes, with sevaral degrees of details on their admin pages. And what I came up with is that we shouldn't. In my opinion the ideal way to solve the problem is to have several seperate Admin-pages for different user-profiles. Let me explain... There's been a lot of talk already about making the admin a module. Having several admin-modules would result in a lot of redundant functionality, so the proper way of doing it would be to do a "AdminBase"-module, containing no GUI, but a lot of functions doing the admin-stuff. The several modules inheriting from this, for instance "AdminAdvanced" for something like the present admin, "AdminSimple" for something like 2 large icons saying "Edit Pages" and "log out" which every grandmother should be able to understand, and perhaps even a "AdminBlind" for a specialized administration made for blind people etc. These should act as frontends for the AdminBase-module which does the actual work.
Of course a lot of planning/testing/coding needs to be done, but I also got the idea of starting the admin-module off before removing the present admin. Everything but modules could be implemented while still running the old admin concurrently, and if the module-admin callbacks gets a different name, modules could be gradually ported to the new system.
2. Hierarchical organisation of modules
I had this idea of getting a more consequent organization into place. A more advanced way of deciding what modules is distributed with the core and which are not. First of all, as much redundant functionality should be seperated into utility-modules, like CMSMail, FEUsers etc. And then all major modules should be organised into a module tree (of course only well-tested modules, see my 3rd thought below). This ways it would be easy to do several distribution sizes matching the endusers wishes. Imaging something like:
Core (level 0)
AdminModule (level 1)
Smallest.zip This would make a very small distribution which could actually work for advanced users. But lets add some utilities:
Utilities: CMSMailer, SOAP, Ajax (I hope), FTP (if it makes sense at the time) etc. (level 2)
And some modules using the utilities, adding features:
FileManager, ImageManager, WYSIWYG (level 3)
Medium.zip Now it's bigger but quite a lot easier to administrate. But next level could be to add some actual frontend features:
News, FEUsers. ThemeManager, ModuleManager etc. (level 4)
Recommended.zip This is a fully working CMSms with basic modules. The recommended release about the size of the present distribution. But we could also do a full version:
Calendar, Album + any other welltested module
Full.zip A feature-rich cms fulfilling most needs
Of course I've forgotten a lot of modules etc. but you should get the idea of what I'm proposing. This of course all makes quite some demands of the module-developers, which leads me to:
3. Module Quality Insurance and Testing
I'll be the first to say that writing modules is great fun, but doing all of the smaller details making it integrate, render and adminsitrate perfectly is not always that amusing. But if the CMSms in a more fullfeatured way should gain users I think some kind of list of minimal demands of modules should be put down. And a kind of team (we already have a quality insurance team) should make sure modules follows these demands before they are accepted into the tree above. The rules could consist of stuff like:
a. Minimum CMSms-version should be correct and set
b. Dependencies should be properly set and not just assuming that the modules are there (eventhough some modules mostly are)
c. Module output should be easily changed where logical, for instance by editing CSS/Templates through the admin. The method of supplying CSS-code in the help-page is not that userfriendly.
d. Helppage should be set and properly formatted
e. Perhaps some visual standards for admin-pages (tabbed layout, table-layout etc.)
f. Default templates/css should conform to w3c standards.
And probably some other things could be decided as well
Of course a lot of modules are still under heavy development (mine are at least), but I think we should work towards some kind of common set of standards for modules making the administration as consistent and streamlined as possible.
I think that's all from me for now as my beer is now empty. Feel free to comment on my thought or laugh you way to the next forum-subject
Best regards
Morten/Silmarillion
