What i would like to have instead of progress bar

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

What i would like to have instead of progress bar

Igor Stasenko
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.

Reply | Threaded
Open this post in threaded view
|

Re: What i would like to have instead of progress bar

Guillermo Polito
REAAALLY Agree to all.

On Fri, Jun 1, 2012 at 1:58 AM, Igor Stasenko <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|

Re: What i would like to have instead of progress bar

Igor Stasenko
In reply to this post by 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.

Reply | Threaded
Open this post in threaded view
|

Re: What i would like to have instead of progress bar

Fernando olivero-2
In reply to this post by Igor Stasenko
I agree, i've implemented in Gaucho a WaitingShape.

Which resembles the ones found in the web players (the lines in
different angles forming a circle, that rotate an alpha value to
denote passage of time).

w := WaitingShape on: self.
w start.
...
w stop.

I've used it when importing stored sessions.


Fernando

On Fri, Jun 1, 2012 at 2:08 AM, Igor Stasenko <[hidden email]> wrote:

> 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.
>

cbc
Reply | Threaded
Open this post in threaded view
|

Re: What i would like to have instead of progress bar

cbc
In reply to this post by Igor Stasenko
On Thu, May 31, 2012 at 4:58 PM, Igor Stasenko <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: What i would like to have instead of progress bar

Esteban A. Maringolo
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.
Reply | Threaded
Open this post in threaded view
|

Re: What i would like to have instead of progress bar

Ben Coman
In reply to this post by cbc
Chris Cunningham wrote:

> On Thu, May 31, 2012 at 4:58 PM, Igor Stasenko <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: What i would like to have instead of progress bar

Igor Stasenko
In reply to this post by Esteban A. Maringolo
On 1 June 2012 17:58, Esteban A. Maringolo <[hidden email]> 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-tp4632707p4632794.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>



--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: What i would like to have instead of progress bar

Esteban A. Maringolo
Igor Stasenko wrote
On 1 June 2012 17:58, Esteban A. Maringolo <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|

Re: What i would like to have instead of progress bar

Nicolas Cellier
2012/6/1 Esteban A. Maringolo <[hidden email]>:

>
> Igor Stasenko wrote
>>
>> On 1 June 2012 17:58, Esteban A. Maringolo &lt;emaringolo@&gt; 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-tp4632707p4632824.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>

Reply | Threaded
Open this post in threaded view
|

Re: What i would like to have instead of progress bar

Igor Stasenko
On 1 June 2012 21:54, Nicolas Cellier
<[hidden email]> wrote:

> 2012/6/1 Esteban A. Maringolo <[hidden email]>:
>>
>> Igor Stasenko wrote
>>>
>>> On 1 June 2012 17:58, Esteban A. Maringolo &lt;emaringolo@&gt; 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-tp4632707p4632824.html
>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>>
>



--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: What i would like to have instead of progress bar

Esteban A. Maringolo
In reply to this post by Nicolas Cellier
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!




Reply | Threaded
Open this post in threaded view
|

Re: What i would like to have instead of progress bar

Igor Stasenko
On 1 June 2012 22:29, Esteban A. Maringolo <[hidden email]> 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-tp4632707p4632837.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>



--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: What i would like to have instead of progress bar

Stéphane Ducasse
In reply to this post by Igor Stasenko
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.
>


Reply | Threaded
Open this post in threaded view
|

Re: What i would like to have instead of progress bar

Chris Muller-3
In reply to this post by 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 <[hidden email]> 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.
>