Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Redesign of installation screens for improved identity and branding #184

Closed
johnalarcon opened this issue Nov 4, 2018 · 45 comments
Closed

Comments

@johnalarcon
Copy link
Contributor

johnalarcon commented Nov 4, 2018

The installation screens have gotten zero love over the years and their current state is excessively verbose (item 5?... that's fully described in 2 places!) Specifically, I'd love to see several changes; quick mockup below.

  1. full-size CP wordmark + feather logo at the top (round logo for mobile/responsive views)
  2. installation button styled as a CTA with CP colors and proper labeling
  3. succinct texts, with links to anything requiring description or more information
  4. larger text (ie, 115%)

Expected behavior

The install screens do already behave as expected.

Current behavior

Install screens are overly verbose and there's little distinction between CP and WP.

Possible solution

Mild redesign of the colors/texts and how they are laid out.

Steps to reproduce (for bugs)

Install ClassicPress.

Context

I've always felt these screens were overlooked. This is a great place to insert CP colors and make an immediate distinction between the CP/WP platforms.

image

@johnalarcon
Copy link
Contributor Author

@johnalarcon
Copy link
Contributor Author

I believe the above is also a needless step (like the Alright Sparky step)... the whole installation can take place on 2 screens: 1) choose language, 2) install now. Something like this:

image

@johnalarcon
Copy link
Contributor Author

And of course, there's also this... (which I love the most)... 1 step installation:

image

Ok, I'm done iterating mockups... :)

@BlueSkyPhoenix
Copy link

@johnalarcon Thanks for taking the time to do these!

@Mte90
Copy link
Contributor

Mte90 commented Nov 5, 2018

I am wondering if change only the installation page is the best solution.
People will say that is different the installation but the rest is the same.

@johnalarcon
Copy link
Contributor Author

@BlueSkyPhoenix, my pleasure. If this is approved, I can probably get a PR in this week. I'm a total geek when it comes to laying out information...

@Mte90, I understand your concern, but am not confident that an all-or-nothing approach is a better solution. Currently, people might say the logo is different and everything else is the same – but that doesn't mean we shouldn't change the logo. Moreover, I'm focusing less on what the naysayers are possibly going to say and, instead, looking toward making ClassicPress better, even if just a little at a time.

@johnalarcon
Copy link
Contributor Author

I think something like the second mockup would be a good direction – clean up the verbiage, link out to help/info, style button as CTA, nix the screen between selecting language and installation, incorporate full CP logo.

After looking a little deeper at this, there's more than just a screen or two involved; I was able to find 9 screens within a few minutes. Some of the screens have a logo, some don't. One has a CTA-style button, the rest don't. In other words, restyling the few main screens doesn't fully resolve the issue, and it would add an element of inconsistency if not done completely. Looking at the code, I think a rewrite is how to resolve this issue...something for v2.

install-language
install-introduction
install-database-setup
install-database-error
install-alright-sparky
install-already-installed
install-success
install-missing-config
install-setup-defaults

@johnalarcon johnalarcon changed the title Mild redesign of installation pages for improved identity and branding Redesign of installation screens for improved identity and branding Nov 5, 2018
@BlueSkyPhoenix
Copy link

@nylen Continuing the conversation from https://classicpress.slack.com/archives/CDGP8FW56/p1541464830199200?thread_ts=1541431855.169100&cid=CDGP8FW56
and taking into account the above additional comments, I think that there can be some subtle visual changes made to the overall styling for v. 1 that can create a more cohesive brand throughout the admin without causing a complete overhaul. For instance, I think it's important to be consistent about where our logo is seen. IMO, the feather in the circle at the top of these install screens is too reminiscent of the WP install. If we use the full logo whenever possible it will help toward creating brand recognition & differentiation. Buttons with the CP color scheme, as well as active menu items and hover text in our color instead of WP blue will also help with that. What other easy adjustments can we make to the CSS to start to set ourselves apart?

@nylen
Copy link
Contributor

nylen commented Nov 6, 2018

Buttons with the CP color scheme, as well as active menu items and hover text in our color instead of WP blue will also help with that. What other easy adjustments can we make to the CSS to start to set ourselves apart?

I really like the mockups in this thread, but this is what I was afraid of here.

wp-admin has an amazing variety of use cases and permutations, so any change across the whole admin needs to be made with a lot of care. If we change styles there then we need to test with a lot of different plugins (as many as possible, especially the major ones).

Keeping the changes very minor (basically small color changes only) would help a lot with this. For example:

  • Instead of the WP blue background for primary buttons, use our blue-green gradient. Keep the border, box-shadow and other styles the same.
  • Change hover colors.

@nylen
Copy link
Contributor

nylen commented Nov 6, 2018

WP's existing "big button" style is class="button button-primary button-hero". It looks like this:

Before After
2018-11-06t00 20 52-05 00 2018-11-06t00 23 13-05 00

Still feels to me like it is missing something, but we really can't make a change that's much more invasive than that.

Using just our solid blue color #006b81 is another alternative that's worth exploring. The gradient looks a little too "playful" here which is probably not ideal given our business focus.

@ginsterbusch
Copy link

Id stay away from directly porting the design of the website onto the CP admin UI, too. Simple colors etc. yes. Playful gradients with potential hazardous accessibility and usability issues ... NOPE. Lets not open that specific can of worms :)

What we could supply though would be a custom admin color scheme. Not only would this help building up our own visual identity, but also enable users to switch back to their preferred colors whenever they like. One could eg. add this as an optional step / setting to the installer, or to the introduction in the dashboard.

cu, w0lf.

@johnalarcon
Copy link
Contributor Author

@BlueSkyPhoenix, Good points, especially about the logo. The bigger logo where it fits; the coin logo where it makes sense (mobile views, admin bar).

@nylen I find the angle of the gradient looks "iffy" (I just copied the 135° angle used on the site,) a vertical gradient would have been better. Still, if we use one of the CP colors, I'd go with the lighter color for CTA buttons, then the darker color used as the thick bottom border. As for links/hovers, perhaps using the darker color for links, lighter color for hovers.

@ginsterbusch, I'd definitely not port the entire design, just the colors/fonts for consistency. You mention "...potential hazardous accessibility..." so, I'm wondering: are you speaking to an actual issue here, or are you speaking to a what-if? It seems the latter. It's not clear to me how using a gradient on a button poses any more issue than using that same gradient on the site's background. Not that I'm sold on putting in the gradient, just that I'm not sold on the idea that these specific mockups pose an accessibility issue.

@BlueSkyPhoenix
Copy link

BlueSkyPhoenix commented Nov 6, 2018

@johnalarcon & @ginsterbusch -- good discussion here. The angle of the gradient was settled on after the previous vertical gradient was deemed "dated" via feedback received in the design phase. This is the final approved gradient, although the buttons are actually at a different angle and slightly different color (to accommodate for accessibility). I'll work to get the branding info moved to a more centrally accessible location, but for now you can find everything here: https://github.com/ClassicPress/ClassicPress-Themes/wiki/Design-Specs

As mentioned above, all colors & gradients were tested using an online accessibility tool, so I'm not really concerned about the gradient in that respect. That said, if you prefer to use a solid color, please use #057f99. Let me know how else I can assist.

@BlueSkyPhoenix
Copy link

@johnalarcon for convenience:

Buttons
Angle: -60˚
Button text is 21px DejaVu Sans Semi-bold
Dark text is #262626; Light is #ffffff

Aqua (white text):
#07989e at 0%
#034a59 at 100%

Purple:
#89288f at 0%
#4b2063 at 100%

Yellow (dark text):
#eaec8e at 0%
#f89c1b at 100%

Light buttons on dark background have drop shadow applied (75% opacity, X offset: 1px, Y offset: 5px, blur: 5px, darkness: 50%)

There are some other style guidelines in the doc as well if you want to check it out -- thanks for your work on this!

@johnalarcon
Copy link
Contributor Author

Before I write up a PR on this, can someone please sum up what the actual decision is? I'm on fairly limited time for now, so I just want to make sure to hit all the points without having to undo anything. :)

@nylen
Copy link
Contributor

nylen commented Nov 7, 2018

I don't think we have an agreement yet.

From a core development perspective I see two things to be careful of here:

  • Major changes to wp-admin screens (please, no font changes or really anything more major than a simple color change. wp-admin uses a system font stack which is a good thing).
  • Having one design for the install pages and another design (the same as what's there today) for the rest of wp-admin.

So, I'd leave the primary install button alone (maybe adding button-hero class if we want to make it larger, and maybe changing the color for all primary buttons in wp-admin). Still, I am pretty sure that even changing the button color is going to have some unexpected effects that we will only see later on.

Other than that, I think we can go ahead and prepare the other changes for the install screen: logos and copy updates.

I'm inclined to save the screen re-arranging for a separate PR, unless there is something very obvious that we can get rid of.

@johnalarcon
Copy link
Contributor Author

johnalarcon commented Nov 7, 2018

I don't think we have an agreement yet.

No worries, glad I confirmed. I agree with the points you make. Re: screen re-arranging, yes, definitely a separate issue, with a scope of its own.

@BlueSkyPhoenix
Copy link

@johnalarcon I agree w/ @nylen as well -- until we get the "big rocks" moved and sorted, I think we don't want to borrow trouble by making major changes to the wp-admin screens. However, yes to button color changes, and I like the idea of adding the button-hero class. Yes to logo updates/changes where appropriate throughout (full logo or coin as outlined above). On the wp-admin screens I'd also like to see the left menu active item color changed to our #057f99, as well as the link text hover. It's a subtle change, but it's a move in the right direction. anything else?

@nylen
Copy link
Contributor

nylen commented Nov 9, 2018

Ok I agree with all of that, and the wording changes for the installation screens. So this is sounding like a plan:

  1. Changes to colors: primary buttons and hover/active color to #057f99
  2. Changes to install screens (wording, bigger button)
  3. Changes to logos

(1) should be its own PR. (2) and (3) can be combined for the install screens if needed, but I'm wondering where else we need to update our logo. The About pages (on each of the 4 tabs) is one place.

@johnalarcon
Copy link
Contributor Author

johnalarcon commented Nov 9, 2018

No problem to break it into multiple PRs. Buttons have several states (and borders), so those must be accounted for. It wouldn't be ideal to hover a button and have it turn WP blue.

  1. Changes to colors: primary buttons and hover/active color to #057f99

This isn't enough info to be actionable. What I need are the following specific values, which I'm unable to glean from the style guide and previous comments:

  1. button background colors (default, hover, and onclick)
  2. button bottom border colors (default, hover, and onclick)
  3. link colors for install screens (default, hover, active)
  4. And...are these button color changes intended only for the install screens, or admin wide?

Also, @BlueSkyPhoenix noted color changes to the admin menu and link colors (presumably, admin-wide?) - there was neither agreement nor disagreement. Please clarify if this is also within the scope of item 1 of the previous comment by @nylen, and whether the link color change should apply to the admin menu only, or all links admin-wide.

  1. Changes to install screens (wording, bigger button)

Got it; separate PR. The work is clear here.

  1. Changes to logos

Good point. This can also be a separate PR, as well.

@BlueSkyPhoenix
Copy link

@johnalarcon on your questions -- see below. Tagging @nylen here to get his confirmation as well.

button background colors (default, hover, and onclick)

Default:
background: #07989e;
background: -moz-linear-gradient(60deg, #07989e 0%, #034b59 100%);
background: -webkit-gradient(left top, right bottom, color-stop(0%, #07989e), color-stop(100%, #034b59));
background: -webkit-linear-gradient(60deg, #07989e 0%, #034b59 100%);
background: -o-linear-gradient(60deg, #07989e 0%, #034b59 100%);
background: -ms-linear-gradient(60deg, #07989e 0%, #034b59 100%);
background: linear-gradient(135deg, #07989e 0%, #034b59 100%);
filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#07989e', endColorstr='#034b59', GradientType=1 );
Hover:
background: #034b59
onclick:
background: #07989e

button bottom border colors (default, hover, and onclick)

border-bottom-color: transparent; (for all)

link colors for install screens (default, hover, active)

Default: #057f99
Hover: #006b81
Active: #034a59

And...are these button color changes intended only for the install screens, or admin wide?

I'd like to see these changes admin-wide.

Please clarify if this is also within the scope of item 1 of the previous comment by @nylen, and whether the link color change should apply to the admin menu only, or all links admin-wide.

Hopefully @nylen will respond to this specifically.
To be super clear on the left hand admin menu and in top menu

screen shot 2018-11-09 at 11 43 34 pm

I'd like to see the active item ("Dashboard" in the screenshot) in #057f99
Any links on hover ("Pages" in the screenshot") in #057f99

In the "main" area (see second screenshot) I would like to see those links also in #057f99, on hover please make them #006b81.

screen shot 2018-11-09 at 11 47 21 pm

Thank you!

@nylen
Copy link
Contributor

nylen commented Nov 10, 2018

@johnalarcon I took a look at the button styling changes and there are a few more things to work through before they are complete (bottom border, text-shadow and box-shadow colors for example).

Michelle and I are both online now so that we can discuss this on Slack, so I'll go ahead and tackle the color changes. I'll create one PR for buttons with gradients and another for solid color, and we can see which one we like best.

I think it's worth splitting out the link hover & active menu item color changes into yet another PR. I am not planning to do that one today.

@nylen
Copy link
Contributor

nylen commented Nov 10, 2018

whether the link color change should apply to the admin menu only, or all links admin-wide

I think we might as well change this for the whole admin too.

@nylen
Copy link
Contributor

nylen commented Nov 10, 2018

Okay, I've put together 2 PRs for the button colors:

I like the solid color background better. I think it looks more "serious" and more appropriate for an admin dashboard where the important thing is the utility of the functions being provided.

What do others think?

@nylen
Copy link
Contributor

nylen commented Nov 10, 2018

When we are changing the link hover color, we should change the active control outline at the same time. Here is an example of this color (the blue outline around the select box):

2018-11-10t13 58 59-05 00

I think this outline color should be #07989e .

@nylen
Copy link
Contributor

nylen commented Nov 10, 2018

Another question about the link color changes: should we change the base link color itself (the link color with no hover)? If so, to what?

@senlin
Copy link
Contributor

senlin commented Nov 10, 2018

I agree that within the dashboard a solid color button looks/works better than a gradient one (too distracting, it's a button after all).

@johnalarcon
Copy link
Contributor Author

I like the solid color better, too.

@BlueSkyPhoenix
Copy link

@nylen I suggest the base link color/no hover would be #057f99, like the buttons. Sorry if that was not clear above. I agree w/ your suggestion above on outline color. Anything else?

@nylen
Copy link
Contributor

nylen commented Nov 11, 2018

On the wp-admin screens I'd also like to see the left menu active item color changed to our #057f99, as well as the link text hover.

We need two separate colors here: link base and link hover.

I suggest the base link color/no hover would be #057f99, like the buttons.

I agree. This means the hover color needs to change from what was proposed above because it's the same color.

I think it makes sense to use the slightly darker #006b81 as the hover color. Please confirm.

@BlueSkyPhoenix
Copy link

@nylen confirmed -- thanks for your feedback

@nylen
Copy link
Contributor

nylen commented Nov 11, 2018

Thanks. I haven't looked at the relevant CSS yet, but I think that gives us what we need to proceed with the rest of the color changes. To summarize:

  • #057f99 for link text & active menu item background
  • #006b81 for link hover/active text
  • #07989e for active control outline

@BlueSkyPhoenix
Copy link

Great -- thanks!

@nylen
Copy link
Contributor

nylen commented Nov 13, 2018

I'll plan to get the color changes in for our upcoming beta release. As for the rest, @johnalarcon if you'd like to make some improvements here before beta then it would be good to get some PRs in this week.

@nylen nylen added the help wanted Extra attention is needed label Nov 13, 2018
@johnalarcon
Copy link
Contributor Author

Got through most of the install wording/button changes, but it's not ready for a PR; see https://github.com/johnalarcon/ClassicPress/commit/24f6cff4c627539e3c0e3d99a3228043c2d092ca If anyone wants to complete this, great. It's not likely I'll revisit this soon; I'm on vacation and plan on taking a few weeks away from the monitor. I need it.

@nylen
Copy link
Contributor

nylen commented Nov 13, 2018

OK, thanks for the update.

@nylen
Copy link
Contributor

nylen commented Nov 14, 2018

I'll plan to get the color changes in for our upcoming beta release.

I have a lot on my plate so I would like some help with this task if possible!

@nylen
Copy link
Contributor

nylen commented Nov 16, 2018

I've confirmed that the color changes as stated above are not feasible. There are literally hundreds of places in the admin dashboard that need to be mapped out and looked at first. Here is an example from just one screen - I've highlighted all the elements that would be affected by these changes in blue boxes:

2018-11-15t21 44 57-05 00

I started making these color changes and almost immediately saw problematic elements - here, the contrast between the proposed hover color and an inactive menu item is too low, making it difficult to read:

And there is much, much more where that came from. I very quickly found 5 distinct colors that need to be replaced with the 3 values we mentioned above. The ClassicPress code has 157 distinct references to these 5 color values. Here is a list: https://gist.github.com/nylen/41f8b36c3864fe5f6c57e304f2172f1e

Each one of those references needs to be understood and replaced with an appropriate color value. There are also more colors waiting to be discovered.


This matches my initial feeling about the magnitude and scale of trying to change the design of wp-admin. At a conservative estimate, the current admin design has been in place for 5 years and used on many millions of sites since then. It was foolish to think that we could successfully re-brand it in a few days.

For another, more concrete reference point, there are 24,371 lines of CSS in wp-admin/css alone, spread across 35 files.

So, if we are going to undertake an admin screen redesign or rebranding in the future, we first need a map of all affected screens (wp-admin, customizer, menus, etc). Then we need to use that map to find all the places where current colors are used, and determine a suitable replacement. This exploratory phase is far more work than I will be able to take on by myself, and the mapping & planning will also need to inform new design & color choices.

There are some resources that we can read up on first.


Now let's come back to buttons for a second. In my first screenshot above, you can see a button that was not updated with our color changes in ClassicPress/ClassicPress#223, because it is covered by a different CSS rule.

There are many more examples to find. Here is a screenshot from the Customizer:

2018-11-15t22 23 48-05 00

This is unfortunately pretty normal when making changes to a large software system: in order to make the change, you need to understand as many parts of the system as possible, and we are nowhere close to ready here.

Since the changes that we started making by re-working the button colors are incomplete, and cannot reasonably be completed with the resources we have now, I've prepared a PR to revert the button color changes and put them back the way they were: ClassicPress/ClassicPress#233

@nylen
Copy link
Contributor

nylen commented Nov 20, 2018

We're out of time for beta1. This is an optional change that is "nice to have". If someone wants to pick this up, great... otherwise we will probably not get to it for v1.

@ginsterbusch
Copy link

I still suggest just creating our own admin scheme - OR extend the options for the admin scheme to include several other aspects, and after that, roll our own, which would be the default one selected ..

AFAIR there are several "WP Admin UI" guides around, that could be used as a reference to properly pickl out those aspects, instead of working ourselves blue and bloody :)

cu, w0lf.

@nylen
Copy link
Contributor

nylen commented Dec 1, 2018

AFAIR there are several "WP Admin UI" guides around, that could be used as a reference to properly pickl out those aspects

This would be a good starting point. Can you link to one or more of those guides?

@johnalarcon
Copy link
Contributor Author

johnalarcon commented Dec 3, 2018

The WordPress Admin Style plugin is a fantastic resource for exposing the inner workings of the admin UI. There might also be some useful information at Dot Org Style Guide and Creating Admin Themes.

instead of working ourselves blue and bloody.

It's my IDE that got beat up...just trying to properly highlight the syntax of the PHP/HTML mishmash in the related files. :D

@johnalarcon
Copy link
Contributor Author

I'm working on this issue and will have a PR by the weekend. Bear in mind that it will cover only a subset of what has been discussed here, limited to the scope of the original issue (the install screens).

@johnalarcon
Copy link
Contributor Author

Submitted PR ClassicPress/ClassicPress#265. Looks like Travis is complaining, though... hopefully someone can help me see it the rest of the way through.

@johnalarcon
Copy link
Contributor Author

PR ClassicPress/ClassicPress#265 covers the issue that was originally raised, so, anything else discussed here should be broken off into a different issue for after V1 and this issue closed once ClassicPress/ClassicPress#265 is merged. I think it's clear that we can't consistently, effectively rebrand the dashboard without extensive research on how/where all those colors are applied.

@nylen nylen removed the help wanted Extra attention is needed label Feb 19, 2019
mattyrob referenced this issue in ClassicPress/ClassicPress Nov 20, 2023
* Update nav-menu.js

Improve feedback for accessibility when moving items in nav menu

* Use localized strings in nav-menu.js

* Add new localized strings to nav-menus.php

Adds new localized strings to `nav-menus.php` to make them available in `nav-menu.js`

* Renovate[bot]: Update dependency rollup to v3.29.2 (#211)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

* Renovate[bot]: Update dependency grunt-contrib-qunit to v8.0.1 (#212)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

* JS Coding standards fixes

* Update common.css

Removes CSS that's no longer needed because of previous commits, and adds new CSS to make the nav menu page more accessible.

* Renovate[bot]: Update dependency postcss to v8.4.30 (#215)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

* Update common.css

Changes `focus-within` to use `outline` instead of `border`

* Update nav-menu.js

After some testing, I have found that merely adding `setTimeout` in itself creates enough of a delay to enable the correct message to be generated. There is no need to set a value greater than 0.

* WP-r56622: Add `sys_get_temp_dir()` to `open_basedir` tests. (#218)

In PHPUnit 10.3.5, 9.6.13 and 8.5.34, the child processes used for process isolation now use temporary files to communicate their result to the parent process.

This caused a failure in some tests that set the `open_basedir` PHP directive to a value that did not include `sys_get_temp_dir()`.

This adds `sys_get_temp_dir()` to the `open_basedir` value set by the tests to ensure that permission is still granted for the temporary directory.

PHPUnit uses `sys_get_temp_dir()`. To ensure the result is the same, Core's `get_temp_dir()` function is not used.

References:
- sebastianbergmann/phpunit#5356

WP:Props desrosj, mukesh27, SergeyBiryukov, costdev.
Fixes https://core.trac.wordpress.org/ticket/59394.

---

Merges https://core.trac.wordpress.org/changeset/56622 / WordPress/wordpress-develop@7d96189ba1 to ClassicPress.

Co-authored-by: Colin Stewart <costdev@git.wordpress.org>

* Renovate[bot]: Update dependency node to v18.18.0 (#216)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

* Update nav-menu.js

Improve feedback for accessibility when moving items in nav menu

* Use localized strings in nav-menu.js

* Add new localized strings to nav-menus.php

Adds new localized strings to `nav-menus.php` to make them available in `nav-menu.js`

* JS Coding standards fixes

* Update common.css

Removes CSS that's no longer needed because of previous commits, and adds new CSS to make the nav menu page more accessible.

* Update common.css

Changes `focus-within` to use `outline` instead of `border`

* Update nav-menu.js

After some testing, I have found that merely adding `setTimeout` in itself creates enough of a delay to enable the correct message to be generated. There is no need to set a value greater than 0.

---------

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: mattyrob <mattyrobuk@gmail.com>
Co-authored-by: Colin Stewart <costdev@git.wordpress.org>
@viktorix viktorix transferred this issue from ClassicPress/ClassicPress Nov 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants