Closed Bug 437956 Opened 15 years ago Closed 15 years ago

Linkify phone numbers

Categories

(Firefox for Android Graveyard :: General, enhancement, P1)

Product:
Firefox for Android Graveyard
Component:
General
Platform:
Other
Maemo
Type:
enhancement

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
fennec1.0m6

People

(Reporter: christian.bugzilla, Assigned: blassey)

Details

Attachments

(2 files, 1 obsolete file)

greasemonkey script to turn phone numbers into tel uri's
733 bytes, application/x-javascript
Details
moved code to browser.js
2.40 KB, patch
mfinkle
: review+
Details | Diff | Splinter Review
Flags: blocking-fennec1.0+
Priority: -- → P1
Assignee: nobody → blassey
we should NOT linkify phone numbers in content no more than we should linkify URLs that do not have anchor tags in HTML.  Authors that want telephone numbers can use the tel: protocol.

I assume that this bug is about impl. a tel: protocol on maemo?
(In reply to comment #1)
> I assume that this bug is about impl. a tel: protocol on maemo?
> 
No, I'm fairly sure this bug is about adding code to add tel: links around phone numbers found in content. It could be preference based.

I believe the goal here is to make it as simple as possible (no typing or finger work) to call a phone number found on a web page (restaurant, movie, hotel, etc.)
I agree with doug here.  We shouldn't linkify things that look a phone number.  Web authors should be using anchors and a tel url.  

It would make a good extension though.
I think we *should* linkify phone numbers based on the simple test: "Do you need a piece of paper to accomplish your task or not". If we don't linkify phone numbers (or make them usable through other means) you will have to use a pen and paper to call someone on your phone. 

Not that the majority is right, but many browsers on phone already do this, because it is very, very useful.




I agree wholeheartedly with Christian here.  If my mobile browser didn't do this, I would switch browsers rather than dealing with copy/paste.  Its a really common use case, and we shouldn't make it harder than it is in other browsers, period.
Figuring out how to linkify a phone number might be a neat exercise, but I worry about false positives and unexpected behavior.  Why not just use the spec (rfc2806) and let the content developer control what the expected behavior should be?

I guess I'll say it again, we *shouldn't* linkify phone numbers.  Web authors should use anchors and the tel url if they want links in their page.  If we do linkify numbers auto-magically, there is no way for the content author to over ride or even anticipate that behavior.

It is useful functionality though (as I said before), and I think it should be exposed through a contextual menu.  

What I *really* want to avoid is the situation I see on windows mobile (both in pie and the mail reader).  Zip codes, ups tracking numbers, my frequent flyer number etc. all get turned into ugly and meaningless links.  Meanwhile, actual phone numbers such as phone extensions don't.


(In reply to comment #8)
> I guess I'll say it again, we *shouldn't* linkify phone numbers.

Rationale?

> Web authors
> should use anchors and the tel url if they want links in their page.  If we do
> linkify numbers auto-magically, there is no way for the content author to over
> ride or even anticipate that behavior.

If there's no way to anticipate the behaviour, how do you expect developers to make a conscious choice to linkify the number?  Either this is a standard authors should be expected to be aware of and make conscious choices about, or its something obscure they won't anticipate.  I'm willing to be most content creators aren't aware of tel: URLs (I had never heard of them until you brought them up in Toronto).  As for overriding the behaviour, a) why would they want stuff to _not_ be linked and b) why can't we provide a way for content authors to obfuscate the number?  More importantly, why should we care about content authors here?  I don't think anyone putting a phone number in content will object if that phone number is easier to call...

> It is useful functionality though (as I said before), and I think it should be
> exposed through a contextual menu.

Contextual menus are advanced functionality and without some sort of visual hinting it'll be rarely discovered.

> What I *really* want to avoid is the situation I see on windows mobile (both in
> pie and the mail reader).  Zip codes, ups tracking numbers, my frequent flyer
> number etc. all get turned into ugly and meaningless links.  Meanwhile, actual
> phone numbers such as phone extensions don't.

To be blunt, then don't screw up the pattern matching that badly.  I don't care so much about the extension number thing (and we should evangelize tel: to give content authors real control for this stuff).  I care about enabling one of the most common user behaviours on mobile (certainly I've used it hundreds of time on my phone).

This is the type of feature that will hinder adoption if absent, because its a _really_ common use case, and there's no really strong arguments being presented here.
@mconnor, the standard way of doing this is via the tel protocol.  tel urls are widely used on mobile sites including google search and have been around for years.  I wonder how much of your usage of the mobile browser was actually linkified a phone number, or just followed the standard tel protocol.




> If there's no way to anticipate the behaviour, how do you expect developers to
> make a conscious choice to linkify the number?  

My point was that if we auto-magically linkify numbers that look like phone numbers and other browsers don't, then there is no way for content authors to anticipate the behavior.  However, if a content author puts the number in a tel url, they can be assured that it will appear as a clickable link.  

Support for the tel url is mandated by carriers to be in the browser.

> Either this is a standard
> authors should be expected to be aware of and make conscious choices about, or
> its something obscure they won't anticipate.

It is a standard that is very well known in the mobile market place.  Until recently, there was no real way for desktop browsers to use the standard, but with softphones becoming popular it should be adopted by desktop browsers as well.

>  I'm willing to be most content
> creators aren't aware of tel: URLs (I had never heard of them until you brought
> them up in Toronto).  

I'd be willing to be most mobile content creators are very well aware of it.

> As for overriding the behaviour, a) why would they want
> stuff to _not_ be linked and b) why can't we provide a way for content authors
> to obfuscate the number?  More importantly, why should we care about content
> authors here?  I don't think anyone putting a phone number in content will
> object if that phone number is easier to call...

UPS's tracking numbers look very much like phone numbers, I would think UPS would like to make sure we don't turn their tracking numbers into phone numbers.  

How would you propose UPS obfuscate their tracking numbers and why would we make them jump through those hoops?

Also, in the case of yahoo and ms live search (below) they but a tel: uri link next to the phone number.  Obviously they made a conscience choice not to linkify the phone number and instead designed their sites in a different way.

> To be blunt, then don't screw up the pattern matching that badly.  
It is a bit more than pattern matching, especially when you take international phone number formats into account. There will be errors.

> I don't care
> so much about the extension number thing (and we should evangelize tel: to give
> content authors real control for this stuff).  I care about enabling one of the
> most common user behaviours on mobile (certainly I've used it hundreds of time
> on my phone).
> 
> This is the type of feature that will hinder adoption if absent, because its a
> _really_ common use case, and there's no really strong arguments being
> presented here.
> 

The real solution here is to evangelize the use of the existing standard to content that's not using it.  Linkifying things that look like phone numbers is at best a stop gap measure.  Besides the high error rate that I would anticipate even the best pattern matching to have, I fear it will make content authors lazy and forget about the standards based approach.

here are a few examples of the tel url's existing adoption/usage  (yelp is using the wtai: url):

http://www.google.com/m/search?mrestrict=xhtml&eosr=on&q=pizza+in+mountain+view
http://us.m.yahoo.com/p/search;_ylt=ApZAQ0DFxvrYJ3TAH7wNFpVaLy4J?p=pizza+in+mountain+view%2C+ca&submit=oneSearch
http://m.live.com/search/StartPage.aspx
http://mobile.yelp.com/search?find_desc=pizza&find_loc=Mountain+View%2C+CA


The point here is that yes there are mobile pages that do support the tel: URL but since the majority of websites are non-mobile and they don't support it, you will have to use pen and paper to call a phone number on those pages. This is a really common use case for a mobile browser and taking the stance that we should just follow standards in situations where we can improve the user experience seems wrong to me.

I am not sure I understand whether the main problem  with this feature is how the user discovers there is a phone number and uses it or the difficulty of finding those numbers.

My suggestion is that we split the work up in two separate bugs:

1) for finding phone numbers on web pages (it can be done, Mail.App does it, several mobile browsers do it). Yes it will create false positives, but the user will know from the context whether it is a phone number or not. 

2) have the UX guys figure out how the user interfaces with the phone numbers on the web page

