Monday, February 3, 2014

Hulu: The Banality Of Video Streaming Services

The Daily Show featured an enticing interview recently. I missed the original broadcast (as I don't have cable TV). So, I watched it on Hulu Plus, a service costing me $8/month for the privilege of watching Hulu content in HD over Chromecast.

Just as the interview is getting interesting, Jon Stewart interrupts himself and does something rather shocking: he turns to face the camera and utters "for the rest of this interview, please go to thedailyshow.com." The video clip then ends abruptly, mid-interview. This left me asking one question...

"Why am I paying $8/month for a service that instructs me to fetch my content elsewhere for free?"

I went to their web site and tried hunted through a massive library of clips. After a long search, I found the particular clip I was looking for. I watched it on my laptop instead of my TV, with ads, at substantially reduced resolution and quality. Even this degraded ("to degrade" is a verb used in the software industry when one thing fails and another worse thing takes over)  thedailyshow.com experience could have been vastly more satisfying had it launched automatically, immediately following the end of the truncated Hulu clip. I would have gladly accepted a specific URL pointing directly to the video, conveyed over any imaginable medium: SMS, email, or Jon Stewart's mouth. But all we ended up getting was "thedailyshow.com".

Why had this happened? It was clear to me that Hulu was fulfilling its objective of faithfully rebroadcasting a TV episode, as originally aired on TV. But, my intention was not to watch the episode, but rather to watch the interview. I made that intention clear in my user-product relationship with Hulu. The TV episode and the interview itself had been presented as two distinct entities in the user interface. I had explicitly selected to watch the latter. My clip began with the beginning of the interview, yet ended with John Stewart abruptly cutoff by a completely irrelevant artifact from the episode's original editing. This left me with the impression that Hulu does not care for the user. It seemed as if they were neglecting to assure the quality of its video content. Or, more specifically, they were just neglecting to have "common sense" regarding Jon Stewart's URL-driven "to be continued".

Poking around Hulu a bit, it became obvious that there was no way to find the rest of the interview there, and that I indeed did need to go to thedailyshow.com. This led me to a straightforward yet disappointing assumption:

Hulu does not host any content that had not priorly aired on TV. 

Rule of thumb #1: Let old formats get revitalized by the Internet. Don't bring the old shackles and constraints with them.

Hulu likes to portray itself as a savvy, forward-looking company. Yet, they seem to be missing (or actively resisting) a great opportunity at hand. Content creators of every stripe feel constrained by the confines of the television format. Jon Stewart seeks to produce meaningful content, and sometimes chafes at the 30-minute mark imposed on him. His team hacks around this limitation by publishing straight to the Internet. It is likely that every single creator of TV content has, at least once, pondered how this kind of "Internet-only content" is relevant to their production. This could open up all sorts of possibilities for them. Hulu could be the forefront of this movement, actively nurturing and supporting these Internet ambitions. This could even lead to the Hulu product being better than TV. But, instead, the product is relegated to being nothing more than a souped-up TiVo.

I contacted Hulu tech support, complaining about the nasty thing Jon Stewart said to me on my TV. They could not even comprehend my observation, responding with:

"Due to the streaming agreements we have in place, new episodes of The Daily Show with Jon Stewart are only available for 30 days after they first air on TV, being posted the day after. The duration of how long an episode of a show like this stay on Hulu are the result of agreements between the network or studio that owns the show and cable service providers, in this case, Comedy Central."

This response is quite boilerplate-ish, and indicates the degree to which their thinking is dominated by constraints, constraints, and more constraints. Upon clarifying my original request, I received this second response:

"Thanks for getting in touch with us, and my apologies for misunderstanding. I see what you mean now, and I can definitely pass along the request to our content partners in obtaining entire clips or episodes of the interviews of The Daily Show. While that's not a guarantee we'll be able to expand on or change the streaming rights we currently have for the show, we're always looking to shape our service and expand our library."

This may sound reasonable, until we identify the owners of Hulu: a group of TV conglomerates. Hulu and the "content partners" are really the same people. It's just Jon Stewart and me versus the TV companies. They have bound both themselves, me, and Jon into a maze of constraints, in the form of legal contracts and logistical 30-minute time slots. This mess of entanglements saps critical energy that could rather be used in building the right product: just broadcasting whatever Jon Stewart has to say, and however much he has to say of it.

If the same people own both Hulu and TV, why are they not letting Hulu win?

Rule of thumb #2: If you own two competing products, it's OK to let one beat the other. In fact, it's a good thing.

This idea isn't mine. It comes from a man that our society idolized beyond measure: Steve Jobs. Honestly, I was never a big Steve Jobs fanboy. I haven't read his biography. I've heard the "cannibalize one's own products" maxim be attributed to him, which is plausible. Apple never objected to the iPhone's competition with the iPod, or the iPad's competition with the Mac. They accepted that all products, even their best ones, were mortal. They decided that the best possible death would be any death brought on by Apple itself. By this logic, Hulu, the child of the TV companies, should be actively working to destroy TV, perhaps more aggressively then anyone else.

Unintentionally Competing Video Products

Whether they like it or not, the Daily Show has created a video product that competes with Hulu. They host a web site with a video player and navigable video clips. They are effectively running a mini-YouTube, with Jon Stewart as the only user to have a working Upload button available. To me, the viewer, thedailyshow.com is yet another destination to find interesting videos, with its own particular set of limitations, constraints, peculiarities, and incompatibilities. To my particular tastes, my complaints are as follows: the videos are not in HD, I cannot watch them on my TV, there is no meaningful "watch later" queue, and it's hard to find the content that Jon Stewart had just instructed me to fetch. It's obvious that Hulu provides a far better user experience for the same kind of content. This led me to ask my second question of the night:

"Why isn't Hulu exclusively powering the video experience on thedailyshow.com?"

From an operational standpoint, this seems like a no-brainer. Someone working for Viacom deals with the everyday nitty-gritty of their half-baked video platform. This boils down to two large undertakings: serving the content and monetizing the views. While both of these nontrivial tasks can be farmed out to experts, specifically content distribution networks and ad networks, a nonzero amount of money/time/expertise is still required on Viacom's end. And they are doing a terrible job, from my perspective as a user. Hulu, on the other hand, has a better set of user features, specializes in this area, and already has procured most of the Daily Show's content. The maintainers of thedailyshow.com could even perform a minimally invasive transition, swapping out the current player for the Hulu player, leaving the rest of the site unaltered. In sum, the Daily Show could:
  1. Keep their beloved site almost unchanged.
  2. Downsize staff, cut expenses, and simplify operations by eliminating their unnecessary video platform.
  3. Deliver a better video-watching experience based on the features of the Hulu platform.
  4. Gain exposure from Hulu's users by expanding Daily Show content offerings on Hulu's own destination sites.
  5. Get a huge canvas bag full of money every time Jon Stewart mentions Hulu on TV. Imagine hearing "for the rest of this interview, go to Hulu, at hulu.com/thedailyshow".
  6. Strengthen a relationship with an existing partner.
  7. Continue to make money on Internet video with the same business model as before.
Rule of thumb #3: Let your partner do its job. Don't get in the way. Don't compete with them unless you absolutely must.

Unite the Content Fiefdoms into a Content Kingdom

The primary interest any user has in any video product is the content. The only reason I come to thedailyshow.com is for watching the Daily Show. The only reason I pay for Netflix is for watching Breaking Bad. The only reason I use my parents' HBO GO account is for watching Realtime with Bill Maher. Yet, none of these companies focus their product on providing access to the content. Were that their focus, all content would be accessible in open video formats, retrievable over HTTP, with OAuth for authentication. This is far from the status quo. All these companies instead focus on offering video player software. I can only watch Hulu content using an official Hulu player, in the form of a mobile app, a web site, a Roku channel, etc. The same applies for other products, like Netflix, HBO GO, Amazon Instant Video, YouTube etc.

This is a substandard user experience. As a user, I have nearly a half dozen apps that might stream videos and/or music. My video watching life is already complicated by hardware; this unnecessary "appliferation" just makes things worse. I have many devices with screens: my TV, my computer, my phone, and my tablet. I have just as many, plus two, with pairs of speakers. I also need to organize content: I need to queue, bookmark, and share things. Each company is solving all of these needs individually, in their own specific way, in their own silo. As a result, I need to configure six apps instead of one. I have to learn how to use six different user interfaces, each with a unique look and feel, instead of one (although Roku has fixed this problem).  I cope with feature disparities across the six apps, such as my Chromecast only working with some. I have six different "watch later" queues. And ultimately, for any given piece of content, I must remember which particular service hosts it. Wouldn't it be much better if I had one app instead of six?

Imagine a universal video player that was my one-stop shop for playing all videos. You may ask "don't we already have that? Isn't it called Quicktime?" Quicktime is like a baby who needs its data spoonfed to it. When you point it at a file, Quicktime plays the video. Otherwise it sits around and doesn't do much. We need something akin to a hyperactive dog that runs out and fetches the ball. Except the ball is the data. It would have access to files on your local network and cloud storage, as well as your subscriptions to streaming services such as Hulu and Netflix. You would just ask for Top Gun and it would just start playing on your TV. You don't care how the content is retrieved. As long as it's efficient, free (or with clearly labeled prices), and legal, you don't care whether the retrieval was from your hard drive or from your Netflix account. This is an insignificant detail that should be decided by a computer, and be largely invisible to the user. Most people visiting cnn.com do not know that the images and videos on their screen came from 3rd-party content distribution network like Akamai. Most people haven't even heard of Akamai. Most people who open a tap don't know any details about the pipes delivering the water. So, why is the Netflix brand so prominent in the video watching experience, when what you primarily care about is the content itself?

Rule of thumb #4: The product is more important than the brand.

Furthermore, should you share a link to the movie, you should not need to know anything about the link recipient's content subscriptions. You shouldn't need to discern between sharing a Netflix Top Gun link versus an Amazon Instant Video Top Gun link. There is only one Top Gun, so there should be only one Top Gun URL. Links, aka URLs are the basic essence of sharing on the Internet. URL stands for uniform resource locator. One could look at Top Gun as a locatable resource in a universe. The main role of the universal video player is to turn URLs into content... like magic. When I subscribe to a newvideo streaming service, I am simply gaining a key to a slice of that universe. I would aggregate all my keys together into a keychain, used by the video player in authentication. The keychain becomes the catalyst that gets me to go from URL to actually seeing Tom Cruise's face.

If the recipient of a URL has access to the movie's bits, however that may work, clicking on the Top Gun link should just instantly launch playback of the movie. If she lacks access, the problem can be remedied fairly easily. She could then be presented with a menu of options for procuring access. Perhaps the menu would include rentals, such as "rent on Amazon for $1.99, rent on Redbox for $2.99, etc". In today's world, access is typically just 30 seconds and a credit card payment away.

Furthermore, users should be empowered to organize their view of the content universe. They would use the URLs not just for sharing, but for bookmarking. They could make queues, and then watch later. They could search. They could click on "more like this" or "other movies with actor X". They could set up alerts for when a video becomes available. Most importantly, this would all "just work". This has nothing to do with the video content itself: it is all strictly metadata. And metadata is publicly available. The access, or lack thereof, of a user should have no impact on the organizing of the metadata.

This could perhaps be powered by an open, curated, indexed, searchable database of all metadata of all content ever produced, something akin to ISBN or IMDB. Every piece of audio or video content ever published, from user-generated YouTube to major motion picture studios, would have a canonical entry, with a unique well-known URL. Content creators would then also be content curators, cultivating their part of the garden. The Daily Show staff would be certified, by some chain of trust, to curate Daily Show episodes. They would make sure that, for each episode, the title, date, running length, and other metadata were correct. More importantly, they would de-duplicate, and guarantee that each episode had exactly one canonical entry. They could then cryptographically certify that Hulu Plus does indeed have the rights to serve the bits to the videos. Universal video player software would use this database to lookup just where the bits are stored, and cross-reference with a user's keychain to get them cheaply and easily. This decreases barrier to entry for small players in the content provider business. They would need nothing more than certification in the chain of trust, and the bytes would then start flowing.

With this, the balkanization of the content universe, and the excessive appliferation, would hopefully come to an end. I would have my one player that works with all my hardware and all my platforms, and it would present a portal to a world of content that is highly shareable and manageable. Besides, do Netflix, Hulu and their ilk really want to be in the video player software development business anyway? Do they really want to spend energy on integrating with hardware and platforms, such as Web, iOS, Android, Windows Phone, Roku, AppleTV, Chromecast, DLNA and more? Or would they rather put all their effort into procuring and serving content? It would be a win-win, for both them and the user, to get out of this nasty business But, in their view, they have no choice: they must only serve bits to a trusted video player. This is supposedly the only means to prevent piracy, and the only way to enforce any requisite ad watching. And, apparently, the video streaming companies have decided that the only players they can trust are ones created in-house.


Untrusted Players

Were someone to create a Netflix-compatible video player with an big, red, obvious "Save to Disk" button, for example, allowing viewers easily to store streamed videos to disk, Reed Hastings would suffer an aneurysm. For this reason, video streaming companies hold on to as much control over the player as possible. Were there to be reasonable solutions to the problems of ads and piracy in 3rd-party players, however, there might no longer be a very good case for the in-house player. Let's take a stab at this:


Ads

Ads are the bread and butter of video streaming services. One might argue that YouTube is an ads product with a side effect of videos. While YouTube is fairly good at connecting content creators with viewer, YouTube is astonishingly good at creating an abundance of "ad inventory". Note that "inventory" in this context does not refer to ads, which are never scarce, but refers to available ad time. Gazillions of person-hours are spent watching videos on YouTube daily, leading to the availability of gazillions of 30-second preroll ad slots. This "ad inventory" is then sold to the highest bidders on the ad market.

For an untrusted player to work with YouTube, it would need to guarantee that ads were being watched. The ad playback should not be skippable or fast-forwardable. There is no way for Hulu to ascertain that their ad pixels had been rendered on a screen in front of a human at the correct frame rate. Even if Hulu could assert that, there's no certainty that a viewer is actually sitting there watching. And if Hulu could determine even that, they still don't know if those viewers were actually paying attention. In fact, ask yourself: when's the last time you paid attention to an ad? I almost never do, clicking on YouTube's "Skip Ad" link with the ferocity of well-trained fast-twitch muscle fibers. Were we to address this problem, not only would we help enable 3rd-party players, but we could perhaps make advertising substantially more effective as a whole.

Guess what... there's a solution to this problem! Amazingly, the technology to check for the presence of human attention exists, and is mature! It's called the CAPTCHA. You have probably seen many of them, they look like this:




CAPTCHAs are tests that are designed to be passed by a human but failed by a machine. They are typically paired with web forms to prevent submissions by computer programs. They can also be used to make sure a human being has watched an ad. Here's a simple CAPTCHA-based algorithm a video streaming service can employ:
  1. Serve the bits for the ad. Do not serve the bits for the requested content.
  2. Ask the user a question about the content of the ad that a computer can't easily guess. It can't be multiple choice, but would be something like "what color shirt did the second person in the ad wear?"
  3. Go back to step 1 if answered incorrectly. Do not serve the video content until a question is answered correctly. 
Today's world of multi-screens and touch devices facilitates this approach. The ad and CAPTCHA question would be presented on my TV, while I input the answer into my handheld mobile device. It could be social: everyone in my room should have the capability to answer.

Now that I've proposed a system for forcing innocent people to pay attention to things that don't interest them, we have arrived at my next question.

Why force people to watch ads if they don't want to?

Advertising is a bug, not a feature. Let's be honest, videos are not free. Compensating content creators should not be a choice. But, ads could be a choice. This is why paid subscriptions to services like Netflix are so popular.

Imagine an ad-based system were ad watching was decoupled from video watching. I could have a "video bank account". Every time I watch a video, a fraction of a penny would be debited from my video bank account. Every time I watch a CAPTCHA-verified ad, a fraction of a penny would be credited into my video bank account. Advertisers would pay and content creators would get paid. I could set aside time for ads. I would perhaps sit down and watch a half hour of ads. I might even watch infomercials. And if I wanted to forgo ads altogether, I would just pay the price, as long as the price was made well-known and was competitive. This is, in essence, the true "pay-per-view" model. On the other hand, if I did not have any money, I would just sit and watch ads, as we all do today.

Payments are hard to get right. Especially micropayments. And it is even harder given my constraint of doing all this with open standards. I don't know of any open standard that would really work for this use case but one: Bitcoin. I'm not the first person to think of Bitcoin as a micropayments platform. (Please consider this a proper citation so that I can avoid the charge of plagiarism. I forget who it was that originally talked about this). While I cringe at the thought of converting a significant sum of money into Bitcoin, I have no qualm buying $10 worth. If a video view costs one cent, then this sum would be worth 1,000 views. Bitcoin transactions are irreversible, which is fine as I'm never going to ask for a penny refund. The price of Bitcoin is volatile, but content creators probably wouldn't mind being compensated in it (considering that the marginal cost of a video view is zero to them. They have only fixed costs to cover, so Bitcoin is a godsend). Even advertisers might not mind paying in Bitcoin, considering that bidding in online ad markets is probably already quite volatile. Furthermore, it works across international borders, requires no third-party or middleman, has no transaction cost (sort of), and is anonymous (sort of). The only problem with Bitcoin is the transaction clearing time: on the order of minutes. It would be awful if I had to wait minutes between clicking on a URL and a video starting. But Bitcoin seems to be down the right track.


Piracy

Just as there's no way to ascertain whether pixels appeared on a screen, there's no way to ascertain whether the user's bits appeared on a disk. This saved content could be used for unauthorized sharing and later playback. This is a very difficult problem to solve. Digital rights management just moves the problem around rather than provides a solution. Even today, people could potentially workaround DRM by various software and hardware hacks. Perhaps someone needs to create a lie-detecting CAPTCHA. That would be quite useful.

Ultimately, it's a delusion to think that piracy could ever be fully solved. I don't know the data on how much piracy of streaming services occurs today, but I would be surprised if it's zero. I suspect that nearly all copyrighted content is pirated, and thus there is not necessarily a large difference between the locked-down world of today and a world of openly streamable content. Regardless, there are numerous countermeasures one could take to protect against this threat.

First, there needs to be throttling. Ostensibly, streaming services are used for streaming. On average, a viewer should be downloading approximately one minute of playbackable video content per one minute of wall time. Anything significantly greater means the user is not watching, and is possibly pirating. If I download one hour of Breaking Bad over the course of an hour, I'm probably streaming it. If I download an entire season of Breaking Bad in one hour, I'm probably a pirate. Therefore, there should be aggressive throttling in place. The video player should frequently refresh an authorization token from an authorization server, which is then handed off to the content server. The content server can verify the token in a distributed way, using shared public keys. Each token would authorize the user to access a certain portion of a certain video for download. This way, throttling could scale, where authorization servers are kept separate from high-throughput content distribution servers. The "window size" has to be determined. If, for example, a user is only allowed to download 5 minutes of content in every 5 minute window, then the video buffer is limited to a 5-minute window. This is likely more than enough. However, if the user switches videos, they might have to wait 5 minutes before the next one begins streaming. This window size must be tweaked.

Second, digital watermarking (by way of steganography) could be employed to tag downloaded content with information about the identity of the downloader. This is incredibly expensive to do at scale. I have no suggestions on how to make this perform better. Were all content to be digital watermarked on download, then we could begin pursuing a radical shift in our approach to prosecuting pirates. Instead of chasing after the downloaders, digital watermarking would enable chasing after the uploaders, the people who made the pirated content available in the first place.

These are ads and piracy. I think it's doable. I think we can get this!


In Conclusion

In conclusion, copyrighted content tends to make for bad products. If we didn't have to worry about forcing viewers to watch ads, or not to pirate content, and if we didn't have to worry about contractual agreements between content creators and middlemen... we could have much better products. The best I can do is sit here and design, propose, and publish. I would love to flesh this out further, but I've run out of steam on this blog post. I just want a better user experience, and putting out my ideas seems like it could be fruitful. Remember, never settle for a bad product. Stay vigilant and work hard.

Sunday, January 5, 2014

MTA: Electronic Annunciator Signs: Good Start, Needs Work

I am an avid user of New York's mass transit system, the MTA. I am also a fan of helpful information, specifically when it appears in the right place, right time, right dose, and right way.

That is why I'm overjoyed that the MTA, like so many other major mass transit systems around the world, has deployed electronic annunciator signs at subway platforms indicating train arrivals. These signs look like this:


MTA Electronic Annunciator Sign

This is a great start. You may say, "hey, in this era of smartphones, who needs such things?" In the tunnels of the NYC subway system, you will seldom find WiFi or mobile signal. Additionally, some people don't have data plans (or could be roaming), and some don't have smartphones at all. And even if everyone had a smartphone with perfect connectivity, the cognitive overhead of the phone's interface is too much for retrieving such handy and topical information. These signs still provide great value. But, as they are today, they need much improvement.

Lack of Station Coverage


Why are these signs not present at every last station throughout the system? I only find them at a small, seemingly arbitrary smattering of stations. To help explain why this is outrageous, let me borrow a quote from one of the greatest speakers of all time:

"Injustice anywhere is a threat to justice everywhere." -Rev. Dr. Martin Luther King Jr.

A lack of useful information is definitely unjust. Let me tweak the above quote into a suitable first rule of thumb for this blog post:

Rule of thumb #1: An information gap anywhere is a threat to information everywhere.

For Information to be useful, it needs to be predictably retrievable and reliable. If information is hard to find, or altogether absent, it's of limited utility. At the moment, passengers cannot rely on these signs being present throughout their journey. They could be burned by the absence of a sign when mistakenly assuming one would be present. This is especially true for international travelers who assume that, throughout the civilized world, transit systems provide ample information regarding train arrivals. With inconsistent coverage, these signs are, at best, a pleasant surprise to passengers fortunate enough to stumble upon one.

Note that if all passengers had ample information about train arrivals, they would each potentially make better travel decisions. This is what pretentious intellectuals say would lead to an "emergent phenomenon". If a whole bunch of individual ants coordinate their decisions, an anthill "emerges". In the same way, an efficient subway system emerges from efficient passengers. This could improve the subway system as effectively as would system expansion or more frequent train service. Imagine average train crowd size and average journey time dropping just from the consistent placement of simple signs at train platforms. Who would need the new Second Avenue Subway? (That's a joke. Please finish that project, dear MTA).

London (and probably most major cities in the world) has fully deployed such electronic annunciator signage (at bus stops, even). This is frustrating, as between NYC and London, the former clearly has a more dire need for signage. London has far better underground WiFi and mobile network coverage, facilitating smartphone use. Additionally, average and maximum wait times for subways in London are far shorter than those in NYC. In London, a train typically arrives by the time I finish reading the sign, thus rendering the sign unnecessary. In NYC, I can find myself waiting upwards of twenty minutes for a train, in an information-deprived purgatory of constant anticipation.

Why hasn't the MTA fully deployed these yet? Would it be too expensive? Let's estimate the costs. On Amazon, at the moment of writing this, one can purchase the kind of programmable LED sign I played around with in middle school for $106. Note that this item is likely to be far more sophisticated than that which the MTA needs. There are 468 stations. If we provision an average of 10 signs per station (likely to be more than enough), the total cost is $496,080. I am going to ignore the cost of electricity and labor for installing and programming the signs (these should both be negligible given that the MTA has existing sign infrastructure and expertise). Also note that the signs could be substantially cheaper when purchased wholesale.

The MTA's annual revenue is on the order of $7 billion, which is one side of an almost balanced budget. Even if I round up the cost to $700,000, it would run to 0.01% of 1 year's revenue. And this is a one-time cost; annual upkeep should be far cheaper. Also, this purchase falls in the category of capital investment. In other words, should the MTA walk into any bank in the world, they would likely walk out with the money to buy all the signs they would ever need.

So, in summary:

  • Money is not an obstacle.
  • This fits existing internationally accepted standard expectations held by travelers.
  • This would lead to a more efficient, optimized subway system without digging new tunnels or adding new trains.
  • This is the most obvious improvement to the subway system that I can think of.

So... do it now, MTA!

I must pause at this point. I'm afraid that I have veered this blog off course. This blog is not about proposing big, costly changes. It's about finding obvious pain points and easy, cheap fixes with huge impact. Let's investigate one particular case:

34th Street – Penn Station (IND Eighth Avenue Line)


Like tens of millions, I matriculate through New York Penn Station (a major North American mainline train station). Like tens of millions, I exit Penn Station by connecting to the NYC subway system via the station titled "34th Street – Penn Station (IND Eighth Avenue Line)". This is where you catch A-C-E service, and is probably one of the most heavily trafficked stations of the entire system. There are annunciator signs on the train platform, but outrageously, they tell you nothing but the current date and time of day.

Train arrival information is critically important here. Going through the turnstiles at the entrance, you are immediately presented with a room that has three doors, and are asked to choose one. 
Monty Hall 3 Doors

Just kidding. The room doesn't have doors, it has stairways leading to the three platforms of the station.
  1. Downtown Local (C, E service)
  2. Uptown and Downtown Express (A service)
  3. Uptown Local (C, E service)
Each passenger must choose one. This set of choices, however, is less than ideal.
  • Each passenger wants to get to their destination as soon as possible.
  • Each passenger needs to go either uptown or downtown, but not both.
  • There are three services on this line: A, C, and E. Some passengers need to select a particular service. Many (maybe most) are fine with taking whatever comes their way, since all three services run on the same line in Manhattan (8th Avenue).
In sum, many passengers just want to take the first train arriving in the appropriate direction. Forcing them to decide on local versus express prematurely is a mistake. Ideally, there would be two doors instead of three: one for uptown and one for downtown. That decision is easy for passengers to make. Then, each door would lead to a platform (or platforms) featuring full A, C, and E service. This would satisfy those passengers interested in a particular service, as well as those on the "first-train-that-comes" strategy.

Unfortunately, the layout of the subway station cannot be altered easily, so we must work with this. I am a passenger who is in the "first-train-that-comes" category. Every time I arrive at the three doors, I choose between downtown local and downtown express at random. I often make the wrong decision, in that often the first arriving downtown train is bound for the other platform. The instant that I perceive this to be happening, I start a race against the train. I bolt down the stairs, run across the room, bolt up the other stairs, and try to leap through the train's closing doors. The window of time between my identifying the arriving train's target platform and the train's departure from the station is fairly short... so I need to run pretty fast. Unsurprisingly, there are always other people in the same situation, who make the same humiliating sprint through this obstacle course.

Rule of thumb #2: Place helpful information in places where customers have to make important decisions.

Dear MTA: put one goddamn annunciator sign, with train arrival times, at the bottom of the three stairways. This way, passengers like me can decide where to go. The presence of just this one sign would have a major positive impact on your subway system. Even just programming the showing of arrival times into the existing annunciator signs at the top of the stairs would yield a major improvement.

Information Architecture


It's not enough for information just to be present (although that's 99% of it). Information must be presented well. This isn't straightforward, but it's easy to improve, since it can be addressed in the software. Before we go into any specific improvements, I must lay down a general rule of thumb.

Rule of thumb #3: There exists a field of study named "information architecture". It is valuable. Go to your nearest library and borrow a book on it, for free. It will be the best zero cents you have ever spent.

Information should be consistent. Compare these two signs of the same subway system:
MTA L train Electronic Annunciator Sign

MTA 4-5-6 Train Electronic Annunciator Sign

Look at the differences in color, capitalization, typeface, spacing, use of arrows, use of list numbering, use of terminus station (Pelham Bay Park) versus borough (Manhattan), use of a "shield" to designate subway service, and the way multipage content is scrolled through (not visible here). The information on these two signs could not be presented more differently!

Rule of thumb #4: Eliminate all inconsistencies in the presentation of information.

While neither sign has perfect information presentation, I greatly prefer the second:
  • The use of a shield around "5" and "6" to designate subway service is an instantly recognizable visual cue with a very well-known meaning. Using a shield is consistent with the way visual information, electronic and not, is presented throughout the subway system. People might wonder what the "L" in the other sign references.
  • Arrows that point to train platforms anchor the information to the physical world. This is, in fact, one of the most critically helpful components of the sign, and yet is conspicuously missing from the other sign. Note that the subway station in question does have a two-sided platform, with both sides in full use. Thus, arrows do add value.
  • The use of terminus station "Pelham Bay Park" is more specific than just referencing a borough "Manhattan". Veteran L train riders know that all Manhattan-bound L trains terminate at 14th Street – Eighth Avenue, but others might not.
Criticisms of both signs:
  • Both signs scroll through multiple pages of information, slowly. People need to wait for relevant information, and may not even know what to expect from upcoming pages. It would be substantially better if all useful information fit on one page.
  • There isn't anything present on the sign to cue the passenger into expecting scrolling. There is nothing to indicate how much content has already been scrolled through, and how much remains. If scrolling is present, its existence needs to be well indicated.
  • If scrolling is present, keep the most useful information fixed, while less useful information is scrolled. The first sign scrolls through 1 page of all the Manhattan-bound train arrivals, 1 page of all the Brooklyn-bound train arrivals, and 1 page with the current date and time. I suggest fixing the current time and the single next arrival for both directions. Using arrows as a helpful and concise way to represent train direction, this could all be compressed into a single row.
  • List numbering is unnecessary (the "1." and "3.") and peculiar in this context (what happened to "2."?) Although, the scrolling animation (not visible here) is a strong cue that explains this peculiarity.
  • Since so much space is used in "claiming" a row for a particular train service ("L Manhattan" or "6 Pelham Bay Park"), show as many arrivals as can fit in that row. Comma-separated arrival times aggregated together would be handy here. Specifically, compress the two rows of the first sign down to one row of "L Manhattan 1, 9 Min". Passengers are now empowered to make better decisions regarding skipping crowded trains (if I don't take this one, I see than I can just wait X minutes for the next one).
  • For passengers in Manhattan stations, final destinations such as "Pelham Bay Park" are usually not as important as service designations such as "6". I don't know how to use this fact to improve the situation.
  • Information such as direction of trains (uptown versus downtown) and destination boroughs would be very useful, but is missing. I don't have a suggestion on how to add this.
  • A nearby clock with the current time would be extremely handy. People care about wait times late at night, when wait times are substantial. But, in the middle of the day, people have appointments with strict timing. They care much more about expected arrival time, and thus need to know both current time and wait time.
MTA, you are on the way to improvement. You don't need to spend more money... you just need to do things a bit smarter.

Saturday, December 28, 2013

Twitter: Error Messages Should Be More Useful Than the Average Tweet

I have a 140-character message for the people at Twitter:

@twitter Error messages important. They should be avoided, but when needed, should be descriptive, helpful, and more than 140 chars. kthxbye

The other day, I was trying to send a direct message using the official Twitter Android app. For no apparent reason, I kept getting one of the following two error messages, at random:
  • Sending direct message failed.
  • Sorry, we were unable to send the message.
These are terrible error messages.

First, why are there two different messages that say the same thing? One is polite and one is brusque. Twitter, choose one and stick to it! Randomly choosing an error message is pointless, not user friendly, and complicates solving the problem.

Rule of thumb #1: There should never, ever be any randomization in error messaging.

Next, these two messages provide no information whatsoever. Years of experience as a failed user led me to interpret these as indications of a momentary outage of Twitter service, and that I should try again later. So, I did. Over the span of two days, I tried to send my message nearly a dozen times, each attempt denied with the one of the above worthless error messages. I decided to engage in some sleuthing, leading me to this discovery, buried deep within the Twitter help center:

Bingo! I was, in fact, trying to send a message containing a URL! My assumption was incorrect. "Try again later" was not at all the appropriate course of action... the contents of my message were invalid. After remedying this, I successfully sent my message, and moved on with my life.

Beyond the horrendous error messaging, and the burial of critical information deep inside of the Twitter support web site, lies a much deeper problem. It is outrageous to think that any string of length 140 characters or less could ever be considered invalid.

Rule of thumb #2: A string that is less than 140 characters is ALWAYS a valid tweet or direct message.

I could understand Twitter engineers discovering a theretofore unknown issue, and posting an explanation while they rushed to address the issue. But, the above explanation seems to indicate that Twitter knowingly decided to break messaging functionality during back-end restructuring. Why was it necessary to do so? When a URL-processing sub-system is taken offline, messaging should not be disrupted. At its core, Twitter (to its credit) is an extremely simple product: the dispatching of max 140-character messages. Everything else is icing on the cake, and optional. If users miss their URL shortening or click analytics data for a few days, no biggie. If users cannot send the messages they want, that's a biggie. Everything at Twitter, from normal operation to planned back-end restructuring to unexpected situations, should be organized around this central principle.

I'm not done here.

I also received the following additional error message:
  • Direct message could not be sent. Recipient is not following you.
This is also less than ideal. First of all, at times, the message was patently false... the recipient was following me. Pardon my French, but that's quite a huge fuck-up, and heads should roll.

Regardless, should this ever be the actual case, it could be handled much better. Note that this an edge case, considering that opening a direct messaging dialog with a recipient who isn't following you is prevented. This case then only occurs if the recipient unfollows you sometime between the rendering of the dialog-launching menu item and the clicking of the send button (or in my case, it occurred for no good reason at all).
  • As soon as it is known that the recipient is not following, disable the send button. Re-enable the send button as soon as the recipient follows you.
  • Put up a word bubble over the disabled send button, explaining why it's disabled.
  • Provide a button for an action that helps remedy the situation. Either by
    • Facilitating the composing of a tweet that asks the recipient to follow you
    • Sending a private "follow request". This functionality does not exist at the moment, but it should.
Furthermore, it is hard to learn how to call up the direct message dialog. I looked through the action menu for "Send a Direct Message," but it did not appear to be there.

Compare:




 "Send a Direct Message" only appears if the recipient is already following you. How am I supposed to know that? I continued scouring the Twitter interface, but fortunately, the interface is small enough to be covered completely in a short amount of time.

Rule of thumb #3: Menu items that cannot currently be actioned should be disabled, not invisible. Additionally, the reason for disabling should be clearly labeled.

Hopefully, with the new money raised by the recent IPO, they can spend some of that on buying common sense.

Friday, December 27, 2013

PayPal: Do You Ship Internationally?

I met a merchant at a bazaar (in real life) who had some exciting merchandise. She directed me to her web site to showcase the remainder of her inventory. I was interested in buying a gift for an overseas friend, and thus asked the merchant:

Do you ship internationally?

She said "yes, I can do that!" Overjoyed, I browsed to her web site, powered by PayPal's shopping cart system. After filling my cart, I then had been escorted to the PayPal checkout flow.

I'm always a bit confused by the PayPal checkout flow. It is designed to coerce the user into using default payment settings (bank account instead of credit card, which is cheaper for PayPal to process). I managed to pull up the shipping address dialog in order to input my giftee's UK home address.

I was surprised to find this:


The country field was set to United States, and was unchangeable. At that moment, I had become consumed with the question "why can't I ship outside of the United States???" After all, I had confirmed with the merchant, face-to-face, that it was possible. 

Rule of thumb #1: Avoid telling the user "no," especially when the user knows the answer is actually "yes".

To me, it was straightforward: shipping companies do ship outside of the USA. All the merchant needed to do was to stick an address label on the box, and all I needed to do was to pay the shipping fee. What would ever be the case for bolting down the country field? The only complications I could imagine are 1) taxes 2) export restrictions. Taxation, with all of its vast complexity, already has been implemented by PayPal, and would have been an inappropriate justification for altogether preventing my order. Export restrictions are an edge case, and had not been applicable here.

I started to pursue a solution to this problem. I had contacted both the merchant and PayPal tech support (twice). The merchant noted that, in her browser, she did have the option to ship internationally. She suggested working around this, by requiring that I provide a US shipping address, and then that I pay the remaining shipping costs in ad hoc manner. I was resistant, because this would have put me at risk, and also would have entailed my acquiescence to the flaws of a bad product. No one could answer the simple question of "why is this happening?" The best suggestion that had come from PayPal tech support was "there's something wrong with the merchant's integration." Both I, the user, and they, the support experts, were staring at the exterior of a black box whose inner contents were utterly mystifying.

Rule of thumb #2: If you must tell the user "no", provide an accompanying explanation, with actionable steps.

Imagine how much time would have been saved if the address form just noted "this item cannot be shipped internationally due to the merchant's preferences (or due to export restrictions). Please contact the merchant." Imagine, additionally, a button that auto-emails the merchant a message from a @paypal.com e-mail address with a boilerplate explanation of "a potential customer of yours desires to ship internationally. Here's how to reconfigure your shopping cart integration to do so." This functionality would not only greatly benefit me, the customer, but it would also benefit the merchant, and would leave out tech support altogether. Note that these fixes are rather cheap and easy, implementable in a few hours by a mediocre developer.

Unfortunately, the developers didn't have the prescience to implement this functionality. They erroneously decided that a hardcoded text field is just fine, when actually, it's rather tyrannical. The instinct for good user experience was just not present.

The next steps suggested by tech support were for me to implore the merchant to contact merchant tech support to ask for help in fixing a problem that she didn't care to fix. There is plenty wrong with this, but I may perhaps leave the analysis for a later date.