

Google-owned YouTube announced they now allow you to upload subtitles for your videos. These will display in the video if the user expands the menu at the bottom right of the player to enable the captions, as in this CNet video. The supported formats for captions are Subviewer and Subrip (*.sub/ *.srt). To upload such a definition, visit your video’s edit page (accessible via Account -> My Videos) and switch to the Captions entry on top. For each video, you can also upload captions in several languages.
It’s an important feature, but YouTube’s tools are often not the most innovative; in this case, an additional web-based captions editor from YouTube is missing. YouTube suggests a couple of caption editing programs on their help page. Captions don’t seem to work with embedding yet.
[Via Ionut!]

Google search result advertisers who sell products through Google’s Checkout program get the special benefit of having a visible icon next to their ad (“Your AdWords ads will stand out”, as Google says). This could be an incentive for sellers to use Checkout, as the Checkout program has been struggling in the past (judging from e.g. Google’s extensions of free usage for sellers). Now, Google has been seen experimenting with an even more colorful version of the Checkout badge, which in this case is placed in a pet food ad and reads “$5 off!”. It’s getting kinda cheap. The pet food, I mean.
[Images from WowFeed and Search Engine Land, with hat tip to Steve LaLonde.]

SUP stands for Simple Update Protocol (officially, anyway, though it’s perhaps an acronym or backronym for “what’s up” aka “’sup”). It’s a JSON-based meta format for RSS/ Atom feeds useful for websites that deliver a large number of feeds, like a blogging platform, so that services subscribing to that site’s RSS feeds only need to download a single file to check for updates, and then download the other individual feeds as needed. SUP was invented by the ex-Google employees Paul Buchheit and Gary Burd of (recently redesigned) social feed aggregator Friendfeed. There is no official documentation at the moment outside of the Python source.
Friendfeed’s aim in introducing the format is to decrease the load in polling so many feeds from all over the web all the time (a polling that’s typically done whether or not the feed changed since last time). After all, that’s one of Friendfeed’s problems, too. “FriendFeed’s user base has grown quite a bit since launch, and our servers now download millions of feeds from over 43 services every hour,” Paul Buchheit writes in a blog post announcing SUP. A SUP feed can thus serve as first stop for feed readers to see if a feed changed, and the SUP file will only include the changes since the last SUP in a specified frequency – like 3 minutes – was published. (I remember Google’s Blogger once had such a “what’s new” file in XML format, but I’m not sure they ever attempted to turn it into something like a standard.)
So, all of this means SUP is not a competition to RSS feeds, but rather it’s a level above “watching” over it to make site updates be known faster and easier to other sites, due to a lowered load for publisher and reader programs. For sites with only a single feed or two (like Blogoscoped.com for instance) there seems to be no immediate need to support SUP (I’m not sure if it would be a speed win with Friendfeed). “[T]he benefits are most significant when the SUP feed covers a large number of other feeds,” Paul says. On the other hand, from an aggregator’s point of view the SUP format also requires you to set up a system that doesn’t miss out on its polling in the defined frequency, or else your program may miss feed update information (a look at the SUP’s time stamp could help find out about this). Paul in an email says, “SUP consumers must be somewhat intelligent when consuming feeds in order to poll at the appropriate frequency, but our goal was to make things as simple as possible for SUP producers in the hopes that most sites will be able to quickly implement a SUP feed.”
As for the syntax itself, why the choice of JSON over, say, XML? In popular browsers, XML can be checked for well-formedness and also displays somewhat formatted when directly opening it. Paul comments that JSON (JavaScript Object Notation) “is a very simple and common data format that is now supported by just about every common language ... It is also very compact, which is a real advantage for SUP feeds that may have thousands of entries. An XML-based SUP feed could be easily generated, but it’s not clear that there would be any advantage (and it could easly end up being 3-5 times as large).”
At this time, not even Friendfeed itself has SUP reading support (they do have a SUP feed), but Paul says “it should be ready soon.” As SUP is so new it’s hard to tell who else will adopt the format. Paul states:
I’ve spoken with several sites, but we’re not yet ready to make any announcements.
We would like for everyone to support SUP, however Blogger already pings several blog ping services, so the benefit may not be as significant as it is with other non-blog services. One other issue with blog feeds is that many people send their feeds through Feedburner, which introduces additional delay (meaning that even after a new blog post is published, it may not appear in the RSS feed for some time).
A great example of a service that would really benefit from SUP is Google Reader. The Reader shared items feeds have “secret” urls that Google does not want to publish, so a traditional blog pinging service is not viable for them. Using SUP, they could easily notify feed consumers such as FriendFeed of which feeds have been updated without having to disclose any of the secrety urls.