(In reply to comment #10)
> @mconnor, the standard way of doing this is via the tel protocol.  tel urls are
> widely used on mobile sites including google search and have been around for
> years.  I wonder how much of your usage of the mobile browser was actually
> linkified a phone number, or just followed the standard tel protocol.

Based on the sites I've used, I don't think most of them have it.  Much of the time its very much not a mobile site that I'm getting numbers from.
(In reply to comment #11)
> > If there's no way to anticipate the behaviour, how do you expect developers to
> > make a conscious choice to linkify the number?  
> 
> My point was that if we auto-magically linkify numbers that look like phone
> numbers and other browsers don't, then there is no way for content authors to
> anticipate the behavior.  However, if a content author puts the number in a tel
> url, they can be assured that it will appear as a clickable link.  

Except by all of the ways that content authors handle cross-browser inconsistencies if they feel the need to work around them.

> Support for the tel url is mandated by carriers to be in the browser.

Doesn't mean that content creators know or care about it.

> > Either this is a standard
> > authors should be expected to be aware of and make conscious choices about, or
> > its something obscure they won't anticipate.
> 
> It is a standard that is very well known in the mobile market place.  Until
> recently, there was no real way for desktop browsers to use the standard, but
> with softphones becoming popular it should be adopted by desktop browsers as
> well.

Browsers typically support whatever protocol you throw at them, try linking foobar://www.mozilla.com, you'll just get an error that nothing is registered in the OS for that protocol.  The point doesn't matter, because I don't think people know about it, and I don't think people are going to go back and fix up years of content to follow the spec.

> >  I'm willing to be most content
> > creators aren't aware of tel: URLs (I had never heard of them until you brought
> > them up in Toronto).  
> 
> I'd be willing to be most mobile content creators are very well aware of it.

Sorry, wrong answer.  Mobile content vs. other content is a false god.  See Mitchell's talks recently about how the Mobile Web is bad fragmentation.  Mobile content is not our goal as a browser, content, period is.

> > As for overriding the behaviour, a) why would they want
> > stuff to _not_ be linked and b) why can't we provide a way for content authors
> > to obfuscate the number?  More importantly, why should we care about content
> > authors here?  I don't think anyone putting a phone number in content will
> > object if that phone number is easier to call...
> 
> UPS's tracking numbers look very much like phone numbers, I would think UPS
> would like to make sure we don't turn their tracking numbers into phone
> numbers.  

a) why?  what harm does it create for them?
b) it will be very unlikely that users will accidentally click on those and attempt to call it, given surrounding context.  Possible, but unlikely.

> How would you propose UPS obfuscate their tracking numbers and why would we
> make them jump through those hoops?

Well, I would probably avoid pattern matching numbers without spaces in any case, but obfuscate is the wrong word.  We could do something simple like a meta tag if authors wanted to prevent auto-linking.

> Also, in the case of yahoo and ms live search (below) they but a tel: uri link
> next to the phone number.  Obviously they made a conscience choice not to
> linkify the phone number and instead designed their sites in a different way.

Then we provide a way to suppress it.  Or, maybe trickier, if content has any tel: URLs, we don't auto-link numbers in that document?

> > To be blunt, then don't screw up the pattern matching that badly.  
> It is a bit more than pattern matching, especially when you take international
> phone number formats into account. There will be errors.

International phone numbers tend to have some pattern to them.  I realize its imperfect, but false positives are a better failure state here, IMO.

Option B is be conservative and be very restrictive about the patterns we match (i.e. if you see (nnn) nnn-nnnn you know its a phone number, so we shouldn't panic about linkifying that)

> > I don't care
> > so much about the extension number thing (and we should evangelize tel: to give
> > content authors real control for this stuff).  I care about enabling one of the
> > most common user behaviours on mobile (certainly I've used it hundreds of time
> > on my phone).
> > 
> > This is the type of feature that will hinder adoption if absent, because its a
> > _really_ common use case, and there's no really strong arguments being
> > presented here.
> > 
> 
> The real solution here is to evangelize the use of the existing standard to
> content that's not using it.  Linkifying things that look like phone numbers is
> at best a stop gap measure.  Besides the high error rate that I would
> anticipate even the best pattern matching to have, I fear it will make content
> authors lazy and forget about the standards based approach.

Sorry, I don't buy this.  The problem is that a huge number of content creators (people sticking stuff on wikis or blogs or whatever) are not within reach for evangelism.  Relying on user education is not a viable path forward, our job is to make the users' lives easier, and digging in here doesn't solve any real problems, IMO.

> here are a few examples of the tel url's existing adoption/usage  (yelp is
> using the wtai: url):
> 
> http://www.google.com/m/search?mrestrict=xhtml&eosr=on&q=pizza+in+mountain+view
> http://us.m.yahoo.com/p/search;_ylt=ApZAQ0DFxvrYJ3TAH7wNFpVaLy4J?p=pizza+in+mountain+view%2C+ca&submit=oneSearch
> http://m.live.com/search/StartPage.aspx
> http://mobile.yelp.com/search?find_desc=pizza&find_loc=Mountain+View%2C+CA

