AlanHogan.com

Short URLs in Markup with rel-shortlink

Tue, 23 Feb 2010 04:51:58 -0500

Everything you need to know about rel-shortlink

Authors and administrators can and should use rel="shortlink" to indicate their preferred short URL¹ for a piece of content. Below, I discuss history, reasoning, implementation details, and helpful hints.

Rel-shortlink is decidedly the way to go #

Why rel="shortlink"?

Previous suggestions included rev="canonical" which is both confusing and technically incorrect² and the less problematic rel="shorturl".

However, rel="shortlink" is a WhatWG standards body³ proposal and is going through the MicroFormats process, unlike any other variants. A rel="shortlink" link is the way to go.

Terms used in this document #

slug: The part of a short URL after the domain and slash.
service: A web app that takes a long URL and optionally a custom slug and returns a shorter URL that redirects to the original URL.

Implementation into content #

The following examples are mostly from Microformats.org. The long, original resource URL is http://www.flickr.com/photos/tantek/3909804165/.

The #1 most important thing to do as an author or website administrator is to use the following HTTP header to indicate the “shortlink.”⁴ #

Link: <http://flic.kr/p/6XuLyD>; rel="shortlink"

Authors should also include the following in the HTML <head>⁵ #

<link rel="shortlink" type="text/html" href="http://flic.kr/p/6XuLyD">

The type attribute is optional and almost meaningless since the other end of the link is just a redirection back to the current page; thus the content type is already implied.

Both of the above representations are important and machine-readable. (You can your implementation here.)

If authors wish to expose short URLs to human site visitors (e.g. to suggest short URLs in the <body>), they may do so any way they wish. As long as the above methods are also used, services (i.e. machines) will correctly understand the canonical shortlink.

However, there are still related microformat standards which maintain a degree of machine-readability for user-facing markup. Markup standardization is inherently good and encourages portability (of CSS styles and JavaScript code, for example). #

<a rel="shortlink" type="text/html" href="http://flic.kr/p/6XuLyD">
 http://flic.kr/p/6XuLyD
</a>

<input type="text"
  class="shortlink"
  value="http://flic.kr/p/6XuLyD"
  readonly="readonly" />

The latter would present an input box with the short link, which makes selection for copy & paste easy. The readonly attribute prevents users from accidentally overwriting the link.

User selection of shortlinks may be further aided by executing the following JavaScript when users click the text input: #

this.focus(); this.select();

A best-practice, unobtrusive jQuery code snippet to apply this to any and all input elements with a class of “shortlink” is as follows:⁶ #

$(document).ready(function() {
        // Auto-select short urls
        $('input.shortlink').click(function()
        {
                this.focus();
                this.select();
        });
});

Some authors also provide a button that copies the short URL to the clipboard using Flash (as this is not allowed in JavaScript).⁷ Be aware that Flash can crash Macs and a growing number of users are using flash blockers. You may only want to show the Flash-based copy button if Flash is both installed an not blocked. Let me know of any related best-practice code. #

Shortening service implementations #

Shortening services should always use the “301 Moved Permanently” HTTP status code combined with a “Location:” header to redirect user-agents to the longer URL. #
The WhatWG suggests that short URLs consider avoiding lookalike glyphs such as 0/O and 1/l/I, “particularly when manual entry will be required (e.g. printed, spoken).” #
The WhatWG also suggests allowing for human-readable slugs (short URLs), which allows users to better guess what lies on the other side of the link. This means allowing custom, manually-set slugs. #
Whether or not capital letters are used is up to the service provider. It is easier to verbally dictate a URL of all lowercase, though mixed-case services can provide dramatically shorter URLs when hosting a large number of URL redirections. Thus it is my personal recommendation to consider using all lowercase when the redirection service is only expected to hold at most a few thousand redirections, and mixed-case otherwise.⁸ #
Shortening services expected to produce four-letter or longer slugs, or allow the public to enter free-form slugs, should strongly consider blocking offensive terms for at least automatically-generated slugs.⁹ #
In the spirit of the robustness principle,¹⁰ a URL shortening service should expect other programs to add extra punctuation on the end of short URLs it expects to resolve. The service should attempt to gracefully deal with this. For example, a user may write:

