Closed Bug 83100 Opened 24 years ago Closed 4 years ago

UI needed to enable use of Outlook/Outlook Express address books

Categories

(MailNews Core :: Address Book, enhancement)

x86
All
enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1697669

People

(Reporter: martin.maher, Unassigned)

References

Details

Attachments

(5 files)

We need to create two checkboxes to add Outlook and Outlook express mailboxes to the addressbook. (this of course can only be done once 78933, which adds MAPI support is completed)
Depends on: 78933
Alexis is making the UI changes for this bug
Assignee: dmose → alexis.ledoux
Keywords: nsbeta1
Target Milestone: --- → mozilla0.9.3
Doesn't look like this is getting fixed before the freeze tomorrow night. Pushing out a milestone. Please correct if I'm mistaken.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
is there a screen shot (or spec) that shows these changes for jglick to review? is this being done in a way (with overlays) so that this UI doesn't show up on builds (example UNIX) that don't have Outlook?
We hope to be in a position soon to show some screen shots and/or experimental builds. The problem is that since we are waiting for 78933 to get landed which is taken a lot of time, then work on this and others have ceased until we see if the #78933 gets landed successfully. This UI patch is a companion for #83103 and yes this would only get activated on the Windows platform.
Where exactly would these checkboxes be located? And how would this functionality work?
what about outlook variants on Macintosh? IE/Outlook is common there. there is also an outlook variant on Macintosh called Entourage.
We have got a patch ready for this bug. I enclose a screenshot about it. jglick@netscape, would you take a look at the screenshot? We had a number of options to implement this. We have addded a new External Address Books entry in the View menu. This will only appear on the Windows environment.
OK, so is this a feature that allows users to view an Outlook or Outlook Express Address Book from within the Netscape/Mozilla AB Without having to Import the AB? They only need to an Outlook or OE AB installed on their Windows machine and it can be viewed? This correct? If so, what do you think of moving this menu item into the View: Show/Hide --> flyout menu? It sorta goes with the items there. Show/Hide ---> Toolbar Status Bar Search Bar ----------- Card Pane Address Book Pane ------------ External Address Books --> -------------- My Sidebar Robin, "External Address Books" seem correct? Can the user add/modify/delete the entries in one of these ABs from our product?
I think "External Address Books" is OK, since I think users will understand from looking at the ABs listed under there what we mean by "external".
This is a reply to Outlook on the Mac: Although Outlook as a product is available on Mac, MAPI and WAB as a mean of programmatically accessing the messaging system are not. These requirements are consistent with the availability of the Outlook/Outlook Express import feature. In short this is not available to the MAC.
Entourage is AppleScript friendly, so is Outlook Express, I suspect other MS Mail applications for macos are too, but that's really a serperate bug. I'm marking this bug PC/Win98 because it's a windows only enhancement. The problem w/ this bug is it has generic spec work for a specific instance, if someone wants to split one of these issues into a new bug so that we can later track Eudora support and Balsa support and ... that'd be nice. Personally, i don't see a real need for this in the View menu. Why not put it in Preferences or whatever AddressBook uses for prefs? As a user, I will either want to see external address books, or I won't. It's not something i'll change frequently. Most likely, I'll change it exactly once. If i happen to uninstall the app, mozilla should notice the absense of the addressbook and continue gracefully, not even requiring me to tell it that the books no longer exist.
Depends on: 83103
OS: All → Windows 98
Hardware: All → PC
Yes Jen, it is correct. The users can view the Outlook and Outlok Express ABs from Mozilla. Furthermore, this is a dynamic access, so they can modify, add, delete entries in those ABs as well. We placed it here for four reasons: 1. View menu, because with this feature, we change the view of the AB UI left panel list of Address Books. 2. The choice of "External Address Books" also leaves the door open for us to extend this in the future, Evolution, Eudora etc.. 3. We did not put it next to the toolbar, statusbar, etc. because this change is about content and not the Window. The Show/Hide is about the Window only. 4. At the moment the Preferences do not contain any specific Address Book entries. Adding this to there would involve a lot more UI work. Our solution has merit in its functionality and simplicity.
Jennifer, please don't make serious suggestions involving nested submenus (e.g. `View' > `Show/Hide' > `External Address Books' > whatever). Nested submenus are extremely difficult to use; and as I'm sure you know, the UI guidelines for Windows (the platform this bug is for) explicitly discourage them. Timeless is correct -- since this function will probably be used an average of about 0.5 times in the life of a user profile, and that it never has to be accessed in a hurry, no way does it belong in the menus. I think the appropriate UI for this would be in the import utility for importing address books. Users switching to Mozilla from Outlook or Outlook Express (or using Mozilla at the same time as one of those two) are surely far more likely to expect Mozilla to be able to import an Outlook address book, than they are to expect it to be able to display a synchronized version of that address book. Having a checkbox for the extra option, | | [/] Synchronize address book changes between Outlook and Mozilla|, would be an added bonus. I'm sorry that this `would involve a lot more UI work' than just adding a menu item. But given that the back end for this feature no doubt involved considerable careful design, it would be a shame to see the front end tacked on as an afterthought in such a way that it would make Mozilla less usable overall.
Summary: Checkboxes needed to enable use of Outlook and Outlook express mailboxes. → UI needed to enable use of Outlook/Outlook Express address books
Any particular reason why this feature is Win32 only? After all, there's nothing stopping someone from accessing an address book file over a network, and thus it becomes essentially operating system independant. Particularly if the company web programmer using Mozilla on Linux needs to access the corporate Outlook-maintained address book regularly over the network. Not as inconceivable as one might expect, probably :-).
jg: please don't comment and run, if you're going to ask a question it's polite to CC yourself as you wait for an answer [i break this rule because most people know i'll get the bugmail anyways]. This specific feature Outlook(Express) addressbook support was implemented using windows MAPI, it is _not_ an implementation of the Outlook Addressbook file format or the Windows Address Book file format or any other file format, it's just a gateway. At some point, someone will file a bug about supporting the Mac Mail clients using AppleScript. There we go, Filed Bugzilla Bug 95648 Support Microsoft's Mail app Address Books using AppleScript. Support for outlook address books over a network isn't a high priority in my book, if you want it, file a bug. I'd be much more interested in Lotus Notes/Domino support than Exchange Server. -- Exchange server should probably support LDAP queries in which case there's nothing to do. come to think of it, I think Notes does too.
timeless: I didn't cc myself because I'm somewhere along the line watching someone who's watching someone getting bugmail from this bug, so no need to cc me. Since this bug's implementation uses OS-specific stuff, that's fine by me. We have much more important things to worry about that building our own 'drivers' for competitor's address books, except if we had done so without thinking about other OSes. Not the case here.
In general, I have a lot of sympathy with those who see the current proposal as an easy option. So I want to propose the following in an attempt to get a closure on this: Rather than seeing this in isolation, I believe that the landing of 78933 code affords us an opportunity to do this properly. After that code was landed, two features remained outstanding to consolidate that code. One was how to add Outlook/Outlook Express(this) and the other was how to add LDAP Address Books(83091). At the moment the 78933 pulls all Outlook Address Books to Mozilla. If we modify that to allow users to choose which ones to select, we can extend the New -> Address Book to: New -> Address Book -> Personal Address Book LDAP Address Book Outlook Outlook Express The PAB would continue to work as is, whilst the LDAP and Outlook/Outlook Express would present the user with a choice. The LDAP choice would be from the Directory Servers set up in the Preferences, the Outlook/Outlook Express would involve returning the names of the Address Books back to the user in a List Box from which to choose from. This would mean a small change to the Preferences plus we could add the ability to right-click on the address books on the left pane and see their properties. I hope to be in a position soon to post some screen shots.
QA Contact: fenella → nbaca
Moving to 0.9.5 per PDT
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Blocks: 104166
0.9.5 is out the door. bumping up the TM one notch
Target Milestone: mozilla0.9.5 → mozilla0.9.6
John, `File' > `New' > `Address Book' > {whatever} would have exactly the same nested menu yuckiness that `View' > `Show/Hide' > `External Address Books' > {whatever} would. (And yes, there's a major-severity bug on getting rid of the `Site Navigation Bar' submenu from `View' > `Show/Hide' in Navigator.) Again, this feature really belongs in the import tool, not in the menus.
I don't agree. I believe that you are missing the bigger picture. This bug plus bug 83091 should be taken together. What is now available is the ability of mozilla to support multiple types of address books. Support for Outlook and Outlook Express is not an import feature. We already have that. What we now have is the ability to add/modify/delete address books/cards of Outlook/Outlook Express from within Mozilla. This taken together with the LDAP Address Books allows us to add it to the New -> Address Book in the exact same way as PAB is done now. Are they all not on the same par? I have put forward this solution and I understand that Seth will look at it soon. But I believe this is a good enterprise solution.
This is very useful functionality, and it would be good to get it user-visible asap, even if there is still disagreement as to how best to present it to the user. We need to have widespread user interaction with the feature to iron out bugs in the back end code as much as smooth the UI. It would be nice if there was a wizard to prompt the user to expose OE and Outlook AB's as soon as these are detected on the system. During the initial account creation, for example, if an OE or Outlook AB is detected, the user should have the option to include them in the account. And if OE or Outlook is installed after Mozilla, then the next time MailNews is invoked then it would be great to have the wizard pop up and ask if the user wants access to that AB from MailNews. After that, at any time, I support the ability to add these AB's through John's proposal for File->New->Address Book... My interest in this feature is because of the widespread availability of syncing software for a variety of PDA's and net sites that uses Outlook as the basis. Once this code is user-visible, I will be able to use the Outlook AB from Mozilla, keeping it in sync with web based AB's and PDA's. I suspect there are many peolpe who currently use Outlook, as well as syncing software that is Outlook-specific, who would love to be able to use Mozilla instead. This will help them make the transition. Hopefully we will get the sync software people to support Mozilla / Netscape directly soon too ;-) The core code for this feature has been checked in for ages, but the UI seems to have blocked the momentum. Please could we get this user-visible in 0.9.6?
I agree, this is not import. This is more like when you add an ldap addressbook. jglick is best suited to evalute your screen shots and comment on the UI design. john, we already have the back end code for reading the OE addressbook, right? We just don't have a way to allow the user to expose the OE addressbook in our address book? this sounds like a good feature, but one that would be delayed by the current focus on performance.
First to reply to Seth's last post: >john, we already have the back end code for reading the OE addressbook, right? >We just don't have a way to allow the user to expose the OE addressbook in our >address book? Yes, to both. To enable Outlook and Outlook Express now, you only need to manually edit the prefs.js file. This UI change will update the prefs.js file for us. Jennifer's ideas look great. Option 'C' looks good. I agree with Scott that there is no need to add an extra key click to add an address book. My only doubt about it is moving the LDAP Address Book Preference update to the control of the Address Book rather than amending the Preferences directly. I believe there was some structural code issues around doing this when this was first mooted. I don't see why we need to duplicate the effort of entering Directory Servers. Entering an LDAP Address Book might simply be selecting from the list of Directory Servers already entered. We need to get some agreement on the relationship between the LDAP autocomplete and LDAP Address Books. Our proposal also incorporated the idea of right-clicking on the Address Books in the left pane which would display their properties. In the case of LDAP it would display the Directory Server Preferences. We could also use a different icon to highlight different Address Book types. But the differences overall are small in comparison to what we agree on. I believe we have enough consensus to start a patch and build a prototype around this proposal. I hope to get the go ahead to start this very soon.
I like Option C also.
Are the OE and Outlook addressbooks "monolithic" in the sense that there would be only one of each type on a machine? Or might I have multiple OE and Outlook identities, and thus AB's, that I might want to access from Mozilla? If so, won't we need an additional dialog to select the actual OE or Outlook AB to display? Is it enough to simply choose between OE and Outlook, or would the user also have to choose the Outlook/OE account?
>My only doubt about it is moving the LDAP Address Book Preference update to the >control of the Address Book rather than amending the Preferences directly. I >believe there was some structural code issues around doing this when this was >first mooted. I don't see why we need to duplicate the effort of entering >Directory Servers. Entering an LDAP Address Book might simply be selecting from >the list of Directory Servers already entered. In 4.x, the only way to add a new ldap directory (using the ui) was thru the Address Book. Seems like a logical place. An then in Prefs users could select a directory to use for autocomplete. When users were setting up a directory for autocomplete in Prefs, there was a lot of confusion as far as how to get items to appear in the list of available directories. Its wasn't very obvious you had to first go to the AB and add the directory so that it would appear as an available option in Prefs. So, for this release, we tried to solve this problem by adding the "Edit Directories" button in Prefs so that users could add/edit/delete entries right from prefs. But I think its good to also have the ability to add/edit/delete directories from the AB as well. I think users will expect to be able to create a new directory from the AB. If not, it won't be obvious that they have to first go to prefs to setup the directory and then go back to the AB to "show" the directory. So the proposed spec allows the user to add/edit/delete ldap directies from both places, the AB and Prefs. If the user adds a directory in one place, it should be available in the other place as well. For example, if the user adds a directory from the prefs window, it should automatically be listed in the AB. And if the user adds a directory using the AB, it should also be available for selection in Prefs. Updated spec is here (based on C): http://www.mozilla.org/mailnews/specs/addressbook/NewAddressBook1.html Original Draft of alternatives is still here: http://www.mozilla.org/mailnews/specs/addressbook/NewAddressBook.html
Please don't use "External Address Book". Very few customers will figure out what that means. The "External" part is confusing. I prefer Option B in Jennifer's latest document, because: (a) Addressbooks and LDAP Directories are separate (b) Addressbooks can either be Mozilla or Outlook / OE But please change the text "Add an existing address book from another application" to "Access an existing address book from:". The difference between "Add" and "Access" is important - it tells the user what is actually happening. Otherwise Option B is great, I hope it can land soon.
http://www.mozilla.org/mailnews/specs/addressbook/images/LdapSel.gif The pair to Add is Remove, the pair to Delete is New. I'd suggest Add/Remove as I think that's what we're using elsewhere in mailnews. slightly offtopic http://www.mozilla.org/mailnews/specs/addressbook/images/Group1.gif can you shift Add to to be right aligned matching listname etc?
>Are the OE and Outlook addressbooks "monolithic" in the sense that there would >be only one of each type on a machine? Or might I have multiple OE and Outlook >identities, and thus AB's, that I might want to access from Mozilla? If so, >won't we need an additional dialog to select the actual OE or Outlook AB to >display? Is it enough to simply choose between OE and Outlook, or would the >user also have to choose the Outlook/OE account? The existing functionality will pull in all Outlook and/or OE address books by simply adding an option to the preferences file. This proposal would incorporate the user choosing which Outlook or OE Address Book to add. I presume that is what Jennifer is showing in Option C where the user will choose from a list box of available Outlook or OE Address Book Names
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Target Milestone: mozilla0.9.7 → mozilla0.9.8
This patch should be applied on top of patch for bug #83091. There are a couple of issues with the patch. Although the patch employs an overlay as this UI change is for Windows only, this patch stills appears on other platforms. I need to understand this better in order to implement as a Windows only UI change. The screenshots also intended that the user should choose an Address Book name as returned from MAPI. This is also outstanding and probably would need a fix for bug #111968 to fully support it. The current Outlook and Outlook Express functionality was recently broken. The patch for bug #118119 needs to be applied. But overall this patch is advanced enough to kickstart the process.
Depends on: 118119
Following the landing of fix bug #83091, this patch needs to be updated. This patch requires only the patch for bug #118119 to be applied first.
created a new experimental build for windows for this patch at the experimental builds page of: http://abzilla.mozdev.org
we need some reviews here :)
Keywords: patch, review
Target Milestone: mozilla0.9.8 → ---
Blocks: 213274
uhh... I guess this work has stalled then?
I will find some time to continue this and #219559
Now both Outlook and OutlookExpress are created as MAPI addressbook, thus unpatched mozilla can use the directory without wrong. I had build a installer for it, where can I put it to?
Comment on attachment 146081 [details] [diff] [review] reworked patch to make it up-to-date and work better Could you please give a review or sreview?
Attachment #146081 - Flags: review?(bienvenu)
Attachment #146081 - Flags: superreview?(dmose)
Attachment #146081 - Flags: superreview?(dmose)
Attachment #146081 - Flags: review?(sspitzer)
Attachment #146081 - Flags: review?(bienvenu)
I asked David Bienvenu about reviewing this a couple of minutes ago. He will super-review it and ask Neil Rashbrook (Mozilla UI Owner) to review the front-end work.
Comment on attachment 146081 [details] [diff] [review] reworked patch to make it up-to-date and work better Neil, can you review this? I'll start with a few comments: + var popup = document.getElementById('externalABListPopup'); + + top.okCallback(popup.value); + } tab/spacing here is wrong. + if (dirType == MAPIDirectory) //AVoid create the same MAPI addressbook more then one time should be Avoid creating the same MAPI addressbook more than once. + if (! (nsCRT::strcmp ( description.get(), serverDescription.get() )) ) can't you just use description.Equals(serverDescription)? + return NS_ERROR_FILE_ALREADY_EXISTS; + if (dirType == MAPIDirectory) { + if (uri) + server->uri = nsCRT::strdup(uri); + } this should be: if (dirType == MAPIDirectory && uri) server->uri = strdup(uri);
Attachment #146081 - Flags: superreview?(bienvenu)
Attachment #146081 - Flags: review?(sspitzer)
Attachment #146081 - Flags: review?(neil.parkwaycc.co.uk)
Comment on attachment 146081 [details] [diff] [review] reworked patch to make it up-to-date and work better I don't have an msvc build I can test this with... >+++ mailnews/addrbook/resources/content/abExtAddressBookDialog.js 2004-04-13 21:37:54.000000000 +0800 What is the point of this dialog? Also the JS has no licence. >+ popup.setAttribute("label",gAddressBookBundle.getString("outlookAddressBook")); >+ popup.setAttribute("label",gAddressBookBundle.getString("outlookExpressAddressBook")); I'm not sure what you're trying to do here but the strings are not defined. >+++ mailnews/addrbook/resources/content/abExtAddressBookDialog.xul 2004-04-13 21:37:54.000000000 +0800 Wrong licence, needs to be MPL. >+<window xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" >+ title="&title.label;" >+ orient="vertical" >+ class="dialog" >+ onload="abExtNameOnLoad()" >+ style="padding:10px"> This needs to be a <dialog>, then you don't need dialogOverlay, okCancelButtons or class; orient and style were also unnecessary. >+ <hbox autostretch="never" align="center" pack="end"> autostretch no longer exists. How old is this patch ;-) >+ <text class="label" value="&application.label;" accesskey="&application.accesskey;" for="externalABListPopup" /> Use <label> instead of <text class="label"> >+ <menulist id="externalABListPopup" class="small-margin" flex="1" style="width: 0px;"> I don't think you need this style either. >+ var dialog = window.openDialog( >+ "chrome://messenger/content/addressbook/abExtAddressBookDialog.xul", >+ "", "chrome,titlebar", {okCallback:AbCreateExtAddressBook}); You don't need the "var dialog =" bit. Also, I think your dialog should be modal. >+function AbCreateExtAddressBook(type) >+{ >+ var properties = Components.classes["@mozilla.org/addressbook/properties;1"].createInstance(Components.interfaces.nsIAbDirectoryProperties); >+ if(type == "1") Why the opaque type values? Why not just pass the appropriate URI? Also space between if and (. >+ properties.description = "Outlook"; Is this description language-neutral? >+ if (dirType == MAPIDirectory) //AVoid create the same MAPI addressbook more then one time >+ { >+ if (!DIR_GetDirectories()) >+ return NS_ERROR_FAILURE; >+ >+ PRInt32 count = DIR_GetDirectories()->Count(); >+ for (PRInt32 i = 0; i < count; i++) >+ { >+ DIR_Server *server = (DIR_Server *)(DIR_GetDirectories()->ElementAt(i)); >+ >+ if (server->dirType == MAPIDirectory) >+ { >+ NS_ConvertUTF8toUCS2 serverDescription (server->description); >+ if (! (nsCRT::strcmp ( description.get(), serverDescription.get() )) ) >+ return NS_ERROR_FILE_ALREADY_EXISTS; >+ } >+ } >+ } Is there an easier way of doing this? It would be useful to allow the xul to disabling the option to create the directory if it exists.
Attachment #146081 - Flags: review?(neil.parkwaycc.co.uk) → review-
Hi Neil, >>+ popup.setAttribute("label",gAddressBookBundle.getString ("outlookAddressBook")); >>+ popup.setAttribute("label",gAddressBookBundle.getString ("outlookExpressAddressBook")); > >I'm not sure what you're trying to do here but the strings are not defined. Aren't they here: --- /dev/null 2004-04-14 13:06:49.000000000 +0800 +++ mailnews/addrbook/resources/locale/en-US/abExtAddressBookDialog.dtd 2004-04- 13 21:37:54.000000000 +0800 [...] + <!ENTITY outlookAddressBook.label "Outlook Address Book "> + <!ENTITY outlookExpress.label "Outlook Express"> + <!ENTITY outlookExpressAddressBook.label "Outlook Express Address Book">
no they aren't, because a dtd is no stringbundle, and outlookAddressBook is different from outlookAddressBook.label anyway
Noticed in the patch that the naming convention is not very strict for function entity and such : sometime we have the full Addressbook or AddressBook, or when it is abbreviated it is as Ab or AB or ab... Of course it is not that important but it helps readability a lot - I may do a cleanup after the patch is submitted in a following bug if the patch author does not want to spend time on this, of course the priority is functionality :-)
wind.li@sun.com: are you able to provide an updated patch based on the reviews which have been done? Gerv
I am trying my best to find time to learn XUL. But I am afraid I don't have the ability and time to finish this patch.
I am trying my best to find time to learn XUL. But I am afraid I don't have the ability and time to finish this patch in a short time.
I'm not quite sure which of the UI parts should be implemented - only the 'File->New->Add External AB' part (as the current, nonfunctional patches do) or the entries under 'View' also? But I'm willing to give it a try.
Assignee: alexis.ledoux → mnyromyr
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0?
Product: Browser → Seamonkey
I won't have time for this in the foreseeable future. Sorry, Simon. :(
Assignee: mnyromyr → sspitzer
QA Contact: nbaca
Attachment #146081 - Flags: superreview?(bienvenu)
Assignee: sspitzer → mail
Assignee: mail → nobody
Component: Address Book → MailNews: Address Book
Product: Mozilla Application Suite → Core
QA Contact: addressbook
Keywords: helpwanted
*** Bug 339392 has been marked as a duplicate of this bug. ***
Thought I should mention that I've been looking for this functionality for many years as I am a Mozilla fan. However, I did not believe that it was doable - not even by manually editing the user.js file (see http://kb.mozillazine.org/Using_Outlook_(Express)_contacts_with_Thunderbird_or_Mozilla_Mail). It's great that it can be done manually, but I think a lot of users miss that option. As for myself this was the only reason that I didn't make the switch from IE to TB.
Product: Core → MailNews Core
Flags: wanted-thunderbird3?
The reason that this isn't turned on by default is because the code isn't finished, reviewed, and given UI yet. Even if someone were to sign up for doing the coding work soonish, it would still require a large investment of time by Bryan for UX as well as core reviewers who already have too much on their plate in the Thunderbird 3 timeframe. So, unfortunately, I think this needs to be wanted-thunderbird3-. Marking as such.
Flags: wanted-thunderbird3? → wanted-thunderbird3-
Severity: normal → enhancement
Keywords: helpwanted
OS: Windows 98 → All

With IT Support's vast work over the last three months, can the UI please be enabled to use Outlook address books by default?

It will make discovery much easier than people trying to find and follow:
http://kb.mozillazine.org/Using_Outlook_and_OE_contacts_with_Thunderbird_or_Mozilla_Mail#To_use_Outlook_Contacts:
Note the URL above won't work as the colon (:) is required. Would be better if the heading on the page didn't have an ending colon.

What do you think?

Thank you

Sorry, forgot to add the link showing IT Support's vast work over the last three months:
https://hg.mozilla.org/comm-central/log?rev=henk

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: