[Pharo-project] What i would like to have instead of progress bar
If you would ask me (yeah nobody asking me, by i will tell anyways ;) ) how the indication of a progress of some process should look like, here's my potential answer: - a tiny one line in a corner of desktop (instead of huge banner centered in window, sticking on top of everything and obscuring the view) - not blocking user input - no stupid nesting.. i don't care what happens inside of something else happens.. if it is really necessary, i would just replace the title of a task with it's subtask title while it performing. this is just about first rule: it has to be a single line, not a bunch of lines stocking one over another.. i think this is abuse. most of the times, i just need a notion of progress of a whole thing, not progress of it's subthings (if user really wants, he can hover the mouse over progress line to see the details, but by default it should take minimal space on the screen). -- Best regards, Igor Stasenko.
REAAALLY Agree to all. On Fri, Jun 1, 2012 at 1:58 AM, Igor Stasenko <siguctua@gmail.com> wrote:
If you would ask me (yeah nobody asking me, by i will tell anyways ;) ) how the indication of a progress of some process should look like, here's my potential answer:
- a tiny one line in a corner of desktop (instead of huge banner centered in window, sticking on top of everything and obscuring the view) - not blocking user input - no stupid nesting.. i don't care what happens inside of something else happens.. if it is really necessary, i would just replace the title of a task with it's subtask title while it performing. this is just about first rule: it has to be a single line, not a bunch of lines stocking one over another.. i think this is abuse.
most of the times, i just need a notion of progress of a whole thing, not progress of it's subthings (if user really wants, he can hover the mouse over progress line to see the details, but by default it should take minimal space on the screen).
-- Best regards, Igor Stasenko.
ah, yeah.. one last thing: - do not show the progress, in situations when there is no timely advance is possible, like waiting for server response: just put a notification line.. but no stupid empty progress line which serves no purpose -- Best regards, Igor Stasenko.
On Thu, May 31, 2012 at 4:58 PM, Igor Stasenko <siguctua@gmail.com> wrote:
If you would ask me (yeah nobody asking me, by i will tell anyways ;) ) how the indication of a progress of some process should look like, here's my potential answer: <snip> - no stupid nesting.. i don't care what happens inside of something else happens.. if it is really necessary, i would just replace the title of a task with it's subtask title while it performing. this is just about first rule: it has to be a single line, not a bunch of lines stocking one over another.. i think this is abuse.
most of the times, i just need a notion of progress of a whole thing, not progress of it's subthings
I have cases where I have multiple background processes going on that occassionally wake up, and in that case, I really, really appreciate the stacking progress bars - I can tell that one (or more) background processes have kicked off. This isn't quite 'nesting', although I think it uses some of the same features. As long as some result out of this discussion doesn't remove that capability, I agree with what you are saying. -Chris
Chris Cunningham wrote
I have cases where I have multiple background processes going on that occassionally wake up, and in that case, I really, really appreciate the stacking progress bars - I can tell that one (or more) background processes have kicked off. This isn't quite 'nesting', although I think it uses some of the same features.
As long as some result out of this discussion doesn't remove that capability, I agree with what you are saying.
+1. If the progress tracks something that happens in the background with no direct impact to the workflow (such as uploading/downloading something), I'm ok to have a separate out-of-bounds bar. If the progress is modal, it is... I need to wait until it finishes, I think it should be as it is now. Regards, Esteban. -- View this message in context: http://forum.world.st/What-i-would-like-to-have-instead-of-progress-bar-tp46... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 1 June 2012 17:58, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Chris Cunningham wrote
I have cases where I have multiple background processes going on that occassionally wake up, and in that case, I really, really appreciate the stacking progress bars - I can tell that one (or more) background processes have kicked off. Â This isn't quite 'nesting', although I think it uses some of the same features.
As long as some result out of this discussion doesn't remove that capability, I agree with what you are saying.
+1.
If the progress tracks something that happens in the background with no direct impact to the workflow (such as uploading/downloading something), I'm ok to have a separate out-of-bounds bar.
If the progress is modal,
then someone should stop programming and pick other activity in his life, like organizing the queue during hot sales in supermarket :)
it is... I need to wait until it finishes, I think it should be as it is now.
Regards,
Esteban.
-- View this message in context: http://forum.world.st/What-i-would-like-to-have-instead-of-progress-bar-tp46... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
Igor Stasenko wrote
On 1 June 2012 17:58, Esteban A. Maringolo <emaringolo@> wrote:
If the progress tracks something that happens in the background with no direct impact to the workflow (such as uploading/downloading something), I'm ok to have a separate out-of-bounds bar.
If the progress is modal,
then someone should stop programming and pick other activity in his life, like organizing the queue during hot sales in supermarket :)
Touché. But I was thinking in short, less than 20 sec, modal tasks. Anything beyond that should go async. It would be like... "DON'T MODE ME IN" for more than 20 sec :) Regards. -- View this message in context: http://forum.world.st/What-i-would-like-to-have-instead-of-progress-bar-tp46... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
2012/6/1 Esteban A. Maringolo <emaringolo@gmail.com>:
Igor Stasenko wrote
On 1 June 2012 17:58, Esteban A. Maringolo <emaringolo@> wrote:
If the progress tracks something that happens in the background with no direct impact to the workflow (such as uploading/downloading something), I'm ok to have a separate out-of-bounds bar.
If the progress is modal,
then someone should stop programming and pick other activity in his life, like organizing the queue during hot sales in supermarket :)
Touché.
But I was thinking in short, less than 20 sec, modal tasks. Anything beyond that should go async.
It would be like... "DON'T MODE ME IN" for more than 20 sec :)
Regards.
You should add every hour, because 20 sec every minute would obviously be too much Nicolas
-- View this message in context: http://forum.world.st/What-i-would-like-to-have-instead-of-progress-bar-tp46... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 1 June 2012 21:54, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2012/6/1 Esteban A. Maringolo <emaringolo@gmail.com>:
Igor Stasenko wrote
On 1 June 2012 17:58, Esteban A. Maringolo <emaringolo@> wrote:
If the progress tracks something that happens in the background with no direct impact to the workflow (such as uploading/downloading something), I'm ok to have a separate out-of-bounds bar.
If the progress is modal,
then someone should stop programming and pick other activity in his life, like organizing the queue during hot sales in supermarket :)
Touché.
But I was thinking in short, less than 20 sec, modal tasks. Anything beyond that should go async.
It would be like... "DON'T MODE ME IN" for more than 20 sec :)
Regards.
You should add every hour, because 20 sec every minute would obviously be too much
yeah.. but then it defeats the point: why you need to reflect something which consumes something like 1/1000 of total run time.. by analogy it is like turning mouse into hourglass every time VM's runs GC :)
Nicolas
-- View this message in context: http://forum.world.st/What-i-would-like-to-have-instead-of-progress-bar-tp46... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
You're right. But let's be real, how many progress-bar related actions do you perform on a hourly based? I've been programming daily in smalltalk for the last 7+ years, and most of the times progress bars show up when: - Performing a long/deep search in the image (which I have to wait until it finishes) - Serializing a big object (+20s must be a BIG/heavy object graph) - Deploying (nothing else should be done before it finishes) - Downloading from a repository. And I don't do that more than once per day, if much. All the other progress bars are "app related" (like querying the database, or similar). I can't figure more regular use cases of progress bar usage. Igor have one, Chris has another. I added my two cents. :) The only one that could be sent to be background is when uploading/downloading from a repository, and that's because most of the times it is slow, even in comparison with other package management tools (such as apt-get, npm, etc.), which in turn mode you in while working. Regards! -- View this message in context: http://forum.world.st/What-i-would-like-to-have-instead-of-progress-bar-tp46... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 1 June 2012 22:29, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
You're right. But let's be real, how many progress-bar related actions do you perform on a hourly based?
I've been programming daily in smalltalk for the last 7+ years, and most of the times progress bars show up when: - Performing a long/deep search in the image (which I have to wait until it finishes) - Serializing a big object (+20s must be a BIG/heavy object graph) - Deploying (nothing else should be done before it finishes) - Downloading from a repository.
And I don't do that more than once per day, if much.
All the other progress bars are "app related" (like querying the database, or similar).
I can't figure more regular use cases of progress bar usage. Igor have one, Chris has another. I added my two cents. :)
Yes, i am talking about tasks, which we perform on a regular basis: - read file(s) from web/OS/whatever - compiling & installing new code etc irregular ones (like using a render farm to render special effects for new Holywood blockbuster) is out of scope.
The only one that could be sent to be background is when uploading/downloading from a repository, and that's because most of the times it is slow, even in comparison with other package management tools (such as apt-get, npm, etc.), which in turn mode you in while working.
Regards!
-- View this message in context: http://forum.world.st/What-i-would-like-to-have-instead-of-progress-bar-tp46... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
Chris Cunningham wrote:
On Thu, May 31, 2012 at 4:58 PM, Igor Stasenko <siguctua@gmail.com> wrote:
If you would ask me (yeah nobody asking me, by i will tell anyways ;) ) how the indication of a progress of some process should look like, here's my potential answer:
<snip>
- no stupid nesting.. i don't care what happens inside of something else happens.. if it is really necessary, i would just replace the title of a task with it's subtask title while it performing. this is just about first rule: it has to be a single line, not a bunch of lines stocking one over another.. i think this is abuse.
most of the times, i just need a notion of progress of a whole thing, not progress of it's subthings
I have cases where I have multiple background processes going on that occassionally wake up, and in that case, I really, really appreciate the stacking progress bars - I can tell that one (or more) background processes have kicked off. This isn't quite 'nesting', although I think it uses some of the same features.
As long as some result out of this discussion doesn't remove that capability, I agree with what you are saying.
-Chris
The "number" of simultaneous progress bars could be displayed next to a single one showing in a bottom status/task bar - and a hover of them would expand to show them all.
so if somebody would like to help - we should spot showWhile: useless senders - progress bar useless calls Stef On Jun 1, 2012, at 1:58 AM, Igor Stasenko wrote:
If you would ask me (yeah nobody asking me, by i will tell anyways ;) ) how the indication of a progress of some process should look like, here's my potential answer:
- a tiny one line in a corner of desktop (instead of huge banner centered in window, sticking on top of everything and obscuring the view) - not blocking user input - no stupid nesting.. i don't care what happens inside of something else happens.. if it is really necessary, i would just replace the title of a task with it's subtask title while it performing. this is just about first rule: it has to be a single line, not a bunch of lines stocking one over another.. i think this is abuse.
most of the times, i just need a notion of progress of a whole thing, not progress of it's subthings (if user really wants, he can hover the mouse over progress line to see the details, but by default it should take minimal space on the screen).
-- Best regards, Igor Stasenko.
I know I'm late to the discussion, but I thought I'd share features of my own design of MaClientProcess, which has been part of the Maui framework for Squeak since 2004, how it handles progress. It is based on the ultimate progress-bar handling I did in VisualAge and published in 1997: - The ClientProcess runs in the background, of course. - It's UI can be placed anywhere on the desktop, or minimized. - Shows time elapsed and estimated time remaining. - Shows units processed as a fraction of total units. - Allows descriptions of sub-tasks being worked on to be displayed. - Doesn't appear at all unless the task takes more than 5 seconds to complete, that way the system is not presenting progress bar and then immediately removing it. - Allows the user to PAUSE or change the priority of the Process -- generically without client code knowing anything about that. - No nesting. - UI updates based on a time-interval rather than client processing so that performance is NOT affected. On Thu, May 31, 2012 at 6:58 PM, Igor Stasenko <siguctua@gmail.com> wrote:
If you would ask me (yeah nobody asking me, by i will tell anyways ;) ) how the indication of a progress of some process should look like, here's my potential answer:
- a tiny one line in a corner of desktop (instead of huge banner centered in window, Â sticking on top of everything and obscuring the view) - not blocking user input - no stupid nesting.. i don't care what happens inside of something else happens.. if it is really necessary, i would just replace the title of a task with it's subtask title while it performing. this is just about first rule: it has to be a single line, not a bunch of lines stocking one over another.. i think this is abuse.
most of the times, i just need a notion of progress of a whole thing, not progress of it's subthings (if user really wants, he can hover the mouse over progress line to see the details, but by default it should take minimal space on the screen).
-- Best regards, Igor Stasenko.
participants (8)
-
Ben Coman -
Chris Cunningham -
Chris Muller -
Esteban A. Maringolo -
Guillermo Polito -
Igor Stasenko -
Nicolas Cellier -
Stéphane Ducasse