Bring progressbar to the modern era

This seems like an issue we didn't fix yet, I was looking at it just now in "Seven" and indeed looks a bit outdated. There are a lot of indicators for progress.

Wowa this is awsome, would love if this could get some theming love indeed. I see the colors might need some touching, but the animation itself seems very good.

+1. Our progress bar does look awful.

We should also add -webkit-border-radius to have rounded borders not only in gecko/mozilla/firefox but also in webkit (safari, google chrome, etc). And maybe also the CSS3 border-radius property even if it's so far unsupported by major browsers.

And there is no proper cross browser rounded borders AFAIK. If we want to have rounded borders in IE as well, we need to do it with background images that have a transparent background at the outside. Or we decide that IE users won't get rounded borders.

hmmm, I really like this, it makes a lot more sense to me than the previous way with the fat border and stuff

this way of doing it eliminates the need to cope with certain browsers failing at sub-pixel rendering, in fact, this gave me an idea of how to fix the current implementation without the need for dirty overflow:hidden tricks

as you said, the double height definition isn't needed, as the outer div will expand to accommodate for the size of the inner div, as it doesn't have absolute positioning or anything

attached patch is #7 without the height definition on the wrapper, only tested on FF3.5.5 on Ubuntu, but I see no reason why IE would quirk (definitely wouldn't mind opera testing though)

re: #8 I'd lean towards c) using the jQuery UI component. jQuery UI is currently under utilized in core. Let's fix that! UI provides many other interface patterns so using its progress bar would play nicely with anything based on it. Finally, I think we'd all love to see some sort of theme roller support so that themes could easily skin common interface components (color module tie in for D8?). Even if it is a bit less sexy that what Kika has designed (which I LOVE BTW), the trade off is worth it.

Using the jQuery UI component is a larger refactor, and IMO has much higher chances of not making it in time. It also does not involve the same skills and would most probably not be driven by the same persons.
So I'd much rather see us get the current 'minimal approach' patch polished and committed, rather than chase jQuery progressbar and having D7 ship with the current bar.
This doesn't prevent interested people to start working on a jQUI approach and defend it for D7.

@yched Completely agree that changing to what Kika has designed would be better than what we have now. A nice, incremental change shouldn't be put on hold due to the possibility of more sweeping changes.

So 4 comments further, lets continue with seutje his patch? I just tested it I think the color needs a tad bit more blu (perhaps yoroy could comment on that standard)

I love the new look.

--- modules/system/system.css
+++ modules/system/system.css

system.css! This the default progress bar for all themes. Which is good, specially for Stark. So we should keep the same progress bar colors as in the patch since this is system and not in a theme.

However, we need to override the progress bar color in Garland and use a Garland blue, and override the color in Seven using a Seven color. As said before, Stark would simply use the color provided from system.css.

I'm on crack. Are you, too?

As per my comment.

