404507 - Can't assign bookmark keywords from "Add Bookmark" dialog

Status: RESOLVED DUPLICATE of bug 405795

(Firefox :: Bookmarks & History, defect)

Description

[Matt Hughes]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b1) Gecko/2007110903 Firefox/3.0b1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b1) Gecko/2007110903 Firefox/3.0b1

Currently the only way to assign bookmark keywords is to add a bookmark (CNTL-D), go into the bookmark manager, find the bookmark you JUST ADDED, click on 'Properties', then click the 'More' button, and finally enter your keyword.

You should be able to assign keywords directly from the quick add dialog.  It is a very small dialog already, so I can't imagine size is an issue.

I really like all the work that has been done on bookmarks in this release (Firefox 3, Beta 1) but why, oh why are bookmark keywords so shunned!  They're an awesome feature, but hardly anybody knows about them because you don't even see them unless you venture into bookmark manager.

Reproducible: Always

Steps to Reproduce:
1. Go to a website
2. Add a bookmark (CNTRL-D)
3. There is no way to assign a keyword from the dialog
Actual Results:  
Added a bookmark without any keyword

Expected Results:  
I expect the keyword field to be on the dialog

Proof of fans of this feature: http://lifehacker.com/software/bookmarks/hack-attack-firefox-and-the-art-of-keyword-bookmarking-196779.php

Also, I believe keyword autocomplete (https://bugzilla.mozilla.org/show_bug.cgi?id=212605) should be a very nice addition to fixing this bug.

Comment 1

[Bryan Henry]

Can't find a good dupe for lack of keywords in new star Bookmark Dialog, marking NEW and duping newer bug to this. Not sure how much love this is gonna get, though - that would be a big change this late in the game, but I agree that it is troublesome and user-unfriendly.

Comment 6

[David McRitchie]

Note that Bug 419713 which was marked as a duplicate has some workarounds in "Open Book" extension, and customizable in User style 9029.  Keywords should should also show from Organize Bookmarks (bottom),  the location bar star, and of course Ctrl+D.    Mentioned particularly because in Organize Bookmarks Description etc will take up space from main list, so would want specific control there of what appears there before using the More button.

Comment 8

[[:Aleksej]]

This bug is about the keyword, and that bug includes the URL and proposes a different solution.

Comment 9

[Thomas D. (:thomas8)]

Aleksej and reporter, I agree very much with the goal of this bug, but I think it should be resolved duplicate of 405795 as proposed by Shawn in comment #7, for the following reasons:

1) This bug covers a very small subset (make *Keywords* accesible via "Add/Edit this bookmark" / Bookmark Properties dialogues) of bug 405795 (make *all properties* accessible for the dialogues).

2) If your preferred solution is to have the Keywords property visible /at all times/ (without ever clicking more-button to expand the dialogue): this won't happen. Bug 405795 comment #15 leaves no doubt that the minimal ("streamlined" / "crippled") design of the dialogue is intended and only light-weight ("non-obtrusive") additions will be accepted. As much as I am in favour of making the dialogue expandable to edit all properties, I think adding only "Keywords" property permanently to the reduced(!) dialogue would be very confusing: Average user won't know the difference between tags and keywords. 

3) With 2) in mind, I think there are only 2 possible solutions for this bug:

a) make reduced "Edit this bookmark" dialogue expandable (more-button) to edit all the properties of a bookmark /inside/ the dialogue. IMO, this is the most-needed and most intuitive option.

b) add a button that links to some other way of editing all properties /outside/ the reduced dialogue (all properties window, "Open containing folder in Library" etc.). IMO, this alone(!) makes it unnecessarily complex to edit the props.

c) combine a) and b): expandable properties dialogue AND "Open containing folder in Library" button (cf. bug 469441). IMO, this is the best solution with added value.

