Two column admin theme concept

[Philipp]

Two days ago, an idea about a new admin theme came to my mind. Some hours later, I've crafted a first concept in Adobe Fireworks....

The look and feel of the admin is important

Two months ago, I've introduced some teachers into ProcessWire. They were none-technically people. At the end, they knew how to use the admin panel to create content or update a gallery on their new page. However at some points, they got confused with parts of the admin theme -beside the problems with our concept on how to use fields and templates for creating content.

I think one factor why Wordpress became so large, was the great Adminpanel. It works well and easy (as long as you have a blog and not a twenty-plugins-for-text-pages-site). Editing content on a daily basis is the main task of my customer. I've to take this aspect serious.

Problems I wanted to solve

• Have the page tree always visible. If I do not click the right link, it will be closed after I've finished editing my site
• More visuals like icons.
• Simplify some workflows. Creating 3 or 4 pages can result in multiple unnecessary clicks.
• More focus on important links like the tabs.
• Guide my customer through some action. Help them to repeat simple tasks.

The concept

First: Nothing is perfect and its not possible to find one single solution for everything. This was just done in a couple of hours and it's only the first iteration.

Quick action button

Next to the ProcessWire logo is the quick "Quick Actions" button. It should be possible, to configure it like: "Create a new Page with Template X with page Y as a parent". Use it for skyscrapers, news or galleries. (Yes i know, the arrow is pointing upwards. This is wrong)

Two column layout

The page tree is always visible (as long as we are in the pages view). It can be navigated as the normal page-tree. If you click "edit" it will become highlighted. Every action that would take you to a new page, would be displayed in the other half of the monitor. Speaking of a "half monitor" - I think that most people use a screen resolution of atleast 1300px. The sidebar should take up to 1/3 of this. On smaller screens, it will become hidden by default or we just simply step back to single pages for each view. If the content is to long, the sidebar becomes scrollable.

Page tree

I like the Template Decorator made by mindplay.dk. It fits the concept well with black outline icons for every type of template. The same icons could be used in the Quick action menu. I'm note sure what to do with the "move" action. 

To Do list

• Think more about the behavior of the elements. 
• Design the modules view. 
• Rework the search and the top menu.
• Options to "brand" the panel for agencies while keeping the ProcessWire logos.
• What happens if we are on mobile (small screen) devices?
• Listen to your feedback.

[kongondo]

Wow Philipp! Looking nice! Keenly watching this , thanks!

[Craig]

I'll second that - it looks amazing!

[landitus]

Great work Philipp! I agree that the admin experience for non-tech or unexperienced users is really important for any CMS. I think that while ProcessWire has a nice admin it could really benefit with some of the ideas you're trying out. I had the same thought about what makes Wordpress so famous and user friendly and ultimately the design of the admin has played a big part in it.

I want to stress out that I have nothing against the core admin (  ), but I think It could still be improved to achieve a more modern look (whatever that means) and be more user-friendly, which for me is the top concern towards using PW in commercial projects. I really like what some people have done with themes and such, but I still  always use the default one. 

I would be awesome to have some special place in the forums to talk about design of the admin (that ships in core). Mostly to talk about the actual user experience and the user interface, and posting ideas (and iterating) with the core team. I am thinking that some of these ideas would eventually make it to core and I can see my clients (and people in general) benefiting a lot.

[kongondo]

Btw, I think this thread is in the wrong forum? It should be in http://processwire.com/talk/forum/12-themes-and-profiles/ , no? At "worst" it should be in http://processwire.com/talk/forum/25-dev-talk/ but definitely not here (pub), me thinks

I would be awesome to have some special place in the forums to talk about design of the admin (that ships in core). Mostly to talk about the actual user experience and the user interface, and posting ideas (and iterating) with the core team. I am thinking that some of these ideas would eventually make it to core and I can see my clients (and people in general) benefiting a lot.

I think there was a thread discussing this? Anyway, if one doesn't exist, feel free to start one by all means

[Nicole]