+++ modules/system/system.css
@@ -440,15 +440,16 @@ html.js .no-js {
+  border-radius:3px;
+  -moz-border-radius:3px;
+  -webkit-border-radius:3px;

Missing spaces.

This review is powered by Dreditor.

fixing those missing spaces

heh oops, old habits die hard I guess :x

Subscribe.

Going to mark this RTBC, due to schedules it will be hard to really fine-tune the colors - so I think its best to get this in sooner. To change the ascetic model.

Can someone report back results with IE?

Tagging this beauty!

Using the patch from #18 and progress.gif from #5, attached are screenshots of the progress bar under Seven for FF 3.5, IE7 and IE8. Also under Garland for IE8. All running on Win XP.

The bar appears to be fine under IE (excluding the unsupported border-radius)

Cool, RTBC then.

Committed to CVS HEAD. Thanks.

Um....something didn't get committed right. When we run SimpleTests, we get no a nice gray non-cool-looking progress bar. It only looks great when it's at 100%. sun has confirmed this as well with latest HEAD.

Or maybe this is how it was intended to work, but it looks really, really strange when running tests.

Works fine for me...

Do you still see the same if you run a large number of tests?

Check if misc/progress.gif as been updated (and clear your browser's cache)

Ha, just as I was going to upload my version :)

http://skitch.com/yoroy/npi2p/untitled is the comparison

http://skitch.com/yoroy/np46c/progressbar is the screenshot using it in Seven theme.

edit: ugh, wrong gif attached.

Because tests run so slowly, it takes a long time to actually get past the first step and have a non 0% progress bar. Maybe I'm just used to seeing something moving when it was at 0% before this patch, but now it's just empty and gray and I get paranoid that something got stalled. If you have a fast-moving batch operation, it's no problem (like installing).

yes, the actual issue is that you can have a batch with just a single item to be processed in it.

Example: Run a single test (not a group) in HEAD.

You will see a grey bar. Nothing else. Not even a textual indicator that something is actually planned to be done. The average user, who doesn't know anything, will think that something got broke (like in an OS freeze, JavaScript error halting everything), and will likely try to refresh the page to see whether it works in a second pass.

To clarify what I see:

I see now.

What about a spinner (or something similar) to display while the progress bar is at 0% (didn't we use to have a spinner attached to the progress bar sometime ago?)

Maybe show a teeny bit of the blue 'completed' progress when its at 0%?

Processing test 1 of 1 should trigger a 100% value and not a 0% value.

I would suggest modifying the test module for the 1 of 1 case only.

re #41: Nope, showing a 100% bar means 'done, redirect to the next page'. That's not even batch API, that's how progress.js works.

Got bitten by the dumb gray bar as well, of course. Now we know why so far it was the background that was animated :-(.
I'd probably agree with Dave Reid, show a little bit of the 'completed' progress when % is 0.
Or put back 'some' animation in the background.

+1 to the suggestion in #41

Or we just add a "Prepare tests" operation or something to go before each test run.

A simpletest-specific workaround won't cut it. It's not just simpletest, it's not even just Batch API.
Any progressbar-monitored operation whose first step takes more than a couple seconds to run will face this perceptive bug.

ah, then starting with 100% won't make sense.

why don't we just give it a tiny min-width?

Options:

1. Apply a min-width.

   0%

   Doesn't really work out, because there can be a unlimited amount of operations, so the min-width can be larger than 1/1,346,902.
   0%

   Or it has to be so small that it's not visible at all.

2. Display as 100% (just for reference, this doesn't work, not limited to running tests)

   0%

   I'm glad this is not limited to running tests, because this is insane. Look here »

3. Apply a background image on the bar.

   0%

   i.e. partially go back to D6.

4. Add a visual indication to the mouse pointer. (on the entire page during processing)

   0%

   Hover this to get a clue. Now think of the entire page.

5. Add another visual indication that something is happening.

   0%

   So the progress bar displays progress. This indicates that something happens.

...or multiple of those in combination. Don't ask me. :P

EDIT by Dave Reid: Restored the ordered list since I couldn't tell which one anyone was referring to.

So who needs screenshots? :P Added another option that was suggested earlier.

Realistically, I think either 3 or 5 are the better ways to go. That way the page gives us feedback that something is happening, and the progress bar shows how far through we are. This also seems the better HIG way to go.

My issue with 1 (as mentioned) is that we don't know how many steps there are, and also, if one step takes a long time, we are in the same situation of no progress being shown while that task is running. The only way to get around that would be to try to estimate the time it will take and slowly move the progress bar, however that is notoriously difficult to get right.

My concern with 4 is that it could cause users to think that the page had become unresponsive. That would be the feeling that I would get, especially if I moved the cursor out of the browser window.

Overall, I like option 5 the best with the spinner.

I vote for 3 (animated background).
Same image in background than in the progressbar, but desaturated / greyscale - and possibly less contrasted that in D6, keeping the vivid colors for the progress bar itself. Given the way the HTML/CSS is done, I think the oblique rays would stitch neatly between progress and background.

At 0%, it's animated and doesn't give a 'stalled' feeling (just like in D6)

I confronted one of my end-users with this question, and this is what he replied to me:

No. 1 looks like progress bars in Windows... if you know what I mean. ;)

No. 3 looks like my initial suggestion, which visually also looks most beautiful -- you should take into consideration that there are not only developers using Drupal...

No. 5 works and probably makes most sense for Drupal... primarily, because this indicator [throbber] also appears elsewhere and is therefore known to the user.

My primary choice would be the jQuery UI Progress Bar. Maybe if in the case of 0%, we force it to 1% so you see at least some of the animation? Or overlay the percentage in the middle of the progress bar? By reading this post, you acknowledge that I am in no way a designer, or mean to be a designer.

@Rob Loach: Sure, sure, thing. But they equally don't seem to have solved this particular issue. In that demo, go into Firebug, and apply width: 0% to the filled progress. uh oh? uh oh! :P

EDIT: Your proposal is the same as 1) above... see also the included reasoning above. :)

My comment in #41 was based on the 1 of 1 value of the test, which would account for 100%, or 100/100 or 1/1.

So the number 2 example made by sun in #48 should be labeled 100%, not 0%.

That being said I agree that examples 3 and 5 are the best ones.

SUGGESTION 1
What I would suggest, though, is to use two animated GIF files, the background one for the main progress bar gray background, as in example 3, and the coloured one for the value seen in comment #2, or for that matter, already checked in.

We could apply the same effect on the gray animated background as the coloured one.

SUGGESTION 2
As another suggestion I would keep the gray animated background (example 3) and add a blue rectangle for the value on which we could apply an opacity value.

After running some more tests, and considering above options, I really think that we should go with 5. (additional throbber) for two reasons:

A) It provides a clear separation of visual indicators. The bar indicates the current status of the overall progress. The throbber indicates that something is happening.