All these possible solutions are covered and discussed in bug 405795. I have proposed a sample UI of the expandable dialogue in bug 405975 attachment 392075 [details], which solves the problem of this bug by combining the best of a) and b).
In other words: we should focus our energy on finding a good solution for bug 405795 that makes everyone happy.

Aleksej and reporter, any objections against resolving this bug as a duplicate?

Comment 10

[Thomas D. (:thomas8)]

Can we please remove wontfix? nomination from this bug?
It's an insult in the face of 10 votes, several duplicates, more votes at bug 405795, and especially the outstanding popularity of Firefox's unique "smart keyword" feature, as can be seen from google search results like the following:
http://www.google.com/search?q=Firefox%20bookmark%20keywords

Comment 11

[Shawn Wilsher :sdwilsh]

(In reply to comment #10)
> Can we please remove wontfix? nomination from this bug?
No, unless a module owner does so.  It's nominated for wontfix by a module peer, and the module owner will take a look at it at some point.

Comment 12

[Thomas D. (:thomas8)]

It's good to know that you have your hierarchies all sorted. We also get a sense where the user might be in that hierarchy: somewhere far down at low interest level. To assist with taking an informed look at it "at some point", here's some references both future and past all asking for the same thing: Can we please have some easy way of adding a keyword while bookmarking pages?

http://forums.mozillazine.org/viewtopic.php?f=8&t=1431655
https://bugs.launchpad.net/firefox/+bug/237679
http://forums.mozillazine.org/viewtopic.php?f=38&t=552496&start=0
http://forums.mozillazine.org/viewtopic.php?f=23&t=687835&start=0
http://forums.mozillazine.org/viewtopic.php?t=650888
http://forums.mozillazine.org/viewtopic.php?f=7&t=179600
http://forums.mozillazine.org/viewtopic.php?p=350092
http://forums.mozillazine.org/viewtopic.php?f=38&t=482646&p=2578288

Comment 13

[Marco Bonardo [:mak]]

This usage of keywords looks like misuse as tags, keywords adding natural UI is: right click a search field and choose "add a keyword for this search". Otherwise looks like you want a tag on your bookmark.
We need clear use-cases that are not "type g and press enter to go to Google" obviously.

And the awesomebar can find bookmarks quite efficiently typing partial content, thus removing the need for a short "nickname" for the bookmark that we had in FX2.

Users are on top of the hierachy, but even if Firefox is built to accomplish satisfaction in most users, it just can't satisfy every user. That's why we have a user experience team, module owners and so on, to be able to take decisions that we think are good for most users, but maybe they won't be for all of them (with hundreds millions users you can understand how hard that can be). And that's also why extensions do exist, and i'm pretty sure an extension that does that already exists as of today.

that said, i won't spam anymore here, all the needed requests are filed.

Comment 14

[Thomas D. (:thomas8)]

(In reply to comment #13)
Thanks for that comment, it was helpful to understand your personal perception of keywords and thus your problem with this bug. Marco, are you using keywords yourself? As a location bar keyboard shortcut for opening URLs with and without query parameters? Looking at comment #13, I guess not...

> This usage of keywords looks like misuse as tags, keywords adding natural UI
> is: right click a search field and choose "add a keyword for this search".
> Otherwise looks like you want a tag on your bookmark...
> And the awesomebar can find bookmarks quite efficiently typing partial
> content, thus removing the need for a short "nickname" for the bookmark that
> we had in FX2.

Absolutely NOT. You _cannot_ use a tag instead of a keyword as a keyboard shortcut to _reliably_ open a static URL with as few steps as possible. The functionality is very different, and in most cases, it simply won't work (since location bar autocomplete is based on frecency more than on keyword matches, and they're competing with your history matches). Even defining a _unique_ tag will _not_ ensure autocomplete match from location bar, so tags are pretty useless as a shortcut for specific urls (I can provide STR for a test case, if needed). Whereas the _keyword_ shortcut works 100% of the time, and guaranteed hassle-free: Ctrl+L, type keyword, press Enter - you're there. Works like a charme, without thinking, parsing, cursoring and everything, straight from your muscle memory. Always.

So keywords provide valuable functionality for highly efficient browsing; therefore, adding keywords to a bookmark should be easy. It's way too hard now (especially when creating a new bookmark; quote below from http://forums.mozillazine.org/viewtopic.php?f=8&t=1431655):

-------------------------------------------------------------
Actual Behaviour (missing on comment #0):

> Right now, to assign a keyword, we have to do this:
>
> . select bookmark this page
> . ctrl+shift+B
> . search for the bookmark
> . select "more"
> . enter the keyword
> . close
>
> #-o [-( The insanity of it all!!! 8-[
-------------------------------------------------------------
Yes, it's insane. Therefore this bug. Access to all properties of a bookmark from it's most prominent representation (the star) should NOT need extensions.

A simple fix that can make virtually everyone happy has been proposed in bug 405795:
-> Add some sort of tiny [v] more button to expand the crippled "Edit this bookmark" dialogue (cf. mockup screenshots, attachment 391888 [details], attachment 392075 [details], attachment 392887 [details])

The fact that we are deliberately hiding valuable functionality (keywords) to an extent that the average user will never find it, is also detrimental to Firefox adoption (cf. comment #0):
> ...but why, oh why are bookmark keywords so shunned! They're an awesome
> feature, but hardly anybody knows about them because you don't even
> see them unless you venture into bookmark manager.

From a Mozilla inside perspective, the article "How Cool are Custom Keywords" by Mozilla's Asa Dotzler looks pretty much supportive of this view (http://www.mozilla.org/docs/end-user/keywords.html). I know Asa from the Mozilla Europe Camp 2009 to which I was invited for my bmo contributions, and I'm sure he knows what he is talking about.

Finally (quoted from http://forums.mozillazine.org/viewtopic.php?f=8&t=1431655):
> So, if someone can make this happen, you will definitely make me happy and
> you might also make millions of others just as happy.

Links:
- Keywords: http://www.mozilla.org/docs/end-user/keywords.html, http://kb.mozillazine.org/Using_keyword_searches
- Tags: http://support.mozilla.com/en-US/kb/Bookmark+tags
- Conceptual difference between keywords and tags: http://forums.mozillazine.org/viewtopic.php?p=7896835&sid=66f7fa0d4a0ca16468afed8bd1169580#p7896835

Comment 15

[Thomas D. (:thomas8)]

(In reply to comment #13)
> We need clear use-cases that are not "type g and press enter to go to Google"
> obviously.

OK, maybe this usage quoted from "How Cool are Custom Keywords?" (by Mozilla's Asa Dotzler) is good enough? (http://www.mozilla.org/docs/end-user/keywords.html, my emphasis):

> Mozilla Custom Keywords ROCK! Not just for making *shorthand for bookmarks*
> but also for searches and queries. Simple keywords allow you to type a short
> string in the Location Bar and load its corresponding Bookmark URL.
>
> *An example is my bookmark for http://www.mozilla.org to which I've added the
> keyword "m.o".* So, with that set, I can type "m.o" in the Location Bar and
> it loads http://www.mozilla.org. Using keywords combined with autocomplete in
> Mozilla and I seldom type more than about three or four characters for all of
> the sites I regularly visit.

As requested by comment #13, here's some more "clear use-cases that are not 'type g and press enter to go to Google'" (some of my keyword shortcuts for loading _static_ URLs):

mo -> www.mozilla.org (Sites of personal interest; all with similar names and thus usually not directly addressable via location bar matches)
mz -> www.mozillazine.org
mdc -> https://developer.mozilla.org/En (*)
xul -> https://developer.mozilla.org/En/XUL (*)
bzo -> www.bugzilla.org (important portals)
wpo -> www.wikipedia.org (reference works start pages)
sh -> www.selfhtml.org
shf -> http://forum.de.selfhtml.org (forum entry pages of all sorts)
he -> http://htmledit.squarefree.com/ (Real time HTML Editor)
abc -> www.abc-school.de (my workplace; this is not the real link)
ob -> www.my-bank.de/onlinebanking (my bank account; not the real link)
ucc -> www.xe.com/ucc/ (Universal currency converter)
yt -> www.youtube.com (sites where the start page provides appetizers)
zw -> www.sokwanele.com/thisiszimbabwe (news sites of personal interest)

All of these I am using on a daily basis for the fastest possible access to my favourite sites (_static_ URLs). In addition, I have a lot of smart keywords for "query URLs". With millions of users, I'm sure a _lot_ of people will use this in a similar way. HTH.

(*) "mdc" and "xul" as shortcut keyword for Mozilla Devolper Center / XUL Project are two more good examples why tagging just won't do the trick: after typing "mdc" / "xul" in location bar, you'd get countless matching pages from your browsing history on MDC / XUL. On the other hand, hit "Enter" after your favorite shortcut keyword and it'll get you straight to the respective pages. No fuss, 100% of the time.

> keywords adding natural UI is: right click a search field and choose "add a
> keyword for this search".

Unfortunately, we can't set keywords for _static_ urls using this method.
In addition, even for query URLs, the context menu method won't work for certain cases (e.g. http://maps.google.com/) and will create untidy URLs with unknown and unnecessary parameters set. All of these problems would be easily cured by making all bookmark properties accessible from the respective bookmark dialogues (Bug 405795).

Comment 16

[Marco Bonardo [:mak]]

We will provide an updated bookmarking UI soon, that *could* satisfy your needs, as it could not. Firefox is designed to satisfy most users, not always any user, unfortunatly. You are free to partecipate to the design discussions with our UX team. We will soon post mockups to get feedback, as we are used to do, it's wrong to think we don't listen, we just have to make choices.

I see your passion, and it's fine, but please be polite toward us.

This bugs as "extend current star panel with additional fields", even if hidden, is still wontfix imo, but new design could probably have space to reduce the user road toward keywords.

Comment 17

[Thomas D. (:thomas8)]

(In reply to comment #14)
> (In reply to comment #13)
> You _cannot_ use a tag instead of a keyword as a keyboard
> shortcut to _reliably_ open a static URL with as few steps as possible. ...
> In most cases, it simply won't work (since location bar autocomplete is based 
> on frecency more than on keyword matches,

typo fix: Using tag instead of keyword often won't work because location bar autocomplete finds and orders matches based on frecency more than based on _*tag*_ matches, and so tag matches are competing with your history matches, which are likely to be listed near the top.

So while a bookmark with matching tag might not even show on the autocomplete list at all, a bookmark with a matching keyword will always show at the very top of autocomplete list (but I won't even need the list as I just use the keyword).

(In reply to comment #16)
> We will provide an updated bookmarking UI soon,

Let's hope that this is good news.

> Firefox is designed to satisfy most users, not always any user, unfortunatly. 
> ...we just have to make choices.

I fully understand and accept this. My point is that in this particular case, there are two proposed solutions in bug 405795 that could satisfy everyone without losing anything (don't change the reduced dialogue so as to keep it simple, but add a tiny toggle to make it expandable as we do in bookmark manager properties pane).

> We will soon post mockups to get feedback, as we are used to
> do, it's wrong to think we don't listen

Thank you for listening, and I'm sure you do. I think it's when easy solutions with a lot of benefit but no or virtually no negative impact get rejected without good arguments (or even wrong arguments), that we might feel not listened to. I know it's tricky because "good arguments" are hard to define, and tend to vary from different points of view.

Where will the mockups be posted? Can you leave a note on this bug when they are?

> This bugs as "extend current star panel with additional fields", even if
> hidden, is still wontfix imo, but new design could probably have space to
> reduce the user road toward keywords.

I accept that we want to keep the reduced star panel as a default, but unfortunately I'm perfectly failing to see what's wrong with making it expandable (which really seems the shortest and most intuitive road)...
As a way out, maybe we can try along Alex' proposal of bug 405795, comment #20 (completely unobtrusive "expand to window" icon, tear-off-approach), explained in bug 405795, comment #25 and welcomed by Marco in bug 405795, comment #24. :)

Marco, you think we could duplicate this against bug 405795 (as proposed by Shawn in comment #7, and explained in comment #9 with no reply or objection from reporter or Aleksej, who wanted to keep this separate in comment #8)?
Inaccessibility of keywords from "Edit this bookmark" dialogue seems to be a subset of bug 405795 in that Description, URL (cf. bug 518423), and bookmark's folder are also inaccessible, and if anything, we'd probably want a unified approach that makes _all_ properties available somehow...

Finally (@FF devs and contributors), thanks for all the good work you do, we've seen some great improvements shipping with the most recent versions of FF. Keep it up!

Comment 18

[Marco Bonardo [:mak]]

(In reply to comment #17)
> Where will the mockups be posted? Can you leave a note on this bug when they
> are?

bug 524071 is aimed to add an UI that will provide all fields at a click distance, the current idea is a right sidebar. Please avoid long comments, try to be concide, Alex needs a clean bug, so any suggestion should be expressed in a few words and/or point to a newgroups discussion in moz.dev.apps.firefox.

> I accept that we want to keep the reduced star panel as a default, but
> unfortunately I'm perfectly failing to see what's wrong with making it
> expandable

not  all the users are good with expandable UIs, especially basic users tend to forget they can contract panels. moreover that panel was intended to allow really quick bookmarking, and it already has too many controls in it, it should be small and sleak, while already now it appears bloated.

> Marco, you think we could duplicate this against bug 405795 (as proposed by
> Shawn in comment #7, and explained in comment #9 with no reply or objection
> from reporter or Aleksej, who wanted to keep this separate in comment #8)?

Imho that's the right choice, as you want keywords, some other user could want description, and so on, so there is not much difference to bug 405795

Comment 19

[Thomas D. (:thomas8)]

Interestingly, Firefox 3.7 / 4.0 are actually heading for a powerful _EXPANSION of keywords magic_ by introducing TASKFOX*, which will see a _massive_ return of a familiar use pattern... :

(from: https://wiki.mozilla.org/Taskfox/Use_Cases)
* Select part of the page you want to send
* Type into address bar: "email this to blair" ["map this" | "weather" | etc.]
* Hit enter 

:)))

(In reply to comment #17)
Thanks for pointing out bug 524071, up since 2009-10-23, mentioning that one a bit earlier might have avoided a lot of discussion around here...

*: https://wiki.mozilla.org/Firefox/Projects/3.7_and_4.0_Theme_and_UI_Revamp/Direction_and_Feedback#Merging_the_LocationBar_and_SearchBar

Comment 20

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to comment #19)
> Interestingly, Firefox 3.7 / 4.0 are actually heading for a powerful _EXPANSION
> of keywords magic_ by introducing TASKFOX*, which will see a _massive_ return
> of a familiar use pattern... :

While one of the ideas I explored in Taskfox was to improve support for the existing keyword functionality, I don't think its relevant to this bug.

Comment 21

[Gervase Markham [:gerv]]

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

Comment 22

[tigernerve]

I see that no one is working on this bug. I would be willing to volunteer my time to help fix this, yet I don't know much programming. Does anyone know how I can access the code and what computer language this is written in?

[e-mail]

Comment 23

[Mackenzie]

Firefox is written in C++ on the backend and XUL (easy if you know HTML) and Javascript on the frontend.  Source code info: https://developer.mozilla.org/En/Developer_Guide/Source_Code

Comment 24

[Marco Bonardo [:mak]]

We don't plan to add keywords to the default UI, whether we'll provide an alternative "full-edit" UI is bug 405795, there is no other plan to do partial changes.