457736 - (freeform-tags-field) Inline contact editor (and Edit Contact properties dialogue) should support freeform contact tags (single-row simple text input field)

Status: NEW

(Thunderbird :: Address Book, enhancement, P3)

Description

[Andrew Sutherland [:asuth] (he/him)]

Attachment: Add a "tags" row to the edit contact overlay.

It would be nice to be able to tag contacts.  It is probably advisable to start out with a light-weight implementation, allowing simple free-form tags delimited by commas.  This set of tags exists in a separate realm from the message tags for reasons of simplicity and because I believe our use of IMAP keywords (and servers' limitations on that front) prefers a much more bounded set of tags.

I have attached a patch that implements this for the 'edit contact overlay', which I believe is being referred to as the 'inline contact editor'.  It simply adds a "tags" property on the cards.  I understand that in vCard space, CATEGORIES is probably the right name to use, but it sounds like that requires an underlying mapping/transformation anyways, and 'tags' is much more intuitive for extension developers.

Comment 1

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 340958 [details] [diff] [review]
Add a "tags" row to the edit contact overlay.

Looks good, but if you could add an emptytext attr to the tags textbox you'd get a gold star!

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

Attachment: v2 add a "tags" row to the edit contact overlay.

Add emptytext per clarkbw.

Comment 3

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 340962 [details] [diff] [review]
v2 add a "tags" row to the edit contact overlay.

excellent!  though only a silver star for making me review again :)

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 340962 [details] [diff] [review]
v2 add a "tags" row to the edit contact overlay.

Standard8 (and other people who know address book things), implementation input/thoughts appreciated.  Pointers to other bugs about address book tagging also good.

Comment 5

[Mark Banner (:standard8)]

Bug 75711 would probably be the main tagging bug and the only one I can find at a glance.

I'm surprised we've got no error checking/tidy up on input here? What about ",," or "my, tags , xyz abc " ?

The tags property should also become a built-in option. Which raises the question, should we be re-using our existing "Category" field or just dumping that? It would be good to have Joshua's input here.

I think it would also be nice to have the drop-down quick select that Firefox has got.

We also need to think about the address book UI - are we going to do something similar on the cards? What about quick edit menus/buttons? and quick search.

Comment 6

[Andrew Sutherland [:asuth] (he/him)]

