New ProcessWire admin theme on dev branch

[ryan]

@adamspruijt, yes please submit any feedback you'd like, that's what this thread is for. I would just request that any feedback be based on actual use/testing the theme itself rather than the screenshots, as the screenshots are fairly limited in scope relative to the theme. We may have to wait to act on some of the feedback until we approach the bigger admin-theme project in the future, but all feedback is appreciated either way. For instance, if there is a consensus that the page list actions are too small, I'll be glad to increase the default size of them. That's also a fairly simple thing to do. 

and it's still on the warm. I'm lost why it's not working.

Chances are that the value in your session was already set to something, and the session value overrides the $config value. To resolve that, just set your session value to match the $config value, or clear out the session value by specifying an unknown color theme. 

/processwire/?colors=classic

/processwire/?colors=poopst

ok.to poopst in here ?

I'm not sure that I like the sound of that, but if you mean post a color theme file here that's great. 

[adamspruijt]

We may have to wait to act on some of the feedback until we approach the bigger admin-theme project in the future

Would it maybe make sense to have a separate admin theme repo that I (we) could fork and share contributions and tweaks? Then if someone say "I think such and such is better" and we all agree on it I can then they can say "hey look I already did it, Here!" ..... I'm a git noob so I don't know the best approach here and don't want to make things more complex than they need to be, but at the same time requiring you to implement ever agreed tweak and interpret other harder to describe changes may lead to some inefficiencies?

EDIT

Also a quick thought as I'm looking at the other color options. From what I understand making my own that work with your theme (and this would go for any 2.4 theme) is as easy as giving a unique name so I could have main-weird.css and then define ?colors=weird ... since this file can more or less override the colors and styling of any part of the theme would it maybe make sense to call these "skins" or "styles" etc? So we would use:

$config->adminThemeSkin = "weird";

?skin=weird

I know this is a tiny matter of semantics but maybe it represents the function of these files better. Also we could then consider having an area to share skins per theme (maybe listed on the theme's module page?). So I could say.... make a "skin" for the "Default Theme" geared toward accessibility that uses giant fonts and high contrast colors and it could be listed on the Modules site as a skin available for the default theme? I'd say generally a lot of the time I've made themes they've started out of the desire for very minor tweaks to the default theme (or my own). Also sometimes I've wanted to make some decently large style changes to one of my themes (or others) and offer it to the community but also don't want to bombard the theme directory with subtle versions of themes every time this happens.

Thoughts?

[horst]

 Chances are that the value in your session was already set to something, and the session value overrides the $config value. To resolve that, just set your session value to match the $config value, or clear out the session value by specifying an unknown color theme. 

/processwire/?colors=classic

/processwire/?colors=poopst

I have had same behave. My Session-Key adminThemeColors is 'main'

I also have copied over the main-classic.css to main.css to get the right PW-feeling

Nice work, nice improvements, Ryan!

PS: using the GET-Var in URL has only switched for one time to classic and with next loading (without GET-Var in URL it goes back to warm)

I also have killed all session files etc. pp,  - only copying main-classic.css to main.css worked for me.

Edited October 4, 2013 by horst

[ryan]

Would it maybe make sense to have a separate admin theme repo that I (we) could fork and share contributions and tweaks? 

That's fine with me, though it doesn't necessarily have to be on GitHub. I think it's just as easy to post any new SCSS file(s) in here along with a screenshot of what's proposed. 

PS: using the GET-Var in URL has only switched for one time to classic and with next loading (without GET-Var in URL it goes back to warm)

I think there was a bug in there when I first posted it related to this (colors switching back to main). I did fix it and think (hopefully) that was fixed in yesterday's commits. 

[adamspruijt]

That's fine with me, though it doesn't necessarily have to be on GitHub. I think it's just as easy to post any new SCSS file(s) in here along with a screenshot of what's proposed. 

I was just playing around with the new theme and thought the same thing. Sounds like a plan, I will play around more soon.

[Soma]

There's a bug:

$defaultColorTheme = 'warm';
if($input->get->colors && !$user->isGuest()) $colors = $sanitizer->pageName($input->get->colors); 
    else if($session->adminThemeColors) $colors = $session->adminThemeColors; 
    else if($config->adminThemeColors) $colors = $sanitizer->pageName($config->adminThemeColors); 
    else $colors = $defaultColorTheme;

if(is_file(dirname(__FILE__) . "/styles/main-$colors.css")) $session->adminThemeColors = "main-$colors";
    else $session->adminThemeColors = "main";

$config->styles->prepend($config->urls->adminTemplates . "styles/$session->adminThemeColors.css?v=5"); 
 

echo "/styles/main-$colors.css"; // results in -> /styles/main-main.css

who finds what's wrong?

It doesn't work with with all I tried untill (sessions, browser) I looked into what it's doing there. At least I think.

--- 

Edit: Also by luck I found that my color picker, selecting swatches won't do anything (changing the color), reason it stops working must be with the new admin theme (for no obvious reason), after half an hour I gave up now. It's working with old theme and my teflon, other themes. Really really misterious. No errors, the click event is registered but data attribute on elements aren't updated.

[SiNNuT]

If we're talking apps i would also like to mention prepros, it does a lot

http://alphapixels.com/prepros/

If we're talking apps i would also like to mention prepros, it does a lot

http://alphapixels.com/prepros/

[adamspruijt]

Things like this confuse me...

#masthead, #headline, #content, #footer {
    padding-right: 20px;
    padding-left: 20px;
}

