Visual cue in command palette when the command is run

[jasongrout]

I think there should be a visual cue in the command palette indicating when a command is run from the palette. For example, we could blink the command name once or twice, or blink the highlight around the command.

As it is now, if the command doesn't cause a discernible difference in the UI, it's hard to know if we actually ran the command.

Menu items in OS X work this way - executing on a menu item blinks the blue bar highlight off and then back on.

See also #447 where this was discussed earlier.

[ellisonbg]

+1. Maybe a loud sound as well (LOL, JK) ;-)

[jzf2101]

@cameronoelsen do you think we could leave this as sprint-friendly?

[tgeorgeux]

I think there are three good options to pursue here.

1. A ripple effect like mac uses (if we use this method, we should also update similar interactions, such as the file menu, and the cell type selector in a notebook).
   

2. We could treat it like we treat other buttons. With a hover of Layout Color 2 and switch to layout color 3 on active. (This solution is easiest, has the least impact on existing design.)

3. We could implement the Material Design 'Ripple Effect.' This option is ideal if we decide to add ripple effects to all the buttons (which to this point we have avoided.)

My advice is option 2 for the lowest impact, and highest consistency with our existing design.

[jasongrout]

@lheagy and I tracked this down to phosphor. We think that phosphor itself should probably add an "executing" class to the item being executed in https://github.com/phosphorjs/phosphor/blob/483118db255fea3ba4ec8fb82d4eb4620282def0/packages/widgets/src/commandpalette.ts#L427-L461, and leave it up to the application to provide css that will do, say, a css transition to blink the item or something. At some point phosphor should remove the class too - perhaps phosphor should just say that the class is added for at least 200ms (using setTimeout), and it's up to the app to make sure the transition completes in that time.

[jasongrout]

Probably the same thing should be done for phosphor menus as well.

[ellisonbg]

+1

…

On Tue, Dec 4, 2018 at 12:25 PM Jason Grout ***@***.***> wrote: Probably the same thing should be done for phosphor menus as well. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1095 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABr0AfMz7Oiaj9nGoKo-CpOWrfKWAhHks5u1tokgaJpZM4KXQy0> .

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

[tgeorgeux]

I referenced a solution in #279 I think the solution for now is to blink layout color 3 on activate. In the menu and in the command palette.

[jasongrout]

Setting this to Future, since it likely requires changes to Phosphor.

[saulshanabrook]

@jasongrout @tgeorgeux @ellisonbg I just added a fix for a related issue that makes the active command darker on hover: #6407

Do any of you think this is still 1.0 priority after that fix is in? If so, @jasongrout do you still believe the fix here would be down in phosphor?

[jasongrout]

@tgeorgeux - you set it back to 1.0 in our triage. Do you think this is still a 1.0 issue after #6407?

[tgeorgeux]

I am OK with pushing it back to phosphor if we've fixed the hover issue. I moved to 1.1 as this should be a priority to fix in Phosphor, it will impact the experience enough that it should be prioritized.

[tonyfast]

i'm not sure if this an accessibility issue, it seems more design specific. the audit in #9399 likely covers some of these status considerations for different readers.