I do have some technical gripes with MySQL, though:

• InnoDB doesn’t support fulltext indexes, so I’ve forced to give up referential integrity for any table that needs fulltext searching.
• The mysql(1) command-line tool doesn’t allow setting user variables on the command line when invoking a script.

The first is too big a problem for me to take on right now, but the second looked like it just needed a bit of perl magic, so I wrote a wrapper script:

runmysql

This script scans each command-line option for a string beginning with “@”, and pulls it out of the arguments before passing the rest on to mysql. Any option in the format @name=value will be converted to a SQL variable declaration and passed to mysql; any other option gets passed through unmodified.

Example

Let’s say that you have a SQL script named getstuff.sql:

use mydatabase;

select * from Stuff where type=@type;

You can invoke this script like this:

runmysql @type=foo -X < getstuff.sql

The script will run the command “mysql -X” (the “-X” means XML output — it’s just there to demonstrate how other options get passed through), and prepend a declaration to the SQL script, so that MySQL actually sees this:

set @type = 'foo';
use mydatabase;

select * from Stuff where type=@type;

That’s it, really. Of course, it’s not that useful in a trivial script like this, but for scripts that load data from many different files (for example), it makes life much simpler.

The Ontario College of Teachers says teachers should avoid connecting with their students on Facebook or Twitter.

They are also told to avoid contacting them on LinkedIn, Flickr, YouTube and MySpace.

It’s a great idea to offer guidelines for how teachers communicate with vulnerable pre-College/University students; it’s too bad that the College revealed little other than its own ignorance in the way it wrote them. In a sense, that’s our fault in IT, because we call a whole bunch of unrelated things “social media”, so we can hardly expect teacher-bureaucrats to distinguish between broadcasting publicly over Twitter and exchanging secrets with a select group of friends over Facebook.

Not where you are, but what you’re doing

So, let’s forget about red herrings like online vs. offline, social media, etc., and instead, propose two simple questions a teacher has to answer:

1. Is it all taking place in the public view (can the student’s parents, my colleagues, my principal, etc. follow the exchange)?

2. Is it related to my role as a teacher (am I using this information to help teach, or do I have non-professional motives)?

If the answer to both these questions is “yes”, then the communication is probably appropriate, whether it’s through the spoken word, paper, Twitter, Facebook, or any channel.

Good and bad communication

Here are some examples of how the questions play out:

• It is OK, and often desirable, for a student to read public school-related information posted by a teacher, whether it’s on a bulletin board in the hallway, a Twitter feed, a blog, or a posting in a Facebook group. “Public” means that the parents and principal can read it too. It’s a good way for a teacher to communicate with the students (deadlines, assignments, study hints, etc.) and encourage discussion.

• It is usually OK for a teacher to read public information posted by a student, whether it’s a letter to the editor in a newspaper, a Twitter feed, or a posting in a Facebook group. The key is whether the information is related to the teacher’s role — for example, reading a feed of public political. literary or math tweets from a student is being a good teacher; scouring tweets (or any other public information, such as Google Streetview or the phone book) for personal information is stalking.

• It is probably not OK for a teacher to open private communication channels with a student, where the communication can’t be seen by other teachers, parents, etc. This would include passing private notes in the student’s locker, exchanging email (unless the parent or another teacher is CC’d on it), becoming Facebook friends, chatting privately using Jabber or MSN, or exchanging SMS text messages. This is a bad idea even if the communication is meant to be strictly professional, because it leaves students open to manipulation, and teachers open to accusation.

Sound reasonable? It’s not the platform (Twitter, Facebook, etc.) but the activity that matters. As long as you keep everything out in plain view, talking and exchanging information is a good thing, online or otherwise.

… (Progressive Conservative at the time) was the 1988 federal election. I’d grown up in Kingston as a Red Tory (socially left, fiscally right), working on campaigns for Flora Macdonald and Keith Norton before I was old enough to vote, but by age 24, living in downtown Toronto, I’d drifted around the political spectrum and generally voted NDP or Liberal, with an occasional crush on Green.

In particular, I disliked our current Progressive Conservative Prime Minister, Brian Mulroney, because he’d pushed out Joe Clark, the last of the great Red Tories. Still, on principal, I always tried to learn something about the local candidates, because in the Westminster System that we follow in Canada, no one votes for a party or leader — we elect local representatives for each Riding, and the government is whoever can convince enough MPs (of any party) to support them.

A direct question

So one day, I was walking down Yonge Street and I ran into the local Progressive Conservative candidate, David MacDonald. MacDonald was an ordained United Church minister at a time when the church was torn apart over the issue of gay ordination; he was also running in a Riding that had both a large gay community (we called it just “Church and Wellesley” at the time — the nickname Gay Village wasn’t current yet, at least not in the hetero community) and a large, often homophobic Catholic immigrant community; finally, he was running for a party that wasn’t exactly in the vanguard of the gay rights movement.

I decided, then, as a cocky 24-year-old, to give him a chance to prove himself with a simple Shibboleth question that would piss off half his church, half his potential supporters, and some faction of his party no matter how he answered it:

