1093635 - Show an estimated reading time in the Reading list

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: Reader View, defect)

Description

[Karen Rudnitski [:kar]]

Attachment: Screenshot_2014-11-04-09-53-05.png

See attached screen shot. It was explained to me *after* that this indicated how long it would take me to read the article.

I thought it was either when an article was added or when an article was updated. Regardless of what we want to indicate, this is very confusing.

FWIW, I think having a time stamp for when the article was published is important for RSS feeds (so I know what's the latest it's been updated). I'm not positive what's of real benefit for adding 'time' to a reading list: whether it's the length of time you think it's going to take me to read it (!!), when it was added, when it was published.... 

But in its current implementation, there is no indication that you've guessed how long it's going to take me to read the article so it's even more confusing. Either we let a user display what kind of 'time' they want to see on their list, and/or at least indicate WHAT the time refers to.

Comment 1

[:Margaret Leibovic]

This was part of ibarlow's original design. NI to antlam to decide what to do about this.

Perhaps what we really want is a way to differentiate "short reads" from "long reads"? If we decide to try to do something more complex than what we currently have, we can always just remove this from the UI in the meantime.

Comment 2

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

I think that the decision to show an "estimated reading time" (ERT?) is still helpful. We just have to improve on how we display that information. For instance, maybe "3 min read" as opposed to just "3 min" would be a bit clearer.

After getting some UX feedback, I'd say that we should keep this indicator and try to make it clearer what we're saying. It still seems more helpful than a time stamp to me (I find that information pretty hard to remember) but we could also get some testing on this from Gemma if we'd like.

Comment 3

[Karen Rudnitski [:kar]]

I don't mind the idea of an estimated reading time, but yes - an indicator of what it refers to would be of benefit! 

Timestamps are important when we pull in feeds as a way of letting users know they are, indeed, getting updated content. I don't think it applies as much in a reading list that you've added to yourself (in my opinion!).

Some user feedback on this would definitely be good!

Comment 4

[Mark Finkle (:mfinkle) (use needinfo?)]

/Puts on UX Hat/: What if we added a small icon next to the number? Use a small stopwatch for "reading time" and a small calendar for "feed update" time? Try to add some context to the number.

Comment 5

[:Margaret Leibovic]

I can own figuring this out. Maybe we should consider backing these changes out of aurora so that we can iterate on them in nightly?

See also: bug 1106380.

Comment 6

[Karen Rudnitski [:kar]]

Margaret - I think that sounds like a great idea. I'd rather get it feeling 'right' before it riding up the trains.

Comment 7

[:Margaret Leibovic]

(In reply to Karen Rudnitski [:kar] from comment #6)
> Margaret - I think that sounds like a great idea. I'd rather get it feeling
> 'right' before it riding up the trains.

I looked into backing out the patches wholesale, but it's a bit messy, and we would lose out on the article excerpts, which have not been a contentious part of this feature.

I filed bug 1110461 to just disable the estimated reading time bit, and we can re-enable it when we address these UX issues.

Comment 8

[:Margaret Leibovic]

I disabled this in nightly (and requested uplift for aurora), so there's no pressure to get a fix here quickly, but we should think about this as part of our overall reading list initiative. We should keep in mind that we need to come up with a solution that works for all locales, which likely means this will need to be localizable.

Comment 9

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Leaving a note here that I've also been considering the viability of this feature as it pertains to our desktop counter parts as well.

Comment 10

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Talking to rnewman and Margaret about this a bit more, some notes:

 - Concerns around accuracy of localization and estimated read time in other languages
 - rnewman has an idea for a less "specific" estimate of read time ('Long read' vs. 'short read')
 - need to consider "reading speed" on different devices
 - possibly start with "long", "medium", or "short"?

Comment 11

[:Margaret Leibovic]

Also, before we can do anything here, we need to fix bug 1127451.

Comment 12

[:Margaret Leibovic]

Updating the summary, since we disabled the original feature.