Turning this off has little visual impact and seems redundant to the function that the .container serves, this kind of styling should really be handled by a class anyway.

Also the markup and subsequent use of position:absolute; on items in the #masthead seems bizarre to me. If instead you wrap the top and bottom portion of the masthead separately and style them accordingly there is no need to absolute position the elements, simple floats will do. There is also then no need for the #masthead_shade element. 

<div id="masthead" class="masthead">
	<div id="masthead_top">
		<div class="container">
			<!-- LOGO -->
			<!-- SEARCH -->
		</div>
	</div>
	<div id="masthead_bottom">
		<div class="container">		
			<!-- NAV -->
			<!-- BREAD -->
		</div>
	</div>
</div>

With this setup we can create consistent height on the nav and breadcrumbs by simply setting:

#masthead_bottom{
        background: $masthead-secondary-bg; 
        border-top: $masthead-secondary-border; 
        line-height: 2.5em; 
} 

    

Then the elements just need to be floated.

This also wouldn't prevent you from doing what you currently are with the mobile version of the masthead, though you would need to remove the float obvious (although just removing the floats and letting the elements fall in place naturally would be how I would do it). With other small tweaks the difference is minimal (though I prefer CAPS and font-weight:bold; in my nav/pageLinks generally). Oh, I also added outline:none; to the search query, can't stand they way those outlines looks.

EDIT:

Also the search query is to hard to see, maybe drop the transparentize value to 0.7?

#ProcessPageSearchQuery {
	height: auto; 
	padding: 2px 7px 1px 7px; 
	font-size: 1em; 

	border: 1px solid transparentize($reverse-text-color, 0.7); 
	
	background: transparent; 
	width: 100%; 
	color: $breadcrumb-link-color;
	border-radius: $button-radius; 
	outline: none;
}

EDIT 2

Oh and I increased the PageListItem padding, though this should maybe be handled by line-height 

.PageListItem {
	padding: 0.5em 0;
}

[diogo]

I din't come to the forum a lot lately, but I did install the theme to try it out. Great effort Ryan! There lots of good things in it.

I don't like the color schemes very much and I think it's not very positive if you are planning to use the warm as default because in my opinion it's important to keep the corporate colors of PW. I think the warm scheme is the one that works better for now, not because of the colors, but because it might have had more love than the others from your side

Two new things I don't like:

• The dropdowns are too stuffed and clunky. the items need some space to breath.
• I think you went too far by removing the field boxes, I feel like everything is floating without an order. The boxes could be kept, but be simply lighter and less present then before.

Two things that are not that important but would make the theme look more modern:

• Removing the color on that second area bellow the menu and making it lower seems to make the theme look cleaner (see screenshot)
• Shouldn't we let Helvetica and Arial have a rest (Arial in my case)? Let's try open-sans since it's the one used on the website.

[ryan]

Turning this off has little visual impact and seems redundant to the function that the .container serves, this kind of styling should really be handled by a class anyway.

It's a leftover from the old admin theme (I didn't create these files from scratch). You are right, we can drop this left/right padding as there isn't any need for it. 

Also the markup and subsequent use of position:absolute; on items in the #masthead seems bizarre to me.

Also a leftover from the old admin theme. In 2009/2010 there was still a little bit of lingering IE6/IE7 bad habits–which meant using absolute positioning when floats were more appropriate largely because IE was not consistent with floats. Obviously that's not the case anymore. I think your suggestion to change these to floats makes sense. Though also not sure it really matters much in this case, but I do prefer floats from the responsive side, so that's a good enough reason. 

(though I prefer CAPS and font-weight:bold; in my nav/pageLinks generally).

Your screenshot is  too bold for my taste, but maybe it makes sense for one of the color themes to take a bold approach like this. I understand that very often what looks better depends somewhat on how the platform and hardware/screen render type, so it's good to provide options. 

Oh, I also added outline:none; to the search query, can't stand they way those outlines looks.

I'm not familiar with the outline you are talking about (Chrome OS X), but will try it out and add it if it provides some benefit in Windows or another browser or something. 

Also the search query is to hard to see, maybe drop the transparentize value to 0.7?

Kind of depends on the screen, it's quite visible here. But I see no harm in increasing the value. 

Oh and I increased the PageListItem padding, though this should maybe be handled by line-height 

It's preferable to do it with padding rather than line-height since it's possible for long titles to wrap, and we want wrapped titles to still look like a single item. But I am not a fan of increasing the padding or line height here, as it just means a lot more scrolling on the sites I work on (which tend to have lots of pages). Again though, I see no problem with providing this as an option in one of the color themes if people find it more attractive. I find it less attractive myself, but it's all subjective. I think a good goal here is to support a broader range of preferences by providing more options, and so this may be one of them. 

I don't like the color schemes very much and I think it's not very positive if you are planning to use the warm as default because in my opinion it's important to keep the corporate colors of PW.

ProcessWire is not a corporation so we don't have corporate colors. But we do have brand colors, and I think we will stick to them for our branding and marketing. But I'm feeling like the application itself should be less branded...  would rather have people think of it as a tool like their text editor. It bothers me that a seemingly large group of people have ignored ProcessWire largely because they don't like the way the admin looks. And the colors are one of the first things mentioned. Many of potential audience thinks they look childish: light blues and pink, which are also known as baby boy and baby girl colors. I like the colors myself (a lot), but have heard it enough objections to know it's not an isolated opinion. Those people aren't here to tell us about it in the forums because they were turned off by subjective things before they got to know why it would be a great tool for them. So I wonder if the admin needs to be more neutral and not defined by colors or brand, but by its usefulness as a tool. I want people to focus on the tool and not on the colors, because the colors really have nothing to do with the tool at all. While there has to be default, it should be fairly neutral and easy to change. Ideally it would be selectable from the installer so that it's clear from the beginning that it's a tool to get stuff done more than a brand to buy into. By the same token, I wonder if there shouldn't even be a PW logo in the admin, or if we should make it something the user can easily replace with their client's logo.

With regard to color schemes, I'm also hoping some others here that are better at it than me will put some together. I think I've setup some good starting points that I like, but colors are always subjective. I think someone else can do better here, so I've tried to make it as easy as possible by isolating all the components of the color scheme in a separate file that can be changed easily. So if anyone is interested in experimenting with colors, please do and post your results when you've got something that you think looks good. 

The dropdowns are too stuffed and clunky. the items need some space to breath.

These are standard jQuery ui-menus, which are meant to follow the scale of select boxes (I think that's what they were trying to do anyway). I'm not yet sure if I can make major adjustments to them without affecting other jQuery UI widgets that I don't want to, but I can experiment. However, the plan is that these will descend another level for templates and fields (which can potentially include a lot of nav items) so I think it has to be a careful balance. 

I think you went too far by removing the field boxes, I feel like everything is floating without an order. The boxes could be kept, but be simply lighter and less present then before.

This is something that I can confirm is very much affected by your screen. I have two screens connected to my computer, and I can barely see the lines on one of them, while the lines are nearly too dark on the other. So what you see now is a compromise between the two in finding the right darkness level for them, based on my own screens. No doubt we'll want to provide higher contrast options here in one or more of the color themes, to account for these variations. But rather than basing it on my screens, it would be good to hear from more people to see where the right balance is for visibility of the box lines. 

Removing the color on that second area bellow the menu and making it lower seems to make the theme look cleaner (see screenshot)

I've tried it both ways. To my eyes it looks whiter, but not cleaner. It's subjective of course. My personal preference is to have a color, a line or something to make navigation part of an interface with visual hierarchy that rather than free floating. But I think it doesn't hurt to experiment here in one of the color options. I actually thought it worked ok that way when testing it in the Modern color theme. 

Shouldn't we let Helvetica and Arial have a rest (Arial in my case)? Let's try open-sans since it's the one used on the website.

I don't think we can legally connect an admin theme with my TypeKit account. Maybe there is another resource we can use for this, but it's got to be something that doesn't require connecting to an outside service. The typeface also has to be one that is fairly generic. Arial is about perfect IMO due to it's anonymity... keeps the focus on the content without the type influencing the personality or suggesting style. The goals in the admin are entirely different from the goals on the marketing/brand site we're on now. Arial doesn't do anything for me (which is partly why I think it's a good fit in this case), but if we can find something that has similar characteristics while looking newer or more professional, I think that would be a desirable thing.  

[adrian]

Just a quick on - and maybe this is something for Soma to fix in the modules manager, rather than in your theme (I haven't checked where the problem is), but see the button offset in the attached screenshot.

[janlonden]

ProcessWire is not a corporation so we don't have corporate colors.

But we do have brand colors, and I think we will stick to them for our

branding and marketing. But I'm feeling like the application itself

should be less branded...  would rather have people think of it as a

tool like their text editor. It bothers me that a seemingly large group

of people have ignored ProcessWire largely because they don't like the

way the admin looks. And the colors are one of the first things

mentioned. Many of potential audience thinks they look childish: light

blues and pink, which are also known as baby boy and baby girl colors. I

like the colors myself (a lot), but have heard it enough objections to

know it's not an isolated opinion. Those people aren't here to tell us

about it in the forums because they were turned off by subjective things

before they got to know why it would be a great tool for them. So I

wonder if the admin needs to be more neutral and not defined by colors

or brand, but by its usefulness as a tool. I want people to focus on the

tool and not on the colors, because the colors really have nothing to

do with the tool at all. While there has to be default, it should be

fairly neutral and easy to change. Ideally it would be selectable from

the installer so that it's clear from the beginning that it's a tool to

get stuff done more than a brand to buy into. By the same token, I

wonder if there shouldn't even be a PW logo in the admin, or if we

should make it something the user can easily replace with their client's

logo.

Yes! I also think that the admin should be as neutral design wise as you said as possible. A good example of this is Nico Knolls Dark Business, appy, clean and neutral design.

[diogo]

Ryan, I agree with almost everything that you wrote. Not sure about the branding (ok, not corporate) colors issue though. You can use these colors without making them look childish, they can at least be sprinkled here and there. I also think that as soon as the theme is ready, there should be screenshots of the several color schemes on the homepage. Like this people won't abandon because of the colors for sure. As soon as I have time I will also give it to change the colors a go for sure

I don't think we can legally connect an admin theme with my TypeKit account. Maybe there is another resource we can use for this, but it's got to be something that doesn't require connecting to an outside service. The typeface also has to be one that is fairly generic. 

http://www.fontsquirrel.com/fonts/open-sans 

The typeface also has to be one that is fairly generic. Arial is about perfect IMO due to it's anonymity... keeps the focus on the content without the type influencing the personality or suggesting style

You must have "Helvetica Neue" on your computer. Arial just looks terrible and ultra-boring.

[Soma]

Does anyone else agree? Currently the base font size is 13px (same as PW has always been). I could always bump it to 14px. Though it is quite a size difference, (too big to my eyes, and I'm on a 30" 2560x1600 screen where everything is already small). It is defined in one place, and all other font sizes (except #footer) are affected by this rule in main-[colors].css (or main.scss). 

 

#masthead, #notices, #content, .ui-dialog {

  font-size: 1.3em;

}

Just my opinion.

Base font size currently is 10px/20px (body) and just set using #id's to 1.3em. 

I don't understand why it is has to be this way, as I'm long time used to working with 100%, font-size: 1em for starting point along with media-queries in em too.

Some related reading I just found about this why this seems like a good practice:

http://filamentgroup.com/lab/how_we_learned_to_leave_body_font_size_alone/

http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/

Defining font-size should not happen on containers but on html set to 100% and body on 1em as default first, and then on text elements. We don't think in pixels anymore.

In this case this #content 1.3em is just scaling it up from the 10px/20px which seems ok but there's drawback as you in some cases can't overwrite it easily on inherited elements without using #content in the selector again.

I'm also in general not very convinced about how the admin default css is built (but it get's better and better) and think it could be cleaned and improved a lot. There's a lot of redundant, unnecessary (and some not even having an effect at all!) definitions it even goes into performance rendering (even if very minimal). I think it need's a global scope rethink and rewrite/cleanup and I would be willing to help where I can.

 Sorry I'm not so good at explaining and communicate those things with text and even so more not in my mother language. 

-

Desing wise I think colors are important, (I just think not as many as it has now, I count over 10!)) but good UI design is much about font type, spacings, and how elements are presented. Good UI design doesn't distract and confuse, I can't currently say that this theme does solve anything from the default previous theme. Colors should be used to emphasize certain things and elements not brand it. My opinion.

People I know that don't like PW aren't saying colors, but general UI design and style not being modern. And that comes down to how big a font is and how much spacing it has.

[dragan]

Looking great! To me, it's the additions of dropdowns I'll probably appreciate the most (especially for the "Setup" menu)... reaching menus faster, with fewer mouse clicks. Kudos.

[Manfred62]

just an idea: make CKEditor to the new default RTE?

This, or upgrade to the new TinyMCE v4?

a second thought on this RTE topic: what about including both RTE's (TinyMCE + CKEditor) in the default PW install? Both as separate modules available but not preinstalled.

Then the developer could decide, which of them to install (same procedure as with other modules like repeater etc.). Maybe also in this case the RTE's as modules are easier to maintain and update?

contra: the size of PW gets bigger.

[Pete]

One thing to note with the new theme is that in one module I'm working on that uses jQuery to watch certain elements for changes it no longer works because I assume some of the elements' parent containers have changed.

Not difficult to fix, but might break a few modules is all I'm thinking.


EDIT: To fix mine all I had to do was change references for .ui-widget-content to .ui-widget-content, .InputfieldContent

[Pete]

there are also some applications for the fancy sass, scss, compass, less or coffescript stuff...

http://incident57.com/codekit/

http://mhs.github.io/scout-app/

http://koala-app.com

Just looked at the video for Scout App - works well for Windows or Mac and the video shows it as simple to use for those of us who don't see why we should be doing any command line stuff and installing Ruby when there's a simpler (lazier) solution

Though I also like the look of the others - Codekit is especially interesting for its other features at a low price tag!

[BUCKHORN]

Great theme. Much improved. 

I'd like to see more padding and margins around clickable objects like the menu drop down and buttons, maybe even increase the font size. This is for mobile and tablet users. 

Is there a link to: Phillip Reiner's great admin theme design

I think I've seen it before, and would also like something like it. 

[Martijn Geerts]

Hope the icons go to 14px. Font Awesome is designed for 14 px.

[horst]

when I switch in images field from listview to the thumbs view and drag to reorder them, they open a modal window with big sized image after dropping.

I would like to disable that. e.g. when in thumb view modal opening is disabled or only available via doubleclick! would be good solutions.

Or is this behave only with my firefox 24 ?

[ryan]

I've pushed several updates consistent with the feedback above. This includes going a little more minimal on some things, converting absolutes to floats, making the lines more visible, and numerous other updates. I also added another color theme "futura", which is based on Nikola's Futura Remixed.

With regard to typography, I'm going against my own preferences and making the type bigger, bolder (in Classic and Modern), and increasing the line height. These changes make it less usable to me personally, but my conclusion from previous feedback was that others may prefer bigger/bolder, more height, more room, etc... so just trying to find a balance. After all, the point here is to have a theme that appears to a broader group, rather than one that maximizes usability at scale. Or at least to find a balance.

Regarding there being some redundancy or things that need cleaning in the CSS–I'm leaving a lot of extra stuff in there since I change my mind a lot. I'm not going to fully clean and remove redundancies until it's final. So please don't look for perfection here, this is a work in progress. I'm not going to vacuum this place until the work is done. 

Regarding use of Arial as the typeface: I tried switching to OpenSans, but there was just too much personality to it that I thought it was influencing the tone too much, and ultimately too distracting. If you guys can think of any other free, fairly neutral webfont typefaces worth trying, please let me know. I would love to find a better alternative to Arial. 

Edit: Almost forgot, here's the screenshots of the updates. 

./?colors=classic

 

./?colors=modern

 

./?colors=futura

 

./?colors=warm

 

[diogo]

There was a post here some days ago where Arimo was mentioned. The metric is the same as Arial.

It's the default font at HTML Kickstart from our Joshua

[ryan]

Thanks Diogo, I'll try that out. 

Also, I forgot to commit that update that fixes the ?colors=[warm|classic|modern|futura] thing (it was previously keeping the color theme selection for only 1 page). Just committed that fix now. 

[janlonden]

We really appreciate this Ryan. I like the bigger font size and added padding. The futura color theme matched the company's website I'm working on right now almost perfectly

One thing that still bothers me a little is the rounded corners on submenu items when hovered over with the mouse. Not a big thing, but still wanted to give a little constructive criticism.

Thank you for your work!