Do you support same-sex marriage?
Do you support ordaining gays and lesbians as ministers?

A direct answer

The normal political instinct would be to waffle and try to come up with a wimpy compromise answer (“I support the aspirations, but it’s a difficult question and we need time …” kind of BS). The second instinct would be to be bluntly opposed, in line with the majority of Canadians 23 years ago. But MacDonald gave his answer loudly and without hesitation:

Yes, I support it fully.

That’s the kind of courage I love to see from a politician in any party. When I combined that direct and honest answer (which I happened to agree with) with the fact he had real political experience as a cabinet minister under Joe Clark, I decided that even a 24-year-old Toronto grad student could, I guess, vote Tory just once.

Aftermath

MacDonald won the election and went on to become a cabinet minister during Mulroney’s second term, acting as a moderate voice from inside the cabinet room, where he could do the most good. I had mixed feelings about Mulroney’s government, but I was always happy to know that MacDonald was there to speak for me.

Today, I am still a fan of voting local first, and national second. We need good people in Parliament, willing to represent their constituents. I do care about what party those people belong to, but it’s a secondary consideration. Sure, most MPs vote with their parties, but first, there has to be a consensus in cabinet and in caucus, and the more moderate, reasonable voices you elect there, the less likely that Layton can nationalize Canadian industry, Iggy can start a new war in the Middle East, Harper can ban abortion, or whatever nightmare scenario you happen to have in mind.

Perhaps you’ve asked this question yourself: just substitute “iPhone app”, “blog”, “web site”, “Twitter mashup”, etc. for “sonnet”. You have a right to be proud that your app/blog/site is wonderful, but why won’t anyone pay you for it?

A pat on the head for young Billy

In school, when you did good work, you got rewarded, because school is a system designed to encourage you to do your best (at least, a good school is). In a job, when you do good work, you may get noticed and rewarded, depending on how much value your manager puts on continuing to treat you like a school student.

Outside of these artificially-constructed systems, however, nobody beyond friends and family gives a shit that you did something good — as Don Draper said on Mad Men “There is no system. The universe is indifferent.”

Don’t go past the fence!

Still, many brave or foolish people venture outside the school/employment sandbox every year, and the moment they go out the gate, they are hit with two shocks at once:

1. Nobody wants to give them money.
2. Nobody wants to give them praise.

If you’re going to have a chance of success, you recover from this shock, forget about chasing after praise (it’s mostly worthless), grit your teeth, and learn through trial and error how to provide enough value to other people that they’re willing to give you money in exchange.

That’s hard work — very hard work — and the heart of it is not simply promoting a product or service, but spending months and years developing real business relationships with people, and even more importantly, learning (and caring about) what those people — not you — want and need.

Shortcuts

Many people aren’t ready to face that kind of a shock, though, and at that point, they’re an easy mark for anything that promises an alternative to the hard (but necessary) work of actually dealing with people and caring about what they want. Every year, there seems to be at least one fad that promises a shortcut:

• You can run Google ads (or others) on your blog or web site, and Google will take care of finding and billing the customers, then will send you a monthly cheque.
• You can write a Twitter mashup or Facebook app, where Twitter or Facebook members will take care of the hard work of marketing for you, and you can then get enough visitors to cash in on those adds (or sell subscriptions through PayPal, etc.).
• You can post a video to YouTube, and get a share of ad revenue if it goes viral (insert buzzwords like “social media” where appropriate).
• You can write an iPhone or Android mobile app, and Apple or Google will find and bill your customers for you.

All of these promise money (however little they actually deliver), but more importantly, they promise that you can stay in a safe, non-Don-Draper-esque world like the one you remember from school or work: the world where you can get an A+ for doing a very good job on your essay, or a bonus for working extra hard on the ACME account. Effectively, Google, Apple, or some other organization becomes your teacher/parent/boss, dishing out rewards in the form of money and/or pageviews.

That’s a world most people understand; it’s a system where most people feel safe; but it’s no way to sell a sonnet.

Shakespeare

To be honest, we don’t know if Shakespeare ever made money from his sonnets, but he did make a living from his plays … well, not so much from his plays, as from putting them on. It turns out that around the end of the 16th and beginning of the 17th century, Londoners sometimes wanted to get out of the house and do something, but you can go to only so many bear-baitings and Morris dances before a certain ennui sets in.

Shakespeare didn’t just sit in a lonely garret writing plays to for someone else to put on (the 1600 equivalent of writing mobile apps for the iTunes store): as an actor, as part-owner of the Lord Chamberlain’s Men (later King’s Men), and as an investor in the Globe Theatre, Shakespeare threw himself directly into the hard work of forming relationships and dealing with his customers. He made enough money to go back to his home town and buy the second-largest house — a mansion, really — and lord it over everyone he grew up with.

After all that work, perhaps he wrote his sonnets just for fun.

(This post was inspired partly by my life partner, Bonnie Robinson, and the long hours she’s putting into Sweet Tarts Takeaway.)

Too many clicks

Copyright © 2011 by YOW! Productions. Used with permission.

