Drupal's admin UI (the Seven theme) starts to feel outdated and needs a visual update. It was created for D7 at 2008/2009, when many of current Drupal's features and components didn't exist and Seven's UX was not counting with them.

I think it's a good time to start gathering ideas of where the Admin experience should visually go.

Perhaps we could have a design hackathon at Drupalcon Vienna to gather visual ideas for Drupal's new visual language. I believe this has a potential to turn into a new Admin UI initiative:)

First screens that I created to kickstart discussion: https://marvelapp.com/961cib4

Drupal Admin UI redesign

#9 User-create.png99.79 KBckrina
#9 Content.png196.41 KBckrina
#9 Node-title.png259.82 KBckrina
#9 Node-images.png250.43 KBckrina
#9 Node-body.png184.29 KBckrina
teaser.png531.89 KBjojototh
Members fund testing for the Drupal project. Drupal Association Learn more


jojototh created an issue. See original summary.

jwilson3’s picture

Overall, excellent work! Like the visual direction being taken here. Light, soft, rounded fonts, buttons, and inputs, generous whitespace.

This will be appealing to non-technical site administrators.

I do have a couple of small technical issues on the node edit screen. Left feedback in comments on the marvel app.


ckrina’s picture

+1 to that. Current UI design was a great improvement, but some years have passed since then.

A design hackathon in Vienna sounds great, count me in!

Maybe some more steps to prepare it would be to create a list of UI elements to design. Also, as @jojototh says, it could become a new Admin UI so I guess elements like colors, animation & typography could be discussed too.

@jojototh thank you for starting this!

Bojhan’s picture

Keep exploring :) Looks exciting!

We did this a while ago with r5yn too, and the core of Seven in its branding is quite open to refresh. It's quite some work, but it is time. I would gladly provide input on strategies how to approach this, but first I would say keep exploring!

andrewmacpherson’s picture

I'm not keen on the toggle buttons in the initial design. They convey information by colour alone. While there is a shape change (switch moves to left or right hand side) it's not clear whether ON is represented by right or left - that info comes from the blue vs grey distinction.

Checkboxes and radio buttons have an empty vs. full shape affordance, but toggle buttons are always "full", because the switch is at one side or the other.

Aside: which side of a toggle represents ON in a right-to-left language?

Explicit on/off labels (or yes/no...) for each side of the toggle would that. The can be inside the slider track (so moving the toggle reveals one state name or the other) or both always visible, either side of the toggle.

andrewmacpherson’s picture

I really like the vertical tabs, much leaner than Seven and Bartik.

andrewmacpherson’s picture

The border-less grey buttons present a challenge for colour contrast.

In WCAG 2.0, colour contrast success criteria apply to text only. However the WCAG 2.1 update is bringing new success criteria (scheduled for mid-2018), and eventually our accessibility gate will switch to that. By the time we get around to shipping a new admin theme, we will hopefully be addressing the new success criteria.

For the buttons, the new SC 1.4.12 User Interface Component Contrast (Minimum). Broadly speaking, contrast is no longer just required for text, but also applies to borders, outlines, focus styles, etc.

Example: on the Content listing, there's an "apply to selected items" button...

  • The background is page is white
  • The button background is a medium grey
  • The button text is dark

The button text will need 4.5:1 contrast against the mid-grey button background, to meet existing WCAG 2.0 SC 1.4.3 Contrast (Minimum).

As I read WCAG 2.1 SC 1.4.12 User Interface Component Contrast (Minimum), the button background would need to have 3:1 contrast against the surrounding page background. The button has no border, so I'm assuming the button has at least 3px padding. The "blue submit button with no border" example in the Understanding User Interface Component Contrast is the one that best describes the buttons in these designs.

andrewmacpherson’s picture

Issue tags: +accessibility
ckrina’s picture

184.29 KB
250.43 KB
259.82 KB
196.41 KB
99.79 KB

Here are some more explorations I created for a project. It picks ideas both from Wordpress' Gutenberg new plugin and Contentful. Its main visual goal is to move away from the "typical form" as was commented on Slack.

User create page

bdeclerc’s picture

I concur with Andrew, while the proposals look stylish I think it's important that the contrast fits in with the WCAG guidelines, the contrast on most of the UI text is way too low.

Do like the layout with the vertical tabs - perhaps think about the mobile version as well (probably drag them from left & right and overlap with the actual form fields when open.)

roland.molnar’s picture

During the BoFs and Friday sprint in DrupalCon Vienna we did brainstorming, wrote user stories, categorized the target users and lined up a vision.

We used this document to collect ideas and conclusions: https://docs.google.com/document/d/1CudJAVFFt6FK_Lh5-n6_lkHsOHn5tnMkMreS...

The main outcomes were:

We have to re-design and re-think the entire admin user experience and editorial experience from scratch.

3 main categories for functionality/user stories:

  • Create & manage content (content editing)
  • Build structure and functionality (site building)
  • Building functionality (module development)

Future Drupal customers - with Dries’s “Ambitions Digital Experiences” in mind

  • Headless/decoupled where Drupal is mainly used for content repository
  • E commerce
  • Publishing industry / Media
  • Large community sites
  • Education / Universities
  • Government / Public institutions / NGO
  • Booking systems

Most of these above will probably not use frontend inline editing tools for content editing, because they have complex content editing and moderation workflows.

We think that 80% of these users will be doing content editing using large screen devices (laptops, desktops etc), however we need to keep mobile experience in mind.

This will form the vision for the Redesign Admin UI initiative.

The Vision:

Declutter and simplify the content authoring experience by driving user’s focus on the content itself, modernize the tools used for content authoring and move the meta/settings/workflow elements to a new “utility(ies)” section(s).

How to achieve the vision

  • Visually separate content worked with from the tools used.
  • The solution should empower and communicate multiple “mental concepts” of using Drupal, for example “workspace switcher” is pulling from top to communicate that you can work with multiple workspaces “Drupal instances”, “settings tray” will come from side as you are working with current Drupal instance...
webchick’s picture

This issue was brought up in today's UX meeting as something we ought to dust off again now that #2921367: Add the JS modernization initiative to MAINTAINERS.txt is getting closer to being officially kicked off. Especially given that Out of the Box got so far this release, that hypothetically frees up some front-endy/design-y people to start tackling this long-standing and important problem.

So, "poke." :)

ckrina’s picture

I guess this will require some kind of plan, so here is a really quick draft to start talking about it and plan where and how we can ask for help:

  • Discovery Phase
  • Design phase
    • Information architecture. Our interface is full of drupalisms that comes from decisions made years ago. But how does it feel to a newcomer? I’d say that we could really use some UX tests here like opened card sorting, for example. The work has already started here: #2755613: Restructure the Admin interface
    • Redefine interaction patterns now that some limitations will probably no longer apply, like the need to refresh the full page with every interaction. It applies, for example, to the position of elements like the Toolbar, patterns like outside-in, or the look&feel of forms and the amount of information we show.
    • Low-fidelity designs
    • Tests
    • Design
    • Define the Style guide (UI, Language, animation, …) & pattern library
  • Apply & Develop