B) The throbber can be considered as "key visual" and is exactly used this way in other situations already (autocomplete). Its unique purpose is to denote that something is performed and the user should wait for the results.

Please don't go for 5. Showing a preloader for a progressbar… Showing two things to communicate something will start happening seems silly. Instead of adding stuff, can we take something out instead? What about not showing the grey progressbar state at all during step 1 of a batch.

Agreed with #57 that a load indicator for a load indicator is silly and confusing, but I'm not sure if removing it during step 1 is the solution. I'd actually be in favor of #4 as it's subtle and still gets the point across.

Ah, #4 is actually supposed to change the cursor into a clock? I was thinking there was some unresponsive script going on there. Consider that my -1 for that option :-)

"imagine the whole page" == The clock would be default cursor as long as step 1 takes? That might work.

Taking a step back. Do we ever see the bar at 100% currently?

@sun:
yeh for like a split second
when I was suggesting min-width, I was thinking more like 0.1% instead of 1% or 0.01%, but then again that would get all quirky if there would be more than 1000 items

@yoroy:
I'd say during the entire batch process, I would find it confusing if it was only a busy cursor for the first item and then switch to the normal cursor for the remaining items, like as if it wasn't busy anymore

I'd say go with #1 or #4

#1 coz the problem sun outlined is impossible to avoid anyway. For instance: if the bar has a total width of 400px and there's 800 items, it'll be inaccurate however u do it, as a screen can't render half a pixel, so depending on how the browser handles sub-pixel rendering, u might only see a 1px increase every 2 items

#4 coz it just makes sense to show a busy cursor when things are in fact... busy :P

I am implementing #55 suggestion 1 and will provide a patch in the next the minutes.

This patch is very simple.

It reintroduce the gray progress animated GIF (renamed to progress_undeterminate.gif) and we use it as for the background while the new blue progress.gif is used on top of it to display the progress.

If you apply this patch to test it out, please also add manually the progress_undeterminate.gif file.

I tested it with a 1 of 1 test where is displays the progress bar with the gray animation, and at 100% it's displayed using the blue progress animation.

To do: The progress_undeterminate.gif needs to be redone since it's running a bit faster than the new blue progress.gif file. It should also use the same visual as there are a few differences.

So, what do you think?

I also made two screen captures.

I think #65 is by far the best approach visually.
One worry: I'm not sure that we can technically ensure that the two animated gifs will always be in sync so that the stripes match. Doesn't that depend of img loading lag ?

If that's the case, I think we should go with #55 suggestion 2: one single animated gif in background, actual progress on top if it adding color with transparency.

About the implementation; Maybe you should just use that gray progress gif, use that as the background of the whole progressbar, and use a color + opacity on the completed part.

Bringing the animated part to the foreground was the trick that brought this thing into the modern area. Latest direction takes it back a couple of centuries again. I'm getting the impression we're applying design workarounds to a bug/limitation in the code. I f so, we should improve the code, not mangle the design.

My suggestion was a response to yours in #66 and is about how to implement what @xmacinfo is proposing in #65; ensures that the (two; actually one with my suggestion) animated gifs will always be in sync so that the stripes match.