I hadn't thought about the page tree, and that is absolutely useful (thanks for that). I did start incorporating the "quick links" for my mom's website. That way she could easily add new products (she doesn't like to click much). I have a similar dropdown that states: "New (insert name of product)", she just had to click that, add the picture, description and done. I think the quick links are great for specific jobs, so it fits each client's needs.

So, kudos for this, I love it.

I think what makes PW so awesome is that you can personalize the back-end to your needs, not just the front-end.

[diogo]

Nice work Philipp. I like it that the tree is always present while working with pages. There were some tries to do this already, but in my opinion, none of them worked well. Are you planning to have the sidebar within each page (refreshing when the page refreshes), or to bring the pages to the content area via Ajax?

[Philipp]

Thanks for your feedback. 

@diogo I'm mostly a designer, not a programmer. I currently have no plan or experience to code this concept.

It would be nice, if the right side of the screen would load dynamically via AJAX. There was a concept with Lightboxes loading the admin views but we would have the right div insteaf od a popup. Additionally,we have to make sure, that the URLs are right.( HTML5 History pushState?).

I'll post some alternatives color schemes later.

[apeisa]

Always visible page tree has it's merits. But I also find it little overwhelming. When I evaluated different CMS products few years back I did found Silverstripe interesting, but remember that "always visible pagetree" was little messy. PW way is much more "zen" This is how it looks now:

[kongondo]

MODX also has always visible. I would prefer an option to always have it open or collapsible (not-open) - hidden like an accordion...I like the real estate offered by PW but sometimes miss the possibility to quickly get to a page on the tree

[Nicolas]

The always visible is great for quick navigation between pages. Silverstripe approach is great as both menu and pages panels are collapsable.

Phillip, that's a great admin concept

[ryan]

Nice job Philipp, I like where you are going with this. Thanks for putting your time and skills towards this. Having a new default admin theme is something I think we need to approach soon, and contributions like this are very much appreciated. I also think your work here is nice to look at and very well designed. 

With regards to an always visible page tree: not showing the page tree when in the page editor is very much a conscious decision. I recognize there are benefits and drawbacks and that it's a compromise either way. Here's the thinking of why we currently compromise on the side of not showing it:

The default admin theme needed to be something that could scale near infinitely, and delegating the page tree to a sidebar introduces a lot of natural limitations (though none that scrollbars can't solve, but I'm not a fan of them). Another goal was to keep the user focused on the page they are editing by having the browse and edit states be very separate things. Lastly was the issue of overhead: generating a page tree involves a lot of work, and can contribute to making the admin feel slow… especially if having to generate it for every page edit. (Though this may be something caching could solve, but it could be tricky to develop: clearing such a cache after each page save might defeat the purpose). I did actually test out both SilverStripe and MODX before developing ProcessWire–I wasn't pleased with their page trees and really wanted to differentiate ourselves from that. Though your design here for the page tree does do that–it looks a whole lot better than what's in other systems. 

Those are some of the reasons why we'd decided not to show the page tree when in the page editor. But I recognize there are some real benefits: I like the possibility of being able to quickly jump between pages when needing to make edits to multiple pages or needing to add a bunch of pages. I also like the aspect of seeing where I am in the tree… While the breadcrumb trail accomplishes it, the tree can reinforce it. But these benefits were not enough to outweigh the benefits of not showing it. Still, if there is great demand, or if people would prefer the option, I'd be supportive of it as an option in the default admin theme. Though do wonder if a full-width, click-to-reveal panel at the top of the screen would better solve the scalability aspect? Whether sidebar or top-panel, if these things open only when hovered or clicked, we could solve the overhead problem by just doing it with ajax. 

For the Quick-Add button, I believe we could easily support this on any templates that have family settings defining a single required parent. When templates are configured that way, they could have a checkbox that says "Add to quick-action list?" or something along those lines. 

Keep up the great work. I look forward to seeing more. 

[kongondo]

FYI,

Regarding sliding panels, sometime back I was working on an admin them with a top down slider/panel but never got to finish it...Here's the ugly screens....nowhere near Philipp's beautiful work

[SteveB]

Earlier today I was thinking of a use/case situation where I might use parenting or page fields to tie together some related pages. The better approach was page fields and really the only reason I was even trying to make it work with parenting is that it would be easier to explain to a client how to set it up. This is a case where a client-oriented admin interface could make it easy to select the related pages and declare the relationship but hide the actual details of how that relationship is expressed in PW.

In my pre-PW work I've done a lot of custom admin pages for clients to use. It really pays to keep these very focused on application-specific work flow, terminology, etc. I don't expect clients to accept the level of abstraction necessary to work directly with the PW data. The admin pages provided by core should be a tech tool, guaranteed to be scalable and capable of accessing anything any application might have. Sure, there's room for improvement but what about putting that effort into easing the task of constructing a more focused and mediated admin interface for clients to use.

I haven't looked deeply at how the admin pages work now but given the modular way things tend to be done in PW I'd think we could do something to streamline the building of custom admin pages. Sort of an admin construction kit. Let the client deal with "skyscrapers" and "cities" rather than "pages" even though underneath, they are all PW pages. Reuse the basic underlying CRUD while adding application specific prompting and tools to help the user with the more focused task of working on a city, skyscraper, category, etc. Build a custom interface where clients can do their routine tasks easily. if they end up with an odbball situation beyond the scope of what you built for them you can always talk them through using the standard admin interface, and if that becomes a habit you extend their custom interface.

Personally, I don't think a single admin interface is ever going to be optimal for both programmer and client. Those are different audiences with different needs. I'd be wary of anything that compromises the ability of the standard admin pages to deal with huge amounts of data etc.

[Philipp]

Thanks for the feedback.

The default admin theme needed to be something that could scale near infinitely, and delegating the page tree to a sidebar introduces a lot of natural limitations (though none that scrollbars can't solve, but I'm not a fan of them). Another goal was to keep the user focused on the page they are editing by having the browse and edit states be very separate things. Lastly was the issue of overhead: generating a page tree involves a lot of work, and can contribute to making the admin feel slow… especially if having to generate it for every page edit. (Though this may be something caching could solve, but it could be tricky to develop: clearing such a cache after each page save might defeat the purpose). I did actually test out both SilverStripe and MODX before developing ProcessWire–I wasn't pleased with their page trees and really wanted to differentiate ourselves from that. Though your design here for the page tree does do that–it looks a whole lot better than what's in other systems.

I agree with you, Ryan. PW is focused on scalability and a simple interface. Pressing the page tree into a sidebar could cause scrollbars. And I'm not sure how to handle the client side AJAX while maintain a good site performance.
ProcessWire has this zen focus, because there are not so much buttons, not 4 positions for links or three submenu levels. Showing only one view (edit page, page tree, create page) is really good. But sometimes when the tree collapses because I've took the "wrong " way back from editing a page it becomes anoying.
The concept should always leave the option, to just use this "pure" editing by hiding the page tree.
 

In my pre-PW work I've done a lot of custom admin pages for clients to use. It really pays to keep these very focused on application-specific work flow, terminology, etc. I don't expect clients to accept the level of abstraction necessary to work directly with the PW data. The admin pages provided by core should be a tech tool, guaranteed to be scalable and capable of accessing anything any application might have. Sure, there's room for improvement but what about putting that effort into easing the task of constructing a more focused and mediated admin interface for clients to use.

But this would add another layer of abstraction to the site. A page tree is different to e.g. a bucket of blog posts as seen in Wordpress. I know, sometimes we build sites that have a slightly different structure on the front-end or we need to fit the internal workflows to the CMS admin panel while having a completely different front-end.
Ryan wrote something on this here: http://gadgetopia.com/post/7242 (go to the comments)

I haven't looked deeply at how the admin pages work now but given the modular way things tend to be done in PW I'd think we could do something to streamline the building of custom admin pages. Sort of an admin construction kit. Let the client deal with "skyscrapers" and "cities" rather than "pages" even though underneath, they are all PW pages. Reuse the basic underlying CRUD while adding application specific prompting and tools to help the user with the more focused task of working on a city, skyscraper, category, etc. Build a custom interface where clients can do their routine tasks easily. if they end up with an odbball situation beyond the scope of what you built for them you can always talk them through using the standard admin interface, and if that becomes a habit you extend their custom interface.

Eam admin pages. Sort of an admin construction kit. Let the client deal with "skyscrapers" and "cities" rather than "pages" even though underneath, they are all PW pages. Reuse the basic underlying CRUD while adding application specific prompting and tools to help the user with the more focused task of working on a city, skyscraper, category, etc. Build a custom interface where clients can do their routine tasks easily. if they end up with an odbball situation beyond the scope of what you built for them you can always talk them through using the standard admin interface, and if that becomes a habit you extend their custom interface.
 
Personally, I don't think a single admin interface is ever going to be optimal for both programmer and client. Those are different audiences with different needs. I'd be wary of anything that compromises the ability of the standard admin pages to deal with huge 

The admin construction kit sounds really good - especially when multiple admin themes become a default feature of PW(v2.5?). I'm not sure about the hard split between developers and customers. Maybe only a slim version of the admin theme would be enough?

[Nico Knoll]

I already built something kind of similar: 

http://processwire.com/talk/topic/4209-dark-business-10/ 

[diogo]

I already built something kind of similar:

Hm, unfortunately I'm including your theme (which I love) here:

There were some tries to do this already, but in my opinion, none of them worked well.

[kongondo]

..... I like it that the tree is always present while working with pages. There were some tries to do this already, but in my opinion, none of them worked well....

@Diogo,

Maybe you'd like to clarify what you mean by "none of them worked well". I am not disputing your position, just pre-empting the inevitable question from others.."what did not work well?" {although Ryan maybe alluded to some of these above}. It will also keep this discussion going. 

Edited September 2, 2013 by kongondo

[landitus]

I also think the tree as a sidebar presents its challenges, both on the design and coding aspects. Also, it generates more noise on the page. The ability to toggle it helps a lot. I think this is those kinds of decisions that generate some divide and aren't easily reconciled.

Take a look at this example by Squarespace. It doesn't look very scalable, I guess.

But my point of view is that other improvements that are talked here are sure to generate more goodness and acceptance. Things like bigger text and inputs, for example, place more focus on the content, which is always a good thing. It won't change the general structure of the admin, but certainly make it better. Aspects like iconography and color are included in Philipps and Nico's proposal, which I like a lot. This would still maintain the admin's clean and un-bloated look, which is an asset in this case.

The idea of "building blocks" is very appealing because PW is a really modular system and that philosophy should be taken into account in the UI. Bootstrap, Foundation and other CSS frameworks take this idea of building blocks into account and are good examples. Those look like good starting points and inspiration in my opinion (even if they are not used, the organisation is very good). I imagine every admin PW like a grid full of widgets that can be closed/opened and have different interactions (page selection, image uploading, text input, etc). The tree is a whole different beast and UI improvements are already present in Philipps and Nico's proposals. We even talked about some stuff here: http://processwire.com/talk/topic/4292-search-filters-and-options-for-the-page-fieldtype/#entry42038

In all, I'm happy there's a discussion about this topic!

Edited September 2, 2013 by landitus

[diogo]

@Diogo,

Maybe you'd like to clarify what you mean by "none of them worked well". I am not disputing your position, just pre-empting the inevitable question from others.."what did not work well?" {although Ryan maybe alluded to some of these above}. It will also keep this discussion going. 

In the case of Nico's theme, that I still have installed on one site to see if I could get used to it (this is probably the longest that I had a theme installed on a website instead of the default), The problem is that the sidebar has two moments (menu and tree), which is pretty confusing for me, especially on smaller screens (I'm talking 15.4'', not an ipad). The content area is too small, when the tree is open, and you can't hide the menu without hiding the tree. Besides this, the items on the menu behave differently when pressed ('pages' opens the tree, while the others open their pages with a browser window refresh. Custom pages simply kill the sidebar). Phillipp addressees some of these problems pretty well in my opinion, but ...read under