Google’s YouTube has a video identification system available to find copyrighted content. Google says there are currently 300 content-owning partners available who can be alerted by the system and who then face the choice of blocking the video, promoting it*, or getting a share of the ad revenues from YouTube (money from which the one who uploaded the detected video will not see a share, according to the New York Times, though I guess they can display some of their own links and so on in places like the video description snippet). Interestingly enough, Google says content owners participating here choose the third, seemingly more sensible model, around 90% of all times... making money from their content which was not uploaded by them.
[Via Andy.]
*I asked Google what exactly that option means (will it be pushed as partner video?) and will add an update if there’s a reply. If you know please comment.
Update: By “promoting it”, Google means to “leave up on YouTube, but without monetizing”, they say.
When Ron (of Totlol.com) searched Google.ca for iphone recently, he hit upon what looks like an experimental video onebox result. Instead of the usual thumbnailed videos displayed in list format, this box was showing two videos results side by side below the headline “Video results for iphone”. Both in this search as well as in a search for love, all videos part of that onebox were from Google-owned YouTube.
In 2006, briefly before the YouTube acquisition another type of video onebox was showing, displaying 3 thumbnails with the video titles below the thumbnail.
[Thanks Ron!]
When you enter obama08.com into your address bar, you’ll end up on a Google search for [Barack Obama]. This isn’t any browser fallback for a non-existing domain or something... http://obama08.com actually has a temporary HTTP redirect towards that Google search URL. (Anyone could set this up, but I’m curious who did this and why – I can’t seem to find any good info in a Whois query or on the Wayback Machine.) [Thanks Andreas Schneider!]

Google just announced they will start to roll out Google Suggest as a default feature for the Google.com homepage over the next week. For instance, when you enter “presid” with Suggest, below the search box choices like “presidential polls, “presidential election” and more will pop up, to be selected and then searched for using e.g. the arrow and return keys.
Already, besides the Google Labs experiment which started in 2004, auto-complete features are available on the homepage of Google China*. As I’ve never been a regular user of Google Suggest I’m curious if that feature will be useful or annoying in the long run during daily usage. Google is convinced that it 1) helps formulate queries, 2) reduces spelling errors, and 3) saves keystrokes.
Also see the Google Suggest FAQ.
[Thanks Martin Porcheron!]
*Among other Google places. In China, the suggestions also work as transliterator from Pinyin to Chinese, though that’s not the case with the main Google Suggest.
I asked a couple of people to draw the Google homepage with their eyes closed during the whole drawing process. Here are the results:

Brinke Guthrie’s minimalist approach.

Pascal of the German GoogleWatchBlog created this one. He says that “...schland” ended up on the table.

Google’s Matt Cutts created this one with eyes closed...

... and this one with eyes opened, but from memory.

To my defense, immediately when I started drawing the search buttons I realized they belong below the input box (and I realized I misplaced the privacy link at first!). Only on search results is the search button placed to the right side.

Drawing by my sister Judith.

TomHTML of the French Google blog Zorgloob.
Feel free to join with your drawing in in the comments (but don’t look at the paper during drawing)!
Also see Google recreated from memory.
[Thanks to all participants!]

Google has a new direct result showing translations, triggered for certain queries. Here are some examples:
Here are two sample queries which specifically do not trigger the onebox:
All in all such a translation onebox if done right would be an incredibly helpful feature. I’m currently using a Firefox search box connected to Leo.org for English to German translations, and I’m referring to it quite frequently. However, the quality of the translation onebox by Google is surprisingly bad... it just doesn’t always find the most appropriate words to look up in the dictionary. Even if we’d assume the translator would be right 70% of the time, it would still be almost useless because if you don’t speak the language you also can’t easily verify whether or not you’ve hit on one of those 30% bad results.
Also see Google’s translate gadget, available as a “subscribed links” feature to add to your results, and Google onebox results we still need (from 2006)..
[Thanks TomHTML!]