… these guidelines for short URLs (http://ajh.us/k).

and a plaintext URL auto-linker¹¹ may match this as

http://ajh.us/k)

in which case the service at ajh.us may receive a request for the URLs

http://ajh.us/k),
http://ajh.us/k%29, or perhaps even
http://ajh.us/k).

Thus, it is a best practice for services to use one of the following algorithms (in pseudocode) when redirecting¹².

Whitelist method (most forgiving):
```
slug //from user
pattern = /^[0-9a-z]+/i //whitelist of characters allowed in slug
slug = regex_match(pattern, slug)
if ! slug then fail
```
Right-trim method (serves more 404s for truly horrible requests):
```
slug //from user
slug = urldecode(slug) //decode %-encoded characters e.g. %29
characters_to_trim = ")>]}.,;!-"
right_trim(slug, characters_to_trim)
if length(slug) == 0 then fail
```
Let me know if additional erroneous trailing characters should be stripped in the second method.

I would use whichever algorithm is faster in your environment. #
I am currently unsure as to the best way to deal with special characters like “”é() in long URLs. Such characters “shouldn’t” be in HTTP URLs in the first place, but again, according to the robustness principle, services should support them, as they do show up in the wild.

Please contact me if you are aware of a best practice for dealing with special characters in original URLs. #

Caveats

Be careful not to serve shortlink incorrectly by making incorrect assumptions regarding GET parameters. A resource’s shortlink must redirect to exactly the same content.¹³

Also understand that using shortlink is a commitment to always support that short URL for as many years into the future as possible.¹⁴

Lastly, this standard is new (having been suggested less than a year ago, in early 2009). It is not finalized, and early some implementors are still using alternatives such as rev="canonical", rel="short", etc.¹⁵ However, this standard makes the most sense and is backed by standards bodies; Google Suggest also hints that rel="shortlink" is already the most popular choice.

Short URLs redirect to a longer URL when entered into an address bar. They are convenient for media where space or characters come at a premium, such as Twitter, phone, and print. ↩
Technically, a rev="canonical" link means “the page I am linking to considers me to be the canonical, or best/truest, URL for this content.” An example of why this is wrong for short URLs was pointed out by Eli White: “The canonical URL of something on php.net might look like: http://php.net/manual/en/security.php … However, you will never actually be served HTML under that canonical URL, instead you are auto-redirected to a mirror, such as: http://us3.php.net/manual/en/security.php.” This means for php.net to use rev="canonical" would be to incorrectly assert that the current page is the canonical, or “one true” URL for that content. What we really want is a way to say, “the resource I am linking to is the canonical, or ‘one true,’ short URL for myself,” which is a different thing entirely. ↩
The WhatWG is the group bringing us HTML5 and are similar in function to the W3C. ↩
This is because other services, such as Twitter clients, may use an HTTP HEAD request on the long URL to see if it has a canonical short URL defined. ↩
This helps bookmarklets and other client-side code function, as bookmarklets only have the document to work with, not the headers. ↩
It is tempting to apply the above code on the focus event (a more general event than click, it would include tabbing into the input box), but some browsers require the focus event to finish firing before select() is called for select() to have any effect. ↩
Please indicate to your browser manufacturer and/or standards bodies that you would like a JavaScript method to copy to the clipboard (if the user trusts the site in question.) ↩
It is possible, though uncommon and not recommended, to produce even shorter URLs by using more characters than just alphanumerics. For instance, slashes, periods, commas, and a question mark could be used. However, there are serious reasons to avoid these characters in slugs, especially as a trailing character. For instance, the URL http://example.com/foo. will typically become a hyperlink to http://example.com/foo, losing the trailing full stop, when auto-linked as it would be in Twitter or a plaintext email. Some other short URL providers use Unicode symbols in their short URLs, but support for these URLs is weak among email and Twitter clients and on many mobile devices. ↩
TinyURL.com had a minor mess on their hands when someone linked an offensive slug to the then-current U.S. First Lady’s homepage. ↩
The robustness principle is, “Be conservative in what you do; be liberal in what you accept from others.” ↩
John Gruber suggests a liberal regex pattern that can avoid these mistakes (usually). ↩
Unless of course the characters to be trimmed can appear in legitimate short URL slugs. In that case, you should trim them only if a legitimate short URL is not found. However, supporting these characters is obviously a really bad idea, in the opposite case where third party plaintext URL auto-linkers prematurely end matching your link. ↩
This excludes trivial enhancements to the page, e.g. a user menu at the top, as long as the main content resource is unchanged. ↩
Cool URIs don’t change ↩
As of February 14, 2010, this still includes Flickr, where the original rev-canonical variant was first proposed. ↩

Google Buzz is Already Dead

Sat, 13 Feb 2010 21:30:55 -0500

There is no way Google Buzz will be a successful product. Why not? Here’s a hint: It’s more than those massive security blunders, since Google is already fixing those.

Reading updates feels like an obligation

Look at me, look at me!

This is a huge mistake.

Buzz appears right below Inbox in Gmail’s left-hand navigation. And like “Inbox,” “Buzz” becomes bolded and shows an unread count in parentheses when it contains unread items.
New content on Buzz receives yellow highlighting.
Any replies, no matter how insignificant the are compared to the hopefully serious items in my email inbox, get bumped into my Gmail inbox.
When I got Buzz, my Google Reader account instantly started overflowing with every single article anyone I follow on Buzz shares, as if I didn’t have enough to read already. RSS feeds are not as inconsequential as Twitter feeds. This should not be default behavior, and there should be a way to opt out of this without stopping following everyone on Buzz!

None of this makes any sense. Since Buzz is a direct competitor to Twitter, Buzz updates are theoretically low-value, non-critical, skimmable, and okay to completely ignore. Adding an unread count encourages users to catch up on Buzz items as soon as one or more new ones are available. All of the above “features” interrupt workflow, fragment skimming sessions, and ruin the low-intensity “skim, read, and briefly respond” experience.

After all, there’s a reason Twitter isn’t a service that emails you all of your friends’ updates.

Fun	vs.	Stressful
Stream	vs.	Inbox
River of news	vs.	Action items
Twitter	vs.	Email
Unread count	vs.	Recent items
Serendipity	vs.	Obligation

Doesn’t encourage scanning

Inline content (like pictures & video) and comments (as opposed to separate @-replies) are one of the biggest reasons that Pownce and FriendFeed never caught on.

Why? After all, they sound like a good feature; they make it easier to see shared content, right? Wrong. Inline content steales focus.

Inline pictures and videos are all your eye will want to look at, instead of scanning faces, names, and text
They take up room that could be used to fit more (text-only) updates on the screen. This makes quickly scanning updates much more difficult.
The assumption I care about peoples’ replies or “likes” to updates is often going to be incorrect.

Each item in Buzz takes up way too much room. Look at this: Only one update fits on my screen at a time.

The text of each update is de-emphasized by the abundance of text-heavy, shiny, space-stealing options. Just look at this. The dubious value of the “Email” action does not in any way warrant its prominent position here. Two “Comment” links is two too many (okay, at least one), and a simple grey icon would be less distracting. “Like” is way too visually prominent. And just look at all the wasted space and text when I am the only one to “like” something:

What’s up with the visual weight given to the source of each update (Twitter, Buzz, Reader, Picasa, etc.)?

I’m done design-raging now. Time to let my other personality defect shine, and be anti-social:

Too many non-friends

Consider this: I am following Doug Bowman (@stop) on Google Buzz. He’s a pretty popular guy on Twitter, as a high-profile employee of theirs, and good designer, to boot. This means lots of people follow him not only on Twitter but also on Buzz.

When I comment on his status, my his own update shows up in his Gmail inbox so he can see my response. Now, I think I’m a pretty cool guy, but that doesn’t mean Doug does, and I’m going to go out on a limb and say he doesn’t care for every Tom, Dick, and Jane’s comment cluttering his inbox.
Similarly, when someone else comments on or “likes” his update, that update gets promoted to the top of my Buzz feed. That’s ridiculous and confusing by itself, but when I don’t know 90%+ of the people following Doug, there is precious little value to that. It also unfairly makes Doug’s updates much more likely to be read than less-popular Buzzers’, since his are more likely to be commented on and thus more likely to be at the top of my feed when I use Buzz.

We’ve seen all of this before

A year ago, Dare Obasanjo listed these four criticisms with FriendFeed, a service which, like Buzz, allowed people to consume updates from Twitter and elsewhere:

Too few items per screen

Secondary information clogs up each item

Difficult to scan content titles quickly

People who aren’t my friends

Sound familiar? Buzz has those same problems. Does no one at Google learn from others’ mistakes? Does no one at Google read Dare?¹ Sheesh.

How many times has Dare, also known as Carnage4Life, insightfully written about consuming feeds of content? There was Some Thoughts on User Interfaces for Activity Streams, then RSS readers modeled after email clients are fundamentally broken, and finally The Top 5 Reasons RSS Readers Went Wrong, for starters. Update: And just today, he writes about Google ignoring user privacy to give Buzz a competitive advantage. ↩

Qwest Customer Service: Terrible

Wed, 21 Oct 2009 20:22:18 -0400

What would you do if your broadband service with your DSL company ended when you moved several months ago, and out of the blue the following landed in your e-mail inbox?

Notice: Changes have been made to your Qwest® customer profile.

Our records show you recently made these change(s) to your customer profile, either by contacting a Qwest representative, or through your MyAccount page at qwest.com.

Email Address Changes
*The e-mail address you provided for us to reach you.

For Qwest account ending in:7503

At Qwest, we value the security of our customers’ information and are sending this notice as a confirmation. As long as this change was made intentionally, no action is necessary. However, if you feel this change has been made in error, please contact Qwest immediately at 1 866-450-6152(Residential) or 1 800-603-600(Small Business).

Thank you for helping us maintain the security of your account.

[Marketing pitches comprising the rest of the email have been redacted.]

Well I certainly hadn’t made the change, so I called Qwest at the number provided. After being asked irrelevant questions by their friendly and persistent automaton, I was transferred to a real live human operator. I explained the situation.

He asked me a few times if I was sure I hadn’t changed my email address. After finding my old account number and reading it to him, along with my name and address, he informed me my old customer number had been re-assigned to a new customer and I “had probably nothing to worry about.”

“‘Probably’ isn’t good enough,” I replied. After all, they had sent an email designed to alert me of suspicious activity. I hardly wanted my old account to be used to pay for someone else’s Internet service. He then assured me it was a completely new account (without, to his credit, divulging any personal details of the new customer).

At this point it was now clear the alarming email I received should not have been sent and my time was therefore wasted. I asked the representative to ensure this would not happen to other Qwest customers in the future. He refused to do so, saying there was nothing he could do. I did not, of course, expect that he would roll up his sleeves and fix this bug in Qwest’s system, so I clarified by asking that he tell a superior about the problem to ensure it would be taken care off. “I am sure there is nothing they can do, either,” was his hopelessly pathetic, unempowered, uncaring, self-defeating reply. I insisted he try and was promptly put on hold, at which point I hung up, having had enough.

I fault both the Qwest representative and Qwest itself here. The representative clearly didn’t care if the problem was ever resolved, though it would end up wasting more customers’ time and costing his employer money in unnecessary calls to customer support. The Qwest company itself evidently has a corporate culture of apathy and does nothing to empower or educate its representatives to help get real problems solved.

That’s the lesson to be learned here: Tell your employees to do whatever it takes to solve the problem at hand. Tell them what to do when they don’t think anything can be done.

In the past I have had difficulties with Verizon, AT&T, and Cox as well. Is there no decent telecommunications company?

Github Issue Linker

Sun, 06 Sep 2009 03:46:00 -0400

The plugin and what I use it for.

The Plugin

GitHub Bug Linker is a simple Wordpress plugin that looks for numbers with pound signs in front of them and links them to issues in your GitHub repository.

There is a lot of room for improvement:

Doesn’t acknowledge other syntaxes for linking to issues that GitHub supports (like repo/#1).
Doesn’t ignore numbers in <code> or <pre> blocks (straight regexp find/replace).
Would be fantastic if it used the GitHub API to check the status of linked issues and cross off closed issues.

This plugin is based on EHT Mantis and is released under the LGPL.

Download GitHub Issue Linker from its Wordpress Plugin page.

Killer App: Dev team wiki/documentation

I have paired this plugin with a few other Wordpress plugins to create a darned good (programming) project documentation system:

Members Only to keep anyone but team members from seeing documentation¹
Markdown for Wordpress and bbPress because
- it disables Wordpress’s annoying over-processing of content and
- it allows us to use Markdown, my favorite quick markup/wiki syntax (also used on GitHub for everything but their wiki)
Email Users so team members can alert others to new and updated pages
WP to Twitter to populate our private, internal Twitter feed with new and updated documents
highlight.js to automatically highlight any <code> pasted into the content
One of the “Link to Post” plugins to make linking to other doc pages simple

It’s a pretty great system, in my opinion.

Yes, Wordpress allows individual pages to be marked as private, but then they donât show up in the nav, and neglect could expose sensitive information. ↩

Snow Leopard Problems

Thu, 03 Sep 2009 19:56:16 -0400

I installed Snow Leopard less than 48 hours ago. So far, these are the ostensible bugs which I have bumped into:

Upon installation, my system hung on first boot-up. A hard reset took care of that.
Once or twice, my desktop icons were nowhere to be found.
Google Gears doesn’t work in Safari all of a sudden. I had to Google how to uninstall it before Gmail would load.
(Update: Not a Snow Leopard bug, more in a bit.) The top half of my (laptop’s built in, not external) monitor occasionally flashes black for a millisecond. This occurs at seemingly arbitrary times and blackness lasts just long enough to be noticeable and annoying. (I like to imagine that it contains a subliminal message — “IGNORE THIS FLASH” — and I am immune to its effects.)

Update (2009-10-31): It turns out that my MacBook Pro, which has two video cards, has a problem with one of them. (Apple will probably fix this when I ask them to.) Installing Snow Leopard must have switched my setting to use the problematic low-power card. Switching to the beefier card (via System Preferences) has resolved this issue for now.
Spotlight sporadically won’t find the application I was searching for, such as iChat, Keychain Access, or System Preferences. This is important because Spotlight is my app launcher, and now it’s not reliable for that task. Not fixed in 10.6.1. Update (2009-10-31): This problem hasn’t happened for a while. My Spotlight index was rebuilt, so if you have this issue, try rebuilding your Spotlight index.
The “Calculate All Sizes” option fails on some folders of a network drive of mine — even on folders with no more than 8 files. (Added 2009-09-07)
I realize it was not officially supported, but it was possible to back up to a network drive (without an AirPort Base Station) via Time Machine in 10.5 Leopard, but now on Snow Leopard, backups have been hanging indefinitely. (Added 2009-09-07)
Sometimes switching Spaces via the keyboard has left the spaces indicator on my screen after I let go of all the keys, and then I could not use my (MacBook Pro’s built-in) keyboard until I logged out and then back in. (Added 2009-09-08) Update This is still a problem, as of 10.6.2.

You can imagine that some of these quirks are damned annoying.

Still, there have been some really nice little improvements, like the dock & Exposé integration. I think the net change is positive, but boy am I ready for Apple to release 10.6.1 with a few bug fixes! Update, September 11, 2009: I just upgraded to 10.6.1, and some of these issues are still not resolved. I am updating the list above when I know for sure that an issue has or has not been resolved.

Finally, I’d like to note that some of these things could well be caused by third-party apps. That said, it’s clearly the OS upgrade that triggered these problems. Apple, you’ve let me down.

Pasting Unformatted Text on OS X

Thu, 30 Jul 2009 21:21:14 -0400

One of the few default settings that genuinely annoy me on Mac OS X is the tendency for Apple software to retain source formatting when copy and pasting. This can be particularly annoying in Keynote (since pasted formatted text is incredibly small) and in Mail.app.

There are two solutions.

Set Command-V to paste unformatted text all the time:

Simply follow this tip which sets a system-wide keyboard shortcut for Command-V to trigger the menu item “Paste and Match Formatting.”

May not work in all apps, but it should work in most. When it doesn’t, you can use the first tip.
Manual workaround each time:

Use the “Paste and Match Formatting” menu option, or the following keystroke sequence:

Paste into Spotlight search, select it, copy it (unformatted), then paste. This even works for multi-line text.
1. Command-Space (or whatever you have Spotlight set to).
2. Command-V for paste. (The text is now unformatted).
3. Command-A to select all.
4. Command-C to copy that unformatted text.
5. Command-Space to close Spotlight. (Focus returns to whichever app you were in previously.)
6. Command-V to paste unformatted text.
It looks like a lot of work but it is actually very, very quick for me. (I type in Dvorak, but I don’t think that makes a big difference here.)

Nielsen, Password Masking, and the iPhone

Tue, 14 Jul 2009 23:52:29 -0400

This is my reaction to the recent password masking debate Nielsen ignited. Summary: A checkbox to show the password is acceptable (perhaps ideal), but showing passwords by default or using the iPhone-style solution on websites is a bad idea.

Introduction

Recently, respected and influencial usability guru Jakob Nielsen stated that “[u]sability suffers when users type in passwords and the only feedback they get is a row of bullets,” which “doesn’t even increase security, but it does cost you business due to login failures.” This is probably one of his most popular recent alertboxes due to its very controversial nature. Most of the reactions I have heard have been very negative, as Nielsen ridiculously dismisses out-of-hand the potential for shoulder surfers to oversee passwords (“a truly skilled criminal can simply look at the keyboard and note which keys are being pressed”). That is, of course, rather naÃ¯ve. Why not say, “A truly skilled criminal would add a keystroke logger,” or “A really determined bastard could waterboard victims for passwords.”

His final suggestion is to stop masking passwords but to provide a checkbox to enable masking, if so desired, in cases of high security (e.g. bank websites). I find this completely unacceptable for reasons Nielsen himself has enumerated in other contexts.

Regardless, Nielsen does make some good points in his alertbox.

Constraints, concerns, and observations

Nielsen: Being able to view your password instils a sense of confidence and allows the user to ensure they entered it correctly.
Nielsen: Users spend most of their time on other websites.
Those who can’t touch-type have more trouble with passwords then those who can (assumed by myself; should be self-evident).
Nielsen: Users skim, and they read in an F-pattern.
Nielsen: Users have a harder time entering passwords confidently on mobile devices.
Nielsen: …but it’s still not easy on desktops and laptops.
Good mobile devices deal with observation 5 (e.g. iPhone).

All masking, all the time

Pro: Eliminates shoulder surfing.

Con: Doesn’t allow users to check they entered the password correctly.

iPhone style password masking

This is the style popularized by the iPhone, though they probably did not invent it. As Gruber succintly put it:

The iPhone strikes an interesting middle ground here — it shows you each letter youâve typed in a password field for a second or so before turning it into a bullet.

At most one character is revealed at a time. This applies not just for iPhone apps but also for web pages viewed in Mobile Safari.

Some have made attempts to implement this on websites with JavaScript hackery. I think this is an absolutely horrible idea, though innocently conceived. Go ahead, though, try it out if you aren’t familiar with the iPhone.

If Apple thought iPhone-style password masking were ideal for the desktop, as well as for the iPhone, they would implement it on the desktop. They do not.

If someone types fast enough shoulder surfers cannot see the password, then they are typing too fast to get the benefit of confidence that Nielsen described.
If someone types slow enough to get the benefit of confidence, then they are typing slow enough for shoulder surfers to catch the password.

The implementation would be extremely difficult to get right on the Web. I have not seen, and (since the above items make this solution less than ideal anyway) do not expect to see, an implementation that gets it right. A solution would need to prevent plaintext passwords from being shown when JS is off and in all browsers. It should also allow editing a password from the middle, because that’s how it works on the iPhone and in normal password boxes. Those of us with lots of HTML experience can imagine how very difficult that would be to implement. It should not break “wand” or auto-fill browser functionality. Also, going “back” a page in (any and all!) browsers should not show a plaintext password.

Lastly, in the case that browser and/or operating system manufacturers change the way password boxes work (say, with a built-in toggle mode, or iPhone-style on mobile devices), JavaScript methods like this will override that and possible break the password box completely for those users.

Verdict: a bad idea in theory as well as in practice.

Providing a checkbox to enable masking (masking off by default)

Thinking about observations 2, 3, and 4 from above means that any websites with password masking off by default — even if they have a checkbox to enable it — can and will catch users off-guard; some will enter their password before realizing it wasn’t masked. It will be seen. It is irresponsible to pretend this doesn’t matter. Consequences can range from, yes, bank passwords being seen to a friend overseeing a Facebook password and setting an innappropriate status message that the user’s family or boss sees.

Con: Shoulder surfers will still view passwords.

Con: Going “back” reveals the password.

Verdict: Terrible idea.

Providing a checkbox to disable masking (masking on by default)

As I mentioned before, Apple does not enable iPhone-style masking on the desktop. What they often do instead (e.g. when entering network passwords) is provide a toggle (in the form of a “view password” checkbox) so that users may optionally view their password as they enter it.¹ This is a great idea and is much easier to implement than the iPhone-style password masking.

Pro: Enables users to check their password entry if and only if they are confident no one is watching.

Con: If care is not taken to convert the plaintext back to a masked password box on form.submit and page.navigate (i.e when users leave the page), going “back” will reveal the password.

Verdict: Take care of the problem mentioned in “con” but this is by far the best solution.

Conclusion

Masking by default and providing a mechanism to view passwords at will is the best solution.

It should be kept in mind that there are a lot more password-related concerns to keep in mind; consider enforcing strong passwords for users and use encryption, password salts, and hashes server-side.

Windows (XP, at least) does the opposite: When joining — not creating, but joining — a network, it forces users to enter a masked password twice. ↩

The Anti-Competitive Google

Tue, 14 Jul 2009 19:18:05 -0400

Google is betting that the Web is going to continue be a very strong platform. They are betting that web apps will provide a large chunk of our productivity and pleasure, where traditional desktop programs used to.¹ With their strong hand in HTML5, their open-source Gears browser extension, and the drafting of the Wave protocol, Google is loudly proclaiming the Web to be an open environment that no one entity should control. Their actions, however, belie this vision in favor of anti-competitive corporate strategies.

Google’s public vision for an open web

Google has indicated they believe in the Web as an open, popular platform in which anyone who implements the open, published web technologies (HTML, CSS, JavaScript, maybe Gears) — which other companies can help shape and define — can have a browser that can run any web apps and view any web sites crafted to those same standards. (Contrast this with Microsoft, whose past strategies pushed Windows Internet Explorer-only technologies like the insecure ActiveX API and VML, and who would still to this day have us use Silverlight, which does not run on all platforms or browsers, and Web Clips and other IE-only tech).

Google has made the following statements to lend credence to that position:

We are working on (and an employee of ours is controlling) the HTML5 specification, a collaboration between major browser vendors, reducing or eliminating the need for awkward and closed plugins like Flash or Silverlight; this makes the Web an open playing field, and any device and any operating system can now have the full web experience without Adobe or Microsoft’s consent.²
We are writing a protocol called Wave to power the next generation of Web communication and synchronization, and we won’t control it; it will be email or HTTP, a specification anyone can implement without our consent or help.
We wrote Gears and made it open-source, so all browsers (not just ours! cough, cough, Microsoft) may run web apps with features that once only native apps could have, and to speed up certain kinds of sites.
- In the meantime, we released Gears as a plug-in for popular browsers such as Safari and Firefox.
- We built Gears into Chrome, and hope other browsers include it by default in the future.
We believe the Web is going to be so powerful that we announced plans for an OS based on Chrome (WebKit) and Linux (Just like Palm’s Web OS.)

Inconsistencies and other anti-competitive red flags

Let’s examine a couple ways Google has betrayed their publicly stated vision with contrary actions:

Google has a policy of not supporting or testing their web apps in Opera. Opera is a browser that has driven much web innovation (inventing not only tabs but Chrome’s new start page, to name a few) and always supported open Web standards (such as the effort to write HTML5, and in fact, their CTO invented CSS). Opera has very few inconsistencies with other websites.

The problem is so bad that Opera users can’t add Gmail events to Google calendars, and the emails that Opera users send in Gmail suffer collapsed line breaks so that the paragraphs run together. It’s been like this for years.

While I have called on Opera to step it up and fix these issues themselves to enhance their own market share (low market share is a vicious cycle for browsers and other platforms, because low market share means fewer developers support it, which inclines users to avoid it), I would argue that for Google to create and ignore these problems is anti-competitive. (I have discussed this before.)

How is this anti-competitive? It means that a company who makes the world’s best webmail says, “We choose to force 100% of the people who like our webmail to use one of the browsers on our list, and not Opera. In faaact, you will get the best experience in our own browser, Chrome.” What got Microsoft into trouble was throwing its dominance in one software category (OSs) around to dominate other markets (browsers, office suites, media players). To cite market share as a reason to avoid supporting Opera is a cop-out because of the vicious cycle I mentioned above: When you’re a big dog and a trendsetter with lots of cash, you better do the right thing and play fair.

Why is not supporting Opera inconsistent with an open web strategy? Because claiming to support an open-standards-based Web that works on all browsers, including Opera, with whom Google is working on HTML5, but not actually supporting that very open-standards-compliant browser just doesn’t make sense.
Seemingly dropping support for the Gears Firefox plug-in

As I write this, it has been a full 2 weeks since Firefox 3.5 officially launched (on June 30, 2009). There had been completely public betas and release candidates (the last of which, per Mozilla policy, became the stable 3.5 release, bit-for-bit) available for some time. And yet, to date (July 14, 2009), Google has not updated their Gears plugin for Firefox 3.5 (which, among other things, enables offline Gmail and speeds up WordPress publishers’ experiences).

You might be thinking, dear reader, that it could take significant time to update the plugin for Firefox 3.5.Â You would be mistaken, though quite understandably: Users have taken the open-source code, tweaked it, and compiled it to work with Firefox 3.5 on Windows, Linux, and Mac OS X. (This didn’t solve the problem, because Firefox does not know about these unofficial, untrusted fixes and can not/should not make them available via its add-on update routine.)

So it’s not that the upgrade takes too long. Google knew ahead of time Firefox 3.5 was coming and its users showed that the fix is fairly trivial. It’s just that Google is dragging their feet. Because they aren’t replying to users, no one knows why. (Does Google hate their customers? Or are they just arrogant?)

But users have their suspicions. One wonders, and I join him, if this isn’t a deliberate (and shady) attempt to get Firefox users to switch to Chrome. Is it? What other reason could be at play? The only alternative I can think of is just developer laziness and an incompetent manager or two. Then again, many people at Google use Firefox, and there is no way this issue could have gone unnoticed.

How is this anti-competitive? Why is it internally inconsistent? Google says it wants an open, interoperable, Web with a diversity of browsers all supporting the same open standards and ideally with enhancements like Gears (which is, remember, open source) that make for a better experience. But by denying Gears support for Firefox, they are pressuring Gmail users to switch to Chrome; using one product to artificially support another is anti-competitive and any attempt to homogenize browsers toward one (Chrome & the WebKit engine) betrays the vision of the open Web.

True feelings about the open web

I wish I could summarize Google’s true position, but the contradictions here are too great for an outsider like me to resolve. The least we can conclude is their actions are considerably less benevolent than Google would have us believe.

Let me know if you have anything to add.

Update (February 14, 2010): Google Buzz, which I believe will fail, so aggressively competitive that Dare Obasanjo notes they are using privacy as a pawn in a competitive chess game, even if it jeopardizes their very safety.

Hence the Chrome OS initiative. My reaction is between the unthinkingly obsessive Arrington-style “OMG this will be big” and the piffling “won’t be anything” response from others: I think Chrome will be just what it is planned to be, a competent entry for netbooks. That is, no, it won’t ever gain much if any traction on traditional personal computers; but if done well, it could provide a smooth (if limited) experience on small, cheap devices used mostly for email and casual surfing. ↩
Sounds a lot like what Apple’s gung-ho true-web-technology push, as they embrace HTML5 wholeheartedly in Safari, extend CSS in innovative and backwards-compatible ways (transitions, gradients, transformations), make WebKit (the core of Safari) available for anyone to use for pretty much anything (from Chrome to Palm WebOS to NetNewsWire), and reject plugins (as they should be able to do!) on the iPhone. The inconvenience of missing Flash, in my view, is not a poor reflection on Apple but on everyone who has used Flash as if it were a Web technology. It is not. It does not integrate well with the rest of the webpage and needs drawn in a separate pass from the rest of the rendering engine, unlike pure web technologies like HTML text, images, SVG, and even <canvas>. You couldn’t apply a JavaScript event to a Flash movie component. You can’t style Flash text with CSS. You can’t (really) link to a “page” or view on a Flash site. You can’t middle-click a Flash link to open it in a new tab. Flash is its own little island. It’s not the Web. ↩

The Arrogance of Google (and the effect on its users)

Tue, 14 Jul 2009 19:18:05 -0400

Google seems to be letting its arrogance dictate a position of indifference towards customers. I argue this is not a wise move.

Google arrogantly thinks their customers have nothing to say.

It would seem Google bloody hates their users.

How else can you explain they way they make feedback and dialog between users and themselves darn near impossible? Even using a solution like GetSatisfaction.com would be many steps ahead of their current mix of help pages (typically lacking any sort of “contact” link) and groups (in which users are supposed to guess at Google’s intentions and/or solve each other’s problems). I say GetSatisfaction would be quite an improvement because it not only smartly attempts to consolidate multiple questions about the same thing into one page/discussion with a keyword matching algorithm based on questions users type, but critically, it provides the company (Google, in this case) a means to designate an official reply or status at the top of the page. Compare this to scrolling and paging through up to hundreds of posts in Google Groups, hoping you can skim fast enough and well enough to see which, if any, posts are from someone claiming to be a Google employee.

Again, the technology is there. Google has money. So the only reason they would be treating their customers so badly is that Google is so arrogant that they don’t think their users matter.

I don’t just mean users of, say, Gears, or even Gmail. Even customers generating revenue for Google, those using AdWords and Checkout, can’t get a real human to help them out.

The value of listening to customers

I’m sure many others have stated the value of listening to customers much better than I, but here is a quick list of benefits from my experience:

They catch bugs and regressions that developers miss.
They can have great ideas for your product (and are frustrated they can’t share them).
- 425Walker has one for Google’s Blogger service.
- I had a number of ideas for Gmail back in 2005, some of which were eventually implemented; but I never was able to actually suggest them to Google.
- Update (July 15, 2009): As @JamesGecko points out, there actually are suggestion boxes for Gmail and Blogger (in fact, I have used the one for Gmail in the past). However, not only are they hard to find, but apparently no one ever receives personal feedback (is anyone listening?).
They can help you decide which features to implement. (Prime example: UserVoice)
They won’t feel like your company is a giant, unfeeling corporation if you actually talk to them.
Problems can pop up for a particular user, and if these are not taken care of, that user can complain very loudly and/or the service is less functional for them. Additionally, these users’ problems may illustrate an edge case or bug your developers overlooked.
- Example: When Twitter Search didn’t index my tweets due to a simple server-side caching issue, my pleas for help went unanswered for half a year, coming back with robot-generated replies and frustrating me to no end until @tiger graciously helped me out. In the meantime, I began to resent Twitter’s central authority, yearning for a distributed alternative. I also avoided #hashtags altogether as they were pointless; no one could find me on Twitter Search even if they searched for a hashtag I used. Presumably their caching mechanism needed improved.
- Example: Google Calendar’s ICAL feed, which I ensured was not being cached, contained recurring events which I successfully deleted from the web interface; no one at Google ever replied to my requests for help. Obviously, though, there was a bug in their system which made using it highly annoying for me, as I had to ignore events that should have been deleted.

As my last example makes clear, Google could use the feedback of its users.

The cost of listening to customers

Assuming not too much weight is lent to users’ feature requests, the only real cost of listening and replying to them is money (in terms of staff).

Google has plenty of cash.

Google not so feel-good anymore

It seems to me that problem of ignoring users (like their anticompetitive tendencies) is contributing to an overall trend of increased distrust of Google and and increased perception of them as another faceless big company. I hope to write more about this in the future. If anyone has seen data showing the trends I expect, or disproving them, please let me know.

Update (July 15, 2009): Just today, Ani reported that Google’s public perception of being “reliable, distinguished, and the best quality” slipped below Microsoft’s in a British survey.

Update (February 14, 2010): Google Buzz, which will fail, is another example of Google doing whatever it wants and not caring what users think, even if it jeopardizes their very safety.

Import the iPhone User Agent into the Firefox plugin User Agent Switcher (download)

Wed, 20 May 2009 15:11:58 -0400

You can import this XML file into your User Agent Switcher plugin for Firefox so you can view and test the mobile or iPhone version of a site. The user agent string is the one described in this tip. (After installing User Agent Switcher, restart Firefox and go to Tools • User Agent Switcher • Options and click “Import.”)

Also of note is that the iPhone Simulator (part of the iPhone SDK from Apple) does include Mobile Safari and can actually navigate to your local development site (e.g. localhost:3000 or any other server running on your computer), not to mention the Web at large.

If this becomes painfully out of date, let me know by my contact form or twitter.