This content originally appeared on Hussein Al Hammad and was authored by Hussein Al Hammad
In Wait.. Am I the third party?, I referred to HTML email code as third party code. This is because the email client (first party) has to render code (HTML email message) written by a sender (the third party) for the recpient (second party - direct user of the app).
Why am I thinking about this again? Email messages may contain:
- dates
- phone numbers
- URLs
- email addresses
- physical addresses
Some email clients choose to auto-link these if found in the email message. A date would link to the default calendar app on the device. A phone number would be a tel link. An email address would be a mailto link. And so on.
This seems reasonable. The app is making it easier for their direct user to perform actions with fewer steps. They can quickly add a bill's due date to their calendar. One click and the support phone number is on their dial screen. They don't have to copy that physical address manually and paste it on Google Maps. You get the picture.
But senders of email marketing messages do not like this. They think of the recpient as their user too/instead. They want to be able to control what their user sees and what parts of the email message they can interact with. They want to choose how links are styled. This also seems reasonable.
However, what I don't see as reasonable is when senders not only want to control how links are styled, but when they also want to contorl whether the email client auto-links any of these. I don't think this is a good goal. The email client is trying to provide a good user experience to the user enabling them to perform certain actions with fewer steps. I don't think it should be the third party's decision to say "no, don't do that" and break the consistency of the email client's UX across different email messages.
Senders choose to break the email client's preferred UX by making text less accessible just so they can control the link style or prevent a piece of text from getting auto-linked.
On the other hand, email clients sometimes style links as if all email messages are only black-on-white (they aren't) and as if all languages can be styled the same (e.g. underline can impact legibility in languages like Arabic and Farsi).
And occasionally email clients would incorrectly auto-link things. Many social media handles include a dot . part way through and what comes after the dot can be a valid TLD. The email client may detect this handle as a valid domain and link to a site that does not exist or does not match what the sender is referring to.
Both the first party and the third party wants the user to belong to them. Each wants to control the UX. Each wants to control the styling. Each does things to cancel what the other does.
But, whose user is it anyway? That's irrelevent. The ultimate goal is to provide a good and accessible experience to the user. The way email clients and senders are handling this right now takes focus away from that goal and the engineering effort is instead put into tricking the other party's code to do what you want.
This content originally appeared on Hussein Al Hammad and was authored by Hussein Al Hammad
Hussein Al Hammad | Sciencx (2024-06-30T00:00:00+00:00) Whose user is it anyway?. Retrieved from https://www.scien.cx/2024/06/30/whose-user-is-it-anyway/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.