The ‘contact’ meta extension



Overview:

You realize that your wallet has been stolen only when you start getting notifications of unauthorized transactions on your credit cards.

Panicking, you quickly try to contact your friend who works for a bank for advice. There is a delay of only a few moments as you search through your phone’s contact list to get his number.

On being advised to get your cards blocked immediately, you then try to obtain the customer care number of your bank. However now, you lose precious minutes as your search in vain for the contact number amidst the melee of links that clutter your bank’s website page.

Juxtapose this to a scenario wherein all that you had to do to get the customer care number of your bank would be to simply fetch the bank’s website and select a browser menu option called “Call” which would then automatically dial your bank’s customer support number.


Proposal:

The contact meta extension defines the vendor's contact information by way of a phone number (such as a customer support number), an e-mail ID (such as the customer support mail ID) or a physical address (such as the office address or billing address).

UAs displaying a page containing this meta extension could then make this contact information directly available for the user’s perusal.

Often visitors have to hunt through a vendor's site for obtaining the customer support mail ID, phone number etc. which is mostly hidden behind a not so prominently displayed "Help" or "Contact Us" link.

Vendor's specifying their registered mail ID, phone number and/or their address via this meta extension can thus expect supporting UAs to present the contact information to the user in an easily accessible format, either by way of a browser menu option (such as "mail", “call”, “map”) or via the URL bar scheme handler or in another similar format.

Selecting these menu options, if available, should launch the default mail application with the specified mail ID, the dialer application with the given contact number or, the default maps application loaded with the specified address/location tag respectively.

No known existing meta extensions with a similar name/intention exist.

Syntax:

<meta name="contact" content="+1-555-555-5555 abc@xyz.com '5844 South Oak Street, Chicago, Illinois' ">

The content attribute for the contact meta extension is a space separated string containing the phone-number followed by the e-mail ID and then the address (specified within quotes).

Or

<meta name="contact" content="Chicago: +1-555-555-5555 abc@xyz.com '5844 South Oak Street, Chicago, Illinois'; Brookfield: +1-444-444-4444 def@xyz.com '2341 Cherry Lane, Brookfield, Illinois'; Naperville: +1-333-333-3333 jkl@xyz.com '515 W. Jefferson, Naperville, Illinois 60540'">

For specifying multiple entries a semi-colon separated list of name: value pairs can be defined. The name can be any descriptive tag identifying the given location.

Valid phone numbers and mail IDs should be provided by the vendor. The address can either be a string specified within quotes or the latitude and longtitude coordinates.

<meta name="contact" content="Chicago: +1-555-555-5555 abc@xyz.com '20.593684;78.96288'; Brookfield: +1-444-444-4444 def@xyz.com '20.593684;78.96288'; Naperville: +1-333-333-3333 jkl@xyz.com '20.593684;78.96288'">


Drawings:

Selecting the Call option for the site icicibank.com should launch the dialer application with the given contact-number.


Selecting the Mail option should navigate; and launch the chosen mailing app with the specified contact-mail.


Selecting the Map option should launch the specified contact-address on the default map application.


Use Case (for multiple contact numbers, mail IDs and addresses):

We take the example of a banking website. In case of international banks (e.g. Citibank) we are posed with the challenge of enlisting all their contact details, spread across different nations.

Vendors mostly maintain granularity at a national level, redirecting the users to the country specific website automatically. This would be handled at the server itself wherein different pages shall be pushed based on the requesting IP. The website author can thus deliver country specific information to the users.

However, the bank will also have multiple offices throughout the country and multiple branches within the same city. The website author shall have to provide all the information regarding the bank’s various locations and corresponding customer care numbers and mail IDs. This forms the basis for having a syntax that is capable of accommodating multiple entries for contact numbers, mail IDs or addresses.

The UA could list down all the available options thereby enabling the user to make an informed choice.

An option for filtering the available options (based on the name) can also be provided to the end user.


Use Case (for geo-fencing):

Consider the same example of a banking website wherein the bank has several branches located within the same city. It would be highly beneficial to the user in such cases if the UA were to display the nearest branch address based on the user’s current location.

The user’s location information (if available) can be retrieved by the UA and the same can then be used to predict the nearest branch office from the list of the available offices. Corresponding contact-number too (if available) can be extracted (if specified with the same ‘name’).


As part of the Manifest:

Considering the aforementioned use cases, we are now faced with the possibility of having lengthy contact number and/or address lists being specified in meta tags. This would unnecessarily make the markup cumbersome and lengthy.

Instead, we could specify these values as part of the new json based Manifest [http://w3c.github.io/manifest/].

The name-value pairs can easily be defined in the json format and since the Manifest would ideally not be updated as often as the main resource it thus offers to be a more optimal solution.


As an HTML tag:

The contact information can also be provided via an HTML tag: <contact>. As an HTML tag, the complexities arising due to mapping of contact information to a particular location, can be avoided.


Future enhancements:

Provision for one click, WebRTC based sessions between the client and the vendor, thereby enhancing accessibility.


Feedback is most welcome! Please post any issues or comments regarding this here!