Things like bigger text and inputs, for example, place more focus on the content, which is always a good thing. It won't change the general structure of the admin, but certainly make it better. Aspects like iconography and color are included in Philipps and Nico's proposal, which I like a lot. This would still maintain the admin's clean and un-bloated look, which is an asset in this case.

Bigger text and iconography are exactly what I dislike in this solution. I think the default admin makes a great job at being minimalistic (not in a trendy, but in a practical sense) and very usable. In my opinion Icons are distracting.

[kongondo]

@Diogo, Thanks for the clarification.

@As has been pointed out earlier, there will be varied opinions about this (reminds me of when MODX revo was deciding on a default theme ). I think I like the idea about an admin construction kit (although, now that I think about it, I fail to see how much different that would be from the present system since Ryan has pretty much followed a consistent method [e.g. jquery ui css classes] to build the default theme) that can be adapted to suit different needs. So, if we had these building blocks well-documented (i.e. what css classes affect what, where they come from, what the different PHP blocks do, etc) that will be your admin construction kit right there. But wait a minute, we already have this documented here by Ryan. Maybe improve on that? I don't know. Until I'm convinced otherwise (or catch enough sleep, whichever comes sooner ), I would continue supporting the minimal, no fuss default theme we have to be the default but make sure stuff like icons, etc. can be plugged in easily by those who wish to. Most of the changes we are discussing here are, after all, stylistic (CSS). Maybe the default theme needs a few tweaks..

