Closed Bug 490627 Opened 15 years ago Closed 15 years ago

Add back per-day containers for previous week in history UI

Categories

(Firefox :: Bookmarks & History, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: sparky, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090427 Minefield/3.6a1pre  Firefox/3.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090427 Minefield/3.6a1pre  Firefox/3.6

The per-day containers for days 2 through 6 were removed by bug 390614. The 'Last 7 days' container is a nice through, but it makes it a lot more difficult to quickly track down a site you know you visited 3 or 4 days ago.

For me, this is a pretty serious regression in usefulness. The daily breakdown was pretty much the only reason I ever used the history sidebar. Now it's pretty much useless to me.

Reproducible: Always

Steps to Reproduce:
1. Open history sidebar
2. Attempt to find a list of sites visited 3 days ago
Actual Results:  
No such breakdown exists.

Expected Results:  
A daily breakdown of history for the previous week.
Blocks: 390614
Version: unspecified → Trunk
I agree with Mathews reasoning on this
Suggesting WONTFIX per the reasoning in bug 390614 (specifically bug 390614 comment 21).  Maybe faaborg (or another user-experience person) wants to chime in here.  The final call is up to dietrich though.
Whiteboard: wontfix?
can you exactly remember you visited a certain time 4 days ago?
i think the last 7 days offers a much better bucket and opportunity to find what you're looking for.
s/time/site/
Well then, maybe add the per-day breakdown in addition to the 'Last 7 Days'
container? Or perhaps add a pref to control the breakdown method (current
model, per-day model, per-day + last 7 days)?

Regarding bug 390614 comment 21, if you knew you visited the site a few
days ago, you only have a few options on where it could be regardless of the
breakdown method. But IMHO, lumping a handful of days together is just putting
the needle in a larger haystack. At least in my experience, I've always found
it easier to find something in a bunch of smaller piles rather than one big
one.

And yes, I can generally remember where I've been +/- a day or so. So when I do have an idea, separate containers is faster. When I don't, it dosn't make much of a difference.
I concur that this is a serious regression.

The point is, I'd like to recall a page that I *know* I visited four days ago, but that has now been made into a more difficult task, since I now have to sift through the past seven days worth of data to retrieve a bit of information that I know can be narrowed down to one day.

For example, I regularly read a news site and amass a large number of visited pages.  If I wish to revisit a particular story that is part of a series covering a continuing news event, I now have to rummage through a weeks' worth of stories instead of being able to target the story that covers the event for that particular day.

The effort undertaken in bug 390614 to improve usability for history beyond the past week has had the ironic effect of diminishing usability for history inside the past week.

Making the buckets smaller for times when one can't mentally narrow the parameters is logical.  Making the buckets larger for when one can narrow the parameters is illogical.
(In reply to comment #3)
> can you exactly remember you visited a certain time 4 days ago?
> i think the last 7 days offers a much better bucket and opportunity to find
> what you're looking for.

This example is just badly worded. Often I wouldn't remember something from "4 days ago" but I might remember some I saw "last Tuesday".
Overall I don't think we should be investing much effort into the history sidebar either way, and we should start focusing on a history interface for the next release that leverages the content area and is considerably more effective for finding pages, as opposed to trying to improve a sidebar UI.

some other thoughts:

-wording a bucket as "last Tuesday" is indeed much better than "4 days ago," I believe we are currently doing this in the download manager

-while some users will be able to identify a specific day, it still seems like it is more common that users will be thinking "awhile ago," so scrolling through a a single larger bucket seems like it would be efficient that scrolling through several buckets (in the case where you are not sure).
I don't believe that anybody is asking for an "improvement," only the restoration of utility that was arbitrarily sacrificed for no desired or apparent purpose.
The comments on this bug aside, I've seen no major problems reported with the new buckets.

Reverting to the previous behavior is not going to happen. Appropriate alternate solutions:

1. make it extremely easy for extension developers to create custom bucket configurations

2. per comment #8, work on a better history browsing interface

-> WONTFIX
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
Whiteboard: wontfix?
This was never about wholeheartedly reverting to the previous behavior. As you so eloquently put it, this was about a better history browsing interface.

Regardless of the solution, there are going to be people who find one method easier to use than the other. As I previously stated, I'm in the camp that finds a daily breakdown more useful. But I'm understand that others find a more general breakdown more useful.

My point is, why is it a problem to provide both? I don't see how it is problematic to have both a 7 day breakdown and a 7 day summary at the same time.

Providing an interface to create custom buckets would certainly be a workable solution. However, in providing such an interface, wouldn't you already be doing most of the work to support both models? If you're going to go that far, wouldn't it be trivial to provide configurations for both models that could be toggled via a preferences ( like I suggested in comment #5 )

And for the record, this doesn't only pertain to the sidebar. The Library suffers from the same problems (and the lack of an 'all history' contain is troublesome)
If we build a history UI that leverages the content area for display, then the user could enter a specific time range or date into the location bar, and effectively "navigate" to seeing that set of history items in the location bar.  This provides the benefits of direct access (the user might know exactly what day or rang they need to target) without the detriments (namly the UI bloat that comes with prefs and alternate browsable interfaces)
Would like to know who and how the decision was reached to set the status of this bug to "resolved wontfix."   It's obvious that many users the better old sort style, including myself.
Firefox tries to satisfy vast majority of users, and to be customizable for them, this does not mean we can satisfy everybody. Just there is no will to further enhance an UI piece that will most likely be revised in near future, last 7 days will most likely contain the visits you are looking for, splitting it further would mean thinking that users exactly remember where they were 3 or 4 days ago, and that's just moving the problem from searching into a container to searching in more containers.
For one I certainly recall when I did something (I don't live & breath the internet, but am on for an hour on a daily basis and can usually readily recollect which day I did what. To put it into a bucket of 7 days is simply too large to bother with and personally I won't use it.  Perhaps there's another browser that does sort as needed?
(In reply to comment #15)
> Firefox tries to satisfy vast majority of users, and to be customizable for
> them, this does not mean we can satisfy everybody. Just there is no will to
> further enhance an UI piece that will most likely be revised in near future
Yes, Alex had previous spoke about revamping the history UI. Would such a revision completely replace the current sidebar and Library history implementation?

If not, then I think this still needs to be addressed in some fashion. A bit off topic, but at the very least the Library should be updated so it has a way to view all history at once (with out having to do something like searching for '.'). That was another thing that got lost in this whole debacle.

> last 7 days will most likely contain the visits you are looking for, splitting
> it further would mean thinking that users exactly remember where they were 3 or
> 4 days ago, and that's just moving the problem from searching into a container
> to searching in more containers.
This bug was never about getting rid of "the last 7 days", but rather adding back the ones that were removed. That way you leave it up to the user to find the best way to search through their own history.
>Would such a
>revision completely replace the current sidebar and Library history
>implementation?

We are looking into introducing in 3.7 the ability to enter time ranges into the location bar, like "yesterday", "last week" or "8/22/09."   This will aid users who are able to more exactly recall the range they need to look through.
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
Based on comment 18 shouldn't this bug be changed from "resolved won't fix" to something that indicates it's being actively pursued?
>Based on comment 18 shouldn't this bug be changed from "resolved won't fix" to
>something that indicates it's being actively pursued?

Sometimes people get annoyed if a bug is re-framed and fixed in an alternate way than the reporter's specific original intent (in this case to modify the history sidebar).  The functionality mentioned in comment #18 will be implemented over in bug 524049
You need to log in before you can comment on or make changes to this bug.