After making one mockup of the home page, we realized that it would take three clicks for a user simply to start watching this week’s episode:

1. Click on “episodes” on the home page.
2. Click on the latest episode at the top of the episodes page.
3. Click on the video to start it playing.

For a web series, where the main point is to let people watch a new episode every week, this made no sense. We thought about a couple of options:

• We could embed a direct link to the current episode on the home page.
• We could embed the current episode itself on the home page.

Broken links and bookmarks

The first option still required two clicks. The second option had more subtle problems: let’s say that I went to sweettartstakeaway.com, watched the current episode, liked it, and sent you the link. Two days later, you open your email, click on the link, and see an entirely different episode, because the current episode has changed.

This isn’t a merely abstract problem. Blogging sites (like those based on WordPress) typically put copies of the newest content on the home page. I have followed hundreds of links to blog postings over the past few years, only to find that someone had linked to the blog’s home page instead of the specific blog posting, and the posting I wanted had long fallen off the home page. Even search engine results do that sometimes.

The zero option

The solution we finally came up with seems simple only in retrospect — throw out the home page.

When you direct your browser to sweettartstakeaway.com, instead of yawning at a promotional page telling you how wonderful the web site is, you get redirected automatically to the current episode page (on February 14, 2011, that was /episodes/01). Next Monday, you’ll be redirected to a different episode, and so on, for all 18 episodes. (We’re using a 307 redirect, for anyone who cares about HTTP status codes.)

Give them what they want, not what you want

With a web series, you know there’s one activity most visitors care about: watching this week’s episode. When you do know that, why not let them start there, instead of forcing them to crawl through an ego-driven “home page” telling them how wonderful you are?

When the series is finished, and we archive it, we may add a home page then to give historical context for the whole series, with links to episodes. For now, though, it will be interesting to see how our zero-home experiment works out.

The site owner was visually-focussed (poor woman, stuck with me as designer!), and had very specific ideas about where layout items and whitespace should go, so I decided that while I have issues with fixed-width layouts like the [in]famous 960 grid, I shouldn’t make her suffer for my beliefs: I designed a fixed-width, em-based layout for her.

Two weeks later, she got in touch and said “I’m really sorry, but …”. She had been looking at the web site on a laptop up to that point, but the first time she opened it on her big monitor at work, it looked like garbage, a tiny strip surrounded by huge bands of whitespace.

Window size: an obsolete problem?

I mention this story because I just read a web page that suggests that fluid layouts — web-page layouts that adjust themselves to fit the width of the browser window — are passé:

With the advancement in displays and the cheap prices of large 22″ and 24″ displays fluid layouts have quickly become more a hinderance than a help because you don’t run your browser full screen anymore. You generally run your browser alongside your mail client, your IM client, iTunes, etc. You find a common size for your browser that accommodates most sites, and you leave it at that width.

Well, apparently not. At least, not in this case. The argument seems to be that users will conform to the needs of designers, by carefully resizing their browser windows to make the designs look good, but the web site owner I’m working with wasn’t one of those people, and I suspect that not all her visitors will be, either.

Rogues’ gallery

The designer of the web site proclaiming the demise of fluid layout probably hoped his or her site would look like this:

This is what you’d see on a typical laptop screen, or on a window sized smaller on a big screen. It’s beautiful — I freely admit that I could never design such a nice-looking web site.

Now, here’s how the same site would look in a large browser window on a large monitor:

OK, even I (and probably my guinea pig) can design something nicer-looking than that. Damn those uncooperative users! Why do they forget to size their browser windows properly?

Now, let’s go down-market, and see how the same site might look in a browser window on a tiny netbook (where the user doesn’t have the option of choosing a bigger window size):

Not nearly as bad as the big screen, but awkward — I can sort-of see what the designer was trying to do, but I have to scroll around to get the whole effect: it’s like looking at the Mona Lisa in 5 cm² segments.

Fluid vs fixed-width is a trade-off

I’m not going to conclude by saying “fixed-width bad, fluid layout good”, or any such oversimplification, but instead, to suggest that the tradeoff that existed between the two ten years ago still exists today:

• If you want a web site that’s a respectable B- in a wide range of screen sizes, use a fluid layout (it’s not an accident that that’s what popular sites like Google use).
• If you want a web site that’s a spectacular A+ in one screen size, and a dismal D- in all others, use a fixed-width layout.

If you need to demonstrate that you are capable of stunning visual beauty, if you know that most of your users will be viewing the site on a certain type of device, or if you just want to stoke your ego by winning design awards (and you know the resolution the selection jury will be using to view sites), then fixed-width can be a great choice. For me, however, usability trumps style, so I’ll stick with fluid-width when I can.

And yes, for the record, you’re reading this blog (as of 2011-02-09) in a fixed-width layout. I just use the default theme on wordpress.com with a custom picture in the banner, because I’m not really all that visually-focussed. Maybe some day I’ll get around to seeing if I choose a WordPress theme with a fluid layout here, too.

My sweetie has been leading a group of talented Ottawa-area actors and crew members to create a new web series, Sweet Tarts Takeaway.

I’ll post again when the web series goes live in a couple of months. In the meantime, you can get updates by following @TartTweets on Twitter, or by joining the Sweet Tarts Facebook Group.

Similar entities

Imagine that you want to deal with a set of geographical entities, similar to what I handle in OurAirports:

• cities
• airports
• navigation transmitters
• points of interest (e.g. buildings, etc.)

The normal object-oriented approach would be to create a base class such as “Location” with all the properties these have in common (unique id, latitude, longitude, elevation, name, description, etc.) and then create subclasses adding additional information for each one (such as frequencies for the navigation transmitters, or identifiers for the airport). The normal naive SQL approach, on the other hand, is to repeat the information in four separate tables.

The base table

SQL can, however, handle polymorphism in a fairly elegant way — I think database people call these “disjoint subtypes”, but feel free to ignore that term. Instead of a base class, we create a base table (I’m using the MySQL dialect, but most SQLs should have similar capabilities):

create table Locations (
  id bigint primary key auto_increment,
  type enum ('airport', 'city', 'poi', 'navaid') not null,
  latitude_deg double not null,
  longitude_deg double not null,
  elevation_m int not null,
  title varchar(128) not null,
  description text not null,
  # add indices as needed
);

(A purer implementation would use a separate LocationTypes table for flexibility, rather than the enum value — I’ll probably do that in OurAirports, but it would make these examples a bit more verbose.)

The subtype tables

Next, create a table for each of your subtypes, where the primary key is also a foreign key pointing to the Locations table:

create table Airports (
  id bigint primary key,
  iati_code char(3),
  icao_code char(4),
  local_code varchar(4),
  # etc.
  foreign key id references Locations(id)
);

Using the same id for the base and derived table ensures that each entity has an id that is unique across all subtables, and simplifies SQL statements for accessing and modifying the tables.

Polymorphism

Now, when you want to deal with locations in general, regardless of subtype, simply query the Locations table:

select L.* from Locations L where latitude_deg > 60;

You can update base information without even knowing the subtype:

update Locations set latitude_deg=45.5 where id=111;

When you want to deal with a specific kind of location, do a simple join:

select L.*, A.* from Locations L
join Airports A on L.id=A.id
where A.latitude_deg > 60;

Views

To make this even easier, define a view containing the join:

drop view if exists AirportsView;
create view AirportsView as
select * from Locations L
join Airports A on L.id=A.id;

Now you can simply query AirportsView as if it were a single table:

select * from AirportsView where latitude_deg>60;

Inserting and deleting

Inserting is slightly more complex, because it involves two steps: first, create the base entry, then link to it from the derived entry:

insert into Locations
 (latitude_deg, longitude_deg, elevation_m, name)
values
 (45.5, -75.5, 100, 'Sample Airport');

insert into Airports (id, iata_code) values
(last_insert_id(), 'AAA');

Stored procedures and/or triggers can automate this fairly nicely, if you don’t want to have to embed too much database logic in application code. Deletion similarly requires two steps:

delete from Airports where id=111;

delete from Locations where id=111;

A simple post-deletion trigger for Airports, though, could automate this and avoid the risk of mistakes in source code.

Eating the dogfood

Unfortunately, I didn’t design OurAirports this way from the start, so I have a bit of refactoring to do. When I’m finished, however, I expect mapping to be much simpler, since I will no longer have to execute 5 or 6 separate queries to find all the icons to display on a map. If anyone has any better ideas, please let me know; otherwise, stay tuned.

Instances of this family provide a small amount of consistent CPU resources and allow you to burst CPU capacity when additional cycles are available. They are well suited for lower throughput applications and web sites that consume significant compute cycles periodically.

• Micro Instance 613 MB of memory, up to 2 ECUs (for short periodic bursts), EBS storage only, 32-bit or 64-bit platform.

Pricing

$0.02/hour = $0.48/day =~ $14.50/month.

A small standard on-demand EC2 instance is $0.085/hour (~$61.50/month), so this is a huge price drop for web sites that don’t really need much computing power, who make up a very long tail). The most obvious target is ISPs who offer shared hosting for low-traffic web sites for $10-20/month.

Competing with free

A less obvious, but perhaps more important target for Amazon EC2 micro instances is Google App Engine. As I explained in a previous posting (Costing out Google App Engine, July 2009), Google can afford to offer free hosting up to about 5 million pageviews/month — enough traffic to pay a modest salary from ad revenue — because they know that most sites will use Google AdWords, and Google will get a cut of the advertising revenue. Amazon EC2 can’t offer free cloud hosting the same way, because it would still be Google getting the advertising revenue.

Four other kinds of “free”

By offering such a low price tier, Amazon is probably gambling that people are willing to pay <$15/month for four freedoms that Google App Engine doesn’t deliver:

1. Freedom to use languages/environments other than Python and Java.
2. Freedom to install out-of-the-box software like MySQL, Apache, PHP, Drupal, and WordPress, etc.
3. Freedom from having to mess around in the App Engine sandbox with the data store, etc.
4. Freedom to move the application to a different ISP without major modifications.

