117154 - Prefs UI for changing "Map It!" provider

Status: NEW

(MailNews Core :: Address Book, enhancement)

Description

[Ben Bucksch (:BenB)]

For every hookup to an external site, we should have the ability to change the
provider via the UI. Users have reasons for not liking particular providers.

In the case of "Show map for address" (bug 116451), it should be extremely
simple. Just add a dropdown somewhere in prefs. Options would be
"Disabled" - ""
"Yahoo! Maps" -
"http://maps.yahoo.com/py/maps.py?Pyt=Tmap&Country=@CO&addr=@A1%20@A2&csz=@CI,%20@ST%20@ZI""Mapquest
(US only)" -
"http://www.mapquest.com/maps/map.adp?country=@CO&address=@A1%20@A2&city=@CI&state=@ST&zipcode=@ZI"
(The first is what the user sees in the dropdown and the latter is what the pref
will be sat to, if that item is selected.) More options can be added, but I
don't know other good map providers.

Seth mentions Expedia. That's a Microsoft site and consequently, it says
"Internet Explorer" when it should say "browser". IMO, we should not support it.

If anyone wants to take this bug, feel free to do so (unless I already attached
patches. of course :-) ).

Comment 1

[(not reading, please use [e-mail] instead)]

I'm not sure we want to expose this in the UI.  

let's wait for a spec decision from jglick before proceeding.

taking for now.

Comment 2

[jglick]

I would agree this is probably not something most users want to change (nor that 
we should let them). A hidden prefs would be useful for advanced users.

Comment 3

[Ben Bucksch (:BenB)]

I do think that average users have preferences for sites. Some people prefer
Yahoo, some dmoz/Netscape. Some prefer cnn.com, some cnet. Some prefer mapquest,
some Yahoo. For example, Yahoo can lookup international addresses, while
mapquest can't. But maybe I just don't like mapquest's colors. :-)

Comment 4

[kmurray1115]

I think with search engines, there is a high level of awareness and loyalty that
warrants us putting the ability to choose a different/default search engine in
the app UI. But I'm not convinced that the same differentiation exists with
mapping services just yet. I'd like to leave the Mapquest info in as is, and
allow changing the pointer as a hidden pref.

Comment 5

[Doug Hockin]

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

Comment 6

[OstGote!]

Bug 282157 changed it to Google Maps for TB en

Comment 7

[Worcester12345]

(In reply to comment #4)
> I think with search engines, there is a high level of awareness and loyalty that
> warrants us putting the ability to choose a different/default search engine in
> the app UI. But I'm not convinced that the same differentiation exists with
> mapping services just yet. I'd like to leave the Mapquest info in as is, and
> allow changing the pointer as a hidden pref.

I think this has changed since 2002.

Comment 8

[Serge Gautherie (:sgautherie)]

<http://mxr.mozilla.org/mozilla/search?string=mapit_url&case=on&filter=%5E%5B%5E%5C0%5D*%24&tree=mozilla>
Actual (SM/TB) flow is: abCardViewOverlay.js <-> mailnews.js <-> region.properties.

***

(In reply to comment #6)
> Bug 282157 changed it to Google Maps for TB en

<http://www.mozilla.org/mailnews/arch/addrbook/hiddenprefs.html#Map_It_pref>
already needs an update as TB bug 282157 and (now) SM bug 436814 replaced MapQuest by Google Maps (for default en-US...).

***

A hidden pref (through <about:config>) is what we currently have.

Adding a UI would also allow to keep/restore MapQuest for its existing happy users...

Comment 9

[David :Bienvenu]

this would be cool, but marking - based on new driver criteria
https://wiki.mozilla.org/Thunderbird:Release_Driving

Comment 10

[:aceman]

Bug 531285 has added support for having multiple mapping services simultaneously. So any UI would have to manage this list (not a single URL). There is also some notion for shipped default URLs and user added URLs. Maybe the UI could just manage the user list. Anyway, ANY list management is not trivial amount of code and UI.
If we decided to only allow adding of new URL via a single textbox, that could be much more manageable code-wise.