Last selected styling

[SylvainCorlay]

Opening the PR since I had the branch hanging around wrt multi-selection styling after the discussion on gitter with @ellisonbg . The goal to not make the case where a single cell is selected a special case.

This makes it a bit more similar to excel:

And it also simplifies the code.

cc @cameronoelsen @Carreau

[Carreau]

-1, We did how it is now on purpose to avoid ambiguity: Is the following notebook in multiple cell selection state ?

[Carreau]

Note that it is at it is in excel to be able to visualize the head of the selection, Libre office does the opposite with the anchor being white (or vice versa).
We already have a difference of style on the anchor.

(and also I find that ugly but it's irrelevant).

[Carreau]

Note that it is at it is in excel to be able to visualize the head of the selection, Libre office does the opposite with the anchor being white (or vice versa).

Selection have Anchor and head:

• In excel Anchor is White, rest is blue.
• In LibreOffice SpreadSheet Head is White, rest is blue.

(might be inverting Excel and LibreOffice, but whatever)

There is no reason to adopt one more than the other.

[ellisonbg]

I am -1 on this

Sent from my iPhone

On Dec 18, 2015, at 6:26 AM, Matthias Bussonnier notifications@github.com wrote:

Note that it is at it is in excel to be able to visualize the head of the selection, Libre office does the opposite with the anchor being white (or vice versa).

Selection have Anchor and head:

In excel Anchor is White, rest is blue.
In LibreOffice SpreadSheet Head is White, rest is blue.
(might be inverting Excel and LibreOffice, but whatever)

There is no reason to adopt one more than the other.

—
Reply to this email directly or view it on GitHub.

[SylvainCorlay]

• Regarding the argument about ambiguity, IMO there will always be this kind of ambiguity:

  • when you only see the end of a code cell on your screen, is it a very long cell or am I just missing a line?
  • in your implementation of styling, if you only display the last two cells: am I seeing the whole selection or are there 3 or more cells selected.

  In that regard, the one-cell selection is not special and should probably not be treated in a different fashion.

• Why make selections of length one a special case?

  • I would "invoke" the Zen of Python: Special cases aren't special enough to break the rules.
  • Having a visual change between the case of a selection of length one or more gives the wrong impression that there is a modal thing going on, while it is not the case, which is confusing by the user.

• Regarding the fact that the head of the selection is styled differently than the rest of the selection:

  • I picked the example of Excel to show that people are used to seeing one privileged cell in their selection styled differently. Hence I think that it is "OK" to do so. Microsoft must have done endless UX experiments in that regard, and the fact that they adopted it means that it is not confusing.

• Excel handles the styling of the last selected cells when there is an heterogeneous selection (with Crtl+Click) because in that case, there is an ambiguity, in that you don't see if there are other cells selected. (See below and compare to the top screenshot)
  

[Carreau]

The difference is that some action do behave differently in multiple selection.
Merge is one example. So there is a modal difference.

If you take microsoft example, the head is style differently with multiple select (IIUC) when it's blue and have a special corner, while it's white with only 1 cell selected.
So just the visual appearance of the head allow to distinguish.
The Style change you propose does not allow such a difference.

I think it also make it much harder to convey some ideas. In your screenshot of excel the selection has a nice border, which make it obvious "what is selected". While our border is only around that head.

So I think that in your proposal the white background+border make a too huge difference. We can though refine for 5.0, but changing now after many weeks on the old style is too risky.

[Carreau]

(bumping as 5.0 to keep playing with possibilities)

[SylvainCorlay]

Yes, I was not expecting this to get in for 4.1. Btw, the loop on the cells is done with Array.prototype.map which is not very efficient since it creates a new array.

[Carreau]

I'm still -1 on this look.
Should we keep iterating ? @ellisonbg

[ellisonbg]

I like it quite a bit after working with it daily in teaching.

What specific parts (or all) are you not liking?

On Mon, Feb 8, 2016 at 12:46 PM, Matthias Bussonnier <
notifications@github.com> wrote:

I'm still -1 on this look.
Should we keep iterating ? @ellisonbg https://github.com/ellisonbg

—
Reply to this email directly or view it on GitHub
#881 (comment).

Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@calpoly.edu and ellisonbg@gmail.com

[Carreau]

What specific parts (or all) are you not liking?

1. just visually I don't find that great.

2. the blue background convey that actions will apply on the cells. It is more complicated to explain that action apply both on blue cells and the cells with the left border.

3. if the cells are scroll and I see only the cursor cell, I have no way to know wether multiple cells are selected.

4. is less pronounced on the spreadsheet example because of the thick border around the all selection. Thisborder also decrease 3) Without such a strong visual cue that is detectable by the peripheral vision of human this is not a good usable UI.

[ellisonbg]

1. just visually I don't find that great.
2. the blue background convey that actions will apply on the cells. It is
   more complicated to explain that action apply both on blue cells and the
   cells with the left border.

In my teaching this quarter (N=50) that hasn't been a problem so far.

3. if the cells are scroll and I see only the cursor cell, I have no way
   to know wether multiple cells are selected.

Not quite sure I follow. Someone can always scroll the selected cells out
of the way.

2. is less pronounced on the spreadsheet example because of the thick
   border around the all selection. Thisborder also decrease 3) Without such a
   strong visual cue that is detectable by the peripheral vision of human this
   is not a good usable UI.

Which spreadsheet example?

—
Reply to this email directly or view it on GitHub
#881 (comment).

Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@calpoly.edu and ellisonbg@gmail.com

[Carreau]

Which spreadsheet example?

Screenshot at top of this thread.

[Carreau]

Not quite sure I follow. Someone can always scroll the selected cells out
of the way.

Here are 2 screenshot of this PR. Which one have multiple cells selected.
Feel free to "scroll the selected cells out of the way".

Here is master, which one has multiple cells selected :

Telling to user "Just scroll" is not a solution you can be a presenter facing 200 people who are trying to follow what you are doing. Or it can be a screenshot in a book. Needing a user to do any action to know in which state he is a strong hint something is wrong.

I won't bother with a Gif that show that Shift-J and J looks identical when going through a notebook.

So no the current white selected cell style is not acceptable.

[SylvainCorlay]

I don't think that the argument of knowing whether there are other cells selected holds as explained earlier: in your screenshot, you also don't know if the cell is 20 times longer than the screen hight or not, and it is ok.

[Carreau]

I don't think that the argument of knowing whether there are other cells selected holds as explained above: you also don't know if the cell is 20 times longer than the screen hight or not, and it is ok.

No the cell is not changing length when it is out of screen. The selection state can.
We already have a highly confusing UI for beginners, and when giving talks, there is no reason to make the UI more confusing in one specific case.

I just show a case where you cannot distinguish, so I just give one argument against this case.
Show me a case where your UI is better, and then we can discuss wether it's worth.

But right now the curent state only have drawbacks for users.

[SylvainCorlay]

I just show a case where you cannot distinguish, so I just give one argument against this case. Show me a case where your UI is better, and then we can discuss wether it's worth.

Well, I thought we could always discuss :) Although my argument was that making a selection of a single cell a special case gives the impression that something modal is going on.

Btw, even with the current behavior in master, you can come up with cases where you don't know if there are 2 or more cells selected... The one-cell case is not special IMO.

[Carreau]

ok, yes we can always discuss, but here I dont' see any advantages, and only disadvantages. I might be missing something.
But I dont' see the point of making the user experience in (I admit) rare cases for no benefits.

[Carreau]

Thanks @SylvainCorlay for working on that. THe discussion has stopped for a few month, so I'm going to close that to keep the PR queue short. I'll marked it with the "Closed PR" label so that we can easily reopen it/find it if needed.