Problem/Motivation
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:
- Identify Drupal core values that we can use to determine the look & feel for the Seven theme.
- Unify the visual language in Seven and ensure the overall look-and-feel supports the core values.
- Identify the visual and UI patterns used by Drupal core so that they form a conscious, shared language for us to built upon.
- 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.
Outstanding Issues — #styleguide
Issues that need to be created
- Image field
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
Comment | File | Size | Author |
---|---|---|---|
#1 | style-guide-change.png | 137.71 KB | Bojhan |
Comments
Comment #1
Bojhan CreditAttribution: Bojhan commentedComment #1.0
Bojhan CreditAttribution: Bojhan commentedUpdated issue summary.
Comment #1.1
ry5n CreditAttribution: ry5n commentedAdded overlay implementation issue
Comment #1.2
Bojhan CreditAttribution: Bojhan commentedUpdated issue summary.
Comment #1.3
Bojhan CreditAttribution: Bojhan commentedUpdated issue summary.
Comment #1.4
Bojhan CreditAttribution: Bojhan commentedUpdated issue summary.
Comment #2
gddThere 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.
Comment #3
amateescu CreditAttribution: amateescu commentedThe 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.
Comment #4
yoroy CreditAttribution: yoroy commentedMaybe 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.
Comment #5
Bojhan CreditAttribution: Bojhan commented@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).
Comment #6
dawehnerAn 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.
Comment #7
LewisNyman CreditAttribution: LewisNyman commentedI 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.
Comment #8
yoroy CreditAttribution: yoroy commentedOk, 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?
Comment #9
ry5n CreditAttribution: ry5n commentedList of issues above is not complete. We should also revert what has already been committed (messages, vertical tabs) until we get everything done.
Comment #9.0
ry5n CreditAttribution: ry5n commentedAdded pager issue
Comment #10
Dries CreditAttribution: Dries commentedPlease 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.
Comment #10.0
Dries CreditAttribution: Dries commentedUpdated issue summary.
Comment #10.1
echoz CreditAttribution: echoz commentedadded Content header
Comment #11
YesCT CreditAttribution: YesCT commented#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.
Comment #12
effulgentsia CreditAttribution: effulgentsia commentedBojhan in #5:
ry5n in #9:
Gabor in #1989480-86: Progress Bar style update:
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.
Comment #13
Gábor HojtsyDrupal 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.
Comment #14
LewisNyman CreditAttribution: LewisNyman commentedThere 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
Comment #15
Bojhan CreditAttribution: Bojhan commentedSo 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.
Buttons
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).
Grouping
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).
Navigation
Primary tabs, secondary tabs. This needs to go in as one, we cannot split this out.
Table
Table. The same as navigation we cannot split this out more. Its also pretty close.
Modal
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.
Typography
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.
Icons
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:
Comment #15.0
Bojhan CreditAttribution: Bojhan commentedadded remaining task... blocker to pick maintainer, who can then decide on commit strategy
Comment #15.1
LewisNyman CreditAttribution: LewisNyman commentedAdded the status report issue
Comment #16
LewisNyman CreditAttribution: LewisNyman commentedForm 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.
Buttons
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.
Navigation
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.
Comment #17
effulgentsia CreditAttribution: effulgentsia commentedIn #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.
Comment #18
klonos#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:
Comment #18.0
klonosAdded installer issue
Comment #18.1
ry5n CreditAttribution: ry5n commentedAdded https://drupal.org/node/2032773
Comment #18.2
tim.plunkettUpdated issue summary.
Comment #18.3
dead_armAdd link contrast issue to list.
Comment #18.4
LewisNyman CreditAttribution: LewisNyman commentedAdded a few more issues.
Comment #18.5
LewisNyman CreditAttribution: LewisNyman commentedRemoved irrelevant issues and added tag link.
Comment #18.6
LewisNyman CreditAttribution: LewisNyman commentedAdded testing directions
Comment #18.7
tkoleary CreditAttribution: tkoleary commentedadded #538788: Implement Seven pagers as designed
Comment #18.8
tkoleary CreditAttribution: tkoleary commentedadded #1899236: Rewrite dropbutton into splitbutton.
Comment #19
chippper CreditAttribution: chippper commentedJust 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.
Comment #20
c8n CreditAttribution: c8n commented@#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 ...
Comment #20.0
c8n CreditAttribution: c8n commentedadded #1899236: Rewrite dropbutton into splitbutton.
Comment #20.1
LewisNyman CreditAttribution: LewisNyman commentedUpdated issue summary.
Comment #20.2
LewisNyman CreditAttribution: LewisNyman commentedAdded a list of issues that need to be created
Comment #20.3
LewisNyman CreditAttribution: LewisNyman commentedUpdated issues to create
Comment #20.4
LewisNyman CreditAttribution: LewisNyman commentedremoved file field from issues to create
Comment #21
klonos...moving related issues to their dedicated metadata section.
Comment #22
LewisNyman CreditAttribution: LewisNyman commentedComment #23
jwilson3Comment #24
tkoleary CreditAttribution: tkoleary commented@jwilson3 oooh, svg throbber. Now that would be nice!
Comment #25
LewisNyman CreditAttribution: LewisNyman at Wunder commentedComment #29
AaronChristian CreditAttribution: AaronChristian at Acro Commerce commentedComment #32
webchickWe brought this up on the weekly UX meeting, since @lauriii has been doing work on this, and the question was raised as to whether or not this work would be valuable to complete, given part of what contributes to Drupal's admin UI looking subpar is that the style guide here was not ever completed.
Both @ckrina and @yoroy pointed out that they feel this effort would detract from future efforts going on at #2902399: Redesign the Admin UI, and require time/focus/energy from the same people. So they would prefer to "freeze" Seven where it's currently at, and focus any improvement efforts on the modern redesign efforts.
As such, closing this as "won't fix." Thanks so much for all of the efforts nonetheless! We'll see you over there!