(Very related to #2902399: Redesign the Admin UI, which is a parent of this. This issue aims to look only at the re-skinning part, which is one part [ideally achievable in a single release cycle] of a more holistic redesign effort of the overall admin experience.)

Problem/Motivation

Myself, along with some of my co-workers, were tasked by Dries to perform a series of interviews along with other research to try and determine what the main blockers are for Drupal 8 adoption, as well as what factors are leading to Drupal 8 being hard to use. (These findings will be part of the Driesnote at Nashville.)

We've talked to over 50 people at this point, from site builders, to developers, to support and sales people, to trainers, both enterprise-level and small-medium business level, from various points on the globe including North America, Europe, and India. From this research, we feel we've gleaned a solid set of common pain points and have some suggested next steps.

One of the common complaints was around Drupal's admin experience looking/feeling dated, especially compared to our competitors. Complaints cited were things like colours, use of whitespace... various interviewees who were involved in curating an evaluator experience for potential new Drupal users universally cited that choosing a more modern-looking admin theme instantly led to Drupal being better-perceived by said users.

There was an amazing community effort to Create a Style Guide For Seven that vastly improved its look + feel compared to the original (designed back in 2008). However, this refreshed design was from 2013—5 years ago. Design best practices have moved on since then, and Drupal itself has evolved as well, now including much more functionality out-of-the-box than Drupal 7 shipped with back in the day, and the Seven Style Guide does not yet reflect these.

Proposed resolution

Improve upon the existing Seven Style Guide to create a fresh and modern look and feel to Drupal 8's admin theme, to create a favorable first impression of Drupal for evaluators and a better user experience for site authors.

See some "prior art" from @jojototh at https://marvelapp.com/961cib4 as a possible starting point.

(One thing we are explicitly not proposing as part of this initiative is evaluating, selecting, and incorporating one of the popular contrib admin themes, rather than improving the look/feel of Seven. That's because this approach a) would be highly politically charged [ala the huge Bartik vs. Corolla vs. etc. debate back in D7], b) result in a lot of required foundational work to bring said theme up to core quality standards, c) potentially take the overall design of Drupal's admin experience out of our hands, if we went with something like Material Admin which is owned by Google, and d) these factors together making it unlikely for the effort to be completed in a single minor release cycle... we only have until July if we want to target Drupal 8.6.)

Remaining tasks

  • Initial idea vetting with community members involved in recent core design efforts
  • Open issue in ideas queue for public discussion period <= we are here! :)
  • Identify initiative coordinator(s) - @ckrina has offered to help lead this initiative.
  • Get product management sign-off on idea
  • (After that) Develop more detailed implementation plans, including literal biksehedding of colours, etc. (please don't delve into those details here... ;))

User interface changes

Yes. Colours, whitespace, etc. In a way, this will invalidate all of the books, screenshots, training videos, etc. out there. However, since our goal here is a "refresh" vs. an entire new theme, hopefully the change is manageable enough that consumers of those resources will be pleasantly surprised at how nice it looks, vs. confused.

API changes

No, though possibly API additions? If skinning elements that weren't skinned before requires adding new theme/preprocess functions?

Data model changes

N/A

Comments

webchick created an issue. See original summary.

jhodgdon’s picture

Small suggestion: get rid of the ALL CAPS that is in the Seven CSS for things like headers on views edit pages, table column headings, and the fieldset summary elements (the open/close links). Reasons:
- They are kind of ugly/shouting in general
- They are less readable than regular text. This affects people with dyslexia and other reading disabilities even more than those without.
- Some screen readers will read words in all caps letter by letter instead of word by word. (e.g., A-L-L C-A-P-S instead of "all caps" as words)

jhodgdon’s picture

ckrina’s picture

I believe the main strength of this approach (starting with a redesign of Seven) is that it will allow us to have an impact into the short term and still will be able to reuse the redesign to work on future updates of the interface in a short/medium term. Another point in favour is that the work can be easily distributed into d.o. issues.

In a longer term (8.7, 8,8?), we could update interaction patterns and more complex designs using the base done here. Some abstract ideas and notes related to this can be seen on DrupalCamp Ruhr notes from the discussions with @yoroy, @ifrik and @sun.

As discussed during today's UX meeting, a possible MVP or first scope could be the redesign of the current elements of the style guide (with basic elements like colors, typography, form elements) + some composites of those: navigation, tables, header / footer.

About the timing, if we want to have something viable for 8.6, we should have a first version of the design ready for sign-offs and feedback in June.

webchick’s picture

Hm. Ideally, a bit sooner than that, I think... if we don't have a viable patch by June, it's very unlikely to have made it through the review/re-work/sign-off/commit cycle by mid-July, which is when feature freeze for 8.6 is.

andrewmacpherson’s picture

There are some other accessibility improvements we can make.

1)
I'd like to improve the focus styles in Seven. Drupal's admin UI has great keyboard-only accessibility so far, but the focus styles could be refined. While the original D8 styleguide did describe some focus styles like the blue button halo, there are several different focus styles in play, and in some cases the focus style is rather weak.

