Yelp User Photos: Mobile vs. Web

As mobile/tablet user experiences become more widely used versus their (archeological) non-mobile/tablet web counterparts, there may be a divergence of functionality for the same feature on the same site for the different platforms.

Consider Yelp user profiles and the corresponding user photos. In the iPhone Yelp App, I can browse to the user’s profile page and view all of their photos without being a Yelp member:

Image

However, when I try to do the same on my laptop, I see the following:

Image

Image

Here, Yelp is asking me to log into my account, or register as a new user in order to view this user’s photos. Not sure if Yelp is making this distinction between iPhone and WebApp on purpose or if this is a bug, but let’s assume it’s on purpose. They may be making the bet that users are more willing to register and/or login in the non-mobile web flow as compared to the iPhone App flow. Why? Most likely, the user has a keyboard in front of them and can get to the next step more quickly than using their touchscreen device to login or worse, register for a new site. It’s an interesting strategy, but one that will may yield a drop-off in logins or registrations as users flock from their computers to smart phones and tablets.

A (rare) Complaint About the iPhone

One surprising “feature”, for me, about the iPhone is that a password character is visibly displayed for a short amount of time before being hidden. The motivation behind this feature being that people are less used to typing passwords into mobile touchscreen devices. And since these passwords need to be 100% accurate (and there’s no nifty iOS auto-correct to save the day), the user is given assistance by showing, for a brief period of time, what they typed in. 

Here’s an example:

Image

I understand the motivation behind this functionality. What I don’t get is why there isn’t an option in the user settings in order to override this type of behavior. If I am willing to forego the extra added convenience of being able to type in the password and willing to trade it for the extra added security for someone looking over my shoulder, why shouldn’t I have this choice? 

The funny thing is that Apple itself doesn’t follow this pattern with respect to the iPhone unlock view. The numerical inputs are always hidden and never briefly lag on the screen for anyone to see:

Image

Gmail Send Button: Compose vs. Reply

I don’t know if this is a bug or a feature, but the “Send” button in Gmail looks different for the following two use cases: (1) composing a new email thread and (2) replying to an existing email thread. 

The key difference (which is obvious) is that the button is a solid red color. The other subtle difference is that the underlying text is all caps for the compose use case. 

I’m fairly certain this is a feature (and not a bug) and the reasoning behind this would be to bring even more attention to the call to action in the compose use case as compared to the reply use case. At first I thought this may be due to Gmail wanting to prevent users from drafting messages and “losing” them due to not sending, but I realized Gmail already has a nifty auto-draft-save feature that will save your composed or replied draft automatically. Either way, you’re not likely to type something up, close your browser, and lose it forever. Perhaps, the difference they’re trying to call out is that an email user has more to lose by not sending out an original message (and being delayed on that front) than not replying to an existing thread (and being delayed on that front). 

Compose:

Image

Reply:

Image

Amazon Shopping Cart

An observation and an idea for the Amazon shopping cart. 

One thing I noticed about the Amazon shopping cart is that their call to action for a user to remove an item from their cart is a link with the text: “delete”. I was expecting to “remove” but was surprised to see “delete”. I think this subtle word difference is done on purpose in order to discourage users from clicking on that link. As a user, I place a very negative connotation on the word “delete”. It implies that by clicking on such a link, you will cause a permanent change. The word “remove” is much more innocent and temporary. It’s much easier to bring something back when it has been “removed” than when it has been “deleted”. 

Image

So what happens if I click on delete?

Image

Interestingly enough, the confirmation text says that the item was “removed”. =)

Now, on to an idea for how to improve on the delete/remove functionality. As a user, I may have removed the item by mistake and want to immediately bring it back – an undo function. I’m surprised Amazon doesn’t have this. 

Here’s a concept mock of how it could look. By clicking on the undo link, the item is immediately brought back into the cart. 

Image

Update to Amazon Sign Out

In a previous post, I shared what the Amazon Sign Out functionality (or lack thereof) looks like. Today I see a new experience (not sure if this is their next redesign or if I’m in an experiment) that does include an explicit sign out. However, it’s not immediately visible on the page as the user has to hover their mouse over the account menu in the top right in order to see the sub menu with the sign out command. 

Image

Sign Out Pages

I did a mini-discovery of the “Sign Out” pages of some of the sites I often visit. This is the page the user sees after deciding to “Sign Out” or “Log Off”. The main purpose users perform this action is so that other subsequent users of the same computer do not have access to the original user’s personal and/or financial information.

First, I found it interesting that, from what I could tell, there are two naming terminologies to choose from for a site. Sign In / Sign Out and Log In / Log Out. I think I like Sign In / Sign Out more, but lets move on to the more important stuff..

For the site itself, the main purpose of the page can be to:

  • Give the user the ability to immediately enter the site again (Sign-In functionality on the Sign-Out page)
  • Take this opportunity to merchandise something to the user
  • Give the user a confirmation that they have indeed subsequently signed out

Let’s take a look at some examples.

WordPress, Facebook, and YouTube took the novel path of redirecting the user straight back to their homepages (this is why I haven’t provided any screenshots).

Chase communicates to the user that they have successfully logged off. I find it funny that they included the date too – not sure what the importance of this is for the user.

Image

Gmail uses this page to merchandise the service (Gmail) to the user. Not sure why they would do this as the user is already a user – maybe to garner even more loyalty? Also, Gmail has a button that the user can press to go back to the homepage to sign in again. I don’t like this approach as I don’t think this page adds anything that the Gmail homepage doesn’t already have. In fact, it doesn’t even have a sign-out confirmation message. All it does is add more more unnecessary step for the user to sign-in again.

Image

Twitter both confirms the sign out and takes a moment to encourage the user to use Twitter on a different platform i.e. Mobile. I wonder what their mobile sign-out page looks like. Maybe they encourage their users to try Twitter on a tablet or a “normal” computer?

Image

Finally, I saved the most interesting one for last. As an Amazon user, it is NOT possible to sign-out! Well, actually, this isn’t entirely true. It’s just that there is no explicit sign-out link. The user only sees two links referring to not being the user that is currently signed in. As a user, I find this annoying and confusing. Why can’t I sign out? Obviously, they do this in order to keep people from signing out.

Image

But the reality is, both of these links are in fact sign out links. By clicking on either of the “not so and so” links, you are taken to this sign-in page, and if you click back or go to the Amazon homepage, the original user is no longer signed in. Clever…but possibly annoying.

Image

Error Messages

Because of my current job, I’ve had to work a lot with how best to handle errors. For some errors, the root cause can be attributed to the user i.e. (1) the user needs to provide a specific (and correctly formatted) piece of data for the flow to proceed or (2) the user did something “wrong” (I use the word in quotes because the customer is always right, and we need to be careful when labeling their actions as wrong). For other errors, the root cause can be attributed to the software itself i.e. something went terribly wrong in the code and the user cannot proceed in the typical manner the user is used to (aka fatal errors).

My philosophy on errors:

Give the user three important pieces of information (if you can):
1. What happened? Explain, as concisely as possible, what went wrong.
2. Why it happened? Explain, (again) as concisely as possible, the root cause of the problem – in language the user understands (don’t tell the user that there was a Null Pointer Exception!!).
3. What next? This is the most important step. Explain to the user what they need to do in order to resolve the issue.

For fun, here is an example of a fatal error (from Facebook):