Skip to content
This repository has been archived by the owner on Feb 22, 2023. It is now read-only.

[Feature] Waveform focus styles #147

Closed
1 task
Tracked by #118
sarayourfriend opened this issue Aug 23, 2021 · 11 comments · Fixed by #188
Closed
1 task
Tracked by #118

[Feature] Waveform focus styles #147

sarayourfriend opened this issue Aug 23, 2021 · 11 comments · Fixed by #188
Assignees
Labels
💻 aspect: code Concerns the software code in the repository ✨ goal: improvement Improvement to an existing user-facing feature 🟩 priority: low Low priority and doesn't need to be rushed

Comments

@sarayourfriend
Copy link
Contributor

Problem

The waveform does not have a clear focus style, meaning that sighted keyboard users will have a difficult time knowing that they are able to seek using the keyboard like other "seek bars" that exist.

Description

We should add a focus style that makes it clear to sighted keyboard users that they can seek using the arrow keys. Screen reader users will get an indiciation from their screen reader that they are in a "slider" which will give the hint that they can use the arrow keys to interact, but for non-screen reader keyboard users this will not apply. Therefore we need some kind of visual indication that the waveform is focused and seekable.

One potential solution is to make the vertical "seek" line a solid color with a circle or bulb at the top. Similar to how iOS represents a video scub in the Photos app, but with a bulb at the top of the line to add an extra indication (especially when the audio is at the 0:00 timestamp something will need to be visible inside of the waveform).

IMG_1064

Alternatives

I'm sure there are other designs we could do for the focus styles, but I'm not sure of any.

Implementation

  • 🙋 I would be interested in implementing this feature.
@sarayourfriend sarayourfriend added 🟩 priority: low Low priority and doesn't need to be rushed 🚦 status: awaiting triage Has not been triaged & therefore, not ready for work ✨ goal: improvement Improvement to an existing user-facing feature 💻 aspect: code Concerns the software code in the repository labels Aug 23, 2021
@zackkrida zackkrida removed the 🚦 status: awaiting triage Has not been triaged & therefore, not ready for work label Aug 23, 2021
@zackkrida zackkrida mentioned this issue Aug 23, 2021
15 tasks
@zackkrida zackkrida self-assigned this Aug 24, 2021
@zackkrida
Copy link
Member

@panchovm This needs some small design thinking applied, please!

@fcoveram
Copy link

Yes. I'm working this week on this

@fcoveram
Copy link

I am trying different styles, but something that comes to my mind is how the interaction works.

Once the focus is on the waveform and arrow keys go forward/backward, does it play the sound immediately? Or does it need a second action (like space bar) to start playing?

On youtube, it is tied to the previous state. If the video is playing, arrow keys go 5 secs forward/backward and the video plays immediately. If the video is paused, it does not play until pressing the space bar. Same on SoundCloud and Spotify.

Last.fm allows playing/pause with the space bar but not moving across time with arrow keys. While Europeana, Jamendo, and Wikimedia Commons do not allow navigation on the audio time.

Youtube

Soundcloud

Spotify web

@sarayourfriend
Copy link
Contributor Author

It works the same as YouTube and Spotify 🙂 Which I think is the most sensible. If you're trying to seek to a specific time before playing the audio, it would be really surprising to me if it suddenly started playing as well. In any case, if seeking using the keyboard we'd have to debounce the auto-playing behavior for some arbitrary amount of time.

@fcoveram
Copy link

Right. That makes sense.

Now I wonder how useful is the 1-sec navigation feature, especially on long audios. I agree with the idea of missing specific seconds, but I guess that seeking time 01:13 but arriving and playing from 01:10 is not annoying.

Youtube iOS has jump periods of 10, 20, 30, and 40 seconds when tapping the video area to go forward and backward. I wonder how that behavior might feel in this case.

@zackkrida
Copy link
Member

@panchovm we have a modifier for shift + -> and shift + <- to jump by 15 seconds. I'll get you instructions for how to run the site locally this week too, i forgot about that!

@fcoveram
Copy link

fcoveram commented Sep 1, 2021

You are right. We decided that and I forgot it. Thanks for bringing it back.

@fcoveram
Copy link

fcoveram commented Sep 1, 2021

Here is the version I like most.

Keyboard navigation

Once the focus is on the wave area, the focus mark is visible and, depending on the audio state (play or pause), it behaves as indicated above. I would like to see how it feels when interacting in real since the mockup is a static depiction.

I tried other styles but did not like them much, yet attached below.

Kayboard navigation  Focus styles

Audio component parts

While designing the component, I faced many unnamed parts that might be a good idea to call them somehow. That is why I made this draft to align us with all concepts used from now. Indeed, this is fully open to changes and enhancements.

Screen Shot 2021-09-01 at 14 49 31

@fcoveram fcoveram self-assigned this Sep 1, 2021
@fcoveram
Copy link

fcoveram commented Sep 2, 2021

Here is the last version of audio component with all states.

@dhruvkb dhruvkb linked a pull request Sep 6, 2021 that will close this issue
7 tasks
@fcoveram
Copy link

fcoveram commented Sep 6, 2021

I added a mockup with focus styles per area. This is to highlight the focus area and being more explicit. In that vein, the focus mark should appear once the focus is in the wave area.

On the other hand, the author link must behave as a default link.

Screen Shot 2021-09-06 at 10 50 23

@sarayourfriend
Copy link
Contributor Author

@panchovm that's great! I was going to comment (but forgot to) on the PR that it was hard to notice that the area was focused at all without an additional outline.

@dhruvkb dhruvkb self-assigned this Sep 7, 2021
@fcoveram fcoveram removed their assignment Jan 11, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
💻 aspect: code Concerns the software code in the repository ✨ goal: improvement Improvement to an existing user-facing feature 🟩 priority: low Low priority and doesn't need to be rushed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants