Bookmarks/History Management: Tab or Window?
Ben Goodger
broken out into a separate window?
-Ben
Adam Kowalczyk (Ancestor)
I think it's definitely better in a tab.
Most of the time users operate around the toolbox and content area. I
think that forcing them to abandon current window and then use system
Taskbar to switch between main browser window and Places window would be
a bad idea.
Closing and switching tabs is something users do all the time and that
can be easily done in many ways. We're trying to make tab management as
smooth as possible in 2.0 and we should make use of these refinements.
Having Places Management in a new window completely disconnects user
from normal browsing activities. When you are main browser window you
can still see your current tabs, you can pick a bookmark or type in an
address and go back to browsing anytime, you can use menus and toolbars,
heck, even monitor weather at the statusbar. :) In short, you're not
disconnected from everything but Places Management.
Other advantages of displaying Places Management in main browser window:
- user can open multiple pages from Places in background tabs, have
immediate visual feedback and easily switch to these tabs
- user can drag Bookmarks to the Bookmarks Toolbar
I realize that so far tabs were used only for displaying content and
hence the potential confusion. However, I don't believe that's a good
reason to sacrifice usability.
I'm strongly in favor of keeping Places in main window.
Cheers,
Adam
scratch
> Does Places Management make sense in the browser window, or is it best
> broken out into a separate window?
I think it should be a pref, just like everything else relating to tabs.
there are some people who just don't like tabs, and there are people
like me who like tabs, but only when they personally elect to open
something in a tab.
-scratch
Mike Beltzner
I think it should be a pref, just like everything else relating to tabs.
there are some people who just don't like tabs, and there are people
like me who like tabs, but only when they personally elect to open
something in a tab.
Most of the time users operate around the toolbox and content area. I
think that forcing them to abandon current window and then use system
Taskbar to switch between main browser window and Places window would be
a bad idea.
Closing and switching tabs is something users do all the time and that
can be easily done in many ways. We're trying to make tab management as
smooth as possible in 2.0 and we should make use of these refinements.
I realize that so far tabs were used only for displaying content and
hence the potential confusion. However, I don't believe that's a good
reason to sacrifice usability.
Ben, I think Mike Connor's on the right track in that other thread where he proposes a compromise solution that gets us the best of both worlds. By using an overlay we clearly illustrate to the user that they're interacting with the browser in a rich UI that will affect the content in the window beneath the overlay, yet the overlay is attached to the browser window so you get some of the benefits of modality and tight coupling. Quite similar to the "sheet" approach taken by Apple in OS X. We can even do some graceful things were the UI opens in a narrow overlay to provide quick and simple search & browse, and then wider for the richer management tasks which require more UI space to accomplish.
Adam, the advantages you list can also be obtained using the overlay solution, and we avoid the messiness of mixing content with browser UI.
cheers,
mike
--
-------
mike beltzner, user experience lead, mozilla corporation
Adam Kowalczyk (Ancestor)
> Ben, I think Mike Connor's on the right track in that other thread where
> he proposes a compromise solution that gets us the best of both worlds.
> By using an overlay we clearly illustrate to the user that they're
> interacting with the browser in a rich UI that will affect the content
> in the window beneath the overlay, yet the overlay is attached to the
> browser window so you get some of the benefits of modality and tight
> coupling. Quite similar to the "sheet" approach taken by Apple in OS X.
> We can even do some graceful things were the UI opens in a narrow
> overlay to provide quick and simple search & browse, and then wider for
> the richer management tasks which require more UI space to accomplish.
>
> Adam, the advantages you list can also be obtained using the overlay
> solution, and we avoid the messiness of mixing content with browser UI.
Actually, I like the overlay solution a lot but since Ben wrote as if
these two were the only considered alternatives I commented on them.
This is going to need a lot of discussion as it's a new approach for
Firefox but if we worked this out it would be great.
(By the way, if we decide to use overlay then it can be potentially used
with other components like EM and TM to unify the UI)
Thank for your reply,
- Adam
scratch
> On 2/13/06, scratch <scr...@the-pentagon.com> wrote:
>> I think it should be a pref, just like everything else relating to tabs.
>> there are some people who just don't like tabs, and there are people
>> like me who like tabs, but only when they personally elect to open
>> something in a tab.
>>
>
> No, no, and um, no. The world needs less prefs, not more. This is a pretty
> simple question, which boils down to: Do we think that the management of
> Places should be surfaced in the same UI area as normally used for content,
> or do we think that it deserves/requires a seperate window.
well, the thing is, right now if a user doesn't want to use tabs (and i
know users like that), they never have to see them. they can pretend
firefox is a non-tabbed browser.
i think i agree with the rest of your post, though. having places in a
tab does feel like a bad idea, even optionally.
-scratch
Mossop
I really don't think a separate window is a good way to go. I've been
using places a fair bit lately and I quite like how it works now. I only
ever have it open for the time taken to find a link then I open the link
and don't want to see it anymore. Opening the link conveniently gets rid
of places for me.
The only issue here is that often I have to open a new tab before
opening places to avoid losing my current page. This could be solved by
allowing you to open places in a new tab. I don't think it's a bad idea,
but not a default, just make the places button respond to middle click
like most of the rest of the UI, it's certainly what I expected.
The alternative is the overlay way which I also like, it fits in with
how I expect to use places.
The spanner in the works is the odd times that I want to have places
open for a prolonged length of time as I arrange my bookmarks toolbar,
with the overlay way I guess I would have to open a new browser window
to browse at the same time.
Mossop
Axel Hecht
> On 2/13/06, *scratch* <scr...@the-pentagon.com
I do like the overlay proposal, and second that it is important that
users distinguish UI from content. I always felt odd about the chrome://
URL in flock (and places, IIRC).
My question would be, should such an overlay be hooked up to the window
or the tab?
And, just to hold that thought, should the places overlay be
incorporated into back-forth navigation? If I search my places, go to a
URL, read and/or dismiss, hit back, getting to my search results would
be nice. Esp as we know that tabs are not that widely used as they should.
Axel
Mossop
> My question would be, should such an overlay be hooked up to the window
> or the tab?
I would say window. Mainly because I think for the overlay to appear
truly separate to the content, it would have to overlay more than just
the content area but should appear on top of the tabs and toolbars too,
so changing tabs would be tough.
> And, just to hold that thought, should the places overlay be
> incorporated into back-forth navigation? If I search my places, go to a
> URL, read and/or dismiss, hit back, getting to my search results would
> be nice. Esp as we know that tabs are not that widely used as they should.
Again, to make this separate from the content it should not appear in
the history.
Ben Goodger
> Ben, I think Mike Connor's on the right track in that other thread where
> he proposes a compromise solution that gets us the best of both worlds.
> By using an overlay we clearly illustrate to the user that they're
> interacting with the browser in a rich UI that will affect the content
> in the window beneath the overlay, yet the overlay is attached to the
> browser window so you get some of the benefits of modality and tight
> coupling. Quite similar to the "sheet" approach taken by Apple in OS X.
> We can even do some graceful things were the UI opens in a narrow
> overlay to provide quick and simple search & browse, and then wider for
> the richer management tasks which require more UI space to accomplish.
Can you sketch out quickly for me (ascii is fine) what you think this
would look like? I'm having a hard time visualizing.
Mike Connor
> Mike Beltzner wrote:
>> Ben, I think Mike Connor's on the right track in that other thread
>> where he proposes a compromise solution that gets us the best of both
>> worlds. By using an overlay we clearly illustrate to the user that
>> they're interacting with the browser in a rich UI that will affect
>> the content in the window beneath the overlay, yet the overlay is
>> attached to the browser window so you get some of the benefits of
>> modality and tight coupling. Quite similar to the "sheet" approach
>> taken by Apple in OS X. We can even do some graceful things were the
>> UI opens in a narrow overlay to provide quick and simple search &
>> browse, and then wider for the richer management tasks which require
>> more UI space to accomplish.
>
> would look like? I'm having a hard time visualizing.
This is barely napkin-sketch-worthy, but this is to get started.
There's different variations on the same theme.
(just show search by default, don't even need to show results pane,
could go either way)
----------------------------------------------------------
| [Places] [Folder] [Folder] [Bookmark] [Bookmark]
----------------------------------------------------------
| |
| Search [________________]|
| |
| [More >>] |
|__________________________|
(Search results expand out, lots of options as to how to present the
results)
----------------------------------------------------------
| [Places] [Folder] [Folder] [Bookmark] [Bookmark]
----------------------------------------------------------
| |
| Search [foo____________x]|
| |
| | MLS Listings | |
| | L.J. Hooker | |
| | Barfoot & Thompson | |
| | Century 21 | |
| | | |
| |______________________| |
| |
| [More >>] |
|__________________________|
(Full version cribbed from
http://wiki.mozilla.org/Places:User_Interface, probably not current,
just for illustrative purposes)
----------------------------------------------------------
| [Places] [Folder] [Folder] [Bookmark] [Bookmark]
----------------------------------------------------------
+-----------------------------------------------------------------------+
| +----------------------+ +------------------------------------------+ |
| |[ real estate| ]| | Search Results for 'foo': ( Save )(+)| |
| | @ All History | |==========================================| |
| | @ Bookmarks Menu | | Name | Location | |
| | @ Bookmarks Toolbar | |------------------+-----------------------| |
| | @ Subscriptions | | MLS Listings http://www.mlslis... | |
| | @ Bonjour | | L.J. Hooker http://www.lhhook... | |
| | @ Most Visited | | Barfoot & Thompson http://www.barfoo... | |
| | @ Updated Today | | Century 21 http://www.centur... | |
| | @ Folder 1 | | | |
| | @ Folder 2 | | | |
| | @ Folder 3 | | | |
| | @ Folder 4 | | | |
| | @ Folder 5 | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| +----------------------+ +------------------------------------------+ |
| ( + New Folder ) Group by: ( Site | Page ) [<< Less] |
+-----------------------------------------------------------------------+
Ben Goodger
> snip ascii
The compact versions are what I had in mind.
With regards to the full version, what seems to be lost now is the
ability to retain the window open at all times, at least in a
non-intrusive way (background window/tab).
-Ben
Mike Beltzner
Mike Connor wrote:
> snip ascii
Did my sketches make it to the list? I see them in my thread in Gmail, but mconnor says that he never got them. I think I'm about to get upset at Gmail ...
Just in case:
1. The user is browsing as normal, lah-dee-dah
2. The user opens the Places UI in "narrow" form and gets a search field and a box that shows either search results or the existing heirarchy & saved search folders for browsing. There's a button at the bottom for going into a "Manage Places ..." UI
3. After pressing that button, the overlay widens and the full management UI is presented, there's a button to go back to the narrow form
The overlay would close when a user selected a link, but not (as mconnor described earlier) if the user clicked with a modifier which opens the link in a tab or new window. Once closed, the overlay would remember state, and re-open to whichever of the narrow/wide UIs it was on last.
[1]: http://www.beltzner.ca/webdav/1-browsing.png
[2]: http://www.beltzner.ca/webdav/2-narrow-ui.png
[3]: http://www.beltzner.ca/webdav/3-wide-ui.png
With regards to the full version, what seems to be lost now is the
ability to retain the window open at all times, at least in a
non-intrusive way (background window/tab).
I'm not sure what user task-flow that would support. I am (perhaps blatantly) asserting that if a user is performing a task that requires the wide-UI, they are performing a task other than navigation/search/retreival of a bookmark and are instead either creating a saved search folder, organizing their heirarchy or doing advanced bookmark property editing tasks.
IMO, having that UI in a tab makes it less convienient, as the user then needs to manage that tab (move, close, find and switch to) as opposed to simply clicking the Places button and getting the overlay instantly.
Mike Connor
> Mike Connor wrote:
>
> > snip ascii
>
>
> ability to retain the window open at all times, at least in a
> non-intrusive way (background window/tab).
>
Yeah, that's definitely lost, but let's consider the usefulness of that
particular use-case. If the full view is primarily for more advanced
searching/management/saved query creation, its not something people will
multitask often, so the modal-like behaviour isn't an impediment. That
said, I don't believe that the full-on persistent management window is
going to be used most of the time, any more than the full-on bookmarks
manager is being used today. That said, we could easily persist last
state so its a keystroke/click to toggle open/closed if need be, which
is probably sufficient for the majority case. I'm sure that an
extension could easily replace the overlay with a button to open the
same UI in its own window, with relative ease, for those who really care.
Beltzner pointed out a problem with the dynamically-sized (a la
Spotlight) search results, namely that the More button moves around.
Thinking on this for a bit, I came up with the following, again
napkin-sketch thinking, but you could do some cool things with some
visual oomph and some animation. We're not tied to the menupopup-like
behaviour of IE's favourites center, we can make the Places button
expand out in two dimensions, instead of just dropping down.
----------------------------------------------------------------------------------------
| [Places] [Folder] [Folder] [Bookmark] [Bookmark]
----------------------------------------------------------------------------------------
Since the Places Toolbar items aren't what the user's looking for at
this stage, we can overlay them and move the More button up beside the
Places button.
----------------------------------------------------------------------------------------
||[Places] [More >>] |[Bookmark] [Bookmark]
-|
|-----------------------------------------------------------
| Search [________________]|
| |
|__________________________|
(Search results expand out)
----------------------------------------------------------------------------------------
||[Places] [More >>] |[Bookmark] [Bookmark]
-|
|-----------------------------------------------------------
| Search [foo____________x]|
| |
| | MLS Listings | |
| | L.J. Hooker | |
| | Barfoot & Thompson | |
| | Century 21 | |
| |______________________| |
| |
|__________________________|
(Full view)
----------------------------------------------------------------------------------------
||[Places] [<< Less] |
-|
|--------------
| +----------------------+ +------------------------------------------+ |
| |[ real estate| ]| | Search Results for 'foo': ( Save )(+)| |
| | @ All History | |==========================================| |
| | @ Bookmarks Menu | | Name | Location | |
| | @ Bookmarks Toolbar | |------------------+-----------------------| |
| | @ Subscriptions | | MLS Listings http://www.mlslis... | |
| | @ Bonjour | | L.J. Hooker http://www.lhhook... | |
| | @ Most Visited | | Barfoot & Thompson http://www.barfoo... | |
| | @ Updated Today | | Century 21 http://www.centur... | |
| | @ Folder 1 | | | |
| | @ Folder 2 | | | |
| | @ Folder 3 | | | |
| | @ Folder 4 | | | |
| | @ Folder 5 | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| +----------------------+ +------------------------------------------+ |
| ( + New Folder ) Group by: ( Site | Page ) |
+-----------------------------------------------------------------------+
Mike Beltzner
Beltzner pointed out a problem with the dynamically-sized (a la
Spotlight) search results, namely that the More button moves around.
----------------------------------------------------------------------------------------
||[Places] [More >>] |[Bookmark] [Bookmark]
-|
|-----------------------------------------------------------
| Search [________________]|
| |
|__________________________|
(Search results expand out)
Mike, your proposal is pretty heavily focused on search. I think we'll want to allow users to browse (their heirarchy, their subscriptions, their history trail) in the "narrow" overlay UI as well. If a user wants only search, we should remember that there's ways/thoughts about doing that in the URL bar and/or Search Bar as well.
I guess what I'm reacting to here is that I don't think the user should ever need to go into the "wider" UI unless they're looking to manage and organize their bookmarks/history. Everything else should be enabled through some (not neccessarily mine!) other lightweight UI pieces.
To recap, we were saying that the primary task we want to encourage is search, with browse as a secondary task (and, I would actually assert, the primary task for subscriptions) and manage as an advanced/tertiary task. Here's where I'm thinking of the mechanisms for those tasks being located in the chrome ..:
Search:
- quick drop-down typeahead search in URL bar or Search bar
- search box in "narrow" overlay UI
- search box in "wide" overlay UI
Browse:
- Bookmarks drop-down menu
- tree in "narrow" overlay UI
- tree in "wide" overlay UI
Manage:
- "wide" overlay UI
Thomas Stache (News)
> Did my sketches make it to the list? I see them in my thread in Gmail,
> but mconnor says that he never got them. I think I'm about to get upset
> at Gmail ...
>
This list seems to (silently!) discard posts with attachments, I was
bitten by that yesterday. Need to fall back to links, or fix mailman.
Ben Goodger
|
+------------------------------------------------------
|#@=#| / PTBookmark 1 / PTBookmark 2 / PTBookma...
| +--------------------------+
| Search Bookmarks & History: |
| [ ] |
| ( >> ) | <-- persists state across invocations
+-------------------------------+
|
+------------------------------------------------------
|#@=#| / PTBookmark 1 / PTBookmark 2 / PTBookma...
| +--------------------------+
| Search Bookmarks & History: |
| [ goat teleporter (x)] |
| |
| +---------------------------+ |
| | The Goat Teleporter & You | | <-- Goat AND Teleporter
| | http://www.goatweekly... | |
| |...........................| |
| | Livestock teleportation | | <-- Goat AND Teleporter
| | http://www.arginews.c... | |
| |...........................| |
| | Goat species | | <-- Goat only
| | http://en.wikipedia.o... | |
| |...........................| |
| | Teleportation Newsletter | | <-- Teleporter only
| | http://www.ieee.org/a... | |
| +---------------------------+ |
| ( >> ) |
+-------------------------------+
|
+------------------------------------------------------
|#@=#| / PTBookmark 1 / PTBookmark 2 / PTBookma...
| +----------------------------+
| Search Bookmarks & History: |
| [ ] |
| |
| +-----------------------------+ |
| | / Foo | |
| | / Bar | |
| | # Baz | |
| | / FooFoo | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| +-----------------------------+ |
| Showing: [ @ Bookmarks Menu :^] | <-- list of "places"
| |
| ( Organize... ) ( << ) |
+---------------------------------+
+----------------------------------------------------------------------+
| File Edit View Help |
+----------------------------------------------------------------------+
| [@ Search Bookmarks & History ] | @ New Folder @ Delete |
+----------------------------------------------------------------------+
| +----------------------+ +-----------------------------------------+ |
| |[ Search Bmks & Hist ]| | Showing Bookmarks Menu | |
| | @ All History | |=========================================| |
| |#@#Bookmarks#Menu#####| | Name | Location | |
| | @ Bookmarks Toolbar | |------------------+----------------------| |
| | @ Subscriptions | | CNN.com http://www.cnn.com/ | |
| | @ Bonjour | | | |
| | @ Most Visited | | | |
| | @ Updated Today | | | |
| | @ Folder 1 | | | |
| | @ Folder 2 | | | |
| | @ Folder 3 | | | |
| | @ Folder 4 | | | |
| | @ Folder 5 | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| +----------------------+ +-----------------------------------------+ |
| ( + New Folder ) ( + New Folder ) |
+----------------------------------------------------------------------+
Mike Beltzner
Summary + Modifications of ideas discussed in this and other threads:
Thomas Stache
display posts as children in the floaty/slim overlay, and what will the
integration with the FeedView look like?
I'd also like to mention a related use case for the bookmarks sidebar:
Due to a bug in the current LiveBookmarks implementation most of my ~10
livemarks (that live in a folder on my toolbar) fail on first load (I
guess a proxy/network timeout issue).
So I usually fire up the sidebar and invoke "Reload live bookmark" from
the context menu for every one of them (which sucks) - doing that from
the bookmarks toolbar is even harder due to collapsing menus.
*So:* should the floaty/slim UI stay in place (or collapse) after I used
a context menu command?
--
Thomas
Mike Beltzner
How would Live Bookmarks work in the slim/extended UIs? Will they still
display posts as children in the floaty/slim overlay, and what will the
integration with the FeedView look like?
I would expect that search results that match feed subscriptions would show up in the search results (potentially as an expandable item?) and that when one browses, one would be able to browse like they currently do in the bookmarks manager.
So I usually fire up the sidebar and invoke "Reload live bookmark" from
the context menu for every one of them (which sucks) - doing that from
the bookmarks toolbar is even harder due to collapsing menus.
*So:* should the floaty/slim UI stay in place (or collapse) after I used
a context menu command?
Well, yes, I would think that it would, but I also think that we need a better way to refresh live bookmarks. It makes sense to me that any time the folder representing the live bookmark is opened, it is also refreshed. That way you're sure you're viewing the latest content.
These are good questions, and bring up the point that the next thing to think about is how all of this interacts with feeds.