For example, the drop button. The first link (manage fields, say) gets an underline, but the more-options arrow button just gets a slight background colour change and is easily missed.

Historically, WCAG 2.0 SC 2.4.7 Focus Visible just says there must be a visual indication that an element has focus. It doesn't set any requirements for focus styles having clarity though. We've had some issues discussing strong focus styles before, but they've been bogged down by the idea that they might be ugly, or that strong focus styles should only appear on keyboard interaction. See #1993574: Add focus styling to all interactive elements and #2735421: Make Seven theme's link + button focus styles more robust for keyboard accessibility.

One thing's clear though: weak/subtle focus styles are very little use to sighted keyboard-only users who rely on them.

Now WCAG 2.1 is trying to address this, and the new "Non-text Contrast" criterion expects interactive states to have sufficient colour contrast. In my view, that settles the argument: we'll need stronger focus styles. Bonus points if we can get achieve more consistency too.

On a positive note, I pushed for strong focus styles in the Umami theme, and the rest of the team were very receptive to them. We managed to achieve some very clear styles in #2938194: Focus styles should meet accessibility guidelines in Umami theme, and have some follow-ups for a few other cases.

I'm not a fan of underlines being used as a focus style. Default browser styles vary, but generally fall into two camps: the "blue glowing ring" (chrome, opera), or the dotted rectangle (IE, firefox). However what they both have in common is they indicate focus by surrounding the element on all four sides. So I feel that underlines are weaker than the default browser focus styles, because they don't make as much use of space.

Another problem with underlines as a focus style, is that browsers use underlines as the resting style for links - they normally look like that without focus. And if we use underlines as a focus style, we can't use them to indicate links in their resting (not focused) state. Which brings me to...

2)
Underline links wherever they appear inside a sentence. This one's important, because we currently have an explicit WCAG failure. I've filed #2958282: Links inside surrounding text fail WCAG Use-of-Color in Seven theme to address it.

andrewmacpherson’s picture

Re: #5 - I think some of this can be done incrementally. The link style failure is quite an isolated change.

andrewmacpherson’s picture

yoroy’s picture

As for timing: We need some time for a solid design phase. Ideally we would find a way to implement this that is not one big patch against Seven. If we have a way that lets us commit changes incrementally we could start committing stuff even sooner, because we would only have to review its fitness for beta by the end of the development cycle? Tying this directly to Seven feels like we only get one chance to do it right with a big patch at the end, which is not good imo. Maybe a subtheme of Seven?

dawehner’s picture

Maybe this feels like a troll, what about copying seven in its current state, call it "eight" and mark it as experimental?

yoroy’s picture

@dawehner no, something like that is exactly the pragmatic kind of approach I'm looking for :)

ckrina’s picture