(In reply to comment #5)
> I'm surprised we've got no error checking/tidy up on input here? What about
> ",," or "my, tags , xyz abc " ?

I've implemented a consumer of this property in gloda and exptoolbar (aka the "thunderbar").  gloda indexes the tags, performing the normalization as it goes.  ",," contributes no tags, "my, tags , xyz abc " contributes ["my", "tags", "xyz abc"].

If the user enters gibberish, as long as it doesn't unduly confuse us, I'm not entirely sure there's a major benefit to cleaning it up for them.  If we clean it up as they type, it could be confusing/frustrating.  If we clean it up after they type, why didn't they fix it in the first place?

> We also need to think about the address book UI - are we going to do something
> similar on the cards? What about quick edit menus/buttons? and quick search.

It is my understanding that the current address book UI is destined for some major refactoring, likely taking the form of building off of the edit contact overlay.  I can obviously put this on there for now, though.  Suggestions on where it should go?

What a quick edit menu/button?

As noted above, the "ThunderBar" has matching/completion on these tags.  Check out gloda, exptoolbar, and apply this patch to enjoy.

> The tags property should also become a built-in option. Which raises the
> question, should we be re-using our existing "Category" field or just dumping
> that? It would be good to have Joshua's input here.

So all those explicit attributes aren't just for backwards compatibility?

> I think it would also be nice to have the drop-down quick select that Firefox
> has got.
 
Yes, Bryan seems to like it so I'm fine with it.  This would imply an automated parse/overwrite update, but I'm still not sure if we should do it unless the user uses this functionality.

Comment 7

[Joshua Cranmer [:jcranmer]]

(In reply to comment #6)
> > The tags property should also become a built-in option. Which raises the
> > question, should we be re-using our existing "Category" field or just dumping
> > that? It would be good to have Joshua's input here.
> 
> So all those explicit attributes aren't just for backwards compatibility?

I *think* that Palm Sync uses the Category field for sync-related stuff, but I'm not 100% sure. What I do know is that no one used the kCategoryColumn that used to be defined in nsIAddrDatabse.idl.

Comment 8

[David :Bienvenu]

I think that's right about Palm Sync and the Category field.

Comment 9

[Mark Banner (:standard8)]

(In reply to comment #6)
> (In reply to comment #5)
> > I'm surprised we've got no error checking/tidy up on input here? What about
> > ",," or "my, tags , xyz abc " ?
...
> If the user enters gibberish, as long as it doesn't unduly confuse us, I'm not
> entirely sure there's a major benefit to cleaning it up for them.  If we clean
> it up as they type, it could be confusing/frustrating.  If we clean it up after
> they type, why didn't they fix it in the first place?

Users are lazy. The other thing is, we would have to include code to handle the blank cases (i.e ,, or , ,) at every place we use the tag field.

> > We also need to think about the address book UI - are we going to do something
> > similar on the cards? What about quick edit menus/buttons? and quick search.
> 
> It is my understanding that the current address book UI is destined for some
> major refactoring, likely taking the form of building off of the edit contact
> overlay.  I can obviously put this on there for now, though.  Suggestions on
> where it should go?

On the "Other" pane?

> What a quick edit menu/button?

At one time it was mentioned about having a quick selection button list on the toolbar - that has probably changed now.

I think Bryan (or someone) really needs to explain to me what the proposed changes for the address book UI are, I'm hearing about things but I've not seen anything written down.

> > The tags property should also become a built-in option. Which raises the
> > question, should we be re-using our existing "Category" field or just dumping
> > that? It would be good to have Joshua's input here.
> 
> So all those explicit attributes aren't just for backwards compatibility?

Nope. Most of them are used on interfaces, e.g. import/export of address book cards, for LDAP & other interfaces. For example:

http://mxr.mozilla.org/comm-central/search?string=kJobTitleProperty

I'd also want a statement somewhere as to what the expected format of the field is, especially if we are (or are not) allowing things like ', ,'.

At some stage I need to also take a quick look at how tags can be implemented on/interfaced to LDAP/OS X/Outlook directories and see if that influences us as well. I'll try and do that Monday.

Comment 10

[Dan Mosedale (:dmosedale, :dmose)]

The world (CardDAV, hCard, PORC) seems to be converging on something that's more or less compatible with vCard v3, so I suggest we want to use that semantic model for the field.  The latest vCard draft sez:

7.7.1.  CATEGORIES

   Purpose:  To specify application category information about the
      vCard.

   Value type:  One or more text values separated by a COMMA character
      (ASCII decimal 44).

   Example:

           CATEGORIES:TRAVEL AGENT

           CATEGORIES:INTERNET,IETF,INDUSTRY,INFORMATION TECHNOLOGY

Possibly commas could be escaped, but it's unclear to me whether that's worth while.

Comment 11

[Andrew Sutherland [:asuth] (he/him)]

(In reply to comment #10)
> The world (CardDAV, hCard, PORC) seems to be converging on something that's
> more or less compatible with vCard v3, so I suggest we want to use that
> semantic model for the field.  The latest vCard draft sez:

That's fine with me.  It also looks like the "palm category" does not involve the CATEGORIES field.  It looks like the palm-sync code uses the category on the palm side to identify the address book the contact came from.  This is mapped to an integer id which is what gets stored on the directory (as "PalmCategoryId").

So we should be fine to use CATEGORIES.  And I will happily introduce a constant for it because I don't want to be typing in capitals all over the place.

Comment 12

[Mark Banner (:standard8)]

(In reply to comment #11)
> So we should be fine to use CATEGORIES.  And I will happily introduce a
> constant for it because I don't want to be typing in capitals all over the
> place.

I don't think we need to use it with capitals. Translation to vcard will be done via an interface. So using something like "Categories" should be fine in our back-end.

Comment 13

[Mark Banner (:standard8)]

Having just had another look around, there is already defined a "Category" field. We could potentially use that, though I'm a little concerned if extensions have started using it, whether it would really be a good idea to use it and turn it into a comma-separated list of fields.

Comment 14

[Mark Banner (:standard8)]

Comment on attachment 340962 [details] [diff] [review]
v2 add a "tags" row to the edit contact overlay.

Per current discussions

Comment 15

[Andrew Sutherland [:asuth] (he/him)]

From IRC discussion with Standard8 (Mark), the current plan is:

* Use "Categories", adding it as a constant on nsIAbCard.  (Category doesn't work for pluralization reasons.)
* Shorten the notes field, add tags to the "other" address book card display tab.
* Add normalization post-edit.
* Add a follow-up bug about implementing a cool drop-down list of existing tags to the edit field, much like Firefox has for its bookmark tags field.  One issue for that is what code acts as the oracle for the list of known tags.  Gloda's FreeTagNoun will know these things; I'm not sure what other code might know.

Comment 16

[Günter]

@Mark, thanks for phasing me in!

I very much welcome the move to have the CATEGORY included in future TB/AB. As I'm working very much on iCAL/ICS based apps (ReminderFox and Lightning) today my question is, how to have a 'general' category(ies) stack for the whole Thunderbird. To be used by Addressbook, Lightning and other app's? Maybe to have a prefs to store the 'default' or also the 'used' items (as we do it with ReminderFox).
As request with the other bug 364152 back in 2006-12-17 that 'general' pref would increase the value of TB !!

@comma separated values
LG already have been extended to use CSV for the 'categories' also it isn't reflected with the 0.9 UI.  (Thanks to [e-mail])
see also: LG Bug 316927 – Multiple categories should be allowed for Events/Tasks

Comment 17

[Andrew Sutherland [:asuth] (he/him)]

Attachment: v3 add a "tags" row to the edit contact overlay, uses Categories

Just updating the patch to use "Categories" instead of "tags" for those who are using bleeding-edge gloda (which now only indexes Categories).  I still need to address the other points.  Keeping ui-r=clarkbw.

Comment 19

[David :Bienvenu]

this would be very nice to have for b1, but not blocking.

Comment 20

[Wayne Mery (:wsmwk)]

(In reply to comment #11)
> (In reply to comment #10)
> > The world (CardDAV, hCard, PORC) seems to be converging on something that's
> > more or less compatible with vCard v3, so I suggest we want to use that
> > semantic model for the field.  The latest vCard draft sez:
> 
> That's fine with me.  It also looks like the "palm category" does not involve
> the CATEGORIES field.  It looks like the palm-sync code uses the category on
> the palm side to identify the address book the contact came from.  This is
> mapped to an integer id which is what gets stored on the directory (as
> "PalmCategoryId").
> 
> So we should be fine to use CATEGORIES.  And I will happily introduce a
> constant for it because I don't want to be typing in capitals all over the
> place.

That is correct per my understanding. The palm implementation is a category on palm maps to an ABname in TB. (and there is a pref to exclude certain ABs from being synced)


(In reply to comment #0)
> It would be nice to be able to tag contacts.  

more like killer bling.  sign me up

Comment 21

[Wayne Mery (:wsmwk)]

xref bug 75711

Comment 22

[Mark Banner (:standard8)]

Unless I've misunderstood Bryan, this is no longer on the blocking list for TB 3.0 - we won't hold the release for it, however this is still very much a wanted bug.

Comment 24

[Thomas D. (:thomas8)]

(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #20)
> (In reply to Andrew Sutherland's comment #0)
> > It would be nice to be able to tag contacts.  
> 
> more like killer bling.  sign me up

attachment 344874 [details] [diff] [review]

Omg, can someone PLEASE revive this nifty patch!? :) :) :) Looks like it could still work as-is after correcting offsets... awesome cost-benefit ratio!!! So after 7 years of slumber, we should really redeem this fantastic thing from just lying around...!

This provides a simple, yet extremely powerful basic version of the more sophisticated feature set probably intended by bug 75711, which has 12 duplicates and 25 votes.

With this, we could provide a dead-simple fix for the current usability gap that there's not a single AB field which is
- explicitly dedicated to adding tags for searching/grouping of contacts AND
- actually searched by AB searches and recipient autocomplete AND
- avoiding to send search words with the display name of recipients of the actual message

The patch adds one simple freeform text field to store the tags, which can now be used straight away for powerful usecases like targeted addressing to [multi-]tagged groups of contacts (via AB or contacts side bar), because Suyash and I have already done the ground-breaking backend groundwork in Bug 1000775: For AB Quicksearch / contacts side bar, implement split multiword search pattern (*foo* AND *bar* for XXL search power; port bug 558931 to AB).


Sample scenario

User has these contacts:
John Doe      - Tags: work, friends, QA
Jane Doe      - Tags: friends
Max Miller    - Tags: work, UX
Susan Johnson - Tags: friends

Then in AB quicksearch or contacts side bar, it's oh-so-simple to do powerful searches which will return the groups of contacts according to their tags:

Search For: friends
-> returns John, Max, Susan
(but also [e-mail] if you happen to have that, see below)

Search For: work
-> returns John, Max

Search For: work UX
-> returns Max

Users who want to avoid any potential false positives (like friends -> [e-mail]) can just make their tags unique enough so they won't possibly occur in other fields like Name or Email, e.g. by adding a special character like # to all the tags in the freeform tags field (and when searching):

John Doe      - Tags: #work, #friends, #QA

Fwiw, in this simple implementation it's rather irrelevant how freeform tags are separated (comma, spaces etc.), but we can recommend comma in placeholder text of the input box, to make future transitions to a tag database easier.

Further hints for implementation:

1) start from existing patch with a simple, single freeform textfield; for this bug, we will not do the bells and whistles like dropdown tags lists you can choose from because then it'll take us another year to deliver progress (whereas this could be simple enough to still land as a cool feature for TB 38, paired with Bug 1000775).

2) not sure why the internal name of the new field is categories and not just tags, but it probably doesn't matter; some relevant discussion can be found on this bug.

3) existing patch only adds the tags field in the inline contact editor XUL (from yellow star); pls add the field also in the "Edit properties" dialogue, probably on 'Contact' tab because it's so important and also nicely grouped with the other name/email fields we search (otherwise on 'Other' tab)

4) For the XXL search power, add the tags field to our default searches:
4a) AB quicksearch/contacts side bar

http://mxr.mozilla.org/comm-central/source/mail/locales/en-US/chrome/messenger/messenger.properties#279
> 279 mail.addr_book.quicksearchquery.format=?(or(PrimaryEmail,c,@V)(DisplayName,c,@V)(FirstName,c,@V)(LastName,c,@V))

Note that we want to change that into a non-localized pref in Bug 118624.

4b) Recipient autocomplete initial search

http://mxr.mozilla.org/comm-central/source/mailnews/addrbook/src/nsAbAutoCompleteSearch.js#385
> 385       let modelQuery = "(or(DisplayName,c,@V)(FirstName,c,@V)(LastName,c,@V)" +
> 386                        "(NickName,c,@V)(PrimaryEmail,c,@V)(SecondEmail,c,@V)" +
> 387                        "(and(IsMailList,=,TRUE)(Notes,c,@V)))";:

4c) Recipient autocomplete secondary search (narrow down result set)

http://mxr.mozilla.org/comm-central/source/mailnews/addrbook/src/nsAbAutoCompleteSearch.js#224
> 224   _checkEntry: function _checkEntry(aCard, aEmailToUse, aSearchWords) {
> 225     // Joining values of many fields in a single string so that a single
> 226     // search query can be fired on all of them at once. Separating them
> 227     // using spaces so that field1=> "abc" and field2=> "def" on joining
> 228     // shouldn't return true on search for "bcd".
> 229     let cumulativeFieldText = aCard.displayName + " " +
> 230                               aCard.firstName + " " +
> 231                               aCard.lastName + " " +
> 232                               aEmailToUse + " " +
> 233                               aCard.getProperty("NickName", "");

Comment 25

[Thomas D. (:thomas8)]

For shipping TB 38, this bug 457736 (freeform tags field for contacts) would complement the following new features well, to show our commitment to improving the AB (in view of the ongoing lack of a new AB):

Bug 1000775 - For AB Quicksearch / contacts side bar, implement split multiword search pattern (*foo* AND *bar* for XXL search power; port bug 558931 to AB)

Bug 170270 - Enable search in multiple/all address books

The common denominator being substantial improvements to the processes of searching / managing contacts.

Comment 26

[Kent James (:rkent)]

Does anybody know why this died originally?

Comment 27

[Günter]

@Kent
See comment#22 by Mark. Afair this feature was skip from the list for TB3.0 -- think for good reason -- it was challenging enough with the other features. 

As of today there should be more focus on finally implementing the AB/cardDAV. There was a summer project in 2011 by Jon Demelo, coached by Mike Conley. Think it was very promising but the whole missed to be based on a db implementation. The final call by Mike was in Dev 2013.
Please contact Joshua Cranmer for this also.

See also these bugs:
Bug 444093 - Spec out nsIAbItem::uuid more clearly started 2008-07-08 by Joshua Cranmer 
Bug 413260 - Refactor the Address Book interfaces

Comment 28

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Kent James (:rkent) from comment #26)
> Does anybody know why this died originally?

I think I created the original patch for an "exptoolbar" (http://www.visophyte.org/blog/tag/exptoolbar/) feature, but the initial gloda search UI we went with didn't end up including an affordance that leveraged this or did anything at all with it.  Without something consuming it, I think it made less sense to expose the UI, because one would naturally assume that you could search on the values, etc.

However, the actual gloda changes did land.  So I think my plan was to develop some extension that both used the data and re-added UI to tag contacts, and then we'd go from there.