Updated: includes info through comment #71

Part of Meta: More Seven Theme issues: #1986434: New visual style for Seven

Problem/Motivation

We visually updated the progress bar in Drupal 7 significantly, we feel this is still a good base. The only thing we did is to round the corners, and to adjust the color pallete slightly

We developed Proposal: A Style Guide for Seven. This issue aims to introduce the proposed styling for the progress bar to core.

To quote the rationale provided:

To appear more cheerful – for the same reason a lobby or waiting room should make an extra effort to be pleasant – progress bars are fully rounded. The progress bar retain much of its current values, e.g. always animated to be scrolling and clearly outlined activity and percentage on each side of the horizontal axis.

Proposed resolution

In #1945526: Add Progress component and small variant we laid the ground work for this change.

Screen Shot 2013-05-07 at 11.49.19 PM.png

Simpletest.me link of patch from #44 (for those who dont have dreditor, or are on a different device where dreditor cannot be added) http://simplytest.me/project/drupal/8.x/false?patch[]=https://drupal.org... and tiny:
http://tinyurl.com/drupal-progress

Remaining tasks

  • (done) Make a patch, See #44
  • Review accessibility
  • find a way forward that acknowledges and builds on the work so far, and gives a way for more opinions: open a follow-up issue for the rounded corners discussion?

User interface changes

The progress bar style will be changed, no functional differences.

before screenshots (from #20)

Screen Shot 2013-05-18 at 6.35.07 PM.png

Screen Shot 2013-05-18 at 6.35.31 PM.png

animated GIFs showing progress movement, from #49

now http://i.imgur.com/AMfQp36.gif

after patch http://i.imgur.com/H3w1qkj.gif

IE9 http://i.imgur.com/zJvftLo.gif

API changes

None

#1986434: New visual style for Seven

CommentFileSizeAuthor
#107 seven.making_progress.1989480.107.patch15.9 KBGaelan
#101 progress-install.png65.83 KBechoz
#101 progress-install-narrow.png31.34 KBechoz
#96 1989480-progress-bar-96.patch15.9 KBrteijeiro
#94 1989480-progress-bar-94.patch16.14 KBrteijeiro
#86 Screenshot_6_19_13_11_56_AM.png119.58 KBGábor Hojtsy
#71 rounded-corners.png427.04 KByoroy
#58 Screen Shot 2013-06-10 at 3.05.50 PM.png4.75 KBtim.plunkett
#58 Screen Shot 2013-06-10 at 3.05.55 PM.png7.38 KBtim.plunkett
#51 progressbar.png44.33 KBtim.plunkett
#47 Screen Shot 2013-06-09 at 19.43.25.png52.23 KBLewisNyman
#46 progress-bar.png34.63 KBrteijeiro
#44 1989480-progress-bar-42.patch16.22 KBLewisNyman
#42 remove-prefixed-css-2005520-8.patch5.36 KBLewisNyman
#33 pb-check-updates.png10.61 KBechoz
#29 pb-working.png10.64 KBechoz
#28 Screen Shot 2013-06-05 at 21.57.12.png21.84 KBswentel
#27 pb1.png4.45 KBechoz
#27 pb2.png6.57 KBechoz
#24 1989480-progress-bar-24.patch10.19 KBLewisNyman
#23 1989480-progress-bar-23.patch0 bytesLewisNyman
#23 interdiff.txt2.85 KBLewisNyman
#21 Screen Shot 2013-05-18 at 6.35.07 PM.png19.91 KBBojhan
#20 Screen Shot 2013-05-18 at 6.34.42 PM.png6.46 KBBojhan
#20 Screen Shot 2013-05-18 at 6.35.31 PM.png14.53 KBBojhan
#18 Screen Shot 2013-05-17 at 4.14.56 PM.png12.27 KBBojhan
#18 Screen Shot 2013-05-17 at 4.14.44 PM.png21.86 KBBojhan
#16 1989480-progress-bar-16.patch10.33 KBLewisNyman
#15 1989480-progress-bar-15.patch10.33 KBLewisNyman
#15 interdiff.txt8.26 KBLewisNyman
#12 1989480-progress-bar-12.patch9.7 KBswentel
#12 interdiff.txt444 bytesswentel
#8 1989480-progress-bar-8.patch9.42 KBLewisNyman
#5 1989480-progress-bar-5.patch9.42 KBLewisNyman
#4 Screen Shot 2013-05-09 at 12.48.07 AM.png7.41 KBBojhan
#2 progress-bar.png9.85 KBoresh
#1 1989480-progress-bar-1.patch2.66 KBoresh
Screen Shot 2013-05-07 at 11.49.19 PM.png63.51 KBBojhan
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

oresh’s picture

Status: Active » Needs review
FileSize
2.66 KB

First attempt. It doesn't cover styles for small version, cause I just couldn't find one.
Also the progressing element and message are inserted in the same element, so it's different from the design.

I hope we change all this stuff in twig ( classes and separating message ) so this patch doesn't cover that.

oresh’s picture

FileSize
9.85 KB

This is how progress looks on my machine.
progress-bar-patch1

kika’s picture

Great, ahem, progress! Probably obsoletes #1477550: Bring progressbar to the postmodern era

Bojhan’s picture

First review

1) The "Initial" state is a little small and does not respect the rounded corners see screenshot below.