@dawehner a new theme makes a lot of sense, actually. I'm not sure what is the best approach, but I think it should let us use the issue queue as much as we can and this approach would let that happen.
Now is the moment to put all cards into the table with all the options we have and discuss them. Any other idea? :)

sun’s picture

I wanted to do #10 directly after DrupalCamp Ruhr to commit & push the working prototype from my local disk somewhere, but found out that https://www.drupal.org/project/eight is occupied already. Then I got lost in diffusive brainstorming about naming.

I agree that a separate theme is the best procedure. But in my opinion, even a pure rebrush/re-skinning needs more time to evolve and get better through testing in actual production sites, before we attempt to "lock down" a v1 (even if only experimental) in core. I would therefore recommend to proceed with a contrib project first, which can be tested and installed by users. If this is in line with your thinking, then I would be happy to help with this effort and set up the project, maintainers, initial repo/code, and so on.

jhodgdon’s picture

RE #13 -- It's definitely way easier to work on an "experimental" project in a Sandbox/Contrib project rather than trying to get every single proposed change through the drupal core review process!! That way you can have multiple issues in the sandbox before you even try to get it into Core, and have lots of small issues instead of one big one, no need for a huge meta issue to discuss everything, etc.

davidhernandez’s picture

I'm a little confused. I would have inherently thought to just make a new theme, but that brings the baggage of release deadline and switching it over in the install profile as well as worrying about some tests. But if avoiding that means an iterative approach on Seven itself, it is marked @internal so can change any time. Why worry about 8.6 release deadline? Is it too disruptive to see small, iterative changes in minor releases? (Just asking, I have no preconceived notion.)

andrewmacpherson’s picture

Doing this in a single release cycle feels ambitious to me. For comparison, the Umami theme didn't get to stable in a single release, even after the designs were largely complete.

For the accessibility gate, this will likely involve a lot of review and manual testing. The "one giant patch" approach sounds daunting for this. There's a lot of potential to introduce regressions compared to Seven. Having an experimental theme would make this easier, because we could break the accessibility regression testing down in separate issues (by design component and/or WCAG criteria). This would be (a) easier to triage, and (b) easier to crowdsource among a11y contributors.

sun’s picture

@andrewmacpherson While smaller steps are good for QA (and I certainly agree on that), design & UX work typically can't be "framed" into smaller pieces – until the bigger picture has been put together and finalized. Only after that, you are in a position to break down the actual changes into byte-sized pieces — but that would only be necessary if we'd shoot for a Seven v2.x, which I believe we are not (anymore) (?).

We're still in a "design discovery phase" with this whole initiative. We have some good ideas to simplify and clean up the user interface, but replies to https://twitter.com/tha_sun/status/977322182094344192 make clear that we are not there yet.

This is why I would still recommend to do this in contrib first.

@yoroy & @ckrina: Essentially I'm waiting for your decision here. Happy to proceed (fast) with your okay :-) Feel free to ping me on Slack on this.

In fact, I will have to work on this area anyway in next 1-3 months, as I need to establish a modern authoring experience for a custom content publishing project based on Thunder, so it is pretty sure that I will opt for that contrib option anyway, as I'm asked to produce. I won't have time for daunting core review processes in this phase, but I'd love to put things into a shape that can be used as base for Core.

The field of admin/authoring UX is still my favorite domain. My work on Administration menu changed how people are working with Drupal today (and we still need to fix a ton of UX issues in Toolbar module to complete the reinvention of that wheel). I still develop products. And I want our products to shine.

jmarkel’s picture

I had tweeted this during Dries' keynote last week but will repeat it here:

The content creators I work with have, in the past, really disliked working on a Drupal system in no small part because of the Seven theme. It's OK for tech-oriented site builders, but content creators don't really get it. I introduced the 'Eleven' theme that Morten has been developing and the content team immediately found it much clearer and easier to use. It does consume a bit more screen space, and has some other shortcomings, but it's early days yet. So I'd suggest, rather than updating the very tired Seven, moving forward to something built around, or at least much more like, the Eleven theme.

