View on Google+

No, I’m not sorry, Wunderlist!

Disclosure: I work at Google, but I’m unaffiliated with the Android team. This blog post reflects my own personal opinions, not my employer’s.

Better Apps

• Native Gmail. Which means you can get Conversation View, colored labels, stars, search and spam reporting right from within the app. Apple’s draconian rules prevent any other email client from being accepted into the App Store.
• Turn-by-turn Navigation. This has got to be the killer feature on Android. Using the in-built Google Maps app, pick a destination, and ask Android to navigate to it. Then keep doing other things such as checking email, or viewing Facebook — of course, only if you’re the passenger, not the driver. The app speaks directions as the car drives, and uses text-to-speech technology to speak names of streets and cities, so you don’t have to ever look at the phone — focus on the road. The iPhone’s Maps app is terrible in this regard.
• Full Google Voice integration. Android allows any application to hook into its innards. So when you use the Google Voice app, it replaces the actual telephone dialer completely. The iPhone app is not permitted to integrate fully, so it does what it can as a second-class citizen on iOS. (If you’ve ever used Google Voice on the iPhone, check your call log: it’s littered with the behind-the-scenes numbers that Google Voice connects to, not your actual contacts’ phone numbers. There is nothing that the Google Voice app can do about this.)
• Widgets on the home screen tell you important bits of information with a quick glance. I use the Pure Calendar widget to see my daily events without having to start up the calendar app. It’s there, it’s ready, and it’s opportunistically visible even when I didn’t pull out my phone to check my schedule.
• Crop your photos before posting them. The default photos app lets you crop your photos before you post them via email or to Facebook.
• Double-click to reflow text in the browser means that you no longer need to scroll horizontally to read articles formatted for larger screens. Double-clicking in a block of text doesn’t just zoom into it (like the iPhone also does), but it also reflows the text maintaining a minimum readable font size to fit within the horizontal dimensions available (which the iPhone does not do.) You have to experience this to see what I’m talking about.
• You don’t have to wait for an app to update its data. Apps such as Twitter and Facebook can run in the background and update their data, so when you pull out your phone, they already have the latest tweets and status updates up on the screen. On the iPhone, these apps can fetch data only after they’re fired up, which means you must wait until they’re done fetching before you see the updates.
• Sync photos from Twitter & Facebook Contacts. Just enable Contacts Syncing, and start seeing your contacts’ photos from their Twitter and Facebook profiles when you dial their phones.
• Bluetooth-related apps can do amazing things! I use the Car Locator app which comes with a Bluetooth plugin; once you pair it with your car, it will auto-detect your car’s location the moment the Bluetooth connection is lost — i.e., as soon as you park and shut off the car. Apple does not allow apps to do things like this on iOS.
• Barcodes scan quickly with live video capture. On Android, the barcode scanner app has full access to live video when you fire it up. This way, it can constantly refine its view and try to locate a barcode within the field of view. On the iPhone, you have to fire up the app, then 1) take a picture 2) crop it 3) click a button to acknowledge that this is indeed the picture you’d like to use 4) wait to see if the app recognizes a barcode 5) rinse, repeat until code is recognized. On Android, you keep waving the phone at the barcode for a few seconds until it recognizes the code. Zero button presses.
• Switch out of Silent Mode automatically after a preset interval: I have missed several calls because I forgot to switch out of silent mode when leaving the office. Phone Silencer is an app that shows up when you put your phone in silent mode using the usual way (power button, or turn ringer all the way down), and asks if and when you’d like to revert to normal mode. You can pick a time and a volume setting, and the app makes sure you don’t miss a call (well, at least for this one reason.) iOS will not and cannot let apps do such a thing, because silent mode is controlled by a hardware button.

A True Post-PC Device

• Contacts sync over the air. Because a true post-PC device does not require to be synced with a computer every time. On Android, I edit my contacts within Gmail on my desktop, and a few seconds later (yes, seconds; usually about 2 to 5), the contacts on my phone are updated automatically. And vice-versa.
• Apps are installed over the air. With the new Android Market, if someone shares a link to an app while you’re using your computer, simply login and click to have the app sent to your phone. When you take your phone out of your pocket eventually, your shiny new app is there, waiting for you. No connecting to iTunes (or other desktop software) required.
• Sync your photos online as soon as they are taken. You can have an app upload your photos to PicasaWeb as soon as they are taken, so you never have to connect your phone to a computer to get them off it. Lose the cable.
• Full multi-tasking. If you click a link in your email app that opens the browser, clicking ‘back’ will take you back to your email app. If you click a link to a map from within the browser instead, then clicking ‘back’ twice will take you exactly where you expect it to.
• You can skip carrying a laptop. Android lets you download, copy, move and send files by email. Any type. This means that you can actually skip carrying your laptop on trips, and have a device that will let you do all that you want with it. No artificial limitations. If someone sends you an archived file, you can open it, browse it, email it, move it into your Dropbox, …
• Data is easy to get in and out. iTunes not required. If you’ve ever tried to copy music to your iPod/iPhone from a computer other than the one it’s synced with, you know what I’m talking about. I could never get a file out of an iPhone unless it was a photo. Android lets me move, copy, delete, do whatever with any file on the phone with a standard USB cable.
• Not really about being a post-PC device, but: Charge your Kindle and Android phone with the same cable. Depending on the manufacturer of your Android phone, you might just be able to charge it with the same charger as the Kindle (Micro USB) so you need to carry one fewer charger while traveling.

User Interface Niceties

• A consistent, global back button.. You know exactly how to get back to the previous screen in any application, and don’t have to rely on the developer of every single app putting a Back button in a consistent position. Ditto with the ‘menu’ button — it’s always where you expect it.
• Instant previews of incoming notifications. It’s better than a cryptic numeric badge on top of an app icon. You don’t have to fire up an app to see the new email or text message you just received, or a notification when someone mentions you on Twitter. The pull-down notifications area scrolls a quick preview once, and after that, it is available to scan quickly.
• You can tell if you’re typing in upper case or lower case, because the keyboard keys change accordingly.
• Unlock your phone with a pattern instead of using a PIN. Of course, if you’d rather use a PIN, you have that choice too. You, as the user, are in complete control of your experience.

And finally …

• Freedom. I cannot stress this enough. With Android, your phone is yours. It is not rented from a corporation who decides what you can and cannot install on it. If you don’t want to upload your app to Google’s Android Market, upload it to Amazon’s Android Market. Or put an .apk file on your server, and distribute it yourself. You don’t have to pay anybody 30% for the privilege of dictating to you what you are allowed to do with your phone.

(Because 16 is as good a number as any.)

Much has been said for a long time about making your URLs easy to use, remember, type, hack, and spread virally. There is still no dearth of ugly URLs all over the Web. A few very popular content management systems also engage in dirty URL practices, and it’s a shame. To aid you in cleaning up your URLs, here’s a list of specific things that do not belong in a URL.

1. www. We’ve spent enough time with the World Wide Web to know that web pages reside on the WWW. Adding those four characters to the beginning of every single URL not only requires users to type them in every time, but also requires 4 extra bytes in every single database that stores URLs. Think for a moment how many bytes that would be. Get rid of them! And after you do that, make sure all your www. URLs redirect to the non-www. version.
2. Port numbers. Unless your site is under test, there is no valid reason for hosting it on a non-default port (i.e., a port other than 80.) Apache on Mac OS X has a performance cache that runs on port 16080, and makes every URL of the form http://your-site.com:16080/. Unless you find a mechanism to run the performance cache on port 80, it is a good idea to dump the cache. It’s not worth the confusing URL (to most users, if not to you.) Standard well-known port numbers are there for a reason.
3. Index filenames. Filenames such as index.php and default.asp do not give us any more information than the rest of the URL. Drop them.
4. Details of the server-side technology. Your users don’t need to know what software you’re running behind the scenes. They couldn’t care less about whether your pages are .php, .jsp, .aspx or .do. It’s best to configure your server to hide these extensions, and then make sure none of your URLs contain them.
5. Special directories for special scripts. You no longer need to place your scripts in a cgi-bin. Get rid of that directory and any others like that. If your server requires you to do something like that, either find a way to configure it correctly, or upgrade to one that will let you do that.
6. Document maintainers’ names. Often, when each document has an assigned maintainer for some duration of time, those documents end up being in that particular person’s web space. Later, when the maintainer moves on or someone else takes over the maintenance, you’re left with a different URL than what you started with. To avoid this, it’s best to categorize documents by topic and subject instead of under ~username/document.html.
7. Internal database IDs. Sure, your content management system needs those IDs to locate your content, but your users don’t need to know. If it takes an extra database lookup to get the ID from the URL, then so be it.
8. CMS Module Names. Use a CMS that is intelligent enough to render a page without needing all sorts of information stored in the URL. Joomla is particularly notorious at this. What does this URL tell you about where it will take you?
   

   http://www.joomla.org/content/section/1/74/

   Now what if it were:

   http://joomla.org/news

