-
-
Notifications
You must be signed in to change notification settings - Fork 1
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
Comments
Related Slack chat: https://classicpress.slack.com/archives/CCNEEH86P/p1541364210294700 |
@johnalarcon Thanks for taking the time to do these! |
I am wondering if change only the installation page is the best solution. |
@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. |
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. |
@nylen Continuing the conversation from https://classicpress.slack.com/archives/CDGP8FW56/p1541464830199200?thread_ts=1541431855.169100&cid=CDGP8FW56 |
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:
|
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. |
@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. |
@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. |
@johnalarcon for convenience: Buttons Aqua (white text): Purple: Yellow (dark text): 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! |
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. :) |
I don't think we have an agreement yet. From a core development perspective I see two things to be careful of here:
So, I'd leave the primary install button alone (maybe adding 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. |
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. |
@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 |
Ok I agree with all of that, and the wording changes for the installation screens. So this is sounding like a plan:
(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. |
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.
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:
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.
Got it; separate PR. The work is clear here.
Good point. This can also be a separate PR, as well. |
@johnalarcon on your questions -- see below. Tagging @nylen here to get his confirmation as well.
Default:
border-bottom-color: transparent; (for all)
Default: #057f99
I'd like to see these changes admin-wide.
Hopefully @nylen will respond to this specifically. I'd like to see the active item ("Dashboard" 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. Thank you! |
@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. |
I think we might as well change this for the whole admin too. |
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? |
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? |
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). |
I like the solid color better, too. |
@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? |
We need two separate colors here: link base and link hover.
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. |
@nylen confirmed -- thanks for your feedback |
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:
|
Great -- thanks! |
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. |
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. |
OK, thanks for the update. |
I have a lot on my plate so I would like some help with this task if possible! |
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: 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 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: 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 |
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. |
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. |
This would be a good starting point. Can you link to one or more of those guides? |
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.
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 |
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). |
Submitted PR ClassicPress/ClassicPress#265. Looks like Travis is complaining, though... hopefully someone can help me see it the rest of the way through. |
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. |
* 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>
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.
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.
The text was updated successfully, but these errors were encountered: