Closed Bug 464588 Opened 16 years ago Closed 15 years ago

Reword Clear Recent History time range option

Categories

(Firefox :: General, defect)

defect
Not set
normal

Tracking

()

VERIFIED DUPLICATE of bug 480169

People

(Reporter: faaborg, Assigned: beltzner)

References

(Blocks 1 open bug)

Details

Currently the wording is

Remove:
-the last hour
-the last two hours
-the last 4 hours
-my entire history for today
-----------------------------
-my entire history

Here are the problems with this wording:

-the value "Remove: my entire history" makes no direct reference to time

-using the word "history" causes people to assume this control only effects visited pages, as opposed to everything in the groupbox, since they aren't mapping history to the correct set of items

-the sentence structure design doesn't localize well

-I can't find other examples of sentence structure drop downs in Windows (although I think beltzner knows of some).

I propose we change the wording and structure to:

Time range to clear:
-Last Hour
-Last Two Hours
-Last Four Hours
-Today
----------------------
-Everything
Sounds good to me. The "Everything" rubs me backwards a bit, "Entirely" wouldn't. But I'll leave that up to a native speaker.
This would be much clearer. The 'History' is still inferred by groupbox title. There is no need to repeat what is being cleared as that depends on the checkbox choice within the groupbox.  

The 'Everything' rule may confuse users as it is not time specific, and may indicate to a user that all history options will get cleared rather than just their choice in the groupbox. 'Entirely' is better, but suffers from a similar problem in that it is not related to time. 

Is it possible to somehow calculate on the fly the oldest thing in their history,downloads,cookies,cache etc. or read an existing pref that sets the oldest retention range, and show that date instead. The last entry in the drop down would therefore read 'Entire 180 days' or 'Entire 90 days' etc. That way all entries in the list would have a time component which is what we want for clarity. 

The 'what are to be cleared components' are therefore explicitly dealt with only by the user's checkbox selections.
(In reply to comment #2)
> The 'what are to be cleared components' are therefore explicitly dealt with
> only by the user's checkbox selections.

In addition to what the others said, I would still like to see one additional line of text clarifying the relation between the dropdown and the checkboxes within the history section of the dialog. At least with the GTK theme I'm using on Linux there is no boundary around History and the checkboxes, and the small indentation doesn't really stand out enough.
So perhaps a "Apply this to" above the buttons would help.

(It's actually new to me that cookies and form entries would be collected as history and have a timespan associated with them, but I haven't really followed the last year of Places discussion in enough detail. Wrong place to discuss that here, anyway.)
Along the same lines of showing how long "everything" is, it might also be nice to show how long "today" is. At first glance it's not 100% explicit that it means today since midnight, rather than the past 24 hours. This would also avoid confusion if the user selects this at 10 past midnight expecting all of "today" to be cleared.

Thus the menu would look something like:

Time range to clear:
-Last Hour
-Last Two Hours
-Last Four Hours
-Today (last n hours/min)
----------------------
-Everything (last n days)
Blocks: 471910
(In reply to comment #0)
> -using the word "history" causes people to assume this control only effects
> visited pages, as opposed to everything in the groupbox, since they aren't
> mapping history to the correct set of items

We have named this dialog "Clear Recent History", so in order to make it less confusing, we should rename the dialog itself to something like "Clear Recent Data" or perhaps even "Clear Private Data" :-)
>so in order to make it less
>confusing, we should rename the dialog itself to something like "Clear Recent
>Data" or perhaps even "Clear Private Data" :-)

The downside of that is that we would need to stop staying things like "when in private browsing mode no history is recorded."  Some people are still mentally associating "history" with only pages visited (as opposed to all of the information that is implicitly collected), but I think overall we are doing a pretty good job of keeping the terminology consistent across the interface. Also, when you delete a page or site from history, we clear some of the associated data, so even when talking about traditional page views, the term history is broader behind the scenes.
We're past string freeze for fx 3.1 and this isn't a blocker or anyhow else triaged, removing late-l10n keyword.
Keywords: late-l10n
I think this should be a blocker, it left me confused enough to not even want to use the dialog, indeed I am still nervous about what it is going to do and we are playing with people's data here.
Flags: blocking-firefox3.1?
Keywords: late-l10n
Flags: in-litmus?
(In reply to comment #4)
> -Last Hour
> -Last Two Hours
> -Last Four Hours
> -Today (last n hours/min)
Just to be sure, "Today" would potentially clear less data than if you selected "last 4 hours". What if the user didn't realize the day changed? (What are the benefits of having a dynamic "today" vs a static 24 hours?)
Having a dynamic "today" option maps to the way humans usually divide their days, and the way we think they are likely to remember browsing habits ("I know I was there this morning, I don't remember if that's within 4 hours or not...").

I do think that "1,2,4,today,everything" could be revisited (maybe drop "2 hours" and add "this week"?) but I think that's a separate bug, and needs some actual data or at least compelling argument.  :)  It's also great add-on fodder.
Per the previous discussion, test case https://litmus.mozilla.org/show_test.cgi?searchType=by_id&id=7473 has
been added to litmus for regression testing. If a separate bug is going to be created for this issue, then please set the in-litmus flag to ? and reference this litmus test case to that bug for future consideration.
Flags: in-litmus? → in-litmus+
Aakash: I had already created https://litmus.mozilla.org/show_test.cgi?id=7401 as a general test case to cover this issue, so I think your test case is bit of a dupe of this. I had flagged the bug just to change the wording.
I don't think this blocks, but the patch is simple and safe and a good candidate for taking after we re-open post B3.

I also agree that taking this along with a fix for 471910 seems ideal, though not essential. It would certainly simplify the dynamic/static 24 hours argument, though.
Flags: blocking-firefox3.1? → blocking-firefox3.1-
If we're string changing in the CRH dialog post-b3, I think bug 464207 is a good ride-along as well (1 extra string, makes us not look silly, can be part of the same patch as this bug).
Taking.
Assignee: nobody → beltzner
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.