Page MenuHomePhabricator

Article progress indicator
Open, LowPublic

Description

User story

As a KaiOS user, I want to understand my progress through reading an article

Acceptance criteria

  • Article progress indicator (can be based on length of article, or section a reader is in)

Proposed design

Mocks
Article title pageSecond page of articleThird page of article
09 - Article header.png (640×480 px, 245 KB)
10 - Article continued.png (640×480 px, 82 KB)
10c - Article continued - scroll.png (640×480 px, 94 KB)
https://zpl.io/25oJjKJhttps://zpl.io/V05Lko9https://zpl.io/agOQq3Q
Design details
  • The indicator should remain the same size but 'jump' at different amounts down the page based on the length of the article (eg. more incremental jumps for longer articles)
  • The indicator should not appear on the title page or any page that includes any of the title or title description text

Related Objects

Event Timeline

SBisson edited projects, added Inuka-Team (Kanban); removed Inuka-Team.

@cmadeo: Idea - Since we have pagination, could the progress indicator appear at the top of the screen (to imitate progress reading a book) instead of to the right?

@AMuigai hmm, we could but as we're using the up and down hardware keys to indicate moving earlier and later in the article I think the metaphor is still closer to scrolling rather than paging though a book?

The suggestion came from having complete pages showing on the screen on the app at the moment.

@SBisson @hueitan On the end of the first page, can we fade out the first sentence or statement from the next page as shown in the mock here, so that the user understands to scroll down for more?

Related to: T234436

[...] can we fade out the first sentence or statement from the next page as shown in the mock here, so that the user understands to scroll down for more?

Technically it would be hard in most cases and impossible if the next element is anything other than regular text.

In the context of pages, having partial text makes it unclear if you're supposed to read it or not because you don't know if it's going to be repeated on the next page. e-readers don't do that. We can have small arrows indicating there's more but looking at other apps, using the d-pad to read more is pretty universal. The only thing that is unique and maybe not obvious is that we're using one axis (up/down) to paginate and the other axis (left/right) to select the links on the page.

@SBisson hmm, I like the visual affordance that the blurred text provides (ideally the blurred line would be the top line on the next page) but if this is too complex then I'd suggest only having an arrow on the title pages, after that I trust that users will get the hang of using the up / down arrows, although we can always earmark this to be tested in user testing

My personal preference still sits with the up/down metaphor for scrolling through pages. I worry a bit about breaking into a new paradigm and having an unforeseen issue bringing something over from the apps, etc in the future. FWIW I saw a cool prototype for a KaiOS app where the used left/right to page through options (similar to what we do with the carousel) and then up/down for within an element.