9. MiXeD-CaSe NaMeS. Don’t confuse your users by-Mixing-Upper-case-and-Lower-case-Characters-in-the-URL. Stick to lower-case letters, and don’t make them guess. If your user actually types in a URL in mixed case, normalize it on the server and serve the appropriate case.
10. Random gunk. Unless you are a URL-compressor service such as Tiny URL or SnipURL, forget using random characters in your URL. Nobody wants to visit http://yourdomain.com/WijHyYQnVPWNs and guess what it might lead to.
11. Session IDs. Make sure no user-session-specific identifiers end up in your URLs. This makes sure that users can pass on URLs to other users via email or IM, be able to bookmark them, and be sure that they represent a single resource. There are better places to keep session state in.
12. Punctuation. Avoid punctuation that might make it difficult for people to tell others about your wonderful site over the phone. The only punctuation you may have is a hyphen ("-") and HTML entities that have special meaning (e.g. ?, #, :, + and @). No underscores, commas, periods, brackets, parentheses, braces, quotes, less-than, greater-than, equals, or pipes.
13. Database query details. If your web pages have even a hint of database query language in the URLs, you should be on The Daily WTF.
14. Repeated domain name. If the address of your web site looks like http://your-site.com/your-site/your-page.html, then you should have a chat with your web hosting provider about how to shorten it to http://your-site.com/your-page.html.
15. Inconsistent naming. If you sell several products, then make the subdirectories below each product name exactly identical. If someone were to replace a product name by another, the rest of the URL structure should still continue to function. In other words, strive for consistency in naming.
16. Missing content at each level. When a URL is several levels deep, users should be able to chop off parts at the end ("hack the URL") and still be able to get to a usable page. E.g. if you’re a news site, and if an example URL looks like: http://my-news-site.com/2008/05/21/news-story.html, make sure you include a list of news articles from 21 May 2008 at http://my-news-site.com/2008/05/21/, and a list of links to daily articles for the entire month of May 2008 at http://my-news-site.com/2008/05/.

There are some easy technological solutions to make this work. Many of these do not require you to change the underlying file system structure or database structure.

But most of this comes with discipline: there is nothing here that is technology magic. It is just an application of common sense to a common domain (no pun intended.) Google mod_rewrite and content negotiation to get started.

It’s not funny how many cultural, socio-economic, and even religious assumptions can be implicit in the design of a simple form. Here’s the form I was greeted with today when I tried to log on to ShareBuilder. Note, I don’t want to single out ShareBuilder here; many other companies have such silly forms as well. But it just so happens to be the form I chanced upon today.

Here’s a list of the assumptions made by whoever was tasked with designing this particular form. It’s quite easy to see why these assumptions are not universally applicable. Though not outright discriminatory, these questions suggest a subliminal discriminatory preference for car-owning, married people, both whose parents are currently alive. And no, you cannot create your own questions.

1. “What was the make (Chevy, Ford, Honda, etc) of your first vehicle?”
   This question assumes that you own a vehicle. Many people in several countries worldwide do not own a vehicle, either by choice, or because their governments had the good sense to invest in public transportation instead of highways.
2. In what city does your father currently live?
   This one assumes that your father is currently alive. This doesn’t sound discriminatory until you realize that it is far more likely for younger users’ fathers to be alive than older ones’. There you go: it’s ageist.
3. What is the first name of the maid of honor at your wedding?
   This question assumes (1) that you’re married and (2) that you follow a religious tradition where the concept of ‘maids-of-honor’ exists in relation to weddings.
4. What is your mother’s father’s first name?
   This is probably the only question that’s universally answerable.
5. What is your father’s middle name?
   This particular question assumes that everyone has a middle name. I know people from a lot of communities where there is no concept of a middle name.
6. What was the first name of your manager at your first full-time job?
   This question whispers: ‘Hey students, hope you’ve had at least one job so far in your career, else we don’t quite want you here. Now go away!’
7. In what city were you married? (Enter full name of city)
   This one (again!) assumes you’re married. If you happen to be gay or lesbian in the wrong state or in the wrong country, you’re not even granted the right to marry, so making an assumption about marriage is adding insult to injury.
8. What was the name of your first pet?
   Everyone’s had a pet at some point in their lives, right? </sarcasm>
9. What color was your first vehicle?
   Again, this assumes you have owned a car in the past.
10. In what city does your mother currently live?
    Finally, this one assumes that your mother is currently alive. (again, ageist as in the second question.)

We have—thankfully—grown out of the age of blatant racial or gender discrimination (for the most part). But behind every user interface widget and every design decision we make is an invisible representation of the subconscious biases we hold in our minds. If you build a team comprising only of like-minded individuals from similar backgrounds, this is the kind of sign-up form you get. If your team includes people who have experienced a rich diversity of life experiences, you can bet their designs will be much more universal.

In this post, I have typeset many more sentences in bold than I usually do, so readers can quickly skim through it.

I applaud the efforts of U. Colorado’s EPIC Group in assisting the victims of the Haiti earthquake in calling for help using Twitter, and to make their tweets discoverable and actionable. I just performed a Twitter search for the terms #haiti -RT -http (includes all Tweets tagged #Haiti, except retweets or links) to inspect some of the tweets that are directly related to happenings on the ground, and they are (as expected) only a minuscule percentage of the total number of tweets about #Haiti. Syntax is thus sorely needed to achieve a decent signal-to-noise ratio to assist relief efforts.

Though, in my opinion, the current version of the tweet syntax seems too formal, too rigid and a tad too complicated for victims or rescuers on the ground. I am a programmer, and even I had trouble mentally parsing a few of the examples provided. We must keep in mind that Haiti is a bi-/tri-lingual country (and neither of them is English), so any syntactic terms used should preferably be semi-obvious to non-native speakers of the language as well as rescuers.

Roles of Microsyntax

1. Make tweets discoverable: Microsyntax can assist local search-and-rescue efforts and unaffected Twitter users in determining if a tweet is actionable. This task is partly a Signal Detection Task and partly a Data Mining problem. In both situations, microsyntax can prove helpful: all that’s needed is a single tag that emphasizes that a particular tweet is actionable (versus not), e.g. #haiti #rescue (or #haitirescue, to avoid having to type a second # (hash) sign). This will greatly increase the sensitivity parameter d’ of the signal detection task.
2. Make data mining easier: Once a tweet has been detected to be actionable, its contents must be parsed into a form that local efforts can take action upon. While it’s true that all the other proposed microsyntactic tags make it easier for applications to parse the data, this is at the cost of requiring users to learn new syntax. This seems to me a little too much to expect from victims of a recent calamity of this scale as well as from rescue workers with other higher priorities. Instead, as long as our tools can identify relevant tweets, computers should be able to perform the second task of parsing locations, names, and verbs from tags quite easily.

Also, microsyntactic terms need not always be prefixed with # (hash) signs; they are often difficult to type using cell phone keyboards, and on some handsets, may hamper input methods such as T9. Because of the intervening # signs, Tweets containing the proposed microsyntax decrease typographic readability for someone browsing through tweets.

To summarize, this imposes a heavy cognitive load on victims and search-and-rescue efforts while making parsing easier for machines. However, the task of parsing details from tweets can also easily be performed by large numbers of humans a.k.a. crowdsourcing via volunteer efforts or via tools such as Amazon’s Mechanical Turk.

Simpler, Lighter Microsyntax

The following are examples of microsyntax that are more readable, yet also parseable by machines. All situations are based on the ones in the original proposed microsyntax. Most are directly based on the EPIC microsyntax, with a few simplifications.

• Rule 1: Always write in the third-person. This takes care of part of the name problem.
• Rule 2: Instead of using #loc for locations, use “at”. It’s much more natural and not much more difficult to parse.
• Rule 3: Verbs are actionable. Not syntactic verbs, but English (or French or Haitian Creole) verbs. It’s a trivial task to populate a tool with a dictionary to detect all word forms correctly.
• Rule 4: Anything that cannot be parsed ends up as the equivalent of the #info tag (see EPIC syntax).
• Rule 5: The entire text of the tweet should always be available to a human, so whatever information was incompletely parsed can be understood manually, and optionally added to the parsed version by a human.

The general aim is to require as little syntax knowledge as possible, and to keep as close as possible to the natural way people write tweets.

Examples

TWEET-BEFORE: Sherline Birotte aka Memen. Last seen at 19 Ruelle Riviere College University of Porter a 3 story schol building
TWEET-AFTER: #haiti #ruok #name Sherline Birotte aka Memen. Last seen #loc 19 Ruelle Riviere College University of Porter #info a 3 story schol building
Simplified Microsyntax: #haiti #rescue Looking for Sherline Birotte aka Memen. Last seen at 19 Ruelle Riviere College University of Porter, a 3 story school building

This tells the computer us:
What = Looking for someone.
Who = Sherline Birotte aka Memen (identified fuzzily based on initial capital letters)
Where = 19 Ruelle Riviere College University of Porter (automatically parsed based on “at”)
What else = “a 3 story schol building” (i.e. everything else in the tweet)

TWEET-BEFORE: Mirna Nazaire lives in P-A-P at Bizoton 6#12. Entire neighborhood without food. People are dying.
TWEET-AFTER: #haiti #need #food #name Mirna Nazaire lives in #loc PAP at Bizoton 6 #12 #info neighborhood w/o food. People dying
Simplified Microsyntax: #haiti #rescue Mirna Nazaire at PAP at Bizoton 6#12 needs food. Entire neighborhood without food. People dying.

This tells us:
What = needs food. (automatically detected from the verb in the sentence.)
What do they need = food (automatically detected from the object in the sentence.)
Who = Mirna Nazaire (heuristically determined from initial capital letters.)
Where = PAP at Bizoton 6 #12 (detected from microsyntax “at”)
What else = “neighborhood w/o food. People dying.” (Rest of the tweet, unfiltered.)

TWEET-BEFORE: French hospital is now open and ready to receive the wounded at the french lycee in rue marcadieux bourdon
TWEET-AFTER: #haiti #offering #med #loc french lycee in rue marcadieux bourdon #num 30+ #info French hospital is open and ready 2 receive wounded
Simplified Microsyntax: #haiti #rescue French hospital ready to offer help to 30+ wounded at the french lycee in rue marcadieux bourdon

This tells us:
What: Hospital. Also, something to do with medical efforts. (no need to tag explicitly, we can infer that from ‘hospital’.)
Where: The french lycee in rue marcadieux bourdon. (Automatically parsed from microsyntax “at”.)
How many people: 30+. (It’s already a number, no need to state “#num” explicitly.)

These are just a few suggestions. I will be contacting the PIs (principal investigators) of the EPIC project directly with some of my recommendations, but please continue to follow their syntax until they recommend anything different. The current syntax proposal isn’t perfect, but it is more important to avoid fragmenting the tagspace.