How to be Evil: A Lesson from Google on Non-Transparency

For having released a policy proposal (jointly, with Verizon) that pushes transparency as a key element of Internet access, Google’s certainly acting shady on its public policy blog.

For starters, Google’s recap mentions only one tiny piece of the spooky Network Management section of the proposal at all. The section includes the monstrous sentence below, which seems to provide blanket allowance for traffic regulation by ISPs:

Reasonable network management includes any technically sound practice: to reduce or mitigate the effects of congestion on its network; to ensure network security or integrity; to address traffic that is unwanted by or harmful to users, the provider’s network, or the Internet; to ensure service quality to a subscriber; to provide services or capabilities consistent with a consumer’s choices; that is consistent with the technicalrequirements, standards, or best practices adopted by an independent, widely-recognized Internet community governance initiative or standard-setting organization; to prioritize general classes ortypes of Internet traffic, based on latency; or otherwise to manage the daily operation of its network.

I tried to find a key phrase or two to italicize for emphasis—but the passage has just too many nasty bits to single any out.

The Google-Verizon proposal also pointedly declaws the FCC (while also begging for federal funds to develop broadband Internet access in “unserved” areas). The document notes that the FCC is merely to “oversee” broadband Internet access, and includes the most bizarre sentence I’ve read this year:

Regulatory authorities would not be permitted to regulate broadband Internet access service.

Nasty, right? But Google’s blog post makes all this sound much sunnier, noting that the proposal creates “enforceable consumer protection and nondiscrimination standards that go beyond the FCC’s preexisting consumer safeguards,” and claims “the proposal also provides for a new enforcement mechanism for the FCC to use.” That enforcement mechanism seems to mirror what’s in place for broadcast television; the crucial difference is that in the broadband case, the FCC would be enforcing rules set up by the companies being enforced (since regulatory bodies wouldn’t be allowed to regulate). Sounds like paradise for the companies providing access, doesn’t it?

What a distressing lack of integrity from the company that looks to be taking over our digital lives.

Problems & Process: An Open Letter to Facebook

Dear Facebook user experience team*,

Just in case you’re listening, here’s what I hope will be a specific, constructive critique of your recent changes—instead of so much more of the caps-lock venting that seems such a common response to your work. I’ll start small and work my way to the bigger issues; if you want to skip to those, look for the longer paragraphs.

Unless I’m on the home page, it’s now two clicks to get to my bookmarked applications, instead of one. An annoyance, and unnecessary: Why undo your previous round of changes, which made what is now the left-hand navigation a usefully global element?

In fact, it can sometimes be a third click to get to a certain bookmarked app, since you now only show three such apps instead of six. Remembering the state of the “more”/”less” toggle across sessions would take away this extra step.

I’m not sure what prompted you to bury the Help Center in the Account menu; that seems like one of the most important links to have readily available and locatable for users of such a complex system—and one with such a varied user group in terms of skills and experience with the Web.

It’s nice that you clarified the difference between the Top and Most Recent Stories with the new names. But that’s another place where user preferences ought to be configurable (or, better, just remembered from session to session).

Further, I think many of us were a little surprised you put something out there with the original terminology (News Feed/Live Feed) to begin with; this change feels like a long overdue make-up call. In other words, your strange process has obscured the real innovation that you’ve got in place here. I’m sure there’s some complex algorithm running the Top Stories section, but your users can’t appreciate it because of all the drama (for lack of a more precise term).

Speaking of process, I think the bigger point, which no doubt you’ve heard, is that you need to just cool it for a while. Iterative design shouldn’t happen at the expense of your gazillion users; do your experimenting behind closed doors and then release major updates only when you’re confident that (a) you won’t have to change them for a while and (b) you have enough useful feedback from well-habituated users to be able to make the right changes to the old system. From the outside, it’s impossible to think that’s what’s going on now. Fix whatever corporate problem you have, an then put a new process in place.

In the meantime, as they say, leave Facebook alone.

Best,
Devan

P.S.: As for the stranded chat box at bottom-right… well… I’m sure you can’t be happy about that.


* Though I address this to the UX team, it wouldn’t surprise me at all to learn that some bureaucratic pressure has left key decision-making power about the interface in the hands of a non-professional. [back to top]

URLs & Users

David Sklar’s claim that “people don’t care about URLs” (via Full Stop Interactive) seems like a wild overstatement, even taking “people” to mean “average” people.

At one point, he might have been right, but people who know what’s up with URLs have long been training others, through the kind of informal technical support so many of us give, to pay attention to them. I get a call from one of my parents from time to time saying, “This address looks funny. Should I trust this site?”

Internet literacy has grown to a point where people who might not have known how to open their browser a few years ago—I had a client like this in 2004—now understand that the thing with the blue line under it is called a link or hyperlink, and that some kind of code they can’t see tells their browser where to go when they click, and that “where to go” means, in a sense, “to what URL.”

(Besides, if you’re going to tweak URLs anyway, why not take “advanced” users into consideration?)

Don’t Hammer Screws: Nielsen on Social Media Outsourcing

In his latest AlertBox entry, Jakob Nielsen effectively shows that “usability suffers when an organization puts its website content on social sites without adapting it to the particular site’s features.” This is true enough: One should no more use YouTube in the half-hearted ways Nielsen identifies than one should use a hammer on screws.

However, Nielsen also claims that this argument “count[s] in favor of keeping social features on your own site where you can design them to provide a better user experience for your customers.” I take issue with this claim: Nielsen’s blaming bad UX on social media platforms, when it rightly belongs with development teams (as it usually does).

