[Pharo-project] about cursor: an interesting blog post
I am completely agree with this post. A showWhile: pattern takes its roots from modal processing, when user is blocked and have to wait till something will give control back to him. This is inacceptable and should be exterminated. It was excusable for 80's , partly excusable in 90's .. and completely inexcusable past 0's. A progress bar is another abomination of same kind. Look at download bars in your internet browser: do they center it in a window on top of everything and preventing you from doing anything? or maybe they just sit in the corner and not interfere? This is a road where we should put our steps on. We should remember once and for eternity: staying responsible to user input is most important task for a system. The rest doesn't matters. On 31 May 2012 21:22, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&p...
-- Best regards, Igor Stasenko.
On 1 June 2012 00:43, Igor Stasenko <siguctua@gmail.com> wrote:
I am completely agree with this post. A showWhile: pattern takes its roots from modal processing, when user is blocked and have to wait till something will give control back to him. This is inacceptable and should be exterminated. It was excusable for 80's , partly excusable in 90's .. and completely inexcusable past 0's.
A progress bar is another abomination of same kind. Look at download bars in your internet browser: do they center it in a window on top of everything and preventing you from doing anything? or maybe they just sit in the corner and not interfere? This is a road where we should put our steps on.
"No modes" is something towards which we should strive. However, don't forget that downloading a file in a web browser is completely different to loading a package into an image: the former changes no state, and the latter can do arbitrary things to the image itself. We need _some_ kind of notification, and in fact Chrome _does_ have a progress bar... but it's a little pie-slice thing down on the bottom of the screen. I can see it, but it doesn't stop me carrying on working. So I'd say it's not so much that progress bars are an abomination, but rather progress bars that stop you from working (like Monticello's bars (but remember the "you're changing your own brain" warning previously mentioned)) that are the abomination. frank
We should remember once and for eternity: staying responsible to user input is most important task for a system. The rest doesn't matters.
On 31 May 2012 21:22, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&p...
-- Best regards, Igor Stasenko.
On 1 June 2012 10:48, Frank Shearar <frank.shearar@gmail.com> wrote:
On 1 June 2012 00:43, Igor Stasenko <siguctua@gmail.com> wrote:
I am completely agree with this post. A showWhile: pattern takes its roots from modal processing, when user is blocked and have to wait till something will give control back to him. This is inacceptable and should be exterminated. It was excusable for 80's , partly excusable in 90's .. and completely inexcusable past 0's.
A progress bar is another abomination of same kind. Look at download bars in your internet browser: do they center it in a window on top of everything and preventing you from doing anything? or maybe they just sit in the corner and not interfere? This is a road where we should put our steps on.
"No modes" is something towards which we should strive. However, don't forget that downloading a file in a web browser is completely different to loading a package into an image: the former changes no state, and the latter can do arbitrary things to the image itself.
We need _some_ kind of notification, and in fact Chrome _does_ have a progress bar... but it's a little pie-slice thing down on the bottom of the screen. I can see it, but it doesn't stop me carrying on working. So I'd say it's not so much that progress bars are an abomination, but rather progress bars that stop you from working (like Monticello's bars (but remember the "you're changing your own brain" warning previously mentioned)) that are the abomination.
in smalltalk code & data is the same - it just objects. why you think "changing your brain" should stop you from doing something else? When you coding in browser, you alsos changing systems brain.
frank
We should remember once and for eternity: staying responsible to user input is most important task for a system. The rest doesn't matters.
On 31 May 2012 21:22, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&p...
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On 1 June 2012 12:25, Igor Stasenko <siguctua@gmail.com> wrote:
On 1 June 2012 10:48, Frank Shearar <frank.shearar@gmail.com> wrote:
On 1 June 2012 00:43, Igor Stasenko <siguctua@gmail.com> wrote:
I am completely agree with this post. A showWhile: pattern takes its roots from modal processing, when user is blocked and have to wait till something will give control back to him. This is inacceptable and should be exterminated. It was excusable for 80's , partly excusable in 90's .. and completely inexcusable past 0's.
A progress bar is another abomination of same kind. Look at download bars in your internet browser: do they center it in a window on top of everything and preventing you from doing anything? or maybe they just sit in the corner and not interfere? This is a road where we should put our steps on.
"No modes" is something towards which we should strive. However, don't forget that downloading a file in a web browser is completely different to loading a package into an image: the former changes no state, and the latter can do arbitrary things to the image itself.
We need _some_ kind of notification, and in fact Chrome _does_ have a progress bar... but it's a little pie-slice thing down on the bottom of the screen. I can see it, but it doesn't stop me carrying on working. So I'd say it's not so much that progress bars are an abomination, but rather progress bars that stop you from working (like Monticello's bars (but remember the "you're changing your own brain" warning previously mentioned)) that are the abomination.
in smalltalk code & data is the same - it just objects. why you think "changing your brain" should stop you from doing something else? When you coding in browser, you alsos changing systems brain.
Yes, there is no difference between loading a package and entering the same code through the browser... except that in the former case (without the abominatory modal progress dialogs stopping your) you might ALSO be adding code, or be running something, or or or. So you start loading some package. That package sadly has a bug in its replacement of Object >> #printString which accidentally kills the image. You're busy debugging something while that package loads. You're inspecting something. You inspect it again... and your image dies! You know you weren't doing anything crazy, so this time it's not your fault. But was it a VM bug? Some weird edge case in the base image noone's run into before? Monticello? The package being loaded? While that package is loading - while you are busy hacking away - the image is changing under your feet. That is _never_ safe. Now, in happy land, we'd have sandboxes and isolation and atomic loading and all sorts of fun stuff so, in happy land, this wouldn't be a problem. But _today_ it would be a problem. frank
frank
We should remember once and for eternity: staying responsible to user input is most important task for a system. The rest doesn't matters.
On 31 May 2012 21:22, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&p...
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
usly mentioned)) that are the abomination.
in smalltalk code & data is the same - it just objects. why you think "changing your brain" should stop you from doing something else? When you coding in browser, you alsos changing systems brain.
Yes, there is no difference between loading a package and entering the same code through the browser... except that in the former case (without the abominatory modal progress dialogs stopping your) you might ALSO be adding code, or be running something, or or or.
So you start loading some package. That package sadly has a bug in its replacement of Object >> #printString which accidentally kills the image. You're busy debugging something while that package loads. You're inspecting something. You inspect it again... and your image dies! You know you weren't doing anything crazy, so this time it's not your fault. But was it a VM bug? Some weird edge case in the base image noone's run into before? Monticello? The package being loaded?
that can even happen without monticello being blocking...
While that package is loading - while you are busy hacking away - the image is changing under your feet. That is _never_ safe. Now, in happy land, we'd have sandboxes and isolation and atomic loading and all sorts of fun stuff so, in happy land, this wouldn't be a problem. But _today_ it would be a problem.
sure it could be, but let's say we make a setting. Cause most of the time I know exactly what I load in Monticello and still wan to be able to work on something else. It's like having a #become: around, nobody stops you from doing silly things with it :). - Most of the UI stuff should be written non-blocking, adding blocking support on top is mostly easy. (in MC the only thing that makes sense to be run in blocking mode is indeed loading, but even that necessarily) - add Options/Settings (maybe with some warnings) so everybody is happy
On 1 June 2012 13:38, Camillo Bruni <camillobruni@gmail.com> wrote:
usly mentioned)) that are the abomination.
in smalltalk code & data is the same - it just objects. why you think "changing your brain" should stop you from doing something else? When you coding in browser, you alsos changing systems brain.
Yes, there is no difference between loading a package and entering the same code through the browser... except that in the former case (without the abominatory modal progress dialogs stopping your) you might ALSO be adding code, or be running something, or or or.
So you start loading some package. That package sadly has a bug in its replacement of Object >> #printString which accidentally kills the image. You're busy debugging something while that package loads. You're inspecting something. You inspect it again... and your image dies! You know you weren't doing anything crazy, so this time it's not your fault. But was it a VM bug? Some weird edge case in the base image noone's run into before? Monticello? The package being loaded?
that can even happen without monticello being blocking...
While that package is loading - while you are busy hacking away - the image is changing under your feet. That is _never_ safe. Now, in happy land, we'd have sandboxes and isolation and atomic loading and all sorts of fun stuff so, in happy land, this wouldn't be a problem. But _today_ it would be a problem.
sure it could be, but let's say we make a setting. Cause most of the time I know exactly what I load in Monticello and still wan to be able to work on something else.
It's like having a #become: around, nobody stops you from doing silly things with it :).
At least with #become: you have to actually type out the letters: you KNOW you're doing something dangerous.
- Most of the UI stuff should be written non-blocking, adding blocking support  on top is mostly easy. (in MC the only thing that makes sense to be run  in blocking mode is indeed loading, but even that necessarily)
I should perhaps restate that I _agree_ with Igor that I don't think the UI should ever block (except maybe at shutdown, but the user doesn't care at that point anyway). I just wanted to highlight that changing the system while a large amount of changing the system is already happening is asking for trouble.
- add Options/Settings (maybe with some warnings) so everybody is happy
Well, too many settings = nobody happy, because noone's system works the same as anyone else's! frank
+1 We will have to look at that now let us finish what we started.
I am completely agree with this post. A showWhile: pattern takes its roots from modal processing, when user is blocked and have to wait till something will give control back to him. This is inacceptable and should be exterminated. It was excusable for 80's , partly excusable in 90's .. and completely inexcusable past 0's.
A progress bar is another abomination of same kind. Look at download bars in your internet browser: do they center it in a window on top of everything and preventing you from doing anything? or maybe they just sit in the corner and not interfere? This is a road where we should put our steps on.
We should remember once and for eternity: staying responsible to user input is most important task for a system. The rest doesn't matters.
On 31 May 2012 21:22, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&p...
-- Best regards, Igor Stasenko.
participants (4)
-
Camillo Bruni -
Frank Shearar -
Igor Stasenko -
Stéphane Ducasse