User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:184.108.40.206) Gecko/20071024 Firefox/220.127.116.11 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OSX 10.5; en-US; rv:1.9b2pre) Gecko/2007111304 Minefield/3.0b2pre When I bookmark a page an enter a number of tags such as "image share daily popular", the bookmark is saved with just one tag consisting of the whole string, instead of the 4 separate tags as was intended. Took me a bit to figure this oddness out. I have never seen tags act this way before. Some sites where tags are separated by spaces instead of commas: www.flickr.com and del.icio.us Reproducible: Always
Component: Bookmarks → Places
QA Contact: bookmarks → places
where do you see that tags are "unified" into one? In Places Organizer? could you provide a screenshot?
i've seen that, you should separate tags with commas or they will be considered a single multi word tag
Yes, I figured out you have to separate tags by tabs. Separating tags by spaces just seems much more intuitive, and was what I expected. As I have been paying attention to how websites handle tags over the last few days, I notice that some use commas (last.fm), and some use spaces (previous examples I gave). Maybe we should do a poll and see if people expect commas or spaces to separate tags?
Most popular websites like del.icio.us or flickr uses space to separate different tabs. Especially del.icio.us has a good explanation of what a tag is: http://del.icio.us/help/tags For me a tag is a single word and should be separated by space. I don't feel well with commas and I also think that's not intuitive for most of our users. But if someone has a multi-word tag we should give him the opportunity to set it with the help of double quotes.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Mac OS X → All
Hardware: Macintosh → All
Version: unspecified → Trunk
Summary: When bookmarking a page, tags should be separated by a space, and not a tab → When bookmarking a page, tags should be separated by space and not by comma
Here is our rationale for separating on comma: -We want to support multiple word tags -We want to do a graphical change to the tag when the user hits comma (kind of like the tag editor control on OS X, used in places like the to: field in Mail.app) [not sure if this will make Firefox 3] -Due to the limited reach of Web 2.0 sites outside of very tech savvy demographics, this will be most user's first experience with tags. A Pew/Internet research report on 1/31/07 found that only 28% of American Internet users have tagged content, and 7% tag content daily (http://www.pewinternet.org/PPF/r/201/report_display.asp). According to Alexa, Flickr has an global reach of 1% of users, and del.icio.us has a global reach of .8% of users. Even though Firefox users are in general more technical than average computer users, the vast majority of them will still not be familiar with the Web 2.0 meme of "tagging." We believe this voids the need to leverage external consistency. To improve usability, the field is supposed to be self describing with the text "tag one, tag two, tag three," or maybe "Separate tags with commas" similar to how the search field says "Google" and the location bar says "Search Bookmarks and History."
11 years ago
It seems reasonable but I can't fully agree. As far as I can see we have 3 groups of users. First the novice or memory artist who even don't know or don't want to bookmark pages. They also won't use tags. More familar users who visit pages on a regular basis are saving websites as bookmarks and perhaps also using keywords if they know this feature. And at last heavy users who are blogging each day and using tags all around the time. The third group which will be a minority as you already told, has to switch to a new format. I can believe that they will be confused some times and enter tags in the wrong format. The second group of users who never used tags before has to learn this great feature from the bottom up. Whatever they use they don't mind. But the question is what can Mozilla do to prepare their ground? I know web 2.0 is a great hype and not everyone is fascinated on what's going on. But if these applications will get a huge user base in the future all have to learn a new way of tagging. My last comment wasn't only limited to Flickr or del.icio.us. These were only examples of thousand other sites. The lack I see is that there is no existing definition in how tags should be used - regardless if it's a single or multi-word tag. Am I correct or did I miss something? Mozilla as an open platform could benefit from all its users and could try to create a community survey to get feedback which possible way is the more favored one? Just an idea...
>The lack I see is that there is no existing definition in how tags should be >used - regardless if it's a single or multi-word tag. Am I correct or did I >miss something? We haven't really given users a good indication yet. I think the two ways we will do this are: 1) shipping with a few pre-populated example tags like "Read Later" 2) documentation on what new in Firefox 3, getting started, and help This should cover how tags are used in the functional sense, in the grander sense of what people actually use them for, that will likely be up to each individual user and the reasons they happen to be on the Web. I don't know exactly why so many Web 2.0 sites decided not to allow spaces, but it may have been to easily adapt the tags to URLs, or maybe to get people to coalesce to a simpler set of tags (important for social tagging). Neither of these concerns impacts the local, non-social tagging used to organize bookmarks in Firefox. Humans like to express ideas with spaces, "Read Later" is a lot more natural than readLater, read.later, or read+later. People use commas when they are writing on physical paper (as opposed to quotes or semicolons). Also, I'm pretty sure anyone informed enough to already know about tagging will be able to easily adapt to commas. Thanks for the feedback, marking wontfix. Here is a related discussion on 37signals: http://www.37signals.com/svn/archives2/tag_formats_cant_we_all_just_get_along.php
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WONTFIX
(In reply to comment #7) > 1) shipping with a few pre-populated example tags like "Read Later" Is there a bug about it yet? > Here is a related discussion on 37signals: > http://www.37signals.com/svn/archives2/tag_formats_cant_we_all_just_get_along.php Great. Thank you for the link. A lot of useful information.
>Is there a bug about it yet? Just filed one: bug 408780
Please reconsider your decision to mark this wontfix. I think a more humble approach should be taken. You should realize that the majority of users who will use tags are already accustomed to using spaces because of sites like Flickr and del.icio.us. Even the Yahoo del.icio.us Firefox extension uses spaces for tagging, which predates Firefox's implementation of tagging. Instead of forcing these users to switch between both methods, you should humbly go with the flow and use the method that is most widely used and already implemented. It is also a much faster method of tagging. Ergonomically, the spacebar can be hit by dedicated fingers: the thumbs. The comma is hit by the middle finger, which is also used for other characters. Anyone who can touch type can tell you that it's much quicker to hit the spacebar than the comma. Those who must use multi-word tags can use quotation marks. I would recommend that you allow both single and double quotes, so you don't have to hit the shift key. At the very, very least, you should have an an about:config option to choose whether to separate by commas or spaces (or semicolons, while you're at it; how about letting the user choose?). Please do not cripple the first, halfway-decent in-browser tagging implementation by forcing us to use commas. It is simply frustrating, and Firefox is supposed to be the very opposite of frustrating.
11:12 <beltzner> we based it on delicious and flickr, I think 11:14 <mconnor> er 11:14 <mconnor> we require commas 11:19 <mconnor> flickr uses double quotes 11:19 <beltzner> yeah, then we [messed] that up 11:19 <mconnor> ok We should support commas, semicolons and spaces as tag separators, as those are the popular ones I've seen in UIs across the land. We could actually be really smart, too, and detect the following patterns: tag1 tag2 tag3 tag1, tag2, tag3 "tag1 more" tag 2 tag3 tag1 more, tag2, tag3 (where , could also be ;) (no, I didn't just wink at you)
Summary: When bookmarking a page, tags should be separated by space and not by comma → When bookmarking a page, detect separate tags by space, comma, and semicolon
The only sucky case I didn't cover in comment 11 is two words Is that "two" and "words", or "two words". By default I think we should opt for the former.
not only could we be, we should be smart. Doing anything else kinda feels not-smart! I'll note that I have some concerns about the internationalization aspects of requiring commas, since they're not used in every language as natural separators. -> me for now. Here's a proto-spec: 1. Semi-colons and commas, when found, mean we will treat the entire field as comma/semicolon-separated, and anything not separated will be treated as a multiple word tag. foo bar, baz == "foo bar", "baz" foo; bar baz == "foo", "bar baz" 2. When there are no commas or semi-colons, space becomes the separator, and we recognize quotes as containing multiple foo bar baz == "foo", "bar", "baz" foo "bar baz" == "foo", "bar baz" 3. Odd cases foo bar == "foo", "bar" This will not make the comma-loving world happy. But I believe that adding a single multi-word tag is not likely to be a dominant case, but adding a couple of tags would be. You can append a comma, or as may be more likely to those using multi-word tags, add more tags. No one has really compelling evidence here, but given that the two most dominant tagging-driven sites (Delicious and Flickr) default to this, I'm ok with it.
Assignee: nobody → mconnor
Status: REOPENED → NEW
>But I believe that adding a single multi-word tag is not likely to be a dominant case I really disagree, I believe people commonly think in multiple word concepts, and the vast majority of Firefox users exposed to this feature will have never tagged anything before. If the user enters the tag "read later" tagging it as "read" and "later" is going to be annoying. Asking the user to express multiple word concepts in quotes or camelCase seems like we are forcing them to adapt instead of adapting to them. I'm all for us trying to be as smart as we can about inferring separators, but I don't think we should default to separating on spaces.
I think, as I said six months ago, that we should do this in the same manner as Flickr. Spaces are the delimiter. If you want spaces in your tag, wrap it in double-quotes. People manage this on Flickr every day for thousands of photos. 1. foo bar == "foo" and "bar" tags 2. "foo bar" == "foo bar" (sans quotes) as one tag. The suggestion in comment 13 is just going to confuse people, I think.
Wordpress uses commas to separate tags but allows you to save the tags *before* you save the post. That means that if you screw up entering tags (by entering "foo bar" and getting one large tag), you can fix it immediately. With our set up, you won't know that you messed up the tags until you dismiss the add bookmark dialog and bring it back up, having committed the change. You'll then need to remove each tag and try again, saving it, to check the results by bringing up the dialog again...
>People manage this on Flickr every day for thousands of photos. There are all sorts of pictures on flickr that are tagged both "new" and "york," or "san" and "francisco." External consistency with a really bad interface isn't a usability win.
So instead of using a method that lots of people have learned, possibly the hard way, we want to give them yet another way to tag?
Using commas is just how people make a list of stuff, regardless of if they are typing or writing, it is natural. The field is self describing, but using commas (or semi colons) is not a new behavior to learn. For instance, this is how nearly every email program separates addresses. Notes from a places mockup created on 5/25/07 explaining the design decisions: Mainstream users are not familiar with tagging interfaces. A Pew/Internet research report on 1/31/07 found that only 28% of American Internet users have tagged content, and 7% tag content daily (http://www.pewinternet.org/PPF/r/201/report_display.asp). According to Alexa, Flickr has an global reach of 1% of users, and del.icio.us has a global reach of .8% of users. Even though Firefox users are in general more technical than average computer users, the vast majority of them will still not be familiar with the Web 2.0 meme of "tagging."
Flickr also doesn't want spaces because it is a social tagging system and they want to introduce artificial constraints to get a large community of people to coalesce around a single tag set. That consideration is completely irrelevant for non-social tagging systems.
(In reply to comment #20) > Flickr also doesn't want spaces because it is a social tagging system and they > want to introduce artificial constraints to get a large community of people to > coalesce around a single tag set. That consideration is completely irrelevant > for non-social tagging systems. > for a segment of users, Fx's "local" tag set will be derived from and integrated with social tagging systems.
From what I understood in comment 13, we aren't discussing commas versus spaces here. We're discussing accepting both. Now, you have to have a default. And spaces make sense as a default. It's more intuitive for my mom to type spaces between words than to type a comma. However, if people want to use commas they can still do that. I think the proper goal here is to not require our users to learn any new tagging system. They should be able to use whatever they are already accustomed to using. And I think that this flexibility is a usability win that far outweighs whatever issues people might have with the default entry method(comma versus space versus semicolon).
>And I think that this flexibility is a usability win that far outweighs whatever >issues people might have with the default entry method Issues like a library window full of single word tags that are often meaningless prepositions and verbs, and some very popular tags like "the."
The real issue is that there is too loose a feedback loop in the tag creation process. Thus, the user is left guessing as to where the tags will separate and has to follow the arduous process outlined by Al. As Alex wrote: > We want to do a graphical change to the tag when the user hits comma (kind of > like the tag editor control on OS X, used in places like the to: field in > Mail.app) [not sure if this will make Firefox 3] Please see: http://people.mozilla.com/~faaborg/files/granParadisoUI/places_NewBookmarkDialog_i9.png, and also https://bugzilla.mozilla.org/attachment.cgi?id=272133 (from https://bugzilla.mozilla.org/show_bug.cgi?id=387485) Of course, doing the graphic only after the comma is added is also too late -- the single-word tag case is still ambiguous: will the system make one or two tags? The right solution is to have the visual identity of the tag appear from the get-go. For example (I'm using brackets to denote the visual identity of a tag, and | to denote cursor location): | [f|] [foo bar|] [foo bar],| [foo bar], [baz|] We should also include a note below the tag field letting the user know what the delimiter characters are. Using spaces as delimeters is sub-par as the "new" "york", and "san" "francisco" problem makes clear. Using a tight-feedback loop makes the system self-learning, so that even veteran Flickr users will only get one or two characters wrong before correcting.
This bug should be marked as wontfix, and we should open another bug to correctly implement the originally proposed graphical representation of tags.
First, this does not block final release. Notes beneath delimiters are, IMO, weaksauce. Less documentation in UI, more UI that documents through feedback. Yes, I realize that this means our current approach (documenting in the textarea) is weaksauce; I've always thought of it as a mitigation. Also, yes, we should definitely follow up on the richer visual feedback loop, and the Mail.app style bubbles. I certainly don't think you'll get any objection there. In the absence of that, however, we have a system which will, indeed, be unfamiliar to a subset of the general user population who have cut their teeth on space-separated tags. That's something against which we must balance ourselves. While delicious and Flickr have limited reach, I don't think we should discount the success they have had in teaching their user audiences how to tag. I would suspect that delicious has done a *lot* of research to this end, and maybe if we asked nicely we could borrow some of it. One thing we *could* do now is add an onBlur() method which redraws the tags field with the contents as entered, and have the ENTER button in the tags field not actually dismiss the dialog; that would allow the user to confirm that tags had been faithfully represented, though at the cost of requiring two ENTER presses. Just tossing out ideas, as well as half-baked assertions on user behaviour. ;)
Flags: blocking-firefox3? → blocking-firefox3-
Short article followed by interesting discussion in the comments: http://www.37signals.com/svn/archives2/tag_formats_cant_we_all_just_get_along.php
I remember reading some blog posts by del.ici.ous and flickr about the issue as well, and if I remember correctly I think they summarized their position as they get that the UI is bad, but it gets people to coalesce on a common set, so that's why they still use spaces.
I'm gonna have to disagree with explanatory notes as weaksauce. Indeed, calling something weaksauce is weakargumentescelationsauce ;) In particular, using notes like: "E.g., 'read later', 'vacation', or 'flying spaghetti monster'. Use commas to separate tags." on the tags input helps mitigate the fear of fields labeled with a single, somewhat ambiguous word, as well as the problem of, "Wait, what am I even supposed to put in here, anyway?". Flickr and Delicious both prep the user by having shown them examples of tags left-and-right. We don't have that luxury in Firefox. Notes are little helpful voice -- someone watching over your shoulder -- that guides you through the form. That is to say, more UI that documents through feedback, and more unobtrusive documentation in UI. I would suspect that delicious has done very little real research towards this end, and have iterated gently from the tool that it began as: a way for Joshua to group bookmarks for himself. I don't think we should implement a bandaid fix that fundamentally alters UX for the worse. Facebook has a good implementation (that very cleverly reduces the complexity of programming) of visual representations of tags (check their in-system email "to" field). In liueu of that, we can always use underlines, onKeyUp, as a visual identifier.
Who is the final decision maker on this? All of these questions about tagging have come up more than one time since Summer, 2007 but, other than Alex, it isn't clear who, if anyone, makes the decision at the end of the day (and this isn't a dig on Alex, he's doing a difficult job). It seems like this goes round and round every so often and then we continue as we were.
>Who is the final decision maker on this? beltzner and mconnor
(In reply to comment #26) > One thing we *could* do now is add an onBlur() method which redraws the tags > field with the contents as entered, and have the ENTER button in the tags field > not actually dismiss the dialog; that would allow the user to confirm that tags > had been faithfully represented, though at the cost of requiring two ENTER > presses. Just tossing out ideas, as well as half-baked assertions on user > behaviour. ;) The Things To do tracker does something like this . When you are on the tag entry field, you can type to your heart's content and when you hit enter it highlights your collection of words as a multi-word tag. Alternatively, if you hit comma while typing your tag, the text preceding the comma (either single or several words) is highlighted as a tag. I find it very intuitive and easy to use. Proper visual feedback on what constitutes the tag really makes the separator question moot. However, I'm not sure how a feedback approach like that will be made accessible. : http://www.culturedcode.com/things/
Mconnor, is this going to make 3.1?
retargeting to 3.2 until we get an answer from mconnor
Target Milestone: Firefox 3.1 → Firefox 3.2a1
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
(In reply to comment #34) > retargeting to 3.2 until we get an answer from mconnor Any chance of getting this in 4.0?
Picking up semi colons and quotes as differentiators is ok, but breaking tag names on spaces is both problematic from a usability perspective as described above, and in terms of transitioning the user's existing tag set. If user's really really want to break on spaces, we could perhaps have a hidden about config pref that allows them to modify the set of characters that break apart tag names.
Assignee: mconnor → nobody
Priority: P2 → --
Target Milestone: Firefox 3.6a1 → ---
So this was just reassigned to nobody without an explanation. What happened? Will we never see this feature? Doesn't seem like it should be that complicated. :(
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: 11 years ago → 2 months ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.