Noticed something confusing as I was reading a book on my Kindle app on my iPhone. Even though I was on page 229 of 263, the bottom of the app said that I was only done with 64% of the book. I did the math and confirmed that, according to my page position, I was actually done with 87% of the book.
Was this a bug? Well, not so fast. The other data point being displayed is location. And according to that metric, I was at location 3946 of 6164, which turns out to be 64%. Based on what I can see, it looks like the key difference between page numbers and location is that page numbers start and stop based on the actual book content while location includes everything — even the table of contents as well as the acknowledgments and index at the end of the book.
As a user, when I see the % complete statistic, what I really care about is how far I’ve come so far, and how much longer I need to go to finish the book. Thus, this metric should be based off of the page percentage and not the location percentage.
Noticed a bug in the Yahoo iOS Stocks App. When viewing the detailed metrics for individual stocks, the field for average volume is showing wildly incorrect values. Based on the examples included below, there doesn’t appear to be a pattern or obvious root cause to the problem (i.e. simply missing the M for million) as the numbers are all over the place.
One of my favorite features of Google Maps is routing using public transportation. This is extremely useful for anyone who doesn’t have a car. An interesting use case comes when a certain public transportation option is not available. Recently, BART, a highly utilized transportation system across the bay area shut down due to a strike by its union. So here’s what I saw when looking for directions into downtown SF:
After clicking through the orange warning exclamation point icon, I saw:
So here’s the interesting part. Based on the error messaging, the application should know (or should have a confident estimate) that this option is not viable for the user. Which is why the better user experience would be to include a different public transportation option in addition to, or instead of, all of the options that include a dependency on BART .
Noticed a bug while looking through my friend Joseph’s list of friends on Facebook.
Here’s what I’m shown first when I go to browse his friends. As expected, I see his list of friends sorted alphabetically and I’m shown the friends at the top of that list.
After scrolling through the list, I encounter one of my other good friends Tom:
…and I click through to view his timeline:
When I’m done viewing his timeline, I touched the “friends of Joseph” menu item in the top left section of the page. As a user, my expectation was to be taken back to Joseph’s friend list at the exat spot where I originally selected – namely the T’s where Tom’s name exist. However, I am taken back to the top of the list:
I was getting ready for a cross-country flight and decided to download a movie to watch. After I selected the movie and made the purchase, I was presented with the error message below.
This error state was quite the unpleasant surprise and exposed two potential points of improvement for this flow.
(1) I was allowed to make the purchase before I received the actual product. Ideally, the user would be warned that they do not have enough storage on their device to download the movie now so that he/she can decide to back out at that point. Getting the error message after the purchasing commitment opens the possibility of paying for something that you will not be able to consume now.
(2) Assuming the business case of letting the user get this far before warning them is more important than the user unfriendliness of this design, there is one way that this error message can be improved. The user needs to be told exactly how much extra storage is necessary to continue the download. For the message above, touching OK does nothing but take you back to the screen you were on, and touching Settings takes you here:
At this point, I had no idea how large the movie file was and how much extra storage I needed to free up on my device. Knowing that I had a back-up of my mp3s on my laptop, I just started deleting songs from my phone – one album at a time – and kept checking back into the download screen to see if I had enough free storage. This was a very manual process and finally at a certain point, I was able to start the download as can be seen below.
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.