by Kathleen Henning
I received my Apple Watch this past Thursday. I chose the space grey Apple Watch sport with the black band, which was worth the wait. It’s fairly subtle, with one person (okay, a kid!) thinking it could be a real watch. Overall, I am impressed with its performance, especially for a v1 device with limited connectivity options. Powered by my iPhone 6, even on LTE instead of wireless, there is very little lag in most apps. However, the remote app has some issues connecting to iTunes libraries. It’s fantastic as a remote for the Apple TV, but very limited and challenging to sync with my computer’s iTunes library.
Performance at home is fantastic. I was able to leave my phone in my bedroom and wander all over my apartment with the watch. I made calls on it of durations between 30 and 40 minutes with no problems. I will say the speakers could be a bit stronger, though. It’s hard to hear people if they’re speaking quietly, or also on speakerphone. Messages and alerts come through in real-time, though. Pleasantly, if you’re interacting with an app on another device you do not receive an alert on the watch. While this makes sense, it isn’t true for the iPhone/iPad, so it was a great software addition that should come to more devices in the family.
I was deeply impressed with its performance in transit. Using Bluetooth, the watch is still connected to your phone so you can change music or get activity updates while underground with no cell service. Where there is cell service, it will push notifications to you. I was expecting the watch to be fairly useless while traveling, but that is certainly not the case.
It’s useful while at work. Again, the performance over LTE has few noticeable lags for any app, apart from maybe 5-10 seconds sometimes for NYT updates. The calendar alerts are fantastic. They pop up 10 minutes before your meeting and let you scroll through all of the meeting details. There’s even an option to email the meeting creator, which is the only email option I’ve seen on the watch so far. The dictation is good enough that I wish they allowed text responses to emails. It would be a really useful update. My biggest frustration while using it at work was when I went out of range for a meeting in a far conference room. I didn’t bring along my phone because the watch was a great substitute, but it didn’t alert me as I was exiting its range. Some sort of notification would be helpful, as it’s challenging to gauge distances, especially inside buildings.
The messages app is delightful to use. Being able to dictate messages makes it extremely functional. However, the feature could be improved by making it easier to edit these messages. I’ve definitely found myself canceling messages and re-dictating them due to one or two incorrect words in places that would make overall comprehension challenging. I would also like to be able to send the messages without having to touch the watch. There currently isn’t a verbal command that lets you send a message. Despite these usability challenges, I still found myself sending the majority of my text messages this weekend using the watch. It’s the easiest way to send text messages I’ve seen so far, though it would definitely be improved by easier (or any!) editing capabilities and a way to send without touching it.
Email is surprisingly functional on the watch. Initially, I assumed it would be just notifications, but you can scroll through the entire email. Not everything renders on the watch, especially graphics, but you can see the entirety of provided text, which is very useful. My biggest pain point when using the email feature was how difficult it was to delete emails. When I clicked on a notification, I had to scroll through the email to get to the delete option. In your mailbox you can swipe for a trash option, but as a notification that only gives you the option to clear notifications. Being able to delete from the notification without scrolling through the whole thing would be a useful addition.
My largest gripe centers around Apple Pay. Figuring out how to add a card to the watch was NOT intuitive. It kept directing me to my phone, but I assumed it was the regular Passbook section. I tried re-adding my card, but it didn’t let me. I had to Google how to do it to find out it was in the Apple Watch app on my phone. Even then, I had to re-verify my card for the watch by calling my credit card company. When I tried to use it at Whole Foods by tapping the button twice it kept telling me it was ready, but ultimately it was unable to make the payment. Obviously, this was pretty frustrating. I ended up using my phone. Seeing as the watch is likely one of Apple’s best chances at making Apple Pay catch on, it’s a shame this was the least intuitive watch experience I had all weekend. This experience should definitely be improved. The Apple Pay on-boarding would have been easier with a diagram clearly illustrating where to go on the phone. The BEST solution would be letting me choose on the watch whether to add the credit cards from my phone. I don’t see why I need to go through the phone. I’m not sure why it doesn’t work in stores, but that’s definitely a huge issue that needs to get fixed.
The native activity app is interesting. I’ve given it a small amount of information and it’s been making attempts to inspire me to greater efforts. I personally am not a super active person, but what I like about the activity app as it exists currently is that it works with you. It’s not being overly critical or alerting me too frequently, both of which would result in me turning it off. It’s sitting there in the background letting me know when I’ve hit a goal or reminding me when to stand up. I don’t listen to every stand reminder, but I’ve listened to more than I’ve ignored. I’m curious to see if it changes my behavior over time. It’s definitely a much better way to interact with this information than the Health app on the iPhone, which I’ve always found oddly buggy.
Of the 3rd party apps I’ve interacted with so far on the device, I’m most impressed with the New York Times app. They’ve done a wonderful job of creating a new kind of article specifically for the watch. Some articles feature just a headline, some have pictures, and some have 1-2 sentences. It’s a fun surprise to scroll through them a few times a day. I do hope in the future it’s possible to read full shorter articles on the device, but I understand their choice and think it makes a lot of sense for the watch that exists today. 95% of my interaction with the NYT iPhone app is through notifications, so NYT on the watch is an ideal match. Now I actually get more information with the brief articles and images. I prefer the tablet for actual reading, but again I would be interested in having a more email-like experience for the NYT.
While I was initially unimpressed with the battery life, it was fine over the weekend. It does drain my phone battery faster, BUT it means I’m spending significantly less time on my phone so that evens it out for the most part. Like all Apple devices, I would appreciate a longer battery life, but I will say it survives a 12-hour day much better than the iPhone. Having the two devices has made it possible to have weekend days without airplane mode or constant recharging. Speaking of charging, I wish it were possible to wear the watch while charging it. One of the best use cases for me so far has been using the watch to act as an Apple TV remote. I do most of my Apple TV watching at night, so it would be great to be able to plug it in and continue using it. I’m also curious about the watch’s potential as an alarm, given that the taptic feedback might be a more pleasant way to wake up.
At this stage, I would rate the Apple Watch as a ‘nice to have’. If you, like me, own the whole family of devices and upgrade pretty regularly, go for it. It’s an awesome addition to the family, and you’ll find a lot of unexpected uses for it. I think it needs to be able to stand alone, ideally by v2. However, it’s still challenging enough to use that I wouldn’t recommend it to my parents just yet. I do think it will get there, and I will definitely be keeping mine and not returning it. Its best uses for me are: messaging, Apple TV remote, email, and keeping me off my iPhone (supposedly the #1 secret purpose). Those are important enough things in my life that I find value in a device that improves my access to them.
Note to Apple: I would be happy to put a $5 data share plan on it so I could leave my phone behind while at conferences, meetings, bars, parties, etc.
Last month our CEO and Founder, Ania Rodriguez, joined the South Florida Interactive Marketing Association to discuss “Optimizing User Experience for Conversion”. She joined other panelists from Ion Interactive and HiConversion. Top takeaways from the event:
– You can find 80% of the issues with only 5 users
– Eye tracking can detect if call-to-action size and color make a difference in your conversion results
– Strong colors attract the eye, but if there is too much competing for the eye’s attention the people can get overloaded
– Do not put a search bar under the mega menu button or it will get lost and decrease your conversion rate
– Test and embrace user experience design to continually improve, solve and remain relevant in your space
– One great tool for quick usability test: KlueMobile
by Kathleen Henning and Phil McGuinness
In part two of our series on mobile payments, Phil and Kathleen review a few exciting mobile payment options and talk about the near future of mobile payment technology.
Phil: In part one, Kathleen and I field tested the PayPal and Google Wallet apps, two popular forms of mobile payments. However, there are a few up and coming forms of payment that take a different approach to the process.
Due to an unfortunate coincidence, the company ISIS is in the process of changing its name to Softcard to avoid sharing its name with a militant terrorist group. However, that’s not the only obstacle facing Softcard. While Google Wallet restricts the use of Near-Field Communication (NFC) payments to Android, Softcard is bringing these payments to the iPhone as well. In order to do that, users need to make a one-time investment in a special phone case (minimum of $50).
Requiring users to invest additional money to make payments creates a difficult barrier to adoption, especially when NFC payments aren’t yet accepted on a widespread basis. Softcard does, however, address one of our gripes about Google Wallet. It allows users to search for local stores that accept NFC payments. The app also boasts numerous security features on their site, including a PIN entry required before each purchase, the ability to freeze your wallet remotely, as well as using unique transaction IDs for each payment.
Instead of relying on NFC, consumers have another option in LoopPay. LoopPay gets around NFC by imitating credit cards in a way that allows the familiar credit card readers to get the signal. This allows LoopPay to work in almost any store, using the technology that’s already in place. As with Softcard, though, this also requires the user to make an initial investment. At this time, Loop Wallet provides the option of a reasonable $39 for a key fob, or $99 for a charging phone case and key fob.
As NFC adoptions treads water, LoopPay is an interesting alternative to watch. At the time of this writing however, Apple is expected to announce NFC as a standard in the iPhone 6, which could change the field dramatically. Kathleen, our resident Apple expert, will break down the rumors and implications this could have later in the article.
Another interesting option in the mobile payment field is the Coin Payment Card. This works similarly to LoopPay, but instead of requiring a fob or charging case, users can store their cards in a credit card-shaped item and switch between them at the tap of a button. This has the added benefit of removing any questions of NFC adoption or security concerns with wirelessly transmitting credit card information. In addition, it provides the comfort of a payment process with which both users and vendors are familiar. There is no need to fumble with a mobile app or worry about having mobile service if you can simply hand a card to a waiter or cashier.
Another neat feature unique to this system is added security through a Bluetooth tether. Coin uses a low-energy Bluetooth signal to connect with your phone, which will then alert you if you get too far away from the card, say by walking away from a shop and leaving it on the counter. So what’s the downside? Again, users need to invest in the card, and right now it is still in the crowd funding stage. Early investors can buy the card for $50, and once it’s released it will retail at $100. If somehow Coin can manage to bring the price down, I could see this being widely adopted by consumers interested in both familiarity and security.
Now, Kathleen will talk about Starbuck’s success with mobile payments and Apple’s likely upcoming adoption of NFC in the new iPhone.
The best part of the Starbucks app is how little effort it involves. Once you enter in your gift card number and the 8-digit identifying code on the back, you’re good to go. You can add money via the app, set it up to automatically reload when running low, and even add it to iOS’s Passbook. Using it in the store is a seamless process. Unlike some of the other apps we’ve tested, it just works. You don’t have to think about it, and since the store has integrated it on their end paying by app is as natural as paying by credit card. This too works independently of NFC capabilities.
Starbucks in Korea has a new feature called Siren Order. Customers can enter in their order details and receive a QR code, which is scanned by baristas at the counter. Starbucks is thinking about rolling out app preorder capabilities in the US in the next three to six months.
As of September 8, 2014, Apple has entered the mobile payments field with Apple Pay. As of January 2014, 42% of smartphone owners in the US own some model of iPhone, many of these older models. Apple Pay will work on the iPhone 6, the iPhone 6 Plus, and the Apple Watch. Users will scan the front of their credit/debit card, enter the CVV, and be able to make payments. Apple will generate a unique code each time a user wants to make a payment. This will work in physical stores, online, and in apps. Merchants like Starbucks, Whole Foods, Duane Reade, Disney, Bloomingdale’s, and Uber are already signed up. American Express, Visa, MasterCard, and most major US banks are currently participating on the credit/debit card side. I look forward to seeing how this transforms the mobile payments process, hopefully for the better!
Personally, I’m optimistic for a trickle down effect to smaller merchants by next summer so it can be available at Smorgasburg and Governor’s Ball. A lot of the payments systems we’ve showcased are promising, but none of them have gained widespread adoption. I’m hoping Apple’s entry into the market will change this outcome.
by Phil McGuinness
A hot topic right now in mobile user experience is the debate between providing an HTML5 web app versus a more traditional Native OS app. Simply put, HTML5 is a method of programming a mobile website to behave like an app (think m.youtube.com) which can be accessed through any modern tablet or smartphone browser. Conversely, apps written for a Native OS are developed to run directly on Android or iOS smartphones (they are designed for each native platform), and must be downloaded through the GooglePlay Store or Apple App Store. Both approaches are a great way to provide web content to smartphone and tablet users, and they each have their own strengths and weaknesses. Which of these approaches is right for your business? At Key Lime Interactive, we are exploring this question in depth, and have key information to help you make the right decision.
From a development standpoint, HTML5 is the clear winner in both cost and flexibility. If your business has a website, it’s a given that you already have programmers on hand who can write HTML5 code. In addition, your programmers will only have to program the basic code once. Of course, during QA testing some minor edits will need to be made in order to support different browsers and browser versions in the marketplace such as Chrome, Safari, Explorer and more. It’s also important to note that since your code lives on the web rather than on a user’s device, you can make changes on the fly without having to roll out a new application update via an App Store update every time you make a change.
If you decide to make a Native OS app, you will need to hire a team who know the specific language for each operating system, or a jack-of-all-trades programmer who knows all of the relevant languages. These programming skills are much less common, and therefore, can be more expensive, than HTML5-only developers. In order to provide a robust and compelling experience for each OS, you’ll need someone who understands the nuances of each platform. This requires a developer who can write for each operating system, and that’s no small task. If you decide to go the path of a a Native OS app then you’re developing for both Android and iOS and that means you’re now doubling every step of the cycle, including programming, testing/QA, and maintaining the code. When it comes time to update your apps, you’ll also need to release an update two versions via the GooglePlay Store or the Apple App Store.Publishing via either store requires approval before your app can be made available for download.
So why use the Native OS app approach at all you might ask? It sounds expensive AND time consuming. We would submit that developing for a Native OS platform is the right choice. This approach excels at something that we at KLI hold near and dear to our hearts: you guessed it, user experience! Currently, an HTML5 mobile site compete to a Native OS app in look, feel, functionality, and overall speed. Of course, Android and iOS platforms have quirks which make for a unique user experience on each device but the robust and rich UX is worth the price of admission. See our previous article for a detailed discussion about how Android users can be alienated by seemingly insignificant design choices. When building an HTML5 web app to be standardized across all devices, you lose the custom feel ofa Native OS app.
The functionality advantage for Native OS apps comes partially from a better support system – not only from Apple and Google – but from the online community of app programmers – and also from the apps being installed directly on the device. This allows easy access to smartphone features such as the camera, calendar, or contacts. HTML5 web apps are starting to add these functionalities as programmers begin to develop clever new approaches, but equivalency is a long way off at this point in time. Finally, it is well known throughout the industry that the HTML5 web apps react significantly slower than Native OS apps in both UI and load speed. These factors combine to create a smoother, faster, and more intuitive user experience for a Native OS app.
The other main areas differences between these two approaches relate to security, monetization, and accessibility, which will vary in importance can be depending on what you want from your app. Native OS apps have better security since the code and URL strings are not accessible like they are in an HTML5 web app. If you happen to want your app to be accessible online, you’ll need to stick with Native OS. To rely on an existing app store for monetization, you’ll need to either build a Native OS app, or use a program like PhoneGap to “wrap” your HTML5 web app to make it appear as an app in the app store that users can download, although it only behaves as a link to the web app itself. Of course, selling your app through an app store means giving away a cut of the profit to the owner of that store/ HTML5 web apps allows you to create your own monetization strategy and avoid the App Store fees.
In conclusion, it takes careful consideration of your business, and knowledge of each approach to make the right decision for you. Do you need a less expensive, low-frills, dynamic experience? If so, an HTML5 web app would be the best approach for you. However, if your major concerns are usability, performance, and security, and you have a little room in your development budget, then a Native OS approach is the way to go. In our opinion, until HTML5 can catch up to the user experience provided by Native OS apps, enterprise companies will almost always want to represent themselves with Native OS apps for the enhanced usability and unparaelleled user experience. In the coming months, Key Lime Interactive will be conducting a study to measure the current user experience of HTML5 web apps, so stay tuned for more detailed information in a future newsletter.