[Accepted] SDL 0084 - Progress Bar Seek Feature

[theresalech]

Hello SDL community,

The review of "Progress Bar Seek Feature" begins now and runs through August 22, 2017. The proposal is available here:

https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0084-Progress-Bar-Seek-Feature.md

Reviews are an important part of the SDL evolution process. All reviews should be sent to the associated Github issue at:

#250

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of SDL. When writing your review, here are some questions you might want to answer in your review:

• Is the problem being addressed significant enough to warrant a change to SDL?
• Does this proposal fit well with the feel and direction of SDL?
• If you have used competitors with a similar feature, how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
  Please state explicitly whether you believe that the proposal should be accepted into SDL.

More information about the SDL evolution process is available at

https://github.com/smartdevicelink/sdl_evolution/blob/master/process.md

Thank you,
Theresa Lech

Program Manager - Livio
[email protected]

[stefanek22]

👍

[joeljfischer]

I'm of a bit of two minds on this. The first is that I've definitely been annoyed in the car that I was unable to drag the slider to a later point in a podcast, and had to instead press the skip forward button many times to find the place I want. However, I can also see a case made that adding this increases driver distraction. Carplay I know does not have this feature, I don't know about Android Auto. On audiobooks or podcasts that are several hours long I can also envision a user getting frustrated at trying to get the seek bar to the precise point they want it.

A suggestion might be to have a specific number of points that the bar can skip to. For example, the bar by default allows 10 points along its length and the seek bar can only skip to those 10 points based on where the user lands his finger. This could be customizable to allow the app to define these points, for example, chapters in a podcast or audiobook.

The "infinite" number of point slider seems like a possible distracting element. I'm not going to give a thumbs up or down on this proposal as my reservations seem more like opinion to me than fact, and would be interested if there's any further information about the safety (or if other OEMs are using free seek bars) of this API.

[mrapitis]

@joeljfischer While I do share your concern around distracting elements, I also believe that the responsibility around 'points' falls on the hmi implementation (especially since different oem's and regions may have unique requirements). Overall, in my view sdl core should not be limited from the seek notification perspective allowing more flexibility from oem implementation standpoints.

[joeljfischer]

@mrapitis I definitely understand the HMI should take care of it when possible, but if we wanted to open it up to apps to set those points as chapters for audiobooks or podcasts, we'd have to build an API for it. Maybe that's a later possible addition and not a replacement for this API.

[MichaelCrimando]

@joeljfischer, I like the idea of having "points" along a timeline instead of a smooth progress bar.
Why do you bring up this idea?

From my perspective, we researched a few apps on phone such as Spotify, Audible and Youtube and they all do the smooth progress bar regardless of screen size. So in theory, if an app wanted to setup the progress bar jump points - this would most likely be something that they do exclusively for the in-vehicle experience. Do you think that realistically any apps would do that?

Alternatively, of we wanted the HMI to just have the jump points distributed across the progress bar (like 1 point every 10 minutes or maybe have ~10 jump points per track) - I would see that as just a HMI item without any requirements from the API side. All the HMI would have to do is send back the the new seekTime depending on what the user picked.

[joeljfischer]

@MichaelCrimando I just thought of it as I was trying to think of possible alternatives. I don't think apps like Spotify would need this (and seeking would be disabled for them). I can certainly see an app like Audible (and any audiobook or podcast app) using jump points for chapters if they support chapters. Otherwise, you're right, it would just be an HMI issue.

[MichaelCrimando]

@joeljfischer, FYI Audible has books that range from a handful of minutes to 44+ hours (Stephen King's IT gives you value for your money). They're usually split into chapters of a handful of minutes to 1-2 hours. When you look at a worst case scenario like Stephen King's IT, I don't think the points along a timeline idea solves the problem.

So I think a realistically best way to treat a worst case scenario would be to treat each chapter as it's own track and then just have the regular smooth progress bar. This way, apps wouldn't have to do anything they don't do already and it provides the best possible experience for most use cases

[theresalech]

As any questions about this proposal were answered in the comments on the issue, the Steering Committee fully agreed to accept this proposal.

[theresalech]

Issues Entered:
Core
iOS
Android
RPC
Generic HMI
SDL HMI
JavaScript Suite