I suspect that for many users, the ability to just drop in an app without having to spend weeks messing around with JVM-limited language ports like JRuby will be outweigh the price of three beers each month. Of course, thousands of ISPs already offer that freedom through shared hosting accounts, often at a lower price and with decent personal technical support. What else does AWS offer this group that the ISPs don’t?

Does this mean that Google is about to roll out full Google Voice support for Canada, or just that they forgot to plug a hole in the code that that’s supposed to prevent non-US accounts from using the service?

Google Voice on my Android phone would be fantastic, because I could make unlimited North American phone calls on (say) a 6 GB, $30/month data plan instead of paying the world’s highest cell phone bills for (limited) voice and long distance. I’m sure Rogers and other mobile carriers won’t be happy about that, but I hope their lobbyists can’t stop it.

Java is dead.

A lot of developers have thought they were too hip for Java, but I still liked it. I implemented SAX in Java first of all, and have developed software in Java and encouraged my enterprise customers to use it for many years, sometimes in 9-figure projects at Fortune-500 companies — it’s a great, mature platform, with a lot of tools for managing large projects and development teams, and it has unit-testing and IDE support that is second to none.

But now, Oracle (which recently bought Sun) has decided to sue Google for using Java in Android, even though (a) Sun long ago open sourced Java, and (b) Google built its own VM anyway. I very much hope that Oracle will suffer the same humiliating, crushing, well-deserved defeat that the SCO group suffered when it went after Linux with its own bogus law suits, but it will take years for that to happen. The Android and Blackberry mobile operating systems will be fine, and Java (of a sort) will live on there (though I still recommend web apps instead of phone apps), but the days of Java and Eclipse in the enterprise are finished.

In the meantime, there are lots of open alternatives to Java, and the litigation risks of using Java have suddenly become far too high. In my consulting work, I’ll reluctantly have to advise customers not to use Java for any new projects, and to consider migrating older projects to a different platform. If you’re a big company or government, you just can’t afford the risk that Oracle will come after you, too.

I’m sorry the end was so sudden and messy, but still, it was a great 15 years. Thanks to James Gosling and all the other people in the Java community for the memories and opportunities.

Summary: Mobile web users’ needs differ by more than UI features (small touch screen): they may check information more often, and expect it to be fresher.

Last night, I finally got around to installing Google Analytics on ourairports.mobi, the mobile version (for pre-smartphones) of ourairports.com, and this morning, I got my first stats: all of 3 visits yesterday (vs. 1,677 for the non-mobile site).

I expect that number to climb when the site is collecting stats for a complete 24-hour day, but already, I’ve noticed a significant difference in use:

Of course, the mobile sample is too small to be statistically significant, but it still made me think about how a mobile user will use the site:

• A desktop user at home may check information for an airport once while planning a flight (as pilot or airline passenger).
• A mobile user, at or on the way to the airport, will keep checking for changes (new weather forecast, NOTAMs, etc.), constantly updating the same few pages.

A closer look at the analytics confirms that hypothesis, with a small number of airports updated multiple times (there were four pageviews for Sunbury Airfield in Australia, for example).

Further hypothesis: timely data is important for all web users, but it may be disproportionately important for mobile users. If this is true, it’s probably worth spending less time trying to make your mobile site (or app) look like a fourth-year graphic design college project, and more time making sure that it has the best, and most recent information.

I’ll watch the analytics for ourairports.mobi over the next month to see if this trend continues.

So what happened last week?  Did Google backtrack after getting caught trying to be evil about net neutrality and the mobile internet, or were they a victim of a misunderstanding (gleefully amplified by blood-thirsty Apple and RIM supporters)?

Net neutrality is a crucial issue for those of us who care about open information.  We believe that the Internet is a public thoroughfare, where every information provider has the same access.  Competing web sites shouldn’t have their traffic slowed down because Google or Microsoft paid more money to Verizon, Rogers, or Bell, any more than you should have to pull to the side of the road to let someone in a more expensive car pass you.

Carriers in search of a business plan

For obvious reasons, the Internet providers don’t see it that way. They’ve ended up stuck in the rut of commodity service, with the inevitable race to the bottom for price, and are desperate to find some new revenue.  The mobile Internet providers are a little better off because they can at least lock customers into three-year contracts by giving them subsidized smartphones, but it’s still clear that someone like Verizon would be thrilled be able to take a big bag of money from Google in exchange for letting Google sites load a little faster than anyone else’s.

It turns out, though, that that’s not what Google was trying to do.

Neutral in what sense?

The Google-Verizon kerfuffle draws attention to a different, and trickier part of the debate.  What if, instead of discriminating by provider (Google vs Facebook), carriers discriminated by traffic type? In other words, what if streaming audio and video got priority handling to avoid jerky playback, while e-mail was delayed an extra 2-4 seconds? All streaming video would get the same treatment, whether it comes from YouTube or a student’s dorm-room start-up, and all e-mail would get the same treatment, whether it’s from IBM or a LOL cats fan list.

According to Google’s CEO, Eric Schmidt, this is what Verizon and Google were talking about all along: not favouring one provider over another, but favouring one content type over another.

Is it still evil?

I expect that many people who support net neutrality for providers won’t feel so strongly about net neutrality for content types, because it doesn’t have the same appearance of unfairness.

Going back to the thoroughfare analogy, we have sidewalks where only pedestrians are allowed, paths where only cyclists are allowed, crossings that pedestrians aren’t allowed to use, and superhighways where only motor vehicles are allowed. Buses and carpoolers are sometimes allowed to use a faster lane, trucks are sometimes required to stay in the slower lanes, and so on.  Why can’t we have different lanes for different kinds of network traffic, too?

Net neutrality makes sense for content types, too

There are, however, four compelling arguments in favour of net neutrality by content type as well as provider:

1. Pandora’s Box — it seems straight-forward enough to give streaming video priority over email, but how far might carriers take it? Will carriers throttle IM during the next G8 summit to make it harder for protesters to organize? Will government regulators prefer content types that are more popular among the old than the young?
2. Business/content-type alignment — as the owner of the world’s top video site, Google has a strong interest in making video on the mobile web faster, even if it means that its competitors’ videos are faster too. This kind of thing could turn evil fast — imagine Adobe and Apple in a bidding war to determine whether Flash should be delivered faster or slower than other content types, or the recording industry lobbying to throttle bittorrent so much that it becomes useless.
3. Innovation — the Internet already existed when HTML and HTTP arrived on the scene 20 years ago. If the net hadn’t been neutral then, perhaps priority would have gone to important existing protocols like telnet and FTP, and HTTP (and HTML) might have been slow enough to turn off early adopters. We don’t know what The Next Big Thing will be, but we do know that regulators respond slowly to change. Why shut the door on innovation?
4. Routing around censorship — seriously, how long will it take a few enterprising developers to realize that they can build an “accelerated download” app that allows other traffic to masquerade as video (or whatever has top priority). Seconds? Less? You can make anything look like anything else on the Internet, and everyone thinks that his/her traffic is most important.

It’s OK to be wrong sometimes

Google is a company that embraces failure, which, perhaps, is why it has so many successes: Google puts products out early, lets us play with them, then feeds the ones that succeed (e.g. Gmail) and kills the ones that don’t (e.g. Wave).

Perhaps Google is willing to try the same thing with ideas — they’re not necessarily evil for suggesting dropping net neutrality for content types, but they are wrong. Let’s treat the whole thing as a failed project and move on, concentrating on making the net (mobile or desktop) faster for all providers, and all content types.

The Balisage 2010 conference runs next week in beautiful Montreal, focusing on XML and other markup technologies. I cannot make it this year, unfortunately, but I gave some help (far too little) to Sam Wilmott to organize the silent auction.

The Balisage silent auction will raise money to help students and other young, up-and-coming markup stars to defray the cost of attending the conference: the auction includes O’Reilly books, various enterprise software licenses, and geeky memorabilia. We’re encouraging participants to splurge, and try to outdo each-other by overpaying for things. Most of us can’t afford to blow $20-50M on a bizjet, but we can certainly drop $50 on a $25 O’Reilly book and then brag about it to our friends.

Think of it this way — Montreal, with its Vegas-of-the-North attitude towards sin, offers far less savoury places to stick a few $20 bills. Why not put them somewhere that you won’t have to lie about when you get home?

Now that I’ve had a few weeks to play with my Nexus One, I’m starting to grok the gut-level experience of living with a smart phone. I understand why people download apps, how it feels to have the Internet with me everywhere, and what it’s like to experience the web by touch on a screen that’s only a few centimetres square.

Past

Device-specific apps are sweet and shiny at first, but after a couple of weeks, it becomes obvious that many of them are the encore of the floppy-based PC shareware world of the 1980s and early 1990s (SEND $5 TO GET RID OF THE ANNOYING ADS! ONLY $10 FOR THE FULL VERSION!).

Discovering an interesting app through Apple’s or Android’s market (or taking a picture of a barcode on your computer screen) is surprisingly awkward compared to just following a link from one web site to another, and as we’ve learned from the postal service, the telegraph, the telephone, email, and the web, connectivity always wins in the end.

Future

Web apps run everywhere and connect to each-other seamlessly, and HTML5 allows a well-written web app to do almost everything a closed, device-specific app can do on a smart phone — many of the mobile web sites I’ve used (hello, Google!) are as good as or better than the corresponding device-specific apps. There are some things, though, that make mobile web apps stand apart:

• The built-in buttons on your smartphone are tied to the browser, not to the app, so the Android menu or search button (for example) brings up a browser menu or search box, not an app one.
• For good security reasons, a web app will probably never have as much access to the filesystem and device hardware as a closed device-specific app (do you want a malicious web app to be able to turn on your video camera when you’re browsing in bed? do you ever consider that when you give a downloaded app access to your camera?).
• While HTML5 supports notifications, you have to actually be on the web page to receive them. That can be fixed by allowing the browser to launch web pages automatically on start/restart, but it’s still more awkward than an autostart app.
• Web app processes need to be managed from inside the browser, not from a device-wide process manager.
• As far as I know, there’s no way for a web app to install its own icon on the device home screen — the user has to install it manually (though it’s pretty easy).

I don’t consider most of these to be a big deal, but they do point to the fact that no matter how much extra functionality HTML5 provides, web apps have a different world view: they’re nodes in a huge network, not standalone silos.

Present

I’ll probably have to continue to use a device-specific app for anything related to playing music or capturing photos/video for a while longer, and I’ll hang onto the Android WiFi analyzer I’m running on my phone. Android has a lot of the same apps that show up in iPhone commercials (like Urban Spoon), but while they’re pretty, they’re limited in the end — there’s way more out there on the web than there will ever be an an app store.

If you’re an person or organization that wants to interact with people on mobile devices, you have two choices:

1. You can develop and maintain separate apps for iPhone, Android, Blackberry, Palm, and any other smart-phone OS’s that may come along, and let the phone vendors be gatekeepers between you and your users.
2. You can run a single mobile web app on your own server, one that’s only a click away from any other web site that links to it.

The first option lets you force an icon onto the users desktop, but the direct development costs and opportunity costs of losing inbound links and search-engine love just seem too high.

I left this comment on Simon St-Laurent’s interesting and thoughtful post How dare Apple … (which, in turn, was partly a response to Tim Bray’s post Nothing Creative).

I don’t believe that most things, including the iPad, are obviously right or wrong, but I do have serious concerns that go beyond simply not being able to code on an iPad (at least, until there’s an app for that). I’m copying my comment here to give it a more permanent home. If I hadn’t posted this yet, I’d edit it to tone down the emotional language 10% or so, but still, it’s a fair reflection of my thoughts and concerns, not about the iPad itself (it’s just another consumer device), but about the way people are starting to talk and think about issues that are very important to me, like software freedom:

The thing about creativity is that it responds poorly to central planning and central control. I have no problem with the fact that the iPad isn’t developer-friendly — I can buy a Netbook with twice the power for half the price and code on it (and, BTW, that netbook makes just as simple a consumer device).

My problem is the idea that a single Apple politburo controls everything that can appear on the device. Is that the future? Even in the bad old days of TV, before cable, there were 3 1/2 US networks to choose from, not just one – you had to watch TV outside the US to see just how bad things could get with a single, government-controlled broadcaster (I grew up in Canada, but close enough to watch the US stations, thank god).

Apple’s obsession with central control goes beyond software to hardware. There must be some kind of port for the optional keyboard to plug into, but no way it’s going to be USB or Firewire, because that might let someone use an *unplanned* creative device on the iPad, someone creative daring not to give Apple its cut (and veto). If I build something clever for creative people using a USB interface, it will work with desktop towers, notebooks, netbooks, and even some small portable devices, but *not* with the iPad.

Apple has some smart people working there, but they won’t always have the best ideas, and Apple has thrown up too many barriers to other people with smart ideas. The best apps in the future are going to come from a couple of students coding in a dorm room, and they might just be so annoyed by Apple censorship that they defect to a freer platform. It’s sad that things have gotten to the point that even Windows is a freer platform than Apple.

Safety vs. money

Here’s a simple example: let’s say that you want to go on a two-hour scheduled flight, and that the odds of you dying on the flight come out to about 1 in 1 million (it’s actually lower, but let’s keep the math simple). Your ticket costs $400 with taxes.

Now, I start an airline that adds all kinds of extra safety features and procedures, and over the years, it proves itself twice as safe as the average, so your odds of dying are only 1 in 2 million. However, your ticket would cost $600 with taxes on my airline.

Will you buy the more expensive ticket? If not, then you’ve decided that your life is worth less than $200 million dollars (for every million people who paid the extra $200, one would be saved from death, in the unlikely event that I managed to get the simple math right) — a big number, still, but no longer “priceless”. Decide how much extra you would pay for the ticket ($5? $10? $50?) and multiply by 1 million — that’s what your life’s worth to you.

Safety vs. time and pleasure

Of course, time is as much of a commodity as money. How much time do you save by flying between cities instead of taking the train, or driving across town instead of taking the bus? How much extra risk of death did you assume by making that choice? Again, you can do the math, and decide what value (in saved time) you put on your life. Ditto for your hobbies — downhill skiing is more dangerous than playing Wii, but you’ve decided that the value of your life is less than the extra enjoyment divided by the extra risk of dying (where risk is < 1.0).

It’s perfectly normal

Risk taking is normal for humans, and most of the time we don’t actually do the math — we just make a snap judgement of the value of our lives and the effects of our choices based on instinct. This matters, though, because we (where “we” = American, Canadian, British, Australian, etc) are now electing governments that promise to spend more money to make us safer, and much of that money ends up going into blowing up central Asian villages, spying on our communications, and groping us at airports.

Valuing lives

Is it helping? If we’d spent the same amount of money building better flu clinics, fast intercity trains or even better-lit intersections, could we have saved more lives in our own countries? If we’d invested even one percent of that money into sewers, clean water or earthquake-resistant hospitals for the developing world, how many lives could we have saved there?

Putting a dollar value on a life isn’t a crass, corporate, conservative thing — it’s a way of deciding where to spend money most effectively. If I could save one life for every $2 million spent on road improvements, and one life for every $200 million spent on improved airport security, where should I spend that money?

Where are people dying?

Let’s end with fatality numbers for the U.S. in 2001, the worst year for terrorism on U.S. soil:

Influenza and pneumonia: 63,730

Traffic accidents: 42,196

Terrorist attacks: 2,973

If you’d had billions of dollars to spend to save lives nine years ago, where would you have spent it first? Where would you spend it now? That depends not only on the overall numbers, of course, but the amount you have to spend to save each life. I’m not sure we know that, but I suspect that it’s much higher for anti-terrorism efforts than for basic road or healthcare improvements.

Case in point: in the information technology world, the greatest accomplishment of the most talented coders and business people in GenX was replacing the Baby Boomers’ nasty old platform-dependent shrink-wrapped computer applications with open web applications that could run anywhere, from a Windows desktop to a Linux cell phone. Write once, run all over the place on any hardware/OS you want. GMail instead of Eudora. Wikipedia instead of Encarta. Cool, eh?

So GenY comes along and says “hey: instead of encouraging people to browse the web with open standards, let’s build proprietary applications that run on only one type of mobile phone. And we’ll allow only one store to sell those applications for each type of phone, and every proprietary, platform-specific app will have to be preapproved and precensored by the phone manufacturer, who will extort^H^H^H^H^H^H be gladly offered a cut of sales.” Even Microsoft in its monopolistic hey-day — before it became the toothless lion it is today — never had the balls to try anything like that with Windows apps.

Who, ten years ago, would have predicted an IT catastrophe like this after so much progress and hope? It’s enough to make a person cry. Let’s encourage those GenY’ers who taken up the torch and continue to work on the dream of an open web.

The “Airport” tab has bold text, and a white background that runs smoothly into the rest of the page, while the other tabs have a light-blue background, blue text, and a line at the bottom separating them from the page — that should make it obvious to everyone that “Airport” represents the current page, while the others represent alternative pages that you can view by clicking on them.

Right?

Err, maybe not. Even though it doesn’t look linky, the active tab is still, by a lucky coincidence, a link, so I was able to track it using the Google Analytics Site Overlay out-link tracker (note that it’s not actually a click tracker, even if it looks like one). I have over 40,000 airport pages like this, so I can’t check every one, but the few dozen I looked at all told the same, sad story…

People don’t get tabbed interfaces

On most airport pages, the majority of user clicks were on the active “Airport” tab. In other words, people go to the page, see the word “Airport” in bold in a prominent position, and click on it. They don’t notice that it’s the active tab — maybe they don’t know that it’s a tab at all. They just figure that it must have more information about the airport they’re looking at.

For example, on the Heathrow Airport page over the past month, Google Analytics tracked 17 outlinks to the same page (via the active “Airport” tab), 5 to airport arrivals, 4 to airport departures, and 0-2 for every other link.

Once they click on what I thought they’d recognize as the active airport tab, the same page just reloads. Blech. I assume that’s when they get sick of the site, and go back to their Google search results to find a better page about the airport.

Tabs encourage information clutter

So the tabbed interface just leads to confusion and frustration from many of the visitors to my web site. But there’s another problem evident from the the outlink stats: tabs encourage a designer to present too many options in too many contexts. The tabs are all visible on every page they cover, but most of the time, they represent information that the users don’t actually need, and there’s no clear visual cue that some of the tabs (e.g. arrivals and departures) are a lot more interesting than others (e.g. the airport page’s change history).

Here, for example, are the last month’s outlink counts for each of the tabs on the Myrtle Beach International Airport page:

For reasons I don’t understand, this was the most-visited airport page on OurAirports last month, with 371 pageviews (300 uniques). It’s a little atypical, in that the active tab is not the most clicked (though it’s still unacceptably high), but otherwise, it shows the picture well. The “Pilot info” tab has existed for only a few days, so we can leave it out, but in general, it’s clear that the main thing accomplished by the tabs is showing a lot of links at the top of every page that no one actually wants to use. I suspect that even the four clicks on the “Visitors” tab were accidental — instead of trying to see what OurAirports members have visited the airport, people were probably just looking for visitor information.

How to redesign?

So if (a) tabs aren’t actually intuitive for most of my visitors, and (b) they fail to distinguish useful/popular information from more esoteric information, then they have to go. It’s going to take me a while to redesign the site, but what I think I’ll do is highlight the 3-5 most useful actions for each type of page in a side bar beside the map, like this:

Show me…

• arrivals or departures
• visitor comments
• pilot information
• nearby airports
• points of interest
• more…

A list like this, as opposed to tabs, provides a clear call to action for a page visitor, providing more detailed options in language that will make sense to them. It highlights useful information they might have missed in a tab (e.g. pilot info) or a section lower on the page (e.g. Visitor comments), and hides stuff they rarely need in a menu that appears only on demand, when they click “More…”.

Farewell, tabs. Even if you weren’t helpful, you were fun to design with CSS and rounded-corner images.