Opened 13 years ago
Closed 12 years ago
#3106 closed enhancement (fixed)
Support "indeterminate" progress bar via animated gif rather than javascript animation
Reported by: | owen | Owned by: | simonjb |
---|---|---|---|
Priority: | high | Milestone: | 0.9beta |
Component: | Dijit | Version: | 0.9 |
Keywords: | Cc: | Adam Peller, bill, Becky Gibson | |
Blocked By: | Blocking: |
Description
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.
Attachments (2)
Change History (22)
comment:1 Changed 13 years ago by
Cc: | Adam Peller added |
---|---|
Milestone: | → 0.9 |
Owner: | changed from bill to simonjb |
comment:2 Changed 13 years ago by
Summary: | Add code support for "indeterminate" progress bar → Support "indeterminate" progress bar via animated gif rather than javascript animation |
---|
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?
comment:3 Changed 13 years ago by
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).
comment:4 Changed 13 years ago by
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.
comment:5 Changed 13 years ago by
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!
comment:6 Changed 13 years ago by
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.
comment:7 Changed 13 years ago by
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.
comment:8 Changed 13 years ago by
Owner: | changed from simonjb to Adam Peller |
---|
comment:9 Changed 13 years ago by
Owner: | changed from Adam Peller to simonjb |
---|
comment:10 Changed 13 years ago by
Cc: | bill added |
---|---|
Milestone: | 0.9 → 0.9beta |
comment:11 Changed 13 years ago by
Status: | new → assigned |
---|
Changed 13 years ago by
Attachment: | HighContrastIndeterminateProgressBar.html added |
---|
comment:12 Changed 13 years ago by
Attached mockups of some high-contrast options for the "indeterminate" progress bar. Also available at:
http://sjb.atrc.utoronto.ca/sandbox/HighContrastIndeterminateProgressBar.html
comment:13 Changed 13 years ago by
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
comment:14 Changed 13 years ago by
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.
comment:15 Changed 13 years ago by
Cc: | Becky Gibson added |
---|
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?)
comment:16 Changed 13 years ago by
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.
comment:17 Changed 13 years ago by
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.
comment:18 Changed 13 years ago by
Changed 12 years ago by
Attachment: | IndeterminateProgressBar.diff added |
---|
comment:19 Changed 12 years ago by
Attached patch implementing indeterminate progress bar as an animated gif.
comment:20 Changed 12 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Sounds like a great idea. Simon, let's nuke the animation code in favor of this approach.