<a href="tel:[phone]"></a> Welke error code?

[Blueflame_Core]

Ik zit even met het volgende. Op m'n site wil ik graag dat het telefoonnummer direct gebeld kan worden vanaf een telefoon. Dit lukt met dit stukje code. Alleen werkt dit niet in een desktop browser. Ik krijg dan een melding als:

Het adres werd niet begrepen

Firefox weet niet hoe het dit adres moet openen, omdat het protocol (tel) met geen enkel programma is verbonden.

Misschien moet u andere software installeren om dit adres te openen.

Prima! Maar welke error pagina hoort hier bij zodat ik mensen vanaf een gewone computer kan redirecten naar de vorige pagina? Ik heb alle veelvoorkomende errorcodes al gebruikt (van 100 t/m 505), maar geen een die past bij dit probleem. Heeft iemand enig idee, zodat het wel werkt op een smartphone en gedirect word op een gewone pc?

[Snake]

Error codes zijn HTML. Aangezien tel: geen HTML is, hoe zit het dan?

[ Voor 5% gewijzigd door Snake op 25-04-2013 11:20 ]

[glashio]

HTML:

<a href="tel:[phone]" onclick="var w = window.open(this.href);w.close();return false;">Bel</a>

Edit: _{omdat het kan}

HTML:

<a href="tel:[phone]" onclick="return !!window.open(this.href).close()">Bel</a>

[ Voor 44% gewijzigd door glashio op 25-04-2013 11:45 . Reden: Minimize purisme ]

[Onbekend]

Een code 100 t/m 505 wordt eigenlijk gemaakt nadat de aanvraag van de pagina is gedaan. Bijvoorbeeld 404 - pagina niet gevonden.

Maar een webbrowser weet vooraf al niet hoe hij die aanvraag moet doen. Dus zo'n foutmelding zou je met javascript moeten afvangen.

[NMe]

Gewoon met javascript kijken of je met een mobiele browser te maken hebt, en zo nee, de link ook weer met javascript onklikbaar maken. Of juist andersom: alleen klikbaar maken als je wél met een mobiele browser te maken hebt.

[ameesters]

uhhmmm bestaat hiervoor niet iets als de vCard microformat?

code:

<ul class="vcard">
    <li class="fn">John Doe</li>
    <li class="org">Acme dummy corp.</li>
    <li class="tel">([phone] </li>
    <li><a class="url" href="<?php echo $profile->website()?>"><?php echo $profile->website()?></a></li>
</ul>

Deze link kan daarbij ook nuttig zijn: http://www.w3.org/2002/12/cal/vcard-notes.html

[MueR]

Dit kan je inderdaad niet aan de serverkant oplossen. Je stuurt iemand naar een protocol waar je browser niets mee kan en ook niet op je server aan gaat komen.

[Orion84]

Doen de meeste smartphone browsers dat trouwens niet gewoon vanzelf? Dat als ze ergens een telefoonnummer herkennen, dat het klikbaar wordt?

[bartbh]

Even snel getest: Chrome op Android wel, de stock-browser op Android JB niet.

[NMe]

Orion84 schreef op donderdag 25 april 2013 @ 12:15:
Doen de meeste smartphone browsers dat trouwens niet gewoon vanzelf? Dat als ze ergens een telefoonnummer herkennen, dat het klikbaar wordt?

Hangt er heel erg vanaf hoe dat nummer geformatteerd is. Met spaties, streepjes, haakjes en plusjes raakt zo'n parser al snel in de war.

[Orion84]

NMe schreef op donderdag 25 april 2013 @ 12:19:
[...]

Hangt er heel erg vanaf hoe dat nummer geformatteerd is. Met spaties, streepjes, haakjes en plusjes raakt zo'n parser al snel in de war.

Dat is natuurlijk een probleem dat je net zo goed gaat hebben als je het in datzelfde formaat aanlevert via een tel: link neem ik aan? En afhankelijk van de situatie hoeft dat geen probleem te zijn. Met een setje statische nummers op je contact pagina kan je er prima zelf voor zorgen dat ze op een nette manier geformatteerd zijn.

Alleen als het dynamische content is (gebruikersprofielen, bedrijfsprofielen, weet ik wat) en je het formaat van telefoonnummers niet afdwingt bij het opvoeren er van, dan zou je inderdaad een uitdaging hebben.

Maar goed, als er belangrijke browsers zijn die het niet automatisch doen, dan houdt het inderdaad wel een beetje op en zou je denk ik inderdaad het beste met JS kunnen kijken of je een mobiele client te pakken hebt en zo ja, het nummer als tel: link presenteren.

[NMe]

Orion84 schreef op donderdag 25 april 2013 @ 12:29:
[...]

Dat is natuurlijk een probleem dat je net zo goed gaat hebben als je het in datzelfde formaat aanlevert via een tel: link neem ik aan?

Nee hoor:

HTML:

<a href="tel:[phone]">([phone]</a>

[RM-rf]

Blueflame_Core schreef op donderdag 25 april 2013 @ 11:17:

Prima! Maar welke error pagina hoort hier bij zodat ik mensen vanaf een gewone computer kan redirecten naar de vorige pagina? Ik heb alle veelvoorkomende errorcodes al gebruikt (van 100 t/m 505), maar geen een die past bij dit probleem. Heeft iemand enig idee, zodat het wel werkt op een smartphone en gedirect word op een gewone pc?

je zou dit script kunnen proberen om een alternatieve href uit te voeren als een bepaalde urii-scheme niet herkend wordt

HTML:

<a class="linktoaction" href="persoon.vcf" data-action="tel:[phone]">Max Mustermann</a>

<script type="text/javascript">
jQuery("a.linktoaction").click( function(){
    
    // get action
    var action = jQuery(this).data("action");
    // get href
    var href = jQuery(this).attr("href");

    // start timer    
    var start= new Date().getTime();

    // redirect to the uri:scheme
    location = action;

    // end timer
    var end = new Date().getTime();
    // get elepased time
    var elapsed = (end - start);

    // no elepased time means protocol not recognized, refer to href
    if (elapsed < 1 && href ) {
        location = href;
    }
}
</script>

[Orion84]

NMe schreef op donderdag 25 april 2013 @ 12:48:
[...]

Nee hoor:

HTML:

<a href="tel:[phone]">([phone]</a>

Als je het in een parsebaar formaar in de tel: link kan zetten, dan kan je het toch ook in dat parsebare formaat plain text neerkwakken? Mits dat parsebare formaat ook een formaat is dat leesbaar is voor een mens natuurlijk, maar volgens mij is dat helemaal niet zo'n probleem. De telefoonnummers op http://tweakers.net/contact bijvoorbeeld worden gewoon prima geparst door safari. (Of zit daar stiekem al JS code achter die tel: linkjes aanbiedt als je met een mobiele browser surft? )

Maar goed, dat is een beetje een non-discussie als dat parsen überhaupt niet in alle belangrijke browsers (goed) ondersteund wordt.

[R4gnax]

Blueflame_Core schreef op donderdag 25 april 2013 @ 11:17:
Heeft iemand enig idee, zodat het wel werkt op een smartphone en gedirect word op een gewone pc?

Openen als een nieuwe window en deze meteen sluiten? Als er een protocol handler aan het venster gekoppeld zit, dan zal deze afgaan net voordat het venster automatisch gesloten wordt.

JavaScript:

$(document.body).on( "click", "a[href^='tel:']", function( event ) {
  event.preventDefault();
  window.open( this.href ).close();
}

Snake schreef op donderdag 25 april 2013 @ 11:20:
Error codes zijn HTML HTTP.

Zie RFC 2616.

[Blueflame_Core]

Zooo wat een reacties. Bedankt .

Onderstaande heb ik geprobeerd, maar dan werkt die ook niet op mobile browsers . Helaas ben ik niet zo thuis met Javascript, dus moet eigenlijk even een simpel compleet script hebben dat 100% werkt. Maar daar kan ik zelf wel even om googlen uiteraard. Ik weet nu in ieder geval dat een error code niet voor de hand ligt.

RM-rf schreef op donderdag 25 april 2013 @ 12:56:
[...]


je zou dit script kunnen proberen om een alternatieve href uit te voeren als een bepaalde urii-scheme niet herkend wordt

HTML:

<a class="linktoaction" href="persoon.vcf" data-action="tel:[phone]">Max Mustermann</a>

<script type="text/javascript">
jQuery("a.linktoaction").click( function(){
    
    // get action
    var action = jQuery(this).data("action");
    // get href
    var href = jQuery(this).attr("href");

    // start timer    
    var start= new Date().getTime();

    // redirect to the uri:scheme
    location = action;

    // end timer
    var end = new Date().getTime();
    // get elepased time
    var elapsed = (end - start);

    // no elepased time means protocol not recognized, refer to href
    if (elapsed < 1 && href ) {
        location = href;
    }
}
</script>

[Blueflame_Core]

glashio schreef op donderdag 25 april 2013 @ 11:20:

HTML:

<a href="tel:[phone]" onclick="var w = window.open(this.href);w.close();return false;">Bel</a>

Edit: _{omdat het kan}

HTML:

<a href="tel:[phone]" onclick="return !!window.open(this.href).close()">Bel</a>

Dit werkt op zich prima, maar niet in IE .

[_Thanatos_]

Niets doen. De foutmelding die de browser geeft is gewoon correct. Ik gebruik ook altijd tel: links en nog geen klant die erover gezeurd heeft. Leg gewoon uit dat je erop kunt klikken om te bellen als de device een belfunctie heeft.

Op de desktop kun je immers Skype, of Lync, of een VoIP ding, of eoa andere belapplicatie hebben. Op een tablet kun je zelfs bellen met de juiste app. Op een mobieltje werkt het standaard. Dus waarom zo moeilijk doen met allerlei scripts?

Daarbij, als je geen e-mailclient hebt (als je bijv alleen maar webmail gebruikt, of als je op een publieke computer zit) krijg je ook een foutmelding op een mailto-link. Wil je dat ook gaan afvangen?

[ Voor 17% gewijzigd door _Thanatos_ op 29-04-2013 04:47 ]

[NMe]

_Thanatos_ schreef op maandag 29 april 2013 @ 04:45:
Niets doen. De foutmelding die de browser geeft is gewoon correct. Ik gebruik ook altijd tel: links en nog geen klant die erover gezeurd heeft. Leg gewoon uit dat je erop kunt klikken om te bellen als de device een belfunctie heeft.

Ja joh, wat een heerlijk advies: als het linkje niet werkt snapt elke gebruiker dat meteen prima!

Nee, dit hoor je dus absoluut wél netjes af te vangen. Ofwel met graceful degradation, ofwel met progressive enhancement. Je kop in het zand steken en negeren dat er ook mensen met een desktop rondlopen zonder Skype (of zonder die plugin) is nogal dom.

Daarbij, als je geen e-mailclient hebt (als je bijv alleen maar webmail gebruikt, of als je op een publieke computer zit) krijg je ook een foutmelding op een mailto-link. Wil je dat ook gaan afvangen?

Mensen bij wie mailto: niks doet zijn heel zeldzaam, en volgens mij geeft je browser zelfs zonder mailclient alsnog een betere melding bij mailto-linkjes dan je krijgt bij tel-linkjes. Mensen bij wie tel: niks doet op de desktop zijn veel minder zeldzaam en daar hoor je als fatsoenlijk developer gewoon rekening mee te houden.

[ Voor 28% gewijzigd door NMe op 29-04-2013 16:52 ]

[_Thanatos_]

Nee, dit hoor je dus absoluut wél netjes af te vangen. Ofwel met graceful degradation, ofwel met progressive enhancement. Je kop in het zand steken en negeren dat er ook mensen met een desktop rondlopen zonder Skype (of zonder die plugin) is nogal dom.

Het ziet er dom uit, maar dat is het niet. De foutmelding is prima, en het is per browser verschillend hoe aan de gebruiker uitgelegd wordt wat het "probleem" is en wat er aan te doen valt. Echt, ik heb wel cryptischere foutmeldingen gezien, die gewoon door websites uitgekotst worden - willens en wetens door developers gemaakt.

Standaard browsergedrag moet je niet veranderen. Op de lange termijn kom je jezelf tegen - of er werkt ergens iets niet waardoor al je tel-links kapot gaan, of hij belt het verkeerde nummer, of hij zegt "je browser kan geen tel-links" terwijl dat wel zo is. Niet nu misschien, maar bij de volgende browser of volgende gebruiker wel.

Straks ga je ook nog het kunnen weergeven van PDF afvangen.

De browser kan niet bellen. Deal with it.
Mijn klanten zeuren er niet over als ik het gewoon uitleg. En er zitten zeikerds tussen hoor, geloof me.

[incaz]

Maar als je het persoonlijk uitlegt, kun je het toch ook uitleggen via een iets begrijpelijkere foutafhandeling? Scheelt aanmerkelijk aan tijd die je moet besteden aan user support, en aan frustratie van mensen. Meteen een begrijpelijke tekst zien is veel fijner dan eerst een vrij cryptische foutmelding te zien waarvoor je uitleg bij de developer moet vragen. En ja, de foutmelding is cryptisch. Dat er talloze applicaties zijn met nog veel cryptischere foutmeldingen is vooral waarom IT geregeld een nogal slechte naam heeft, niet echt een goede reden om het net zo beroerd te houden.

Bovendien: de browser kent het protocol mogelijk niet, en kan dus niet zo specifiek zijn. De developer weet wel wat precies de bedoeling is en kan dus heel specifiek zeggen wat het probleem is (geen applicatie om mee te bellen) en suggesties doen om het op te lossen door bijvoorbeeld applicaties met name te noemen.

En wat betreft pdf: op heel veel plekken met pdf-bestanden staat uitleg, 'voor het bekijken van dit document heeft u Adobe Acrobat Reader of een vergelijkbaar programma nodig.' Alleen genereert dat geen foutmelding.

"De browser kan niet bellen. Deal with it."

Dat is toch precies de vraag: hoe deal je daarmee?

[NMe]

_Thanatos_ schreef op dinsdag 30 april 2013 @ 02:49:
[...]

Mijn klanten zeuren er niet over als ik het gewoon uitleg. En er zitten zeikerds tussen hoor, geloof me.

Dan zit je dingen als excuus te gebruiken die geen excuus zijn. Je kan dit soort foutmeldingen prima afvangen voordat ze gegooid worden. De gemiddelde gebruiker snapt die melding niet. Zelfs als je klant op een gegeven moment die melding snapt, dan snappen hún klanten het nog niet. Zo'n link zomaar bewust (!) laten staan terwijl hij prima netjes weg te werken is, is een belediging voor je eigen vakgebied.

[ameesters]

laat dit nou allemaal perfect werken als vcard/hcard:
http://microformats.org/wiki/hcard

Maar nee, laten we vooral het "not invented here" syndroom toepassen

Gewoon lekker moeilijk blijven doen is mijn advies...
Vergeten jullie dan niet een duidelijke foutmelding te tonen mocht de foutmelding afhandeling/onderukking niet werken, en voor de zekerheid ook even die foutmelding checken zodat als de foutmelding over de foutmelding niet werkt ze toch een foutmelding krijgen

[NMe]

ameesters schreef op woensdag 01 mei 2013 @ 15:38:
laat dit nou allemaal perfect werken als vcard/hcard:
http://microformats.org/wiki/hcard

Maar nee, laten we vooral het "not invented here" syndroom toepassen

Naast het feit dat een vCard gebruiken alleen om een telefoonnummer weer te kunnen geven nogal overkill is, stap je er voor het gemak even helemaal overheen dat vCards helemaal niet door elke browser zo geïnterpreteerd worden dat een telefoonnummer klikbaar is. Dus misschien iets minder stromannen rondstrooien en wat meer nadenken voordat je iets roept.

[steffex]

je kunt bij je request toch zien door welk soort device het is gedaan? Als het wordt gedaan door een desktop device, serveer je toch gewoon andere content?

Bijvoorbeeld met CSS de div hiden waar de a tag in staat en dan een span met alleen het nummer tonen in tekst format.

[NiteSpeed]

NMe schreef op woensdag 01 mei 2013 @ 15:47:
[...]

Naast het feit dat een vCard gebruiken alleen om een telefoonnummer weer te kunnen geven nogal overkill is, stap je er voor het gemak even helemaal overheen dat vCards helemaal niet door elke browser zo geïnterpreteerd worden dat een telefoonnummer klikbaar is. Dus misschien iets minder stromannen rondstrooien en wat meer nadenken voordat je iets roept.

Overkill valt wel mee, je hoeft niet alles in te vullen natuurlijk. Als je alleen een telefoonnummer wilt invullen kan dat best.

Je tweede argument is trouwens voor mij persoonlijk een reden om juist deze oplossing toe te passen. Laat het maar aan de browser over om te bepalen of een telefoonnummer klikbaar is of niet. Lekker feature-friendly ontwikkelen zo. Devices die het ondersteunen hebben de functionaliteit, devices die het niet snappen negeren het. Prima geregeld.

[ZpAz]

glashio schreef op donderdag 25 april 2013 @ 11:20:

HTML:

<a href="tel:[phone]" onclick="var w = window.open(this.href);w.close();return false;">Bel</a>

Edit: _{omdat het kan}

HTML:

<a href="tel:[phone]" onclick="return !!window.open(this.href).close()">Bel</a>

Die laatste is dat niet een "double negative?"

Als in

C:

true == true;
!true == false;
!!true == true;

En return je in feite weer true?

[NMe]

NiteSpeed schreef op donderdag 02 mei 2013 @ 00:18:
[...]

Overkill valt wel mee, je hoeft niet alles in te vullen natuurlijk. Als je alleen een telefoonnummer wilt invullen kan dat best.

Natuurlijk kán dat, maar dat streeft het doel helemaal voorbij. Je hebt niks aan de hele vCard.

Je tweede argument is trouwens voor mij persoonlijk een reden om juist deze oplossing toe te passen. Laat het maar aan de browser over om te bepalen of een telefoonnummer klikbaar is of niet. Lekker feature-friendly ontwikkelen zo. Devices die het ondersteunen hebben de functionaliteit, devices die het niet snappen negeren het. Prima geregeld.

Juist met dat in het achterhoofd moet je tel: hebben, want de kans dat dat klikbaar gerenderd wordt door browsers met bel-support is groter dan bij een vCard...

[R4gnax]

ZpAz schreef op donderdag 02 mei 2013 @ 12:18:
Die laatste is dat niet een "double negative?"

Die laatste is een truthy -> true conversie.

Overigens lijkt die logica me ook niet helemaal correct: het hangt vziw nogal van de gebruikte browser af of er een window instance of null geretourneerd wordt wanneer je een link met een procotol als 'tel:' probeert te openen dat niet echt een nieuwe pagina gaat tonen...

[ZpAz]

Aa precies. Weer wat geleerd.

[_Thanatos_]

glashio schreef op donderdag 25 april 2013 @ 11:20:

HTML:

<a href="tel:[phone]" onclick="var w = window.open(this.href);w.close();return false;">Bel</a>

Edit: _{omdat het kan}

HTML:

<a href="tel:[phone]" onclick="return !!window.open(this.href).close()">Bel</a>

Net even getest in IE10 op een desktop zonder belapplicatie: dit geeft in hetzelfde window een error "The webpage cannot be displayed" met de tel-link in de adresbalk. Precies hetzelfde als een kale tel-link. Wat dat betreft lost het dus niets op (zoals ik al dacht - zie hierboven).

In Opera en Chrome geeft het een fractie van een seconde een nieuwe tab, dus het is hooguit niet netjes, maar dit betekent dat de gebruiker slechts popups hoeft te blokkeren (of vrij aggressief automatische popups blokkeren) om dit ook te laten falen in Opera op een desktop mét belfunctie. Het probleem met de popupblokker zal ook spelen op een mobiel, en dan krijg je dus óók klachten dat de link niet werkt.

In Safari geeft het zelfs een compleet nieuw window dat meteen verdwijnt. Ziet eruit alsof je iets probeert te verbergen.

/edit:

Dan zit je dingen als excuus te gebruiken die geen excuus zijn. Je kan dit soort foutmeldingen prima afvangen voordat ze gegooid worden. De gemiddelde gebruiker snapt die melding niet. Zelfs als je klant op een gegeven moment die melding snapt, dan snappen hún klanten het nog niet.

Dus we verwachten van jou nu een oplossing die wel werkt
Dat laatste zinnetje uit je post denk ik maar even weg

[ Voor 21% gewijzigd door _Thanatos_ op 02-05-2013 20:40 ]