yoroy’s picture

I'm looking for a way to make many incremental changes that add up to something we can release by 8.6. I agree Seven looks dated, but it's complete. It covers everything we have in core. I strongly prefer an approach that improves what's there.

What I worry about when starting in contrib is that we'd still work towards a mega patch in the end. If we start from within core we can iterate in smaller steps at the time.

@davidhernandez re "Is it too disruptive to see small, iterative changes in minor releases?". Not necessarily but I think we want to be able to assess the cumulative result by freeze date for 8.6 to see if we've made something coherent enough.

jmarkel’s picture

@yoroy I understand - my concern is more along the lines of wanting not to build a better, more refined, horse-drawn carriage at a time when the rest of the world is moving to driverless electric automobiles.

ckrina’s picture

So far the plan is:
Step 1. Create something we can use soon, ideally launched in 1 release cycle.
Step 2. Reuse and evolve the design for the Modernizing JavaScript initiative.

This issue is to decide & plan step 1, having in mind there will be step 2. So whatever we do in step 1:
- We should be able to reuse as much as we can in step 2.
- We should have something committed in 8.6, with an MVP around June.

So far the options I think are being proposed are:
A. Create a new theme from scratch in contrib. It must be already developed and should have a patch against core by June.
B. Create a new theme from scratch and mark it as @internal.
C. Commit changes incrementally in a Seven subtheme.
D. Commit changes incrementally copying seven in its current state, (call it "eight"?) and start doing changes there. Mark it as experimental or @internal.

I'd go for option D because we don't break backward compatibility for Seven, we have a working theme from the beginning and we could avoid the mega-patch with tons of changes.

yoroy’s picture

@jmarkel Not buying that analogy :) Afaik alternatives like Eleven and Material admin do little that goes beyond cosmetics (Material does goed things with filters/bulk operations in its extra module). As @ckrina points out, initial focus is to make a visual update happen. Funky features are what is worked on inside the javascript intiative.

D. Commit changes incrementally copying seven in its current state, (call it "eight"?) and start doing changes there. Mark it as experimental or @internal.

Any good reasons to *not* take this approach?

webchick’s picture

None that I can think of; let's do it! :)

webchick’s picture

We talked about this a bit further on the product management meeting today... while creating an Eight theme and starting work on it is certainly possible (release manager approval pending), we'll get a lot more velocity if we can work out some of the specifics (e.g. "what colour of black to use here," "how many pixels of whitespace there," etc.) NOT in the core queue. So copy/pasting Seven into a contrib theme (or a GitHub repo, or...) and working from there is probably a more sensible approach as long as this issue (or some other "implementation" issue) in the core queue gets updated periodically (~weekly or more often) with current progress. That way there's visibility, adherence to gates, etc. but also the ability for the team to move quickly, since we only have ~8 weeks if we want to ship something in 8.6.

yoroy’s picture

One big reason to not do it in core right from the start is that the core process is generally too slow.

@sun et all, so:
- lets figure out a way to do this in contrib
- start with a copy of Seven
- make sure any changes made to Seven get pulled in
- establish some cadence in which we post an actual core patch of our progress on a weekly(-ish) basis.

Also: though we can start under the "Eight" name, lets come up with something more inspired :)

webchick’s picture

For those wanting to help/keep abreast of this initiative, there is a team gathering in #admin-ui on Drupal Slack.

andrewmacpherson’s picture

WCAG 2.1 reached the "Proposed Recommandation" stage this week - the last before full Recommendation - so it's stable enough to work with now. None of the new success criteria are "at risk" any more, and hopefully they won't be changing the names again. The supporting notes ("Understanding Non-text Contrast", etc.) have also been fleshed out considerably.

This is excellent timing for the Eight re-skin project, so I'd like to propose we make WCAG 2.1 (level AA) the target for the new theme. This would mean that as well as avoiding accessibility regressions (compared to Seven), we'd also address new criteria like "Non-text contrast" so icons and focus styles have strong contrast.

The big carrot on offer here is that if we go for WCAG 2.1 in the new theme, then maybe we won't have to commit to retrofitting Seven to satisfy WCAG 2.1 ever. I'd still file WCAG 2.1 bugs against Seven, but as soon as Eight stabilizes they could be marked outdated/won't-fix, say. Bartik doesn't get off the hook though :-)

lauriii’s picture

+1 for creating a copy of Seven in a separate repository and starting to make changes for that. That helps building momentum early in the process and makes it less risky to do refactoring for the existing code base. Looking forward to seeing the designs 🤩

ellioseven’s picture

Just wanted to add in my two cents.

I have been experimenting with my own administration theme (https://www.drupal.org/project/titus). This just simply extends Seven but replaces all the stylesheets. The aim is to provide a visual makeover without dramatically changing the UX. Here are some screens: https://imgur.com/a/F3wNu

Based from my experience, I think the best way to approach a new modern administration theme is to start from scratch and focus on building base styles and components, such as typography, forms, buttons, tables, etc. While keeping the familiar UX of Seven.

I believe the best way to approach a redesign would be to produce some style guides, which can then be used to create "overall look and feel" mockups. A good example to take inspiration from is the GTK UI toolkit: https://developer.gnome.org/gtk3/stable/ch03.html This provides a reference of all the included modular components. This is flexible and adaptable.

I took a modular/component based approach with Titus, this allowed me to build an modernised UI quite quickly, without too much work. I personally feel it looks a lot nicer than Seven and doesn't detract from the UX I am used to.

In a nut shell I propose the following strategy:

1. Research other flexible component based UI's (bootstrap, atomic design, etc.)
2. Create a base style guide (typography, forms, tables, colours, etc.)
3. Create a component style guide (drop buttons, table drags, lightboxes, etc.)
4. Implement base and component style guides into a new theme
5. Begin to theme overall structure (layouts, etc.)

Throughout all the steps, modularity, reusability and flexibility should be a primary goal to allow compatability with custom modules as well as a JS admin theme in the future.

EDIT:

Just wanted to add that perhaps we could integrate a new administration theme as an "experimental theme" and make incremental changes from there.

ipwa’s picture

@yoroy I quite like 'Ocho' for the theme name.

webchick’s picture

We spent some time talking about this at Frontend United. The gist was:

1) From a "product" POV, we need to work our way towards a "next-gen" content authoring and admin UI that's all React-ified and jaw-dropping amazing, akin to WordPress's Gutenberg (soon to be installed on 30% of the web) or SquareSpace or Adobe or so on.

2) That's going to take some quite some time and design/implementation effort (at least 9 months before we'd see even a beta of this in a shipped release, and 18+ months to see it in production). In the meantime, we are hemorrhaging potential Drupal adopters today because the default admin experience is so far behind where our competitors are even 3 years ago. Part of that is how it "feels," but a great deal of it is also how it "looks." Hence, this initiative.

3) Between now and Newfangeldy Awesome Spanky UI Of The Future, and even for a long time after once we have that, we're going to be in this "hybrid" mode where the vast majority of Drupal modules are outputting UIs via Twig, and the newfangeldy modules are outputting their UIs in JS. We need to admin experience jumping between the two types of UIs to be as seamless as possible.

4) And, even in the Future Awesomeness Mode, we're also going to need some basic boring old config forms, like the Performance page.

5) Hence, this initiative should focus on creating a "design system" that can encompass both the standard form-based UIs we have today, as well as "next-gen" UIs and making those delightful to use.

6) And so, in order to create an achievable milestone and and get it out in front of people the fastest, with the least amount overhead/maintenance headache for a theme we hope to deprecate as soon as the newfangeldy one is available, we should take the existing Seven theme as-is, and modify it to conform to this design system. This gets us a shorter-term win on the "look and feel" side, while laying important foundation work for Future Awesomeness. Versus trying to create a new, PHP/Twig-based theme that we're going to similarly deprecate once Future Awesomeness exists.

