Redesign the Admin UI

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.

Bravo.

+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!

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!

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.

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

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.

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.

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.)

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...

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." :)

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
  • Define goals/vision
  • Define/ find targets
  • Study competitors & others. What are they doing? Some work started here: #2944689: What could Drupal implement from other CMS or content editors to improve its Admin Interface?
  • Define clear product requirements
• Design phase
  • Information architecture. Our interface is full of drupalisms that come 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 Information Architecture
  • 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

It's come up in interviews I've been doing at Dries's request with various people about Drupal 8 adoption blockers / pain points that the current admin experience is definitely one of them. The entire core admin experience is more than overdue for a holistic redesign, from a re-skin to redesign to improve colours + whitespace usage, to a redesign of various common page components such as table headers + filters to be more compact and nice-looking, to incorporating more advanced, dynamic UI features that will hopefully be provided by the Modernizing JavaScript initiative.

I spoke with @yoroy and @ckrina about this, and we agreed to re-purpose this issue to discuss and build plans around that more "holistic" effort, and to spin off #2957457: Proposal: Modernize the look/feel of the Seven admin theme as the re-skin effort, which is one part of this, and hopefully, thanks to its limited scope, achievable in a single release cycle.

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

We’ve been discussing this with @yoroy and the goals so far are:
- Create a new design to be applied by the Modernizing JavaScript initiative.
- Refresh the default Admin UI as soon as possible.

The plan we’ve came up with so far is:
- Design a new UI.
- Adapt the designs to a “normal” theme.
- Launch a refreshed substitute for Seven. It’s a strategic movement because we don’t want to stay another year or 2 with the current Seven until a new&fancy JS Admin theme is complete. Ideally we should have it for 8.6 in September, so alpha in June. #2957457: Proposal: Modernize the look/feel of the Seven admin theme
- Develop the new Admin UI with React. On the first iterations we had with the JS Modernisation initiative it seemed like the “normal” theme would be the fallback for the React theme, so the “new theme” wouldn’t be useless work dying in 1 year. #2926656: [plan] Modernize Drupal's JavaScript

WCAG 2.1 is a now a full W3C Recommendation, so let's use that as the target for new admin UI designs.

Some inspiration maybe - Laravel released new admin panel https://medium.com/@taylorotwell/introducing-laravel-nova-7df0c9f67273

@ckrina: Nice!

Just a suggestion based on the User-create.png at #9, It would bring better user experience to bring out (eye) icon (to visualize password entered) on password field if we doesn't have any confirm password field.

Re: #19 we're already looking at visible password toggle in #2293803: Replace confirm password element with a new element that allows toggling to view the typed password.

Is claro making this issue outdated?

@nod_ I'd say so

closing because #16 is what essentially happened since then.