New ProcessWire admin theme on dev branch

[Soma]

To me it looks like faux bold.. I wasn't looking into it so sorry if that turns out to be the problem and that's a common problem when people use custom fonts. Some browsers are worse than others, but when working with custom font make sure you choose a font that has at least 2-3 weights and set them according. Just making a font "bold" doesn't mean it has a "bold" (600?) weight, make sure that you use the weight defined by the web font mostly like 500-700.

[Craig]

Craig, thanks for your tests. Both of your screenshots looked pretty decent for Windows. So it sounds like the one on the right is Arial? Arimo looks pretty good on the left (at least compared to the earlier Windows screenshots), but relative to Arial, it looks a rather fuzzy.

Yes, the right one was Arial, and the left one was Arimo with SVG at the top of the font "src" stack.

I've had a look at the Google Fonts page, and the result is shown in the attached image. It renders clearly, but again - it's the bold 'e' at that size that is the ugly duckling. For comparison, I added Open Sans.

[Nico Knoll]

So I would prefer Open Sans or Source Sans Pro.

But Fira looks quite nice too

[FvG]

Nice start! Already like it much better than the current theme.

Some things I noticed:

- Everything looks nicer if you limit the container to about 1050px in my opinion

- see setup/templates or setup/fields: the filter box would look nicer with some top margin and

- the style when you hover the icons in the table don't fit the design at all

[Soma]

The new "Add New" button is nice feature but I'm not sure it's very useful for all sites (the way it works for now), if I have a site structure that doesn't allow for the right setup needed. Either because the template may used in different branches, and or a multisite setup.

I dream of a more configurable thing, and maybe also able to disable it.

[ryan]

I also would like to make it more configurable, and definitely plan to. But in the short term, I think the best bet is just have it not show if there aren't any add-ready templates to populate it with. I will do this before 2.4 is final, but just wanted to keep it there with a little instruction notice to introduce it, as I thought people might not realize the option was there otherwise. 

I've had a look at the Google Fonts page, and the result is shown in the attached image. It renders clearly, but again - it's the bold 'e' at that size that is the ugly duckling. For comparison, I added Open Sans.

Thanks for the screenshot comparison. It looks like the "e" also has the same issue with the bold Open Sans, though to a lesser extent. I notice the 12px size seems to look fine with both by comparison. Is the problem just the 14px font size with these fonts in Windows? Would using a different size (bigger or smaller) as a default be better in the Windows environment?

[wayne]

Here is a comparison between Chrome and Firefox on my Win7 system. The picture shows Arimo from 10px to 16px.

Everything beyond 16px looks good either way in my opinion.

[Nico Knoll]

Could you try this (at least) for Chrome and Safari?

* {
        margin:0 auto;
        -webkit-font-smoothing: antialiased; /* Fix for webkit rendering */
        -webkit-text-size-adjust: 100%;
        
    }

[wayne]

Even with those styles applied I don't see a real difference.

And as there are no css fixes for Firefox or IE it's not really a help for this Windows webfonts problem.

It's also not much better for the following Open Sans and Source Sans Pro:

[ryan]

Thanks for the screenshots Wayne. To my eyes, it looks like the 13px–15px range is problematic for Arimo and Windows, and the other fonts as well. With Arimo, both 12px and 16px look just fine to me (how about you guys?). Perhaps we can solve this by just using a smaller default size that corresponds with 12px. To me 16px just seems overly large for body readable text, like a large print book for visually impaired people. But it is typically the browser default, so not positive whether to default up or down on this one... learning towards down (12px), but going to experiment. 

[ryan]

Nevermind about 12px–it's just too small, at least in OS X. 16px too big, but renders ok. 

[apeisa]

Amen.. oh, I mean Arial.

[Soma]

I want 15.245px

Just noticed that when I have images field in a custom tab as the only field (is at top), the grid view doesn't work. At least for me in latest version Chrome. ©licking the icon just collapses the field.

[Manfred62]

Amen.. oh, I mean Arial.

yes, a lot of time spent to try other fonts... Wouldn't it be easier to stay with 'Arial, Helvetica, sans-serif'?

Another point (already mentioned earlier). In the setup menu dropdowns the translation isn't available. Only 'languages' is translated.