TL;DR: Let's take Seven, copy/paste it into a repo somewhere, and go to town on the designs coming from @ckrina/@yoroy, then commit it ASAP as "$bikeshed_TBD" experimental theme that's basically Seven++. Those who want to work on next-gen UI can take part in the JavaScript Modernization initiative (just renamed to Admin UI & JavaScript Modernisation initiative). The end. ;)

andrewmacpherson’s picture

Doubling down on #27... WCAG 2.1 is a now a full W3C Recommendation, so let's design the new theme for that.

W3C announcement: https://www.w3.org/blog/2018/06/wcag21-rec/

andrewmacpherson’s picture

Issue tags: +wcag21, +Accessibility
rlnorthcutt’s picture

A few things to note:

  • The jsdrupal project for the React components is relying on Material Ui (which makes sense).
  • We should consider some alignment with Material Design to make things work better
  • Efforts to do this could take a significant amount of time, and we hope to get something out sooner.

All this being said, I think we should look at the Material Admin theme - NOT because we should necessarily use it, but because we could potentially pull ideas and code (css, templates) from there. If you look at the bug tracker for the project, you can see quite a few of the types of issues we are likely to run into, and that they have been taken care of already.

Material Admin has over 1k reported sites using it, it has almost 15k downloads, and got some great feedback when presented at the Con. The theme represents almost a year of work and effort by a few developers (not 100% full time, but in community time). It's also based on classy (like Seven), so it should be really easy to pick/choose what we want. There is also quite a bit of active use in production and lots of feedback.

Honestly, this could greatly accelerate the process. Depending on the details, we could conceivably get something in contrib space by the time 8.6 launches. It would also make it easier for the jsdrupal project to test their work against this reskinned Seven sooner.

ipwa’s picture

ckrina’s picture

First thanks @rlnorthcutt and @ipwa for sharing your thoughts about this! I have to say that I had your point of view until we discussed it at Frontend United.

First, just want to point out that the new admin UI in JS is being developed relying in Material UI because we haven’t finished the design system yet, but we will switch to this new design system in the future. And we can’t rely on Google’s Material Design system because I doesn’t solve all Drupal’s needs. Quick example: we need a solution for long and site-builders-proof labels and that isn’t possible following to the letter the guides here https://material.io/design/components/text-fields.html

The main reason why we agreed to proceed this way is because we realized that both the new JS UI and the redesigned theme (Seven or any other contrib theme) will need to live together for a while until the whole UI is in JS. And jumping from a Material theme page to another with a completely different look&feel can create a really confusing experience. (See @webchick comment 3 in #31)

Another decision taken there was not starting from scratch with this new PHP/Twig-based theme and instead of that make the enhancements in a Seven clon that is already working. It’s taken years to get to the point we’re right now in Seven and throwing all this work away (ie. accessibility) and starting from scratch would take too long.

ipwa’s picture

I just started testing the Material Admin theme today and thought it had some clever stuff but I'm not a big fan of how for example the Views UI looks, it looks more complicated than it should with those heavy fieldset labels. The things I did love about the theme where for example the way you choose the publishing date. Maybe we can borrow some ideas like that and add it to the proposed new Seven theme.

Date example: https://www.drupal.org/files/material-admin-date.png

rlnorthcutt’s picture

@ipwa - thanks for the correction!

@ckrina - I appreciate the careful and detailed reply. As I haven't been intimately involved with this discussion, I was sure there were plenty of details I didn't have. My goal was simply to make sure that this was added to the discussion.

webchick’s picture

Status: Active » Fixed
Related issues: +#3017785: Designs for a new admin theme

Doing some housekeeping. This got approved as an initiative way back in the day... the actual designs are at #3017785: Designs for a new admin theme and implementation happening at https://www.drupal.org/project/claro.

Closing this puppy out!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.