In Proposal: A Style Guide for Seven, we set out to overhaul the visual style of Seven. This was met with a lot of great feedback, which we have largely incorporated. However much of the feedback was in line with implementation details, that we need to hash out in the core queue.

At large the goals of this style change is to:

  1. Identify Drupal core values that we can use to determine the look & feel for the Seven theme.
  2. Unify the visual language in Seven and ensure the overall look-and-feel supports the core values.
  3. Identify the visual and UI patterns used by Drupal core so that they form a conscious, shared language for us to built upon.
  4. Provide guidelines and rationale for others (e.g., contrib) to build upon as new interactions, styles and platforms emerge.

We took a holistic approach looking at all of the items and defining our basic style principles and then diving deep into the actual elements. This was a process of several dozens of hours across r5yn, Bojhan and yoroy. In the end this resulted in the presented guide, much of it is still in flux as we fill in the details. All source files can be found in the groups discussion.

Summary: Style principles

  • A primarily light tone to appear bright and open
  • A neutral, desaturated color palette, both friendly and calming.
  • Legible, readable typography. Employs a typeface with some humanist characteristics in a few weights and styles.
  • Crisp lines and sufficient contrast, but not jarring. No large areas of bold colour.
  • Bold shapes reserved for headings and action elements.
  • Some rounded forms to communicate friendliness and naturalness.
  • Little or no ornamentation: no patterns, textures, gradients or shadow/emboss effects – except to communicate affordances.
  • Borders and background tone as grouping devices only: to clarify relationships and emphasize important elements.
  • Generous and consistent use of whitespace.
  • Aesthetically appealing, though minimal graphic style; should appeal simple but not sterile; gracious rather than opinionated; confident without overspeaking.

Issues that need to be created

  • Image field
  • Details and Accordion

User interface changes

Most, if not all elements will be changed - from the styling of the overlay, to the roundness of buttons. Our aim is to bring one consistent style that upon implementation can be documented and maintained as strategy.

API changes

There will hopefully be no API changes required for any of these patches, however we will see conflicts with the currently ongoing Twig and CSS clean up work.

Testing process

Each issue should contain a select of test pages which provide sufficient coverage that a commit should not cause visual regressions. Before and after screenshots are useful for each test page.

Views testing process

Views is by far Drupal Core's most complex UI, it requires it's own testing coverage to ensure a commit does not cause regressions. Each issue can provide before/after screenshots of the following use cases.

Simple use cases

  • Add a new view via the wizard (admin/structure/views/add
  • Select the basics and hit save.
  • On the view edit form, select a new filter for the node type
  • Change the row format to show fields
  • Add the body field to the output, and rewrite the output to use [body]
  • save the view

Advanced use cases

  • Enable a display
  • Disable a display
  • Choose the table style and enable click sort
  • Add a filter by title
  • Add a filter by author
  • Rearrange the filters to have the author first
  • Add a relationship
  • Override the fields configuration // To test the override select
  • Add a contextual filter for Node: ID and setup a validation for a specific node: type
  • Expose a filter
  • Click preview
#1 style-guide-change.png137.71 KBBojhan


new137.71 KB

Issue summary:View changes

Updated issue summary.

Issue summary:View changes

Added overlay implementation issue

Issue summary:View changes

Updated issue summary.

Issue summary:View changes

Updated issue summary.

Issue summary:View changes

Updated issue summary.

There is a threat that some of these items may get in and some may not, which would leave the Seven UI in a mixed state between old and new styling, an even worse scenario than just leaving it be. It will also potentially cause issues to be filed about this inconsistency, since I'm guessing there are quite a few people not really aware this is going on. Therefore I would suggest that these changes take the same approach that we took with Twig - don't commit anything until all the patches are RTBC. This will avoid inconsistency in the interface and make the whole refresh happen *poof* one day. Seems to make sense to me.

The problem with your proposal is that Twig had the luxury of working in one issue per template file, so I assume that the risk of having conflicts between patches was pretty small. All this UI stuff needs to happen in one place only, the Seven theme.

Maybe that is the right strategy, but keep in mind that between what's in D7 and what's been added to D8 *outside of style guide related issues* through things like the new create content page, views in core, redesigned 'action' buttons has already introduced some serious inconsistencies for Seven theme. So we're already beyond the state where 'leave it be' is less worse.

@heyrocker Thanks for 1) putting this here, in the right issue, heh 2) providing strategic process feedback, which is not something we get very often.

However I agree with @yoroy here, leaving it as is would likely be worse than trying to make it more consistent. One of the reasons we undertook this effort is because its been very inconsistent throughout D8. Also we can make these changes pretty much up to release, as far as I know none of it requires API changes. It's also not significant as Twig, e.g. its not two models its just a few styles that will be out of tune. Hopefully if everyone chimes in, the only inconsistencies will be on things that "we can kinda live with it" without a decision (e.g. the font/icons).

An alternative approach to writing multiple patches would be to work in a sandbox and get a full working sevenNG/eight theme done.
Once it is ready replacing seven with it is pretty simple and in the meantime people can review all the bits.

While doing that you should work in issues (maybe even on the core issue queue) and not just commit stuff to this sandbox. This allows a good review of the changes later.

I agree with @heyrocker, I think that would be the optimal way to implement the style guide. The the main problem is, we've got three initiatives that are all touching the same files (twig, mobile, design). I'm not sure if we have the technical firepower to maintain many patches or a sandboxes against other sandboxes or commits. Like Yoroy said, some change is better than none. I fear if we took the sandbox route the initiative would fail.

Ok, lets organize it that way then. It builds on what we've already set out to do in existing issues, only adds we get all of them to RTBC before committing. Even if we don't get everything RTBC we could still make some smart choices about what to commit and what not.

Thanks heyrocker!

Next: is the list of working issues above complete?

List of issues above is not complete. We should also revert what has already been committed (messages, vertical tabs) until we get everything done.

Issue summary:View changes

Added pager issue

Please see my comment on #1989480-84: Progress Bar style update. The next step is to appoint a new maintainer for Seven. Once we have a new maintainer for the Seven theme, myself and the other core committers can work with this person to decide which design elements to add when.

Issue summary:View changes

Updated issue summary.

Issue summary:View changes

added Content header

#2022927: Add new maintainer for Seven
is the issue to do that.
updated the issue summary to reflect the remaining task asked for in #10.

Bojhan in #5:

leaving it as is would likely be worse than trying to make it more consistent

ry5n in #9:

We should also revert what has already been committed (messages, vertical tabs) until we get everything done

Gabor in #1989480-86: Progress Bar style update:

So if we want to end up with a consistent product (vs. the image shown), I don't think not doing most of the style guide is an option

Given all that, if someone's inspired to do so, it would be helpful, I think, to update the summary with what the current HEAD state is, and if we consider any of the existing inconsistencies in HEAD to be release blocking. If yes, then we would need to either open a critical issue to roll those back, at which time, this could proceed as a noncritical issue, or if we think that's impractical, then this issue (or at least the parts of it that must happen to get us into a releasable state) would need to become critical.

Drupal is already in a transitioning state between different styles, just see the buttons on this image:

All kinds of shapes and colours even for buttons used at the same place for the same main operation :D So if we want to end up with a consistent product (vs. the image shown), I don't think not doing most of the style guide is an option. I mean we can argue about applying consistent styles that are not in the style of this plan but then we need to make up that style too, which is even more work.

These are also not API changes, so I think the conventional wisdom is that it is perfectly possible to work on them even if not all of them land before July 1st.

There are issues that have relationships. Icons, color palette, layout, typography, and other visual conventions across several issues.

We should document the relationships so we can decide how to handle them. Right now we don't even have an issue for every component. Some issues are currently implementing everything but icons and waiting for a wider spanning issue to implement them: #1849712: Add theming template and prepare logic for rendering icons It could make sense to take this approach for other relationships

So I did a short breakdown of what needs to be done and which issues are interrelated. I agree with the statements above that although desirable to commit everything at once, its likely to stifle getting any of this into core. Little of it will likely cause big visual inconsistencies and often we have more inconsistencies without the style guide patches, than with. With that in mind I would strongly advise, to keep getting these patches in as small incremental changes - rather than one large.

Form elements
Input forms, checkboxes, text area. These are all connected it frankly doesn't make much sense to get them in without one or the other. Because if this ends up in core impartially we have inconsistent looking forms.

Primary buttons, secondary buttons, dropbuttons, action buttons. This can all go in separately if needed. We currently already have a mesh of different buttons and even if one or two don't end up looking a like in core, we should be fine if we converted atleast the major ones (for which we have a patch).

Fieldsets, Vertical tabs. Vertical tabs is in already, even if fieldset doesn't make it I think doing it separately is fine - given its such a small change (rounding and background).

Primary tabs, secondary tabs. This needs to go in as one, we cannot split this out.

Table. The same as navigation we cannot split this out more. Its also pretty close.

Overlay, modal dialog. This can go in separately given that its currently messy too, however ideally these styles go in rapidly after each other given that they are often used in conjunction in a flow.

Getting this in is a little bit of a long stretch, but fundamental to making it all look beautiful. This cannot go into core in phases, its an all in approach.

I am largely not that concerned about icons. We can do it separately or as a library, if you look at the state of Drupal 7 you will find large inconsistencies between most of the icons. Many of them are designed by different people, with different visual visions. By doing it separately we can make sure no issue is held up on getting icons into core.

In terms of issues that still need to be created, I'd say we need:

Issue summary:View changes

added remaining task... blocker to pick maintainer, who can then decide on commit strategy

Issue summary:View changes

Added the status report issue

Form elements
As it stands we don't do any non-layout styling on checkboxes correct? I think we could commit just the text fields without a regression.

I would prefer buttons and dropbuttons to go in together but I agree that committing just the basic buttons patch would not be a regression.

Surely the tabs and the overlay patches need to go in together?

I'm concerned about having two partially implemented colour schemes in Seven but off the top of my head every issue touches colours, so the only solution would be to commit in one large patch, which might not be worth it.

but off the top of my head every issue touches colours

In #1989480-88: Progress Bar style update, @tkolearly suggested it might make sense to decouple markup changes from css changes. Maybe do markup ones incrementally, but save all css for one big patch. Maybe that's too extreme, but perhaps color can be decoupled from other changes? Anyway, this is very much out of my realm of expertise, so leaving to you all to decide.

#1297962: Brainstorming for D8 Admin Theme features was closed as a duplicate of this issue here. I'm copy-pasting my comment from there so it doesn't get lost...

Browsing Drupal's admin UI as it is now feels like going through a whole user manual. I know that there's a convenient option available right there to hide descriptions in order to get a slightly more clean UI, but still the UI presented to the admins out-of-the-box is overwhelmingly filled with help/explanation text everywhere!

Icons make the (any) admin UI navigation faster and make the product look more polished/refined to newcomers. By faster navigation I mean the fact that they enhance the users' ability to instantly spot task links on the page by visually memorizing their icons. There's also this very helpful article on the matter: Admin 2 + Rubik: Improved UI for Drupal Admins

I love the tabs with icons for admin task categories in RootCandy:

I mostly like how special care has been taken in Rubik to "categorize" the level of importance of each task and then provide the right type of icon depending on this:

...vary color saturation by the importance of the task presented to the user.


Rubik applies this idea to Drupal and begins categorizing administrative pages into several groups:

  • Essential content management and system management pages
  • Build/task pages where you create or manipulate new site building structures
  • Informative pages like reports or logs
  • Configuration pages where users adjust settings

The end result is a much more balanced set of icons where the most common and critical administrative tasks stand out visually from the rest.

Issue summary:View changes

Added installer issue

Issue summary:View changes

Updated issue summary.

Issue summary:View changes

Add link contrast issue to list.

Issue summary:View changes

Added a few more issues.

Issue summary:View changes

Removed irrelevant issues and added tag link.

Issue summary:View changes

Added testing directions

Issue summary:View changes

added #538788: Implement Seven pagers as designed

Issue summary:View changes

added #1899236: Rewrite dropbutton into splitbutton.

Just throwing a link in here on this issue - there is a side issue on whether or not to rename 'seven' in D8. Personally, I really think we should, especially considering how much effort is being put in here.

@#18 klonos: I think this is a really personal question of taste and view point. I remember me in D6 days liking root candy much, but I think it is not the best example to discuss on here since this look and feel is very outdated and from my personal point of view not even less cluttered. Looking into my test installation of Drupal 8 with ember and the navbar (toolbar) active I rather feel organized and arrived in this century than in your examples.

@#19 Why not keeping the name convention where the admin theme from D7 was Seven and from D8 will be Aight? I like the idea ...

Issue summary:View changes

added #1899236: Rewrite dropbutton into splitbutton.

Issue summary:View changes

Updated issue summary.

Issue summary:View changes

Added a list of issues that need to be created

Issue summary:View changes

Updated issues to create

Issue summary:View changes

removed file field from issues to create