[drupal-devel] Admin theme
Id like to pull this discussion out of the general usability improvement, because I feel this needs LOT of thought before it even close to ready. for me the admin theme has a few requirements: * it must be able to disable when someone feels he/she is not helped with it. * it must be overridable in a theme * it must be profilable (a forum site has a different concept of what pages are admin then a personal blog) Some ideas I came up with to tackle this admin theme issue are: * tackle this in the menu. Allow a flag/setting per menu entry 'IS_ADMIN' and 'ADMIN_SUGGESTED'. * tackle this in a blocks/sections alike interface, where sets of regexps define what pages are admin and what pages not. * tackle this in a separate admin-theme UI, where one can select a pre-defined profile (blog, forum site etc) then the profile will select for you what pages are admin and what not. I personally dislike the last item. it is not flexible enough, yet I still mention it, because it might be a starter for better ideas? Ber
I think the CivicSpace admin theme is the model we ought to be striving for. I love it. Bèr Kessels wrote:
for me the admin theme has a few requirements: * it must be able to disable when someone feels he/she is not helped with it. * it must be profilable (a forum site has a different concept of what pages are admin then a personal blog)
* tackle this in a blocks/sections alike interface, where sets of regexps define what pages are admin and what pages not.
A set of regexps is the way I'd like to see it implemented. The two points above would be satisfied by having regexps.
* it must be overridable in a theme
Wouldn't one just change the admin theme? What do you mean by this last point, Bèr? -Robert
At 12:41 PM +0100 25/9/05, Robert Douglass wrote:
I think the CivicSpace admin theme is the model we ought to be striving for. I love it.
As another reference point... I would not like to have the appearance of my admin pages different to the user pages. I think one of the strengths of Drupal is that administering content is as simple as browsing your site, seeing something you want to change and clicking the edit button. And when I'm doing real admin stuff... well I don't need a special theme to tell me I just clicked in the admin menu. Another down-side of this feature is that as a Drupal installer, setting up the basic site structure and appearance for my clients, I would have to create two themes instead of just one. So please make this optional. ...R.
Richard, have you tried CivicSpace to see how their admin theme is implemented?
As another reference point... I would not like to have the appearance of my admin pages different to the user pages. I think one of the strengths of Drupal is that administering content is as simple as browsing your site, seeing something you want to change and clicking the edit button.
This isn't changed in CS - you view and edit the node in the same theme.
And when I'm doing real admin stuff... well I don't need a special theme to tell me I just clicked in the admin menu.
It's not so much about the theme telling you that you clicked admin. The admin theme exists to support the large tables that are part of administration and that break fixed-width layouts.
Another down-side of this feature is that as a Drupal installer, setting up the basic site structure and appearance for my clients, I would have to create two themes instead of just one.
With CivicSpace, you get several themes in 1 (and that is growing). All of them share the same admin theme, and you don't have to install it separately. -Robert
High passions over an admin theme. If it were up to me, I'd have two theme settings, for a site theme and an admin theme. It sounds like the admin theme guys win, but you could just assign the same theme to both settings or default the admin setting to the site setting. How hard is that? Everyone can get their way...though I can just about guarantee that, freed from designing for a site-side theme, soem pretty impressive and useful admin themes will get rolled.
Perfect - as long as there is an easy way to edit the regexps that switch between the two. The solution described is exactly what I think people are looking for. But why stop there? If you're going to make a theme-switching mechanism that is built-in, easy to use and runs on regexps, why not work the bugs out of Bèr's sections module, make it easy to use, and make that core? Ship it with two themes blumarine and admin, with reasonable default regexps. -Robert Earl Dunovant wrote:
High passions over an admin theme.
If it were up to me, I'd have two theme settings, for a site theme and an admin theme. It sounds like the admin theme guys win, but you could just assign the same theme to both settings or default the admin setting to the site setting.
How hard is that?
Everyone can get their way...though I can just about guarantee that, freed from designing for a site-side theme, soem pretty impressive and useful admin themes will get rolled.
On Monday 26 September 2005 16:02, Robert Douglass wrote:
But why stop there? If you're going to make a theme-switching mechanism that is built-in, easy to use and runs on regexps, why not work the bugs out of Bèr's sections module, make it easy to use, and make that core? Ship it with two themes blumarine and admin, with reasonable default regexps.
Its absolutely a TINY module (fifteen lines or so). All it needs is to use the regexp functions from blocks (they need to be updated to become APIs and prolly moved to common.inc then). All bugs and usability issues with it, are currently because I have had no time to do this. The mayor part of the module now is just copy-pasted (and slightly broken) (old) code from blocks.module. Ber
On 26-Sep-05, at 9:51 AM, Bèr Kessels wrote:
On Monday 26 September 2005 16:02, Robert Douglass wrote:
But why stop there? If you're going to make a theme-switching mechanism that is built-in, easy to use and runs on regexps, why not work the bugs out of Bèr's sections module, make it easy to use, and make that core? Ship it with two themes blumarine and admin, with reasonable default regexps.
Its absolutely a TINY module (fifteen lines or so). All it needs is to use the regexp functions from blocks (they need to be updated to become APIs and prolly moved to common.inc then). All bugs and usability issues with it, are currently because I have had no time to do this.
The mayor part of the module now is just copy-pasted (and slightly broken) (old) code from blocks.module.
Ok... but I thought one of the big pushes for the admin theme camp is that there would be one true admin theme to rule them all... so that administration of a drupal site was uniform , and thus much easier to document (i.e. where to click, etc) ... then that information can be reliably written in docs (and books) without a "theme depenedent" caveat. or am i missing something 'cause I'm not a usability guy? -- James Walker :: http://walkah.net/
On Monday 26 September 2005 17:49, James Walker wrote:
Ok... but I thought one of the big pushes for the admin theme camp is that there would be one true admin theme to rule them all... so that administration of a drupal site was uniform , and thus much easier to document (i.e. where to click, etc) ... then that information can be reliably written in docs (and books) without a "theme depenedent" caveat.
or am i missing something 'cause I'm not a usability guy?
No, I think you might be mmissing the same some others seem to overlook. I, and other consultants (AFAIK in th thread it are all small consultants who are "against" an admin theme in some way) want flexibility above all. Not one of my sites is the same. Not one site will have the same admin as another. Thus A 'uniform' way is very hard. We really really really need something that is very flexible, if its up to me. And from the comments in here, I get the idea that most people like the sections idea: select the pages that are served in an admin theme in the exact same way as we define paths for blocks. So, my idea is that most people in this thread preferred: A core admin theme. A UI that allows you to define where theme 'FooBar' will be used. By default FooBar will be the admin theme. Is that correct, people? Ber
Bèr Kessels wrote:
On Monday 26 September 2005 17:49, James Walker wrote:
Ok... but I thought one of the big pushes for the admin theme camp is that there would be one true admin theme to rule them all...
we want flexibility above all.
If we shipped with (example here) bluemarine plus the CS admin theme, configured the way CS is (wrt the paths that constitute the admin section), I predict that very little work would be done in the future on the admin theme. Why? Because I find it very good already and don't see any reason to change it in any way. So in effect, it would become a standard. However, Bèr is right, flexibility is the real goal. Someone else might need a different admin theme, someone else might need none. In those cases they could delete the admin section and it would revert to blumarine for the whole site, or change the theme of the admin section, or make two separate admin sections (this would actually be useful for a site I'm working on now). Our usability gain in this area will come from the combination of adding flexibility, making good default choices, and having a way to revert to the default choices (important in my opinion, so that people can experiment freely but always return home). -R
Bèr Kessels wrote:
I, and other consultants (AFAIK in th thread it are all small consultants who are "against" an admin theme in some way) +1
Not one of my sites is the same. Not one site will have the same admin as another. Yeah. I need some way to easily distinguish the (7 and counting) Drupal sites I maintain. For me that was one of the advantages of integrating admin in the first place.
And yet I do recognize the need to allow for wide tables of the admin section in the theme. In essence I want the admin sections to maintain the look and feel of the site but have different layout - to me that isn't a different theme, although from a technical perspective that is one way to achieve such separation. Flexibility is indeed the key.
So, my idea is that most people in this thread preferred: A core admin theme. A UI that allows you to define where theme 'FooBar' will be used. By default FooBar will be the admin theme. It seems that way but I'd rather see section specific layout logic than a whole separate theme.
-- adrinux (aka Adrian Simmons) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@gmail.com> AOL/Yahoo IM: perlucida, Microsoft: adrian@perlucida.com
On Monday 26 September 2005 08:51 am, Bèr Kessels wrote:
On Monday 26 September 2005 16:02, Robert Douglass wrote:
But why stop there? If you're going to make a theme-switching mechanism that is built-in, easy to use and runs on regexps, why not work the bugs out of Bèr's sections module, make it easy to use, and make that core? Ship it with two themes blumarine and admin, with reasonable default regexps.
Its absolutely a TINY module (fifteen lines or so). All it needs is to use the regexp functions from blocks (they need to be updated to become APIs and prolly moved to common.inc then). All bugs and usability issues with it, are currently because I have had no time to do this.
The mayor part of the module now is just copy-pasted (and slightly broken) (old) code from blocks.module.
Ber
I actually fixed up the sections module recently for a client that needed it. I've just not gotten around to sending back a patch for it. I'll try to do that soon. :-) It's working fine for me now under 4.6.3. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On Sunday 25 September 2005 13:41, Robert Douglass wrote:
Wouldn't one just change the admin theme? What do you mean by this last point, Bèr?
Yup. That is what i meant. But I can think of (hardcoded) ways that do not make this as obvious. For example, shipping an admin theme inside a (civicspace) theme. Or for example, making this a more or less hardcoded thing in core. For this too, i see a few routes: An admin theme is just a theme like any other theme, only that it will be activated on certain places on your site. The other one is a theme('admin',$content) similar to theme('page'). the third route is a flag that becomes available to ,for example theme('page') somthing like $is_admin. Then it is completely up to the themer to do stuff. I personally prefer that last part, but I am afraid it will make the process of creating a theme even harder. Ber
Id like to pull this discussion out of the general usability improvement, because I feel this needs LOT of thought before it even close to ready.
Some ideas that come from my experience setting up Drupal in different environments, and general thoughts: * I would not need a complete new admin theme. I just need to theme slightly different some pages; the CivicSpace approach of checking if we're in an admin page and serving a different stylesheet is great. By default you would get a basic admin stylesheet which you could use or not. Integrating the admin layout would be easy if you design your custom theme (you would inherit it, as you do now with basic styles in misc/drupal.css). Moreover, you may inforce good practices in CSS codign, as people may follow or extend this basic CSS for its own purposes. * is_admin() would need a list of regexps, that I would also provide by default. Then, if you want to have certain page the frontend layout you would only need to remove from the regexp list. And viceversa. (Although I sometimes find regexps not too flexible or easy to use...) Regarding blocks: * When you enable a block you usually want it in the "public" (frontend) area or in the "private" (backoffice) area, but rarely in both. You now have a left sidebar zone and a right sidebar zone (and the new ones): I would make use of something related, an admin area (a more suitable name surely may be found). By default, when you create a block you must choose in what area you want it to show: frontend, back, or both (for the backoffice you would make use of the previously commented list of regexps, and you would not need to copy&paste the same list for every block). And this idea might lead us to the concept of subtemplates or subthemes, as other CMSs have, but I guess is a completely different topic (although in someway related, as you could consider this whole admin thing as a subtheme...) cheers, álvaro -- http://www.popmadrid.com http://www.furilo.com
* When you enable a block you usually want it in the "public" (frontend) area or in the "private" (backoffice) area, but rarely in both. You now have a left sidebar zone and a right sidebar zone (and the new ones): I would make use of something related, an admin area (a more suitable name surely may be found).
By default, when you create a block you must choose in what area you want it to show: frontend, back, or both (for the backoffice you would make use of the previously commented list of regexps, and you would not need to copy&paste the same list for every block).
And this idea might lead us to the concept of subtemplates or subthemes, as other CMSs have, but I guess is a completely different topic (although in someway related, as you could consider this whole admin thing as a subtheme...)
With the new regions in core, you can do admin regions (or admin-left, admin-right), which only show up on admin pages. Goba
On Sat, Sep 24, 2005 at 07:06:42PM +0200, B?r Kessels wrote:
Id like to pull this discussion out of the general usability improvement, because I feel this needs LOT of thought before it even close to ready.
for me the admin theme has a few requirements: * it must be able to disable when someone feels he/she is not helped with it. * it must be overridable in a theme * it must be profilable (a forum site has a different concept of what pages are admin then a personal blog)
Some ideas I came up with to tackle this admin theme issue are: * tackle this in the menu. Allow a flag/setting per menu entry 'IS_ADMIN' and 'ADMIN_SUGGESTED'. * tackle this in a blocks/sections alike interface, where sets of regexps define what pages are admin and what pages not. * tackle this in a separate admin-theme UI, where one can select a pre-defined profile (blog, forum site etc) then the profile will select for you what pages are admin and what not.
I personally dislike the last item. it is not flexible enough, yet I still mention it, because it might be a starter for better ideas?
I think this is the sort of thing which should never have a UI. I can imagine having a place to change which pages are part of the admin section being quite confusing. -Neil
On Monday 26 September 2005 23:53, neil@civicspacelabs.org wrote:
I think this is the sort of thing which should never have a UI. I can imagine having a place to change which pages are part of the admin section being quite confusing.
It will be axactly the same as the the blocks admin thing to select pages a block show up so, uuh, indeed. It will be confusing :p kidding: It is there already, docs are there for this, etcetc. All people need to do is copy paste some list of regexps (from a handbook chapter) and maybe tweak them a little. wouldnt that be ideal: a regexp library for blocks and sections? Ber
Hey guys, been following this convo but haven't chimed in yet. I do agree that a seperate admin area would be great as I'm actually making use of this in a current project. Screenshots: - non-logged in user: http://www.washsq.com/tmp/nocp.gif - logged in admin (homepage): http://www.washsq.com/tmp/cp.gif - logged in admin (logs page): http://www.washsq.com/tmp/cpa.gif Now all that I did was apply some special formatting to the admin menu table *only* and then on admin specific pages (e.g., admin/*) I have a few extra CSS rules that hide the main image and allow for full width tables. As you can tell, the admin section completely integrates with into the rest of the site, which I believe is the best way. However, the admin does have a few unique styles of its own. This was simple enough in the page.tpl.php file. But I think best bet for future Drupal versions would be to have a few extra admin theme-able functions for theming the admin menu block and subsequent admin/* pages to remove any extraneous images/etc that clutter up the interface and force forms to be too skinny. Just my 2 cents. ted (aka m3avrck)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26 Sep 2005, at 11:53 PM, neil@civicspacelabs.org wrote:
I think this is the sort of thing which should never have a UI. I can imagine having a place to change which pages are part of the admin section being quite confusing.
I'd like to have there be a block placed above the main content area, which when the user has the right permission, allows him to set the 'section' of the current page (theme, or theme configuration set.. that i mentioned previously). There would then be a checkbox saying 'cascade', that allowed you to cascade the setting all the way down with paths. I think this needs to live in the menu system, which possibly needs to be refactored so that we can apply arbitrary attributes to paths (ie: not just the ones in the db table) Perhaps a data field would be enough for this ? - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDOWolgegMqdGlkasRAnNIAJ9yKHAyU/YCoAO1UZNM5Ad9JSqvSgCeNaZA ykYLHrCD/AXCwvN5y6Oin/8= =WFt+ -----END PGP SIGNATURE-----
I'd like to have there be a block placed above the main content area, which when the user has the right permission, allows him to set the 'section' of the current page (theme, or theme configuration set.. that i mentioned previously).
There would then be a checkbox saying 'cascade', that allowed you to cascade the setting all the way down with paths.
I think this needs to live in the menu system, which possibly needs to be refactored so that we can apply arbitrary attributes to paths (ie: not just the ones in the db table) Perhaps a data field would be enough for this ?
Interesting idea. Couldn't you do the cascade with a simple wildcard? If you wanted to cascade all admin/node pages, you just write admin/node* in a sections table. No change needed to menu.module
Towards a proposal to solve this issue, I mocked up a UI... it presumes: 1) that an admin theme is available and bundled by default with drupal 2) it's not enabled by default 3) that modules identity the kind of functionality that they provide or that these proposed "zones" can be customized with a set of regexps. http://www.flickr.com/photos/factoryjoe/48039082/ Lord knows this is probably too simple and easy to use, but hey, I thought I would throw it out there to see about moving this discussion away from the "yes/no" admin theme discussion to "well if we have the *option* of an admin theme, where should it apply and how do I customize it per site?" Chris On 9/27/05, Moshe Weitzman <weitzman@tejasa.com> wrote:
I'd like to have there be a block placed above the main content area, which when the user has the right permission, allows him to set the 'section' of the current page (theme, or theme configuration set.. that i mentioned previously).
There would then be a checkbox saying 'cascade', that allowed you to cascade the setting all the way down with paths.
I think this needs to live in the menu system, which possibly needs to be refactored so that we can apply arbitrary attributes to paths (ie: not just the ones in the db table) Perhaps a data field would be enough for this ?
Interesting idea. Couldn't you do the cascade with a simple wildcard? If you wanted to cascade all admin/node pages, you just write admin/node* in a sections table. No change needed to menu.module
On Fri, Sep 30, 2005 at 11:45:28AM -0700, Chris Messina wrote:
Towards a proposal to solve this issue, I mocked up a UI... it presumes:
1) that an admin theme is available and bundled by default with drupal 2) it's not enabled by default 3) that modules identity the kind of functionality that they provide or that these proposed "zones" can be customized with a set of regexps.
I think options like "what is your admin section" are a bit beyond the beginner user. It could be great for ASPs and contractors, and those people don't necessarily need a UI for such a thing. Lets do the admin theme on any child page of /admin. Want create content to be an administration function? Use the menu module to move it to be a child of /admin. While we are on the subject.. anyone have any constructive criticism for the menu module or maybe some mockups? -Neil
On 30-Sep-05, at 12:19 PM, neil@civicspacelabs.org wrote:
Lets do the admin theme on any child page of /admin. Want create content to be an administration function? Use the menu module to move it to be a child of /admin.
+1 for this. Nice and simple. -- Boris Mann http://www.bmannconsulting.com
neil@civicspacelabs.org wrote:
On Fri, Sep 30, 2005 at 11:45:28AM -0700, Chris Messina wrote:
Towards a proposal to solve this issue, I mocked up a UI... it presumes:
1) that an admin theme is available and bundled by default with drupal 2) it's not enabled by default 3) that modules identity the kind of functionality that they provide or that these proposed "zones" can be customized with a set of regexps.
I think options like "what is your admin section" are a bit beyond the beginner user. It could be great for ASPs and contractors, and those people don't necessarily need a UI for such a thing.
Lets do the admin theme on any child page of /admin. Want create content to be an administration function? Use the menu module to move it to be a child of /admin.
While we are on the subject.. anyone have any constructive criticism for the menu module or maybe some mockups?
-Neil
My biggest critique of the menu is having to actually open a page to see sub menu instead of being able to click on the bullet to expand part of the menu tree.... Like when you need to get to admin/setting/mymodule there are three page loads required to get where you are going, instead of one.
On Saturday 01 October 2005 10:15 am, Darrel O'Pry wrote:
While we are on the subject.. anyone have any constructive criticism for the menu module or maybe some mockups?
-Neil
My biggest critique of the menu is having to actually open a page to see sub menu instead of being able to click on the bullet to expand part of the menu tree.... Like when you need to get to admin/setting/mymodule there are three page loads required to get where you are going, instead of one.
I seem to recall someone working on that as an Ajax feature for 4.7. Not sure if it's gone in yet. Of course, that brings up an interesting problem of theming. If you go "into" the admin section of the menu via Ajax, are you now in the "admin theme" zone or not? Ajax makes page-dependent logic (what blocks to display, what theme to display, etc.) really screwy. :-) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
participants (16)
-
Adrian Rossouw -
Adrian Simmons -
Boris Mann -
Bèr Kessels -
Chris Messina -
Darrel O'Pry -
Earl Dunovant -
Gabor Hojtsy -
James Walker -
Larry Garfield -
Moshe Weitzman -
neil＠civicspacelabs.org -
Richard Archer -
Robert Douglass -
Theodore Serbinski -
Álvaro Ortiz