As 2023 winds down, there is nearly constant discussion around AI changing our world. But my interest currently is in a technology that's decades old. That might seem backwards but there is a method to this madness. First, the technology in question:
Short Message/Messaging Service or SMS (commonly referred to as "texting") has been around since the early 90's. On the surface, it's an incredibly simple and boring technology. That's kind of the point, after all. Early devices weren't powerful, so a mobile messaging service had to be barebones. SMS has evolved into iMessage, WhatsApp, and Google Messages, but the technology behind SMS has hardly changed.
Phone numbers are often collected when signing up for services. They're becoming a staple in online user profiles - whether for authentication or communication: notifications, marketing updates, and product status updates. Over 30 years later, SMS messages are still used by just about every large company in the world.
But why?
- Cost: Depending on service provider and plan, a few cents per message. Less in some instances.
- Simplicity: Content is limited to text, emojis, links, and (occassionally) images.
- Reach: Metrics vary but there are about 7 billion mobile phone users (~88% of the world's population), and nearly every one of those phones is capable of receiving SMS messages.
- Effectiveness: 98% open rate, and 90% of SMS are read within 3 minutes of delivery (Source: Twilio)
With such a widely used technology, I figured there must be an industry leading tool to check how text messages will be formatted. But, I was wrong.
While there are a number of services that allow you to send text messages to customers, none of them provide an exact representation of the formatting that users will see when the message gets to them. The previews provided are often abstracted phone displays with some semblance of chat bubbles shown. Even when an actual device is shown, the formatting of the UI itself is incorrect, and there are no options to change the device, font size, operating system or appearance (light vs dark mode). To be generous, the current tools are lackluster.
When you're paying for every message you're sending, you should know precisely how they're going to appear to your recipients. With different screen sizes, font sizes, appearance settings and operating systems, how your message will look when the recipient receives the message can vary greatly.
Seeing this problem as an opportunity, I figured, "Why don't I just create this application?"
I'm first and foremost a designer. Over the years, I’ve taught myself to code well enough to build out my design ideas. I started, as many do, with creating static websites (like this site you're currently browsing). Working at a variety of startups, where there was either a small development team, or just one developer, I found it helpful to be able to show how the UI designs should be implemented. At some companies, I was “just a designer”, while at others I was actually coding the UI myself.
Like anything you do for long enough, you reach a limit. I enjoyed creating the UI, but I felt like I wasn't really making the product - because I wasn't. I was making a (very important) piece of it. I wanted to create the whole thing.
I've created some basic applications, but all of them used static data, and didn't interact with other services. They were standlone applications set out to do a single task. Good for learning, bad for immersive user experience.
The challenge with this application I'm going to build will be to allow users to create accounts, and manage different settings for the best user experience. Later on, there will be other features I haven't even begun to plan just yet, and that will be an entirely new challenge to figure out how to build.
The initial version of the application will be web-based. There are a few reasons for this:
- Instant Updates: I can push new product features and bug fixes nearly instantly (a few minutes for the application to be re-built). No app store approval delays.
- Lowest Barrier to Entry: Users don't need to install/download anything. They can click on a link/type in the web application URL and instantly use the application.
- Larger Screens: The planned experience will work best when using larger screen sizes, which are more typically available to web users. Even large tablet screens aren't very big when compared to laptops and external monitors, and the larger the screen the better for an experience that will simultaneously display different devices.
- Wider Reach: Designing a web application will make it possible for users of all connected devices to preview multiple phone previews simultaneously.
- Speed of Building: While I have some experience with Objective-C and Swift, I have far more experience with HTML, CSS, and JS frameworks, which will make building the first version of the application much easier.
I'm not sure what I'm getting myself into. But it'll be fun. I hope.
If nothing else, it'll be educational.
