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?

Alexis is doing the UI stuff for this bug.

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.

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.

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

*** 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.).

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

*** 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

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

Moving to 0.9.5 per PDT

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.

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.

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

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?

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

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

0.9.5 is out the door. bumping up the TM one notch

*** 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.

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.

taking. now that the ab outliner has landed I'm going to bring AB quick search and AB advanced search back from the dead.

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

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.

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.

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.

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.

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.

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

fixed. the final patch has r/sr=bienvenu. I'll go log the spin off bugs, and mark them as dependent on this one.

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.

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