Closed Bug 83023 Opened 23 years ago Closed 23 years ago

implement advanced AB / LDAP search UI

Categories

(SeaMonkey :: MailNews: Address Book & Contacts, defect)

Product:
SeaMonkey
Component:
MailNews: Address Book & Contacts
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.9

People

(Reporter: martin.maher, Assigned: sspitzer)

References

(
URL
)

Details

(Whiteboard: nab-search)

Attachments

(21 files, 12 obsolete files)

UI proposal
39.96 KB, image/gif
Details
gif image referenced by Calum Benson in Comments on 18th July
97.33 KB, image/gif
Details
index.html referenced by Calum Benson in Comments 18th July
4.49 KB, text/html
Details
gif image referenced by last html attachment ..
91.18 KB, image/gif
Details
Latest ScreenShots - in gzipped tarball format
382.44 KB, application/octet-stream
Details
Updated against todays [04-09-01] head and jglicks minor changes added
84.93 KB, patch
Details | Diff | Splinter Review
updated patch
90.61 KB, patch
Details | Diff | Splinter Review
updated patch, code clean up, performance improvements.
91.60 KB, patch
Details | Diff | Splinter Review
updated patch
100.57 KB, patch
Details | Diff | Splinter Review
Up-to-date patch against the head plus support for sidebar + xul 1.0
98.47 KB, patch
Details | Diff | Splinter Review
Latest patch with review issues + up-to-date against head
110.05 KB, patch
Details | Diff | Splinter Review
Keep patch up-to-date against the head + fix LDAP default order
110.97 KB, patch
Details | Diff | Splinter Review
Keep patch up-to-date against head
111.11 KB, patch
Details | Diff | Splinter Review
updated patch, not complete yet.
114.47 KB, patch
Details | Diff | Splinter Review
screen shot of ab, quick search on local addressbooks, added "Search" ,menu
60.97 KB, image/jpeg
Details
address book advance search, compare it to mail search.
50.62 KB, image/jpeg
Details
updated patch, more clean up of ab code, css rules
140.10 KB, patch
Details | Diff | Splinter Review
updated patch, more code clean up, removing dead files
248.89 KB, patch
Details | Diff | Splinter Review
Async Stop/Search for LDAP and Outlook
24.04 KB, patch
Details | Diff | Splinter Review
updated screen shot
13.62 KB, image/gif
Details
final patch
45.13 KB, patch
Details | Diff | Splinter Review 
Although the new datasource interfaces created in mozilla can be searched there
is no UI to support this.
The URL field now points to a page with screenshots of the proposed new UI. 
Comments?
URL: http://abzilla.mozdev.org/ → http://abzilla.mozdev.org/screenshots...
Alexis is doing the UI stuff for this bug.
Assignee: dmose → alexis.ledoux
We should have a specification in the style of the previous mail news UI
specifications, e.g:
	http://www.mozilla.org/mailnews/specs/addressbook/

hopefully by Tuesday.

    
    

    
  
http://abzilla.mozdev.org/AB_advance_search3.jpg
title: Search Messages <-fix me

    
    

    
  
Brief comments on the screenshots:
(1) Building the simple search UI into the main address book window is great --
    saves having to reimplement UI for features like copy, delete, etc (like we
    currently do in Search Messages).
(2) The `Show names containing:' field needs a `Search' button. A frightening
    number of people don't know how to use the Enter key to activate a form.
(3) The `Add to:' popup menu would also need an `Add' button, but I suspect
    that the popup menu shouldn't exist at all. Why can't I just drag the items
    to my address book (or choose the relevant menu items) in order to add
    them?
(4) `Advanced Search' should be `Advanced ...'. We already know it's a search
    (because it's next to the `Search' button you added for (2)), and it needs
    an ellipsis because it requires more information from the user.
(5) Please use the same UI layout for advanced search as is used for searching
    messages and editing mail filters. Use the same overlays, if possible.
    Consistency is good.
(6) If you ever put a `Close' button in a dialog, you can be pretty sure that
    you're doing something wrong. In this case, each set of search results
    should be in a separate window (separate from the search window and from
    other results windows). This lets you:
    *    have the results of more than one search visible at once;
    *    leave a results window hanging around for use after you've closed the
         search window;
    *    (eventually) drag the proxy icon from the results window title bar, to
         save your search query on disk.

    
    

    
  


  

    
    

    
  
Matthew, A lot of your comments were based on the old screenshots. The screen
shots have been updated, new experimental builds have been up on abzilla
(http:/abzilla.mozdev.org) and the patch has been updated (see attachements).
Can you have a look at this stuff and give us some more feedback. I think this
build should resolve a lot of your issues.

    
  
Depends on: 78933

    
  
Target Milestone: --- → mozilla0.9.3

    
  
Keywords: nsbeta1

    
    

    
  
Cool. This is starting to look quite powerful. From looking at the new 
screenshots, it appears that all my previous points still apply, with the 
possible exception of (3) (though it's a bit hard to tell, since
<http://abzilla.mozdev.org/ABSSinglesearch.jpg> refuses to load).

With regard to (2) in particular: a Raskin-style search-as-you-type UI makes 
sense if you can reliably perform the search `immediately' (within, say, about 
half a second); but I doubt that's the case for LDAP, or even for a large 
personal address book on a slow disk. A pref to determine the delay would not 
make this less annoying, even if users were savvy enough to be able to twiddle 
the pref themselves. So you really do need a `Search' button instead.

(9)  `Search directory:' should probably be `Look in:', since you're not
     necessarily searching a directory.
(10) Please don't call the search dialog `AddressBook Search Dialog'.
     `AddressBook' isn't a word; and as for `Dialog', it's up to the window
     manager -- not the window title -- to let the user know wordlessly what
     type a particular window is. Try `Advanced Address Search'.
(11) Instead of buttons for `Add Boolean' and `Add Expression', which few
     people are likely to understand, just have an `Add Row' button, and then
     add the following three items to the bottom of each attribute popup menu:
         ---------------------  [separator]
         all of the following:
         any of the following:
     Choosing `all of the following:' or `any of the following:' turns the
     current row into a new boolean.