Christopher Finke’s Firefox extension YouTube Comment Snob hides all YouTube video comments which meet certain criterias like comments without capital letters, comments with excessive punctuation, comments with over 2 spelling mistakes and so on. Google has another way to deal with comments at YouTube, at least if you look at their authors at Google series: they disable them altogether. LOL!!!
[Only install Firefox extensions you trust and know that sometimes they may cause problems like crashes with Firefox. Via Waxy. Screenshot source Creative Commons licensed by Andy Baio.]
Many web forms are broken, usability-wise. Knowing these problems can make you avoid them when you design your own web forms, so here are some recurring usability pitfalls.
1. The risky reset button. In most instances, the form reset button is not needed, though it can almost always do harm if users accidentally click it – because it will empty the form without any confirmation box (in popular browsers and popular form implementations, anyway). Take a look at this brilliantly bad-designed German form; it’s meant to calculate the subway route from one place to another:

The quick solution: don’t use a reset button. (And if you do decide you need one after careful consideration, use it with great care.)
2. Choices are good, right? Not really, at least not when it comes to web forms. Only offer the choices absolutely necessary in the context of what the user is trying to achieve – everything else can clutter the screen, add confusion, and actually make the user miss out on taking time to reflect on those choices which are needed and which are important. Isn’t it ironic that most forms on the web which are doing something infinitely simpler than, say, a Google search across billions of documents, are still infinitely more complicated to use than Google’s form?
If you absolutely do need a lot of choice, consider hiding the more rarely used choices within an expandable advanced dialog. Consider how Wikipedia changed their syntax quick picker dialog (while editing a page, you can click on the links below the editing form to have that bit inserted into the page) from showing all and too much, to showing just a little, sorted by topic via a select box.

3. Forms are still part of the web page, and the web. As such, they should adhere to basic web usability rules like making fonts big enough to be readable, and making links look like links and making non-links not look like links. The common way to make a link look clickable is to use an underline, or using blue. But take this Hotmail sign in form – can you guess what’s a link and what’s not just by looking at it?

It turns out the top text (“Have an MSN Hotmail...”), which is blue and thus looks linked is just an info message which doesn’t lead anywhere else. The bottom text (“Use enhanced security”) on the other hand is a link, even when there’s no visual clue provided to get the point across.
Another recurring problems is that form success and failure are not using distinctive color schemes. Do not print a success message in red, for instance... no matter what words you type for that message – say, “Your form submission was a success, congratulations!” – the red color can cause a second of confusion. Similarly, symbols that can be interpreted as warnings should be avoided on mere informational messages.
4. You do the math. Don’t require operations to be performed by the user if you can do it automatically with your script. Take the time zone converter below, a useful tool that can make you arrange a schedule when your friend lives across the ocean.

This service offers two basic options: convert from the current date, or convert from another, defined date. However, when you define your own date & time in the boxes displayed in the middle, this value will be ignored when you hit submit... unless you also checked the “Use the following Date/ Time” checkbox. The obvious thing to do here would be to automatically check the “Use the following...” box as soon as the user enters a custom date (why else would they enter it if they don’t want the form to handle it?).
5. Do not require the user to precisely hit a radio button. Instead, make the text next to the radio button itself clickable. This was common interface tradition on Windows once though it’s ignored by many web forms... even when HTML provides a really easy way to do it (it doesn’t even require JavaScript). The form below, taken from Google Sites, is an offender of this rule as well, as clicking on the “Put page under...” label doesn’t mark the box next to it checked:

6. Don’t force the user towards your custom date picker or other widget. Date pickers in the form of an expanding calendar widget can be a nice thing, but sometimes a user may just wish to enter the date on their own, as plain text (say, by typing “2008-12-24”). If you do decide you need a calendar picker widget, then don’t force the user to use it by e.g. popping it up over the input box as soon as that box is focused. The official German train route calculator form is an example of this – as soon as you select the input box it pops up a calendar widget, but even when you manually entered something and then clicked another input box in that form, it won’t close itself (so you always need to hit its close button).

