Noticed an interesting change from Safari 5 to Safari 6 in OS X. In the Safari 5 header, there are two text entry modules: one for the URL, and another for a search query.
In the upgrade to Safari 6, the two separate fields have been combined into one that serves as both the URL entry as well as the search module:
Some things that come to mind:
1. Looking back at the history of the internet over the last 20 years, there was a moment where Search got really big. What I mean by this is we reached a point where the majority of users who came to the internet initiated their session by searching for something. Very recently, say in the last 3 years, with the boom of mobile apps, there has been a shift away from search as the starting post and more toward apps as the starting post for the user. What I found interesting is that this browser change pushes the user just slightly back toward the direction of search as a starting point.
2. Apple vs. Google. It’s an open secret that Steve Jobs was not particularly fond of Google toward the tail end of his time at Apple. While initially Apple and Google had some partnerships i.e. Google Maps and YouTube being two of the very first native apps on the iPhone, the relationship between the two companies went sour with the heavy investment of Google into Android. Just recently Apple has received a lot of negative attention by creating their own version of Maps for iOS instead of using the already beloved Google Maps app. So in this angle, it is very strange to see Safari, an Apple product, make it much easier for the user to use Google.
3. Web vs. Mobile. While this change has been incorporated into the web version of Safari, the iOS version of Safari remains the same with two separate fields. This is interesting for two reasons: (1) Apple has created an inconsistent user experience across different platforms OS X vs. iOS and (2) It is strange to see two separate fields in the UX for the platform with extremely limited screen real estate. If anything, one could make the case that there’s more justification in the web flow to have two separate entry fields due to an incredibly wider screen than a mobile view which has a much smaller screen width.
Google Voice is a service from Google that gives users a phone number that’s not necessarily tied to one particular phone (or piece of hardware in general). Today, I got the following email from Google notifying me that some action is required by me to keep my account up and running:
What got my attention about this email is that the next steps I had to take in order to verify my account were not entirely clear to me. Consider the following passage:
If you’d like Google Voice to continue forwarding calls and texts to this forwarding number, you will need to verify it by November 21, 2012. If you no longer own this phone number, please remove it from your account at https://www.google.com/voice#phones.
While it’s perfectly clear where I should go to if I wanted to remove the number (the link shown above), I have no idea where to go if I wanted to continue using the number. In the ideal user experience, the user will either see:
– In order to verify your account, go to <link1>. In order to stop using this number go to <link2>.
– In order to verify your account or to stop using this number, go to <link3>.
In an earlier post, I wrote about null search results as they pertain to a couple of news sites. Today, I noticed a sub-optimal user experience in the OpenTable iPhone app when I searched for a restaurant that was not found. Here is what I saw:
While it does make sense, to a point, that restaurants that are not part of the OpenTable network be omitted from the search results, this is certainly a missed opportunity and can be improved. Before outlining a different user experience, lets take a quick look at what the Yelp app shows for this restaurant:
In the Yelp search results, we are able to find the restaurant we’re looking for along with a list of other restaurants that are similar. Furthermore, in the Yelp restaurant page, we see some important pieces of information pertaining to the restaurant. And this leads us back to how OpenTable can improve their user experience.
At the very least, they should have a record of the restaurant and some important information pertaining to the restaurant i.e. address and phone number. With the phone number, the user will have the option to Call (similar to Yelp above) and get in direct contact with the restaurant in order to make the reservation.
Looking beyond the restaurant information, another feature that may be beneficial is to add a list of several restaurants (that are in the OpenTable network!) that would be suggested to the user instead. With the current user experience, the user is stuck, can’t make progress with the restaurant they’re looking for, nor are they pointed toward the direction of another comparable restaurant.
Much has been said about how important it is for Facebook to successfully monetize in the mobile space. Advertising in an app is a double-edged sword that yields seemingly free money on the one side but may lead to long-term disengagement from users. At the end of the day, deciding on the amount of advertising in an app requires a very delicate balance to be maintained.
Today, I saw something in the Facebook iOS app that was definitely not balanced:
In my opinion, this experience as bad for the end user for two reasons:
- The entire screen of the user’s view is taken up by ads
- This was the first thing that was shown upon entry into the app
In an ideal user experience, there would be some smarter logic that would spread out ads across the different news feed stories so that the user is never bombarded with so many ads at once that they don’t get anything resembling what they were looking for in the first place.
Assistive touch is a feature in iOS that lets you enter multi-touch gestures using just one finger. This feature is off by default and can be enabled via the iOS settings. Here is what assistive touch looks like in the iPhone:
Recently, I discovered a bug with assistive touch that does not let the user get to Siri from the assistive touch menu while simultaneously in the “multi-tasking” view. Here are the steps to reproduce the bug:
1. Double click the iPhone home button in order to enter the multi-tasking view
2. Touch the assistive touch icon on the screen in order to also enter the assistive touch view
3. Touch the Siri option
Nothing happens – user is not shown Siri. User sees same screen as step (1) above.
User is shown Siri
One thing I like to do on my iPhone is to take an image which is sent to me via MMS (basically text messaging but for images or videos A.K.A. “multi-media messaging service”) and send it to another friend. I recently noticed that the process to do this rather simple exercise can be improved. Here is an example of an image that is sent via MMS:
By clicking on the top right menu, I see the various options available:
What’s interesting is that there is no option here to forward this image via MMS to another user in my address book. What I end up doing is selecting the option Save to Camera Roll and then going to my camera roll to select the image:
By selecting the menu button in the bottom left corner of the screen, the user is shown the following options:
As can be seen above, the MMS option is available only after saving a local copy of the image to my camera roll. Ideally, this should not be a prerequisite and the OS should have the ability to let me send an MMS of the image directly from the text message view I was previously inside of. Worst case scenario, the OS can keep a local copy of the image and then delete it after the message is sent. By requiring this extra step, the end-to-end process has become more challenging.