UI prototype to show hidden state #669
Conversation
|
I like this. Here's another thought: what if we also actually made a "mark" on the left side for any cell that is selected, if there are other selected cells? So that it "looks" like it's marked as well? It wouldn't actually be marked -- e.g. if you moved the selection up or down, it would move the mark (unless the cell were legitimately marked). But the benefit of doing this would be to allow us to operate on the union of marked + selected cells, and it wouldn't be surprising to users because the selected cell looks like it's marked. |
|
Related to the discussion in #667
I like this idea a lot +10 |
|
Actually, now that I think of it even more, why not just always have the selected cell look like it's marked, even if there aren't other marked cells? Then it's less surprising to see additional marked cells when you do things like multi-cell select, and it's more consistent (when you delete a cell, you always delete all marked cells, which might mean multiple cells or just the currently selected cell). |
+1 , you're on a roll, I like these ideas! |
|
Thanks! 😄 |
|
Question, what styling would we use? The left border alone? Or the full gray border? I should say, if we do the full gray border, it looks ugly with multiple consecutive cells marked. |
|
I also like these ideas. But if we visually style the selected cell like a On Tue, Oct 27, 2015 at 1:35 PM, Jonathan Frederic <notifications@github.com
Brian E. Granger |
|
I think the idea is that no actions would only work on selected |
|
I think the left border alone is fine. I like Matthias' gif and basically am thinking that the selector would still have the gray border but additionally the left blue border. |
|
Are there currently any actions that only work on selected cells and not marked cells? |
Run cell. I'll update the CSS to have the cursor look like marked cell. |
|
Ah, hmm. I could see it being useful though to say "run this set of cells that I have marked" rather than just run the current cell, so maybe that's not a problem to have run cell run all the marked cells... |
|
|
|
I introduced a small difference between |
|
Nice! I hadn't thought about the difference between selected and selected+marked, but yeah, I think that's important. I wonder if the way you have it might be too subtle, though. What about having:
|
|
I like a small difference when selection is the only marked cell, as it give you a quick indication wether there migt be off screen marked cell. I'll finish my version, and play with your 1) and 2) |
|
I would like to see 2 especially Edit: Actually both 2 and 1 |
|
you can check latest commit to try #2 |
|
A gentle suggestion for accessibility would be to make sure the indicator does not solely rely on color. I like 2. |
|
I've pushed proto1 and proto4 proto4 rely on border width:
|
I do think we are going to need an additional indicator besides width, though, as I still think it's too subtle. I'm not sure what would be best, though. Maybe a combination of color and width (would that also address the stuff you're thinking of, @willingc ?) -- what about
or something along those lines? |
|
Here's an example of what I mean, using light blue rather than gray: |
|
The more I play around with the version that doesn't have borders, the more I like it. I think this will have the added benefit of making it much, much clearer when you're in command mode vs edit mode. So +100 from me for something along the lines of proto4! |
|
I've never liked the gray border, so I second @jhamrick 's +1(00) |
|
Another +1 for proto4. @jhamrick Yes, color plus width works for me. |
|
I like the no border too, Though there is also the "edit-mode" green, which has boder. So while I'm +1 to removing border for 5.0 I'm -1 to remove it for 4.1 |
|
I'm a fan of the different color from the selection and the marked cells. One thing I just talked about with @Carreau was that the real problem that is still not adequately addressed is knowing which of the two (selected vs. marked cells) is going to have actions applied to it. One possibility is to flip the problem on its head and rather than thinking of the mark as a state, selected as a state and marked & selected as a state, is to recognize that marks+selected structure is a set of binary variables applied to the complete set of cells. If you instead think of the selected as an implicit mark (which @Carreau said was already part of the discussion) you can treat the entire problem differently and address the "when you do something, what are the things that something is done to" problem by putting a priority queue on the sets of binary variables. The set at the top of the queue is given its own special UI indicator (I was suggesting something that contrasts with the actual selection colors like red, though I know that might have other bad connotations), and it is that set of cells to which the function will be applied. The idea let's you choose to step through the queue by using some kind of toggle/step-through key (based on gmail's mechanism for stepping through different inboxes I suggested sidenote: I'm assuming that actions like merging are just going to be disabled for noncontiguous blocks of cells? Otherwise the semantics of what it is to merge get wonky… |
|
I'm not sure I understand the idea of having a priority queue. The way that I've been thinking about it is:
So, essentially, it should be possible to determine from a screenshot (without knowing the history of actions) which of the following categories each cell falls under:
|
|
Also, it may be helpful here to note the similarity to how selection in emacs works. I will make this quick because I have to run to class in a minute...
|
Sorry @Carreau , here I disagree with you and I say away with it for 4.1! :) (not the edit mode one) |
|
Having the width of the side denote the different states is confusing to me. What if the |
|
@jhamrick, I think we're talking past each other, because that division works for distinguishing between editing and command modes. But before what was discussed was the notion of selection being an implicit mark that is differentiated from the notion of what I think you're calling a sticky mark. I thought that focused was the term for when you are in edit mode in a particular cell. In the previous release there was the notion of selecting multiple cells, and so something could be selected and not focused (because you can select multiple cells, but you cannot be focused on multiple cells for the purposes of editing those multiple cells, unless — in the emacs analogy — it's allowing multiple cursors). So there are actually 8 states: Focused/in edit mode (with "sticky" mark) What I was taking as given was that operations could only be applied while in command mode (I think this is implicit in all the discussion, and I have no quibble with that). But when in command mode, one could have a selection on many contiguous cells and one could have marks on any subset of the cells. What I was suggesting is the ability to (at least) be able to toggle between the selected cells as the target of actions and the marked cells as the target of actions without losing either the marks or the selection when that toggle occurs(I.e., you can toggle back and forth). The UI indicator for the currently active target set is an open question (and I am open minded as to what that should look like). Basically, what's inevitably going to happen in the examples @jhamrick gives in an issue elsewhere(#665 (comment)) will be cases someone applies an operation to the wrong target set, and it should be possible to undo that operation, to and to immediately return the set of focuses to the place they were before, easily toggle to the correct target set and then apply the operation again. If you don't have some way of encoding that information so as to make it easy to undo to the state where both the marks and selections are preserved, switch targets, and redo; people(read: this includes at least me) will be less likely to use marks as opposed to the contiguous selection mechanism because then I'll at least know where all of the changes were made when misfires occur and apply to the wrong target set (which currently is being implicitly decided by…I'm not sure what?). |
|
I give up on UI. Prototypes are here feel free to take inspiration. I shouldn't have gotten into this discussion and I should have left the selected/marked things in the state it was. |
That's a cool idea, like a nod to the design of the common cursor. Just thinking out loud, it may get noisy seeing both the cell side-bar blink and the cursor in the editor. |
|
Don't despair @Carreau!, thanks for the prototypes. |
+1 , I think we are getting close! |
|
Maybe only blink in command mode? |
|
Yeah I think that would work |
|
-1 on any blinking ;-) except of eyes On Tue, Oct 27, 2015 at 6:03 PM, Jonathan Frederic <notifications@github.com
Brian E. Granger |
|
FYI on blinking and accessibility: https://pages.18f.gov/accessibility/flashing/ |
a prototype to have less hidden state when using marked cell.
Change the color of the selection when cell are marked:
ping @ellisonbg @jdfreder @jhamrick