In other words, it’s not that you can’t design good UX with social media outsourcing in place; it’s that the makers of the sites Nielsen points to just didn’t—whether for lack of vision, budget constraints, insufficient technical expertise, or laziness.

(In most cases, I suspect the difference comes down to people using site-provided widgets or embed code rather than APIs. Whether this is a failure of strategists, UXers, designers, or developers probably varies.)

Nielsen seems to acknowledge this distinction in his qualification to the first claim I cite above. That is, when he writes, “without adapting it to the particular site’s features,” he seems to understand that good UX featuring social media outsourcing is indeed possible.

As proof that it can be done, I offer up the following, a simple example of a site that does social media outsourcing right. (Full disclosure: I led the charges on strategy and UX for this site while working for Mind Over Media.)

Case Study: WUTube

Waynesburg University asked us to devise a media-rich, recruiting-focused site that featured students in their own environments. We wanted to outsource some of the material to YouTube and Flickr for a number of reasons, some of them likely familiar:

  • The budget for the project precluded dedicated media servers or high-end hosting.
  • Waynesburg’s target audience—prospective students (and their parents)—already lived on YouTube, and identified themselves as looking for a Waynesburg presence there.
  • The school’s staffing situation made an easy-to-use, low-cost data and media administration tool a mandatory for the project.
  • In a way that was admirably forward-thinking at the time, the school recognized the need to play a role on maintaining their online presence outside the classic “admissions microsite” model. In short, maintaining credibility demanded increased activity on YouTube in particular.

Note that the finished product, WUTube, avoids the pitfalls Nielsen identifies, in part through good design, in part by making heavy use of APIs for the various social media sites involved. Heavy customization, to be sure, but surely Martha Stewart and Harvard Business Publishing (two of Nielsen’s examples) could have sprung for it.

In particular, WUTube overcomes these obstacles (links are to screengrabs on Flickr):

  1. Nielsen’s categorization problem, wherein relying on the social media site’s default means of organizing content serves nobody. Instead, WUTube organizes all content—inluding videos—by student, which is to say, by the main draw to the site.
  2. Lousy titles for the media. WUTube’s administrators and the students involved have been diligent in creating fine, descriptive titles for the images and videos used on the site.
  3. Obtrusive, distracting branding. WUTube includes a set of branded hyperlinks, but they’re located out of the way on the home page. Otherwise, the content feels much more integrated with the site than in Nielsen’s examples.

Again, the problem Nielsen’s pointing to isn’t with the tools; it’s with organizations using them poorly.

Profiles, Pages, and Facebook Spam

Earlier today, I received a Facebook friend request from a user account named for a web-based software product. Before dismissing the request, I sent a message to the account that read:

A business or product having a regular FB account instead of a Page is tantamount to spam.

I received a response from the Community Manager associated with this product, asking for clarification. Since I’ve seen this problem before, I’ve decided to post my explanation here, instead of replying privately. So here it is:

First, I expect to receive friend requests only from people. More generally, I don’t want unsolicited communication on Facebook from organizations. When your organization sends me a friend request, you are sending me spam, just as if you had sent me an unsolicited email.

Unsurprisingly, Facebook’s Rules corroborate my position:

  • “Profiles can only be used to represent an individual, and must be held under an individual name.”
  • “All personal site features, such as friending and messaging, are also for personal use only and may not be used for professional promotion.”
  • “Using personal site features for professional promotion, or creating unauthorized Pages, may result in your account being warned or disabled.”

In short, using a regular Facebook account (which is for people) instead of a Page (which is for organizations) gives you access to personal accounts that organizations should not have. (That “should” represents both a philosophical and a systemic imperative, in my mind.) When you take advantage of that access—by sending friend requests, for example—you are spamming.


Update

The organization’s community manager has responded; with his permission, I post his comments here:

hmm…I get your point, but I’d appreciate more flexibility on the whole “spam” concept. We are not trying to scam you, not even sell you anything. On the contrary, we are inviting you to be a part of an idea that we consider to be helpful to every user in the web and we are giving you the option to reject this invitation.

As we see it, Popego is a person made of software and silicon chips, so it is only natural that it has Twitter and Facebook accounts. We do not spam our followers in Facebook or Twitter and we get 10 new ‘friend requests’ every day so I don’t believe that too many people share your vision of spam.

I should first repeat my private commendation of the community manager for his ceaseless courtesy, which I hope I’ve returned.

Beyond that, of course, he and I don’t find accord on much. To his first point—the implication that it only counts as spam if the goal is to “scam” or to “sell”—I disagree. Any unsolicited mass communication in violation of reasonable expectations is spam. This case amounts to such a violation because Facebook explicitly limits the role of organizations within the service. This creates a reasonable expectation that users will not receive mass communications from organizations they haven’t invited to communicate with them (e.g., by becoming Fans of those organizations).

Neither do I find it relevant that the account in question receives friend requests (the community manager’s final point). For one thing, the account receiving friend requests doesn’t violate the norms of Facebook in the same way as the account sending them. More to the point, just because some users don’t share my expectation, that doesn’t mean it’s not a reasonable expectation to have. Again, I take it to be reasonable, at a minimum, because of Facebook’s own stance on the matter.

Finally, a pair of the rhetorical gestures in the response warrant examination. The argument that because a web service somehow having personality (and a smiley-face as part of the logo) makes it “a person” is specious with or without Facebook’s definition of personhood to turn to. Likewise, using flowery optimism (“an idea that we consider to be helpful to every user in the web”) as a defense against charges of spamming seems like an abuse of the good cheer underlying much of the last few years of innovation on the web.