A while back I was toying with the idea of creating a skeleton admin theme, a sort of admin starter kit. A simple black and white stripped down theme with heavily commented CSS , maybe with a few CSS options to move some stuff around, e.g. tree on left, tree on right etc but with the jQuery working as normal. As with many other ideas in my head...this remains just that...an idea    

Edited September 2, 2013 by kongondo

[Philipp]

To justify the optional sidebar:

Screens under 1200px will not see the sidebar. It will be hidden by default.

I've set the first offset margin to 15px and then increase the margin by 20px each level.

On a 1280px Screen with 1/3 sidebar I get around 425px.

On a 1920px Screen (24" HD Office) I will have 640px for the sidebar.

The "problem" are different lenghts for the text + the edit|view|new buttons. Question: How many sublevels do you usually have?

Bigger text and iconography are exactly what I dislike in this solution. I think the default admin makes a great job at being minimalistic (not in a trendy, but in a practical sense) and very usable. In my opinion Icons are distracting.

I like that aspect. In the next version of the concept I've stripped down some icons. I'm using them for arrows and the template type of a page. I think, it's the tiniest way to display the "type" of template of a page.If not, my customer just thinks of pages and not of galeries,blog posts, news, products,...

The top bar is now white. I've chosen the pink/magenta color for everything that has an action, the blue colorto indicate things. The font size also went done from 18px to 16px and the overall look is now a little bit more compact.

The second screenshot demonstrates a 1280px window size.  

 

A while back I was toying with the idea of creating a skeleton admin theme, a sort of admin starter kit. A simple black and white stripped down theme with heavily commented CSS , maybe with a few CSS options to move some stuff around, e.g. tree on left, tree on right etc but with the jQuery working as normal.

This would be a great start. Especially with the theme switcher for the upcomming versions. We could quick build a custom view for a client.

Another thing to the "Admin Kit". Maybe the admin-themes can get some sort of an option page where we can disable things like the sidebar. Not sure about this one...

[diogo]

Another thing to the "Admin Kit". Maybe the admin-themes can get some sort of an option page where we can disable things like the sidebar. Not sure about this one... 

I would welcome the possibility of choosing a theme per role or user, like this we could build customized themes only for clients without worrying about a big part of the system (template editing, modules page, etc). From there, even deeper changes could be done.

[kongondo]

...Another thing to the "Admin Kit". Maybe the admin-themes can get some sort of an option page where we can disable things like the sidebar. Not sure about this one...

I would welcome the possibility of choosing a theme per role or user, like this we could build customized themes only for clients without worrying about a big part of the system (template editing, modules page, etc). From, even deeper changes could be done.

I like these two ideas Maybe I am under-thinking this but I but don't think these two ideas would be "very difficult" to implement? The main magic as I see it, happens in the default.php and topnav.inc (permissions check). See my proof of concept from a while back here..http://processwire.com/talk/topic/3754-proof-of-concept-processwire-admin-theme-switcher/

I would want the possibility to install multiple themes and choose which one to display. That's what I show in that post...If Admin themes were stored under "settings", changing themes would be a breeze.....Not sure how the upcoming theme switcher will look like though

Edited September 2, 2013 by kongondo

[apeisa]

Philipp, looks great. Can you show how fields looks without that thin border/shadow and maybe with black/grey labels? I think we should aim for "less borders / boxes" feel. I really like your iteration, very clean looking!