Screen Shot 2013-05-09 at 12.48.07 AM.png

2) The height of the progress bar feels a little off, is this the same to the style guide specification? I think we should just implement the large one, by default since you are correct there is no small one in core (except for uploading, but thats probally contrib).

3) Wondering is the design element, of placing the title on top hard to achieve?

LewisNyman’s picture

I decided that it was easier just to update all the mark up and the classes to match the prototype, that means the CSS in the prototype and this patch are near identical.

In order to split the title and the description up, I had to add a new $label variable to the progress bar theme function, progress JS, and the batch api.

I also added a really cool CSS transition. Really cool.

Status: Needs review » Needs work

The last submitted patch, 1989480-progress-bar-5.patch, failed testing.

Bojhan’s picture

Its trowing an "undefined label" exception.

LewisNyman’s picture

Ok let's try this. We also need to make a decision about how much of this styling goes in system vs seven. I vote all in system.

Bojhan’s picture

I think most of it belongs in system?

LewisNyman’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 1989480-progress-bar-8.patch, failed testing.

swentel’s picture

Status: Needs work » Needs review
FileSize
444 bytes
9.7 KB

Should fix the notices

Bojhan’s picture

Thanks swentel for chipping in! This progress bar looks quite sexy. I noticed the "Initialising" state was full width, it should instead only be around 1-5% of the bar

Its kinda hard to replicate, so I made a video at http://screencast.com/t/p8UZN9KS

Bojhan’s picture

We probably need something along the lines of http://drupal.org/files/issues/progressbar_5px.patch

LewisNyman’s picture

Ok, I've added a default width for the progress bar. I've also shifted the CSS from Seven into the system CSS files.

LewisNyman’s picture

On Bojhans request I changed the initial width to 3%.

Bojhan’s picture

Issue tags: +Needs screenshots

This probably needs a screenshot. Other than that it all looked fine to me, I am ready to RTBC this when it comes back green with some nice screens.

Bojhan’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
21.86 KB
12.27 KB

Screen Shot 2013-05-17 at 4.14.56 PM.png

Screen Shot 2013-05-17 at 4.14.44 PM.png

Works!

Comitters please quote designers:

Issue #1989480 by LewisNyman, oresh, swentel | Bojhan, r5yn, yoroy: Progress Bar style update.

Dries’s picture

Can we get a before screenshot?

Bojhan’s picture

Bojhan’s picture

ry5n’s picture

Status: Reviewed & tested by the community » Needs work

Reviewing this now, since I haven’t had a chance yet. Needs a few tweaks but the code looks good, and looks great visually :). I especially love the transition between progress__bar widths. Nice one @LewisNyman!

(Aside: I would like dev credit on this as well, since it was @oresh and I who wrote the new markup and CSS in the Seven sandbox.)

+++ b/core/misc/progress.jsundefined
@@ -22,21 +22,23 @@ Drupal.ProgressBar = function (id, updateCallback, method, errorCallback) {
+                    '<div class="progress__description">&nbsp;</div>' +
+                    '<div class="progress__percentage"></div>');

These elements appear to be source-order swapped compared to theme_progress_bar().

