Closer to Final Places UI Spec
Ben Goodger
http://wiki.mozilla.org/Places:User_Interface
... there are a few open issues (ideas apppreciated!) but this is I
think pretty solid. This document is currently draft. I would like to
solicit feedback on it in the next couple of days so that we can push
forward planning the work required to implement the resulting solution
over the coming milestones.
-Ben
Brett Wilson
"""
When the user clicks on a folder to open it, the user is then able to
move their mouse around over other folders on the strip to open them,
without having to click again. This is especially useful for Live
Bookmarks on the toolbar where the user can quickly scan new postings
across several Live Bookmarks with a single gesture.
"""
I think this sounds really weird and confusing and will need some user
testing to see if they get freaked out. I also anticipate adjacent menus
overlapping so they are useless.
One thing I don't see is where the main places view resides. Tab? Popup?
New Window? Has there been any convergence on this?
I'm unclear on how you switch between tagging and filing modes. Tagging
mode appear from the star button but filing mode appears from the
bookmarks menu? I don't disagree that these could be different modes or
concepts, but the dialogs are so similar it doesn't reinforce this, and
I don't see why we need to arbitrarily limit what they can do based only
on how they got to the dialog. People may think the dialogs are the same
but is sometimes randomly missing the filing item.
I think having tags and "file into" may be confusing as well (though
I've come to agree with the overall approach). We will need to be very
careful about how this is presented. We should try to do some user
testing of people who are not users of bookmarks and some people who are
to see if they can figure out what is going on.
Brett
Adam Kowalczyk (Ancestor)
> One thing I don't see is where the main places view resides. Tab? Popup?
> New Window? Has there been any convergence on this?
New window: "The Organize button shows the Places Manager in a separate
window."
We discussed the overlay solution and I don't recall many opposing
arguments. Why was it dropped? How is a separate window better?
There is only one advantage of a new window that I can think of and it's
the ability to have the Places view in the background and switch between
browser and Places. However, I don't think that serves any common use
case and it doesn't reflect the usual workflow. Do users organize, then
browse, then organize some more? Anyway, similar ability can be achieved
with overlay by restoring the exact state of Places view after
collapsing it.
The downfalls of the separate window are far more significant. First of
all, user will have to manage, well, a separate window. Remember why the
tabs were introduced? Because switching between multiple windows of the
same application is painful. So if the ability to switch seems to be the
main reason to have a separate window then it makes it a poor reason. I
hated the separate window in the old Bookmarks Manager and I avoided it
as much as I could. It's not the way the rest of our UI works. User
never has to switch to a separate window apart from TM, EM and DM which
are more like popups.
I don't know much about Human Interface Guidelines but does a user
expect spawning a full-scale window for a component such an integral
part of an application and which isn't any more separate than others
which don't need a new window?
Opening pages from the new window is another issue. When user
double-clicks a page it opens in the main browser window. Is the Places
window closed? If it isn't user may have to switch back to it and close
it - awful. If it is closed then what's the point in a separate window?
I don't know how much space would overlay take but it could be possible
to keep the tabbar visible and user could do many things that can't be
achieved with a separate window like all kinds of dragging to Bookmarks
Toolbar, to tabbar etc. User would also have a visual feedback when he
opens pages in background. When in a new window, user cannot see the
effects when he middle-clicks the pages which reduces intuitiveness and
discoverability. And if user doesn't know he can open pages in
background he may end up opening them in foreground and switching
windows back and forth. I could go on with examples but this illustrates
the rationale enough.
Cheers,
Adam
Ben Goodger
> From the spec in the bookmarks toolbar section:
>
> """
> When the user clicks on a folder to open it, the user is then able to
> move their mouse around over other folders on the strip to open them,
> without having to click again. This is especially useful for Live
> Bookmarks on the toolbar where the user can quickly scan new postings
> across several Live Bookmarks with a single gesture.
> """
>
> I think this sounds really weird and confusing and will need some user
> testing to see if they get freaked out. I also anticipate adjacent menus
> overlapping so they are useless.
This is actually parity with Firefox 1.x. I need to rephrase this to
make it clearer.
> One thing I don't see is where the main places view resides. Tab? Popup?
> New Window? Has there been any convergence on this?
I think given what we can practically accomplish in the 2.x timeframe we
should go with new window. The browser window architecture needs to
improve a fair bit to allow this sort of thing more robustly before we
can bet the farm on it, sadly. I agree it'd be nice to have, but I think
some of the other usability enhancements are more worthy of spending
time on.
> I'm unclear on how you switch between tagging and filing modes. Tagging
> mode appear from the star button but filing mode appears from the
> bookmarks menu? I don't disagree that these could be different modes or
> concepts, but the dialogs are so similar it doesn't reinforce this, and
> I don't see why we need to arbitrarily limit what they can do based only
> on how they got to the dialog. People may think the dialogs are the same
> but is sometimes randomly missing the filing item.
I agree with your concerns about appearance and similarity. I expressed
these to beltzner, and he considers the actions completely distinct. I
wonder what presentational steps we can take to ensure the distinction
is clear. Mike?
> I think having tags and "file into" may be confusing as well (though
> I've come to agree with the overall approach). We will need to be very
> careful about how this is presented. We should try to do some user
> testing of people who are not users of bookmarks and some people who are
> to see if they can figure out what is going on.
Yes. See above. Hoping to hear more from Mike on this too.
-Ben
Mike Beltzner
> I think this sounds really weird and confusing and will need some user
> testing to see if they get freaked out. I also anticipate adjacent menus
> overlapping so they are useless.
This is actually parity with Firefox 1.x. I need to rephrase this to
make it clearer.
can bet the farm on it, sadly. I agree it'd be nice to have, but I think
some of the other usability enhancements are more worthy of spending
time on.
While I'm less clear on the technical limitations, I thought I'd chime in here and say that while indeed it would be nice to have this as a larger overlay, having it spawn a window won't be that unnerving (as it's a direct result of a click on a button with an elipses, which is UI-speak for "This is going to open a dialog of sorts") and will also be familiar to people who've gotten used to/suffered with our existing Manage Bookmarks UI.
> I'm unclear on how you switch between tagging and filing modes. Tagging
> mode appear from the star button but filing mode appears from the
> bookmarks menu? I don't disagree that these could be different modes or
> concepts, but the dialogs are so similar it doesn't reinforce this, and
> I don't see why we need to arbitrarily limit what they can do based only
> on how they got to the dialog. People may think the dialogs are the same
> but is sometimes randomly missing the filing item.
I agree with your concerns about appearance and similarity. I expressed
these to beltzner, and he considers the actions completely distinct. I
wonder what presentational steps we can take to ensure the distinction
is clear. Mike?
Well, we should make bookmarking about bookmarking and tagging about tagging. The historic reason for there being three levels of disclosure in the bookmarking UI was that we'd been thinking of merging the tagging and bookmarking metaphors. I think we've all agreed that was wrong-minded of us, and that we should be treating these systems as orthogonal as it allows tagging to augment the user's existing mental models instead of requiring them to learn a whole new system. So what I propose is that we drop the "tagging" -> "filing" -> "full disclosure" idea as well, and make it "tagging" || "light add bookmark" -> "heavy add bookmark".
The way for the user to get to tagging is to click the tag button in the URL bar. That should pop up something uber-light-weight in a bubble-like overlay ...:
--------. .------------------.(1) is where tags can be entered by a user; as I described in a previous thread, we can adopt an interaction model here where as a user types tags, the system tries to type-ahead match it with existing tags, a comma or an ENTER will mark the tag as complete, at which point it should be rendered differently as an encapsulated object (this is me shamelessly copying off of mail.app).
.com (+)| |> Go | [G] |
------.-' '------------------'
|\
| `-----------------------------------------.
| Tags: [ (Work), (Not Work), Oth_ ] | <-- (1)
| Notes: [ ben sent me this url ] | <-- (2)
| [ ] |
| |
| [Remove] [Add Bookmark] [Done] | <-- (3)
'-------------------------------------------'
(2) is a section for notes - I threw that in here for fun, but am not convinced of its value over just letting people tag things; the idea was a free-text notes section.
(3) remove and done are obvious; if the user decides that, after all, they want to create a bookmark, they can add a bookmark using the familiar "Add Bookmark" command. The bubble would disappear and the Add Bookmark dialog would appear. I would expect that any data in the tags would get automatically added to the bookmark UI.
This way, tagging is clearly distinguished from bookmarking, yet we make it easy for people to jump between the two systems.
I would also suggest that we drop the "tagging" UI proposed for the Add Bookmark dialog, and skip right to "filing". So an "Add Bookmark" action (keyboard shortcut, right-click, bookmark menu, button in the tagging UI) would bring up the following dialog:
+-----------------------------------------------+
| Name: [ Foo ] |
| Create in: [ Bookmarks Menu :^] | <-- (1)
| Tags: [ (Work), (Play) ] |
| > More |
| |
| ( Cancel ) ( Organize Bookmarks ) ( Add ) | <-- (2)
+-----------------------------------------------+
I've made a couple of label changes here, notably "Create In" (which is what we're using now, and seems sufficient) and "Organize Bookmarks" (which is what it will be called in the places search bar overlay, so we should be consistent there). I've also removed the "Location" field, as that can safely be saved for the "full disclosure dialog":
+-----------------------------------------------+Again, some changes here, including the same ones made above. I also tried to keep the ordering consistent, as well as the fact that the button should remain as "Add" :)
| Name: [ Foo ] |
| Create in: [ Bookmarks Menu :^] | <-- (1)
| Tags: [ Work, Play ] |
| |
| Location: [ http://www.foo.com/ ] |
| Shortcut: [ ] | <-- (1)
| Tip: Type the shortcut in the location bar |
| to open this page. |
| Notes: [ ] | <-- (2)
| [ ] |
| [ ] |
| |
| ( Remove ) ( Organize Bookmarks ) ( Add ) |
+-----------------------------------------------+
> careful about how this is presented. We should try to do some user
> testing of people who are not users of bookmarks and some people who are
> to see if they can figure out what is going on.
I am hoping that with this proposed design, the system will match user expectations. For those who are used to bookmarking, everything in bookmarking works like it did before, and now there's this "tag" field where they can add extra metadata. For those who like to play with new features, there's the tag button right in the URL bar. For those who click on that button but really just wanted to bookmark, there's a shiny "Add Bookmark" button right in the tagging UI.
Thoughts?
I'll look over the rest of the UI spec in a couple of hours ...
cheers,
mike
-------
mike beltzner, user experience lead, mozilla corporation
Mike Beltzner
reproduced it here again for easy cut'n'paste:
mockup of tagging UI:
--------. .------------------.
.com (+)| (->)Go | [G] |
------.-' '------------------'
|\
| `-----------------------------------------.
| Tags: [ (Work), (Not Work), Oth_ ] | <-- (1)
| Notes: [ ben sent me this url ] | <-- (2)
| [ ] |
| |
| [Remove] [Add Bookmark] [Done] | <-- (3)
'-------------------------------------------'
mockup of "add bookmark" UI (first level):
+-----------------------------------------------+
| Name: [ Foo ] |
| Create in: [ Bookmarks Menu :^] | <-- (1)
| Tags: [ (Work), (Play) ] |
| > More |
| |
| ( Cancel ) ( Organize Bookmarks ) ( Add ) | <-- (2)
+-----------------------------------------------+
mockup of "add bookmark" UI (second level):
+-----------------------------------------------+
| Name: [ Foo ] |
| Create in: [ Bookmarks Menu :^] | <-- (1)
| Tags: [ Work, Play ] |
| |
| Location: [ http://www.foo.com/ ] |
| Shortcut: [ ] | <-- (1)
| Tip: Type the shortcut in the location bar |
| to open this page. |
| Notes: [ ] | <-- (2)
| [ ] |
| [ ] |
| |
| ( Remove ) ( Organize Bookmarks ) ( Add ) |
+-----------------------------------------------+
back to the rest of the review (see next post)
Mike Beltzner
>A new customizable button is added to the left of the Bookmarks Toolbar
>entries and is called "Search History and Bookmarks". (Displaying this text
>in a tooltip, showing only an icon). (XXX open issue: what to show as the
>text when this button is dropped onto a toolbar that is showing labels, too)
Maybe "Find Places" or "Bookmark Search"? Out of curiousity, do we
even want to make this button a standard toolbar button, since we're
doing some funky new UI stuff to render the overlay as being visuall
connected to the button?
>2.1.1.3: Search Results
>The user can type some terms into the field, autocompleted according to
>the semantics defined in the Autocomplete Fields section. When they do
>this, after a short delay (to prevent excessive querying) results are
>displayed in the popup:
nit: we should point out how search results are ranked somewhere. This
is touched on in the "Autocompelte Fields" section, but when I was
reading this document, I felt like I was left wondering where this was
going to be defined.
>XXX open issue: show the URL below the title, for disambiguation for
>poorly titled pages)
Yes, I agree that we should show the URL, but let's de-emphasize it by
rendering it in a smaller font, and in a light grey shade of text or
something so that it's information that will disambiguate on deep
scan, but won't interfere with a quick visual scan.
Another open issue in my mind is how (if at all) we represent the tags
that a user has assigned to a search result. Perhaps each result
should look something like this:
..............................
[=] The Goat Teleporter & You <-- (1)
http://www.goatweekly <-- (2)
..............................
(1) This line contains an icon that looks like a little page with
notes [=] for pages that are tagged; when a user hovers over this
icon, the tags for that page are listed. If the page was bookmarked,
the favicon for the site is listed, and a mouse hover shows the
containing folder. The line also contains the name of the page, which
is overridden by the name of the bookmark if the item is a bookmark.
(a11y note: when this row is selected, the tag/bookmark data can be
sent to screen readers)
(2) the url, displayed in a smaller, light grey font
>2.1.2: Places Popup
The three open issues in this section all have to do with selecting
the root query to be used for the search. A slight tweak to the design
of the dialog might make this more straightforward:
|#@=#| / PTBookmark 1 / PTBookmark 2 / PTBookma...
| +----------------------------+
| Search [ @ Bookmarks :^] | <-- (3)
| [ ] | <-- (1)
| |
| +-----------------------------+ |
| | / Foo | | <-- (2)
| | / Bar | |
| | # Baz | |
| | / FooFoo | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| +-----------------------------+ |
| |
| ( Organize... ) ( << ) | <-- (4)
+---------------------------------+
all I've done is combined the "showing" selector with the search box
so that the subject-object relationship between the fields is a little
more clear and the fields themselves are co-located. By default I
think the query should be "All Bookmarks", but the selection should be
sticky and persist across sesions.
>2.1.3: Bookmarks Menu
>3. Show the Places Search Popup for quick searching of Bookmarks and
>History. (XXX open issue: keybinding)
The suggestion of Ctrl/Cmd-B makes a lot of sense to me. Amongst other
things, it provides a graceful migration for people who are used to
the Bookmarks Sidebar :)
A keybinding for tagging needs to be found, though. Ctrl/Cmd-E (for
proximity to D)?, Ctrl/Cmd-H for "History tagging"?
>XXX open issue: insert items into this list in reverse-chronolgical?
It should behave like it does now, unless there are longstanding and
well reasoned requests to change. It might be a nice-to-have to add a
context menu action for "Sort list" (a la IE) for quick
alphabetization within folders.
>XXX open issue: how to handle a long list here? scroll (status quo,
>IE-compat)? overflow into submenus?)
Adobe/Apple used to use the overflow-into-submenus trick, and it was
pretty wonky; enough so that they switched away. FWIW, I'm not that
concerned with trying to solve the "huge unsorted pile of bookmarks"
problem as we'll be providing lots of mechanisms for that type of
bookmark to be handled as a tag.
>XXX open issue: if Bookmark this Page... bookmarks into the Bookmarks Menu
>and the tag button does not, should the Bookmark this Page... menu item go
>at the end of the list to show that it applies to this list (and
>potentially other lists)? Ditto Bookmark all Tabs?
The menu items seem very sensible the way you have them presently laid
out. As mentioned in a previous post, I want to be firm on our
seperate treatment of bookmarks and tags. I'm not even sure that we
want to put a menuitem for tagging this page in the bookmarks menu as
opposed to in the "History" menu.
>XXX open issue: it is not clear that Bookmark this Page is different from
>the star button.
Discussed in previous post. I think that this will be quite clear by
virtue of the fact that bookmarking will maintain all of the familiar
UI, and tagging will just become this mechanism for tagging your
history.
>2.1.4: History Menu
>Keyboard accessible link to Home Page (XXX open issue: where should this
>go?)
Hm. Do we really need a menuitem for loading the home page? Maybe just
include the keyboard shortcut in the home button tooltip? "Home"
doesn't really fit into a "History" menu, and I don't think it's a
valuable enough function to survive just because it was there in the
"Go" menu.
>2.1.5.1: Grouping Heuristic
This seems like a pretty big open issue. I like the idea behind the
pivot, although I'm always of the opinion that forward links are less
likely to be interesting than back ones, and so I would weight the
pivot to be further towards the "future" side of a timeline instead of
being right in the middle. We should have a fallback plan in case we
can't contain the work required to get this heuristic right. If I'm
following, it would behave like SnapBack, but better; I think that's
an admirable goal, but one that's not neccessary as part of the core
Places UI bits.
>2.1.6: Bookmarks Toolbar
>1. XXX open issue: this is probably uber-geek but fits with ideas i've
>heard people discussing. Shows a dialog that lets the user choose a folder
>or Place: query to root the toolbar on. This may let the user root their
> toolbar on a delicious folder, for instance, with a delicious extension
> installed. Related to this, it may be interesting to allow the
> instantiation of N instances of the Bookmarks toolbar to show the content
> of different folders.
So, I'm with you on letting users add/remove 1..N bookmark toolbars.
That's a pretty common support request, and one of the most common
non-IE-parity nuisances for switching users. We should probably
support this through actions like "Add New Bookmarks Toolbar" and
"Remove Bookmarks Toolbar" (this latter one with a confirmation).
The "Change Folder..." function seems really geeky to me, and I'm not
sure how frequently someone would want to switch the root folder as
opposed to setting it once per toolbar. Maybe as part of the "Add New
Bookmarks Toolbar" one of the options (the only option?) in a creation
dialog could be to set the root folder / pick from an online service
(this wouldn't be provided by us, but would be a good integration
point for an extension).
>2.1.7: Places Organizer
> (Subsequent captures will show only the view area, excluding the toolbar
> and menu)
The first ASCII mockup seems to be missing the search box in the left
hand side, and I'm not clear on what the [@ Search Bookmarks & History
] bit in the toolbar means. I would expect the toolbar to have
functions for adding / removing folders, and maybe creating new search
folders (as an alternate way to do that since users will likely look
for it by name instead of assuming that they need to start a search
first -- although I think that's the better way of doing things; users
can be dumb :)
>2.1.7.1: Places List
Hm, I know we talked about this on IRC, so now you get to experience
the first case of me totally reversing my opinion without any warning!
I often find it useful to quote Ashleigh Brilliant at times like this
("My opinions may have changed, but not the fact that I am right.")
Continuing on my crusade to make tagging == marking a page in one's
history as interesting, I no longer think that a good metaphor for a
tagged page is a "bookmark that isn't in a bookmark folder or menu".
As such, listing those pages in the "All Bookmarks" list seems wrong.
Further, the need for such a list seems redundant (as we'll have the
Bookmarks Menu list). I humbly propose the static list be:
* All Bookmarks & History
* Bookmarks Menu
* Bookmarks Toolbar
* Subscriptions
This has the bonus advantage of being consistent with the search
overlay dialog ("Search Bookmarks & History"), etc.
>In the user-editable area:
>
> * Most often visited
> * Any place: query that could equally have been generated by the user
> using the Save Search Query functionality.
> * User created Folders
I would suggest that the pre-constructed smart folders we put here
should be: "Most Often Visited", "Recently Added", "Today", "This
Week", "This Month". The "Any Place" folder might end up being
confusing, since it's a useless example of a smart folder (and
duplicates the All History & Bookmarks folder) so I'd recommend we
leave it out.
>2.1.7.2.1: Grouping Options
This might be better handled with a single checkbox:
[ ] Group by Site
which toggles the grouping by domain on/off. Listing them as a flat
list isn't technically a grouping, and dropping a togglebutton saves
us UI space and declutters.
>2.1.7.3.1: Searching
The first ASCII mockup should probably reflect the list (if one is
being used) across which the search is occuring. So the top bit would
look like:
+-----------------------------------------------------------------------+
| +----------------------+ +------------------------------------------+ |
| |[ foo| ]| | Results for 'foo' in History: ( Save )(+)| |
| | @ History | |==========================================| |
>2.1.7.3.2: Advanced Search
This stuff is great, by the way, and I think will quickly become a
much loved feature of Firefox2. I'm kinda drooling in anticipation of
using it myself :)
>Link is [x] a bookmark [x] a subscribed feed [x] a blog post or news item
Maybe "an item inside a subscribed feed" as the label for the last
item, instead, since some feeds are neither blog posts or news items?
>2.1.7.4: Subscriptions
Same comment about using a single checkbox instead of two
togglebuttons for the grouping options.
>2.1.7.5: Browsing By and Changing Tags
>XXX open issue: is this the right UI?
>XXX open issue: which is the default panel?
I think that the searchbox at the top of the left side pane should act
as a filter that responds to keywords and tags, so we wouldn't need
this panel to act as a filter of its own. But, I like the idea of it
being there as an inspector to show the tags that exist across the
selection, and the default mode can be that it's viewing tags and
letting the user edit them. So no need for the explicit [Edit] button.
Speaking of which, we'll need to render tags that apply to ALL of the
currently selected items differently from tags that apply to at least
one of the selected range. There are pretty well established ways of
doing this, like just rendering it in a lighter text colour.
+------------------------------------------+
| Tags: [ ] (x)| <-- (1)
| [ ] |
| [ ] |
+------------------------------------------+
(1) perhaps a close button to hide the tag viewer? it could be brought
back from a menuitem in the "View" menu.
>2.1.7.6.3: View Menu
As per previous comment, we'd need to add an entry for the tag viewer ...
+------+
| View |
| +-----------------------+
| Reload Ctrl+R |
| ---------------------------- |
| x Toolbar |
| x Tag Viewer |
| Show Columns > |
| ---------------------------- |
| * Unsorted |
| Sort by Title |
| Sort by Location |
| <cols> |
+------------------------------+
>2.1.8: Tag Autocompletion
>From a previous post of mine, here's a proposed interaction/design for
how we render the autocomplete:
Interaction Model:
------------------
S1: wait for input [ (any letter) = S2 | (enter) = S5 ]
S2: accept label input & show drop-down [ (any letter) = S2 |
(any arrow) = S3 |
(enter) = S4) ]
S3: move in drop down [ (any letter) = S2 | (any arrow) = S3 |
(enter) = S4 ]
S4: compete label input, insert comma [ ==> S1 ]
S5: save & exit
[1] Tags: [ ]
[2] Tags: [ f ]
[3] Tags: [ fo ]
.--------------------.
| foo |
| foo fighters |
| food |
| football |
'--------------------'
[4] Tags: [ fo ]
.--------------------.
|=foo================|
| foo fighters |
| food |
| football |
'--------------------'
[5] Tags: [ (foo) ]
>2.1.9: Search Result Ranking
Just to throw in my $0.02, I would say that bookmarking > tagging >
number of visits > general history.
> 2.1.10.1: Add Bookmarks Dialog
See previous posts in this thread.
> 2.1.10.2: Filing Bookmarks
> XXX open issue: is filing into any folder in this way a good idea? What
> are the usage figures on drag and drop? This could be a way for folk to
> discover they can file into folders on the bookmarks toolbar.
I think drag and drop is important to keep. It's not discoverable,
sure, but people generally try to drag and drop things in this
mouse-centric world. What we need to do is make sure that the mouse
turns into a hand as it hovers over the favicon in the URL bar or the
bookmark entry in a list so that users realize that they can indeed
drag the thing underneath their cursor.
> 2.1.10.3: Marking Pages as Interesting
See previous posts in this thread.
> 2.1.11: Content Area Integration
> XXX open issue: is this a good idea? Where does this file into by
> default? The Menu? What about "Mark page as interesting" functionality?
Definitely a good idea, and maintains parity with Firefox 1.x
functionality. I don't think we need to add a "Mark page as
interesting" context entry, though - let's (for now) assume that path
to be purely cued off of the URL bar.
> 2.1.12: Tabbed Browsing Integration
> XXX open issue: is this a good idea? Where does this file into by
> default? THe Menu? What about "Mark page as interesting" functionality?
Ditto as 2.1.11.
Whew. Thanks for all the hard work in writing up the document, Ben.
Going over it, I feel pretty confident that we've got a good thing
going here. We should talk next week about what sort of early paper
prototyping we want to do for usability tests.
cheers and good night,
mike
Mike Connor
> I'm unclear on how you switch between tagging and filing modes. Tagging
> mode appear from the star button but filing mode appears from the
> bookmarks menu? I don't disagree that these could be different modes or
> concepts, but the dialogs are so similar it doesn't reinforce this, and
> I don't see why we need to arbitrarily limit what they can do based only
> on how they got to the dialog. People may think the dialogs are the same
> but is sometimes randomly missing the filing item.
I agree with your concerns about appearance and similarity. I expressed
these to beltzner, and he considers the actions completely distinct. I
wonder what presentational steps we can take to ensure the distinction
is clear. Mike?
Well, we should make bookmarking about bookmarking and tagging about tagging. The historic reason for there being three levels of disclosure in the bookmarking UI was that we'd been thinking of merging the tagging and bookmarking metaphors. I think we've all agreed that was wrong-minded of us, and that we should be treating these systems as orthogonal as it allows tagging to augment the user's existing mental models instead of requiring them to learn a whole new system. So what I propose is that we drop the "tagging" -> "filing" -> "full disclosure" idea as well, and make it "tagging" || "light add bookmark" -> "heavy add bookmark".
The way for the user to get to tagging is to click the tag button in the URL bar. That should pop up something uber-light-weight in a bubble-like overlay ...:
--------. .------------------.
.com (+)| |> Go | [G] |
------.-' '------------------'
|\
| `-----------------------------------------.
| Tags: [ (Work), (Not Work), Oth_ ] | <-- (1)
| Notes: [ ben sent me this url ] | <-- (2)
| [ ] |
| |
| [Remove] [Add Bookmark] [Done] | <-- (3)
'-------------------------------------------'
(2) is a section for notes - I threw that in here for fun, but am not convinced of its value over just letting people tag things; the idea was a free-text notes section.
(3) remove and done are obvious; if the user decides that, after all, they want to create a bookmark, they can add a bookmark using the familiar "Add Bookmark" command. The bubble would disappear and the Add Bookmark dialog would appear. I would expect that any data in the tags would get automatically added to the bookmark UI.
This way, tagging is clearly distinguished from bookmarking, yet we make it easy for people to jump between the two systems.
I would also suggest that we drop the "tagging" UI proposed for the Add Bookmark dialog, and skip right to "filing". So an "Add Bookmark" action (keyboard shortcut, right-click, bookmark menu, button in the tagging UI) would bring up the following dialog:
+-----------------------------------------------+
| Name: [ Foo ] |
| Create in: [ Bookmarks Menu :^] | <-- (1)
| Tags: [ (Work), (Play) ] |
| > More |
| |
| ( Cancel ) ( Organize Bookmarks ) ( Add ) | <-- (2)
+-----------------------------------------------+
I've made a couple of label changes here, notably "Create In" (which is what we're using now, and seems sufficient) and "Organize Bookmarks" (which is what it will be called in the places search bar overlay, so we should be consistent there). I've also removed the "Location" field, as that can safely be saved for the "full disclosure dialog":
+-----------------------------------------------+
| Name: [ Foo ] |
| Create in: [ Bookmarks Menu :^] | <-- (1)
| Tags: [ Work, Play ] |
| |
| Location: [ http://www.foo.com/ ] |
| Shortcut: [ ] | <-- (1)
| Tip: Type the shortcut in the location bar |
| to open this page. |
| Notes: [ ] | <-- (2)
| [ ] |
| [ ] |
| |
| ( Remove ) ( Organize Bookmarks ) ( Add ) |
+-----------------------------------------------+
Again, some changes here, including the same ones made above. I also tried to keep the ordering consistent, as well as the fact that the button should remain as "Add" :)
Ben Goodger
> I haven't really read the rewritten spec yet, but I'm not a huge fan of
> an always-on icon in the URL bar. Because we default to nothing there,
> the presence of an icon is more discernible than if you're having to
> filter out always-present icons.
I think Mike meant the not-status area, more the clickable area.
> Notes is pretty similar to bookmark description, and we've started using
> some page metadata to prefill this for bookmarking. Do we want to
> prefill this information when tagging? (would be useful for searches,
> certainly)
I was not aware of this - how is metadata prefilled?
> I'd like to make Remove show as Cancel if there isn't existing data,
> since that is what users will probably look for at that point. I'm also
> curious as to why Remove matters at all.
I think the spec makes note of this, at least indirectly. As to why
Remove exists, to allow you to un-mark something if you hit the button
mark button by accident.
> Assuming you want the Organize Bookmarks button to close the dialog,
This raises an excellent question. If the button closes the dialog, then
what happens to the add transaction? Is it canceled? Does the bookmark
get added? Eek!
> this should be workable, if strange, but if it opens a new window and
> doesn't close, there's all kinds of hurt with modal things we'll have to
> work around, as well as dynamically changing the contents of Create In
> to reflect folder deletions/additions.
Not necessarily, given that these views populate themselves when they're
shown right now. Are there modality problems when a non-modal window is
opened with a null parent? (e.g. ww.openWindow(null, ...))
> If we have to add a descriptive line explaining what "shortcut" is, can
> we just reuse the "keyword" term, which separates us from the
> modifer+key action that I immediately assumed you meant here. I'm also
> guessing you mean "cancel" instead of Remove here.
Shortcut isn't necessarily the best term, but given the function it's
better than keyword, which is more often used outside of this problem
space as a categorization term (like tags!)
-Ben
Ben Goodger
> Maybe "Find Places" or "Bookmark Search"? Out of curiousity, do we
> even want to make this button a standard toolbar button, since we're
> doing some funky new UI stuff to render the overlay as being visuall
> connected to the button?
I don't understand - do you mean it should have some kind of different
appearance? What would you suggest?
> |#@=#| / PTBookmark 1 / PTBookmark 2 / PTBookma...
> | +----------------------------+
> | Search [ @ Bookmarks :^] | <-- (3)
> | [ ] | <-- (1)
This definitely makes the streamlined popup (non-expanded) more
heavyweight. Is it too much so?
> This seems like a pretty big open issue. I like the idea behind the
> pivot, although I'm always of the opinion that forward links are less
> likely to be interesting than back ones,
True. I think there's value in investigating this general issue though
if we can. It may have higher payoff in terms of every day
browsing/navigation than many other features discussed here. We could
hardly do much worse than the existing Go menu contents at any rate!
> The first ASCII mockup seems to be missing the search box in the left
> hand side, and I'm not clear on what the [@ Search Bookmarks & History
> ] bit in the toolbar means. I would expect the toolbar to have
> functions for adding / removing folders, and maybe creating new search
> folders (as an alternate way to do that since users will likely look
> for it by name instead of assuming that they need to start a search
> first -- although I think that's the better way of doing things; users
> can be dumb :)
Maybe my ascii isn't clear enough... anytime I do [ ] I mean "text
field"... anytime I do ( ) I mean "button"... that thing on the
toolbar is a search field. Now we have more screen real estate
(standalone window) it seemed ok to shift this up and out.
>> * Any place: query that could equally have been generated by the user
>> using the Save Search Query functionality.
> The "Any Place" folder might end up being confusing, since it's a useless
> example of a smart folder (and duplicates the All History & Bookmarks
> folder) so I'd recommend we leave it out.
Clarification: by "Any place: query" I didn't mean one query that
contains all others, I meant any other thing similar to "Recently
Visited" "Recently Added" etc that the user could have generated for
themselves using the query builder, but which we predefine. Similar to
iTunes' "90s music" "Rock" etc.
>> 2.1.7.5: Browsing By and Changing Tags
>> XXX open issue: is this the right UI?
>> XXX open issue: which is the default panel?
>
> I think that the searchbox at the top of the left side pane should act
> as a filter that responds to keywords and tags, so we wouldn't need
> this panel to act as a filter of its own.
How do you see _all_ tags? Is this important? If I have a tag similar to
one I'm about to use, I'd rather use the existing one. Maybe this isn't
a problem. Or maybe I'm thinking too much like folders again, but in the
absence of AI munging...
>> 2.1.9: Search Result Ranking
>
> Just to throw in my $0.02, I would say that bookmarking > tagging >
> number of visits > general history.
So, I've been in discussions about this before. Say I visit a page 20
times a day but never thought to bookmark it. Should something that I
bookmarked because it was interesting in Firefox 1.x or marked as
interesting in 2.0 trump it, even though those pages have less visits? I
think this ranking determination might need more detail.
>> 2.1.10.2: Filing Bookmarks
...
> I think drag and drop is important to keep.
Clarification: not suggesting we remove it.
-Ben
Mike Beltzner
>I haven't really read the rewritten spec yet, but I'm not a huge fan of an
>always-on icon in the URL bar. Because we default to nothing there, the
>presence of an icon is more discernible than if you're having to filter
>out always-present icons.
Good point, Mike. This button/indicator should be in a space reserved
for clickable entities.
>I'd like to make Remove show as Cancel if there isn't existing data, since
>that is what users will probably look for at that point. I'm also curious
>as to why Remove matters at all.
Well, there needs to be some way to untag a page, I think. I'm not
sure I like the idea of the button being state-dependant, though. We
could do it that way for now and see if it feels wierd later.
>I'd much rather morph, OS X prefwindow style, into the add bookmark UI
>somehow, instead of a separate dialog, since that'd feel like a more
As long as the morph ends up with the same dialog that someone arrives
at using any of the other "Add Bookmark" tools (keyboard shortcut,
menuitem, button in the Organizer UI) that'd be fine. I'm always a fan
of visual momentum to emphasize transitions.
>would be a bit jarring. Also, if I'm entering data, and I hit Add
>Bookmark, I might well expect that to just create the bookmark given
>button position etc.
Quite right. That button should be [Add Bookmark...]
>Assuming you want the Organize Bookmarks button to close the dialog, this
>should be workable, if strange, but if it opens a new window and doesn't
[...]
>some of the same issues to implement Create in as an editable menulist so
>people can file in "foo" and if the folder "foo" doesn't exist we'll
>create it.
Good points. Ben's "Eek!" seems to agree with you, so let's drop the
[Organize...] button from this dialog (it does seem like a separate
task)
>If we have to add a descriptive line explaining what "shortcut" is, can we
>just reuse the "keyword" term, which separates us from the modifer+key
>action that I immediately assumed you meant here. I'm also guessing you
>mean "cancel" instead of Remove here.
The tip should be removed; deciding to change from "keyword" to
"shortcut" is an orthogonal decision, IMO. We shouldn't be putting
help text directly into the UI. Nice catches here, again.
On Feb 23, 2006 at 2:54 PM Mike Connor wrote (accidentally just to me):
>> Maybe "Find Places" or "Bookmark Search"? Out of curiousity, do we
>> even want to make this button a standard toolbar button, since we're
>> doing some funky new UI stuff to render the overlay as being visuall
>> connected to the button?
>
> I would just make it part of the bookmark toolbar binding, unless we
> get feedback that it would be a real benefit to it being separated.
> Moving it away from the rest of the places bits seems about as
> interesting as putting the Go button anywhere but attached to the
> location bar.
I'm in agreement with this. Ben, any objections here? I know we were
talking about this in IRC a while back ...
>> Another open issue in my mind is how (if at all) we represent the tags
>> that a user has assigned to a search result.
>
> Why would we? The goal of tagging aiui is to help find things again,
> if you've found them, the tagging data isn't especially useful. This
> seems pretty heavy, especially for screen readers.
I'd been thinking that it might help a user see related tags which
they could then use to expand their search query. It does increase
clutter though, which is why I was asking. If you guys don't see a
strong value in it, let's just drop the idea.
>> A keybinding for tagging needs to be found, though. Ctrl/Cmd-E (for
>> proximity to D)?, Ctrl/Cmd-H for "History tagging"?
>
> We've avoiding Accel-E because its in between things that cause
> dataloss (Close tab and reload)
>
> Cmd-H would be a learning curve for those who used the history
> sidebar, but it's not insurmountable.
And since again we're talking about associating tagging with history,
I don't think that modifying this keybinding will be disastrous. It's
either that or using B for creating a tag and H for bringing up the
bookmark and history search ... the latter seems backwards to me.
>> Hm. Do we really need a menuitem for loading the home page? Maybe just
>> include the keyboard shortcut in the home button tooltip? "Home"
>> doesn't really fit into a "History" menu, and I don't think it's a
>> valuable enough function to survive just because it was there in the
>> "Go" menu.
>
> Putting the keyboard shortcut as a tooltip makes it impossible to
> discover for people using the keyboard (see the bugs on Ctrl-Enter
> for Find Toolbar highlight)
Let's start with the base question before we worry about a11y
concerns. Is it the right thing for the "Home" menuitem to be in the
"History" section. I don't think it is, really. Maybe we shove it into
the "View" menu with the other "didn't know where to put these
menuitems" like Stop and Reload. Or maybe we just don't put those
anywhere by default and think about better ways of supporting those
tasks for a11y.
On 2/23/06, Ben Goodger <bengo...@gmail.com> wrote:
> Mike Beltzner wrote:
> > Maybe "Find Places" or "Bookmark Search"? Out of curiousity, do we
> > even want to make this button a standard toolbar button, since we're
> > doing some funky new UI stuff to render the overlay as being visuall
> > connected to the button?
>
> I don't understand - do you mean it should have some kind of different
> appearance? What would you suggest?
I was speaking more of whether or not we'd let this button be, like
other toolbar buttons, an item that can be moved between toolbars. The
other option is to make it a staticly placed UI element that is either
there or not there, but can't be placed anywhere else.
> > |#@=#| / PTBookmark 1 / PTBookmark 2 / PTBookma...
> > | +----------------------------+
> > | Search [ @ Bookmarks :^] | <-- (3)
> > | [ ] | <-- (1)
>
> This definitely makes the streamlined popup (non-expanded) more
> heavyweight. Is it too much so?
This would only be in the "popup" form, so one level of disclosure
deeper than the streamlined version. All I did was merge the "Showing"
field that you'd had specc'd out at the bottom of that UI with the
label at the top. I think it'll end up being lighter-weight, actually.
> > This seems like a pretty big open issue. I like the idea behind the
> > pivot, although I'm always of the opinion that forward links are less
> > likely to be interesting than back ones,
>
> True. I think there's value in investigating this general issue though
> if we can. It may have higher payoff in terms of every day
> browsing/navigation than many other features discussed here. We could
> hardly do much worse than the existing Go menu contents at any rate!
You'll get no argument from me there. As a low-bar, setting domain
names as the "chapter stops" seems sensible to me. We could do some
quick heuristic analysis on the types of section-formatting that
exists in most complex websites (like cnn.com/news vs. cnn.com/money)
and see if we can come up with ways of setting chapter stops for
those, too.
> >> 2.1.7.5: Browsing By and Changing Tags
> >> XXX open issue: is this the right UI?
> >> XXX open issue: which is the default panel?
> >
> > I think that the searchbox at the top of the left side pane should act
> > as a filter that responds to keywords and tags, so we wouldn't need
> > this panel to act as a filter of its own.
>
> How do you see _all_ tags? Is this important? If I have a tag similar to
> one I'm about to use, I'd rather use the existing one. Maybe this isn't
> a problem. Or maybe I'm thinking too much like folders again, but in the
> absence of AI munging...
I don't know if it's important to see all tags, or at least, if it's
important enough to put in the primary UI vs. letting an extension
present a cool "tag soup" or something. We'll have type-ahead
matching, which I suppose we could use as a way of getting a drop-down
that's populated with all existing tags. I think you are thinking a
little bit like folders, but it's probably going to be a pretty common
request.
> >> 2.1.9: Search Result Ranking
> >
> > Just to throw in my $0.02, I would say that bookmarking > tagging >
> > number of visits > general history.
>
> So, I've been in discussions about this before. Say I visit a page 20
> times a day but never thought to bookmark it. Should something that I
> bookmarked because it was interesting in Firefox 1.x or marked as
> interesting in 2.0 trump it, even though those pages have less visits? I
> think this ranking determination might need more detail.
Agreed. I'm sure that there are some well established algorithms at
your disposal for ranking search results. ;)
cheers,
Brett Wilson
>>one I'm about to use, I'd rather use the existing one. Maybe this isn't
>>a problem. Or maybe I'm thinking too much like folders again, but in the
>>absence of AI munging...
>
>
> I don't know if it's important to see all tags, or at least, if it's
> important enough to put in the primary UI vs. letting an extension
> present a cool "tag soup" or something. We'll have type-ahead
> matching, which I suppose we could use as a way of getting a drop-down
> that's populated with all existing tags. I think you are thinking a
> little bit like folders, but it's probably going to be a pretty common
> request.
Personally, I think it's very important to see all tags. I am of the
more foldery persuation, but personally I would be pretty confused if my
list of tags wasn't obviously presented somewhere easy-to-get to.
It keeps getting brought up (though maybe not in this specific email)
that the way to get at tags is by searching. This makes no sense to me.
How do I explain to new users "where their tags are?" How do I remember
that the tag I'm using for researching my new purchase is "monitor" and
not "screen"? The theory behind tagging is all fine, but it doesn't get
around the fact that many people just want to see a list of what they have.
I firmly believe most people, even advanced users, will have relatively
few tags which will be fine to display in a list in the primary UI. Even
5% of users having more than 30 tags would be huge. The primary design
should be for this common case. The fact that the list isn't useful when
you have 1000 tags should not be a reason not to do it. We should have
other useful capabilities for that minority.
Sorry if I'm sounding repedetive or not understanding something.
Brett
Dietrich Ayala
The popularity of tag clouds is a good example of a general desire to *browse* tags.
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>
Mark Pilgrim
There are a few areas of the new spec that concern me, from an
accessibility perspective. Of course, there's only so much detail I
can glean from prose and ASCII art, but these are the things that
jumped out at me from my initial reading.
- I'm concerned about the "disclosure" widget in the Places Search
Popup, first mentioned here:
http://wiki.mozilla.org/Places:User_Interface#Searching. Please make
sure that this widget is a real button that can receive focus by
tabbing.
- [top priority] Furthermore, I'm concerned in general with this UI
concept of a complex overlay that isn't a separate window, which
auto-expands and contracts based on autocompletion in a text box.
Presumably the "Search bookmarks/history" menu item will open the
overlay and set focus to the search box within the Places Popup. But
once they starts typing, how would a blind user know that there are
any results being shown?
Related: I am concerned about this sentence: "When the disclosure
button in the Places Search Popup is clicked, the popup changes to
show the contents of a selected Place." Again, in the absence of any
window or context change, how would a blind user know that there is a
completely different UI in place of the previous one?
- [2nd priority] Date pickers in the advanced search form. The new
specs states that "these are non-user-editable static date fields.
When the user clicks in the field, a calendar picker is shown." I was
surprised to learn that this functionality exists in the current CVS
code as well. The reason I never noticed it is that in the current
CVS code, the date field is an editable text box; I never thought to
click the box itself, I just typed some dates and it worked as
expected. But the new spec states that the date will *only* be
editable via a separate calendar widget. This brings up two issues:
(a) how does the user open the date picker with the keyboard, and (b)
how does the user navigate the date picker with the keyboard. The
former may be a non-issue, if there is a separate button next to the
date display that you can activate with the space bar. The latter is
a serious issue and will need to be resolved. (A satisfactory
resolution would be to convert the date field back to an editable text
box and let users type dates in some predetermined format, as in the
current CVS code. I understand there are locale issues with this.)
- [3rd priority] I don't see any keyboard-accessible way to mark a
page as interesting. The only UI for this feature seems to be
clicking a button-within-the-urlbar, which is not accessible from the
keyboard. (This may end up being a non-issue if "marked as
interesting" turns into "auto-tagged with a specific keyword", since
the user could just use the 'heavyweight' "Add bookmark" dialog and
tag it themselves to accomplish the same thing.)
Other (smaller) potential issues:
- I don't see any mention of how one would move bookmarks from one
folder to another without drag-and-drop. I filed a bug about this
against the current CVS code, and suggested Accel-X/Accel-V, which
someone agreed ought to work. (This is how you move files between
folders in Windows Explorer, for example.) That would be a
satisfactory resolution, as long as it was documented in the Places
help topic. There are undoubtedly other solutions. I would feel
warmer and fuzzier if the new spec explicitly stated which solution we
intend to support.
- Under "Subscriptions", the following sentence concerns me: "Should
also show read state (bold = unread, normal = read)" First of all,
hooray for not relying on color alone to make this distinction, but
second of all, we should ensure that the read/unread status is exposed
somehow to screen readers. For example, we could have a separate
column that showed a little icon for the read/unread status, and the
icon could have an accessible name that indicated the status. Or we
could check the OS-level bit that tells you whether a screenreader is
active, and if so, prefix the name of the item with "read:" or
"unread:".
--
Cheers,
-Mark
Brett Wilson
> specs states that "these are non-user-editable static date fields.
> When the user clicks in the field, a calendar picker is shown." I was
> surprised to learn that this functionality exists in the current CVS
> code as well. The reason I never noticed it is that in the current
> CVS code, the date field is an editable text box; I never thought to
> click the box itself, I just typed some dates and it worked as
> expected. But the new spec states that the date will *only* be
> editable via a separate calendar widget. This brings up two issues:
> (a) how does the user open the date picker with the keyboard, and (b)
> how does the user navigate the date picker with the keyboard. The
> former may be a non-issue, if there is a separate button next to the
> date display that you can activate with the space bar. The latter is
> a serious issue and will need to be resolved. (A satisfactory
> resolution would be to convert the date field back to an editable text
> box and let users type dates in some predetermined format, as in the
> current CVS code. I understand there are locale issues with this.)
I think the spec is wrong (or if that's actually what Ben meant, I think
he is wrong). Typing in a date works fine now and I don't think this
should be changed.
Adam Kowalczyk (Ancestor)
> The ASCII from my previous post was a little messed up, so I've
> reproduced it here again for easy cut'n'paste:
>
> mockup of tagging UI:
>
> --------. .------------------.
> .com (+)| (->)Go | [G] |
> ------.-' '------------------'
> |\
> | `-----------------------------------------.
> | Tags: [ (Work), (Not Work), Oth_ ] | <-- (1)
> | Notes: [ ben sent me this url ] | <-- (2)
> | [ ] |
> | |
> | [Remove] [Add Bookmark] [Done] | <-- (3)
> '-------------------------------------------'
The idea of separating tagging and bookmarking concerns me. Although I
understand the philosophy behind associating tagging with History, I
don't think it's going to work well in practice. User tags a page when
he finds it interesting and expects he may want to come back. Is it not
essentially the same as bookmarking? This distinction makes sense only
when user is willing to tag a lot - so much that he will even tag pages
which he is not likely enough to revisit and which are therefore not
worth bookmarking. So for users who tag rarely or moderately often it is
better to associate tagging with bookmarking while for those who tag a
lot - with History. Is it reasonable to assume that the majority of
users will tag that much? I don't think so.
Moreover, it is a longstanding habit to mark interesting pages by
bookmarking. To me, most users WILL bookmark and tag at the same time
and the new tagging UI is going make it harder for them. Or rather, will
not make it any easier.
All in all, it seems that the idea of mass, quick bookmarking which has
long been the central point of the new system is abandoned in favor of a
newly conceived History-tagging philosophy. In my humble opinion, it's
not the right move.
On another note, does the [Add Bookmark] button in the above mockup
serve any common path? If user only wants to tag he obviously doesn't
need it. If he wants to tag & bookmark then this popup is not a
convenient way, because he has to enter some of the data in one place,
click a button and then enter some more data in another dialog. In such
case it's better to bring up the Add Bookmark dialog right away. [Add
Bookmark] button in this place makes sense only if users decides to
bookmark after he already started tagging.
Cheers,
Adam
Mike Beltzner
> Personally, I think it's very important to see all tags. I am of the
> more foldery persuation, but personally I would be pretty confused if my
> list of tags wasn't obviously presented somewhere easy-to-get to.
For this we could, I suppose, include a folder (collapsed by default)
on the left pane of the Organize UI which lists all of the tags that
have been used as subfolders, and selecting one loads a search for
that specific tag. *shrug* I guess that could be useful, but we get
back into the "well, why aren't these folders" question again, and I'm
really trying to drive the idea that tags are an orthogonal model.
> It keeps getting brought up (though maybe not in this specific email)
> that the way to get at tags is by searching. This makes no sense to me.
> How do I explain to new users "where their tags are?" How do I remember
So, my opinion (and I'm sounding repetetive as well, I guess :) is
that their tags are nowhere. Their tags don't exist as objects. Their
tags aren't anything more than metadata.
There are lightweight ways of surfacing the user's entire list of tags
in the UI for assigning tags (ie: if the user presses ctrl+down arrow
as they can in any search field, they'll get the entire list of
type-ahead possibilities which will be the entire list of the existing
tags) and heavier weight mechanisms as well (some sort of [...] button
that pops up a full list. I personally think that the latter is
overkill and complicates an otherwise simple concept: what are the
word that come to mind when you see this page.
> that the tag I'm using for researching my new purchase is "monitor" and
> not "screen"? The theory behind tagging is all fine, but it doesn't get
You wrote it. Chances are that the way you classified it the first
time will match the way you did it the other time. The goal of tags is
not to create a static ontology; it's to allow ontologies to emerge
and evolve along with the user.
> I firmly believe most people, even advanced users, will have relatively
> few tags which will be fine to display in a list in the primary UI. Even
If that's the case, then I'm more convinced than ever than some
lightweight UI like the drop-down for type-ahead matching is the right
way to go. Creating a heavier weight UI to select from 1 of 10-20 tags
would be overkill IMO.
> Sorry if I'm sounding repedetive or not understanding something.
Ditto for me! :)
On Date: Feb 24, 2006 at 4:27 PM, Dietrich Ayala wrote:
> The popularity of tag clouds is a good example of a general desire to
> *browse* tags.
Yes, but this flies in the face of what Brett was asserting about how
most users will have few tags. Tag clouds are meant to let more
frequently used tags bubble to the surface, to illustrate the emergent
ontologies. Personally, I think they're more useful in the distributed
case, where you're sharing tagged resources with others, and trying to
determine whether the more popular tag is "monitor" or "screen".
Whichever one bubbles to the top of the tag cloud is obviously the
winner.
On Feb 24, 2006 5:25 PM, Mark Pilgrim wrote:
> - I'm concerned about the "disclosure" widget in the Places Search
> Popup, first mentioned here:
> http://wiki.mozilla.org/Places:User_Interface#Searching. Please make
> sure that this widget is a real button that can receive focus by
> tabbing.
AFAIK, it would be a button like any other, and I'd expect it to be in
the tab order. From Ben's mockup, I was picturing a standard [More >>]
button.
> - [top priority] Furthermore, I'm concerned in general with this UI
> concept of a complex overlay that isn't a separate window, which
> auto-expands and contracts based on autocompletion in a text box.
> Presumably the "Search bookmarks/history" menu item will open the
> overlay and set focus to the search box within the Places Popup. But
> once they starts typing, how would a blind user know that there are
> any results being shown?
What are the current a11y strategies used for things like Spotlight?
Could we not use some sort of sensible timeout to see if any results
are found, and as soon as one is, send the screen reader a signal
which it can interpret (ie: "17 results found .... 23 results found
.... search complete")
> Related: I am concerned about this sentence: "When the disclosure
> button in the Places Search Popup is clicked, the popup changes to
> show the contents of a selected Place." Again, in the absence of any
> window or context change, how would a blind user know that there is a
> completely different UI in place of the previous one?
How does a user understand when they click on any button that launches
a new window that some new UI exists? Or how are [More >>] buttons
currently handled (I know there are lots in Eclipse). I'm not sure I
share this concern. From an end-effects perspective, hitting the
disclosure button would be like asking for a new window. This problem
has most likely been solved already, we just need to figure out how to
enable that solution.
> - [2nd priority] Date pickers in the advanced search form. The new
Thankfully Brett pointed out the spec is wrong, but to emphasize from
my UE perspective, even non-a11y users will need to be able to modify
dates using the keyboard. To not be able to do so, quite simply,
sucks.
> - [3rd priority] I don't see any keyboard-accessible way to mark a
> page as interesting. The only UI for this feature seems to be
I think it was an open issue - see my post in which I reviewed the
entire spec. Above, I propose using Ctrl/Cmd-H for "mark this page as
interesting in the history".
Thanks for the early review, Mark. All of these concerns are valid,
and should be addressed.
Mike Beltzner
> don't think it's going to work well in practice. User tags a page when
> he finds it interesting and expects he may want to come back. Is it not
> essentially the same as bookmarking? This distinction makes sense only
No, we're asserting it is not, and we've discussed this earlier in
this forum. I suggest that you're thinking too much about the way
things *are*, and not about the way things *should be* to handle
today's larger, more diverse, more flexible world wide web.
(To review: Bookmarks were originally intended to be shortcuts to
commonly visited sites. But then the web got bigger, and people
started using them as ways to remember interesting places. But then
the web got bigger still, and all of a sudden the bookmarking system
couldn't cope. Initial thoughts about tagging were: well, let's use
tags and search to make it easier to handle large bookmark sets. But
that led to some very good questions: search isn't as quick as
click-click-click through a drop-down menu or click on a personal
toolbar. The key was realizing that the use of bookmarks shifted and
merged: a single system was being used to store shortcuts AND sites
that were just interesting and that the user thought they might want
to get back to. The goal of keeping all of these interesting sites is,
well, to keep track of one's personal world wide web. To tag those
pages that they thing are interesting and then be able to quickly
search not the entire web, but across their already-experienced subset
to get back to where they were. And that's why we think it's
different.)
> lot - with History. Is it reasonable to assume that the majority of
> users will tag that much? I don't think so.
So it turns out they don't have to tag at all if they don't want to,
and I think that most of our users won't end up tagging. At least not
until they hear about it, read about it, and start playing with it.
Just like tabbed browsing. In the meantime, we shouldn't be changing
their understanding of bookmarking out from underneath them.
The goal of our expression of tagging is to augment and add
functionality while not destroying the user's existing mental models.
> bookmarking. To me, most users WILL bookmark and tag at the same time
> and the new tagging UI is going make it harder for them. Or rather, will
> not make it any easier.
Howso? If you want to tag as you bookmark, the behaviour is EXACTLY
the same as in 1.x, and there's a "tag" field. If you notice the
little button near the URL bar, there's an "Add Bookmark" button,
clear as day. It's only when you tag pages without creating bookmarks
that you step into the new system.
cheers,
mike
Brett Wilson
are expecting this feature to be (it sounds like me and Adam are on one
side, you and a bunch of other people are on another). I still prefer
the unified tag/folder approach we originally planned myself.
I think we can probably agree that it's almost impossible to tell how
well it works without something that is almost complete (probably a lot
of how well users receive it depends on tiny details). I think we should
try to get something working as fast as possible and get user testing
done. It is likely any path we take in this area will require major
revisions once we can try it out.
So here's some predictions :) It's clear there is going to have to be
some beer on the line here.
* Intermediate users won't understand/remember what tags are for because
they're "just metadata" (novice users realistically aren't likely to use
this no matter what we do).
* Users won't know how to call up a previous page given a tag they
remember using.
* People will often remember pages they tagged but not what they tagged
the page as.
Side note: Flock does a really nice job autocompleting in the search
engine box for your tags. I think this is great because it merges
searching your local computer with searching the web; you don't have to
think about whether you tagged it. Not found?--press enter to get
Google/whatever. Forcing people into separate boxes for these makes it
more heavyweight. I'm not sure if we had planned anything like this, but
we really should.
Mark Pilgrim
> > - [top priority] Furthermore, I'm concerned in general with this UI
> > concept of a complex overlay that isn't a separate window, which
> > auto-expands and contracts based on autocompletion in a text box.
> > Presumably the "Search bookmarks/history" menu item will open the
> > overlay and set focus to the search box within the Places Popup. But
> > once they starts typing, how would a blind user know that there are
> > any results being shown?
>
> What are the current a11y strategies used for things like Spotlight?
At the risk of sounding more pissy than usual, let's not use Apple has
our guiding light for good accessibility techniques.
> Could we not use some sort of sensible timeout to see if any results
> are found, and as soon as one is, send the screen reader a signal
> which it can interpret (ie: "17 results found .... 23 results found
> .... search complete")
Yes, something like will probably be needed. I'll confer with
AaronLev offline to figure out how to implement it.
> > Related: I am concerned about this sentence: "When the disclosure
> > button in the Places Search Popup is clicked, the popup changes to
> > show the contents of a selected Place." Again, in the absence of any
> > window or context change, how would a blind user know that there is a
> > completely different UI in place of the previous one?
>
> How does a user understand when they click on any button that launches
> a new window that some new UI exists?
Opening a new window sends a specific OS-level event that screen
readers look for.
Similarly, following a link or typing a URL into the URL bar and
pressing Enter triggers a specific event.
In general, screen readers are event-driven. If the user does
something (press a key, move the mouse, tab to a new control, page up
or down), events get fired and screen readers are programmed to react
to those events. If something happens that was not in direct response
to user input (new mail arrived on a timed schedule, a software update
is available), appropriate events need to be fired so that screen
readers can have the option to react to them.
If something significant is happening in the UI (like large portions
of the UI being replaced by new controls, e.g. Places Search Popup
morphing into Places Popup in response to clicking an otherwise
ordinary-looking button), we need to ensure that some event occurs
that gives screen readers enough information about what happened so
they can react appropriately (such as reading from the first control
of the new Popup).
> Or how are [More >>] buttons
> currently handled (I know there are lots in Eclipse). I'm not sure I
> share this concern. From an end-effects perspective, hitting the
> disclosure button would be like asking for a new window. This problem
> has most likely been solved already, we just need to figure out how to
> enable that solution.
Actually, mconnor found one vaguely similar situation in Firefox, but
the results are not encouraging. If you have the option to ask on
each cookie, the Accept Cookie dialog has a "show details" button that
expands the window to show several labels and read-only text fields
with cookie information. Clicking this button does nothing useful --
WindowEyes (5.5, which fully supports Firefox) does not mention that
the window has changed. I'm tentatively treating this as a bug until
I discuss it with Aaron, and may be filing a bug report on it.
In any case, the Places UI morphing into something completely
different is much more serious -- entirely new functionality is
available on-screen, but the blind user wouldn't know it. Which is
not to say that the idea needs to be scrapped; as you say, we just
need to figure out what the right solution is and how to enable it.
--
Cheers,
-Mark
Adam Kowalczyk (Ancestor)
> On 2/24/06, Adam Kowalczyk (Ancestor) <ance...@o2.pl> wrote:
>> don't think it's going to work well in practice. User tags a page when
>> he finds it interesting and expects he may want to come back. Is it not
>> essentially the same as bookmarking? This distinction makes sense only
>
> No, we're asserting it is not, and we've discussed this earlier in
> this forum. I suggest that you're thinking too much about the way
> things *are*, and not about the way things *should be* to handle
> today's larger, more diverse, more flexible world wide web.
You're probably right. But then again, it may be an indication of how
willing users in general may be to adopt the new system. As stubborn as
I seem, I still am one of the early adopters.:) It's easier to convince
through practice than through theoretical discussion, though.
> (To review: Bookmarks were originally intended to be shortcuts to
> commonly visited sites. But then the web got bigger, and people
> started using them as ways to remember interesting places. But then
> the web got bigger still, and all of a sudden the bookmarking system
> couldn't cope. Initial thoughts about tagging were: well, let's use
> tags and search to make it easier to handle large bookmark sets. But
> that led to some very good questions: search isn't as quick as
> click-click-click through a drop-down menu or click on a personal
> toolbar. The key was realizing that the use of bookmarks shifted and
> merged: a single system was being used to store shortcuts AND sites
> that were just interesting and that the user thought they might want
> to get back to. The goal of keeping all of these interesting sites is,
> well, to keep track of one's personal world wide web. To tag those
> pages that they thing are interesting and then be able to quickly
> search not the entire web, but across their already-experienced subset
> to get back to where they were. And that's why we think it's
> different.)
The new concept must have risen very recently and partly outside this
group as the Places UI draft doesn't include it explicitly. Thank you
for a great clarification, I appreciate.
Two things that came to my mind:
1) Even if users are going to be encouraged to store their History for a
long time, it could be extremely useful to have an option not to purge
the tagged items when clearing history.
2) Would it be reasonable to allow including history items in smart
folders? For instance, a smart folder which queries bookmarks for a
certain tag would also include history items with that tag? It would
have to be optional, of course, as it would not always be desired.
>> bookmarking. To me, most users WILL bookmark and tag at the same time
>> and the new tagging UI is going make it harder for them. Or rather, will
>> not make it any easier.
>
> Howso? If you want to tag as you bookmark, the behaviour is EXACTLY
> the same as in 1.x, and there's a "tag" field. If you notice the
> little button near the URL bar, there's an "Add Bookmark" button,
> clear as day. It's only when you tag pages without creating bookmarks
> that you step into the new system.
I beg your pardon, does it mean that that the new tagging popup didn't
replace the "star" add bookmark button?
Cheers,
Adam
Ian Pottinger
> * People will often remember pages they tagged but not what they tagged
> the page as.
I would add that the current proposal also is inconvenient for the
disabled or anyone who prefers to use a pointing device whenever
possible. Hence, for people with failing hands or minds, an alternate
"mode" similar to that described below (built-in or via an extension)
might be appreciated.
Tagging in "Less" mode
+-----------------------------------------------+
| Name: [ Foo ] |
| Location: [ http://www.foo.com/ ] |
| Tags: [ Videoblog, Funny ] |
| ( >> ) | <-- (1)
| |
| ( Remove ) ( Show All Bookmarks ) ( Done ) |
+-----------------------------------------------+
Tagging in "More" mode
+-----------------------------------------------+
| Name: [ Foo ] |
| Location: [ http://www.foo.com/ ] |
| |
| --Tags--------------------------------------- |
| |
| Available Apply |
| +-----------------+ +-----------------+ |
| |News ^| |Funny ^| | <-- (2)
| |Play | [-->] |Videoblog | |
| |Research | [<--] | | | <-+
| |Work v| | v| | |
| +-----------------+ +-----------------+ | | (3)
| | |
| ( Add ) [ ] | --+
| |
| --------------------------------------------- |
| ( << ) | <-- (1)
| |
| ( Remove ) ( Show All Bookmarks ) ( Done ) |
+-----------------------------------------------+
1. button that switches dialogue between "Less" and "More" modes
2. select options boxes. "Available" contains all existing tags.
"Apply" contains tags to be applied to this location.
3. textbox to add new tags which are immediately move to "Apply"
NOTE: tags that were unique to this locations but were moved
to "Available" will be lost upon dismissal of the dialogue
Searching in "Less" mode
|
+------------------------------------------------------
|#@=#| / PTBookmark 1 / PTBookmark 2 / PTBookma...
| +------------------------------+
| Search Bookmarks & History: |
| [Videoblog, Funny ] |
| |
| ( >> ) ( Search ) | <-- (1)
+-----------------------------------+
Searching in "More" mode
|
+------------------------------------------------------
|#@=#| / PTBookmark 1 / PTBookmark 2 / PTBookma...
| +------------------------------+
| Search Bookmarks & History: |
| |
| Available Search For |
| +-----------+ +-----------+ |
| |News ^| |Funny ^| |
| |Play | [-->] |Videoblog | | <-- (2)
| |Research | [<--] | | |
| |Work v| | v| |
| +-----------+ +-----------+ |
| |
| ( << ) ( Search ) | <-- (1)
+-----------------------------------+
Ben Goodger
> I think the spec is wrong (or if that's actually what Ben meant, I think
> he is wrong). Typing in a date works fine now and I don't think this
> should be changed.
It depends how complicated you want the parsing logic to be. By having a
static field where the user can only enter well formed dates using the
appropriate picking UI, you don't need to worry about validation so
much. What happens when the user enters a data formatted the wrong way,
or enters just random text?
-Ben
Mike Connor
handles various international date formats properly. The calendar guys
were talking about that the other day as a real challenge.
-- Mike
Joey Minta
> Typing in a date probably works fine for en-US, but I doubt it really
> handles various international date formats properly. The calendar guys
> were talking about that the other day as a real challenge.
javascript Date's toLocaleFormat(). The relevant code can be found
here:
http://lxr.mozilla.org/mozilla/source/calendar/resources/content/datetimepickers/datetimepickers.xml#1182
You'll probably also want to look at initDateFormat:
http://lxr.mozilla.org/mozilla/source/calendar/resources/content/datetimepickers/datetimepickers.xml#1339
(Now, if we could just get the datepickers unified and into toolkit...)
-Joey
Ben Goodger
> Side note: Flock does a really nice job autocompleting in the search
> engine box for your tags. I think this is great because it merges
> searching your local computer with searching the web;
Do you really think these are the same action, in most users' minds?
Is searching for previously accessed pages the same as research for new
things?
-Ben
Ben Goodger
> Typing in a date probably works fine for en-US, but I doubt it really
> handles various international date formats properly. The calendar guys
> were talking about that the other day as a real challenge.
A good QA interview question asking someone to define the tests for a
user editable date picker could go on for a long time.
Some potentially valid input cases, as far as a user is concerned:
2/15/06
15/2/06
2/15/2006
15/2/2006
2 15 06
15 2 06
2-15-06
24 Mar 2006
24 March 2006
24-Mar-2006
5.3.06
...
then there's mis-typed or invalid entries.
-Ben
Ben Goodger
> Typing in a date probably works fine for en-US, but I doubt it really
> handles various international date formats properly. The calendar guys
> were talking about that the other day as a real challenge.
A good QA interview question asking someone to define the tests for a
Brett Wilson
Well, the direction that the discussion seems to be going is that tags
are used for keyword searching and almost nothing else. I've talked
before about how I'm not comfortable with this approach, but if that's
what we end up doing, then yes, I think they are the same thing. And
even if that's not what we end up doing, I still think it's a good idea.
Google Desktop search does this by adding history matches to Google
pages, and the beta Google Toolbar for IE autocompletes to history as
well. I think there's a lot of benefit in this because then you don't
have to think about whether you previusly marked things.
Sometimes I don't even think about the fact that I previously viewed the
page, and I'm pleasently surprised that the thing I'm looking for is
right there. Likewise, if I can't think of the keyword I used for the
bookmark, I probably just want to do a web search. In this way, the tags
are essentially a way for me to customize search results to help me find
things in the future. I still think we should have a separate tagging
search box in the tagging UI that would probably provide some other
features.
Brett
Brett Wilson
autocomplete is over previous searches and takes you to the Google
results page, not the page you visited.
Brett
Adam Kowalczyk (Ancestor)
more or less approved of but didn't make their way to the draft. So I
would like to point them out, just in case they were missed:
1. (New Smart Folder) button in the Places Organizer window, analogous
to (New Folder). This greatly enhances exposure of this functionality.
2. Quick tagging and/or bookmarking with last used tags.
http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/d0605d63ba563cf8/19098c6afdc02d44?lnk=st&q=%22last+tags+used%22&rnum=1#19098c6afdc02d44
Cheers,
Adam
Mike Beltzner
> At the risk of sounding more pissy than usual, let's not use Apple has
> our guiding light for good accessibility techniques.
OK, movin' on .. :)
>> How does a user understand when they click on any button that launches
>> a new window that some new UI exists?
>
> Opening a new window sends a specific OS-level event that screen
> readers look for.
So I guess what I'm asking is whether or not we can't send this same
event. I think what we'd be doing here *is* opening a new window, it's
just that we're proposing doing it in such a way that it replaces the
existing window and simply offers more options.
> of the UI being replaced by new controls, e.g. Places Search Popup
> morphing into Places Popup in response to clicking an otherwise
> ordinary-looking button), we need to ensure that some event occurs
And I guess you're asking for the same thing. :)
> Actually, mconnor found one vaguely similar situation in Firefox, but
> the results are not encouraging. If you have the option to ask on
[...]
> the window has changed. I'm tentatively treating this as a bug until
> I discuss it with Aaron, and may be filing a bug report on it.
That's absolutely a bug; please file it.
> In any case, the Places UI morphing into something completely
> different is much more serious -- entirely new functionality is
> available on-screen, but the blind user wouldn't know it. Which is
> not to say that the idea needs to be scrapped; as you say, we just
> need to figure out what the right solution is and how to enable it.
Agreed. I'm thinking that by ensuring that we send the right events to
the screen reader, we'll be able to provide a good experience for our
a11y users.
One question: is this a problem that's specific to Places, or should we
be looking to create these sorts of events somewhere deeper in the toolkit?
cheers,
mike
--
Mike Beltzner
> I think we can probably agree that it's almost impossible to tell how
> well it works without something that is almost complete (probably a lot
I don't know if that's true. We could whip together some low-fidelity
mockups of the various systems, just as paper prototypes, and do some
usability testing to match the systems against users' mental models. We
might want to do that, actually. Although unless we're prepared to
invest some significant time pulling together a realistic cross-audience
sample, we'd basically be looking for really violent reactions one way
or the other.
> done. It is likely any path we take in this area will require major
> revisions once we can try it out.
Which, to be frank, we might not have time for. I've always been
considering the case where we get this wrong, which is one (though not
the primary) reason that I've argued for ensuring that our tagging
experience is layered on top of the existing bookmarking system. If it
turns out that the system doesn't work, it should be easier to back it
out or refactor it as an extension.
> So here's some predictions :) It's clear there is going to have to be
> some beer on the line here.
Dude, I get paid in *tequila* :)
> * Intermediate users won't understand/remember what tags are for because
> they're "just metadata" (novice users realistically aren't likely to use
> this no matter what we do).
We're obviously not going to expose them as metadata. We need to come up
with a solid way to express the concept in a way that matches against an
existing mental model that we're reasonably certain that most users have.
Right now, I'd assert that users have the following mental model of
bookmarks: "A bookmark is a shortcut to a specific website, a lot like
speed dial or a desktop shortcut."
Users familiar with tags will have a mental model that's either
influenced by implementations by Flickr, Adobe Photoshop Album, iPhoto
or del.icio.us, in that order of probability. Looking at the photo apps,
tags are universally presented as annotations on an item that can be
used for categorization, but in a means orthogonal to the primary
categorization in terms of "rolls" or "folders". del.icio.us is
different, and shows tags as annotations but then allows you to view a
"folder" of items that contain those annotations.
In either case, however, the mental model is that tags are annotations
or notes that are properties of the object and used for flexible,
on-demand categorization. I don't see anywhere in these UIs that implies
a user places an object in the "cats" category, as opposed to adding a
"cats" tag to the object.
Users unfamiliar with tags have a mental model for tagging or annotating
as well. When I read an interesting page in a magazine, I might fold the
corner down so I can quickly find it again. I don't name it, I don't
file it away in a special place of references to interesting articles, I
just make a small mark on it. Maybe, if I'm doing research or something,
I might even take a post-it note and jot some quick reminders about what
the page is about, like "recent experiment data".
This is the mental model which I'd like to leverage, and the one that (I
feel) meshes nicely with existing tag UIs in web applications. The idea
that a tag is adding a note to a page, and then later, a user can search
for those notes again.
I don't expect new or even intermediate users to know that they can add
these notes intuitively, and so if we end up chosing to not show any UI
around tagging in the URL bar or default chrome, then this becomes a
power-user function much like tabbed browsing was considered to be in
Firefox 1.0. Even in that case, we haven't broken these users' mental
model of bookmarking, so I think we're winning!
> * Users won't know how to call up a previous page given a tag they
> remember using.
So maybe the first time they create a tag we tell them about where to
search for it. This is a very solveable issue, and relates to the fact
that we don't really do a lot in-browser to help the new user understand
UI elements.
> * People will often remember pages they tagged but not what they tagged
> the page as.
I've described previously a couple of ways around this, but here it goes
again: maybe we add a [...] button that pops up the list of existing
tags, or we let users rely on the drop down. There are ways to fix this
case gracefully without overloading the UI with (potentially) huge lists
of tags. The way this system is *meant* to work is to allow people to
tag things without any requirement of cognitive investment. The action
is supposed to be "eh, maybe I'll want this again later, so I'll just
jot down 'monkey' and 'movie' and now I'm done." Then, maybe 20 days
later, they remember that funny monkey movie, and search for it.
> Google/whatever. Forcing people into separate boxes for these makes it
> more heavyweight. I'm not sure if we had planned anything like this, but
> we really should.
Yeah, we have thought about this, and I think this is something which
needs more investigation.
Personally, I worry about how this will conflict with our hopes for
allowing search providers like Google to return as-you-type results in a
drop-down much like Spotlight does. I think it might be even
heavier-weight to have a list of results in which we have to mix and
match local and web-wide search results. But I don't have as strong a
feeling/instinct here, so would like to discuss it more.
cheers,
mike
--
Mike Beltzner
> I would add that the current proposal also is inconvenient for the
> disabled or anyone who prefers to use a pointing device whenever
> possible. Hence, for people with failing hands or minds, an alternate
While the slosh bucket design you proposed does make it easier to use
the mouse, I'm not sure how it helps a11y concerns, since it's a very
visual model. At any rate, I think I've agreed several times (but am
happy to do it again!) that there may indeed be need to include some
sort of UI that lets a user select a tag from a list of already created
tags. I am asserting that this should not be the primary UI. Let's get
the primary UI settled, and then we can focus on optimizations.
Thanks for the time you put into the mockups,
mike
--
Pam Greene
In either case, however, the mental model is that tags are annotations
or notes that are properties of the object and used for flexible,
on-demand categorization. I don't see anywhere in these UIs that implies
a user places an object in the "cats" category, as opposed to adding a
"cats" tag to the object.
Users unfamiliar with tags have a mental model for tagging or annotating
as well. When I read an interesting page in a magazine, I might fold the
corner down so I can quickly find it again. I don't name it, I don't
file it away in a special place of references to interesting articles, I
just make a small mark on it. Maybe, if I'm doing research or something,
I might even take a post-it note and jot some quick reminders about what
the page is about, like "recent experiment data".
This is the mental model which I'd like to leverage, and the one that (I
feel) meshes nicely with existing tag UIs in web applications. The idea
that a tag is adding a note to a page, and then later, a user can search
for those notes again.
We've been discussing how and whether to differentiate tags and folders, but I think there's a more useful mental model for us, which will lead to a more useful model to present to users. Tags are different from bookmarks or bookmark folders -- but they are very much the same as keywords. Call them that; treat them that way.
The main difference I can think of is one of size: you'd expect a list of tags to be smaller and more constrained than a list of keywords. But that's largely a matter of UI: if we present a list of keywords people have already assigned to other pages, like has been proposed for what's been called tags, that will help them remember they're using "lighting" rather than "lamps" -- and if searching is to be the primary interface to tags/keywords, then assigning both "lighting" and "lamps" isn't a big problem anyway.
- Pam
Ben Goodger
> I have updated the Places UI documentation here:
>
> http://wiki.mozilla.org/Places:User_Interface
OK.
Another question: What should all the keybindings be?
-Ben
Mike Beltzner
> Another question: What should all the keybindings be?
Function Key binding
------------------------ -----------
Bookmark current page Accel+D
Bookmark all tabs Shift+Accel+D
Tag current page Accel+.
Search history/bookmarks Accel+B
Manage history/bookmarks n/a
Any others that we really feel like we need?
cheers,
Mike Connor
> Tag current page Accel+.
Cmd + . is currently Stop on Mac. (OS convention,
Safari/IE/Camino/Mozilla do this too)
-- MIke
Adam Kowalczyk (Ancestor)
> Ben Goodger wrote:
>> Another question: What should all the keybindings be?
>
> Function Key binding
> ------------------------ -----------
> Bookmark current page Accel+D
> Bookmark all tabs Shift+Accel+D
> Tag current page Accel+.
> Search history/bookmarks Accel+B
> Manage history/bookmarks n/a
>
> Any others that we really feel like we need?
Couldn't we have a one-hand shortcut for tagging current page? It's a
function that seems especially suitable to be accessed by shortcut as
you have to switch to keyboard anyway. Perhaps it could be swapped with
some other if we're short of keys.
Cheers,
Adam
Ben Goodger
> Ben Goodger wrote:
>> Another question: What should all the keybindings be?
>
> Function Key binding
> ------------------------ -----------
> Bookmark current page Accel+D
> Bookmark all tabs Shift+Accel+D
This is currently used to bookmark the current page into the default
location with no further prompting. There is no other access point.
-Ben