I'm not surprised at all that mobile content uses it.  What about content that isn't optimized for mobile phones?  There's a ton of it out there, and devices like the N810 _will_ consume primarily "normal" content.

Anyway, I don't quite get what you're digging in for here.  You're identifying things that will cause problems, if left unsolved, but I think we can solve them.

Let's shoot for the following:

a) Start with a very conservative pattern matching setup. (nnn) nnn-nnnn is a good example of an unambiguous pattern that I can't imagine anyone complaining about us linkifying.
b) Provide a way for content authors who care about it to suppress the auto-linking.
c) evaluate more aggressive pattern matching as we go forward.

Perhaps we can stop debating the value of turning this on by default and just agree that the feature itself us useful (either on by default or by contextmenu) and just implement it the best we can.
"feature itself is useful" --- totally in agreement.  We want users to be able to click on phone numbers and have the phone dial.  How this gets implemented is what we are arguing about.

We must support the tel: protocol and we must encourage people to use the tel: protocol.  For older content, taking an approach like mconnor suggests seems reasonable with the big assumptions he is making:

1) that we can conservatively parse for phone numbers and suck up the failure cases.

2) that content developers can turn this off.  mconnor, what are you thinking here?


I wonder if it would be acceptable to not "linkify" any phone numbers, but instead allow the user to select the text and then -- using the context menu as mfinkly suggest -- fire off a telephone call.


Here is a grease monkey script to do the conversion.  It works for all of my American test cases.  I know it won't work if you don't chunk your number in 3-3-4 format.  The recognition is done with regex, so it can be massaged.

I feel fairly strongly that this functionality should be in an add-on (or greasemonkey script), but not in the platform/product.
Brad, you're not presenting a clear argument why this is not desirable under any circumstances. You've raised reasonable concerns about the fallout from a bad implementation, but I think those are solvable problems.

I'm asserting that a) this is a common user task and b) we should do what we can to minimize effort required for users to perform the task.  Can you at least reply to that part so I can understand where you're coming from when you assert that we just shouldn't do it?
If we do implement this and a content author has numbers that look like phone numbers (like UPS tracking numbers) there is no way for them to stop us from linkifying them.  The end result is a user looks at a page that has tracking numbers as links.  The natural assumption is that they are links to tracking data.  The user clicks on it and we try to make a call.  That's broken.

If a content author wants their phone numbers to be linkified, there is an existing standard for it and they should use it.  This standard is widely in use today. 

The iPhone doesn't linkify phone numbers and I don't hear anyone complaining, probably because most sites are using tel uri's.  



the iPhone does linkify numbers, when it can tell what they are.

we should do this.  many UPS numbers start with 1Z which is easy to avoid.  sure you'll hit some, but do you really go to a lot of sites with UPS numbers on them?  I sure don't.  I go to a lot of sites with phone numbers on them.

we should be supporting <a href="tel:"/> as well as auto-linkifying things.  content developers don't currently know about tel:, and will need to be made aware.  I bet evang can help some here, but until it is more common, we should be doing things to make life more easy for the user.
I don't think really belongs in deckbrowser (it exists mostly for encapsulating the panning/zooming stuff). Just put it in browser.js?

        Attachment #327686 -
        Attachment is obsolete: true

        Attachment #327815 -
        Flags: review?

        Attachment #327686 -
        Flags: review?

        Attachment #327815 -
        Flags: review? → review?(gavin.sharp)

        Attachment #327815 -
        Flags: review?(gavin.sharp) → review?(mark.finkle)

    
    

    
  
Comment on attachment 327815 [details] [diff] [review]
moved code to browser.js

only nits:
* are the spaces around $1 needed? I guess as long as they don't effect rendering it's ok
* add spaces between contorl flow statements parens/braces
* add spaces after "," in function param lists

The browser-canvas refresh will make the new anchors show up in the canvas, so no worries there.

        Attachment #327815 -
        Flags: review?(mark.finkle) → review+

    
    

    
  
brad, will this land for M5?

    
    

    
  
It doesn't make much sense to me to linkify phone numbers when we can't handle them, so I was waiting for bug 437950, bug 437949 and bug 441636 to have their patches land.  Let me know if you disagree.

    
  
Target Milestone: Fennec M5 → Fennec M6

    
    

    
  
brad landed this
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED

    
    

    
  
verified with beta3
Status: RESOLVED → VERIFIED

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