To see a more usable example, take a look at the event editor part of Google Calendar. When you edit the event date or time, the widget will pop up but in general doesn’t get in your way if you don’t want to use it, letting you enter free-style text instead.
7. Your Ajax change may be too subtle. Sure, Ajax is the greatest web thing since the title tag, but that doesn’t mean it can’t be abused... because it can, in plenty of ways. One such way is to provide form feedback – say, “you’re now logged in” or “there is an error with your form input” – in the form of a subtle Ajax update to the page somewhere which the user can easily miss. In such circumstances, repeated clicking of the Submit button won’t help, and the task results in confusion. Too-subtle layouts for important messages are always bad but at least when there was a page switch and the accompanying visible loading time, users were more carefully looking for that message.
If you give Ajax feedback to form problems or successes, make them very highly visible. Consider that the user might even have switched to another browser window after hitting submit, figuring that it may take some seconds for the submission to get through; upon returing to your site’s window, will that user get your message... or believe the form submission got stuck?
8. 3D effects in input boxes can look oldfashioned and sometimes ugly, but don’t remove them or all 3D color cues unless you’re aware it might add confusion. If you’re using a default input box, it will render with a slight 3D inset border in popular browsers. If you render a white box on a white background, try not to remove the 3D effect completely, as it makes the input location look less like, well, a place to input text. The same goes for 3D outset borders used on buttons, which look much less clickable without borders. However, I believe you can try to get away removing much of the 3D effect if you use clear color cues and the form is rather short – like a darker form background with a white input box on a single search box. I’m somewhat undecided on this though, but you can judge for yourself:

9. If the data seems OK, then give it a go and don’t ask for another confirmation, and don’t ask for the data to be provided in the very precise form your database needs it. Some web forms convert data like a free style address input by the user to their own “correct” database format... and then offer it as part of a combo box for you to confirm again. If however the form realizes that with good certainty that combo box selection was indeed what the user was after, no such confirmation should be necessary to see the results – instead, there could be a less obtrusive option somewhere below or above the result page which lets the user optionally select other, perhaps better values.
Even other forms force the exact database syntax on the user. If however e.g. your credit card number checker doesn’t accept blanks, then just handle this fuzzy and remove them, and don’t require the user to remove the blanks on their own.
10. Yes, selling detailed user data can get you rich quick (or so I heard). But that doesn’t mean collecting an abundance of information is the right thing to do for your web service. If all you offer is, say, an email service, then how important really is the gender of the user, or their home phone number and so on? The best web forms try to restrict the data to just those things absolutely needed for the service to work (plus, where necessary, fields required legally, or for security reasons... like those awful captchas, which are a big usability problems with forms today).
There are many other usability guidelines which help as well. Like keeping your text short, which is always good for interfaces. Also, use positives in text when asking for the user to make a choice; it’s more intuitive to understand a checkbox reading “do this” or “show this” than one reading “don’t do this” or “hide this” (not to mention quasi double negations like “don’t hide” and so on). And once the form is submitted, it’s important to actually send the user to the most appropriate follow-up location for the task at hand (if the task is not finished yet), and not just to a general “thank you” page. And whatever you do, you need to realize that your users spend most of their time on other web forms, so sometimes the optimal solution might just be to copy what people are used to and already understand – and you need to consider that people may have multiple windows open and just treat your form as a side-task, perhaps giving up on it if they find it doesn’t do what they were expecting.
In the end, most things that make a good form good are common sense, so it just takes time to reflect on your form and look at it from an outsider perspective... by trying to imagine what it looks like to someone who doesn’t know (or care) about your database structure, your many considerations, or the history of your product. To the user, your form is likely not the task in itself, but a necessary obstacle to achieving that task. Better design it like a traffic sign (to be glanced at while driving by at 100 km/h) than like, say, a book (which you’ll open sitting in your armchair with lots of time on your hands).
[First Wikipedia screenshot by ITDL.org.]
This video is from last week’s annual Google Dance event, which allows Google and non-Google employees to meet up after the Search Engine Strategies. The robot shown in the video costs around $1000, depending on the version. As for the digital caricature drawings that were made, I’m not sure which tool they used but the Cintiq is available from around $1000-2000. For comparison, there’s some pictures from 2002 available (with people like Marissa Mayer and Larry Page showing up). [Thanks Ross Dunn!]
This site unofficially covers Google™ and more with some rights reserved. You can subscribe to the feed, email your tips and join our forum!