+++ b/core/modules/system/system.base.cssundefined
@@ -140,19 +140,66 @@ table.sticky-header {
+.progress__close {

Since .progress__close doesn’t exist yet maybe we should leave out the CSS for it. (It was intended for operations that can be cancelled, like file uploads).

+++ b/core/modules/system/system.base.cssundefined
@@ -140,19 +140,66 @@ table.sticky-header {
+@-webkit-keyframes animate-stripes {

Since bg position values in the animation must match the gradient in use, this should go in system.theme.css

LewisNyman’s picture

Status: Needs work » Needs review
Issue tags: -Needs screenshots
FileSize
2.85 KB
0 bytes

Cheers Ryan! I've fixed all the above and I added a few more prefixed keyframes to match the animation references

The commit credits should read something like:

LewisNyman, Ry5n, oresh, swentel, Bojhan, Yoroy

LewisNyman’s picture

Ok I messed up, this should work.

Status: Needs review » Needs work
Issue tags: -Usability, -styleguide

The last submitted patch, 1989480-progress-bar-24.patch, failed testing.

echoz’s picture

Status: Needs work » Needs review
Issue tags: +Usability, +styleguide

#24: 1989480-progress-bar-24.patch queued for re-testing.

echoz’s picture

Status: Needs review » Needs work
FileSize
6.57 KB
4.45 KB

I did not show the visual progress bar, just the text.

pb1.png

pb2.png

swentel’s picture

Status: Needs work » Needs review
FileSize
21.84 KB

Works fine here ...

Screen Shot 2013-06-05 at 21.57.12.png

echoz’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
10.64 KB

It was my Safari cache. All good, visually (awesome!) and code changes from #22 implemented.

pb-working.png

Bojhan’s picture

Awesome, commiters please credit all contributors (including the designers)

LewisNyman, Ry5n, oresh, swentel, Bojhan, Yoroy

Dries’s picture

Is it me or am I the only one that thinks that it doesn't look better than the old bar? I'm happy to commit this if there is consensus that this looks better.

ry5n’s picture

@Dries Everyone I’ve heard from personally has really liked the new look, and we didn’t hear any objections when the new style was proposed. However, since I designed it, I’ll have to let others speak up. :)

If this is going in, I just want to make sure we verify the latest patch has been manually tested by at least two people. Does the progress bar appear anywhere other than the installer? Have we checked that?

echoz’s picture

FileSize
10.61 KB

IMO it looks beautiful, the radius matching the "pill" shaped button (which I don't prefer but get), "to appear more cheerful" while waiting, using "Drupal Blue" from the color palette, cleaner stripes, and the best part is this formerly used an animated gif, and it now leverages css gradient, css animation and css transition.

Screenshot from manually check updates. Unable to install a module, or find a small progress bar. I'd be glad to conjure up another example if anyone tells me where to find it.

pb-check-updates.png

swentel’s picture

I find it dead gorgeous.

Wim Leers’s picture

I also find it very beautiful. Plus, instead of the "progress jumps" that happen without this patch, whenever new progress info arrives, this animates to it much more smoothly.

LewisNyman’s picture

I've only heard 100% positive feedback from this change. I love it, it feels modern.

Objective view; it's more consistent with Drupal's brand colours, reflects our brand values better, and the improved information heirachy improves "scanability"

ry5n’s picture

@echoz Looks like theme('progress_bar'… is called once in all of core, as part of _batch_progress_page() in batch.inc. It seems that installing modules through the admin UI does not work at the moment, so I am not sure where else we can do manual testing. Given how limited the scope here is, I’ll leave that up to committers.

joelpittet’s picture

So pretty! Nice work guys:)

LewisNyman’s picture

Status: Reviewed & tested by the community » Needs review
LewisNyman’s picture

Issue tags: -Usability, -styleguide

#24: 1989480-progress-bar-24.patch queued for re-testing.

Status: Needs review » Needs work
Issue tags: +Usability, +styleguide

The last submitted patch, 1989480-progress-bar-24.patch, failed testing.

LewisNyman’s picture

Status: Needs work » Needs review
FileSize
5.36 KB

Re-rolled this patch to take into account the CSS file organisation changes. I also removed misc/progress.gif.

It just needs a quick test to make sure it applies cleanly and an eyeball.

rteijeiro’s picture

Status: Needs review » Needs work

@LewisNyman the #42 patch only removes prefixed css. Is it related to the #24 patch for the new progress bar look and feel?

LewisNyman’s picture

looks like i uploaded the wrong patch

LewisNyman’s picture

Status: Needs work » Needs review
rteijeiro’s picture

Status: Needs review » Needs work
FileSize
34.63 KB

Tested #44 patch and progress bar has been vanished :( (see attached screenshot)

LewisNyman’s picture

Status: Needs work » Needs review
FileSize
52.23 KB

Looks correct for me on simplytest.me? Did you clear your cache?

Screen Shot 2013-06-09 at 19.43.25.png

swentel’s picture

Status: Needs review » Reviewed & tested by the community

Yeah, works perfectly, let's ship it.

corbacho’s picture

Looks good!

GIFs
now
http://i.imgur.com/AMfQp36.gif

after
http://i.imgur.com/H3w1qkj.gif

IE9
http://i.imgur.com/zJvftLo.gif

IE9 bar will show non-striped. But let's be fair. IE9 worldwide use today is less than 10%
http://gs.statcounter.com/#browser_version_partially_combined-ww-monthly...

tinycg’s picture

I like it, even degrades well in IE9 with a nice clean look.

tim.plunkett’s picture

Status: Reviewed & tested by the community » Needs review
FileSize
44.33 KB

Here is a screenshot of the current progress bar for comparison.
progressbar.png

While I don't think the current progress bar is amazing, I have to agree with Dries.
I think the new proposal looks like something I would have expected in Drupal 5.
The colors are very saccharine and it is rounded to an extreme (very Web 2.0), which makes it look even more dated.

Gábor Hojtsy’s picture

I agree with those *supporting* the new look. The new colors are bolder and cleaner, not using this grayish hue which looks washed out to me. Also while this is considered as a standalone change here, it should be understood in the context of the larger scale improvements in https://groups.drupal.org/node/283223 which clean up many of the rounded things in Drupal (and in many cases make them more rounded). I like the new look much better, especially as it fits with the other pieces proposed.

joelpittet’s picture

  • There is a clear style guide to keep things cohesive.
  • The animation is going in the right direction for it's optical illusion to work.
  • The type has a stronger visual hierarchy.
  • Progress between steps is CSS animated.
  • Round corners help complement the logo.
  • The colors are bold and cleaner.
  • Subtle details give the progress bar a bit of depth without going over board.

All around great job!

tsi’s picture

I think the smallest bars are the most stylish, Unless we're putting some text inside the bar, I'd prefer the smaller variant as the default/only one.

tkoleary’s picture

On the question of the smalle vs. larger bar I think that both should be available. There are some operations (install. migration, backup etc. that warrant a large bar if only psychologically to indicate "this is a big operation" whereas things like image upload etc. are fine with a small one.

Overall this work is awesome. Kudos to Lewisnyman, Bojhan, ry5n, corbacho and everyone else who has contributed.

rteijeiro’s picture

Yeah, cache issue. Tested in Chrome, Firefox and Opera (no animation).

Looks cool!! Great work!!

yoroy’s picture

Status: Needs review » Reviewed & tested by the community

I'd much rather have this *not* be a poll or a popularity contest. Nit-picking individual elements is the best way to end up with a wonky, unbalanced look.

If people think there are issues with this particular design, please review Proposal: A Style Guide for Seven and provide rationale how to make it better fit the overall visual language as it is laid out there.

tim.plunkett’s picture

This moves us in the opposite direction, especially with regard to rounded edges.

D7
Screen Shot 2013-06-10 at 3.05.50 PM.png

D8
Screen Shot 2013-06-10 at 3.05.55 PM.png

As someone who spends a good deal of time looking at core's progress bars, I think this is a real shame.
The twitter-bootstrap-ification of core is directly contrary to the other visual improvements that were made.

aturetta’s picture

I'm sorry, but I must agree with @tim.plunkett & @dries. The shape of the new progress bar is not better than the current one.
I'm not discussing the improvement in markup or CSS, just the shape feels older-style to me...

ry5n’s picture

I want to second @yoroy in #57. Since we know some of us like this and some don’t, I doubt that more likes or dislikes are going to help resolve this issue. I’d like to suggest we focus on:

- Is the progress bar as designed consistent with the rest of the Style Guide? If you think not, please point out inconsistencies.
- If it is consistent, then the objection is with aspects of the design direction as a whole. Critique on that score should happen on the original g.d.o post. In addition, any critique on the design direction should refer to the Basic Principles we tried to establish and how we translated them to the final design language. We tried very hard to avoid arbitrary decisions and instead make the Seven theme express the qualities that make Drupal what it is.

tim.plunkett’s picture

g.d.o is not where the Drupal community makes decisions. The issue queue is.

Being told I'm not allowed to voice my dissent here, and that I must instead critique a 4500 word wiki, is not okay.

ry5n’s picture

@tim.plunkett The way I see it, this is basically an implementation issue. If you want to critique the design of this component, it should be either:

a) here, assuming the general direction of the Style Guide is OK
b) elsewhere, if not. If the Style Guide post on g.d.o is not the right place, I don’t know what is.

And lastly, if you want to critique a design system, you should be expected to at least skim the rationale.

cweagans’s picture

IMO, there was a pretty clear consensus on the style guide. We should implement it and call it good. If, after everything is implemented and you can view the entire vision at once, there needs to be some tweaks to make it more cohesive or something, I think that's a much more appropriate time to start that discussion. I'd also like to note that design by committee is not an appropriate goal here - there's a well defined style guide that a lot of people seem to like and approve of. I think that at this point, we should just run with it.

cweagans’s picture

And for the record, +1 for RTBC - this looks great.

swentel’s picture

@tim.plunkett , actually, those will be changed as well according to the style guide, see https://groups.drupal.org/node/283223#Split_Buttons_and_Dropbuttons

And in the end, I can always patch up Batch video ;)

ParisLiakos’s picture

just for the record -1 for me, agreed with #58

dawehner’s picture

So in general if everything would be in a consistent style, the human eye would have no problem at all to adapt. (that's why most like the new style guide in general) but for a single issue the contrast is too much.

What about doing something similar to twig, so get it in just if everything is converted but work on several tasks in parallel.

gdd’s picture

g.d.o is not where the Drupal community makes decisions. The issue queue is.

Being told I'm not allowed to voice my dissent here, and that I must instead critique a 4500 word wiki, is not okay.

I have to agree wholeheartedly with timplunkett here. Decisions that affect core have never been made on gdo, they are made in issues because that is where core development happens. Discussions that spawn issues are meta-issues. This is the only process we have ever had.

Note this is not a commentary on any design decisions at play, which I have no opinion on, just a rejection of the assumption that these decisions were community vetted in any way the community has ever recognized.

YesCT’s picture

I see some parallels here with the way coding and docs standards are done.
There is a page outside of the issue queue (like a docs page), and changes to the standard are done by filing issues.

Maybe we can move forward here by opening up a meta issue for the style guide,
that will assume the style guide as-is-now is a starting point,
and then sub issues ([policy/nopatch issues]) can be filed to discuss changes to it.
once those are decided, they can get a follow-up to implement the change.

In the mean time, while those policy/nopatch issues have discussion, we can proceed with implementation issues against the current style guide.

I heard some talk the other day about needing a way to better have design discussions, and the meta and sub issue suggestion wont solve that problem, but might get us a bridge between the discussions and the issue queue.

Big issues sometimes use helper issues too, and we might be able to use some of the ideas of helper issues.. where work occurs other places (like maybe in groups wikis), and then get reported back semi-regularly to an issue.

----
On this issue, I propose we view this as implementing the style guide,
and then open a follow-up for more rounded corners discussion.

YesCT’s picture

Issue summary: View changes

meta issue added

yoroy’s picture

FileSize
427.04 KB

Sorry for not pointing that out before, but the meta issue exists and is linked in the issue summary above: https://drupal.org/node/1986434

So we once again run into the known issue that our collaboration tools are lacking. From my perspective we did play by the book: hash things out in a peer group on g.d.o., write a blog post calling for feedback. Create a meta issue in the queue and split off manageable chunks of work in seperate issues.

I do feel the style guide has been community vetted. By peers. I don't contribute to discussions around caching, OOP architecture or whatever technical topics. Likewise, it's hard for me as a designer to take "me no like" comments as reasonable design feedback. But maybe YesCTs proposal is the way to go.

Anyway,

The roundness of the progress bar corners have little to do with button roundness, it's not applied here to communicate "I'm clickable" since there is nothing to click on.

yoroy’s picture

Issue summary: View changes

added before screenshots.

joelpittet’s picture

Issue summary: View changes

Updated issue summary. Added meta to related

YesCT’s picture

Issue summary: View changes

added gifs and simplytest.me link -yesct

YesCT’s picture

Status: Reviewed & tested by the community » Needs review
Issue tags: +Needs accessibility review

I updated the remaining tasks in the issue summary.
One of the remaining tasks was to do an accessibility review. I dont see a comment saying that was done. Adding the tag. Moving to needs review.
(If it was already done, and I missed it, move the status back and link to the review.) https://drupal.org/contributor-tasks/accessibility-review can help someone to an accessibility review.

I also updated the issue summary with a simplytest.me link to make it easier to try out, and gathered related before and after screenshots and the animated gifs.

YesCT’s picture

Issue summary: View changes

updated remaining tasks and took out duplicate meta line in beginning. -yesct

LewisNyman’s picture

I really don't want to derail this issue but I don't buy that 100% of the action happens in the issue queue. There are many places where strategy and implementation is discussed, IRC, Google Hangouts, Skype, g.d.o, face-to-face, wiki documents, sandboxes.

All issues should reference the decisions and logic that have come before it. We've done that in this issue.

tstoeckler’s picture

I totally have to agree with @yoroy and @LewisNyman. Almost all of the initial WSCCI patch didn't happen in the queue. Same for SCOTCH. Same for Twig. And due to the fact that we don't have a road map or a set of focus issues it's very easy to miss issues that are in the queue, even. Very often issues get re-opened after commit because people that totally disagree with the entire premise.

Now that's not to say that there isn't a huge problem with our process, but it's completely unfair to blame this on the Design/Seven team.

tkoleary’s picture

@heyrocker

I have do respectfully but strenuously disagree with you on this one.

The reason why design pulled this issue into groups is very simple. The issue queue and the whole process of decision making in Drupal is a system designed by developers for developers using developer tools, paradigms, rules and processes. It has worked quite well and there's nothing wrong with it as long as all we are talking about is development. The problem is that the entire process is antithetical to the way that designers are used to working, sharing, collaborating and coming to consensus.

As yoroy and others have pointed out, even given the artificial environment that we are forced to inhabit, we did follow established rules. I think it's important to note here that if Drupal is really committed to valuing design (recall the comment about no designer being on the stage in the Portland core conversation). We must overhaul the *process* to provide a workflow for design that works for designers.

tkoleary’s picture

@tim.plunkett

"g.d.o is not where the Drupal community makes decisions. The issue queue is.

Being told I'm not allowed to voice my dissent here, and that I must instead critique a 4500 word wiki, is not okay."

As yoroy pointed out this did not all happen in groups there is a meta issue and comment was requested. Consensus has already been arrived at in lengthy discussions. If I were jump in to the whiskey queue right now and say "I think this should all be based on SNMP instead of REST" I would (probably unceremoniously) be told that the time for that decision has passed.

Since every user of a UI has an opinion on the design of the UI and CSS is easy to change there seems to be an attitude that we can continually re-open these discussions. To do so is to invalidate the time, effort and expertise of the designers and the opinions of all of those who cared enough about design to take the time to review and comment on them.

I'd also like to point out that none of the style guide design work was done by me, though I did comment on it. I maintain the Ember admin theme which takes a different approach on many of these design questions. That said I applaud the work that has been done on the style guide and it's implementation by ry5n, bojhan, lewisnyman and yoroy. A comprehensive review and overhaul of the core admin theme was long overdue and they did an awesome job. It's time to stop the critique and get as much of it implemented as we can.

ps. If you really dislike it so strenuously, write your own admin theme. :)

gdd’s picture

The reason why design pulled this issue into groups is very simple. The issue queue and the whole process of decision making in Drupal is a system designed by developers for developers using developer tools, paradigms, rules and processes. It has worked quite well and there's nothing wrong with it as long as all we are talking about is development. The problem is that the entire process is antithetical to the way that designers are used to working, sharing, collaborating and coming to consensus.

As yoroy and others have pointed out, even given the artificial environment that we are forced to inhabit, we did follow established rules. I think it's important to note here that if Drupal is really committed to valuing design (recall the comment about no designer being on the stage in the Portland core conversation). We must overhaul the *process* to provide a workflow for design that works for designers.

Actually for large discussions like this one it doesn't even work for developers! I had to resort to gdo many times for architectural discussions related to CMI. The difference is that when those discussions reached agreement (or when I forced agreement on them in one case) I made an issue back here and opened it up for comment because I know the community doesn't watch stuff over there. Sometimes I would timebox these discussions but still nothing was final until it came back here where people *actually work*.

Additionally, while I don't deny that our tools are especially foreign for the design community, I would also argue that making one that works is probably a whole separate topic that should be managed on its own, not three people suddenly deciding to implement a new way of working without any greater discussion in the midst of a reasonably important and wide-ranging issue.

Anyways, I'm bowing out of this, because there is actually good work being done here and I don't want to get in the way of it anymore. I was really more trying to expand on the reasons why some people might be a little taken aback by things and why saying "this decision has already been made outside the issue queue" really rubs people the wrong way.

Gábor Hojtsy’s picture

Assigned: Unassigned » Dries
Status: Needs review » Reviewed & tested by the community

Fully agreed with @tstoeckler in #74. Every word.

Anyway this looks like plenty of feedback for Dries to consider.

yoroy’s picture

It's a pity something like this should have to be assigned to the project lead to make a decision. The process discussion is absolutely very valid, certainly not constrained to 'design' but not to be solved in here. I'd love to find a good place to continue this discussion.

Dries: it's still rtbc, so you can either commit it or set it to 'needs work'. In case of the latter, try to provide rationale beyond 'not looking better' to give the designers something to work with.

Gábor Hojtsy’s picture

It is moved back to Dries not for any process discussion feedback but because he tweeted asking people to provide visual feedback here and that was his only complaint. So I guess that makes any other core committer impossible to commit this. It would be the same if it would be about changing an API or removing a feature.

yoroy’s picture

Ah ok, thank you.

Gábor Hojtsy’s picture

#44: 1989480-progress-bar-42.patch queued for re-testing.

effulgentsia’s picture

This issue still has the "needs accessibility review" tag, but is also RTBC. Is the suggestion to delay an accessibility review to a follow up, and if so, why?

Dries’s picture

Assigned: Dries » Unassigned

I had never seen the style guide until earlier today (https://groups.drupal.org/node/283223). In general, I'm very impressed by the style guide work. It would have been better if I could have signed off on that months ago. It seems like we have some process/communication problems on this. Having said that, I'm ok with moving forward with this design guide.

At this stage of the game, every patch that gets committed needs to get us closer to a releasable state. Meaning, if we commit the progress bar patch today, than we should be willing to ship Drupal 8 with none of the other design changes made. We can't create critical or major follow-up issues relative to the style guide. Put differently, we should either be comfortable shipping an incomplete conversion to the proposed style update, or wait to commit a bigger or whole theme update at once.

In terms of process, I'd look towards the Seven maintainer to tell me what style changes need to be bundled as one patch, or what style changes can be committed individually (with no release blocking follow-up). I recommend that we appoint a new maintainer for Seven, as Jeff Burns hasn't been active lately. Once we have a new maintainer for Seven, the new maintainer can decide whether the progress bar can be committed independently. I think ry5n would be a great candidate for this role, if he is willing and able to.

Bojhan’s picture

@Dries Thanks for providing this input. I am sad that you didnt see it before, sadly there wasnt much more we could do within the existing communication platforms (g.d.o, twitter, planet, meetings, irc), we used them all to broadcast our activities.

I have opened #2022927: Add new maintainer for Seven for this. I would recommend lewis, knowing r5yn wanted to take a bit of a break. I dont think many of the design changes are dependant on each other its already pretty inconsistent. But lets move all that discussion to #1986434: New visual style for Seven

Gábor Hojtsy’s picture

@Dries: Drupal is already in a transitioning state between different styles, just see the buttons on this attached image (did not embed because not directly related to this issue). 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. 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.

effulgentsia’s picture

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.

Correct. July 1 is API freeze, not theme, markup, or CSS freeze. But it is still the case that committing partial work needs to move us closer to rather than farther from a releasable state (i.e., it shouldn't result in knowingly introducing new critical or major issues, or needing to raise the priority of existing issues). I think this specific issue is an isolated enough part of the UI that it's fine to commit on its own, but regardless of the decision on this issue, it would be good to get clarity over in #1986434: New visual style for Seven for how that entire issue needs to be structured in order to satisfy the above requirement.

tkoleary’s picture

@effulgentsia

I think the approach that we should take here is to make an effort to abstract markup changes necessitated by elements found in the new seven style guide from style changes. I believe that there are several of these. Doing this would remove discussion about font, color, spacing icons etc. from the queues (for a while) and focus efforts on creating a flexible, modern armature on which any admin theme can hang.

The seven theme patches themselves can continue to progress (and inform the parallel markup process) and when all of the patches to Seven theme are RTBC it can be committed at once.

I believe this would meet the bar of "[not] knowingly introducing new critical or major issues" since the markup changes don't introduce style inconsistencies and the style changes are unlikely to cause critical bugs.

ry5n’s picture

@Dries Thank you for the offer. Unfortunately I’m not able to take this on at the moment; I’ve left more details in a comment on #2022927: Add new maintainer for Seven.

I was also disheartened when I found out that our efforts to get feedback on the Style Guide had not reached core decision-makers and other key parts of the community. I would have loved to have received all of this feedback (and criticism) earlier. It would be worth looking at how we tried to get the word out, what we could have done differently, and help avoid what happened here in the future.

Thanks to everyone who has offered critique and support for this work.

LewisNyman’s picture

Issue tags: +API change

It might not be immediately clear that this issue introduces some small changes to the batch api. I guess that means it needs to be committed before code freeze.

LewisNyman’s picture

#44: 1989480-progress-bar-42.patch queued for re-testing.

alexpott’s picture

Issue tags: -API change

This change does not make a backwards compatibility break in the Batch API, also, the addition of the label to the theme function is an addition and is acceptable after API freeze.

+++ b/core/misc/progress.jsundefined
@@ -81,8 +83,9 @@ $.extend(Drupal.ProgressBar.prototype, {
+          console.log(progress);

This does not need to be here :)

alexpott’s picture

Status: Reviewed & tested by the community » Needs work

Changing status...

rteijeiro’s picture

Status: Needs work » Needs review
FileSize
16.14 KB

Fixed #92

echoz’s picture

Status: Needs review » Needs work

Correctly removes the line noted in #92. Now needs re-roll (system.module-rtl.css) since #2015789: Remove language_css_alter() (RTL stylesheets) in favor of HTML 'dir' attribute got committed.

rteijeiro’s picture

Status: Needs work » Needs review
FileSize
15.9 KB

Re-rolled. Go for RTBC!!

echoz’s picture

Status: Needs review » Reviewed & tested by the community

I also used quotes on the rtl attribute selector on 2 patches earlier today. Lets see what happens with these in combination with #2030925: quote rtl attribute selector, I see more re-roles in our future!

Pancho’s picture

Status: Reviewed & tested by the community » Needs review

I don't agree we can only buy this in a package or leave everything in the current - admittedly awfully inconsistent state.
I can understand that designers often get severely annoyed by clients starting debates on this and that aspect. Still, such debates are unavoidable, even more in a community. And given the generally appreciative feedback on developing a Style Guide, I don't see the current proposal getting picked to pieces.

While a lot of aspects in the Style Guide are unquestioned improvements, a number of aspects raised questions and divided opinions, apart from some apparent inconsistencies this includes colors, the fully rounded input elements, and more generally the amount of "softness we wish to express" as the Style Guide states it. Also, this is certainly more than a progressive touch-up on Seven as we know it, so if it should be put into place, it should be called Eight or Seven 2.0 or whatever else.

But I don't want to pretend being neutral, and admittedly can only agree with #51:

I think the new proposal looks like something I would have expected in Drupal 5.
The colors are very saccharine and it is rounded to an extreme (very Web 2.0), which makes it look even more dated.

While I agree that it seems a good idea to bring a bit more friendlyness to the admin backend, this seems to me a clear overdose. Also, friendlyness doesn't necessarily mean softness and expressiveness. For many admins the admin theme is "their everyday workplace". It should be friendly, yet serious, it should convey ease of use but also accuracy. It should be as pleasant when in a good mood as when in a bad mood. Above all it should be decent enough to make the admin feel in control.

Is it too late to join the party? IMHO, the Style Guide has not yet generated enough awareness and involvement. We have more than enough time to give the raised concerns a bit more weight. We even have enough time for a second proposal.

Therefore I'd propose to start with the technical improvements. We can also try to identify aspects that can be split apart without ruining the coherence of the design, or which need a separate and closer examination anyway, for example typography, or iconography. Bojhan made an attempt in #1986434-15, but I believe he thought more of implementation steps than of breaking up discussion into a number of separate tasks.
In any case, we need more general discussion on #1986434: New visual style for Seven, before putting one or the other aspect into place. Therefore sorry, but from my point of view this certainly isn't RTBC.

Pancho’s picture

Status: Needs review » Reviewed & tested by the community

Didn't mean changing status myself though.
If the maintainers say, it's RTBC, then be it.

Dries’s picture

Lewis: Is this RTBC?

Might be good to check whether it still works with the new installer. Possibly provide screenshots.

echoz’s picture

I did test on the installer, and here's screenshots for both full and narrow viewports.

progress-install.png

progress-install-narrow.png

LewisNyman’s picture

Issue tags: +styleguide-independent

@Dries This is RTBC. I'm confident this patch won't raise a critical accessibility regression.

I've also tagged this with "styleguide-independent", which means it can be committed on it's own without a visual regression.

tkoleary’s picture

@LewisNyman

Awesome. So much smoother too.

YesCT’s picture

Issue tags: +RTBC July 1

This issue was RTBC and passing tests on July 1, the beginning of API freeze.

alexpott’s picture

Status: Reviewed & tested by the community » Needs work

Needs a reroll...

curl https://drupal.org/files/1989480-progress-bar-96.patch | git apply --check
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 16279  100 16279    0     0  28875      0 --:--:-- --:--:-- --:--:-- 37770
error: patch failed: core/modules/system/css/system.module.css:186
error: core/modules/system/css/system.module.css: patch does not apply
Gaelan’s picture

Assigned: Unassigned » Gaelan

Rerolling.

Gaelan’s picture

Assigned: Gaelan » Unassigned
Status: Needs work » Needs review
FileSize
15.9 KB

Rerolled!

Bojhan’s picture

Status: Needs review » Reviewed & tested by the community

Tested, and it works.

Dries’s picture

Status: Reviewed & tested by the community » Fixed

The comment and tag in #102 was exactly what I was looking for. Thanks! Committed to 8.x.

nod_’s picture

Issue tags: +JavaScript

this changed a js file, tagging accordingly

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

Anonymous’s picture

Issue summary: View changes

tiny url. -yesct