Closed Bug 92135 Opened 23 years ago Closed 23 years ago

Show source of suggested matches in addressing results list

Categories

(MailNews Core :: Composition, defect, P2)

defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.4

People

(Reporter: jglick, Assigned: dmosedale)

References

Details

(Whiteboard: have r=, sr=, a=)

Attachments

(15 files)

32.41 KB, image/gif
Details
10.37 KB, patch
Details | Diff | Splinter Review
16.94 KB, patch
Details | Diff | Splinter Review
29.47 KB, image/png
Details
16.95 KB, patch
Details | Diff | Splinter Review
28.26 KB, patch
Details | Diff | Splinter Review
25.88 KB, patch
Details | Diff | Splinter Review
413 bytes, image/gif
Details
427 bytes, image/gif
Details
33.19 KB, image/png
Details
17.78 KB, image/png
Details
34.62 KB, image/png
Details
37.17 KB, image/png
Details
26.27 KB, patch
dmosedale
: review+
Details | Diff | Splinter Review
130 bytes, image/gif
Details
Mail Compose window: Addressing area.

When addressing a mail message, a dropdown list of potential matches is 
displayed.  Use "Address Book" and "Directory" icons to indicate if listed 
results are from one of the user's Address Books or from an LDAP directory.  See 
attachment below.
Attached image Example
Hewitt, we will need to figure out together how we want to implemant that.
Status: NEW → ASSIGNED
QA Contact: sheelar → fenella
It would also be nice if the drop-down could show the name of the address book
that each match comes from. This could be displayed in the same style as page
titles for URL bar autocomplete (i.e. a column to the right). Here's an ASCII
art representation:

[*] John Doe <john@doe.com>             Collected Addresses
[*] John McDonald <john@hotmail.com>    InfoSpace Directory
[*] John Smith <jsmith@netscape.net>    Personal Address Book

[*] = Icon
See also the recent comments on 89198.
Keywords: nsenterprise
I'm moving the UI stuff from 89198 to this bug, since they can land in the tree
separately, and the UI stuff proposed there has to play nice with whatever
happens here.

Here's hewitt's patch to expose the comment field in the addressbook
autocomplete dropdown:

http://bugzilla.mozilla.org/showattachment.cgi?attach_id=45274

And here's a .png after my changes to the LDAP autocomplete code that uses the
"ou" (Organization Unit) field as the comment:

http://bugzilla.mozilla.org/showattachment.cgi?attach_id=45310

I'd like to see this, or something similar, land for 0.9.4, so any comments and
thoughts now would be very helpful.

mpt, jglick, ducarroz: any thoughts on this?
As I was forwarded to this bug and I place my ideas here:

We can put source of guessed address right-aligned in the autocomplete list? As
I've seen comments here, OU could go to comments too. Icons to the left looks
really cute. Extra option not mentioned here is error reporting: they could be
reported right there (instead of guessed address). "No match" could be just
ommited but all other errors reported.

[*] John Smith <jsmith@netscape.net>     Personal Address Book
[*] John Doe <john@doe.com>                Collected Addresses
[*] John McDonald <john@hotmail.com>       InfoSpace Directory
[*] Cannot connect to server              Prosolis Addressbook

I will post similar comment to 79935.
I'm not fond of error reporting in this particular place. We should simply leave
out the results of the failed server query. Most users don't care to debug their
LDAP server in the typedown widget. 

The question also is whether we want to expose the name of the record source, or
the comment field from the target data source. 
e.g., 
* Joe Smith - Personal Address Book
* John Smith - Collected Address Book
* Bill Smith - LDAP Server
vs. 
* Joe Smith - Marketing <org field maybe>
* John Smith - Vice President <or Title field>
* Bill Smith - Vice President, Finance <or both>

What's possible?
Adding nsBranch, moving nsenterprise+.
Targeting 0.9.4.
Target Milestone: --- → mozilla0.9.4
Blocks: 17880
r/sr=blake
I've just landed the patch that makes it an option to show the comments column.
Can we make columns of autocompletion configurable (just like messagelist
columns). For small enterprises and personal use displaying source (some
Addressbook, Collector, LDAP, etc.) makes sence.
Myroslav: that sounds like a useful thing, though I think it's more work than
we've got time for at the moment.  It's worth keeping in mind as we move
forward, though.

Kevin: codewise, the most straightforward option is to do the former (record
source) by default, and leave a hidden preference for LDAP directories so that
they can choose instead to have the comment field be any combination of LDAP
attributes.  

I'll put together an implementation of this shortly.
Keywords: nsBranchnsbranch
Very good. Thanks Dan.
Taking; I hope to land at least basic support for this for 0.9.4.
Assignee: ducarroz → dmose
Status: ASSIGNED → NEW
QA Contact: fenella → nbaca
OK, this latest patch has several tweaks:

* it fixes an i18n bug srilatha found in nsAbLDAPAutoCompleteFormatter exposed
by the first version of the patch

* it turned out that using comments on the default compose window size (640x480)
maybe things even more scrunched than originally though.  So a hidden preference
named mail.autoComplete.showCommentColumn has been added; defining this to false
will switch off the comment column.

* the nsAbLDAPAutoCompleteFormatter::commentFormat has been changed to default
to "" to save a few cycles, since it's almost always gonna be overwritten from
the JS.


