Jump to content

PW 3.0.78 – More admin theme updates


ryan
 Share

Recommended Posts

First, I really like this admin theme!

So what follows isn't meant to be a full picture of my reaction to it because overall I love it - just a few things that could use tweaking IMHO.

 

Fonts

Currently users will see completely different fonts depending on what OS they are using. The font-family rule is:

font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif

It's become popular lately to use system fonts like this (was it GitHub that started it?) but the problem is that the fonts in this stack are not very similar. It's one thing to fall back to Arial if Helvetica isn't available because they are so similar that the average audience won't be able to tell the difference. But San Francisco, Segoe UI, Roboto and Helvetica Neue are completely different typeface designs. So for instance there will be no consistency with x-height or position of type within the line-height box across platforms, so what looks pixel-perfect on MacOS might look sloppy on Windows or some other OS. If the desire is to move away from the bog-standard Helvetica/Arial then wouldn't it be better to bundle an open-source webfont kit with PW so there is reasonable consistency across platforms?

From the blog post screenshot:

2017-10-07_111917.png.281a57a0374eca7664316d7861649d0a.png

From the demo site, Windows 8.1:

2017-10-07_111933.png.ac7e4cdf6a894b767376fb3a027b307e.png

 

Search box

Like the current default admin theme search box styling, I think this is way too subtle:

2017-10-07_111107.png.25a0d2ebdb9c70f593b352f9689d253d.png

I have 20/20 vision and I can only barely make out the bounds of the search box - imagine what it's like for users with less-than-perfect vision. The search feature is hugely useful for quickly finding a page to edit in a deeply nested tree structure, so we want users to know that it exists. With the current admin default theme, most of my clients had never noticed the search box (until I boosted the contrast in some custom admin CSS).

 

Tab metaphor

For a tab metaphor to make sense there has to be some visual connection between the active tab and the content within that tab. Otherwise it isn't clear what content on the screen is controlled by the tab. On this screen...

59d803309131c_screen_shot_2017-10-06_at_11_36_22_am.968x0-is(1).png.68a0a80ad814f62aa3dbc961ab635e34.png

...not knowing better, I would expect the tabs to control only the Title, Date and Headline fields. Body looks like it is outside of the tabbed content and so the expectation is that it remains on screen when switching to a different tab. Of course you learn how it works once you use it, but every time a thing works differently to how a user expects it to work there is a little bit of mental friction - a bit more effort required to understand it and a bit less satisfaction.

I understand that there is a setting for controlling the border style of different fields (although it is disabled in the demo so I couldn't easily try it) - that's great. But I think the default style should be one that lends itself to the tabbed interfaces that are used throughout the PW admin (i.e. a visible border that connects to adjacent fields that are within the same tab).

 

Breadcrumb separator

Getting a little nit-picky here, but I think a guillemet › is a better breadcrumb separator than a slash /. The breadcrumb is supposed to indicate a hierarchy of pages. With the slash there is less sense that Posts is within Blog. It looks like a group of items that are all on the same level.

 

Container width

My preference is for some max-width to be set for pw-container (1600px maybe?). On my 2560px-wide monitor the interface becomes too wide for comfortable use. But that's an easy override for me to apply if there's no agreement on that. 

  • Like 11
Link to comment
Share on other sites

When trying to modifiy a field of type Multiplier(V13) I get an error:

Error: Call to a member function get() on null (line 317 of D:\Projekte\kopfleere\processwire-dev\www\wire\modules\AdminTheme\AdminThemeUikit\AdminThemeUikit.module) 

Line 317 states:

$fieldset->collapsed = !$field->get('themeColor') && !$field->get('themeBorder') && !$field->get('themeOffset');

 

  • Like 1
Link to comment
Share on other sites

I think the new admin theme is a big step ahead! I really like it. I'm now starting to play with it and found a small inconsistency in regard to translations:

59d8a0c3a408d_Bildschirmfoto2017-10-07um11_38_59.png.d5e4f2f39f3aa6b730cd3ab0e8446d67.png

In the upper nav bar, "Seiten" (does mean "Pages" in English) is translated by german language pack. "Pages" below this, however, is the page title of the "Pages" page (Page ID 3) inside of "Admin" (Page ID 2). I figured out that "Pages" can be translated as well by editing the "Pages" title, but this page has to be unlocked first in order to edit the title. I'm not sure if everyone who uses this theme knows how to follow these steps to get a fully translated theme. I think this should be handled somewhat more consistent - either the Page title or the translation file  should be used in both cases. To be honest, I wonder if it has any unforeseen side impacts if the titles of "Pages", "Setup", "Modules" and "Access" pages inside of "Admin" are changed?

...and, for my personal taste, the upper (darker) bar (masthead?) has a little bit of too much height :-)

  • Like 2
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...