Tool KITT

Just because a tool exists that allows you to do something does not mean it is the right thing to do.

Sometimes we realize it was not worth doing in the first place.

Tobacco Smoke Enema Kit

Tobacco Smoke Enema Kit

Sometimes we realize there are better ways to accomplish the same goal.

Olden Shower

Olden Shower

And so it is with widget tool kits as well.

I urge you to avoid using the GtkProgressBar‘s dreadful activity-mode.  You know the one – where the “progress” bar pulses from side to side and back again.

If possible, figure out a way to estimate the duration of an action so you can use the progress bar for what it is designed for.  If you can’t then maybe something like an activity spinner/throbber is more appropriate.  Code that simply calls gtk_progress_bar_pulse very likely needs to get fixed.  We should probably update our Guidelines too.

Unless you have an Anamorphic Equalizer please don’t pulse all over my screen.

(I really wanted to include a Dead Ringers reference but it didn’t quite get the same point across)

This entry was posted in Uncategorized and tagged . Bookmark the permalink.

5 Responses to Tool KITT

  1. Jerome Haltom says:

    As soon as such a spinner widget exists in GTK prime I’ll change my code to use it. Until then, deal with it. =)

  2. Richard says:

    I second the notion of not using a pulsing progress bar. It’s like a progressless bar. I suppose it lets me know that the operation isn’t blocking the GUI or hasn’t frozen the application.

  3. otte says:

    You failed to give a specific reason for why to not use it. A simple “it’s wrong” is not very educational.

    That said, I’ve always thought pulsing was reserved for cases that should have a progress indication, but can’t. Like my browser downloading something that didn’t give a Content-Length. Or is it wrong for that, too?

  4. Hylke says:

    otte: because it’s ugly and distracting :)

  5. mpt says:

    Indeterminate progress bars are “ugly and distracting” only because most GTK themes make them bounce back and forth. That is a silly way to present them, partly because it makes them look hyperactive, and partly because if you glance at one at the wrong moment it looks identical to a determinate progress bar. I suggest reporting a bug against every GTK theme that presents them this way.

    Wherever possible, progress bars should be determinate, even if the proportions allocated to subtasks aren’t exact. Programmers often don’t do this, because they think — incorrectly — that inaccurate progress feedback is worse than none at all. (Giving an estimate of time remaining is a whole different kettle of fish.)

    Progress of a long-running task, where the user is likely to be interested in its completion, should be shown in a dedicated progress window whenever there isn’t another relevant window to show it in. And a dedicated progress window should always include a progress bar, not a spinner, even if the progress is unfixably indeterminate.

    There’s plenty more advice that could be written about progress bars, none of which is in the Human Interface Guidelines yet. (For example, a common error in Gnome software is to use a progress bar as a gauge of something other than progress.)

Comments are closed.