Status: NEW → ASSIGNED
[s]r=hewitt for the xul/xbl/js parts
I've attached a png of the default-sized compose window with the record source
stuff turned on.  Note that both the record source and email address may be
elided in the dropdown (the right thing does get entered into the textbox, not
to worry.  Checking this in as is may be reasonable, given that there is a
hidden pref to turn it off, and most folks can just resize the window itself to
be larger, or resize the attachment pane to be smaller.

However, I'm now trying to figure out how to add the icons shown in jglick's
screenshots, both for this bug and for the error-reporting bug (bug 79935). 
Adding the icons on the left side is going to exacerbate this problem, at least
somewhat.  

Should I just leave things as they are now?  Should I make the record field be
off by default and the icons on by default?  Something else?

Opinions solicited, most especially from UI folks (hi jglick & mpt :-).
I'm thinking that our more consumer-oriented users will appreciate the icons
more than the comments, but in a workgroup setting, both, or just the comments
would be the most useful. It looks like the default window size is too small to
accomodate both, so at this point, I'd prefer we use just the icons. But, if
someone has a good argument as to why just the icons might appear too cryptic,
I'm open to that.
OK, here's a new patch with a typo fixed.  

Not sure if it makes any difference, but one thing to keep in mind when
contemplating what do is that the the compose window size is persisted to disk,
so a user would only need to resize the window once.
Priority: -- → P2
Those who spent time implementing the multi-column display might disagree, but 
I think it's more cluttersome than useful. In Navigator we can get away with 
it, but there are three differences: (a) an URL is much less recognizable than 
a combination name and e-mail address; (b) people might be auto-completing 
based on a page title rather than an URL, so the title (unlike Organization or 
address book name) needs to be shown in the menu; and (c) a Navigator window is 
typically a lot wider than a message composition window is.

The icons are a good idea, though -- since the field itself has an icon, it 
makes sense for the auto-complete entries to have distinguishing icons too. 
(The same is true for the auto-complete menu in Navigator.)
OK, new patch.  Changed the preference stuff a bit.  Here's the scoop:

In modern, by default, this looks pretty much exactly like jglick's first
attachment.

There is a pref, mail.autoComplete.commentColumn.  For each value, here's what
shows up in the comment column:

0 = nothing (this is the default if the pref is not set)
1 = name of addressbook this card came from
2 = other per-addressbook format

For a value of 2 local addressbooks show nothing, while LDAP addressbooks use
the ".autoComplete.commentFormat" preference for the current directory, and that
gets default to "[o]" if unset.  In some ideal world, both addressbooks would
use some indirection to get the same fields and display them.  Maybe in a future
version.

I used existing icons for the modern skin, and because the classic skins didn't
have any comparable icons I copied them to classic as well.  To my eye, at
least, they look perfectly fine in classic.

I'll post screen shots in the morning.

Patch looks good, sr=hewitt with two nits:

1. See harmless typo in this line:
+        NS_WARNING("nsAbAutoCompleteSEssion::AddToResult():"

2. You don't need to add the new image files to the manifest or makefiles, just
the jar.mn
sr=sspitzer looks good.

dmose explained that there isn't a perf hit when using local addressbooks or
when the feature isn't turned on.  (it's off by default)
OK, this (hopefully final) patch does the right thing on default matches: it
doesn't add an icon to them at all, and instead just pads them with empty space.
 The only changes are the addition of about 5 lines of css to both modern and
classic messengercompose.css and a few lines of C++ code around the SetClassName
call in nsAbAutoCompleteSession.cpp.
sr=sspitzer

thanks for following jglick's suggestions and the spec.
Attachment #47709 - Attachment description: commentColumn=2; commentFormat="[ou]"; enlarged window; modern; → screenshot 4: commentColumn=2; commentFormat="[ou]"; enlarged window; modern;
Attachment #47754 - Flags: review+
adding Chris Wozniak for documenting new hidden pref
Sorry for the delay, i was out for a few days. Recent decisions/attachments look 
good. I agree that since we having limited space, showing the icons by default 
is good. They take up the least about of space and provide useful info at a 
glance (without having to read text).  The pref to let users change this is 
nice.

As for the classic icons, cc'ing marlon for his help getting a hold of these. 
Marlon, need the "Address Book" and "Directory" icons from classic. Joe, can you 
work with Marlon to get the classic icons in?
For the classic theme, I went and ripped off the directory server icon
(remove-abook.gif) and I'll attach it here.  Add it to
classic/messenger/addressbook instead of messengercompose.  For the
local-abook.gif, just use chrome://messenger/skin/addressbook/myaddrbk.gif

Other than that, sr=hewitt
Whiteboard: have r=, sr=; need a=
OS: Windows 2000 → All
Hardware: PC → All
Summary: RFE:Show source of suggested matches in addressing results list → Show source of suggested matches in addressing results list
From IRC: a=asa@mozilla.org
Whiteboard: have r=, sr=; need a= → have r=, sr=, a=
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Since about one or two weeks, when i installed some mozilla build, all my
address book was erased. I have the option that auto collects mail addresses,
but it does not work. Has something changed in the way mozilla collects email
addresses? Do i need to create a new profile?
I sent an email to myself, from Francisco J. León <fjleon@iamnet.com> to see if
it would collect and add it to the address book but it did not
BTW, i have 2001090608, and this bug has been "fixed". I added a test entry to
the address book for the test (i can make them manually, just mozilla does not
do it automatically)
Francisco: what you're seeing is not at all related to this bug; please file a
new bug.
I know that, i just wanted to know if you were having the same problem. I had
already filed bug 98708 about mozilla not auto adding mail addresses.
Branch build 2001-09-24-03: WinMe
Branch build 2001-09-24-04: Linux RH 7.1
Branch build 2001-09-24-05: Mac 9.1
It displays one set of icons for matches that are local and a different icon for
those using an ldap directory. If a scrollbar is required then the scrollbar
does appear. I can move the scrollbar by using the up/down arrows or clicking
above/below the scroll widget. 

There is a problem dragging the scrollbar thumb which is logged in bug# 101453.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: