Add right-handed arrow to view title to emphasize the focused view #4024
Conversation
github-actions
bot
added
the
needs label triage
carolinebridge
added
enhancement
| @@ -62,8 +62,8 @@ test('using the hotkey to bookmark the current region', async () => { | |||
|
|
|||
| // @ts-expect-error | |||
| const { bookmarks } = session.widgets.get('GridBookmark') | |||
| expect(bookmarks[0].start).toBe(100) | |||
| expect(bookmarks[0].end).toBe(140) | |||
| expect(bookmarks[0].start).toBe(105) | |||
There was a problem hiding this comment.
is this expected to be changed? could be related to #3996 ?
There was a problem hiding this comment.
we should likely do a full snapshot of the bookmarks object for test
|
stylistically, I am not sure am +1 on the bold font. it just looks a little odd to me |
|
random thoughts on the matter: I know it is hard to try to truly "call attention" to the thing that is "focused" but also, I have questioned: what is the motivation behind trying to call so much attention in the first place? If we compare to other UI systems, the focus can often be pretty subtle. Other systems are not always a very bold about what is in focus. The comparisons are sort of hard to draw though, and our UI challenges are somewhat unique because we have a "stack of views" instead of a floating windowing system like an OS has, or tabs in a browser. I think the vertical stack of views is actually kind of a challenge to convey "focus" properly, and a true windowing system conveys focus much more naturally (e.g. just check whats at the top of the stack). I have even run into a need for floating windows with e.g. the protein view: the screen easily becomes "too tall" to use properly, while my desired behavior would be having a protein view hovering to the right of the screen instead of stacked vertically. If and when we get that type of windowing system, I think there will be more natural analogs to other 'focus' systems common in different other apps and OS's |
|
^ Agree with the challenges for stacks of views. The motivation behind enhancing the focus is that it is hard for some to perceive that there is any focus at all with the difference between the .main and .dark palette options, alone. I think relying on colour alone to distinguish between object features may be naiive...I think in previous UI discussions we've had a lot of success combining colour indicators with coordinating indicators in shape and intensity. Some of the more subtle "out-of-focus" stylings convey "disabled", and a bright border is too harsh, which is why I went for bolding the existing UI. I found it caught the eye without dismissing the other views. Do you think the caret alone is enough to indicate the focus? |
Yes, I think it is probably sufficient to just have caret, and I definitely I approve the caret:) here is a before and after with bold
without bold
|
|
I'll make those changes |
Codecov Report
@@ Coverage Diff @@
## main #4024 +/- ##
==========================================
+ Coverage 63.68% 63.69% +0.01%
==========================================
Files 1026 1026
Lines 30251 30271 +20
Branches 7199 7210 +11
==========================================
+ Hits 19264 19281 +17
- Misses 10822 10825 +3
Partials 165 165
... and 4 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
…in focus if one is open ;; lint and snap updates
cmdcolin
force-pushed
the
emphasize-focus-view
branch
from
2c784dc to
86730a7
Compare
|
@carolinebridge-oicr I went ahead to with merge but I modified it to remove autofocusing view after one is closed, and deferred that into a follow up issue here #4036 There are a lot of tricky issues to solve with the focusing UI, especially with the subviews, and I wanted to try to avoid hardcoding the search for view.views especially as that assumption, if it was not valid, could result in the focusing not working at all (since the search would not find anything, and then apply the next autofocus) |
cmdcolin
changed the title
summary of changes
preview: