Underline or no underline

Question

I am having a discussion with an AD regarding an info page for a store in an iOS app. On this info page we use an grouped UITableViewController showing information such as address, phone number, email address and more. The top shows a mini-map with annotation... I guess you get the picture. Looks very similar to a contact's page on the iPhone.

In the wire-frames the email address is written with an underline and the row has no disclosure indicator. When pressing the row, an Modal view for email should popup allowing the user to send an email to the given email address.

The AD arguments that we should have an underline here since this makes it more clear for the user it is press-able. Also, since it is a common way of showing e-mail addresses/links. He furthermore adds to it that tons of apps do this, including that (some?) of Apple's own apps use it on links.

I argue that this is not only against Apple's HIG, but also not common. It is only common on iOS devices in texts. I refer to the HIG stating the following:

Controls should look tappable. iOS controls, such as buttons, pickers, and sliders, have contours and gradients that invite touches.

If you're coming from the web, you need to make sure that you give people an iOS app experience, not a web experience. Remember, people can visit your website on their iOS devices using Safari on iOS.

Design for touch. Don’t try to replicate web UI design paradigms in your iOS app. Instead, get familiar with the UI elements and patterns of iOS and use them to showcase your content. Web elements you’ll need to re-examine include menus, interactions initiated by hovering, and links.

(Ref link: Apple)

He, in his turn states that half of my arguments are no longer valid after WWDC13's keynote. He is referring to something that is neither finished nor officially released. Besides, after a quick look-through of the iOS7 HIG, I can't find anything stating a different argument. Besides, as example, the contact app on iOS7 doesn't either use underline.

Having in mind that neither of the other field such as address or phone number have underline yet are press-able... also given that the app in question is a new target based upon an existing app which neither implements underlines on actions. My question, given this absurd subject, is: How should it be? With or without underline, thats the question.

Although the answer to this question will not be used to decide which solution we should go for, I would still like to know what would be best.

Answer 1

A tableview typically has a single appropriate action for touching any part of the element. The exceptions to this are obviously touchable widgets for delete, select, expand, those sorts of things.

So in the phone app's contact list, touching anywhere on the contact expands that contact, which then takes you to your choice of touchable phone numbers, email addresses, physical addresses, web sites, etc. In the phone app's favorites list, touching any part of the element launches a phone call - except for the touchable blue arrow widget to expand it.

As a user, I would be surprised (and surprise is bad) if touching a specific line of text inside the tableview element did something different than touching any other part of the element. If you want to have a touchable email address inside the tableview, it might be wise to put a touchable widget next to it, such as the sharing icon:

Answer 2

Interesting question. Your AD is referring to the practice of making URL's underlined (or shown in blue in my browser at the moment, just to confuse matters) to imply that they are clickable like so:

www.example.com

This is easy enough on iOS, just use a UITextView instead of a UILabel like the following question describes:

How to add hyperlink in iPhone app?

As to whether the HIG allows for this or not, the easiest way to answer this is to refer to examples. For example, the Mail app allows for hyperlinks to be displayed inside the contents of an email for easy usability. So, your AD is probably correct in this case.