[ryan]

I want 15.245px 

Actually it looks like 15px (0.9375em in our case) is a good route. This seems to render nicely in the Arimo screenshots above, and looks about the same as 14px in OS X. The 16px size I tested just seems way too big, but 15px seems like a nice balance. Is there something special about 15.245 or are you just being silly? You know I'm actually going to go test it out now.  

Just noticed that when I have images field in a custom tab as the only field (is at top), the grid view doesn't work. At least for me in latest version Chrome. ©licking the icon just collapses the field.

Just tried but I can't reproduce that one yet. My version of the admin theme here is a little newer so maybe that's the difference. I'll get these files together and commit them shortly just in case that's it. 

Another point (already mentioned earlier). In the setup menu dropdowns the translation isn't available. Only 'languages' is translated.

Thanks, I found the problem and fixed it. It will appear in the next commit. 

yes, a lot of time spent to try other fonts... Wouldn't it be easier to stay with 'Arial, Helvetica, sans-serif'?

Yes it may come to that. I have no problem with Arial, but I've also become very attached to Arimo and so want to exhaust all options before giving up on it. 

[ryan]

I've committed some updates to the admin theme, including a bump of the font size up a bit to hopefully look better in Chrome/Windows. I'm curious if you guys running on that platform find it makes an improvement?

[Manfred62]

hi Ryan

tested the 2.3.7 version. In my eyes it looks nice on Win 7 in FX and Chrome. With FX it looks a little bit sharper. Also the font-size is good (not too small). The dropdown translation is fixed too.

Translation questions:

what about making the ProcessLanguageTranslator module translatable (the text on top and the save button)?

under access/user the column titles?

under access/user/username the Roles section is not translated?

[teppo]

@ryan, pulling those updates brought up something slightly weird with new modules page: "Found new module - JqueryMagnific" is a link to "#JqueryMagnific".. which won't work unless I first activate Core tab

[lpa]

On Mac OS X 10.6 with Safari 5.1.10 with this latest update when modifying a page the menu (Content, Children, Settings, View) disappears. 

[Wanze]

In the model view of page edit (append &modal=1 to the URL), the save button is placed inside the first field.

Maybe a bit more space there would be nice

[thetuningspoon]

Thanks I was able to reproduce as well. Looks like I need to wrap the mouseleave() in a 250ms setTimeout() for Firefox, at least that seems to fix it here. I'll commit this update tomorrow. 

Late to the party, but may I suggest superfish.js? Does wonders for my dropdowns!

I'm so excited about the changes you've made, Ryan! Can't wait to try it out.

[teppo]

Feasibly we could switch to a different icon set in the future, and the icon-iconname format strikes me as more portable? The fa-iconname format seems to be branded specific to Font Awesome.

Ryan: are you certain about this? I was just about to post that this little CSS rule in Font Awesome stylesheet is an awesome (pun intended) example of doing it wrong:

[class^="icon-"],[class*=" icon-"]{...

.. but based on above comments it seems that they've already realized and fixed this. The issue is that these aren't exactly "unique" class names and will collide with classes used in some existing Process modules (or, for that matter, in any other external stylesheets / styles that are also doing it wrong), which is not very nice behavior.

Sure, another approach would be to fix any collisions elsewhere and keep these rules as-is, but that feels kind of wrong, considering that this is apparently supposed to be a drop-in will-work-out-of-the-box font library (or whatever the correct term here would be.)

So.. perhaps we could implement fa-* style class names after all -- or if that seems too fa-specific, re-brand them to pw-* or something else "vendor-specific"?

[Soma]

Also wanted to note taht the new Admin Theme is broken on many things (especially the new dropdown) on IE8 and not that usable/nice. Not sure how that matters at all, but we still have clients that use IE8.

[thetuningspoon]

I apologize if this has already been addressed (haven't had time to read through the whole 10 page thread)... But I noticed that the page name auto-fill when creating a new page is no longer working. I am using Chrome on Mac. I checked the Chrome dev tools Console to see if there were any JS errors but didn't find anything.

Is this something on my end or is this functionality temporarily disabled in the dev branch?

[teppo]

@everfreecreative: make sure that you've got the latest version from GitHub. This bug was supposed to be fixed a (short) while ago.