If I speak lala language, let me know; I'll write a patch to show what I mean.

I agree that #65 is the best so far (and it still looks better than the original). The extra animated throttle in option 5 is ... ugly. :)

re yoroy #68. This is not a bug in the code. The first step of processing before we can report some actual >0 percentage progress can be arbitrarily long. That's by design, I see no workaround.

That's the reason the 'old' design for the progressbar animated the background. My bad for not figuring that out earlier in this thread, I don't think a visual modernisation of the progressbar design can change that fact,

Why can't we do the hardcoded initial 10%? To me that seems a very reasonable trade off.

I was just about to propose that again too. Then have the script ensure that on second and further items, it never goes below that initial 10%. Absolute accuracy is not the goal here anyway, we just want to give feedback that 'stuff is happening'.

@yched in response to #66 and @casey in #69: Actually it's possible two have synchronized GIF files. We just need to use the same speed for each frame animation. Currently both GIF files are not using the same interframe speed values.

I will not have time until the week end to touch the animated GIF and enhance them, though (make their speed match, make their style match).

@yoroy for #73: Never going below 10% is OK. But I would apply this only to the Testing progress bar. Elsewhere it's not necessary.

I'm OK with the 10% too, but I'd prefer not to special-case the testing progress bar. Let's keep this simple.

This would be to simple, no?

What if Batch API just added an 'empty' batch task to the beginning of every non-progressive batch with the message 'Initializing batch system'.

Without mentioning batch, perhaps? Assuming not many people don't actually know what that is.

It's getting a bit off now. Let's do #65, perhaps implement the color-overlay approach, and be done with it.

So spoke with tha_sun for a bit on IRC he suggested :

Situation now :
1 of 4 items processed: 0%, 4 of 4 items processed: 75%

Proposed situation:
1st of 4 items: 25%, processing 4th of 4 items: 100%

This would change some of the logic of the progress bar, I am not necessary against or for it. And also do not have the technical know-how-to really provide more feedback, but only think that any solution we come up with should mean minimum to no visual changes to the progress bar (since it finally looks good).

Perhaps even a text, saying "Initializing process" would suffice.

Apparently, it also seems like no one answered my 100% question above.

The underlying question was: If 100% is always ever displayed for a microsecond just before the browser redirects to the finished page, then this issue could be solved by changing the "processed state" into a "processing state".

In other words:

...

Guys, I warn you, this area is a brain swamp :-)

Technically, 100% means 'redirect to the 'final' page'. That's how progress.js is coded (that's not even batch API), and I don't think changing that now is a good idea.
[edit: slightly inaccurate. Actually, "redirect on 100%" is done in batch.js. But progress.js leaves us no other way to decide redirect or not]
This means we cannot display a 100% progress while we are *processing* the last steps in the background.
So @sun: yes, you do see the bar at 100% for a couple seconds, the time it takes for the server to generate the new page and the browser to receive it.

Batch API processes as many steps it can until execution time exceeds 1 second, and reports progress. So before we receive the 1st feedback (and this can be arbitrarily long, see simpletest), we cannot predict how many 'steps' will be done. If the steps are short, possibly 50 out of 100, or even 100 or 100. If the steps are long, possibly 1 out of 100. There's no prediction of what the next % will be.
So: the progress bar is necessarily 'behind'. It shows an amount of 'what's been fully done' at the time of the last feedback loop.
When we're processing the 1st item, no item has been fully processed yet, and progress bar is rightly at 0%.
And it can't display 100 until processing is actually finished.

It's up to each module setting up a batch to chose the messages that make sense for the task. But just like the progress %, they have to cope with the fact that they're 'behind'.
Batch API only provides 'sensible defaults'.
- initialisation message (when we 1st display the bar, before having processed anything yet, so 0%) is 'Initializing'
- progress message (when we have actual progress to report) is 'Completed X of Y'.

Simpletest choses to do:
- initialisation message : 'Process*ing* test 1 of Y' (arguably, more accurate than 'Initializing', since by the time the user sees the message, we are done intializing and are actually processing)
- progress message: 'Process*ed* test X of Y'.

Why are we trying to reinvent the wheel here? The jQuery UI progressbar seems to have solved this issue by always showing a 1px bar, as suggested a few times before. Their (rather simple) trick is to limit the min value to 1E-6, which forces the browser to render at least a a tiny bit. To try: open Firebug and enter $('#progressbar').progressbar('value', .0000009).

We have two patchs that offer two different solutions:

#65 (two animated GIFs)
#76 (set the minimum to 1px, as jQuery seems to do)

and the list can go forever...

I am OK with #65 or #76.

I propose that we commit #76.

So if you want to RTBC a patch, please specify which one.

Agreed with #83 and #84, so RTBC on #76.

yes. 2 anim gifs is not a serious option. #76 it is

I can commit #76, but are you sure it's enough of an improvement? Can you spot the progress bar in this screenshot?

I can spot it! And in D7, the blue 1px progress image is animated, which we don't see in this screen shot! :-)

Oookay. Committed to HEAD. But trust me, the animation doesn't come across at all in that tiny little blip of barely-visible blue. Or else y'all have better eyes than I do. ;P

Let's face it, 1px is not nearly enough.

Attached patch does 5px.

Before:

After:

When core in the future will use jQuery progress it will most probably default to use 1px, not 5px.

With the rounded corners we might try 2px instead of 1px, though. But I'd rather try to duplicate standard jQuery usage.

I agree that 5px makes more sense. Committed!

before this 1/5px inaccuracy:
why is this task staled?

now with this 1/5px tweak:
why suddenly it started with "this much" done, and now it is delaying so much to grow "that much" again

@#52

No. 1 looks like progress bars in Windows... if you know what I mean.

I agree, hate to be so wickedly fooled

without background animation (with or without px fix)
why it is getting more and more animated while I'm awaiting for it to get quite (i.e. finish)?
the user should be expecting the throbber/animations to stop to know the page stopped processing, not the other way around

the first time I saw Drupal's progress I thought it was "the modern era" regarding progress bars
the moving background was indicating "how much is(will be) going on", while the quite/still blue "how much was already done" and therefore "not longer on the move"

@#82

yes, you do see the bar at 100% for a couple seconds, the time it takes for the server to generate the new page and the browser to receive it.

narrow bandwidth and/or slow server means.. how much seconds?

+1 for #96

I don't see the point of the horizontal line through the middle - it looks weird.

It's better but we can't edit the looks of the progressbar over and over again.
This is the end?

All of Drupal is being edited over and over again forever - it will never end!

Fits better overall. :-)

Yup, removing the gloss is good, makes it less trendy and a better overall fit for different themes.

where are the designers of the previous version of the progress bar?

#96, #97 that horizontal shadow is not weird, is the effect of a cylindric glass
IMO, much better that recently proposed dirt-blurred-blue at #96

arhak: read the issue and find out.

#103: I'm looking at it, but I don't see a cylindric glass (whatever that is).

because I haven't seen his thoughts about this whole "new era" proposal
and it seems that I'm the only one who perceives it the other way around (#94)

@#105 well, when I said "cylindric glass" I meant any reflecting cylindric or curved (not concave) surface (which is the oldie "glassy shadow" mentioned by kika @#96)
such as:
- a transparent plastic pen
- a metallic screwdriver
- a glass thermometer (those with mercurial in it)
- the rounded borders of this black plastic keyboard I'm typing on
- furniture (even wooden or plastic)
that's the way shining cylindric surfaces reflect: "glassy shadow"

at #94 I disagreed regarding the gray background turning into more and more animated to represent less remaining tasks
at #103 I disagreed the "more polished look", IMO it looks like a dirty/blurred blue

I first thought that probably new proposal (#96) was using "web safe" colors, but it seems it isn't
it seems to be getting more green or just more brightness level in detriment of contrast

just my -2 cents

IMO it looks like a dirty/blurred blue

Yes, it is. And this is what we are actually looking for.

Drupal 7 image elements are using tone down colors and effects and we try to remove any glossy look from the default interface elements.

Looks like an improvement to me. Committed to CVS HEAD. Thanks kika. Can we have the same level of eye for detail to some other areas?

@#109 thanks for make me aware of it

Hey guys, the progress.gif added here doesn't tile properly.

I wasn't sure whether or not to reopen this, so I created a new issue here: #902490: progress.gif doesn't tile properly.