(12) I think making the popup menus and text fields look like labels when a row
     is not being edited is more confusing than useful, as well as making the
     row `wobble' when you move in and out of it, and slowing the user down
     when editing multiple rows. Just leave the controls visible all the time.
(13) Wording niggles:
     *   `equal:' --> `is'
     *   `not equal to:' --> `is not'
     *   `less than' --> `is less than' (disable this option for text types?)
     *   `greater than' --> `is greater than' (ditto)
     *   remove the colons from all the other options in the conditions menu
     *   change the names of the attributes so that they're English, e.g.
         `first name' instead of `FirstName', `Secondary Web Address' instead
         of `WebPage2'.

    
    

    
  
Excuse me if I'm misinterpreting this, but it seems as if the simple search
results in the addressbook only showing entries including the search criteria. 
The problem with this is, how does the user get back to seeing the entire
addressbook?  

Perhaps it would be better to do the simple search like NS4.x: Just match up the
first letters of the name.  I know for myself that this is all I need most times
anyway.  I also know that this was pretty much a mis-implemented feature, seeing
as how the text says "show names containing" but that's not what it does.
Thoughts?

    
    

    
  
Ben, the user can get back to viewing the entire addressbook by removing the
query. Essentially no query translates to show me everything.

In the case of this search query 'Show name containing' is exactly what it does.
For example typing 'rek' will bring up any entries containing Derek. I think I
understand your point here in that if you type for example 'm' in the query box
you would like to get all names starting with m rather than all entries
containing the letter m. I think the current behaviour works well though I'd
like to hear opinions from anybody else that thinks NS4.X behaviour would be
preferable. Matthew?

If you would like to discuss this in more detail I'll be on irc at
irc.mozilla.org at addressbook all day today...

    
    

    
  
Matthew: an in-place search should be begun after a 'suitable' delay in typing
(in terms of milliseconds) and should be suspended when typing continues.  Most
indexing formats would allow us to simply narrow the results further rather than
causing a new search if the user continued typing.  In the case of an LDAP
directory, an exception might be made to simply make that initial 'suitable'
delay longer since opening and then prematurely closing multiple LDAP queries
might be considered poor behaviour.

At any rate, an easy-to-use Ctrl-F 'find anywhere in address book' function is
needed sooner than later for large address books to be useful.  I can't
currently (to my knowledge) easily list all the people in a certain domain, for
example.

    
    

    
  
Instead of adding a whole additional toolbar, is it possible to incorporate the 
search field into the existing toolbar?  As shown in:
http://www.mozilla.org/mailnews/specs/addressbook/images/ABdes1.gif

I think its confusing the user can choose one item for "Search directory" and 
have a completely different item selected in the Address Book list pane. Would 
be good if there was only One place to select the AB/Directory to be searched.

    
    

    
  
OK, incorporating into the Toolbar probably isn't possible because of space 
issues.  But instead of using a dropdown menu in the additional toolbar to 
select an AB/Directory to search, why not using the existing list of 
AB/Directories in the left pane.  See screenshot below.

    
    

    
  

      
      
      
      

        Attached image
          
        UI proposal
        — 
      

    


  

    
    

    
  
And in the "View" menu, "Search Toolbar", so users can close it if they want.

    
    

    
  
Okay, I've been thinking a bit about the address book GUI, so here are
some comments.

First, the automatic search-as-you-type feature.

I'm undecided about what the best solution is here, but I do think the
default behaviour should be that no searching happens until you type
something and press a Search button (or Enter).  

As a couple of people said, the lack of guaranteed instant feedback with
the automatic search is a problem, and would be a lot worse on slow
connections/large address books.  Also, it's possible that whatever I'm
typing into the search box might be something I'm trying to visually
copy from the list of existing results, so I wouldn't want that existing
list to disappear halfway through my typing when I was still trying to
refer to it.  

Mechanisms that rely on arbitrary delays are generally bad for
accessibility reasons, too-- in this case a slow typist could be slowed
down even more by a search kicking off after every letter they typed. 
(There are possibly other accessibility implications too, I just can't
think of any right now...)

I don't have a huge problem with making the automatic search behaviour
an option, if people are particularly attached to it.  Although I have
to say I don't generally like adding more options than you really need
to make something work, and it would work perfectly well without it  :o)

If you *do* make it an option, though, it may also be worth adding an
option to specify how many characters you have to type before the
automatic searching starts-- as someone pointed out, it's a little silly
searching after the first letter, and it's more likely you'd want to
wait until you'd typed two or three.  (And if you wanted to force a
search before you reached this many, you could always press the Search
button/Return).  Or perhaps you could just hardcode a limit of one or
two characters.

Does the quick search only search on the name fields?  It might be good
if it actually searched on all fields, or perhaps just the ones you
currently had visible in your search results pane.  Just a thought.

Automatic search or not, there ought to be some feedback in the results
pane that the search is happening (busy cursor in that pane, at least),
and the Search button ought to change to a Stop button while the search
is happening, so you can interrupt it if it's taking a long time.  

Results also ought to be displayed as they are found, if that's
possible, rather than all together at the end-- I don't know if that's
how it works just now or not, as the demo you showed me found things
rather too quickly :o)  This does mean the user has to manually sort the
results themselves every time, though, which is a little annoying--
perhaps you could be clever enough to sort the results for them (using
whatever column they last selected to sort by) as soon as the search is
complete.  But it does mean they don't have to wait for a while over a
slow connection if the record they want happens to be the first one that
was found.

I've also mocked up a quick screenshot that shows how you could tidy up
the toolbar a bit:

http://gnome.ireland/Ready2Gnome/AccessUse/Prototypes/abzilla/ABSSinglesearch1.g
if

Changes I made here were:

- Line up "Search Directory" dropdown and "Show names containing"
textfield
- Shortened textfield quite a bit, and moved the Advanced and Search
buttons to the same row
- Added a bit of blank space along the bottom of the toolbar

I don't know how much of this XUL will actually let you do, of course...

Okay, now for the advanced search dialog.

Suggestion #1: Bin it, and just do the same as the Search News/Mail
dialog!  I don't believe for a second that anybody is going to want to
use something this complicated to search their address books; boolean
queries and average users just don't mix.

Suggestion #2: If there really _is_ a definite requirement for complex
queries, here's an alternative design that should be rather simpler to
use, and has more in common with the Search Mail/News dialog:

http://gnome.ireland/Ready2Gnome/AccessUse/Prototypes/abzilla/index.html

It's not a tried and tested design by any means, it's just something
I've come up with over the past couple of days.  You can only do nested
queries by simplifying out the boolean expression into a non-nested
query, but my guess is that would be more than powerful enough for most
people.  Plus it should look a bit nicer and work a bit faster than your
current proposal :o)

Cheeri,
Calum.

-- 
CALUM BENSON, Usability Engineer       Sun Microsystems Ireland
mailto:calum.benson@ireland.sun.com    Desktop Engineering Group
http://www.sun.ie                      +353 1 819 9771


    
    

    
  
The problem with the simple UI for searching the addressbook as referenced by
Calum Benson, attachment (id=42716), is that it takes away all names that to not
match the search criteria. The reason persons like myself got attached to the
netscape addressbook search feature is because when a letter was entered into
the search box it automatically jumped to the first name with that letter. 

Netscape/Mozilla 4.x implemented simple searches very well and perhaps the same
should be done for this and future releases of Mozilla. If you are planning an
advance search mechanism then the sky is the limit. However a simple search
should not rule out that a user may also wish to be able to scroll the list
either after or before the names that match the criteria.

    
    

    
  
I agree with the comments from cnar77@yahoo.com above. 

    
    

    
  
I agree as well. So, we need specific feedback from the sun ireland team on the
proposed implementation on 7/13
(http://bugzilla.mozilla.org/showattachment.cgi?attach_id=42216). A simple
approach to this is critical, then we should probably examine the more advanced
queries in a part of the UI relevant to those customers.

    
    

    
  
I agree with Corey's point about the advantages of the 4.x implementation... the
disadvantage is that you can only match names starting with whatever you type,
rather than names that contain whatever you type (or, for that matter, other
address book fields containing whatever you type).  If the 4.x way matches
Mozilla's user requirements then I agree there's no particular reason to change
it... but being a far from regular contributor to the project, I'm not terribly
familiar with what has gone before, or what the rationale was for changing the
way it works now.  That's my excuse, anyway  :)

    
    

    
  
Simple searches should remain simple and I do believe it works best the way the
4.x versions did it. If a user wants to search for something that is contained
in the user name or email address that should be part of an advanced search
interface.

However there is another possibilty;

Having a drop down menu with the options, "begins with" and "contains" and then
the search field where you enter your text. This might be a quick shortcut and
my suffice for even more advanced searches. To add more functionality (if anyone
out there desires) another drop down box with the options "name" "alias" "email"
etc can be added.

So for example I would be able to:

1 - select "contains" from first box

2 - select "email" from 2nd box

3 - enter the keyword/letters etc i'm searching for for example, "yahoo.com"

As a result - I can display all email addresses and only those addresses that
carry the domain or contain yahoo.com.

This may be implemented on 1 line/row, giving both simple (default) searches of
names beginning with any character entered and subsequently more advanced
searches more advanced searches. This method seems quick simple and effective.
However the designers and coders have their work cut out for them however they
decide to do it.

Just a suggestion btw.

    
    

    
  
The following is an attempt to summarize and get a close of the
proposal and outstanding issues to-date on this. There are three 
areas that need to be agreed. We propose to do the following and
will have the patch updated plus the abzilla.mozdev.org site for
this week.I would hope that this would allow us to move on this and
people who feel strongly opposed can raise bugs against individual
areas.


a. Simple Searching
--------------------

We have two types of 'Simple Searching...' 

1. Personal Address Books i.e. where we are reading all the content.
In this case, the simple search highlights the card in question 
according to the column selected.

and

2. LDAP Address Books where we are performing searches/queries on
the content to get a subset of it.
Here the results of the query is returned i.e. it does not highlight but 
limits the data returned according to the query.

In both those cases we will copy 4.x behaviour. 


Search Toolbar 
--------------

We recognise the need for a button to perform type 2 above of 'Simple Searching' 
which will initiate a query. This button is either called 'Search' or 'Go' 
according to the proposals of 'Calum Benson' and 'Jennifer Glick' respectively. 
When a 'search' is performed the button toggles to a 'Stop' which when pressed 
will stop the search. This is only relevant for asynchronous searches such as 
LDAP. We will use the 'Search' name on the button.

As in the existing 4.x behavour queries may be initiated via a time delay
after a user has typed in the simple search information. The search
button will toggle accordingly.

The Advanced Search button will present a new window with the ability to perform 
Advanced Type 2 Searching  on all types of Address Books. 


Advanced Search Window
---------------------

This will give us the ability to using a 'Simple Search' or an 'Advanced Search' 
[AS]. The AS will be defined in the same manner as 4.x. But results are returned
in this window.




    
    

    
  
for your search results, are you using a tree or an outliner?

for performance reasons, all multiple column trees are being switched over to
outliner.

see 
http://bugzilla.mozilla.org/show_bug.cgi?id=73948
for the addressbook bug, see:
http://bugzilla.mozilla.org/show_bug.cgi?id=73868
any reason why aren't you integrating with the existing mailnews search dialog?  

it's the same UI, and it should be flexible enough to be extended for LDAP searches.

    
    

    
  
Hi Seth,

I am responsible of the addressbook search UI. To display the results in the
advanced search dialog box we are using the overlay already developed in Mozilla
<tree id="resultsTree">. So if somebody is switching from the tree to the
outliner to display the cards then the outliner will be displayed in the
advanced search dialog box as well.
For the addressbook search dialog we are just converting the AB search dialog
from netscape 4.x into XUL. Some new screenshots will be available soon.

    
    

    
  
> I am responsible of the addressbook search UI. To display the results in the
> advanced search dialog box we are using the overlay already developed 
> in Mozilla
> <tree id="resultsTree">. So if somebody is switching from the tree to the
> outliner to display the cards then the outliner will be displayed in the
> advanced search dialog box as well.

right, you are doing the right thing.  When that overlay gets converted to use
the RDF outliner bridge, you'll just get it for free.

> For the addressbook search dialog we are just converting the AB search dialog
> from netscape 4.x into XUL. Some new screenshots will be available soon.

That work has already been done.  (Coverting the 4.x search dialog into xul.)
In the mail 3 pane, "Search | Search Messages..."



    
    

    
  
Just attached the latest patch. This must be applied against patch #78933. To
activate both MS Outlook and Outlook Express you will also need to apply patch
#83103. All patches are up-to-date against the head. I will attach the latest
screenshots shortly plus I will update a number of experimental builds plus the
screenshots on our development site at http://abzilla.mozdev.org. We feel that
this patch is now ready for review.





    
    

    
  
We have made available the latest experimental builds incorporating this patch
at our development web-site at http://abzilla.mozdev.org

    
  
Target Milestone: mozilla0.9.3 → mozilla0.9.4

    
    

    
  
*** Bug 91624 has been marked as a duplicate of this bug. ***

    
    

    
  
Looking at your screen shots at:  http://abzilla.mozdev.org/screenshots.html
Some comments:

I don't think the "Look in:" dropdown widget is necessary. The Address Book or 
Directory which is selected in the left pane should be what is "Looked in".  It 
takes up less room this way. The position of the search bar shown in the image 
linked below makes this relationship more clear.

http://www.mozilla.org/mailnews/specs/addressbook/#Advanced

"Advanced" instead of "Advanced Search".

"Automatic Search" checkbox.  I don't think this belong here and will just 
confuse users. We should pick what we think is the right behavior, (1) search 
results appear as the user types, (2) user must click a "Go" or "Search" button 
to start search. 

The "Advanced Directory Search" dialog should look very similar to the Mail 
search dialog for consistency.
http://www.mozilla.org/mailnews/specs/addressbook/images/AdvSearch1.gif

Personally, I don't see the benefit of the Basic Search vs the Advanced Search.  
Basic search is using the text field in the Address Book to search.  Clicking 
the "Advanced" button should open a dialog which allows the user to perform a 
more Advanced refined search.

    
    

    
  
I'd agree with Jennifer on both making the address search UI look like the Mail
search UI and not splitting the Advanced search into Basic / Detailed. If a user
wants an advanced search, let's give them the full, "detailed" UI, maybe with
just pre-populating the Name / Organization / ... fields. This could possibly
require adding an "is anything" selection to the match criteria list, to
distinguish btw. "?" and "".

John, how much work would adhering to Jennifer's spec be for you? If it's
non-trivial, we should probably get the UI checked in ASAP as-is to get wider QA
coverage on the feature, then refine the UI very soon after the initial checkin.

    
    

    
  
Yes, Jennifer's comments are very positive and we agree with many of them. Many
of our features were based on keeping 4.x functionality. So, we agree that we
should remove the 'Look in'. We will use 'Advanced' rather than 'Advanced
Search'. We will drop the 'Basic Search' and we will modify our Advanced Search
to look like the screen you suggested. This will result in using Checkboxes to
enable the AND or OR functionality. We will use the AND/OR text also. The
'Reset' will be changed to 'Clear'.

This brings us to the issue of the 'automatic search' and the Search/Go To
button.
 
It is important to see the difference in behaviour between LDAP and
the existing Personal Address Book. In the latter you 'Go to' to an
already existing entry, whilst in LDAP you are entering a 'Search'
criteria. Remember in an enterprise LDAP Server you can be searching 
a database of many thousands of entries. Will every keystroke kick off 
another search? 
 
The other issue as regards the 'Search' is that we want to extend
this to toggle to 'Stop' when pressed to allow users to stop 
running a query. This 'Search/Stop' button could show movement 
when an LDAP search is in progress. This will also allow us to
report Search status e.g Search completed, Search Maximum 
result set returned etc.

If forced to choose one or the other our instinct would be that the 
'right' behaviour would be the 'automatic search'. This would be a 
'go to' on the Personal Address Books but we would need to use a time
delay on the LDAP to allow users time to enter their search criteria.

Again, we would encourage people to download the experimental builds or
apply the patch to see the actual user experience.

In the meantime, we will update the patch with the changes above.

    
    

    
  
Wanted to let you know the "Search in Main Mail window" spec has been updated.
http://www.mozilla.org/mailnews/specs/qksearch/

It will work sorta like a filter, as the user types in the field (given a 
certain time delay), only headers matching the criteria are displayed in the 
Thread Pane.

    
    

    
  
John Marmion wrote:

> It is important to see the difference in behaviour between LDAP and
> the existing Personal Address Book. In the latter you 'Go to' to an
> already existing entry, whilst in LDAP you are entering a 'Search'
> criteria. Remember in an enterprise LDAP Server you can be searching
> a database of many thousands of entries. Will every keystroke kick off
> another search?

Kicking off a new search each time and aborting the previous one isn't entirely
unreasonable; this is the way autocomplete works.  We also don't search on
strings that are super short, so that directory servers generally only need to
perform indexed searches.  However, autocomplete also limits the total entries
returned to a fairly small number (default 100); addressbook probably doesn't
have that luxury.

The long-term answer, though, is that at some point in the future, we should
make the LDAP XPCOM SDK and the addressbook code use LDAP Virtual List Views;
which are designed to support exactly this kind of UI by supporting narrowing
searches.
  



    
    

    
  
>It is important to see the difference in behaviour between LDAP and
>the existing Personal Address Book. In the latter you 'Go to' to an
>already existing entry, whilst in LDAP you are entering a 'Search'
>criteria. Remember in an enterprise LDAP Server you can be searching 
>a database of many thousands of entries. Will every keystroke kick off 
>another search? 

Some ideas.

What about if an Address Book is selected, the search is automatic. No "Go to" 
button and no "Automatic" check box.  Typing in the text field either jumps to 
the closes match or filters contents being displayed so only those matching the 
criteria are displayed.

But, if the user selects an LDAP directory in the left pane, a "Search" button 
appears (but no "Automatic" check box). This gives the user a visual indication 
that this search is different. User has to click "Search" to start the query. 
Button toggles to "Stop" while search is in progress.  Status of search is 
displayed in status bar.

Or, LDAP search could be automatic like an Address Book.  No "Search" button or 
"Automatic" checkbox.  As mentioned, would need to have a decent time delay 
after user stopped typing to begin search.  Add a "Stop" button to the Address 
Book toolbar (like 4.x).  Stop button is enabled while a search is in progress 
and can be used to stop search in progress (behavior parallels browser and 
mail). Throbber icon is active while a search is in progress.  Status of search 
displayed in status bar. When search is complete, status bar should indicate 
this. If no matches found, status bar should indicate this.
 

Preference setting. For searching in Main Mail window, we will have a preference 
that lets users choose whether the search will be "Subject or Sender contains:" 
(the default), "Subject contains:", or "Sender contains:".  We will probably 
need to create a preference panel within Mail Prefs for this.  If you wanted 
"Automatic Search" to be the default for LDAP but allow users to change this 
(don't start search until I click button), this pref could be grouped along with 
the Mail pref mentioned above.

    
    

    
  
Regarding automatic searching and LDAP, I think you should have a setting of the
minimum number of characters to input before kicking off an automatic search.
This setting should be in the LDAP server configuration dialog (where you set
the address, port, etc.): Each server has different but somewhat permanent
characteristics. A company or department internal server can be fast and can be
searched incrementally (fast server/limited amount of persons in the directory),
but a nation-wide server with millions of people should be queried only with
long substrings or complete names.

I don't believe that even per-server timers (alone) work reliably, due to
differing typing and computer speeds, or typing situations (you may be typing
with one finger while on the phone etc.).
Depends on: 17879

    
    

    
  
risto: agreed.  right now, there is already an LDAP autocomplete preference for
the minimum string length to search against; perhaps this should be promoted to
a general preference associated with the directory server itself, perhaps
.typedownMinSearchLength

    
  
Blocks: 83091

    
    

    
  
*** Bug 94418 has been marked as a duplicate of this bug. ***

    
    

    
  
The new screenshots incorporating the issues discussed are now available at:
http://abzilla.mozdev.org/screenshot2.html

These screen shots show the requested changes against the screen shots on
08/02/01. I hope to make available a patch today and will update the
experimental builds at the above development web site. 

The patch contains changes to the screens. It does not contain the new
functionality discussed like the LDAP Search/Stop toggle button. 

    
    

    
  
Screen shots look nice. :-)

Some minor wording nits:

Address Book
1. "Show names containing:" not "Show Names Containing" is correct 
capitalization.
2. "Show names beginning:" sounds a little odd. Robin, any suggestions? What it 
does it jump to the closes match. 4.x keeps the same wording regardless of local 
AB or directory ("Shown names containing").
3."Advanced..." not "Advanced Search".

Advanced Search Dialog, if you want to parallel Mail search and Filters:
1. "Search for names in:"
2. "Match all of the following" and "Match any of the following"


    
    

    
  
How about "Show names beginning with"

    
    

    
  
I have incorporated the name changes requested by Jen and Robin and posted a
new Windows experimental build on www.abzilla.org. I will update the screen
shots and continue to test against Linux and hopefully the Mac before attaching
the patch.

    
    

    
  
s/www.abzilla.org/abzilla.mozdev.org

:)

    
    

    
  
About searching the local address books: As I understand it, you are
highlighting the first entry matching the name.

Have you considered how this works, if the address book is sorted by some other
column than Name? I think it would be quite confusing, plus you would need some
way to search for additional matches, since they are not adjacent.

Since it's possible to sort by other columns, and even useful (e.g. sorting by
organization), I think this could be handled intuitively. One possibility is to
search by the sorted column. You would then need to update the label "Show names
beginning with" depending on the sort column.

If sort column affects local searches, the should happen for LDAP, too.


    
    

    
  
risto, this functionality is already present. Clicking on 'Organization' should 
change the Label to 'Show Organization beginning with:" and will then highlight
the first organization that matches the input string. The same is true for
'email' and 'work phone'. On LDAP address books while you can order using these
headings, you search on the front screen using only 'Show names containing:'.

The development web-site will be updated with the latest Windows and Linux
experimental builds today plus screenshots highlighting the issue above.
I am also going to attach the patch so that anyone who wants to build against
the head can. I need to continue to test this but I feel that it is important
for people to give feedback on what is there now. We can build on this by adding
further enhancements at a later date. But I believe our time should now be spent
getting the functionality that is there now working correctly.

    
    

    
  


  

    
    

    
  
Shouldn't you show in the screenshot 'Advanced search dialog box on Personal
Address Book Example 1':
'Search for cards in:' instead of 'Search for names in:'

Another thing, even if I know the project is now on its final stage.
Imvho, a simple search in the addressbooks would be:
Display Name or Nickname or E-mail or Additionnal E-mail begins with the string
I am typing. (This is more or less the Pine behaviour)

btw, as far as I have understood, it is not possible to search all the personal
addressbooks at once. There is no root folder for them. Sorry if I have
misunderstood.



    
    

    
  
** sorry for the spam **
Additional comment on the simple search:
I think 'Show organization beginning with:' is misleading and I don't see the
benefit to have an order-specific label while the search is always operated on Name.
An end user will think that he can perfom searches on phone number or
organization and that is not the case as suggested by the screenshot.

If that is the screenshot that is misleading because the search on column is not
yet implemented, it's not still fine, imho.
An user could choose to sort by organization and want perform a search on the name.
Reciprocly, I think that few people will search for organization and phone
number (so: advanced search)


    
    

    
  
** sorry for the spam (bis) **
What about substituting the advanced search panel for the simple panel when
clicking on Advanced?

It could look like:
-+-----------------------------------------------------------------+
 |                   +---+ +---+ +----+                            |
 | Find cards for:   | |v| | |v| |_   |  (Search) (Clear) (Basic)  |
 |                   +---+ +---+ +----+                            |
 |                   More   Less                                   |
 | that match: o Allofthepreceding *Any [...]ing x includesubfolder|
 +--------------------------^-^------------------------------------+
 |                                                                 |
 : Card header panel                                               :
 |                                                                 |
 +-----------------------------------------------------------------+
 |                                                                 |
 : Card panel                                                      :
 |                                                                 |
-+-----------------------------------------------------------------+

Notes: see bug 63573 especially for the Clear button


    
  
QA Contact: fenella → nbaca

    
    

    
  
The latest patch is still correct against the head.

    
    

    
  
Screen shots from 8/23/01:

Very nice. :-)  
Minor comments:

"Advanced..." with the dots.  The three dots are used to indicate to users that 
additional information is needed from them to complete this request.

Advanced Search Dialog. Dropdown menu associated with "Search for names in:" 
label. Could this widget be smaller? Maybe 1/2 its current size. It looks a bit 
large taking up the full available space. 

    
    

    
  
Please, don't discourage external contributors! I know your time is precious,
however, sspitser, jglick, mpt, alexis, others, I would greatly appreciate a
feedback (negative/positive) on the proposal I have written in this bug 
(2001-08-26) and its corollary (bug 63573 and bug 97023)

According to me, getting rid of the pop-up widget simplifies *a lot* the
advanced search in addressbook:
- no widget that masks all the screen or half the screen
- uniformity of the Search in Addressbook feature. The advanced search is just a
simple search with the ability of modifying the fields. There is no need for a
ad-hoc pop-up widget that bahaves differently for displaying the cards.
- easy way to drag and drop cards from the card header pane (where the found
card headers are displayed) to the addressbook folder pane (see bug 66955)
- no duplication of the interface -> less bugs- instantaneous display of the
card (in the card panel) if there is one match. (thus no need to double-click on
the card in the popup widget, then waiting for the card window. At this point
three windows are opened -Main addressbook window, advanced search window and
card window- whereas only the main one would be necessary)
- no need of a Search names in... droplist because either:
  o Search (advanced and simple) is performed on the selected addressbook 
  o but this is confusing and imho, search should be performed in ALL the
addressbooks,unless a LDAP server is selected. Selecting the addressbook before
is a big waste of time, that implies that the user remembers where he/she has
classified the card and thus reduces a lot the interest of a search feature.

Notes:
- I guess the only implementation trick is to toggle the search pane
configuration between Simple and Advanced
- Putting the advanced droplist in the search pane when the user click on the
Advanced... button would only require to triple its vertical height. This space
could be stolen from the card header result pane, since the latter will contain
only the matches.
- The simple search pane is obtained clicking on Basic... button (it can be
called Simple...).
BTW: the latest screenshot (08/02/2001) for simple search is not consistent with
the spec for Mail/News http://www.mozilla.org/mailnews/specs/qksearch/
In the latter, the search panel has not a total width extension and is imho much
prettier.

    
    

    
  
-sspitser
+sspitzer


    
    

    
  
johnm is out this week (and next) but he asked be to update this patch against
the head and add jglick's minor changes from 2001-08-31. Candice can you start
your review now? Pierre I am not familiar enough with this patch to comment
intelligently on your suggestion. However this patch has been in developemnt
since May (4 months ago) so we need to get this putback. Possibly your
suggestion can be taken onboard after it goes back and futher patches submitted
after that?

regards,
Martin

    
  
Keywords: nsenterprise+

    
    

    
  
Moving to 0.9.5 per PDT
Target Milestone: mozilla0.9.4 → mozilla0.9.5

    
    

    
  
jumping in late, my apologies.

I'll try to do some reviewing today.

2 quick questions:  

1) is that last patch complete, are there addition new files that I need to 
review?
2) what is "putback"?

    
    

    
  
dmose tells me putback == land in the tree.

    
    

    
  
ah, and I see that the new files are in the patch.

do I need anything other changes to test this out, or will it work with the 
trunk?

I'll apply the patch and find some time to review tonight or tomorrow.

    
    

    
  
sspitzer: it should just work with the trunk; if you want to test against an
LDAP server, you'll need to hand-edit your prefs.js file as described on
http://abzilla.mozdev.org/


    
    

    
  
ok, sorry for the delay.  I've applied the patch and tried it out.  

It looks great, but I haven't to review the code yet.

I tried it on a local addressbooks, I haven't tried LDAP addressbooks.  Is any 
functionality or UI different if I use an LDAP addressbook?

here's some initial feedback:

1) "Show names beginning with:" is misleading since we currently jump to the 
first card that begins with that name.  Either we should only show results that 
match, or change the text to be something like "Find first entry that begins 
with .."
2) "Enter Text Here".  I don't think its a good idea to pre-fill the advanced 
search areas with that text.  why not leave them blank?

3) default should be "Any", not "All".

4) default picker, should be "contains" not "is".

5) when searching for matches on "Send Plain Text", the value is a text field.  
shouldn't it be some sort of menuitem since there are a finite number of 
possible values?

6) are there any other non-text field search types?

6) "Clear" doesn't clear text field in the first search term.

7) "Detail" is enabled when no results are selected

8) "Detail" should be "Edit Card..." since that is what clicking on it will 
show you: the edit card dialog.

9) multiple selection is enabled in search results, is that intentional?  if 
so, "Detail" doesn't work in that case.  If not, you can switch to single 
selection.

the next thing I'll do is start reviewing the patch.

    
    

    
  
> 8) "Detail" should be "Edit Card..." since that is what clicking on it will 
> show you: the edit card dialog.

"Edit" sounds scaring, if all the user wanted to do is *look* at the details of
the card. "Detail[s]" doesn't exclude edition.

    
    

    
  
It "Edit" what the user will be doing 99% of the time, since he can see the
"details" on the bottom half of the window? Also, that is the ONLY place the use
CAN edit the card, so renaming it may confuse users as to where they actually
can EDIT their cards.

    
  

        Attachment #36793 -
        Attachment is obsolete: true

    
  

        Attachment #37646 -
        Attachment is obsolete: true

    
  

        Attachment #44385 -
        Attachment is obsolete: true

    
  

        Attachment #44945 -
        Attachment is obsolete: true

    
  

        Attachment #46889 -
        Attachment is obsolete: true

    
    

    
  
continuing my feedback:

I see the author of the patch made it "Details" and not "Edit Card..."

when using against an LDAP addressbook, you can't edit the card.  (it brings up 
the same dialog that "Edit Card..." does, but everything is disabled.

In 6.x, we've got a toolbar button "Edit" and a file menu item "Edit | Card 
Properties...".  when selecting a ldap addressbook, the toolbar button label 
turns into "Detail".  I think that we should do what 4.x did, have the label 
be "Properties" at all times, and not change the label based on which type of 
addressbook we are selecting.

I also think that in the advanced search dialog we should label the 
button "Properties" (or "Properties..." or "Card Properties...") to be 
consistent.

comments?




    
    

    
  
change QA to Yulian said she would be testing this when it's implemented. 
Yulian if this isn't correct please let me know.
QA Contact: nbaca → yulian

    
    

    
  
stopping a search and progress during a search.

1) There needs to be a way to stop a search.  There is no way to stop a search 
when the user does a "Show names containing:" search or when the user does an 
advanced search.  In 4.x, we had a stop toolbar button in the addressbook 3 
pane, I think we need to bring that back.  

For advanced search, we might consider doing what we did for mail search:  turn 
the "Search" button into a "Stop" button while a search is in progress.

2) progress

for "Show names containing:" searches:
We need to hook up search progress to the throbber, add a progress meter to the 
bottom of the address book 3 pane, and update the status text.

for advance search, I think we're going to need to update the status text and 
add a progress meter to the advanced search dialog, similar to what we have for 
the mail search dialog.

    
    

    
  
note, I don't think all of the issues I've raised need to be addressed before 
we land this onto the trunk.  most of the issues I've raised can be spun off to 
seperate bugs after we've landed.


    
    

    
  
this bug is being worked on... changing state to ASSIGNED
Status: NEW → ASSIGNED

    
    

    
  
more feedback:

1) switching addressbooks should clear "Show names beginning with:" / "Show 
names containing:" text.

2) We're overloading the "Total Cards in XYZ: n" status text.  When viewing an 
LDAP address book, we are using that to be the number of result that match 
our "show names containing:" search.  for example, I select my UMich LDAP 
address book.  it says  "Total Cards in Umich: 0", which is misleading (I 
think) since there are not zero entries in that LDAP server.  when I type 
in "a" for the "show names containing" search, it counts up until I get 100 
results.  (my prefs are set to stop at 100, I think.)

for local address books, it shows the number of cards in the addressbook.

3) enter in advanced search text field should kick off a search (we currently 
do this in the mail search.)


    
    

    
  
here comes a follow up patch.  in the the follow up, I've made the following 
changes:

1) removed "Enter Text Here"
2) advanced search default to "any" instead of "all"
3) search terms in advanced search default to "contains" instead of "is"
4) "Properties" instead of "Edit" / "Details" in addressbook toolbar (tooltip 
does change between "Edit card properties" and "View card properties")
5) "Properties.." instead of "Details" button in advanced search dialog
6) removed comments like "Added for ABSearch"
7) remove booleanChanged() not needed was causing js error
8) fixed some js warnings


    
    

    
  
Seth wrote:
[Use "Properties" instead of "Details" or "Edit Card"]

> comments?

Fine with me - "Properties" and "Details" are synonyms in my mind.

    
    

    
  
when searching local addressbook for the first match, if switched it to do a 
binary search instead of a linear search. 

I've got to tweak it a bit more, so that it will select the first alphabetical 
match, not just the first match it finds.

I've also improved SelectFirstCard() [which affects the time it takes to switch 
addressbooks] which was O(n) and is now O(1)


    
    

    
  
I'll continue to fix some issues, and provide some new screen shots.

robinf found some additional issues, and I'll list them tomorrow.

    
    

    
  
Re: Seth's patch from --- 2001-09-11 00:41 ----

1) removed "Enter Text Here"
2) advanced search default to "any" instead of "all"
3) search terms in advanced search default to "contains" instead of "is"
4) "Properties" instead of "Edit" / "Details" in addressbook toolbar (tooltip 
does change between "Edit card properties" and "View card properties")
5) "Properties.." instead of "Details" button in advanced search dialog
6) removed comments like "Added for ABSearch"
7) remove booleanChanged() not needed was causing js error
8) fixed some js warnings

All look fine, except "Properties" without elipsis. No additional input from 
user is required in order to complete request of seeing the properties.


------- Additional Comments From Seth Spitzer 2001-09-07 19:39 -------

>1) "Show names beginning with:" is misleading since we currently jump to the 
>first card that begins with that name.  Either we should only show results that 
>match, or change the text to be something like "Find first entry that begins 
>with .."

4.x used "Show names containing:" for ABs and LDAP.  We could use that even 
though its not 100% accurate, or for ABs use: "Find:", "Show:" or "Look for".  
Robin, suggestions?

    
    

    
  
I had suggested to Seth "Find first entry containing:" for local ABs. If we
wanted to be context-sensitive for the column being searched, we could say "Find
first <Name, Email,Work Phone, etc.> containing:" For LDAP, "Show names
containing:" is fine.

    
    

    
  
new patch coming, with the following changes:

1) "Properties..." -> "Properties", per jglick's feedback
2) local addressbook search will select the first alphabetical match, not just 
the first match it finds.
3) added some missing uuids to the interfaces
4) removed some dead code used for printing addressbook cards

I'm still trying to get things into a state where I think we can land on the 
trunk.


    
    

    
  
So it looks like the Advanced search can be done using either an ldap directory 
OR a Local Address Book. This true? 4.x only did this for ldap. If so, what 
should the name of the window be? "Advanced Search"?  Does that distinguish it 
enough from a mail/news messages search?  Robin any thoughts?

    
    

    
  
Yes, that's my understanding as well. For the advanced search dialog title, how
about "Advanced Address Book Search"?

    
    

    
  
Is it ok to use "Address Book" to refer to both local ABs and LDAP directories?

    
    

    
  
Re:Comments From Seth Spitzer 2001-09-10 12:43 -------

>stopping a search and progress during a search.

I think Seth makes some good points here. I added his suggestions to an updated 
version of the Address Book spec. The updated version should appear shortly. The 
screen shots have also been updated.

http://www.mozilla.org/mailnews/specs/addressbook/#Advanced



Re:Comments From Seth Spitzer 2001-09-10 16:00 -------

>switching addressbooks should clear "Show names beginning with:" / "Show 
>names containing:" text.

Agree.

>We're overloading the "Total Cards in XYZ: n" status text.  

A Local AB should display: "Total Cards in <name>: X"
An LDAP Dir should wait until the results are displayed and show: "X matches 
found"

>enter in advanced search text field should kick off a search (we currently 
do this in the mail search.)

Agree

    
    

    
  
Re: Comments From jglick@netscape.com 2001-09-14 14:20 -------

I think it's ok in this case. Otherwise, we could use "Advanced Address Search".

    
    

    
  
where are we with this?  Jussi tracking.  Is there a chance this will make 0.9.4
branch?

    
  
Keywords: nsenterprise+

    
    

    
  
I noticed hong@netscape.com removed nsenterprise+ from this. Can you give a
motivation for removing it. I would have thought that this functionality is
exactly what 'enterprises' need. 

    
    

    
  
The nsenterprise+ keyword is being used as a tracking mechanism and doesn't
affect the disposition of the patch or its relevance.  This feature is in fact
crucial to enterprise deployments, but we aren't sure of the timeliness in which
the final pach can be delivered and tested -- hence removal of the keyword.

If you want to discuss it further, I'd be happy to do so over email.

    
    

    
  
grega:  this will not make it for the 0.9.4 branch.

    
    

    
  
*** Bug 66242 has been marked as a duplicate of this bug. ***

    
    

    
  
So, what's the status?  Can this be checked into the trunk?  Did everyone just
quit and go home? :)

    
    

    
  
We have not gone away. Just to fill you in on the current status. Seth had
started to review this patch but got called away to more urgent matters. He will
return to it. The 4 outstanding issues at that time were:

1. keep up-to-date against the head
2. support the sidebar
3. support for xul 1.0
4. add the ability to stop a search

I have just posted a new patch which takes care of the first 3 above. I hope to
post the 4th soon in time for Seth's return.

    
    

    
  
still working on the trunk, but here is some feedback on the current patch:

1)

simplify DisableValues(doc)

to all the elements in your xul that are disabled when the addressbook is
readonly, add something
like this:

 disableonreadonly="true"

then, fix  DisableValues() to do this:


var elements = document.getElementsByAttribute("disableonreadonly","true");
for (i=0;i< elements.length;i++)
{
  elements[i].setAttribute('readonly', 'true');
}

2) 

gOperation should be a long, not an object.

function getOperation(ref)
{
  var directory = CheckDB(ref);
  return directory.operations;
}

nsIAbDirectory is a scriptable interface and opRead, opWrite and opSearch are
already defined.

use it and the javascript bitwise operators to do what you want.

in your JS, do this:

var nsIAbDirectory = Components.interfaces.nsIAbDirectory;

then you can turn

if(gOperation.write == 1) {
}

into

if (gOperation & nsIAbDirectory.opWrite) {
}


    
    

    
  
getting closer to 0.9.5 - anything new to add today about this one?

    
    

    
  
Just attached the latest patch which hopefully addresses Seth's last two review
issues. You will make a XUL programmer out of me yet. This patch is also
up-to-date against the head. By my reckoning, the only outstanding issue remains
the "Stop/Search" button

    
  
Blocks: 104166

    
    

    
  
*** Bug 104215 has been marked as a duplicate of this bug. ***

    
    

    
  
0.9.5 is out the door. bumping up the TM one notch
Target Milestone: mozilla0.9.5 → mozilla0.9.6

    
    

    
  
*** Bug 93448 has been marked as a duplicate of this bug. ***

    
    

    
  
ok, I've got the latest patch up and running  (thanks for attaching one up to 
date on the trunk)

I'm going to do some clean up on it.

specifically, I'm going to make quick search work like quick search does in the 
thread pane.  

see http://bugzilla.mozilla.org/show_bug.cgi?id=103734 and 
http://www.mozilla.org/mailnews/specs/qksearch/

the mail 3 pane and the addressbook 3 pane should be the same interface, just 
different data.

see http://www.mozilla.org/unity-of-interface.html

ab quick search for ldap behaves like 3 pane quick search, but ab quick search 
for local addressbook behaves like 4.x (typedown).

I'll do some work to make the quick searches the same and post a new patch.

    
    

    
  
in addition to quick search looking similar between ab and mailnews, the search 
dialog should look similar.

I'm working on that in my tree as well.

I'll attach an update snap shot later today.

    
    

    
  
here's what that change contains:

1) advanced addressbook search looks like mail search (still more to do)
2) title added to advance search dialog
3) default border around search button.
4) for a local address book, quick search doesn't do typedown, we do quick 
search, like we do for ldap.
5) fixed some of the js warnings
6) added a "Search" menu to addressbook
7) cleanup

there's more to do, I'll continue to work on it.

    
    

    
  
notice, quick search is currently hard coded to "displayname contains <foo> || 
email contains <foo>".  

changing the sort order doesn't affect the quicksearch text (which is now "Name 
or Email Contains:") like it did with the original patch, which would do 
typedown based on the sorted column.


    
    

    
  
whoops, that screen shot has "Search" to the left of "View", I'll fix it to be 
on the right.

    
    

    
  
You could probably loose the entire "advanced search" screen by putting a
*dropdown menu* over "Name or email contains:" on the quick search screen.

The only thing we would loose is the ability to search for *multiple criteria*.
But with the primitiveness of the AB (doesn't even atocomplete TO: filed with
"additional" email address!!!), who *really* needs an advanced search anyhow?
Almost nobody.

In any event, the dropdown on the quicksearch might be a cool idea. IMHO.

+------------------------------------------------+
| Name or email    |v| contains:  [peter       ] |
+------------------------------------------------+
| Last name        |
| additional email |
| ZIP              |
| Country          |
| Organization     |
| etc.             |
+------------------+

    
    

    
  
Maybe the "contains" could be a dropdown to, with contains, equals, is not
equal, etc.

PS. my prevous post meant to say: "(doesn't even autocomplete TO:-field with
"additional" email address!!!)

BTW. Seth, very nice work. "Thanks!" from a user ;)

    
    

    
  
Seth you are a patchin' machine! :)

    
    

    
  
Excellent work Seth. I am still going through your changes plus the various code
cleanup to see exactly what you did. But it is looking good. 

I have just attached a patch to add the Stop Search facility for Asynchronous 
Searches i.e LDAP and Outlook. I am keen for you to have a look at this and get
some feedback. This I presume is the last bit of code for this patch. In the
meantime I will continue to test this. 

    
    

    
  
A couple of things I forgot to mention in my last posting .....

The last patch is an addition to Seth's main patch. This patch is concerned with
Stop/Search functionality only. This patch must be applied on top of the
previous patch. It also assumes that the stop*.gif files for the classic skin
are available at themes/classic/messenger/addressbook directory. 

    
    

    
  
I've handed off the compose performance work (#104989) to ducarroz, so I'm back 
on this bug full time.

today, I hope to land the changes in my local tree that were in my last patch, 
but aren't directly part of this feature.

then I'll apply john's latest patch, and continue working on ab quick search 
and ab advanced search.

    
    

    
  
did get a chance to land the changes yet (see #53111 for those changes).

I'll resume working on address book (this feature, and overall performance) next
week.

    
    

    
  
temporary change of plans.

performance and footprint are taking priority over feature work, for at least
the next two milestones.

see my post
news://news.mozilla.org:119/3BE09DDC.3060306@netscape.com
I'm going to be working on addressbook performance and footprint, specifically
switch us over from a RDF tree widget to an outliner for the ab results pane,
and switching to rdfliner for the address book pane.

I won't be able to work on this until at least 0.9.9 (0.9.7 and 0.9.8 are going
to be focused on performance and footprint).

but, mailnews really wants these features.  (see
http://www.mozilla.org/mailnews/current/index.html)

I will be returning to these features as soon as possible.

    
    

    
  
It looked like this might make it at one stage. Is there anything we can do on
our side to help get this in soon? I am also concerned that the Stop/Search
feature is based on notification to an RDF object. Will the changes you
mentioned invalidate that. If this can't be landed soon is there anything we can
do to keep this ready in case an opportunity does arise soon?

    
    

    
  
I hate to add useless banter, but it looked like this was almost done.  The
addressbook without a search bar is a very bad user experience, especially with
collected addressbooks that can get humongous.  The quicksearch bar was just
added, and it looks like labels are almost done.  Couldn't this be one final
exception?  It's just a shame to see all this progress go to waste for the
~three months until 0.99.

I would like to help with this if there is anything that can be done without c++
or intense js.

    
    

    
  
john, thanks for being patient as this bug is delayed.

>It looked like this might make it at one stage. 

We'll get these two features (ab quick search, ab advanced search) in.
These are key features for addressbook, and for mailnews as a product.

see http://www.mozilla.org/mailnews/current/index.html

>Is there anything we can do on our side to help get this in soon? I am also 
>concerned that the Stop/Search feature is based on notification to an RDF 
>object. Will the changes you mentioned invalidate that. If this can't be 
>landed soon is there anything we can do to keep this ready in case an 
>opportunity does arise soon?

you can follow the work going on in http://bugzilla.mozilla.org/show_bug.cgi?
id=73868

I'll provide a summary in that bug describing what the changes are, and some 
estimates on when the switch to outliner for the results pane will be complete.
No longer blocks: 73868

    
    

    
  
i disagree the strange plan, sure is performance and stability important, but
this is one function that the most company's see as a must have to use mozilla.
one milestone is a little bit short to see what problems this feature brings
with it's landing. 
i see no difference between a landing now or later 

    
    

    
  
I support poelzi's view on that performance and stability are important. But the
whole LDAP (are less specific - central address book) part is more than weak. 
See also (http://bugzilla.mozilla.org/show_bug.cgi?id=105103 and
http://bugzilla.mozilla.org/show_bug.cgi?id=108366 )
And that part is a killer criteria for every organization larger that 1 or maybe
two people wanting to use the mozilla mail client.


    
    

    
  
I just needed to add my 2cents and agree with the previous two comments.  I work
in a state gov and we have 10k+ users on enterprise mail, ldap,and 4.7 browsers
and email clients.  An upgrade path for enterprise environments has not
materialized while at the same time the mozilla browser has continued to
improve.  When the state finally upgrades (govs are slow -- good news for
netscape) if we move to explorer, it will be tough going back -- at least not
for another ten years :)  I see enterprise features in the mail client as the
most important feature in the current development stage and the "last great
hope" for keeping us out of the clutches of redmond.  Once you lose users like
that you have a very difficult time getting them back ...


    
    

    
  
I have to chime in here. I'm at another organisation stuck using Netscape 4.7x because there is not LDAP support in Mozilla. The users are getting sick of being behind in browser technology and I think the user interface is looking pretty well aged.



We only have around 3500 staff, plus around 5000 student machines, no LDAP soon will probably mean our email base will move to a MS solution and the labs will either get MSIE(more likely) or Opera and while I think highly of the mozilla project, once this occurs I think it will be 8500 machines that will never get to see the mozilla code installed. Pity.



Implementing LDAP Support later rather than sooner could come back to bite the project harder than is thought. I am also suprised that Netscape and Sun have not commited more people to getting LDAP support into this product. IPlanet, Sun and Netscape have all pushed LDAP so hard as the core technology behind a large number of their products and yet offer no client applications to access them. Maybe someone from the project could call Iplanet, Sun and Netscape and point out that even if you pay for and install they messaging solution to take full advantage of it and have the latest client application you need to use a MS product. Pointing out i would be in their interest to maybe throw a few people at the LDAP codebase to make sure it lands now...not later.

    
    

    
  
Much as I hate to say me too, if Mozilla is to be taken seriously by any
organisation larger than a couple of people it *must* have support for LDAP.
Even in a unit the size of ours (about 80 people) we can't do without it.
The entire product will become unusable without it.

This is not something you can loose now and gain the ground back later. People
are going to move to something else and staff will be retrained in the new
system. Once this is done few organisations will spend more money retraining
people on Mozilla afterwards.

    
    

    
  
There is a difference between doing this now and later.  It's extra work to land
this first and then rewrite the address book.

I don't disagree that this is important.  The goal is to land this before
Mozilla 1.0.  I would be surprised if companies choosing to use Mozilla would
want to standardize on a release that isn't considered finished by Mozilla so
it's not clear to me why this can't wait a couple of milestones.  Those same
companies that want to use the addressbook for anything useful will be
complaining about the addressbook's performance if this landed first.  The goal
is to do both in the order that makes sense to implement them.  The work in this
bug is considered high priority for the mail module so after the performance
work is over, we'll try to land it as soon as possible barring anything
unexepcted happening.

    
    

    
  
I don't think anyone can argue that it will cause more work. However, I think
you will be surprised at howmany companies will be willing to role out Mozilla
prior to 1.0, or even Netscape 6.3 should this LDAP address book land in that.

While I previously argued for my own benefit (I have been the only one stalling on a browser/mail client eval waiting for this to land). I 
would like to take this time to argue for the mozilla projects benefit,
which, to the mozilla project is obviously much more important. I would 
also like to argue for the UI development benefit.

For the Mozilla project this patch is likely holding back the roll out
of the mozilla code base (either as Mozilla of Netscape 6) in organizations
that use LDAP. Those organizations using Netscape 4.7x are probably
well aware of better browsers and possibly mail clients, but like us
are holding back for various reasons. For us it is mostly because we do
not want Outlook or Outlook Express rolled out. The Netscape 4.7x interface
has aged...running is now along side something like XP or even on W2K
makes it look worse.

For the UI development. Implementation now would mean a larger install base of this projects code base. along with that more users using the
application. This would offer a larger amount of feed back in to the user
interface, and maybe some fresh idea's on things that are missing. People
such as myself eventually here end-users comments on a product and can be
give this information back to the mozilla project, hopefully, the end result
is a more usable, friendly address book with all features needed. As a 
example, the current, address book cards are too inflexible. I am sure
as users start using the address book more and more feedback (in more detail)
could be offered.

I would also like to stress again that I can understand from a development view that landing this now is not the most ideal solution. However, this patch appeared to be near landing anyhow. For the most part performance wise, it only needs to perform similar to Netscape 4.7x better performance
would be better, but mozilla code base is probably going to make the most
ground replacing Netscape 4.7x

Cheers,

Stewart James


    
    

    
  
A couple of points here: 

* it's unclear whether some of the folks here are aware that basic LDAP support,
in the form of LDAP autocomplete for email compose, already exists in shipping
versions of both mozilla and netscape.

* bugzilla bugs are intended to be used for technical discussion related to
bugfixing, not for arguments about prioritizing work.  Please do not continue
that part of the discussion here (don't even reply to this comment).  There are
newsgroup/mailing-list pairs for such discussions; feel free to use them.  Thanks.

    
  
Target Milestone: mozilla0.9.6 → mozilla0.9.7

    
  
Whiteboard: nab-search

    
    

    
  
taking.  now that the ab outliner has landed I'm going to bring AB quick search
and AB advanced search back from the dead.
Assignee: alexis.ledoux → sspitzer
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9.7 → mozilla0.9.9

    
    

    
  


  
this patch is for the trunk, and it gives us the basics of quick search.

advanced search, async stop of LDAP searches, comes next.

    
    

    
  
Comment on attachment 62880 [details] [diff] [review]
patch for ab quick search only, ab advanced search is next.

sr=bienvenu

        Attachment #62880 -
        Flags: superreview+

    
    

    
  
Comment on attachment 62880 [details] [diff] [review]
patch for ab quick search only, ab advanced search is next.

this is in, so marking obsolete.  this bug will now track the ab advanced
search feature.

        Attachment #62880 -
        Attachment is obsolete: true

    
    

    
  
Well done Seth and all who contributed to this. This combined with bug 73868 is
an impressive piece of work.I have spent some time today working with today's
head. The quick search is working well. It is now possible to search LDAP
Address Books with this release.I need to spend some more time with it. We still
have to manually edit the prefs.js to enable the LDAP Address Book - see bug
83091. I recently added a patch for this in an attempt to get a some agreement
on a unified method of adding LDAP Address Books and LDAP Directory Servers for
Auto-Completion. That patch may is now out-of-date but the approach may be worth
 a consideration now that the Advanced Search feature is so close. 

    
    

    
  
Here are a few issues that I came across during the testing of this. I apologise
if these are already known issues:

1. see bug #118119 for comments on the quick search for Outlook in debug build.
2. When viewing the properies of an LDAP entry, the fields should be disabled
and the OK button also as LDAP is read only.
3. Another issue which may manifest itself in the Advanced Serach for LDAP is
where we need to map a Mozilla Address Book attribute to more than one possible
corresponding LDAP attribute. Our Hashtable in nsAbLDAPProperties.cpp will need
to return all possible LDAP attributes and not just one.


    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch to re-use existing search (obsolete)
        — 
          — Splinter Review
      

    


  
here's a complete proof of concept patch for the trunk for doing AB advanced
search with the *existing* search code.

there changes are minor.  ABSearchDialog.js and ABSearchDialog.xul are stolen
from SearchDialog.js and SearchDialog.xul.

I'll list the todo items next.

    
    

    
  

      
      
      
      

        Attached image
          
        screen shot (obsolete)
        — 
      

    


  

    
    

    
  
todo list:

most important item, figure out why this doesn't work:

+     // not working
+     // str += searchTerm.searchvalue.value;
+     str += "test";

2)  can we re-use SearchDialog.* instead of doing this big old copy and paste
3)  don't hard code to "or" search (support and)
4)  don't hard code to the pab
5)  get pre-flighting of directory to work
6)  status and progress. 
7)  get stop to work
8)  add more search attributes, fix attribute pretty names to match spec
9)  fix title "Search Dialog"
10) fix the hard coded strings.
11) get "properties" button to work.
Status: NEW → ASSIGNED

    
    

    
  

      
      
      
      

        Attached patch
          
          
        update, several issues fixed (obsolete)
        — 
          — Splinter Review
      

    


  
more issues fixed, pre-flighting work, LDAP vs Local AB differences when
showing search attributes, attributes match the spec, window title correct,
dialog text matches spec, properties button works, double clicking in results
pane works, status text shows up (10 Matches Found), added "Search Addresses"
to 3 pane.

        Attachment #69082 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached image
          
        updated screen shot
        — 
      

    


  

        Attachment #68677 -
        Attachment is obsolete: true

    
    

    
  
items that need to be fixed before I can get reviews and land:

    * initial operator not picked ("contains" should be picked)
    * build on mac and linux
    * default hidden column (old and new profiles)

items that can wait until after I land

    * results pane context menu (copy? delete?  print?  properties?)
    * get stop to work for ldap
    * "Search" button label -> "Stop" when search in progress 
      (important for LDAP)
    * better progress for LDAP (cylon of progress meter?, throbber?, 
    * generic attribute handling (_AimScreenName)

note, stop is a generic issue that needs to be solved for ab quick search and 
advanced search.  (but it looks like john has already investigated this.)

    
    

    
  
Woo hoo!  Seth Spitzer kicking ass here!  Keep up the good work.

    
    

    
  
Comment on attachment 69192 [details] [diff] [review]
fix the "too many columns" problem with new and existing profiles.  only show the default columns.

r=bienvenu

        Attachment #69192 -
        Flags: review+

    
    

    
  

      
      
      
      

        Attached patch
          
          
        final patch
        — 
          — Splinter Review
      

    


  

        Attachment #69192 -
        Attachment is obsolete: true
Keywords: 4xp, 
          
            nsbeta1+
Summary: UI needed to search addressbook datasources → implement advanced AB / LDAP search UI

    
    

    
  
fixed.  the final patch has r/sr=bienvenu.

I'll go log the spin off bugs, and mark them as dependent on this one.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED

    
    

    
  
Seth, I think you forgot to check in the mailnews/jar.mn changes. Advanced
search complains about missing ABSearchDialog.xul.

    
    

    
  
whoops.  thanks peter.  checked in.  it will be on in tomorrow's build.

    
    

    
  
*** Bug 118974 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 125793 has been marked as a duplicate of this bug. ***

    
    

    
  
Has this landed yet as I'm using build id 2002021503 and cannot see the new UI?

    
    

    
  
2002022503 builds on all platforms

Advanced AB search has been landed.
Status: RESOLVED → VERIFIED

    
    

    
  
*** Bug 86534 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: