Seems like everywhere you look these days, users are given an opportunity to share something via Facebook, Twitter, Google+, LinkedIn, Digg, StumbleUpon, and the list goes on an on. While it may be a bit overboard to offer sharing via so many different channels, offering sharing across Facebook and Twitter can be quite beneficial to a product.
One area where sharing would be a logical fit would be across content sites such as espn.com. On their mobile site, they have a video module that typically had 3 videos that can be selected to be viewed.
After clicking through, you are usually shown an ad and then the video.
When the video concludes, you are taken to a video center page that shows you what video you just watched and asks you if you want to watch any more videos.
At this point, this would be a GREAT opportunity for ESPN to offer the user the ability to share the video via Facebook or Twitter. This is no different than ESPN asking users to share articles via social channels. Except such a medium (video) may even have a more effective conversion rate of bringing new users back to the site.
Noticed a bug in the Twitter web flow when a non-signed-in user attempts to view another user’s Following list. For example, I was attempting to view the list of Twitter handles that Bill Simmons follows.
Steps to reproduce:
1. While you are not signed into your own Twitter account, go to a Twitter page and click on the Following module:
2. At this point, you will be redirected to the sign-in flow. Presumably, this is because Twitter doesn’t want guest users (not signed in) to view this information:
3. After sign-in, you should be redirected to the user’s list of handles they are following. However, you are incorrectly redirected to your own Home feed:
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.
Twitter has cemented itself as the platform in which the greatest amount of publicly viewable micro-posts (or just posts in general) exist. One cool aspect of this seemingly infinite supply of real-time user content is the ability to search for real-time tweets reacting to a recent event. So while Google can serve as (or attempt to) the search engine for the entire Internet, Twitter can serve as the search engine of worldwide real-time reactions to a current event.
The interesting thing about this amazing functionality is that the use of this search feature is not supported from the home page: www.twitter.com. Here’s what the home page looks like as of today:
Amazingly, there is no search bar at all in the page. Not in a prominent location in the center, nor is it on the header. The only reason one comes to know about the search bar in the first place is via it’s existence on a specific user’s profile page, such as:
So why is Twitter doing this? Some possibilities:
1. Product miss. They don’t know that offering this functionality on their home page would lead to more user engagement and the opportunity to acquire non-users and convert them to new users.
2. They are doing this deliberately. The intention is to point existing users to signing into the home page, and for new users to sign up. These two user actions are critical and having a search bar (large or small) would lead to a distraction for an existing user or for a new user.
Recently, Twitter rolled out some subtle, but effective, changes to its mobile web header. Here is the previous version. The top left has a button that will take you to the Twitter mobile home page. This button consists of the previous bird logo (facing forward) and the Twitter name spelled out. “Sign in” and “Sign up” are the two buttons shown on the right. “Sign up” is the main call to action as highlighted by the yellow button background.
Here is the new version. The home button in the top left has changed to the new logo (with the bird facing upward) and the Twitter name has been removed. The radical change to the right hand side is that the “Sign up” button has been removed and replaced with an “Open the app” button.
I like these changes. First, changing the home button to take out the Twitter name makes the header cleaner. As mobile web real estate is limited, anything that can be done to make the look cleaner and less noisy for the user is a plus. The other side product of making the header cleaner is that users can focus on the two phrases on the header: “Sign in” and “Open the app” — instead of having a third phrase/word to read across the top.
The net result for the “Sign in” function did not change — as the treatment is identical in both versions. However, by replacing “Sign up” with “Open the app” Twitter may be sacrificing potential user registrations for a gain in iPhone App downloads and usage. This is hardly a trade-off as most iPhone users know that if they really wanted to sign-up, they could do so through many channels (i.e. going to twitter.com on their mobile device, clicking on the home button in the top left, or even through the app itself). Also, at this point, Twitter knows that since the adoption of its product is much further along than say a year ago, they can shift user behavior to different ways of using the product (i.e. mobile app over mobile web) as opposed to getting to use the product in the first place. With hundreds of millions (and counting) of registered users, they certainly don’t have to place an emphasis on user registration.
After signing into LinkedIn, you are taken to a personalized Home page. At the top, similar to Facebook, you will see a status update share module. In the bottom right hand corner of the module, near the Share call to action, you will see a checkbox to share the same status on Twitter.
If you are using this feature for the first time, you will be taken to a page hosted by Twitter that asks for your Twitter credentials and permission to have the LinkedIn web app post to your Twitter account:
By clicking on the Cancel, and return to app link, you are taken back to LinkedIn, but you are shown the following unnecessary error message:
The correct user experience would be to either show one of the following:
1. An informational message upon returning to LinkedIn
2. Not showing any informational or error message upon returning to LinkedIn
Noticed an interesting error message when going through the Twitter registration flow on the Safari browser on the iPhone.
Let’s start with the main Twitter landing page shown when the user goes to http://www.twitter.com:
When you click on Sign up, you will see the registration page:
Here’s the interesting part. If you leave all of the fields empty and click on Sign up, you will see the error messages for each field that you did not properly fill out.
All of the error messages make sense, except for the first one that is shown if the user does not enter their name. The text content is: translation missing: en, settings, name, hint
It’s pretty clear that instead of showing the correct error content, the app is showing some “code” content most likely from a configuration file. In this case, my guess would be that “en” refers to the English language, “name” refers to the text field for the error message, and “hint” refers to the name of the error content field that needs to be served to the user.