Re: Places UI
Alex Faaborg
superimposed on top of the first mockup here (to help organize the
feedback): http://wiki.mozilla.org/Places:User_Interface/Tagging_a_Page1
Or, you can read them below:
> Favicon menu. I'm not entirely sure that the Favicon menu is a
> really great idea, but I'm interested in possibly (in a separate
> discussion) talking about the reasoning behind that.
This was suggested by mconnor, I like the idea for four reasons:
1) The actions in this menu have a visual mapping to the location bar
2) It allows us to push complexity out of primary UI and into
secondary UI
3) The placement makes more sense than IE's Page Menu
4) Since this menu matches the design of the search box, it will be a
familiar control
> * What's the difference between a Bookmark and a Tag? I've gone
> through the mockups a few times now and I'm still struggling to
> find any significant difference.
>
> ...
>
> If tagging and bookmarking accomplish basically the same thing, in
> the favicon dropdown, are "Tag" and "Bookmark" somewhat redundant?
In this design tagging and bookmarking were separated so mainstream
users (who are well out of the Web 2.0 silicon valley mindset) would
be able to bookmark pages without having to understand what it means
to tag something. For instance, the most requested Gmail feature is
"Folders" (Gmail has a tagging system for organizing email)
I think we can integrating tagging into the bookmarking UI in a way
that can still be ignored by user's who are not interested in
learning what tagging is. In the next design bookmarking and tagging
will be collapsed into a single dialog.
> Will there be a keyboard shortcut for Tagging? An optional toolbar
> button? Will it be available on a page's rt-click context menu?
In the next design it's going to pick up the behavior of bookmarking
for all three interactions.
> Feed Notification. I noticed that your URL bars in the mockups
> don't have the orange feed icon at the right hand side of the URL
> bar, but there is a feed icon in the favicon menu. Is it your
> intention to move the feed notification icon out of the primary UI?
No, we should probably keep the RSS icon in primary UI. However, If
we want it redundantly placed in the favicon menu so we can pick up
the textual description "Subscribe" is a separate choice.
> Will there be an easy way to skip the initial tagging step and go
> directly to the tag entry textbox? As it stands, it's at least one
> extra click whenever I want to bookmark + add text tags to a page
> rather than just bookmark/star the page.
The reason for the extra click is so the user feels like they are
done when creating quickly creating a bookmark. If they see a text
field with the focus, they may feel compelled to write something. I
think we should allow for quickly tagging a page through a keyboard
shortcut and (if we have time) a quicksilver like UI.
> Untagging. If a user is on a page that has been previously tagged,
> will the "Tag..." item on the favicon menu become "Untag..."? Or
> possibly, "Edit tag...", or both?
>
> How can a user add/edit text tags on a previously tagged page?
In the next design the single menu item will change to "Modify Bookmark"
> Tag suggest. Like search suggestions, perhaps there could be a tag
> suggestion feature where suggested tags (sourced out of the All
> Tags list) could be listed as the user types (just like search
> suggestions). This would help users re-use existing tags without
> having to scroll through and click repeatedly in a checklist.
>
> Tab completion. Being able to tab-complete tags if there's only
> one item in the tag suggest list would be sweet.
Yeah, I definetly think we should do that.
> The "All Tags..." button over the "Untag" and "OK" buttons is
> pretty busy and looks a little awkward. Maybe the tag text entry
> box could have a drop arrow beside it that, when clicked, opened
> the All Tags checklist?
Sure, Both Windows and OS X have expansion controls that would work
for that, but I am not sure if they are in XUL yet.
> I find the "text gains a tag appearance" feature in Thunderbird and
> Flock (which I believe does it for tagging as well) to be very
> distracting and frustrating, particularly when I'm trying to edit
> text that's already changed to the "tag appearance". I usually end
> up deleting the original and having to start over, which is very
> frustrating. How will this system ensure that users are able to
> easily edit/modify "tag appearance" labels?
[note: beltzner disagrees with me on this one] If it appars as a tag,
then you hit the comma as indicator of being done, and you won't
likely need to edit it anymore. This type of visual appearance
provides feedback on what the tags actually are, since they can
contain spaces.
> Inconsistent terminology. I noticed that there's a bit of mushy
> terminology: "Tags", "Describe...", "Keywords", etc. If "Tag" here
> really is going to be the equivalent of "Star" and "Keywords" are
> going to be the actual text labels, perhaps the "Describe..."
> button should instead read "Add Keywords..."? That, of course,
> conflicts with our current use of "Keyword" in the bookmarking
> context. This terminology stuff should probably be discussed and
> sorted out in the near future so we're all in agreement about which
> means what.
In the next design I'm going to clean up the terminology to
"Bookmarking" a page, and Bookmarked pages can either be "tagged," or
placed in "folders," or both.
I'll go through the feedback for viewing tagged pages tomorrow.
Cheers,
-Alex
Mike Beltzner
> Overall, I'm really excited that this stuff is moving forward and
> we're looking at adding tagging to Firefox. Very, very excited.
I am, too, but want to make sure that we're doing so in ways that meet
the following goals:
- reduce the cost of creating a bookmark
- support users new to tagging & support existing bookmark heirarchies
- maintain the ability to create consistently and quickly accessible
bookmarks that act as shortcuts to frequently visited sites
- do not force users to change the way they interact with bookmarks
My rants about tagging and why it's needed are well documented, but I
see it as a result of the web changing. (Short version of my rant for
those unfamiliar: when the web used to be small, one type of bookmark
was good enough, as there were few sites that people would need to
revisit; now that the web is large, bookmarks are good for "shortcut"
actions in that they are quick, consistently located and can be
organized into a meaningful structure, but they aren't useful for acting
as a memento or sticky-note like marking on a web page that a user might
want to get back to, as their permanence doesn't allow them to scale;
tagging solves this by making it possible to create a class of bookmark
which can be searched and restored, but not permanently located in a
menu such that they add clutter to the user's workspace)
> That said, I've spent a couple of hours going through the mockups and
> jotted out the following notes/questions. It sort of ended up longer
> than originally expected...
I'll comment inline, and know that Alex is prepping a response, too, so
I'll try to avoid redesigning everything for him, and will wait to
digest & respond to that one :)
> == Tagging a page ==
>
> * What's the difference between a Bookmark and a Tag? I've gone
> through the mockups a few times now and I'm still struggling to find
> any significant difference.
Hrm; I can see where the confusion comes in. The idea was that a
bookmark was an object that pointed to a page, and a tag was a property
of a page. A user could create a bookmark and/or tag a page, and that
only bookmarks would be objects unto themselves (which could be named,
moved, etc) and tags would just be properties of a page (which could be
searched, organized, filtered, etc). A page might be both the target of
1..N bookmarks and have 1..M tags on it.
An early UI mockup expressed this by allowing users to tag a page, and
then providing a button to "Create Bookmark" that would lead into the
"Add Bookmark" screen; that seemed to get lost in this revision.
Perhaps that isn't as elegant an idea as we'd originally thought,
though, or isn't as well expressed as I'd thought.
> As it stands, since "Tagging" here doesn't necessarily involve adding
> text tags, when bookmarking and tagging pages, the end result seems
> very similar:
Yeah, the idea was that a user could tag a page and that action in
itself would mark the page as having been interested. Adding labels to
the tag allowed for further search specificity. Too confusing?
> = Bookmark This Page: Pops open a dialog through which a user can
> bookmark a page and optionally specify a bookmark folder. = Tag: Pops
> open a dialog through which a user can bookmark a page and optionally
> specify bookmark tags.
>
> If simple bookmarking and tagging are basically the same thing, why
> are we separating them conceptually? Why wouldn't we just expand
> bookmarking to allow users to optionally add text tags?
They aren't, in that bookmarking creates an item that lives in the
bookmark menu, whereas tagging marks a page such that it can be more
easily found later (and appears in the "Tagged Pages" smartfolder). This
serves the goal of allowing people to tag more pages than they bookmark,
making it easier to find those pages they found interesting without
adding a kajillion entries to the Bookmarks hierarchy.
> In my mind "Bookmarking" means "Recording the location and title of a
> page so I can find it again later", where "Tagging" means "Adding
> text labels to [something] so I can more easily group, categorize,
> filter, and find it later".
Yeah, mine, too. Which means that (to me) a tag is a property, and a
bookmark is an object.
Alex and I chatted on IRC about the idea of just making it possible for
bookmarks to not be created in a location, unifying the model into
something which I think is closer to what you expect. So the user would
create a bookmark, and could add tags to it, and if they placed that
bookmark in the Bookmark Menu, then it would live there as a permanent
entry; otherwise they'd have to search for it using a search/filter UI.
> FYI: Several my other notes are related to my confusion about the
> difference between bookmarks and tags.
I'll just quickly add notes for the ones that do ... :)
> * If tagging and bookmarking accomplish basically the same thing, in
> the favicon dropdown, are "Tag" and "Bookmark" somewhat redundant?
(No, they're different things)
> * Will there be a keyboard shortcut for Tagging? An optional toolbar
> button? Will it be available on a page's rt-click context menu?
(Yes, I would hope so!)
> * As I mention above, the first step in the tagging workflow seems to
> be the equivalent of bookmarking or "starring" a page, and doesn't
> actually involve adding text tags of any sort. In itself this isn't
> bad (I'm a big fan of having some sort of "Quickmarks"), but that
> doesn't feel like "tagging" to me -- it's simply a way to create a
> bookmark.
(It's actually just meant to be marking the page as interesting, or
starring it, which would promote it in history search results and itself
be a queriable criteria)
> * Will there be an easy way to skip the initial tagging step and go
> directly to the tag entry textbox? As it stands, it's at least one
> extra click whenever I want to bookmark + add text tags to a page
> rather than just bookmark/star the page.
I think that we should have one, yeah. The goal here was to make it easy
to be really lightweight about this, like just "hey, that's cool, I'll
tag that" with a one-click action. But we should probably have the text
field there, and pre-populated with "(optional)" or something, and have
the dialog fade away if the user clicks in the content area.
> * I find the "text gains a tag appearance" feature in Thunderbird and
> Flock (which I believe does it for tagging as well) to be very
> distracting and frustrating, particularly when I'm trying to edit
> text that's already changed to the "tag appearance". I usually end
> up deleting the original and having to start over, which is very
> frustrating. How will this system ensure that users are able to
> easily edit/modify "tag appearance" labels?
I agree here; the tag appearance (which might be tough to do anyway) is
meant to show that a tag can have spaces in it, and illustrate the
boundaries of a tag. However, if a user clicks back on that tag and then
double clicks it, we should re-enter edit mode. I think mail.app does
something like this ...
> * No "Cancel" button on tag textbox page. If a user has
> tagged/starred a page and then goes to add further text tags to it,
> there's no easy way to just say "oh nevermind, I don't want to add
> text tags at all". Maybe there should be a cancel button on the tag
> entry textbox dialog?
Agreed. But I think that's what "untag" does.
> * Untagging. If a user is on a page that has been previously tagged,
> will the "Tag..." item on the favicon menu become "Untag..."? Or
> possibly, "Edit tag...", or both?
I would imagine "Edit tag..." and then "Untag". That saves a menuItem
(which gives a UI angel their wings) and I don't think we're going to
get a lot of accidental tagging.
> * How can a user add/edit text tags on a previously tagged page?
See above.
> * Feed Notification. I noticed that your URL bars in the mockups
> don't have the orange feed icon at the right hand side of the URL
> bar, but there is a feed icon in the favicon menu. Is it your
> intention to move the feed notification icon out of the primary UI?
>
> * Favicon menu. I'm not entirely sure that the Favicon menu is a
> really great idea, but I'm interested in possibly (in a separate
> discussion) talking about the reasoning behind that.
I agree that these seem like changes that are independent of this
design. There's some great ideas in them, and I like the idea of seeing
where "subscribe" fits into the mental models of bookmarking/tagging,
but hinging the design on it seems like it's just gonna trip us up.
> * The "All Tags..." button over the "Untag" and "OK" buttons is
> pretty busy and looks a little awkward. Maybe the tag text entry box
> could have a drop arrow beside it that, when clicked, opened the All
> Tags checklist?
Personally, I dislike that [v] control; it's very Mac centric and I
don't think has an analogue in Windows UI design.
> * Tag suggest. Like search suggestions, perhaps there could be a tag
> suggestion feature where suggested tags (sourced out of the All Tags
> list) could be listed as the user types (just like search
> suggestions). This would help users re-use existing tags without
> having to scroll through and click repeatedly in a checklist.
>
> * Tab completion. Being able to tab-complete tags if there's only
> one item in the tag suggest list would be sweet.
I think the goal was to have tag creation work like entering addresses
in an email app, which (if I'm reading things right) speaks to both of
these items.
> * Inconsistent terminology. I noticed that there's a bit of mushy
> terminology: "Tags", "Describe...", "Keywords", etc. If "Tag" here
> really is going to be the equivalent of "Star" and "Keywords" are
> going to be the actual text labels, perhaps the "Describe..." button
> should instead read "Add Keywords..."? That, of course, conflicts
> with our current use of "Keyword" in the bookmarking context. This
> terminology stuff should probably be discussed and sorted out in the
> near future so we're all in agreement about which means what.
Agreed, and really speaks to the mental model we're going to try to
promote and get people thinking about.
> == Viewing tagged pages ==
>
> * Personally I would find the behaviour described by "Once the user
> starts typing in the search box, these search options appear" to be
> very jarring. If we're going to offer advanced search options,
> perhaps we should just do that instead of surprising the user with a
> UI that shifts and changes unexpectedly?
I agree, but understand what Alex was trying to do (save precious screen
real estate). I think, though, that the easier thing to do is put all of
that behind advanced search UI and in the general case, just assume that
the user wants to search titles and tags (and page content and notes,
see below)
> * In the Search options checkbox panel, what's the green "+" button
> for? It's not obvious what that would do. I understand its earlier
> use to add more filters, but why wouldn't we just offer all possible
> search options in the advanced search panel from the get-go?
Not really; there are potentially a large number of search criteria we
can offer (date, number of visits, etc) and so the advanced UI should be
hidden away unless it's really needed, IMO.
> * In the advanced search options, what's the difference between
> "text" and "notes"? Is this assuming a full-text indexing of all
> bookmarks/history?
I think so, yeah. Alex?
> * I think advanced search options might also usefully include "All"
> (or "All Fields"), and "URL" and/or "Domain". "All" in particular if
> all possible fields aren't going to be displayed in the checklist.
We agree!
> * Would tag search be a FAYT system? Being able to filter my tag
> list down to "Just tags that start with F" by typing a single
> keystroke into the search field would be useful.
I sure hope so. Performance might kill us here, but we should try.
> * Would tags be nested in any way? In one of the mockups in my "On
> Tagging II" brainstorm, I have it so any tag associated with another
> tag is nested within that other tag. The article with mockups is
> here:
>
> http://wiki.mozilla.org/User:Dria/On_Tagging_II
>
> I'm certainly not saying that my method is an ideal, but if I tag a
> page as "recipe, soup, crockpot", I'd very much like to be able to
> find that bookmark by narrowing down the filtered lists in stages:
> Recipes > Crockpot > Soup.
I actually really like your way, though we'll need to take care to
ensure we don't end up in an endless loop :)
> * As other folks have mentioned, "Bookmark Search" is an unclear
> label for that button. "Save search" would be good, or "Create Smart
> Folder" or somesuch. Will there be other ways to create saved
> searches/smart folders? Being able to start from the idea of
> creating a smart folder and then handcraft the filtering that
> populates that folder would be great -- sort of like how Google Mail
> allows you to create filters.
Agreed.
> == Tag management ==
>
> * I'd be interested in seeing what the proposed tag/bookmark
> management system looks like.
My feeling was that the management system should be done as a second
phase of the design, as the more interesting and complex work would be
done in the in-situ management UI. So I asked Alex to focus on this, first.
That said, I'd like to make the Bookmarks sidebar more functional; it
should support drag-and-drop re-organization, and have the ability to
inspect properties on hover.
I see the manager ending up a lot like what we have now, where:
- the left sidebar lets the user pick between bookmarks, bookmark
folders, tags, history, saved searches,
- a top-right pane shows the details of the items in the selected group
- a bottom-right pane shows a preview of the selected item
Of course, the top-right pane would be editable such that we wouldn't
have to rely on all this "Properties" modal dialog nonsense.
cheers,
mike
Mike Beltzner
See above.
We agree!
Agreed.
I see two ways to go for the manager. The first is to have something a
lot like what we have now, where:
- the left sidebar lets the user pick between bookmarks, bookmark
folders, tags, history, saved searches,
- a top-right pane shows the details of the items in the selected group
- a bottom-right pane shows advanced details of the selected item from
the top-pane, including a preview
The manager itself, in my mind, looks much as it looks like ..:
- picture a three-pane email-like UI
- the left pane would be a list-of-objects, filtered/searched/etc
- the top pane would be the properties of the selected item
- the bottom pane could be a preview of the selected item
>
>
> Feel free to ping me if any of this is unclear (which is very likely)
> or if you have questions, etc.
>
> ~ deb
>
>
> ----- "Alex Faaborg" <faa...@mozilla.com> wrote:
>> I've been spending some time recently on Places UI, and I just
>> uploaded two mockups here: http://wiki.mozilla.org/
>> Places:User_Interface
>>
>> Let's use this thread for discussion,
>>
>> -Alex _______________________________________________
>> dev-apps-firefox mailing list dev-apps...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-apps-firefox
>
Gervase Markham
> Yeah, mine, too. Which means that (to me) a tag is a property, and a
> bookmark is an object.
Can we eliminate the distinction, to simplify the model?
Say I "re-imagine" my current Firefox bookmarks as a large set of pages,
all tagged with "Gerv Is Interested In This" - in other words, a sort of
implicit tag I created when I pressed Ctrl-D.
Furthermore, I've arranged my bookmarks into folders a bit. I have a
"9am" folder for the sites I read in the morning, a Hacking folder, a
Good Writing folder and so on. If the UI for browsing tags is going to
be an expandable list, why doesn't everything in my Hacking folder
acquire the "Hacking" tag, and so on - and the folder structure itself
disappear? If I've got the same bookmark filed in both "Hacking" and
"Good Writing", the conversion would give it both tags.
Assuming we then have a "(none)" category for pages the user didn't
bother to tag (or top-level bookmarks) and suddenly we arrive in a place
where instead of bookmarks at all, we now just have tags. Ctrl-D brings
up a tagging dialog. You can hit "Enter" to track the page but with no
tags, or specify some.
Would this work?
> I agree here; the tag appearance (which might be tough to do anyway) is
> meant to show that a tag can have spaces in it, and illustrate the
> boundaries of a tag. However, if a user clicks back on that tag and then
> double clicks it, we should re-enter edit mode. I think mail.app does
> something like this ...
Instead of making it look like a luggage tag, have a faint pastel
background and a bolder colour line above and below only. This
separates, but the "the-ends-are-open" look encourages re-editing.
Gerv
Michael Lefevre
> Mike Beltzner wrote:
>> Yeah, mine, too. Which means that (to me) a tag is a property, and a
>> bookmark is an object.
>
> Can we eliminate the distinction, to simplify the model?
Based on previous places discussions and watching people who don't
understand tagging trying to use google mail, I'm not sure that's possible
and/or a good idea...
[snip]
> Furthermore, I've arranged my bookmarks into folders a bit. I have a
> "9am" folder for the sites I read in the morning, a Hacking folder, a
> Good Writing folder and so on. If the UI for browsing tags is going to
> be an expandable list, why doesn't everything in my Hacking folder
> acquire the "Hacking" tag, and so on - and the folder structure itself
> disappear? If I've got the same bookmark filed in both "Hacking" and
> "Good Writing", the conversion would give it both tags.
But then, if Firefox has changed my folders into tags but I don't
understand the tagging concept, what happens when I delete or rename that
bookmark that was in both the "good writing" and "hacking" folders? Maybe
I actually want two bookmarks for that URL, one with the "hacking" tag and
one with a "good writing" tag under a different name.
> Would this work?
Would work fine for people who understand tagging. For people who are
familiar with folders, you'll be forcing them to change their behaviour a
bit, and quite possibly doing that without them understand why things
don't work like they used to.
--
Michael
Deb Richardson
> This was suggested by mconnor
We should definitely split this out into another thread...do you want to start one?
> In this design tagging and bookmarking were separated so mainstream
> users
I understand that we need to have a way to make bookmarking behave exactly as it does now for folks who don't like/know about/understand tagging. My issue is with the idea that beltzner brings up that:
1) Bookmarks are objects that point at locations (this is fine)
2) Tags are properties of those locations (this is where I have the problem)
In my mind I see it as:
1) Bookmarks are objects that point at locations
2) Tags are properties of those objects
So, rather than saying Bookmarks and Tags are different things, Tags become a way to further enrich and refine of Bookmarks. This way Bookmarks could both be located in a Folder and have Tags, both of which the user could use to find those bookmarks later.
I think that thinking about it this way would:
a) Give us a way to very quickly create a "Quickmark" (one-click bookmark)
b) Traditional Bookmarks (create bookmark, specify a folder in which it will live)
c) Tagged Bookmarks (create bookmark, optionally specify a location, specify some tags)
I _think_ we could get away with adding an "Add tags:" textbox to the same dialog in which a folder location could be specified (like the current cmd-D bookmark dialog). Not sure how the one-click bookmark would be done -- maybe an optional toolbar button or somesuch. The two-click in the favicon menu (if the favicon menu remains) would be another method of doing cmd-D.
> I think we can integrating tagging into the bookmarking UI in a way
> that can still be ignored by user's who are not interested in
> learning what tagging is. In the next design bookmarking and tagging
> will be collapsed into a single dialog.
Yeah, I think we're in agreement here, I'm just making sure I'm expressing myself clearly :)
> > Will there be a keyboard shortcut for Tagging? An optional toolbar
> > button? Will it be available on a page's rt-click context menu?
>
> In the next design it's going to pick up the behavior of bookmarking
> for all three interactions.
Awesome.
> > Feed Notification. I noticed that your URL bars in the mockups
> > don't have the orange feed icon at the right hand side of the URL
> > bar, but there is a feed icon in the favicon menu. Is it your
> > intention to move the feed notification icon out of the primary UI?
>
> No, we should probably keep the RSS icon in primary UI. However, If
> we want it redundantly placed in the favicon menu so we can pick up
> the textual description "Subscribe" is a separate choice.
Ok, again just making sure. I use the Feed notification in primary UI all the time and would hate to have it go away :)
> The reason for the extra click is so the user feels like they are
> done when creating quickly creating a bookmark. If they see a text
> field with the focus, they may feel compelled to write something. I
> think we should allow for quickly tagging a page through a keyboard
> shortcut and (if we have time) a quicksilver like UI.
Sure, as I said, having a way to create a one-click bookmark would be great, but for the powertaggers having a fast way to create+tag would also be useful. I'm just suggesting we do both, not just the powertagger version. Maybe cmd-D could be the powertagger version (just throw focus into the tag textbox instead of title or something), and another button/menuitem/key combo would be the one-click version?
> > up deleting the original and having to start over, which is very
> > frustrating. How will this system ensure that users are able to
> > easily edit/modify "tag appearance" labels?
>
> [note: beltzner disagrees with me on this one] If it appars as a tag,
>
> then you hit the comma as indicator of being done, and you won't
> likely need to edit it anymore.
I strongly disagree with this assumption, for what it's worth. When I'm typing a comma-delimited list of any sort, I'll often throw in a comma then need to backspace past it to fix a word. If I had to take a hand off the keyboard to double click on a term every time I had to fix one, I'd get cranky pretty quickly.
I don't mind the tag appearance as such, I just need to be able to easily edit those tags without having to use my mouse. Maybe just double-backspacing into a tag-appearance term would convert it back to regular text for editing?
Anyhow, thanks for the response Alex. I'm looking forward to seeing the revised design :)
~ deb
Axel Hecht
>>> Favicon menu
>> This was suggested by mconnor
>
> We should definitely split this out into another thread...do you want
> to start one?
>
>> In this design tagging and bookmarking were separated so mainstream
>> users
>
> I understand that we need to have a way to make bookmarking behave
> exactly as it does now for folks who don't like/know about/understand
> tagging. My issue is with the idea that beltzner brings up that:
>
> 1) Bookmarks are objects that point at locations (this is fine) 2)
> Tags are properties of those locations (this is where I have the
> problem)
>
> In my mind I see it as:
>
> 1) Bookmarks are objects that point at locations 2) Tags are
> properties of those objects
>
The question that I had would be, if I have one location at several
places in my bookmarks, maybe even with edited title, should the two
possibly have different tagsets?
Axel
Alex Faaborg
>> "text" and "notes"? Is this assuming a full-text indexing of all
>> bookmarks/history?
>
> I think so, yeah. Alex?
During the fall summit there was some discussion of adding notes to
Web pages, and making that text searchable. The "Notes" checkbox was
for searching that set of information, assuming we still want to have
that feature. The "Text" search box was for searching the indexed
text of bookmarked pages.
>> * Would tag search be a FAYT system? Being able to filter my tag
>> list down to "Just tags that start with F" by typing a single
>> keystroke into the search field would be useful.
>
> I sure hope so. Performance might kill us here, but we should try.
Yeah, FAYT, and also pressing the down arrow needs to move the focus
out of the text field and into the search, results so the user
doesn't have to move their hand to the keyboard to start exploring
results.
-Alex
Gervase Markham
> But then, if Firefox has changed my folders into tags but I don't
> understand the tagging concept,
The UI looks pretty much the same, though.
> what happens when I delete or rename that
> bookmark that was in both the "good writing" and "hacking" folders?
The same thing as before.
Before, you had two bookmarks; deleting one meant that the other
remained in the other folder.
After, you had two tags; deleting one meant that the page disappeared
from the list of pages with that tag, but remained in the other list.
The UI works pretty much the same. Which is why I think it's possible to
make the migration without throwing people off.
> Maybe
> I actually want two bookmarks for that URL, one with the "hacking" tag and
> one with a "good writing" tag under a different name.
How likely is that? Really and truly?
Gerv
Deb Richardson
> bookmark menu, whereas tagging marks a page such that it can be more
> easily found later (and appears in the "Tagged Pages" smartfolder).
> This
> serves the goal of allowing people to tag more pages than they
> bookmark,
> making it easier to find those pages they found interesting without
> adding a kajillion entries to the Bookmarks hierarchy.
I think these might actually be different problems, causing some conceptual overload.
First problem: A user finds a page interesting and wants to revisit it sometime in the future.
Second problem: A user wants to have only a subset of these interesting pages in her Bookmarks menu.
I think you're possibly conflating the two, so "mark a page as interesting" and "only put a subset of items in my bookmark menu" becomes "mark a page as interesting and put it in the menu" (Bookmarks) and "mark a page as interesting and don't put it in the menu" (Tags).
This said, I think we should clarify the terminology as follows:
1) Bookmark = Mark a page as interesting
2) Tag = Add text labels to a bookmark*
3) Keyword = What keywords are now - text shortcuts usable in the location bar
* For now we'll deal with just bookmarks - this system should extrapolate well to allow tagging of other objects in the future (pointers to downloaded files, history items, etc).
> > In my mind "Bookmarking" means "Recording the location and title of
> a
> > page so I can find it again later", where "Tagging" means "Adding
> > text labels to [something] so I can more easily group, categorize,
> > filter, and find it later".
>
> Yeah, mine, too. Which means that (to me) a tag is a property, and a
> bookmark is an object.
Sure, I'm just saying the tag is a property of the bookmark, not the location.
> Alex and I chatted on IRC about the idea of just making it possible
> for
> bookmarks to not be created in a location, unifying the model into
> something which I think is closer to what you expect. So the user
> would
> create a bookmark, and could add tags to it, and if they placed that
> bookmark in the Bookmark Menu, then it would live there as a
> permanent
> entry; otherwise they'd have to search for it using a search/filter
> UI.
Alternately, allow users to specify which tags/folders/bookmarks they want included in the bookmark menu. So, by default, all bookmarks would be included in the Bookmarks menu as the currently are (carrying over the current model for users who will expect it), but allow users to customize that list. As an example, I might want to have all bookmarks tagged as "menu" in my menu, but nothing else. Or all bookmarks in my "Important" folder, and the "Read Soon" subfolder, etc. This would have to be carefully thought through and designed, of course, but I think the continued "default" behaviour mixed with a decent level of customizability could be a decent and relatively simple win there.
> (It's actually just meant to be marking the page as interesting, or
> starring it, which would promote it in history search results and
> itself
> be a queriable criteria)
Temporary bookmarks might be a different problem again.
> > * No "Cancel" button on tag textbox page. If a user has
> > tagged/starred a page and then goes to add further text tags to it,
> > there's no easy way to just say "oh nevermind, I don't want to add
> > text tags at all". Maybe there should be a cancel button on the
> tag
> > entry textbox dialog?
>
> Agreed. But I think that's what "untag" does.
But in your model "Untag" would imply "Unstarring" rather than "Removing text labels".
> > * Untagging. If a user is on a page that has been previously
> tagged,
> > will the "Tag..." item on the favicon menu become "Untag..."? Or
> > possibly, "Edit tag...", or both?
>
> I would imagine "Edit tag..." and then "Untag". That saves a menuItem
> (which gives a UI angel their wings) and I don't think we're going to
> get a lot of accidental tagging.
Not accidental, but being able to easily unmark-as-interesting pages that I've revisited could be very important. I _often_ bookmark pages "to read later" that, once I've read, I want to un-bookmark. As it stands, I have to wrestle my way through the bookmark manager to do this, which is frustrating and time consuming when really all i want to do is "Star" then "Unstar" (both, ideally, one- or two-click actions) a page.
> > * How can a user add/edit text tags on a previously tagged page?
>
> See above.
Again, modifying text labels and tagging strike me as very different things in the model you have described here.
> > * Inconsistent terminology. ...[snip]... This
> > terminology stuff should probably be discussed and sorted out in
> the
> > near future so we're all in agreement about which means what.
>
> Agreed, and really speaks to the mental model we're going to try to
> promote and get people thinking about.
I'm not sure I understand what you mean here.
> I actually really like your way, though we'll need to take care to
> ensure we don't end up in an endless loop :)
Yah, that's a good point. I expect there's some way to do it, though :)
For what it's worth (which probably isn't much) Wikipedia agrees with my understanding of "Tags" being the actual text labels rather than the flagging of an item as interesting...
http://en.wikipedia.org/wiki/Tag_%28metadata%29
~ deb
Michael Lefevre
> Michael Lefevre wrote:
>> But then, if Firefox has changed my folders into tags but I don't
>> understand the tagging concept,
>
> The UI looks pretty much the same, though.
>
>> what happens when I delete or rename that
>> bookmark that was in both the "good writing" and "hacking" folders?
>
> The same thing as before.
>
> Before, you had two bookmarks; deleting one meant that the other
> remained in the other folder.
>
> After, you had two tags; deleting one meant that the page disappeared
> from the list of pages with that tag, but remained in the other list.
Ok, so that "delete" action is deleting a tag rather than deleting a
bookmark.
Given that, what happens if I then delete the bookmark that is still
showing up in the other list? Would the UI know that I wanted to delete
the bookmark in that case, or would it still remove the tag (so the
bookmark would then show up in the top-level "none" category that you
mentioned)?
If it worked as I might expect as a folder user (deleting the bookmark
when it only had one tag), then if I was a tagging user would I expect it
just to remove the tag (and otherwise how might I remove the tag)?
>> Maybe
>> I actually want two bookmarks for that URL, one with the "hacking" tag and
>> one with a "good writing" tag under a different name.
>
> How likely is that? Really and truly?
Well, I don't consciously do it myself, but I think I recall some people
saying that they did as part of a previous discussion. I guess the number
of people that do that is small enough (and that those people are
technical enough) that they can be expected to read about the changes and
understand them (and maybe even write/download an addon to make things
work differently...)
--
Michael
Alex Faaborg
tagging and bookmarking, I've put together a spectrum of options
ranging from fully separate to fully integrated:
http://wiki.mozilla.org/Places:User_Interface/Tagging_a_Page2
Note that these designs avoid the issue of quickly bookmarking a
page, we can address that separately. Of the four options in the
mockup, I am gravitating toward Option 4, fully integrated. Based on
Deb's comments, I think she will probably like this one the best as
well.
What does everyone else think?
-Alex
Jesper Kristensen
> To help frame the debate over potentially integrating the UI for tagging
> and bookmarking, I've put together a spectrum of options ranging from
> fully separate to fully integrated:
>
> http://wiki.mozilla.org/Places:User_Interface/Tagging_a_Page2
>
> Note that these designs avoid the issue of quickly bookmarking a page,
> we can address that separately. Of the four options in the mockup, I am
> gravitating toward Option 4, fully integrated. Based on Deb's comments,
> I think she will probably like this one the best as well.
>
> What does everyone else think?
>
> -Alex
Option 4: Firefox is asking for a lot of information, the user may think he
has to fill in all the fields.
I would vote for option 2 or 4, but they both have issues.
Alex Faaborg
> bookmark.
Here is how I see deletion working in the design I've proposed:
-Bookmarks in smart folders that represent a single tag gain a menu
item "Remove Tag: 'tagname'"
-Bookmarks in smart folders that represent a saved search gain a menu
item "Remove"
-All bookmarks have a menu item "Delete" that completely deletes the
bookmark
Adding an additional command bloats the interface, but I don't like
overloading "Delete" to mean different things in different contexts.
-Alex
Gervase Markham
> Given that, what happens if I then delete the bookmark that is still
> showing up in the other list? Would the UI know that I wanted to delete
> the bookmark in that case, or would it still remove the tag (so the
> bookmark would then show up in the top-level "none" category that you
> mentioned)?
>
> If it worked as I might expect as a folder user (deleting the bookmark
> when it only had one tag), then if I was a tagging user would I expect it
> just to remove the tag (and otherwise how might I remove the tag)?
That's a good point. The mapping is not perfect.
But isn't this a general problem for tagging? Tag people: how do I get
the tagging system to completely forget I ever tagged a page? Does
deleting the last tag do it?
Gerv
Gervase Markham
>> Ok, so that "delete" action is deleting a tag rather than deleting a
>> bookmark.
>
> Here is how I see deletion working in the design I've proposed:
> -Bookmarks in smart folders that represent a single tag gain a menu item
> "Remove Tag: 'tagname'"
> -Bookmarks in smart folders that represent a saved search gain a menu
> item "Remove"
> -All bookmarks have a menu item "Delete" that completely deletes the
> bookmark
What does the Delete key do in each case, when the item is selected?
Gerv
Gervase Markham
> I understand that we need to have a way to make bookmarking behave
> exactly as it does now for folks who don't like/know about/understand
> tagging. My issue is with the idea that beltzner brings up that:
>
> 1) Bookmarks are objects that point at locations (this is fine)
> 2) Tags are properties of those locations (this is where I have the problem)
>
> In my mind I see it as:
>
> 1) Bookmarks are objects that point at locations
> 2) Tags are properties of those objects
How about:
1) Bookmarks are properties of locations (with the property being a
generic "I'm interested")
2) Bookmark folders are properties of locations (that say something
about the location, or more about the reason for my interest)
3) Tags are also properties of locations (that say something about the
location, or more about the reason for my interest)
I think this is a better way to unify the model.
Why do people bookmark? Because they are interested in a site, and want
to remember where it is so they can visit it again.
Why do people put bookmarks in folders? Because a big list of "I'm
interested" gets unwieldy; they want to group and categorise.
Why might people tag? Because a big list of "I'm interested" gets
unwieldy; they want to group and categorise.
Gerv
Gervase Markham
> The question that I had would be, if I have one location at several
> places in my bookmarks, maybe even with edited title, should the two
> possibly have different tagsets?
It's a valid question. But there's another important, related question:
is your question a question anyone who does not subscribe to this
newsgroup would ever ask? In other words, isn't it true that only a
very, very small number of people bookmark a site twice and edit the
title on one copy?
Gerv
Gervase Markham
> I think you're possibly conflating the two, so "mark a page as
interesting" and "only put a subset of items in my bookmark menu"
becomes "mark a page as interesting and put it in the menu" (Bookmarks)
and "mark a page as interesting and don't put it in the menu" (Tags).
Except that the tag viewing UI mockup looks awfully like bookmark folders.
And there's a further subdivision for bookmarks - "put it in the menu",
and "put it in the menu and on the bookmarks bar".
In other words, both the menu and the bar could be thought of as showing
a set of all bookmarks. It just happens that currently the menu always
shows the entire set, and the bar generally doesn't.
Gerv
Gervase Markham
> To help frame the debate over potentially integrating the UI for tagging
> and bookmarking, I've put together a spectrum of options ranging from
> fully separate to fully integrated:
>
> http://wiki.mozilla.org/Places:User_Interface/Tagging_a_Page2
Small whinge: is there any way you can do such mockups while making a
greater percentage of the text actually text? The current versions are
both ungreppable and inaccessible.
Here's Option 5.
When the new Firefox is installed, we've migrated the bookmarks from a
hierarchy to a set, but with each bookmark tagged with tag(s)
corresponding to the name of the folder(s) it was in. We then have
available the tree-based tagging UI which you mocked up in another page,
which comes out looking rather like the current hierarchical bookmarks
view (because the tag names are the old folder names), so that people
aren't lost.
Then, when the user goes to Add Bookmark, it's like option 4 except that
there's no "Create in:" line in the dialog. OK is highlighted so someone
can quickly just hit "Enter" and have a bookmark with no tags (which has
a special category in the tag view).
The text below is:
Use tags to organise bookmarks.
Separate tags with commas.
E.g. religion, politics, death
Gerv
Sailfish
> I've been spending some time recently on Places UI, and I just uploaded
>
> Let's use this thread for discussion,
>
the motivational benefit of tagging is for most users. As near as I can
tell, it offers the user another way of contextualizing saved bookmarks
so that they may be able to be more readily found at some later point?
It is with that assumption that I base my following critique.
First, while this promises to offer the user a more expansive way of
finding bookmarks and, implicitly, may remove the need to manually
organize bookmarks into appropriate folders, the tagging process itself
is a manual exercise. For new bookmarks, this may not be too difficult
but for all of the existing bookmarks, most users will not want to go
through the tedious process of back-tagging them, especially those who
have accumulated hundred of bookmarks over the years.
After thinking about this a bit, something occurred to me that might
make this feature much more useful. Why not do what Google does and
(optionally) auto-tag bookmarks based on what's in the page's title,
meta-tags, and perhaps other areas? Of course, manual tagging could
still be allowed in the event that the user determined that a search
using his criteria didn't find a bookmark that they expected but I
suspect this would be the exception rather than the rule. It could even
allow the user to exclude bookmarks that met some criteria (maybe via a
bookmark checkbox?) where they didn't want it to.
PROs
----
o No need to manually back-tag existing bookmarks
o Reduces the need to manually add tags
o Increases the 'hit' rate on bookmarks that would meet some criteria
o Potentially, reduces the UI design
o Easier to 'sell' to the users
CONs
----
o Increases the size of the bookmarks file, perhaps substantially
o Adds to net traffic
o Others?
--
Sailfish - Netscape/Mozilla Champion
Netscape/Mozilla Tips: http://www.ufaq.org/ , http://ilias.ca/
mozilla-based Themes: http://www.projectit.com/freestuff.html
Deb Richardson
> well.
Yes, of those I do prefer Option 4, but I'm not sure why tagged bookmarks would be forced into a specific smart folder. Why would I not be able to create a bookmark, put it in my "LOLCats" folder, and *also* tag it as "cute, walrus, bucket"?
(Aside: This is, of course, assuming that we want both folders and tags which is arguable, but understandable.)
So I think the four major things we want to do are:
1) Allow users to create and delete bookmarks with a single action.
This would be "quickmarks", or "starring". This is what I think you are thinking of when you talk about "tagging" a location. The action could be a click, or a shortcut key, or somesuch.
2) Allow users to create bookmarks in folders as they currently do.
This would be so we do not freak anyone out by forcing a new model on people who are perfectly comfortable with the present system.
3) Allow users to add tags to bookmarks (regardless of folder location).
This way users can, if they like, ignore foldering altogether (dump all bookmarks in a single folder and use tags to sort through them), have a combination of foldering and tagging, or ignore tagging altogether.
4) Allow users to specify what does or does not show up in their bookmarks menu.
This could be accomplished in a number of ways. Default would be to simply continue with the current system where all bookmarks in all folders are included in the menu. That could be customizable, however, so (as I described in an earlier post) any one or set of tags/folders/smartfolders could be included in that menu. Etc.
~ deb
Alex Faaborg
> "LOLCats" folder, and *also* tag it as "cute, walrus, bucket"?
You can (although it is a little quirky). In Option 4, the folder
location changes to "Bookmarks > Tags" only if you don't change the
default location, and even after it changes you can still modify it
by selecting a folder. This is kind of unusual behavior, but was the
only way I could think of directly integrating the two UIs in a way
that allows you to:
1) Place a bookmark in a specific folder
2) Tag a bookmark
3) Tag a bookmark AND place it in a specific folder
The downside of this design is:
1) If it changes to "Bookmarks > Tags" users may think they can't
change it to something else.
2) if you do edit "Bookmarks > Tags" to another folder, the bookmark
will still be placed in the appropriate smart folders in the Tags
smart folder, and this isn't clear. I should probably tweak the
mockup to make this more clear in cases where you both tag and folder.
-Alex
Robert Kaiser
> -Bookmarks in smart folders that represent a single tag
Umm, just as a note, nested bookmark folders are still supported in the
concept, right? I have a well-thought-through structure of nested
bookmark folders, and it would be a shamed if I would need to something
that feels less organized when eventually changing to places...
Robert Kaiser
Robert Kaiser
> After thinking about this a bit, something occurred to me that might
> make this feature much more useful. Why not do what Google does and
> (optionally) auto-tag bookmarks based on what's in the page's title,
> meta-tags, and perhaps other areas?
The "keywords" meta tag comes to my mind here, it's probably quite
similar to what tags mean...
Robert Kaiser
Alex Faaborg
organize information into hierarchies. In my proposal for changes to
the bookmarks menu/sidebar we add a smart folder called "Tags" which
contains a smart folder for each recently used tag, but you could
drag these out into your own nested structure. Or while creating
your organizational hierarchy you could create a new smart folder
that will display all pages with a particular tag, basically a "saved
search."
-Alex
Alex Faaborg
> what
> the motivational benefit of tagging is for most users
So far the best explanation I've found of why users like tagging
interfaces is this blog post, A Cognitive Analysis of Tagging: http://
www.rashmisinha.com/archives/05_09/tagging-cognitive.html
> Why not do what Google does and
> (optionally) auto-tag bookmarks based on what's in the page's title,
> meta-tags, and perhaps other areas?
Having the user manually enter tags is more work, but that work makes
the tags they enter more memorable, which helps with retrieval later.
I think we should do this non-optionally in the background to improve
search. As for displaying these types of automatically generated
tags in Bookmarks > Tags, I'm worried that might cause the user to be
confused if any tags are inaccurate, or feel like they don't have a
lot of control over the application.
Perhaps we should consider this type of feature when we get around
designing the bookmarks organizer interface? If we don't do it
ourselves, I can see a lot of extensions coming out to add tags to
existing bookmark collections, similar to the set of applications
available to clean up ID3 tags on MP3 files.
-Alex
Sailfish
>> In reading the discussions on this thread I've tried to understand what
>> the motivational benefit of tagging is for most users
>
> So far the best explanation I've found of why users like tagging
> interfaces is this blog post, A Cognitive Analysis of Tagging:
> http://www.rashmisinha.com/archives/05_09/tagging-cognitive.html
>
purpose of tagging is for subsequent ease of retrieval, unless there is
some additional benefits/objectives in the Fx implementation not
discussed in that article?
I accept the benefit of tagging, even the more laborious self-tagging.
I've already done this in a somewhat unstructured manner by adding tags
to my bookmark name fields (in addition to storing them in meaningful
folder/sub-folders), thus, affording me the benefit of them being found
via the search textbox. A structured approach for this would be of some
benefit for future bookmarking, though.
>> Why not do what Google does and
>> (optionally) auto-tag bookmarks based on what's in the page's title,
>> meta-tags, and perhaps other areas?
>
> Having the user manually enter tags is more work, but that work makes
> the tags they enter more memorable, which helps with retrieval later.
>
Sure, but so did taking notes in class, and most of us slackers
intuitively knew this, but chose to be lazy and rely on our photographic
memories (NOT!) for accurate retrieval. I suspect that this
functionality may end up being used mostly by the rigorous net
users/researchers while the great unwashed slackers will continue to
fool themselves into trusting their memory rather than lift a finger to
give their synapses an assist.
Admittedly, even if only a very small percentage of the install-base
uses it, that could be a very substantial number of users who will
praise the added feature.
> I think we should do this non-optionally in the background to improve
> search. As for displaying these types of automatically generated tags
> in Bookmarks > Tags, I'm worried that might cause the user to be
> confused if any tags are inaccurate, or feel like they don't have a lot
> of control over the application.
>
Thinking about it a bit more, I'd agree. Many sites tend to overload
their meta-tags with every conceivable word/phrase and even, to quote
Vizzini, "Inconceivable!" ones. Maybe allowing them to selectively
exclude bookmarks when they match a search criteria would be best?
> Perhaps we should consider this type of feature when we get around
> designing the bookmarks organizer interface? If we don't do it
> ourselves, I can see a lot of extensions coming out to add tags to
> existing bookmark collections, similar to the set of applications
> available to clean up ID3 tags on MP3 files.
>
Okay.
Dan Mills
> It's a valid question. But there's another important, related question:
> is your question a question anyone who does not subscribe to this
> newsgroup would ever ask? In other words, isn't it true that only a
> very, very small number of people bookmark a site twice and edit the
> title on one copy?
No, it's not true. Here's a few reasons why:
* Users who use microsummaries may also bookmark the site separately.
You can't set the title on the microsummary or it overrides the
generated title.
* A user may rename a bookmark on their bookmarks toolbar to reduce it's
footprint (since real estate there is quite limited), but wish to retain
the full title on another copy in the menu.
* Bookmarks can contain POST data. So a user might want to have two
copies of the same URL with different titles to differentiate them in
that case.
Dan
Peter Lairo
> Gervase Markham wrote:
>
>> isn't it true that only
>> a very, very small number of people bookmark a site twice and edit the
>> title on one copy?
I have no idea how large or small this number might be. I do know that I
am one of these people and that I rely on being able to have two
bookmarks for the same URL - for the reason given below...
> * A user may rename a bookmark on their bookmarks toolbar to reduce it's
> footprint (since real estate there is quite limited), but wish to retain
> the full title on another copy in the menu.
+1
On a related note: Google needs different icons for its various services.
--
Regards,
Peter Lairo
The browser you can trust: www.GetFirefox.com
Reclaim Your Inbox: www.GetThunderbird.com
Mike Beltzner
> ----- "Alex Faaborg" <faab...@mozilla.com> wrote:
>
> > ...I am gravitating toward Option 4, fully integrated. Based on
> > Deb's comments, I think she will probably like this one the best as
> > well.
>
> Yes, of those I do prefer Option 4, but I'm not sure why tagged bookmarks would be forced into a specific smart folder. Why would I not be able to create a bookmark, put it in my "LOLCats" folder, and *also* tag it as "cute, walrus, bucket"?
I agree competely with this. I think that the intent here was to make
it possible to create the bookmark without placing it in a folder that
appears in the menu, but the resulting design ended up being more
confusing.
The simplest way to do this would be to either place a checkbox
(default on) next to the "Create in" UI and maybe change the label to
"Create shortcut" with the list of destinations. Or add a "no
shortcut" option to the menu.
The more I think about this, the more I think Deb's right in an
assertion (see below) that what we really want to do is support a
"Quickmark" action which *doesn't* create shortcuts in the bookmark
menu, and whenever someone selects traditional "Bookmark" operations
(using accel-D, menuItem, whatever) that they should just see the
traditional bookmarking UI with the new ability to tag things.
> (Aside: This is, of course, assuming that we want both folders and tags which is arguable, but understandable.)
I think we do. I fear the clutter that occurs when a UI moves to a tag
= folder system (which is what I think I see Gerv proposing, and what
the del.icio.us extension does). It doesn't seem like a good way to
solve the problem of having too many bookmarks, and the benefit of
tags is the ability to search and filter on them, not the ability to
navigate even more complex and random hierarchies.
> So I think the four major things we want to do are:
>
> 1) Allow users to create and delete bookmarks with a single action.
>
> This would be "quickmarks", or "starring". This is what I think you are thinking of when you talk about "tagging" a location. The action could be a click, or a shortcut key, or somesuch.
Agreed, and this is, I think, the insight I was missing. Some quick
action that simply marks the page as interesting, to be remembered
(and not auto-expired from history), to be promoted when searching
history and included when searching bookmarks, and to optionally be
tagged.
> 2) Allow users to create bookmarks in folders as they currently do.
>
> This would be so we do not freak anyone out by forcing a new model on people who are perfectly comfortable with the present system.
This is *essential*, yes.
> 3) Allow users to add tags to bookmarks (regardless of folder location).
>
> This way users can, if they like, ignore foldering altogether (dump all bookmarks in a single folder and use tags to sort through them), have a combination of foldering and tagging, or ignore tagging altogether.
I've been using "tag" as a verb recently, which is a terminology
failure on my part. Yes, we should think of a tag as the label, the
text, the thing, which can be applied to any object. They should be
properties that can be added to a bookmark.
> 4) Allow users to specify what does or does not show up in their bookmarks menu.
>
> This could be accomplished in a number of ways. Default would be to simply continue with the current system where all bookmarks in all folders are included in the menu. That could be customizable, however, so (as I described in an earlier post) any one or set of tags/folders/smartfolders could be included in that menu. Etc.
I think the easiest solution here is to just say that, by default,
Quickmarked items aren't added to the menu, and to add a "don't add to
menu" option to the "Create in" drop-down of the bookmarking UI.
Great summary, Deb. This really helped a lot.
cheers,
mike
Deb Richardson
> Quickmarked items aren't added to the menu, and to add a "don't add
> to
> menu" option to the "Create in" drop-down of the bookmarking UI.
Not 100% sure I agree with this, because if a "quickmark" is a bookmark (which it really is) then users who are accustomed to finding bookmarks in their bookmark menu might be befuddled by their lack.
I'd instead suggest having a "Quickmarks" smartfolder included on the menu where, instead of being left off the menu entirely, they're nicely encapsulated in a folder of their own.
Beyond that I think we're largely in agreement at this point. :)
` deb
Mike Connor
On 18-May-07, at 11:51 AM, Deb Richardson wrote:
>> I think the easiest solution here is to just say that, by default,
>> Quickmarked items aren't added to the menu, and to add a "don't add
>> to
>> menu" option to the "Create in" drop-down of the bookmarking UI.
>
> Not 100% sure I agree with this, because if a "quickmark" is a
> bookmark (which it really is) then users who are accustomed to
> finding bookmarks in their bookmark menu might be befuddled by
> their lack.
>
> I'd instead suggest having a "Quickmarks" smartfolder included on
> the menu where, instead of being left off the menu entirely,
> they're nicely encapsulated in a folder of their own.
The problem here is that it'll get huge really really quickly, and
become unusable (that, or its too hard to quickmark and people aren't
doing it much). We had this discussion around starring last time as
well, iirc. As long as the UI is understandable as beltzner
suggested, I don't think there will be befuddlement at all.
-- Mike
Deb Richardson
> become unusable (that, or its too hard to quickmark and people aren't
>
> doing it much). We had this discussion around starring last time as
>
> well, iirc. As long as the UI is understandable as beltzner
> suggested, I don't think there will be befuddlement at all.
So, after creating a Quickmark, how would users revisit that page? What does that interaction look like if the Quickmarked pages aren't in the menu, bookmark toolbar, etc?
~ deb
Gervase Markham
> After thinking about this a bit, something occurred to me that might
> make this feature much more useful. Why not do what Google does and
> (optionally) auto-tag bookmarks based on what's in the page's title,
> meta-tags, and perhaps other areas?
Wouldn't this have the same problem that meta-tags had with search
engines? I.e. people don't act honestly, and try and fiddle the tags to
game the system (perhaps by giving their book selling site an "amazon" tag)?
Gerv
Sailfish
key words/phrases? It's likely the web designer would insure the most
pertinent ones would be there.
I wouldn't expect the code to be too sophisticated in culling "gaming"
keywords since it may add to bloat in doing so.
mcdav...@netscape.net
I'd be really happy seeing this as a starting point, with these values
(from the meta-tags) filled in, for me to edit and override.
Gervase Markham
> I'd be really happy seeing this as a starting point, with these values
> (from the meta-tags) filled in, for me to edit and override.
The problem with that is that if you just hit "Enter" (which is
something we should allow) then the defaults get accepted.
Gerv
Mike Shaver
No, I think we've seen that it's pretty common for people to have some
of their bookmarks copied into the bookmark toolbar, where they get
cryptic-but-compact titles like [$] for their online banking,
initialisms, etc. See also live titles, which are used almost
exclusively in the toolbar, but which may duplicate another "normal"
bookmark elsewhere in the hierarchy. And when you start sharing your
bookmarks with other people, or integrating services like del.icio.us,
I think the likelihood of multiple bookmarks with the same target URL
increases dramatically.
I suspect that it's also not that uncommon for people who have large
bookmark sets to bookmark the same page twice, and edit them
distinctly (likely because they don't even know that they have two
bookmarks for the same place). Perhaps we should be endeavouring to
help users grasp the totality of their tagged/bookmarked web set such
that they don't make dups, but I wouldn't want to make many UI
decisions predicated on the assumption that we'll manage to eliminate
that case/problem.
Mike
Alex Faaborg
discussion going on. Here is a fresh mockup for bookmarking and
tagging, based on previous discussions. This mockup also introduces
one click bookmarking (also sometimes called starring, quickmarks).
http://wiki.mozilla.org/Places:User_Interface/Tagging_a_Page3
-Alex
On May 25, 2007, at 6:40 AM, Mike Shaver wrote:
> On 5/17/07, Gervase Markham <ge...@mozilla.org> wrote:
> No, I think we've seen that it's pretty common for people to have some
> of their bookmarks copied into the bookmark toolbar, where they get
> cryptic-but-compact titles like [$] for their online banking,
> initialisms, etc. See also live titles, which are used almost
> exclusively in the toolbar, but which may duplicate another "normal"
> bookmark elsewhere in the hierarchy. And when you start sharing your
> bookmarks with other people, or integrating services like del.icio.us,
> I think the likelihood of multiple bookmarks with the same target URL
> increases dramatically.
>
> I suspect that it's also not that uncommon for people who have large
> bookmark sets to bookmark the same page twice, and edit them
> distinctly (likely because they don't even know that they have two
> bookmarks for the same place). Perhaps we should be endeavouring to
> help users grasp the totality of their tagged/bookmarked web set such
> that they don't make dups, but I wouldn't want to make many UI
> decisions predicated on the assumption that we'll manage to eliminate
> that case/problem.
>
> Mike
Jesper Kristensen
> I've been neglecting the places thread with all the content handling
> discussion going on. Here is a fresh mockup for bookmarking and
> tagging, based on previous discussions. This mockup also introduces one
> click bookmarking (also sometimes called starring, quickmarks).
>
> http://wiki.mozilla.org/Places:User_Interface/Tagging_a_Page3
Great.
The only thing i don't like is that the favicon is now a button instead of a
menu. It is not obvious that this button is for bookmarking. Can it be
changed back to a menu with one of the items called "Bookmark this page" or
something like that?
What if the user chooses to bookmark a page using a keyboard shortcut or the
bookmarks menu? Will the bookmarking UI still be linked to the favicon?
Michael Vincent van Rantwijk, MultiZilla
> I've been spending some time recently on Places UI, and I just uploaded
> two mockups here: http://wiki.mozilla.org/Places:User_Interface
>
> Let's use this thread for discussion,
>
Have you looked at FireSpook? I mean, my father developed something
VERY similar back 2005 for his employer (I have forwarded the links/mock
ups to see what they have to say about it).
Michael
Gervase Markham
> I've been neglecting the places thread with all the content handling
> discussion going on. Here is a fresh mockup for bookmarking and
> tagging, based on previous discussions. This mockup also introduces one
> click bookmarking (also sometimes called starring, quickmarks).
>
> http://wiki.mozilla.org/Places:User_Interface/Tagging_a_Page3
Just as a suggestion, it might be best if new mockups went into new
top-level threads, with a subject line like "FooBar mockup, version X"?
- I assume Ctrl-D will also bring down the "Page Bookmarked" dialog?
- Does this dialog go away if ignored? There's no "close" or "OK". Might
it be better to make it wider and thinner to cover less important stuff?
Page Bookmarked
Firefox will remember that you visited this page. [Organise] [Remove]
- What happens if the user chooses not to "create a shortcut"? Is a
shortcut a bookmark as we know it today?
- There seem to be two ways to select the folder in which to put the
shortcut - either the dropdown arrow on the top box, or the larger box
below. How does that work?
- How do you choose which tags to offer in the expanded tag view?
Gerv
ja...@mozilla.com
> shortcut a bookmark as we know it today?
>
> - There seem to be two ways to select the folder in which to put the
> shortcut - either the dropdown arrow on the top box, or the larger box
> below. How does that work?
Apologies for dive-bombing... but when looking *only* at the latest
mockup, I had no idea what "create a shortcut" was. I kind of thought
bookmarking == creating a shortcut. I'm assuming other users will as
well.
I'm guessing that technically it means to tag a bookmarked page as
belonging in a folder. If that's the case, I'd suggest something more
explicit like "put in folder," which seems to fit under the "organize"
rubric better anyway.
Alex Faaborg
Agreed, if we go with this design the button should have some type of
bookmark image on it. Also, the current proposal to change the
location bar removes the favicon from the URL bar entirely (so the
site can't display a lock icon, etc.).
> What if the user chooses to bookmark a page using a keyboard
> shortcut or the
> bookmarks menu? Will the bookmarking UI still be linked to the
> favicon?
I think this makes more sense than having a separate pop-up window.
Cntl-d and "bookmark page" should display the expanded version of the
dialog with "create shortcut" checked. Also, if we have separate
commands (keyboard shortcut or bookmarks menu item) for tagging,
these would also display the expanded dialog, and the tag text field
would have the focus.
-Alex
Alex Faaborg
> top-level threads, with a subject line like "FooBar mockup, version
> X"?
I want to keep everyone in the same thread so comments on old threads
don't continue after the UI issues have already been addressed.
Also, I want a single URL to all conversations on the UI of each
major user facing feature for a post I'm about to push to planet.
You can see the mockups in order of version here though: http://
wiki.mozilla.org/Places:User_Interface
> - Does this dialog go away if ignored? There's no "close" or "OK".
> Might
> it be better to make it wider and thinner to cover less important
> stuff?
Similar to the notification redesign, this dialog goes away on any
mouse click outside of it, like a context menu.
> - What happens if the user chooses not to "create a shortcut"? Is a
> shortcut a bookmark as we know it today?
I'm still working on the latest version of the sidebar mockup, but
the plan is to place these pages in a pre-populated smart folder,
which is probably called "Unorganized bookmarks." I should add a
sentence in the first state of the dialog to tell the user how they
can get back to the bookmark.
> - There seem to be two ways to select the folder in which to put the
> shortcut - either the dropdown arrow on the top box, or the larger box
> below. How does that work?
This is the same as the current dialog box to create a bookmark.
> - How do you choose which tags to offer in the expanded tag view?
All the tags the user has previously used will appear here. We could
rank these alphabetically, by recency, or by popularity. Probably a
combination of the later two methods would work best.
-Alex
dusa...@gmail.com
> To help frame the debate over potentially integrating the UI for
> tagging and bookmarking, I've put together a spectrum of options
> ranging from fully separate to fully integrated:
>
> http://wiki.mozilla.org/Places:User_Interface/Tagging_a_Page2
>
> Note that these designs avoid the issue of quickly bookmarking a
> page, we can address that separately. Of the four options in the
> mockup, I am gravitating toward Option 4, fully integrated. Based on
> Deb's comments, I think she will probably like this one the best as
> well.
>
>
> -Alex
>
I think that this discussion have in a way suffered from the typical
profile of the participants.
Hence my entry, to account for the more stubborn and less fashionable
users...
I find the whole theory of "tagging" in Web2.0 "style" just a fashion.
Actually there are
huge groups of users for whom tagging is just unneccessary complexity
and (as are most
of the participants here) huge groups of users who do actually benefit
(or want to beleive so)
from this mechanism.
Hence I see "Option 1" or variation on that theme as the most viable.
Bookmarks and Tags should be
completely separate concepts. This gives perfect conditions not only
to the typical
"old fashioned" users and "web 2.0" users but to the people "in
between" who can experiment
with the new concept without disturbing their old and set ways.
Also, I'd hate to switch to Firefox 3 and have my bookmarks messed-
with. Simple text format
(editable by Notepad, or Emacs or alike) and no automatic tagging. If
one wants to Tag,
great, provide a tool to convert bookmarks to Tags, but do not force
it down the users throats...
Please do have in mind that although the Tags concept is fashionable,
not everyone benefits from it.
My personal example: after two years with the Gmail, I still hate its
"no folders" tagging
interface and would in a second go back to the folders if given an
option. I am sure I am not
the only one.
Hope this helps diversify this discussion,
Dusan Maletic
Mark
> I've been neglecting the places thread with all the content handling
> discussion going on. Here is a fresh mockup for bookmarking and
> tagging, based on previous discussions. This mockup also introduces
> one click bookmarking (also sometimes called starring, quickmarks).
>
> http://wiki.mozilla.org/Places:User_Interface/Tagging_a_Page3
>
> -Alex
I like a lot of the things that Alex is proposing in these mockups,
but if there's going to be a "dropdown" associated with the page icon,
I think there's an opportunity to clarify the source of the page and
the security information.
My own mockups, heavily influenced by Alex's, are at:
http://wiki.mozilla.org/Markc:Firefox_3.0_UI_Mockups
Mark
Deb Richardson
http://wiki.mozilla.org/User:Dria/Places_Mockups
Currently included are notes/mockups for:
* One-click bookmarking
* Bookmark sidebar enhancements
* Bookmark toolbar enhancements
Alex: did you want these just added directly to the mockups page?
~ deb
Gervase Markham
> Currently included are notes/mockups for:
>
> * One-click bookmarking
I like the Flock-style star idea. The accessibility problem could be
solved by having a small white centered star in the unbookmarked form,
and making it bigger in the bookmarked form. So the icon changes form as
well as colour.
Gerv
Alex Faaborg
left of the location bar. Here are some of his mockups:
http://blog.johnath.com/index.php/2007/06/04/will-firefox-have-a-
green-bar/
Personally I don't think we should directly integrate security UI and
bookmarking UI into the same drop down. But I think it would make
sense for them to each have a button in primary UI. Mike Beltzner
suggested that larry in the security button could be looking at the
favicon, which is used for bookmarking. Of course, similar to using
a lock favicon, this could lead to two larrys pointing at each other,
each trying to convince you that they are the real larry :)
Alex
____________________
Open source UI design:
http://wiki.mozilla.org/Mockups
Alex Faaborg
Yeah, this way people can view all of the mockups without having to
read the entire discussion thread, and we have a faster way of
getting back to them.
> * One-click bookmarking
I like the Flock star, although I think it has a few usability issues
(beyond the accessibility issues you raised)
-It isn't at all clear that a second click will produce additional
options. A lot of users will expect the second click to clear the
star back to the original state. Additionally, a lot of novice users
double click everything since they are not sure what targets on their
screen are supposed to receive single clicks or double clicks, and
double clicking always seems to work. For these people, they will
always get the heavy weight interface.
-The interface it produces on the second click is a little more
complicated than it needs to be (in particular, I think both the
address and description don't need to be there).
Also, I'm not entirely sure if we should switch to using stars for
bookmarking. This would be consistent with IE and the Google
toolbar, but traditionally Netscape and Firefox have literally had
"bookmarks" both in terminology and icon design. For consistency, we
may want to keep bookmarks bookmarks. Also, if we visually represent
bookmarks as stars (like the Google toolbar) we start mixing metaphors.
> * Bookmark sidebar enhancements
I think we should minimize access to the advanced search
functionality in primary UI, but still have some way of getting to it
from the sidebar so that the user is able to create saved searches.
I like showing if pages are bookmarked or not when searching
history. I'm not sure what specific use cases the "files downloaded
from this site" icon enables.
> * Bookmark toolbar enhancements
I like adding a button to the far left of the bookmarks toolbar.
Although instead of opening a menu, I think it should display the
bookmarks sidebar (similar to IE7 and Safari). I think things like
"newest bookmarks", "recently visited bookmarks" and "most visited
bookmarks" would make more sense as pre-populated Smart Folders in
the bookmarks sidebar. This will both demonstrate what types of
things the user can do with smart folders, and put them in control of
moving or deleting them if they don't need them (like the pre-
populated getting started bookmarks).
Alex
____________________
Open source UI design:
http://wiki.mozilla.org/Mockups
On Jun 4, 2007, at 1:29 PM, Deb Richardson wrote:
> I've cobbled together some additional mockups based on various
> ideas that have been floating around...you can find them here:
>
> http://wiki.mozilla.org/User:Dria/Places_Mockups
>
> Currently included are notes/mockups for:
>
> * One-click bookmarking
> * Bookmark sidebar enhancements
> * Bookmark toolbar enhancements
>
> Alex: did you want these just added directly to the mockups page?
>
> ~ deb
>
Gervase Markham
> Additionally, a lot of novice users double
> click everything since they are not sure what targets on their screen
> are supposed to receive single clicks or double clicks, and double
> clicking always seems to work. For these people, they will always get
> the heavy weight interface.
I keep hearing this argument presented, but I continue to think it's a
false one. If the user's underlying OS makes a distinction between
single and double clicks (and I believe they all do) then we do no-one
any favours by pretending there isn't one in our UI - we are just adding
to their confusion. All we do is reduce our UI options. Users who think
there isn't one need to be told otherwise, or they'll just end up not
being able to work their computers properly.
Obligatory car analogy: a road designer wants to make signs visible and
clear, junctions easy to understand, etc. etc. But if the driver doesn't
know the difference between left and right, it's not a good idea to make
every road completely straight just so they don't have to use the
steering wheel.
> I like adding a button to the far left of the bookmarks toolbar.
> Although instead of opening a menu, I think it should display the
> bookmarks sidebar (similar to IE7 and Safari).
I continue to think the sidebars should appear on the right rather than
the left. Much less disruption to the content, and no disconnect between
Forward/Back and the content it refers to.
Gerv
Alex Faaborg
> single and double clicks
Right, we could detect a double click to turn the star on, instead of
turning the star on and then turning it off again (which wouldn't
help anyone). But in this particular case a single click turns the
star on, and a double click turns the star on and also produces a
dialog box, which is just weird.
-Alex
Deb Richardson
So, instead of popping up the "Page Bookmarked" mini-dialog as in the second part here...
http://wiki.mozilla.org/Places:User_Interface/Tagging_a_Page3
...we would just change the appearance of whatever the bookmarking icon ended up being -- maybe a book changes to a book with a bookmark in it or somesuch. I hadn't really delved into the specifics at this point -- my mockups are meant to be more rough sketches than precisely detailed specs :)
As for metaphors, I've never been a huge fan of the "bookmark" thing since the web is in no way a "book". I understand wanting to maintain consistency so as to not confuse users overmuch, but I don't think we should be afraid of changing that metaphor due to simple tradition.
I also don't find the "one-click star, second-click open dialog" thing to be particularly weird. It did surprise me the first time I did it (as you suggested, I expected the second click to turn the star off), but after doing it once or twice I learned the new behaviour and it became entirely second-hand and comfortable. Are we unable to introduce new interactions like that to users?
~ deb
Mark
>
> Personally I don't think we should directly integrate security UI and
> bookmarking UI into the same drop down. But I think it would make
> sense for them to each have a button in primary UI.
I don't see it as "security UI" so much as "useful information to help
the user to make an informed decision". Carrying a summary of the
security information about a page might help to inform a user as to
whether or not they want to carry on with the bookmarking operation.
In my experience people tend to be very trusting of their bookmarks.
"I bookmarked it, therefore the site must be okay". If bookmarking is
a simple process - perhaps down to one or two clicks - then there's
more likelihood of rogue sites slipping into people's bookmarks by
mistake and being trusted ever after.
A real-life example is Gmail. They have both an http and an https
interface, and depending on what route you take to get to the site,
it's possible to get switched away from the secure version without
noticing. When adding a bookmark for Gmail I'd like a more obvious
indication of which version of the site I'm on.
> Mike Beltzner
> suggested that larry in the security button could be looking at the
> favicon, which is used for bookmarking. Of course, similar to using
> a lock favicon, this could lead to two larrys pointing at each other,
> each trying to convince you that they are the real larry :)
After posting my mockups I considered that the favicon would probably
be better associated with the bookmark controls than the security
information for precisely this reason (though I haven't got round to
editing the images yet).
By including the security information in a fixed and consistent
location (e.g. at the top of the popup), users should hopefully become
accustomed to seeing Larry or a lock icon in the same obvious place.
Using an open lock, or a crossed out Larry to denote an absence of
security information is also important - the best that an favicon
spoofer could hope for then is to end up with two contrary icons,
which in itself should raise some alarm bells. Ensuring that Larry,
the lock, or any other security icons are significantly bigger than
the favicon should also make it harder for that kind of spoofing to
have any real effect.
Personally I'd prefer to see the popup not as "security UI" or
"bookmarking UI", but as "things to do with the URL UI". Security
information would be ever-present, but beyond that I don't see any
reason why bookmarking should be more special than blogging, emailing
a link, or any other operation that an extension author might want to
perform with the URL. Taking it to the extreme means that you can
either have lots of separate icons in primary UI, each with a single
specific popup, or you keep the additional primary UI to a minimum by
allowing the secondary UI to be extended instead.
Gervase Markham
> I don't see it as "security UI" so much as "useful information to help
> the user to make an informed decision". Carrying a summary of the
> security information about a page might help to inform a user as to
> whether or not they want to carry on with the bookmarking operation.
>
> In my experience people tend to be very trusting of their bookmarks.
> "I bookmarked it, therefore the site must be okay". If bookmarking is
> a simple process - perhaps down to one or two clicks - then there's
> more likelihood of rogue sites slipping into people's bookmarks by
> mistake and being trusted ever after.
That's possibly true. But how many people get phished on their second or
subsequent visit to a site? Once you've been there and trusted it enough
to even press the Bookmark button, you've probably lost already. So I
don't think this is a worry.
Gerv
Mark
> Once you've been there and trusted it enough
> to even press the Bookmark button, you've probably lost already.
I know what you mean, but it's not that clear cut. If you visit a
phishing site and provide some credentials, then yes you've lost long
before you reach the bookmark button. But what about if you bookmark
the "login" page with the intention of going back later to enter your
details? And whilst a malware site might prove to be innocuous when
the user's anti-virus is up-to-date, that doesn't mean it's still safe
in a month when they've let their subscription lapse.
We know things about the page and about the site, from a security/
authentication/encryption perspective. Things that might influence the
user's decision to bookmark or not. I think that we should expose that
information to the user before they make that decision.
(Apologies if there are two replies from me - Google seems to have
lost my first one)
Alex Faaborg
button: http://wiki.mozilla.org/Places:User_Interface/
I4_Star_Button_and_Sidebar
Note that this iteration includes a few changes to the theme, let's
not spend too much time debating those right now, I primarily made
the change so that the navigation toolbar didn't have 6 icons in the
mockup, but I understand that a lot of people are going to have
issues with that. But let's keep this thread about places, and
discuss the browser chrome in a separate thread.
Both Flock and the Google toolbar have a star button for bookmarking
pages that fills in on the first click, and they both produce a menu
or dialog on the second click. I thought more about it, and I am
pretty sure that if we did clear the star on the second click, people
would regularly become angry because deleting a bookmark needs to be
a slightly more involved action, especially if you have gone to a lot
of work to organize the bookmark into a folder, and provide tags.
So, here is the behavior that I think makes the most sense:
[if star is inactive]
Single click or double click on the star: star activates
[if star is active]
Single click or double click on the star: display bookmarking dialog
with folder and tag options, and a button to delete the bookmark
So in this model a click->pause->click would produce the dialog, or
you could just click once directly on the drop down arrow next to the
star.
The feedback and alternative mockups people are posting are really
helping to refine what we think the places UI is going to look like,
great job everyone!
-Alex
Robert Kaiser
> [if star is inactive]
> Single click or double click on the star: star activates
Why not make only single-click do it that way and double-click directly
going to the bookmarking dialog (just with "Cancel" instead of "Delete")?
I think it would be really good to have a fast option to add a bookmark
with options, and click-pause-click is very unintuitive for that.
Still, for people mistakenly double-clicking instead of single-clicking,
they would get the same result as with a single click by just clicking
OK on the dialog, right?
Robert Kaiser
Alex Faaborg
still get to the dialog with a single click, although the target area
is a little bit smaller than the star itself.
http://wiki.mozilla.org/Places:User_Interface/I4_Star_Button_and_Sidebar
> Still, for people mistakenly double-clicking instead of single-
> clicking,
> they would get the same result as with a single click by just clicking
> OK on the dialog, right?
Yeah, expanding the dialog and clicking OK is the same as just
clicking the star.
-Alex
John Bird
One question:
When I arrive at a page that is already bookmarked or tagged, does the star
change in some way to show that I already have this page in bookmarks or
tags?
(That has been one of my gripes - that there has been no way to find out if
a page is already in my bookmarks - apart from going into the bookmarks
organiser and looking theough them that is - so I just tend to add it again.
Even when I add it, the UI does not say if its already there either)
John
Alex Faaborg
> the star
> change in some way to show that I already have this page in
> bookmarks or
> tags?
Yes, similar to Flock and the Google toolbar, the star lights up when
you are on pages you have bookmarked. In this mockup, clicking on
the down arrow would let you modify existing tags, move the bookmark
to a different folder, or delete the bookmark.
-Alex
Mike Beltzner
> that I would very much like for us to have a single-click system for
> creating a bookmark that doesn't pop up any additional dialogs or
Yup, though we need to provide some feedback to complete the action,
such that users have answers to the very questions you asked mconnor
earlier about "well, if these quickmarks don't actually appear in the
menu structure, how do I get 'em back?" as well as the other logical
question "hm, I meant to actually create an entry in the menu system for
that, how do I do that?"
I think we're getting there, slowly but surely.
The action of "starring" something is becoming more familiar in web and
client application UI as a shorthand for "mark as
favourite/interesting/noteworthy" and I think we can build on that
metaphor. It can be reinforced (as it was in some of your mockups) by
always showing that history entry with the same star mark beside it,
either in the Location Bar autocomplete, or the history search, or even
(if we want to get fancy) when a user hovers over a link to that page in
the content area.
> buttons or anything (first time perhaps, like Flock does, but with
> the option to suppress that dialog in the future).
How about an overlay (which vanishes after 5s) which tells the user how
they can find that thing again. Something like:
"Page marked! You can find it in "Recently marked pages" or by searching
in your history."
(this assumes a "Recently marked pages" smartfolder as per your mockups,
which I thought was a good idea)
> So, instead of popping up the "Page Bookmarked" mini-dialog as in the
> second part here...
>
> http://wiki.mozilla.org/Places:User_Interface/Tagging_a_Page3
>
> ...we would just change the appearance of whatever the bookmarking
> icon ended up being -- maybe a book changes to a book with a bookmark
> in it or somesuch. I hadn't really delved into the specifics at this
> point -- my mockups are meant to be more rough sketches than
> precisely detailed specs :)
I'm not a fan of the button changing state, mostly because I don't think
that creates a strong enough relationship to the actual thing that's
being quickmarked (which is the site, not the button). Other starring
interfaces (iTunes, email applications) always relate the star with the
item, and I think that's important for us to do, as well.
> As for metaphors, I've never been a huge fan of the "bookmark" thing
> since the web is in no way a "book". I understand wanting to
> maintain consistency so as to not confuse users overmuch, but I don't
> think we should be afraid of changing that metaphor due to simple
> tradition.
FWIW, I don't think the majority of our users even notice that the icon
we're using for a bookmark is supposed to look like a bookmark :)
Despite being in a Mozilla-heavy crowd, though, and despite the fact
that I agree that the web is nothing like a book, I hear that term used
ubiquitously when talking about navigating the web with friends, family
and strangers. I'm not married to it, though, and anyone who's listened
to me rant about my ideas for this will know that I prefer the idea of
using terms like "remember", "shortcut", "mark", etc.
> I also don't find the "one-click star, second-click open dialog"
> thing to be particularly weird. It did surprise me the first time I
> did it (as you suggested, I expected the second click to turn the
> star off), but after doing it once or twice I learned the new
> behaviour and it became entirely second-hand and comfortable. Are we
> unable to introduce new interactions like that to users?
That's a bit of a straw-man there, Deb, since I don't think anyone
suggested that we were unable to introduce new interactions. When
presenting new primary UI for a common user function, we'll want to make
sure that all interactions are as intuitive and discoverable as possible.
New interactions should be introduced when observation leads the
designer to believe that someone would be expecting the proposed action
to lead to the proposed result, or when care can be taken to illustrate
to users how the new interaction works (either in a declarative or
emergent fashion).
In this particular case, though, I think the strangeness Alex was
describing was that it would be a single button on the toolbar which
would act like no other button.
As mentioned, I'm not a fan of it being a toolbar button at all, and
would rather see it as a button inside the Location Bar, at which point
a singe/double click breakdown as proposed wouldn't feel as strange.
Everybody wins! :)
cheers,
mike
Gervase Markham
> page as opposed to the current symbol now?
I had to press the spacebar 14 times to page down before I could read
what you had to say. Please trim your posts.
http://www.mozilla.org/community/etiquette.html
Thanks,
Gerv
Gervase Markham
> I know what you mean, but it's not that clear cut. If you visit a
> phishing site and provide some credentials, then yes you've lost long
> before you reach the bookmark button. But what about if you bookmark
> the "login" page with the intention of going back later to enter your
> details?
Under what circumstances would that happen?
This site is supposed to be (e.g.) your bank, right? Now either you have
your bank bookmarked already, or you don't. What are the chances that
you receive a "Your account is about to be shut down!" email, visit the
site in a panic, and then decide that actually, today is a good day to
bookmark the site and come back and prevent your account being shut down
later?
I really think that the risk of someone accidentally bookmarking a
phishing site is low, and it's not a scenario we need to be concerned about.
Gerv
Gervase Markham
> Here is a fresh iteration of the Places UI which includes a star button:
> http://wiki.mozilla.org/Places:User_Interface/I4_Star_Button_and_Sidebar
Any chance of having the different screens as different images, one
after the other? This very large, very wide graphic is hard to navigate
on my laptop.
> Note that this iteration includes a few changes to the theme, let's not
> spend too much time debating those right now, I primarily made the
> change so that the navigation toolbar didn't have 6 icons in the mockup,
> but I understand that a lot of people are going to have issues with
> that. But let's keep this thread about places, and discuss the browser
> chrome in a separate thread.
OK. As a meta point, we need to decide some method for making the
"consistent across Firefoxes" vs. "consistent across platforms" decision.
When does this thread start?
> Both Flock and the Google toolbar have a star button for bookmarking
> pages that fills in on the first click, and they both produce a menu or
> dialog on the second click. I thought more about it, and I am pretty
> sure that if we did clear the star on the second click, people would
> regularly become angry because deleting a bookmark needs to be a
> slightly more involved action, especially if you have gone to a lot of
> work to organize the bookmark into a folder, and provide tags.
That's an easy one, though. When you remove a bookmark, it doesn't
actually throw the associated information away until the end of the
session. So if you accidentally click the star, click it again and all
is as it was before. Instant undo.
My thoughts on the mockup:
If the user creates a new bookmark using click-pause-click (say), then
clicks outside the window, does the bookmark remain? What's the default
action? I'm not sure clicking outside the window should dismiss, because
it's unambiguous as to what has happened.
We seem to be inventing these hybrid dialog-menu things here. What UI
precedents are there for them, if any?
Why is using a star icon to represent bookmarks "mixing metaphors"?
You talk about "reducing data loss when the user meant to click the
drop-down". If you think this is a problem, surely the fix is not to
change the interaction model, but fix the theme to distinguish between
what are actually two separate (albeit related) buttons? This trend for
flat buttons which highlight when you mouse over them actually reduces
the usability of the buttons IMO - and your note here demonstrates that
you recognise that :-) So let's fix it.
Gerv
Mike Connor
On 9-Jun-07, at 10:25 PM, Alex Faaborg wrote:
> Note that this iteration includes a few changes to the theme, let's
> not spend too much time debating those right now, I primarily made
> the change so that the navigation toolbar didn't have 6 icons in the
> mockup, but I understand that a lot of people are going to have
> issues with that. But let's keep this thread about places, and
> discuss the browser chrome in a separate thread.
I think that we're unlikely to radically reorganize the toolbars,
say, this week, so we're even less likely to make significant
experimental changes even later in the cycle. If the UI doesn't work
with the existing layout (possibly with _minor_ tweaks) we're not
going in the right direction to move forward quickly. I think that
moving to consistency with IE7/Safari is overrated by some, I don't
think they have better UI overall, so let's base decisions based on
the best overall task organization and users' experience.
> Both Flock and the Google toolbar have a star button for bookmarking
> pages that fills in on the first click, and they both produce a menu
> or dialog on the second click. I thought more about it, and I am
> pretty sure that if we did clear the star on the second click, people
> would regularly become angry because deleting a bookmark needs to be
> a slightly more involved action, especially if you have gone to a lot
> of work to organize the bookmark into a folder, and provide tags.
> So, here is the behavior that I think makes the most sense:
>
> [if star is inactive]
> Single click or double click on the star: star activates
>
> [if star is active]
> Single click or double click on the star: display bookmarking dialog
> with folder and tag options, and a button to delete the bookmark
>
> So in this model a click->pause->click would produce the dialog, or
> you could just click once directly on the drop down arrow next to the
> star.
Overall this seems logical, but I don't know if we'd want another
menubutton in the primary UI, it feels quite heavy and focused on
users who actually care a lot about bookmarking, rather than being a
low visual impact feature that's easier and more powerful than
Firefox 2, which is why I liked the cascading favicon menu
interaction better.
-- Mike
Mark
> Mark wrote:
> > I know what you mean, but it's not that clear cut. If you visit a
> > phishing site and provide some credentials, then yes you've lost long
> > before you reach the bookmark button. But what about if you bookmark
> > the "login" page with the intention of going back later to enter your
> > details?
>
> Under what circumstances would that happen?
>
> This site is supposed to be (e.g.) your bank, right? Now either you have
> your bank bookmarked already, or you don't. What are the chances that
> you receive a "Your account is about to be shut down!" email, visit the
> site in a panic, and then decide that actually, today is a good day to
> bookmark the site and come back and prevent your account being shut down
> later?
I'm thinking of more subtle phishing schemes than trying to get your
bank details directly. I know plenty of people who would quite happily
click on a link that says "To celebrate our nth anniversary we're
giving away 100 ipod Nanos - just click on this link and log into your
Amazon account: www.amazon-competition.com".
> I really think that the risk of someone accidentally bookmarking a
> phishing site is low, and it's not a scenario we need to be concerned about.
I agree that the risk is low. This wasn't my primary concern when
suggesting the addition of security UI to the proposed bookmarking
popup, it was just one possible scenario in which it might help.
More particularly, additional security information would help to draw
attention to the fact that I'm absent-mindedly trying to bookmark
http://gmail.com instead of https://gmail.com. It would also provide a
lightweight UI to simply get an overview of the security information
related to the page (as opposed to the heavyweight UI of Page Info, or
the so-lightweight-people-miss-it UI of the lock icon).
Finally, as I mentioned, if there's going to be a new popup that is
closely associated with the URL, then I don't see why bookmarking is
any more deserving of that space than security information - or any of
a number of URL-related tasks that extension authors might have in
mind. I'd rather see a general "things to do with this URL" popup,
with security and bookmarking as standard, but perhaps with the
possibility of future expansion.
Of course the whole "Star" approach renders the point largely moot, as
the primary means of using it to bookmark a site wouldn't bring up any
additional UI anyway.
Mark
Dão
>
> On 9-Jun-07, at 10:25 PM, Alex Faaborg wrote:
>
>> Note that this iteration includes a few changes to the theme, let's
>> not spend too much time debating those right now, I primarily made
>> the change so that the navigation toolbar didn't have 6 icons in the
>> mockup, but I understand that a lot of people are going to have
>> issues with that. But let's keep this thread about places, and
>> discuss the browser chrome in a separate thread.
>
> I think that we're unlikely to radically reorganize the toolbars, say,
> this week, so we're even less likely to make significant experimental
> changes even later in the cycle. If the UI doesn't work with the
> existing layout (possibly with _minor_ tweaks) we're not going in the
> right direction to move forward quickly. I think that moving to
> consistency with IE7/Safari is overrated by some, I don't think they
> have better UI overall, so let's base decisions based on the best
> overall task organization and users' experience.
I think keeping the Stop and Reload buttons as distinct buttons but
moving them between the Location and Search bar would be a nice trade-off.
Dao
Alex Faaborg
-Security UI gets the favicon menu
-Star button moved to right side of location bar
-Starred pages moved to "Recently Starred Pages" smart folder
-Alex
Justin Wood (Callek)
Star button on "right side of inside location bar" as shown in the I5
mockup would not allow it to be customized away, and thus no-pop-up
window "feature".
/me is refraining from making other comments as I haven't yet read any
of this thread, and don't want to re-state stuff already talked about
and answered.
~Justin Wood (Callek)
Gervase Markham
> Iteration 5: http://wiki.mozilla.org/Places:User_Interface/I5
> -Star button moved to right side of location bar
I'd rather like Ctrl-D do the equivalent of single-clicking on the star.
If we are trying to create a system where you just say "Keep track of
this for me", and the browser DTRT, then the key combo should reflect
that, rather than bringing up the dialog.
What happens when a page is no longer "Recently Starred"? Where does it go?
We are also mixing the "starred pages" and "bookmarks" metaphors at the
moment. Starred pages, bookmarks and tags is 3 metaphors - that's at
least one (and possibly two) too many.
Should the Delete button be labelled "Unstar" or "Unmark"?
I don't think it needs to be possible to remove the star (thereby
avoiding the need to produce a dialog version of the, er, dialog). We
don't allow people to customise away the feed icon, and I don't think we
allow people to remove the Go button independent of the URL bar. Do we?
Gerv
Benjamin Smedberg
> Iteration 5: http://wiki.mozilla.org/Places:User_Interface/I5
>
> -Security UI gets the favicon menu
> -Star button moved to right side of location bar
> -Starred pages moved to "Recently Starred Pages" smart folder
* It is not clear to me from this mockup what I would drag to put a page
into my personal toolbar.
* Do we really expect that people will use the bookmarks sidebar? I have
never used it in my entire life, and I don't see why I'd want to start now:
I imagine that all an average user wants is two things:
- quick access to very common pages through quick-click UI; for me this is
the bookmarks toolbar
- ability to recall interesting pages through a search interface: this
should be the search bar and the browser homepage, which are our traditional
and best search interface.
All this focus on the sidebar seems counter-productive... there isn't even a
one-click way to open the sidebar, is there? And even if there were, for the
common tasks above that's one click too many.
--BDS
Alex Faaborg
> does it go?
Firefox will never forget that you starred the page, but the only way
to get to the page is to search for it, or click "all starred
pages" (the last item in "Recently Starred Pages"), which loads the
history sidebar with a filter set to only show starred pages.
> We are also mixing the "starred pages" and "bookmarks" metaphors at
> the
> moment. Starred pages, bookmarks and tags is 3 metaphors - that's at
> least one (and possibly two) too many.
I agree, but if we make stars directly analogous to bookmarks (which
we did in iteration 4), the bookmarks menu / sidebar will quickly
become inundated with new pages. Or alternatively, users won't star
pages because they don't want to make a mess of their menu, or have
to go to the extra work of organizing it later.
If users know that starring a page records it in a lightweight way
that doesn't clutter their current bookmarks, they are more likely to
take advantage of the feature.
> Should the Delete button be labelled "Unstar" or "Unmark"?
If you change the location of the starred page, then you are
essentially creating a bookmark. I think it would be better to keep
it "delete" as opposed to having the name change depending on what
folder the stored page is in.
> I don't think it needs to be possible to remove the star (thereby
> avoiding the need to produce a dialog version of the, er, dialog). We
> don't allow people to customise away the feed icon, and I don't
> think we
> allow people to remove the Go button independent of the URL bar. Do
> we?
We don't currently allow these things, but I think in general we
should enable users to customize as much as they want. If it is too
difficult to implement, keeping these things static isn't a big deal.
-Alex
Alex Faaborg
> page
> into my personal toolbar.
There is a debate to remove the favicon going on over in the location
bar proposal thread. The star is independent of this interaction,
either you would still drag the favicon, or you wouldn't be able to
because there isn't one anymore. Dragging the star itself seems a
bit odd, but I guess we could think about enabling that (and dragging
the RSS icon to create a live bookmark).
> All this focus on the sidebar seems counter-productive
The folder structure will be the same as the bookmarks menu, which is
the only important part of these mockups. I'm not trying to say that
the bookmarks sidebar is better than the bookmarks menu, or vice versa.
We could consider moving the pre-populated smart folders to the
bookmarks toolbar, so that they are more discoverable. We would
probably want them all under one folder so they don't take up too
much space. I'm going to try that change in iteration 6.
-Alex
Alex Faaborg
-To reduce overall visual complexity, the RSS and star icons use the
visual variables of position and shape to different themselves, but
not color. (mostly just wanted to see what it looked like, maybe just
on the mac?)
-Pre-populated smart folders are moved from the bookmarks menu/
sidebar to the bookmarks toolbar for discoverability.
-Open questions: What if the user turns the bookmarks sidebar off?
Will they know to move the folder? Should we put it in both places?
-Alex
On Jun 12, 2007, at 3:28 PM, Alex Faaborg wrote:
>> * It is not clear to me from this mockup what I would drag to put a
>> page
>> into my personal toolbar.
>
> There is a debate to remove the favicon going on over in the location
> bar proposal thread. The star is independent of this interaction,
> either you would still drag the favicon, or you wouldn't be able to
> because there isn't one anymore. Dragging the star itself seems a
> bit odd, but I guess we could think about enabling that (and dragging
> the RSS icon to create a live bookmark).
>
>> All this focus on the sidebar seems counter-productive
>
> The folder structure will be the same as the bookmarks menu, which is
> the only important part of these mockups. I'm not trying to say that
> the bookmarks sidebar is better than the bookmarks menu, or vice
> versa.
>
> We could consider moving the pre-populated smart folders to the
> bookmarks toolbar, so that they are more discoverable. We would
> probably want them all under one folder so they don't take up too
> much space. I'm going to try that change in iteration 6.
>
> -Alex
>
>
> On Jun 12, 2007, at 4:59 AM, Benjamin Smedberg wrote:
>
Benjamin Smedberg
>> All this focus on the sidebar seems counter-productive
>
> The folder structure will be the same as the bookmarks menu, which is
> the only important part of these mockups. I'm not trying to say that
> the bookmarks sidebar is better than the bookmarks menu, or vice versa.
My assertion, from personal experience helping beginning and intermediate
users, is that most people use neither one because they are not. Focusing on
the organization of the bookmarks is only going to help Maybe better
starring/tagging will make the menus better (automatically) organized, but I
don't see that it makes it easier to use.
I think I'm saying that we should optimize bookmarking experience for
reusing the existing search UI (start page and search box) to promote
"re-recognition" and search of bookmarks, rather than folder-based UI.
--BDS
Justin Wood (Callek)
> I think I'm saying that we should optimize bookmarking experience for
> reusing the existing search UI (start page and search box) to promote
> "re-recognition" and search of bookmarks, rather than folder-based UI.
Agreed.
Two questions, has it been discussed why a quick-way to enumerate what
tags have been used, and what pages are starred with those tags ever
been discussed/explained?
And, Would a "One-click" tagging for any/certain tags be possible
without bookmarklets? (As-in, built-in) or would taht best be for
extensions. My concern is if I was searching for a particular research
project I might be starring many pages, say as "Dung Beetle" if my
research was on that. Being able to one-click "Star + tag" a page could
be very useful in that regard, rather than needing to (as currently
outlined)
* Click Star (Which actually begs a related question, how do we make
"button in URL-bar" accessible to keyboard only users?)
* Click Star Again
* Click/tab into "Tagging" box
* Type/and-or/Autocomplete "Dung Beetle"
At most 4 actions, at worst one for each keypress for a disabled user.
~Justin Wood (Callek)
(I apologize in advance if any of this has allready been brought up, in
which case a simple link to relevant re-hashed idea's is enough)
Deb Richardson
> we did in iteration 4), the bookmarks menu / sidebar will quickly
> become inundated with new pages. Or alternatively, users won't star
> pages because they don't want to make a mess of their menu, or have
> to go to the extra work of organizing it later.
Metaphors aside, I think what we're trying to do is make it as easy as possible for users to record page locations so they can visit them again later. Off the top of my head, this involves four fundamental interactions:
1) Record the location of a page.
2) Add/modify the meta-data associated with that recorded location to improve findability.
3) Find and use that recorded location at a later time.
4) Delete recorded locations when they're no longer wanted.
As I see it:
1) "Record the location of a page" is currently being called both "starring" and "bookmarking". I do not see any difference between "starring" a page and "bookmarking" a page since fundamentally they are both the user saying "remember this URL".
2) "Add/modify some meta-data" involves a user adding or changing the folders and tags associated with a bookmark.
3) "Find and use" involves the user interacting with the Sidebar, the Toolbar, the Menu, the Search system to browse or search for a bookmark.
4) "Delete" is fairly straightforward and is simply the user saying "forget this URL".
The current bookmarking system sort of muddies the water between 2 and 3 because adding a bookmark to the Toolbar is done by adding it to a Folder. So "Bookmarks Toolbar Folder" is a special type of folder that users can leverage to add Bookmarks directly to their browser UI. Things are further muddied because we automatically add all bookmarks to the Bookmark Menu without giving the user any control over what does or doesn't appear there.
Would it make sense for us to give users the same level of control over what does/doesn't appear in the Bookmark Menu as they have over the Bookmark Toolbar? Could we add a "Bookmark Menu Folder" as well, giving users direct control over what bookmarks and bookmark folders appear in the Menu, essentially treating it exactly the same way as the Toolbar?
That doesn't exactly solve the "making it easier to create bookmarks is going to let the user mess up their bookmark menu even faster!" problem, but perhaps it could give us another way of thinking about and approaching the problem.
~ deb
Alex Faaborg
> over what does/doesn't appear in the Bookmark Menu as they have
> over the Bookmark Toolbar?
Yeah, I think this is a really great idea. This would allow us to
place starred pages in the root without causing the bookmarks menu
and sidebar to have to try to load all of these items (or
implementing lazy loading). Additionally, the bookmarks menu folder
is both internally consistent (similar to the bookmarks toolbar
folder), and externally consistent (Safari). We need to give these
two correct icons a drop the "folder" from the name.
This would also allow us to make much cleaner argument that starring
== bookmarking, since you could bookmark a page but not place it in
your bookmarks toolbar or menu, which is equivalent to starring a page.
For discoverability we would probably need to add a "Bookmarks->Show
all Bookmarks," which loads the bookmarks manager.
-Alex
Mike Beltzner
> Alex Faaborg wrote:
>
>>> All this focus on the sidebar seems counter-productive
>> The folder structure will be the same as the bookmarks menu, which is
>> the only important part of these mockups. I'm not trying to say that
>> the bookmarks sidebar is better than the bookmarks menu, or vice versa.
>
> My assertion, from personal experience helping beginning and intermediate
> users, is that most people use neither one because they are not. Focusing on
> the organization of the bookmarks is only going to help Maybe better
> starring/tagging will make the menus better (automatically) organized, but I
> don't see that it makes it easier to use.
If I'm parsing your comment correctly, you're saying that people don't
use the bookmarks sidebar not the bookmark menu, as both have problems
that make them useless for the user's needs. And optimizations for
organizing and categorizing them might yield incremental improvements,
but won't adequately solve the problem which. Is that right?
> I think I'm saying that we should optimize bookmarking experience for
> reusing the existing search UI (start page and search box) to promote
> "re-recognition" and search of bookmarks, rather than folder-based UI.
On this I think we agree, though I'm not convinced that putting bookmark
search in the Search Bar is a good idea, as it blurs the line between
"Search the Web" and "Search my set of bookmarks / starred pages".
Perhaps, however, a search engine for "History and Bookmarks" could be
added which opens the search sidebar. Or maybe we can always add "Seach
History and Bookmarks" at the bottom of the suggestions drop-down.
What I've been expecting (but what hasn't been called out in these
mockups) is other ways in which we're going to leverage Places to
promote bookmarked and starred results. For example, I'm expecting that
typing text in location bar will show:
--- matching URLs from history
--- matching bookmarks / starred pages based on titles
--- matches based on tags
cheers,
mike
Mike Beltzner
> Benjamin Smedberg wrote:
>> I think I'm saying that we should optimize bookmarking experience for
>> reusing the existing search UI (start page and search box) to promote
>> "re-recognition" and search of bookmarks, rather than folder-based UI.
>
> Agreed.
>
> Two questions, has it been discussed why a quick-way to enumerate what
> tags have been used, and what pages are starred with those tags ever
> been discussed/explained?
I don't understand what you're asking here at all; can you rephrase the
question?
> And, Would a "One-click" tagging for any/certain tags be possible
> without bookmarklets? (As-in, built-in) or would taht best be for
> extensions. My concern is if I was searching for a particular research
> project I might be starring many pages, say as "Dung Beetle" if my
> research was on that. Being able to one-click "Star + tag" a page could
> be very useful in that regard, rather than needing to (as currently
> outlined)
>
> * Click Star (Which actually begs a related question, how do we make
> "button in URL-bar" accessible to keyboard only users?)
> * Click Star Again
> * Click/tab into "Tagging" box
> * Type/and-or/Autocomplete "Dung Beetle"
Clicking the star button twice would be the same as Accel-D, which would
be the equivalent keyboard shortcut. I suppose we could do something
like Accel-Alt-D for a keyboard equivalent for the one-click action.
cheers,
mike
Mike Beltzner
> Metaphors aside, I think what we're trying to do is make it as easy
> as possible for users to record page locations so they can visit them
> again later.
That's absolutely right. I think it's been mentioned before -- maybe not
-- but the basic UI goals are:
A) retain and improve support for traditional bookmark hierarchies,
B) make users comfortable with bookmarking more pages,
C) make it easier to manage and navigate large bookmark collections
without requiring hierarchies.
The rationale behind A is obvious, and serves the majority of our users
who've never heard of tags or stars, or who are keen to manage large
folder structures for their bookmarks since that's what they know how to
do. We can't abandon those users with the new system.
Goals B and C arose from the observation that the web has grown
dramatically since Bookmarks were first created, and that people had
started to use Web Search (or for a subset of users, tools like
del.icio.us) as a replacement for bookmarking pages. There was a
reluctance amongst users to bookmark every interesting page they saw.
Reasons for the reluctance (again, based on observation were):
- creating a bookmark felt like a very permanent and heavy action
which might not be appropriate for pages that may simply be of transient
interest
- navigating through large bookmark sets was slow
- creating and maintaining hierarchies for large bookmark sets was a pain
> Off the top of my head, this involves four fundamental
> interactions:
>
> 1) Record the location of a page. 2) Add/modify the meta-data
> associated with that recorded location to improve findability. 3)
> Find and use that recorded location at a later time. 4) Delete
> recorded locations when they're no longer wanted.
I agree with those interactions, yes: create, edit/annotate, retrieve,
delete.
> As I see it:
>
> 1) "Record the location of a page" is currently being called both
> "starring" and "bookmarking". I do not see any difference between
> "starring" a page and "bookmarking" a page since fundamentally they
> are both the user saying "remember this URL".
Yes, although in terms of interactions in the current design, "starring"
is intentionally far lighter-weight than "bookmarking" (where I define
"bookmarking" as hitting Accel-D or the "Add Bookmark..." menuItem which
will result in the dialog that hangs off the star and asks for a folder
name and tags).
Creating a bookmark has historically meant "add an item to the Bookmarks
Menu, and place it in a specific folder." That's what people think of
when they think of bookmarking an item. The idea behind starring is to
provide a very lightweight way of telling Firefox "hey, I think this
page is interesting, and might want to see it again later," or, "this is
an interesting page on the web." It's meant to speak directly to Goal B,
which is to encourage people to bookmark more things.
At an implementation level, sure, they're both entries in the Places
database and both technically "bookmarks", but the interaction is very
different.
The current design tries to harmonize this by saying that the basic
level of interest a user can express in a page is to "star" it. If they
want to create an entry in the Bookmarks Menu, they can do that, too,
and the page will also be starred, as the intent of marking the page as
interesting is obviously carried over to that action.
While you might not see the difference here from the point of view of
the model, I think the two interactions will feel very different to
users, and the goal is that starring will result in users bookmarking
more pages.
> 2) "Add/modify some meta-data" involves a user adding or changing the
> folders and tags associated with a bookmark.
Yes, and also includes actions like:
- add/change the folder that the bookmark exists in
- change the target of the bookmark
- etc.
> 3) "Find and use" involves the user interacting with the Sidebar, the
> Toolbar, the Menu, the Search system to browse or search for a
> bookmark.
Agreed.
A continuing part of the "starring" strategy here is to not show pages
that are starred in the Bookmarks Menu until the user decides to
explicitly place them in that structure. This will, hopefully, reduce
the cost of starring a page in that the bookmark menu won't get
cluttered and/or the user won't need to create huge hierarchies to
support large bookmark collections.
> 4) "Delete" is fairly straightforward and is simply the user saying
> "forget this URL".
Yup.
> The current bookmarking system sort of muddies the water between 2
> and 3 because adding a bookmark to the Toolbar is done by adding it
> to a Folder. So "Bookmarks Toolbar Folder" is a special type of
> folder that users can leverage to add Bookmarks directly to their
> browser UI. Things are further muddied because we automatically add
> all bookmarks to the Bookmark Menu without giving the user any
> control over what does or doesn't appear there.
Yeah, I think that's another way of putting the problem. Good analysis.
> Would it make sense for us to give users the same level of control
> over what does/doesn't appear in the Bookmark Menu as they have over
> the Bookmark Toolbar? Could we add a "Bookmark Menu Folder" as well,
> giving users direct control over what bookmarks and bookmark folders
> appear in the Menu, essentially treating it exactly the same way as
> the Toolbar?
As Alex mentioned, I think that's a great idea, and would work well to
support the idea that a starred page is a bookmark like any other, we
just don't automatically file it in a folder until we're told to do so.
cheers,
mike
Gervase Markham
> I agree, but if we make stars directly analogous to bookmarks (which we
> did in iteration 4), the bookmarks menu / sidebar will quickly become
> inundated with new pages. Or alternatively, users won't star pages
> because they don't want to make a mess of their menu, or have to go to
> the extra work of organizing it later.
There's no law saying that starred pages have to appear at the top level
of the bookmarks menu, is there? :-) Just have a folder called "New
Additions". If that ends up filling up, then we clearly have either a)
made our bookmark management UI too hard to use, or b) are making people
"manage" their bookmarks when they shouldn't have to do that at all.
> If users know that starring a page records it in a lightweight way that
> doesn't clutter their current bookmarks, they are more likely to take
> advantage of the feature.
Do you think users really have that sort of mental model of two types of
"I'm interested in this page"?
>> Should the Delete button be labelled "Unstar" or "Unmark"?
>
> If you change the location of the starred page, then you are essentially
> creating a bookmark.
Wow. I _really_ don't think people will get that.
So starring is not like bookmarking, except when it is?
>> I don't think it needs to be possible to remove the star (thereby
>> avoiding the need to produce a dialog version of the, er, dialog). We
>> don't allow people to customise away the feed icon, and I don't think we
>> allow people to remove the Go button independent of the URL bar. Do we?
>
> We don't currently allow these things, but I think in general we should
> enable users to customize as much as they want.
I think that's a terrible general principle. A lot of the changes of
Firefox over the Suite were letting users customise less stuff. We have
toolbar customisation, and that's fine, but I see nothing wrong with
saying that the star is part of the URL bar, full stop.
Gerv
Gervase Markham
> On this I think we agree, though I'm not convinced that putting bookmark
> search in the Search Bar is a good idea, as it blurs the line between
> "Search the Web" and "Search my set of bookmarks / starred pages".
Hasn't the Google Desktop addon rather successfully blurred the line
between "Search the Web" and "Search my stuff"? (I don't use it, so I
can't say for sure.)
Gerv
Gervase Markham
> As I see it:
Good analysis:
> 1) "Record the location of a page" is currently being called both
> "starring" and "bookmarking". I do not see any difference between
> "starring" a page and "bookmarking" a page since fundamentally they
> are both the user saying "remember this URL".
I agree.
> 2) "Add/modify some meta-data" involves a user adding or changing the
> folders and tags associated with a bookmark.
And I would apply your lesson from 1) to 2), and say that putting
something in folder "Foo" and giving it a tag "Foo" are pretty similar
actions. The only difference is that when you present the results in a
tree view, multiply-tagged things appear in more than one place.
> 3) "Find and use" involves the user interacting with the Sidebar, the
> Toolbar, the Menu, the Search system to browse or search for a
> bookmark.
I really wish we had good data about which access methods were most used.
Sample size of 1: my housemate. I think he's OK with computers, although
when asked "which web browser do you use?", he still answered "Google".
<sigh> He actually uses IE 7.
IE 7 only has one method of accessing bookmarks - a sidebar-like thing,
which you access by single-clicking the star icon in the lowest toolbar.
He has a few organised folders by topic, and also a top-level list of
sites he visits reasonably regularly. To access them, he opens the
sidebar and just clicks on the one he wants.
His trigger for reorganising things is when the list reaches the bottom
of the screen. He doesn't have any complaints about the way the system
works. He does delete things during the reorg, although he hasn't
bothered to delete the bookmarks which came with it, even though he
doesn't use them.
I don't know if IE 7 has a bookmarks toolbar but if it does, he doesn't
use it.
> 4) "Delete" is fairly straightforward and is simply the user saying
> "forget this URL".
Ideally, users would never *have* to do this - i.e. the cognitive load
of having a thousand starred pages would be about the same as having ten.
Gerv
Gervase Markham
> That's absolutely right. I think it's been mentioned before -- maybe not
> -- but the basic UI goals are:
>
> A) retain and improve support for traditional bookmark hierarchies,
> B) make users comfortable with bookmarking more pages,
> C) make it easier to manage and navigate large bookmark collections
> without requiring hierarchies.
>
> The rationale behind A is obvious, and serves the majority of our users
> who've never heard of tags or stars, or who are keen to manage large
> folder structures for their bookmarks since that's what they know how to
> do. We can't abandon those users with the new system.
Do we have evidence to suggest that the majority of our users manage
large folder structures?
> Goals B and C arose from the observation that the web has grown
> dramatically since Bookmarks were first created, and that people had
> started to use Web Search (or for a subset of users, tools like
> del.icio.us) as a replacement for bookmarking pages.
Why did we decide this was bad? Because they might not necessarily find
the same page again?
> Reasons for the reluctance (again, based on observation were):
> - creating a bookmark felt like a very permanent and heavy action which
> might not be appropriate for pages that may simply be of transient interest
I think this became the case when Ctrl-D stopped just adding a bookmark,
and started popping a dialog.
> - creating and maintaining hierarchies for large bookmark sets was a pain
So should we attempt to apply the "Search, don't sort" principle?
> Yes, although in terms of interactions in the current design, "starring"
> is intentionally far lighter-weight than "bookmarking" (where I define
> "bookmarking" as hitting Accel-D or the "Add Bookmark..." menuItem which
> will result in the dialog that hangs off the star and asks for a folder
> name and tags).
Is starring going to acquire a keyboard shortcut?
> Creating a bookmark has historically meant "add an item to the Bookmarks
> Menu, and place it in a specific folder." That's what people think of
> when they think of bookmarking an item.
I'm not sure that's true - at least, the part about the folder. I know
I, and my housemate (see previous message) just bookmark things and they
go into a big "untriaged" list, and then we sort them later. This is
pretty close to starring.
> The current design tries to harmonize this by saying that the basic
> level of interest a user can express in a page is to "star" it. If they
> want to create an entry in the Bookmarks Menu, they can do that, too,
> and the page will also be starred, as the intent of marking the page as
> interesting is obviously carried over to that action.
But what does starring buy you if you can't see a list of starred pages?
Or is it that you can, it's just not called the Bookmarks Menu?
> A continuing part of the "starring" strategy here is to not show pages
> that are starred in the Bookmarks Menu until the user decides to
> explicitly place them in that structure. This will, hopefully, reduce
> the cost of starring a page in that the bookmark menu won't get
> cluttered and/or the user won't need to create huge hierarchies to
> support large bookmark collections.
But wouldn't that cause the problem that a user might thing "Hey, I
starred that page, but it's not in the list?. After all, the other page
which I starred is here." (Which is actually because he also gave it a tag.)
Gerv
Gervase Markham
> This would also allow us to make much cleaner argument that starring ==
> bookmarking, since you could bookmark a page but not place it in your
> bookmarks toolbar or menu, which is equivalent to starring a page.
Yes! :-)
Gerv
Robert Kaiser
> Iteration 5: http://wiki.mozilla.org/Places:User_Interface/I5
>
> -Security UI gets the favicon menu
> -Star button moved to right side of location bar
Why this? This completely goes against what people are used to from
other browsers. If there is security UI in the location bar, it's always
at the right end, and icons associated with the page and/or bookmarking
are always at the left side (star, favicon, etc.)
Is there some in-deep argument for reversing that logic?
Robert Kaiser
Robert Kaiser
> Iteration 6: http://wiki.mozilla.org/Places:User_Interface/I6
>
> -To reduce overall visual complexity, the RSS and star icons use the
> visual variables of position and shape to different themselves, but not
> color. (mostly just wanted to see what it looked like, maybe just on the
> mac?)
users are completely used to seeing the RSS icon as this orange thing
with the white markings in it, this _is_ the feed indicator used
everywhere - on web pages and in a big range of readers.
See
http://blogs.msdn.com/rssteam/archive/2005/12/14/503778.aspx
http://en.wikipedia.org/wiki/Web_feed
Why suddenly change this user experience to something much harder to
recognize?
Robert Kaiser
Deb Richardson
----- "Mike Beltzner" <belt...@mozilla.com> wrote:
> Clicking the star button twice would be the same as Accel-D, which
> would
> be the equivalent keyboard shortcut. I suppose we could do something
> like Accel-Alt-D for a keyboard equivalent for the one-click action.
Having a keyboard shortcut for the one-click action would be fantastic.
~ d
John Bird
wanting :)
As an outsider to the original design I am puzzled by why some things in
Firefox work as they do.....
Why is the bookmarks sidebar so different to the bookmarks menu?
Why does the bookmarks sidebar filter not show folders?
Why does the location bar autocompletion not show matches from bookmarks as
well as from history?
Why does the bookmarks filter not show matches from open tabs and history as
well as from bookmarks?
Why does adding a bookmark not show if or where this page might already be
bookmarked?
Why can't I keep my own notes related to a web page somehow that can be
found when I visit that page...
As a power user I am still puzzled at the actual differences between
starring, tagging, bookmarking etc.
I am guessing a star means the page is recorded in some way, either as a
bookmark or tag. Users can use either bookmarks or tags as they like. If
so this sounds a good and flexible idea - let users organise the way they
like.
Up to now to avoid putting lots of pages into bookmarks when I am only
interested in them for a day or two I just leave them open in tabs. That's
how I get 50-60 tabs open usually. A very inefficient and resource hungry
way to remember a page! This scheme should eliminate much of that!
I would however love to be able to make my own notes relating to a web
page.....like lots of people I will go searching a group of pages for
something (eg text editors or recipes or printers) and after reading all of
the dozens of matching pages I would like to be able to make quick notes
about what I like about each one to save me having to search and re-read all
the pages again. This could be like a memo/text field attached to the
bookmark and whenever I visit this page again I get say a little icon
appear, or a note on the status bar "you have notes about this page" and a
little button to show the notes...
Its sort of like a reverse rss feed, except it comes from me to me about the
web page...
(At present I copy and paste urls and my own notes into text files. I do
this a lot. I presume others do too)
> Metaphors aside, I think what we're trying to do is make it as easy
> as possible for users to record page locations so they can visit
> them again later. Off the top of my head, this involves four
> fundamental interactions:
>
> 1) Record the location of a page.
> 2) Add/modify the meta-data associated with that recorded location
> to improve findability.
> 3) Find and use that recorded location at a later time.
> 4) Delete recorded locations when they're no longer wanted.
>
John
Benjamin Smedberg
> If I'm parsing your comment correctly, you're saying that people don't
> use the bookmarks sidebar not the bookmark menu, as both have problems
> that make them useless for the user's needs. And optimizations for
> organizing and categorizing them might yield incremental improvements,
> but won't adequately solve the problem which. Is that right?
Yes.
Speaking from personal experience only:
I have "mouse memory" for the bookmarks in my personal toolbar. I dragged
them there to begin with, and I know exactly where to click to get at a
particular link. They are in my face: I know how to get to "Johnstown
Weather" or "GNU Make Reference" with two clicks. *Organizing* anything
beyond that would be a waste of my time.
> On this I think we agree, though I'm not convinced that putting bookmark
> search in the Search Bar is a good idea, as it blurs the line between
> "Search the Web" and "Search my set of bookmarks / starred pages".
> Perhaps, however, a search engine for "History and Bookmarks" could be
> added which opens the search sidebar. Or maybe we can always add "Seach
> History and Bookmarks" at the bottom of the suggestions drop-down.
Something like this, yes: probably I'd want to use the dropdown for quick
access by default: if it doesn't show up in the quick results I'd probably
use Google to re-find the page anyway.
> What I've been expecting (but what hasn't been called out in these
> mockups) is other ways in which we're going to leverage Places to
> promote bookmarked and starred results. For example, I'm expecting that
> typing text in location bar will show:
>
> --- matching URLs from history
> --- matching bookmarks / starred pages based on titles
> --- matches based on tags
Interesing that you would use the location bar: what I would interested in
for that is whether that bar displays the page URI (meaningless) or some
better recognition (title/tags/stars/...?)
--BDS
Benjamin Smedberg
> 1) "Record the location of a page" is currently being called both
> "starring" and "bookmarking". I do not see any difference between
> "starring" a page and "bookmarking" a page since fundamentally they are
> both the user saying "remember this URL".
I disagree. I think that "remember this page so I can click on it" and
"remember this page so I can search for it" are fundamentally different
concepts from the user POV.
> 4) "Delete" is fairly straightforward and is simply the user saying
> "forget this URL".
Sure, but it is much more important to delete bookmarks that "clutter the
UI" than to remove memory of interesting pages.
--BDS
Michael Lefevre
> Iteration 6: http://wiki.mozilla.org/Places:User_Interface/I6
>
> -To reduce overall visual complexity, the RSS and star icons use the
> visual variables of position and shape to different themselves, but
> not color. (mostly just wanted to see what it looked like, maybe just
> on the mac?)
But Mozilla has had a bit of campaign about using the standard icon, and
has published guidelines and encouraged others to follow them. It would
at least look a bit silly if Mozilla decided not to follow their own
guidelines less than a year after publishing them.
http://www.mozilla.org/foundation/feed-icon-guidelines/
"We believe that the color of the icon is an important visual cue for
people, and that arbitrarily changing the color could disrupt that cue and
could confuse users. ... We therefore recommend not changing the color of
the icon when it's used in the context of feed readers and related
products and services."
http://www.mozilla.org/foundation/feed-icon-guidelines/faq.html
--
Michael
Myk Melez
> While you might not see the difference here from the point of view of
> the model, I think the two interactions will feel very different to
> users, and the goal is that starring will result in users bookmarking
> more pages.
Based on personal experience (always a tricky base, to be sure) with the
existing system, I concur. Like bsmedberg, I put things onto my
bookmarks toolbar when I want to know exactly where they are because I
plan to use them frequently.
Otherwise, I only use bookmarks to "star" items, i.e. bookmark them
without regard for location and then search for them later using the
bookmarks sidebar search box.
And I will venture to say that when I search "starred" items I would
never expect to see items from my bookmarks toolbar in the search
results if I didn't already know they might show up because they happen
to share the same machine model. To me they seem like such different
beasts; I use them in completely different ways.
-myk
Myk Melez
> Alex Faaborg wrote:
>> should enable users to customize as much as they want.
>
> I think that's a terrible general principle. A lot of the changes of
> Firefox over the Suite were letting users customise less stuff. We have
> toolbar customisation, and that's fine, but I see nothing wrong with
> saying that the star is part of the URL bar, full stop.
I think it was less that Firefox let users customize less stuff as that
it *made* them customize less stuff, i.e. it didn't throw a lot of
complexity and decisions in users' ways. But it still gave (and gives)
them the power the power to customize to their heart's content (for the
most part) if they so choose.
This combination of both apparent simplicity and well-camouflaged power
is pretty key to the Firefox experience.
-myk
Jason Douglas
> people, and that arbitrarily changing the color could disrupt that cue and
> could confuse users. ... We therefore recommend not changing the color of
> the icon when it's used in the context of feed readers and related
> products and services."
> http://www.mozilla.org/foundation/feed-icon-guidelines/faq.html
I assume that original recommendation had more to do with changing the
color to match a site's theme rather than removing all color for the
purposes of interactivity. It is a change, but I don't think that's a
bad thing if it's motivated by a new use case.
However... it does beg the question of whether the feed icon will
"light up" like the star icon if I'm subscribed to that feed? Or will
it ever light up? If not, that would be very inconsistent with the
star icon sitting right next to it. And they really do belong to the
same family of actions.
Expanding on an argument made earlier in this thread, in fact, I think
there are many different "levels of commitment" that a user can have
to a website. At least:
1) Searchable -- I may want to reference it in the future
2) Accessible -- I'll be going back to it repeatedly
3) Subscribed/Notifiable -- I want to know as soon as anything changes
on it
4) Invokable -- I want to be able to send stuff to it (web service
content handlers in FFx3).
That last one may seem like a stretch right now, but I'm not so sure
it will down the road. My guess is that some users may have a hard
time understanding the difference between setting gmail as their home
page and setting it as their e-mail protocol handler... not too
mention subscribing to their inbox as a feed... or even setting google
as their default search engine!!
Not that I have a solution for this. :-) I just think starring/places
is so important, I wonder if it might not be better to push the feed
subscribing stuff down underneath it. I'm just worried that having it
at an equal weight in the UI will suppress usage of starring to the
whole clutter factor. And this coming from someone who spent the last
four years of their life working on a feed aggregator!
-jason