Noticed a strange bug when searching for a business page on the Facebook iPhone App. Even thought I had previously liked the business, the search results still displayed a hollowed out thumbs-up icon that indicates I have not yet liked the business. Here’s how to reproduce the bug.
1. Start with a Facebook Page you’ve already visited and liked. Search for this Page in the iPhone app:
2. Just in case you haven’t liked it yet, double check, and press down on the empty thumbs-up icon to like the page again:
3. Visit the page and confirm that you have liked the page:
4. Touch the top level menu to search again. Here you will see your previous search query correctly displayed in the liked state:
5. Then, clear out the search box:
6. Finally, search for the same page again. Now, you will see the page displayed again, but it is displayed incorrectly as if it is not in the liked state.
Noticed a recent change in the latest FB iPhone App which was presumably done for the purpose of increasing user engagement with stories in the news feed. Before the change, here is how a sample story would look like:
As shown above, the Like, Comment, and Share calls to action are displayed as simple word links. In addition, the number of likes and comments for the story are shown in a similar treatment with the same amount of prominence and with the same color.
With the most recent iOS FB app update, here is how this component looks like:
So what changed?
- The biggest change is the change of word links as the primary CTAs (call to action) to using buttons with icons as the primary CTAs. This is a very huge and radical change. One well-accepted best-practise of conversion for site/app flows is the usage of buttons instead of text links and another best-practise is the usage of icons instead of just words. Here, Facebook is adding two very important components: both the conversion of the word to a button, and the addition of the corresponding CTA icon.
- In terms of overall screen real estate, the primary CTAs are taking up more space. Also, the component that conveys the amount of likes and comments has increased in size. Instead of showing the amount of likes and comments next to their corresponding icons, they are now shown next to the words Likes and Comments.
Is this a good idea? Will this feature succeed?
On the surface level, this is certainly not one of those cases where one design is obviously better than the other. Rather, FB will just simply A/B test this feature and see which design yields a higher level of engagement. What’s interesting about this before and after is that the before had a more prominent display of how previous users had engaged with this story (i.e. the amount of likes and comments) and thus this would increase the probability of the current user wanting to get involved and like or comment. And in contrast, the new design is leaning more toward making the primary CTAs more prominent and more appealing-to-be-clicked instead of relying on the social pressure of the statistics of the story.
Safari on the iPhone offers users an option to enable private browsing. If you enable this setting, the browser will stop tracking your web history, your search history, as well as other user inputs such as usernames and passwords. Here’s how you enable the setting in iOS 6.0.1:
Today, I noticed that if I go to a user’s Twitter page while this setting is enabled for Safari mobile web, Twitter simply does not work. Here’s what the user sees in iOS Safari with private browsing enabled when the user goes to mobile.twitter.com/BillSimmons:
Essentially, the user sees a blank page with nothing in it. The expected result can be observed when the private browsing setting is disabled:
I really can’t think of a good reason for the Twitter mobile web experience to stop working correctly if the browser is in the private mode. Perhaps something having to do with cookies that Twitter is trying to manage on the user’s device and an error leading to nothing being shown. But either way, this is a predominantly read-only view and should be shown without issue to the user in either browser mode.
Discovered another case of a disparity between a product’s iPhone app and the same product’s Safari mobile web app on the iPhone. I was browsing for some books on the Amazon iPhone app and was curious to see what the Amazon Sales Rank of a particular book was. Everywhere I looked in the product description, I was surprised to see that I could not find it. So I turned to the mobile web app to see if it existed there. Lo and behold, I found the sales rank in the product details section of the mobile web app product page:
Then I returned to the iPhone app to see if I could find it in the same section. Surprisingly, I found the same section with all of the same pieces of information for the book, except for one: the sales rank.
I’m fairly certain that this is a bug and that if Amazon has made the decision to show this piece of information to the user in the mobile web view, there’s no reason not to show the same information in the iPhone app view. Especially since they are showing all other pieces of information (i.e. ISBN numbers, number of pages, shipping weight, etc.) in the same Product Details view.
Recently, while I was going for a walk, I saw something really cool that I wanted to use as my new Facebook cover photo. I took a photo of it with my trusty iPhone and then went to my profile page in the Facebook iPhone App, ….., and then I was stuck. As far as I could tell, there was no way to update my cover photo directly from the iPhone App. I tried left swipe, right swipe, holding down on the cover photo, touching the cover photo, but to no avail…
Here is what the profile page looks like in the web view. On mouse-hover, the user is presented with a Change Cover button in the bottom right corner of the current cover photo. Ideally, the iOS app should be modified to allow the user similar functionality. Possibly on touch of the picture, or hard press down, or even a tiny button in the bottom right corner in a similar manner as the web view.
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.
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.
As an iPhone user, one common user activity is to watch a video. While you’re watching a video, there are very few things that could occur that would justify the phone stopping the video and grabbing your attention. An example of something that would justify stopping the video would be an incoming phone call.
I noticed an example where I did not appreciate the phone stopping the video. This occurs when the phone is running low on battery. If the phone reaches 20% or 10%, you will see a dialog alert like this and your video will stop mid-stream:
I do recognize that it is important for the OS to get the user’s attention for this use case, but I think there’s a better way of doing this. To explore a better way of doing this, we can look no further than the iOS update to how text messages are treated. Previously, text messages in iOS, would be shown as a dialog alert just like above:
As of iOS 4.0 (or was it 5.0?), text message alerts are not as intrusive and can float to the top of the page:
So the idea for this enhancement would be the same. If the user is watching a video, simply show them an alert but have it exist in the background with a dismiss button. This way, the user can continue to watch the video without being interrupted and know that their iPhone is about to run out of battery.