Suboptimal button ordering on Scratch welcome screen?

[Jon Loldrup]

When scratch is started from the application launcher, it initially shows, in the main area, two buttons and a bit of text:

http://youtu.be/ULblsnv48WM?t=3m23s

Among these two buttons, the one that is used the most should be on top, as people will evaluate/read the buttons starting from the top. If the buttons are so arranged, people will, on average, spend the least amount of time before finding what they are looking for. Even more crucial, impatient users will have less chance of losing patience (giving up) before they find the button they are looking for. This unfortunate scenario is what happens right here (she actually wants to edit a new file, but manages to get confused by the first button (which I won't fault you guys for) and thus gives up reading the button right below):

http://youtu.be/ULblsnv48WM?t=3m32s

If you do not have usage statistics that can reveal the frequency of usage (that is, whether people most often launch Scratch to subsequently open an existing file, or most often launch Scratch to edit a new file), I offer the following reasoning:

If one wants to open an existing text file, one often finds the file through the 'Files' application, then double clicks it.
If one wants to create a new text file, one will most often do it by opening Scratch, then editing and subsequently saving it.

These "observations" indicates that the 'New File' button will be used more than 'Open File'. Thus the 'New File' button should be positioned above 'Open File'. Currently it is the opposite.

[Danielle Foré (danrabbit)]

OP, it's good that you're thinking about these sorts of things, but typically we put our "call to action" or "Primary" button at the end of a dialog. So if you're suggesting that creating a new file is the primary action, things are already in order ;)

See this article for more info: http://uxmovement.com/buttons/why-ok-buttons-in-dialog-boxes-work-best-on-the-right/

But there is a bit of a problem here! Our description text says "Open a file to begin editing", then puts "New file" in the call to action spot. So if "Open" is our call to action, the open button should indeed be at the bottom.

In other words, I agree with reversing the order of the buttons, but for the opposite reason that you think they should be reversed :p

[Kurt Smolderen (kurt.smolderen)]

Although the icons have switched place now, the actions did not :-). So clicking the "New file" icon will now display an 'open file dialog box' and the 'Open file' action will actually create a new file...

[Chris Johns (ter0)]

Whoops! Fixed that in the new branch.

[Jon Loldrup (loldrup)]

Seriously, Daniel.

That article is mind boggling naive.

As an example, they say that "you cannot ignore the fact that users will
look at all their options before they choose which action to take".
..Where's the empirical documentation for..??

That statement is flat out contradictory to everything I've learned about
users through actual observation of users. Most users I've seen just
stumble through their interaction, as if they would be doomed to eternal
suffering if they were so unfortunate as to happen to do some actual slow
thinking. And lo and behold - the video I linked to in the original bug
report reveals exactly this pattern of sloppy behaviour.

If that article is representative for the level in non empirical ux design
analysis, all non empirical ux design analysis should immediately be
halted. It would do far more bad than good.

Jon
On Jan 30, 2013 8:01 PM, "Daniel Fore" <email address hidden> wrote:

> OP, it's good that you're thinking about these sorts of things, but
> typically we put our "call to action" or "Primary" button at the end of
> a dialog. So if you're suggesting that creating a new file is the
> primary action, things are already in order ;)
>
> See this article for more info: http://uxmovement.com/buttons/why-ok-
> buttons-in-dialog-boxes-work-best-on-the-right/
>
> But there is a bit of a problem here! Our description text says "Open a
> file to begin editing", then puts "New file" in the call to action spot.
> So if "Open" is our call to action, the open button should indeed be at
> the bottom.
>
> In other words, I agree with reversing the order of the buttons, but for
> the opposite reason that you think they should be reversed :p
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1097690
>
> Title:
> Suboptimal button ordering on Scratch welcome screen?
>
> Status in Scratch:
> Confirmed
>
> Bug description:
> When scratch is started from the application launcher, it initially
> shows, in the main area, two buttons and a bit of text:
>
> http://youtu.be/ULblsnv48WM?t=3m23s
>
> Among these two buttons, the one that is used the most should be on
> top, as people will evaluate/read the buttons starting from the top.
> If the buttons are so arranged, people will, on average, spend the
> least amount of time before finding what they are looking for. Even
> more crucial, impatient users will have less chance of losing patience
> (giving up) before they find the button they are looking for. This
> unfortunate scenario is what happens right here (she actually wants to
> edit a new file, but manages to get confused by the first button
> (which I won't fault you guys for) and thus gives up reading the
> button right below):
>
> http://youtu.be/ULblsnv48WM?t=3m32s
>
> If you do not have usage statistics that can reveal the frequency of
> usage (that is, whether people most often launch Scratch to
> subsequently open an existing file, or most often launch Scratch to
> edit a new file), I offer the following reasoning:
>
> If one wants to open an existing text file, one often finds the file
> throug...

[Jon Loldrup (loldrup)]

I suggest that you take a careful look at the original video once again.
And then once more. That video is far more worth to elementary OS than non
empirical speculation.
On Jan 30, 2013 8:01 PM, "Daniel Fore" <email address hidden> wrote:

> OP, it's good that you're thinking about these sorts of things, but
> typically we put our "call to action" or "Primary" button at the end of
> a dialog. So if you're suggesting that creating a new file is the
> primary action, things are already in order ;)
>
> See this article for more info: http://uxmovement.com/buttons/why-ok-
> buttons-in-dialog-boxes-work-best-on-the-right/
>
> But there is a bit of a problem here! Our description text says "Open a
> file to begin editing", then puts "New file" in the call to action spot.
> So if "Open" is our call to action, the open button should indeed be at
> the bottom.
>
> In other words, I agree with reversing the order of the buttons, but for
> the opposite reason that you think they should be reversed :p
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1097690
>
> Title:
> Suboptimal button ordering on Scratch welcome screen?
>
> Status in Scratch:
> Confirmed
>
> Bug description:
> When scratch is started from the application launcher, it initially
> shows, in the main area, two buttons and a bit of text:
>
> http://youtu.be/ULblsnv48WM?t=3m23s
>
> Among these two buttons, the one that is used the most should be on
> top, as people will evaluate/read the buttons starting from the top.
> If the buttons are so arranged, people will, on average, spend the
> least amount of time before finding what they are looking for. Even
> more crucial, impatient users will have less chance of losing patience
> (giving up) before they find the button they are looking for. This
> unfortunate scenario is what happens right here (she actually wants to
> edit a new file, but manages to get confused by the first button
> (which I won't fault you guys for) and thus gives up reading the
> button right below):
>
> http://youtu.be/ULblsnv48WM?t=3m32s
>
> If you do not have usage statistics that can reveal the frequency of
> usage (that is, whether people most often launch Scratch to
> subsequently open an existing file, or most often launch Scratch to
> edit a new file), I offer the following reasoning:
>
> If one wants to open an existing text file, one often finds the file
> through the 'Files' application, then double clicks it.
> If one wants to create a new text file, one will most often do it by
> opening Scratch, then editing and subsequently saving it.
>
> These "observations" indicates that the 'New File' button will be used
> more than 'Open File'. Thus the 'New File' button should be positioned
> above 'Open File'. Currently it is the opposite.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/scratch/+bug/1097690/+subscriptions
>