Support "indeterminate" progress bar via animated gif rather than javascript animation

[owen]

I've created a graphic and CSS for an "inteterminate" progress bar, as an alternative to the animation that is currently being used. To make it work from a CSS perspective, set the class 'dijitProgressBarIndeterminate' on the domNode of the widget and set its progress to 100% -- you'll see an animated graphic for the full part of the bar.

For coding, I suggest we have a "mode='indeterminate'" or something like that to turn this on. Maybe maximum of 'unknown'?

Not sure how this interacts with the "animation" code that's in progress bar now. Also note that to see the animated graphic, you have to set the 'progress' to maximum.

[Adam Peller]

Sounds like a great idea. Simon, let's nuke the animation code in favor of this approach.

[bill]

Animated gif sounds better than javascript animation except I'm not sure about the size... can the progress bar still be arbitrarily sized? And does it work on IE, FF, and webkit?

[owen]

The current animated gif is designed so that it can get bigger and still look OK. Width is obviously not a problem, and I designed it so it looks OK when taller than the animating part. I'm open to making the animation part taller as well if desired.

Should work fine in all browsers. If you look at the "test_Progressbar.html" file you'll see the bottom item is an example of what it might look like (hacked since there's no programmatic support right now).

[bill]

I wonder... should this be a separate (tiny) widget? It seems like the template would ideally be completely different, and there wouldn't be much javascript in common either.

[Adam Peller]

Perhaps. Or perhaps we could do this via mixin. But I think having a progress bar that can switch modes is also useful -- you might start out with a spinning indicator until you have some context?

Factoring this out later might be the way to go. As it stands, I think ProgressBar? ought to be pretty light after this change!

[simonjb]

For high-contrast mode the animated gif would not be visible if it is specified as a background image. It would be visible as a foreground image but we would probably want to increase its contrast to make it more usable for high-contrast mode users.

[bill]

Hmm, in high contrast mode we could have a message saying "processing..." or "loading..." or something, rather than a percentage. I don't want to add a whole animation just for a11y.

[simonjb]

Attached mockups of some high-contrast options for the "indeterminate" progress bar. Also available at:

​http://sjb.atrc.utoronto.ca/sandbox/HighContrastIndeterminateProgressBar.html

[owen]

Not sure the best of the high-contrast ones to use, but some thoughts:

1) the word "processing" will require localization, which we're trying to avoid 2) the ascii animation, if you use "—" instead of "-" it'll probably look more consistent on the sizing of the pieces

[owen]

Oh, also, we can make a default animated gif that is high contrast pretty easily, if that solution makes sense. This would be part of "dijit" (instead of a specific theme), so it wouldn't have to change for different themes. If that would be helpful, note in the bug and assign to me and I can turn it over pretty quickly.

[simonjb]

We'd have to make a high-contrast animated gif a foreground <img> -- we couldn't use a background image. Is using a foreground <img> a possibility? We couldn't tile, right? (except maybe in JavaScript?)

[Becky Gibson]

I guess my preference would be for the animated ascii or just the three dots if Bill is concerned about the size of the animation code. I like the moving bar but it might be distracting to some people and I'm not sure we would meet this WCAG 2.0 success criterion:

2.2.3 Pausing: Moving, blinking, scrolling, or auto-updating information can be paused by the user unless it is part of an activity where timing or movement is essential. Moving content that is pure decoration can be stopped by the user. (Level AA)

I don't think we want to add the code and UI to pause the moving bar. I should have thought about this earlier.

[owen]

Another possibility for an animated bar would be a simple, say, 20 pixel animation: background white, with a single black dot that moves back and forth. This could be scaled horizontally and vertically and would look something like the moving bar, but would be less code. Still not sure how to stop it. I'm Ok with whatever is decided, just throwing other options out.

[owen]

(In [9099]) refs #3106 Tiny animated GIF that can be stretched for high-contrast mode animation (in an IMG tag). Becky is checking on feasibility of this as a solution. If we decide not to use it, let me know and I'll remove it. If it needs to change, update the bug text and I'll get on it.

[simonjb]

Attached patch implementing indeterminate progress bar as an animated gif.

[bill]

(In [9201]) Fixes #3106: Support "indeterminate" progress bar via animated gif rather than javascript animation Patch by Simon Bates (CLA on file)