928843 - Polish the history view

Status: RESOLVED WORKSFORME

(Firefox :: Toolbars and Customization, defect)

Description

[:Gijs (he/him)]

(In reply to Thomas Stache from bug 888572 comment #15)
> Would it be possible to add some (sub)section headers to the view? It now
> looks funny with some menu items, page titles, more menu items, page titles
> - only structured with separators. It's hard to make sense of it all.

Additionally, it seems we should be setting the favicon size for these and aren't, because on my Windows machine I see double-size icons for some of the items in the recently closed tabs/windows list.

Comment 1

[:Gijs (he/him)]

The huge icons were fixed already, but this should still get a bit more love, I think.

Comment 2

[Matthew N. [:MattN]]

Fixing dependency tree so this bug is tracked

Comment 4

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

this is definitely a regression compared to the old history menu

Comment 5

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

and since bug 940464 has been duped here, this needs to be more generic

Comment 6

[Jim Jeffery not reading bug-mail 1/2/11]

Clicking on the new Menu-button (Hamburger) and then History I see that the menu-item to 'show all history', is now a 'link' at the bottom of the History display.

Previous to Australis, there was a menu-type command line at the top of the history list, i.e. open History from the Menu,  Alt+history , note that 'Show All History' is at the top with keyboard shortcut shown as Ctrl+Shft+H,  The New History button in the Hamburger button should be the same.  

It was not immediately 'obvious' to me how to open All History and was thinking it had been removed, until I discovered, buried at the bottom of the history list a 'Link'...

The list of items in History should match the list items when clicking the Bookmarks button, i.e.  Show all Bookmarks, is at the top.

Comment 7

[alex_mayorga]

Why "History" has to be constrained to a % of the width of the "hamburger" menu?

It truncates almost all the titles there for no good reason IMHO.

I for one would like the polish the "Bookmarks" menu has to be done on the "History" menu.

Comment 8

[Jared Wein [:jaws] (please needinfo? me)]

Win8 styling of the History view, it should be the same for all platforms though, http://screencast.com/t/kF5Wzhvv

Comment 9

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Why do exactly history items interleave other entries (Restore all tabs/Restore all windows), in the mockup too? The current history widget contents don't make any sense to me.

Comment 10

[:Gijs (he/him)]

(In reply to Marco Bonardo [:mak] from comment #9)
> Why do exactly history items interleave other entries (Restore all
> tabs/Restore all windows), in the mockup too? The current history widget
> contents don't make any sense to me.

They are closed tabs/windows that can be restored.

Comment 11

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

I find it very confusing, it definitely needs better sperators. As it is, it looks like random options are put in the middle of the history entries...

Comment 12

[Jim Jeffery not reading bug-mail 1/2/11]

I agree with Marco.  History is a special-case item in the new Menu-panel in that its the only icon to have extensive/long list of items. 

Recent close tabs / windows should IMO have a expander arrow, like from pre-Australis to display those items. It would shorten the list and prevent bugs like https://bugzilla.mozilla.org/show_bug.cgi?id=951723 
for users that run with a higher DPI due to vision problems.  There are a considerable number of users that run at 125% on Windows and I suspect there will be any number of complaints about the list being off the bottom of the view-port.

Comment 13

[Robert Kaiser]

(In reply to Marco Bonardo [:mak] from comment #11)
> I find it very confusing, it definitely needs better sperators. As it is, it
> looks like random options are put in the middle of the history entries...

Yes, it's also unclear from looking at that list what are closed tabs and what are closed windows - even if you know they are in there.

That said, I often open the history view trying to find the "Show All History" item and it's not there, it can only be accessed by the workaround of going to bookmarks and opening the library from there and then go to history inside that.

Comment 14

[Zhenshuo Fang (:fang) - Firefox UX Team]

Attachment: History Subview.jpg

(In reply to Marco Bonardo [:mak] from comment #11)
> I find it very confusing, it definitely needs better sperators. As it is, it
> looks like random options are put in the middle of the history entries...

Agreeing with Marco, the "restore all tabs" copy is confusing because there is no indication that "all tabs" are actually all recently closed tabs. 

Here's a proposal to rename the action to "restore recently closed tabs" and place it on top of all the recently closed items, same with recently closed windows. Unfortunately the string is very long...but hopefully it makes more sense, that below the action are the recently closed tabs/windows user can restore.

There's also an argument to place the full history list before the recently closed items, which also make sense. I just don't think we have any data to support one or another.

Comment 15

[Zhenshuo Fang (:fang) - Firefox UX Team]

Related to History subview, I also don't think we should put "View history sidebar" as the first item if not many people use it.

Comment 16

[:Gijs (he/him)]

(In reply to Zhenshuo Fang (:fang) - Firefox UX Team from comment #14)
> Created attachment 8366251 [details]
> History Subview.jpg
> 
> (In reply to Marco Bonardo [:mak] from comment #11)
> > I find it very confusing, it definitely needs better sperators. As it is, it
> > looks like random options are put in the middle of the history entries...
> 
> Agreeing with Marco, the "restore all tabs" copy is confusing because there
> is no indication that "all tabs" are actually all recently closed tabs. 
> 
> Here's a proposal to rename the action to "restore recently closed tabs" and
> place it on top of all the recently closed items, same with recently closed
> windows. Unfortunately the string is very long...but hopefully it makes more
> sense, that below the action are the recently closed tabs/windows user can
> restore.
> 
> There's also an argument to place the full history list before the recently
> closed items, which also make sense. I just don't think we have any data to
> support one or another.

Changing the font-size of an item because we can't make the English text fit isn't the best start, though... What will l10n do? Can we not think of a better solution?

Why the 'recent' - even if it was a day ago, a tab will show up there - I don't think we ever purge tabs from that list or anything. Maybe we could just say "Restore Closed Tabs" or "Restore Closed Windows" ?

Comment 17

[:Gijs (he/him)]

Upping this because strings, and the signficant regression for people who regularly mouse-use this menu...

Comment 18

[u428464]

Stephen's mockup shows the history items first and then tabs and windows. It seems more logical to me.

Comment 19

[Sören Hentzschel]

(In reply to Guillaume C. [:ge3k0s] from comment #18)
> Stephen's mockup shows the history items first and then tabs and windows. It
> seems more logical to me.

For me it's not more logical, the recently closed tabs are the most important and should be come first. But "Show all history" should be on top.

Comment 20

[u428464]

Since it's history I would expect to have the history items on top, but let UX decide this.

Another nice fix would be to add the new separators in bug 938578

Comment 21

[Zhenshuo Fang (:fang) - Firefox UX Team]

(In reply to :Gijs Kruitbosch from comment #16)
> 
> Why the 'recent' - even if it was a day ago, a tab will show up there - I
> don't think we ever purge tabs from that list or anything. Maybe we could
> just say "Restore Closed Tabs" or "Restore Closed Windows" ?

"Restore Closed Tabs" works for me.

For where to put "show all history" and the order of recently closed items vs. history items, I can see argument from both side. But at this point we don't have any data to support one or the other, I think we should stick to stephen's original mockup, which is putting the closed tabs/windows first and keep "show all history" on the bottom.

Related to this, the "show all history" should be docked at the bottom, but now you have to scroll to see it, is there already a bug for this? if not I can file one.

Comment 22

[u428464]

(In reply to Zhenshuo Fang (:fang) - Firefox UX Team from comment #21)
> (In reply to :Gijs Kruitbosch from comment #16)
> > 
> > Why the 'recent' - even if it was a day ago, a tab will show up there - I
> > don't think we ever purge tabs from that list or anything. Maybe we could
> > just say "Restore Closed Tabs" or "Restore Closed Windows" ?
> 
> "Restore Closed Tabs" works for me.
> 
> For where to put "show all history" and the order of recently closed items
> vs. history items, I can see argument from both side. But at this point we
> don't have any data to support one or the other, I think we should stick to
> stephen's original mockup, which is putting the closed tabs/windows first
> and keep "show all history" on the bottom.
> 
> Related to this, the "show all history" should be docked at the bottom, but
> now you have to scroll to see it, is there already a bug for this? if not I
> can file one.

No in fact even if "show all history" is at the bottom, the rest of history items are on top. Look closely the separators here.

Comment 23

[Sean Smith]

After the landing of bug 878546 my history menu has increased padding.  So now my menu is extremely long, and I can't even get to the "Show All History" link at the bottom because the menu is under the taskbar.  In addition, the entire panel moves up, so the arrow at the top of the menu is now anchored to the top of the button.  It's jarring and it looks bad.

I can attach a couple of screenshots if anyone needs them.

Noticed on Win7, default Aero theme.

Comment 24

[:Gijs (he/him)]

Attachment: start polishing the Australis history view by improving labels,

So this fixes the recently closed items to have the correct headings. That doesn't fix all the issues here, but it gets the strings out of the way.

Comment 25

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 8367953 [details] [diff] [review]
start polishing the Australis history view by improving labels,

Review of attachment 8367953 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/components/customizableui/src/CustomizableWidgets.jsm
@@ +187,5 @@
>        separator = doc.getElementById("PanelUI-recentlyClosedWindows-separator");
>        elementCount = windowsFragment.childElementCount;
>        separator.hidden = !elementCount;
>        while (--elementCount >= 0) {
> +        windowsFragment.children[elementCount].classList.add("subviewbutton");

This will add the subviewbutton className to the menuseparator, which isn't semantically correct. Do we need to add this className (or something like it) to the menuseparator for styling? Or can we skip adding it the className to the menuseparator?

::: browser/components/sessionstore/src/RecentlyClosedTabsAndWindowsMenuUtils.jsm
@@ +30,5 @@
>    *          The tag name that will be used when creating the UI items.
> +  * @param   aPrefixRestoreAll (defaults to false)
> +  *          Whether the 'restore all tabs' item is suffixed or prefixed to the list.
> +  *          If suffixed (the default) a separator will be inserted before it.
> +  * @param   aRestoreAllLabel

Add a "(defaults to "menuRestoreAllTabs.label") here and for getWindowsFragment (respectively).

Comment 26

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Jared Wein [:jaws] from comment #25)
> > +        windowsFragment.children[elementCount].classList.add("subviewbutton");
> 
> This will add the subviewbutton className to the menuseparator, which isn't
> semantically correct. Do we need to add this className (or something like
> it) to the menuseparator for styling? Or can we skip adding it the className
> to the menuseparator?

Ehrm, cough cough, nevermind. Move along... :)

Comment 27

[:Gijs (he/him)]

w/ nits,

remote:   https://hg.mozilla.org/integration/fx-team/rev/aeb7967a0a8c

Comment 28

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/aeb7967a0a8c

Comment 29

[:Gijs (he/him)]

I'm not the best person to push this the rest of the way. Mike, do you want to look at this?

Comment 30

[Mike de Boer [:mikedeboer]]

Sure! *nomnomnom*

Comment 31

[u428464]

I really think this depends on bug 938578.

Comment 32

[Mike de Boer [:mikedeboer]]

tracking is cheap... ;)

Comment 33

[:Gavin Sharp [email: [e-mail]]]

in triage: we think that outstanding work here is tracked in other bugs. Please re-open if that isn't so!