857207 - [FHR] FHR raw data needs to state that it is as last submitted

Status: RESOLVED WORKSFORME

(Firefox Health Report Graveyard :: Web: Health Report, defect, P4)

Description

[Annie Elliott]

On Apr 2, 2013, at 11:18 AM, Laura Thomson <[e-mail]> wrote:

On 4/2/13 2:15 PM, Annie Elliott wrote:

Might it be prudent to include a simple sentence on the raw data view that says something to the effect of, "This is your data as last submitted to Mozilla."

Good idea - file a bug.  We won't be able to do it until v2 as we are in string freeze for l10n.

Cheers

Laura

...

Laura Thomson :laura <[e-mail]> changed:

          What    |Removed                     |Added
----------------------------------------------------------------------------
        Depends on|856804, 856815, 856310      |

--- Comment #3 from Laura Thomson :laura <[e-mail]> 2013-04-02 11:13:10 PDT ---
Removing unrelated dependencies

Referenced Bugs:

https://bugzilla.mozilla.org/show_bug.cgi?id=856310
[Bug 856310] [FHR] FHR Total crashes per month not correct
https://bugzilla.mozilla.org/show_bug.cgi?id=856804
[Bug 856804] [FHR] FHR last crash not correct
https://bugzilla.mozilla.org/show_bug.cgi?id=856815
[Bug 856815] [FHR] FHR addons not correct

--

Comment 1

[Larissa Co [:lco]]

OK. UX will take this one :)

Comment 2

[Daniel Einspanjer [:dre] [:deinspanjer]]

Providing initial triage, but I am not the final say.

Comment 3

[Schalk Neethling [:espressive]]

Pull request sent: https://github.com/mozilla/fhr-jelly/pull/64

Comment 4

[Mike Connor [:mconnor]]

before you do that,  it's not as last submitted..

Comment 5

[Annie Elliott]

:mconnor ... what is it showing?

Comment 6

[Mike Connor [:mconnor]]

sorry,  was rushing to catch a car to the airport. 


What we're displaying is as close to current as we can get. we don't necessarily submit exactly that, but it is the equivalent to what we would submit. This means we always have at least some data for users even right after first run.

Comment 7

[Gregory Szorc [:gps]]

Obtaining the document via about:healthreport essentially triggers generation of a new document. However, it does not trigger submission of that document. What about:healthreport gets is essentially what would be submitted if data submission were to occur at the same time.

Comment 8

[Annie Elliott]

Hmmm. I had filed bugs contrary to that behaviour though.

I added bookmarks, and visited tonnes of pages throughout the day, and depite going away from and revisiting (and refreshing) the page, it never updated.

Comment 9

[Annie Elliott]

See comment #1 in 856843

Comment 10

[Schalk Neethling [:espressive]]

(In reply to Mike Connor [:mconnor] from comment #6)
> sorry,  was rushing to catch a car to the airport. 
> 
> 
> What we're displaying is as close to current as we can get. we don't
> necessarily submit exactly that, but it is the equivalent to what we would
> submit. This means we always have at least some data for users even right
> after first run.

but it is not live data right?

Comment 11

[Schalk Neethling [:espressive]]

Is this not as close as we can get to be accurate without causing confusion between the stats in the landing view and the raw view?

'NOTE: The raw data displayed is based on the last data you agreed to share with Mozilla and is not live data. This is also the data used to provide you with that statistics on the landing page. '

Comment 12

[Annie Elliott]

that's a "Wroks for Me."

Comment 13

[Gregory Szorc [:gps]]

Data collection doesn't always behave the same way. Some data is only collected at most once per session. So, continuously refreshing the payload won't actually result in new data being pulled in. And, this behavior may change over time.

Also, desktop's behavior will likely differ from Android's.

It's probably best to guarantee a low "SLA" of the freshness of the data. If we exceed it, great. If not, we're not lying.

Comment 14

[Schalk Neethling [:espressive]]

(In reply to Annie Elliott from comment #12)
> that's a "Wroks for Me."

oops

Comment 15

[Annie Elliott]

A case of the Mondays... I have one :}

Comment 16

[Schalk Neethling [:espressive]]

So, does my wording in PR work or does it need to be tweeked?

Comment 17

[Mike Connor [:mconnor]]

I am not sure whether we want to do anything here.  I'd actually suspect that other than people trying to mess around, it'll look fully functional and accurate for users.

Comment 18

[Larissa Co [:lco]]

Before we implement something, can I provide a design recommendation first? This is on my list of bugs to look at.

I know I've been gone for a week so I'm trying to catch up with everything that's happened.

Comment 19

[Schalk Neethling [:espressive]]

(In reply to Larissa Co [:lco] from comment #18)
> Before we implement something, can I provide a design recommendation first?
> This is on my list of bugs to look at.
> 
> I know I've been gone for a week so I'm trying to catch up with everything
> that's happened.

Sure thing, let me know once you have had time to look at this, thanks!

Comment 20

[Larissa Co [:lco]]

Attachment: vital stats-health report update

Whoops, sorry about that. My suggestion in last week's meeting was to have a brief "last updated" message at the bottom of vital stats. See what I mean in the attachment

Note that for the most part, the attachment is CONCEPT ONLY for v2 for now (solves a few design bugs that have come up, but people haven't completely agreed on the direction yet)

I think there's no opposition the little "last updated" note though.

Comment 21

[Schalk Neethling [:espressive]]

Continuing from IRC, can we agree that we can do the following in terms of this bug:

'Your health report was last updated {{lastPingDate}}'

i.e. use lastPingDate for the last updated value? Thanks!

Comment 22

[Mike Connor [:mconnor]]

Let's back up here.  What specific problem are we trying to solve here?  The document handed to the remote report is not guaranteed to match a submission, or necessarily be 100% current.  Given that, any description is unlikely to be 100% accurate unless the daily collection is pretty recent.

It's not clear that we should change our implementation guarantees for the sake of having a text string.

Comment 23

[Schalk Neethling [:espressive]]

(In reply to Mike Connor [:mconnor] from comment #22)
> Let's back up here.  What specific problem are we trying to solve here?  The
> document handed to the remote report is not guaranteed to match a
> submission, or necessarily be 100% current.  Given that, any description is
> unlikely to be 100% accurate unless the daily collection is pretty recent.
> 
> It's not clear that we should change our implementation guarantees for the
> sake of having a text string.

So the main reason for this is to inform users that the data, both on the landing and raw data pages, is not live data but a reflection of the data that was last submitted to Mozilla, which might be yesterday, 3 days ago, today etc.

The perception some users have, and there has been a bug logged in this regard, is that the data is live so, if they add another bookmark and then go to FHR and see that the number of bookmarks has not gone up by one, they think something is wrong with FHR, but in reality, everything is as it should be, the latest data reflecting the additional bookmark just has not been submitted to Mozilla yet and hence we are not showing the change.

Comment 24

[Mike Connor [:mconnor]]

(In reply to Schalk Neethling [:espressive] from comment #23)

> So the main reason for this is to inform users that the data, both on the
> landing and raw data pages, is not live data but a reflection of the data
> that was last submitted to Mozilla, which might be yesterday, 3 days ago,
> today etc.

I understand that was the assumption we were working on, but that isn't true.  Some measurements are performance-intensive to collect, and so are not collected more than once per day.  Others can be trivially captured, so we don't record them.  When the health report is loaded, we'll generate a document to pass in, and some of that data will be fully "live" and others will lag for up to 24 hours.

That said, we also need to keep in mind that the feature needs to work even if data submission is off, and in that case there will never be a last payload, we'll just generate one as current as possible.

So our options are:

* Do nothing
* Attempt to describe reality: "some measurements are only collected once per day, so data may be slightly inaccurate"
* change the client to return 100% current data in all cases.
* cache and return the submitted payload by default, losing up to 24 hours of changes in the process.

Comment 25

[Georg Fritzsche [:gfritzsche]]

No activity since 2013, clearing assignee here.

Comment 26

[Georg Fritzsche [:gfritzsche]]

Since we switched to the v4 version we shall all the archived pings.
Closing as this doesn't any longer apply.