Election 2012

cbsnews.com 2012 Election

My 4th election, 2nd presidential election. I couldn’t even tell you how many primaries, debates, etc. without hitting Wikipedia and counting. Handling the technical side of elections on a large internet news presence is nothing short of crazy. It’s a lot of 1′s and 0′s to move across the internet in a very short amount of time. No margin of error, no time to recover from mistakes. You’re product launches with the firmest of deadlines and is consumed immediately. Scale later is not an option, you scale from the starting gate to handle an unknown number.

It’s an interesting experience no matter how many times you do it. No matter how much planning, quick thinking and judgement calls are unavoidable. At least there’s a 2 year break until the next one :).

On Apple’s Lack Of Adaptive Image Support In WebKit

It’s becoming clear to me that despite Apple having a huge chunk of the mobile web, it still treats the web as a second class citizen on iOS and Mac OS X. My latest battle is adaptive images, in particular for use in High DPI devices (“Retina” on the Mac). High DPI displays are awesome. I own an iPad 3, and it’s one of the greatest displays I’ve ever looked at. What I don’t get is why Apple is making it so difficult to take advantage of as a developer.

Currently, there’s no easy way to switch image resolutions based on the display being used. The basis of that isn’t Apple’s fault. Nobody thought of the problem when HTML was first created. All of the methods have ugly tradeoffs. They are hacks. Even Apple.com doesn’t have a great solution. They were doing image replacement (easier to read version here). Apple does however have a solution called image-set which looks like it will be in iOS 6 and Mac OS X 10.8.

That’s several months later. The iPad 3 was announced March 7, which was only about 2 weeks after the initial proposal. Why wasn’t a solution for web authors included when the iPad 3 shipped? It seems silly that there’s no API to properly interface with one of the most touted features of the new device. Of course there’s a way to take advantage of that brilliant display if you build a native app.

You could argue that Apple didn’t want to rush implementing something proprietary without discussing it with the community at large, but Apple has said in the past:

tantek (Mozilla): I think if you’re working on open standards, you should propose your features before you implement them and discuss that here.
smfr (Apple): We can’t do that.
sylvaing (Microsoft): We can’t do that either.

So Apple is pretty candid about reserving the right to implement features without discussion, yet nothing happened. It’s not that such a discussion would have been a “leak”. The iPhone 4′s display would be adequate justification for the feature. In fact it’s mentioned in the first sentence of that proposal in www-style by Edward O’Connor. So not disclosing the new product doesn’t seem to be the reason either. Apple could have done this a year ago without anyone being any wiser about the iPad 3′s display.

I can’t be the only one who’s scratching his head over this. Why didn’t the iPad 3 ship with a browser capable of providing an efficient way to switch images? The cynic in me would say “to encourage native app development”, but then why bother now?

The upside is Apple products have high OS adoption rates. All those retina iPad 3′s will be running iOS 6 relatively quickly. If it were a popular Android device I’d be much more concerned because we’d be dealing with 2 years of devices on a stale OS with no support. This is why we need more competition in mobile. We need web solutions to be a priority, not an afterthought.

As far as I’m aware image-set is also prefixed, but that’s another rant.

HTML5 One Time Submit

One of HTML5′s coolest features in my opinion is that forms are easier to build. Things like required, autocomplete, pattern make it much easier to create an intuitive form without having to jump through hoops and repeating efforts to do some basic form validation.

The one thing that I still see as missing is a one-time submit button. Many sites create transactions that should only be performed once. For example, when you click “place order”, you definitely don’t want your transaction being processed multiple times, so what websites do is disable the button after the first click. I’m not sure why, but this little pattern never quite made it into HTML5. I’d love to see something like this:

<input type="submit" id="process_order" transactionsafe="true"/>

Then when the submit button is pressed, it automatically sets the disabled attribute. Either on the server side (if you submit the entire page), or via JS (for a refresh-less UX) you could unset the disabled property should you want the user to be able to submit again (for example if the order failed).

It’s trivial, but we seem to use this pattern quite a bit. It would be nice to one day be able to do this without an event.

Full SPDY Ahead

For those not keeping score, Twitter, and Facebook have both come out publicly in favor of SPDY. Twitter is already using it in production. It sounds like Facebook will be soon. Mozilla implemented it in Firefox. Opera has SPDY. Google, the author of SPDY is using it in production.

This leaves Microsoft and Apple as the holdouts. Microsoft’s HTTP + Mobility is SPDY at it’s core. Microsoft hasn’t started supporting SPDY in any products, but it seems inevitable at some point. They are a holdout in implementation but not opposed to SPDY it seems.

Apple is the last major holdout. SPDY hasn’t been announced for iOS 6 or Mac OS X 10.8. As far as I’m aware Apple hasn’t made any statement suggesting support or opposition to SPDY. However I can’t see why they would oppose it. There’s nothing for them to disapprove of, other than it’s not using their IP. I’d be surprised if they don’t want to implement it.

However given SPDY is a rather backwards compatible thing to support, I don’t see this holding back adoption. Nginx is adding support for SPDY (thanks to WordPress creator Automattic), and Google is working on mod_spdy for Apache. That makes adoption for lots of large websites possible.

While the details of SPDY and the direction it will go are still in flux, it seems nearly certain that SPDY is the future of the web. Time to start digging into how to adopt it and ease the transition. The primary concerns I see are as follow:

  1. TLS Required – While not explicitly required, SPDY essentially builds on TLS and virtually any real world application needs it. This means purchasing SSL certificates for any website you wish to use SPDY with. Some have argued performance and scalability, but Google, Facebook and Twitter use SSL extensively on commodity hardware.
  2. IP Address – Unless you use Server Name Indication (SNI), which almost no websites do because of compatibility, you need an IP address for every hostname that you use TLS with. That means until IPv6 is widely adopted, it will be putting further strain on the remaining IPv4 pool.

Both of the above concerns increase complexity and cost of building websites at scale and for those who are on a very tight budget (the rest of us will manage). Because of this, I don’t think we’ll see a 100% SPDY or HTTP 2.0 web for quite some time. Don’t expect SPDY for shared hosting sites anytime soon.

In a world of increasing surveillance and user data being integrated into everything, the benefits of TLS will be realized. Both Facebook and Twitter acknowledge it’s importance in preventing user data from getting into the wrong hands.

I, For One, Welcome Our New SPDY overlord.

Getting RSS Feeds For Twitter Users

Want an RSS feed for a particular Twitter user? This used to be linked off the profile page(s) but since disappeared. It’s still available if you know where it is:


http://api.twitter.com/1/statuses/user_timeline.rss?screen_name={username}

Replace {username} with a username (example).

You could also put a bunch of users into a list and query that using:


http://api.twitter.com/1/lists/statuses.atom?slug={listName}&owner_screen_name={username}&include_entities=true

Replace {username} with the list owners username and {listName} with the list name (example). Strangely that’s only available in atom format.

I still find RSS handy for those accounts I don’t want in my stream but want to keep an eye on, as well as those I want to programmatically access or manipulate.

PHP 5.4 And Short Syntax

I’m actually pretty excited about PHP 5.4′s release. I still manage to write a fair amount of PHP these days.

I suspect it will be quite some time until I have enough PHP 5.4 targets to utilize some of the newer features like Traits and the short array syntax, but that’s OK. Performance and memory improvements are always welcome. I doubt I’ll touch the built in web server much. It seems to only be intended for testing, and I never really ran across PHP without Apache (except when I didn’t want it in which case cli is what I wanted).

One slight disappointment is that there is a short array syntax, but no short object syntax. I guess you could always use casting to make it happen like this:

$obj = (object) array(‘foo’ => ‘bar’);
$obj = (object) [‘foo’=>‘bla’, ‘bar’=>2]; // PHP 5.4+

But that still isn’t ideal. I’d prefer to see:

$obj = {‘foo’=>‘bla’, ‘bar’=>2};

Maybe next time around.

On Prefixing And Monobrowser Culture

I’ll say right off the bat that Daniel Glazman is right, and I fully support his message. The failure to alter the course of the web now will lead to headaches. Truthfully it’s already a headache, it’s just going to get worse. The IE Days were the dark ages of web development. I don’t want to go back to that.

In an ideal world, CSS prefixing wouldn’t be necessary. Browser vendors would spec things out, agree on a standard and implement it. That however is too rational, so CSS prefixing is an unfortunate reality. It outright won’t happen by the admission of Microsoft and Apple (pointed out by bz):

tantek (Mozilla): I think if you’re working on open standards, you should propose
your features before you implement them and discuss that here.
smfr (Apple): We can’t do that.
sylvaing (Microsoft): We can’t do that either.

Of course you can question if there’s really a legitimate need to work on standards in private. I’m personally skeptical a css property will leak the next iPhone.

It’s also worth noting Apple and Microsoft are both OS vendors and (cynically speaking) have interests that are explicitly contrary to the internet being a universal platform. Fragmenting the web and making it a more difficult platform to develop on is potentially in their interest. Not to different from their stance on h.264 of whom they are both licensors and thus haven’t implemented WebM.

I’m starting to second guess the permanence of prefixes. I personally think once there’s a standard the first release of a browser 12 months after standardization drops support for the prefix. Yes, this will break a few websites that never update. However it’s almost always an easy fix. I’d venture 95%+ of the time it could be done safely via a regex. Truth is you’re talking about 18-24 months from initial implementation in practice anyway. Possibly longer. A website that is so stale it can’t manage to deal with this in 1.5-2 years is in pretty poor shape to begin with. LESS and Sass can also be a big help in automating this. W3C CSS Validator already errors on prefixes. The tools to deal with this are in place today.

I should note dropping is unlikely to happen and thus wishful thinking.

A large part of this issue is how many websites are built these days, especially “mobile sites” which are typically separate sites bolted onto an API or even the backend database of a website. Often built by 3rd party vendors getting things passable and out the door is key. As a result every shortcut in the book is taken, including the absolute minimum in testing and compatibility.

For what it’s worth, this blog has only one prefix in use, and it’s coded as:

-moz-border-radius: 3px;
-khtml-border-radius: 3px;
-webkit-border-radius: 3px;
border-radius: 3px;

Which catches everyone. That takes all of 30 seconds at most to do.

Notifications For Better Engagement

One thing I’ve learned repeatedly over the years is that good notification systems create great engagement and encourage habitual users.

The biggest problem with any product/service is getting people to come back. “Drive by” users aren’t terribly difficult. Google will bring you those with a little work. However your business comes from users coming back repeatedly. Those are you’re true “users”. They are the ones who will bring others.

Today, I think Facebook and Twitter are the perfect example of companies who understand and utilize this strategy in a way that amazes me. Lets look at this:

Facebook

They are the biggest, so I’ll go through it first. The first method of notification is the obvious alerts when logged into the site. You can keep it open and use it as a client, it works great. Facebook also has one of the best email notification systems on the net. You can reply to a comment or message by simply replying to the email. No “app” to install. Even an old Blackberry can participate. Even people where Facebook is restricted but email works can participate (stereotypical corporate office). Email is the worlds greatest API. They take full advantage of it.

On top of that Facebook apps have push notification for smart phone users. Facebook also supports SMS notifications. They additionally support XMPP (Jabber) so you can use a desktop client with their messaging service.

One thing I never understood is why they don’t officially support and continue their desktop notification service. With a trivial amount of work it would be an even better retention method. However the API’s are clearly there for client support (several use it).

Facebook doesn’t exploit this system for marketing or PR. It’s just a useful way to interact with their system. It’s an interface. It’s an API.

Twitter

Twitter is another company that gets notifications. The most obvious again is their website. Secondly their apps support push notifications. Twitter is also pretty good about email notifications however they don’t accept replies over email. They also support SMS (i.e. “Text follow raccettura to 40404″).

Twitter lastly has an open API and even supports desktop apps like Twitter for Mac and TweetDeck. They encourage their users to stay on constantly and keep up. It’s part of what keeps users addicted to the service.

Again, they don’t market. They just keep users interacting.

Google+, Quora, etc.

I won’t judge Google+ just yet, they are pretty new still. Quora does a pretty good job with notifications however the balance between annoying and useful hasn’t quite been met, at least in my opinion.

It’s easy to overlook this “detail”, but for many users, this is the interface, realize it or not.
I won’t

Web App Stores Via Twittter/Facebook

It seems likely to me that Facebook and Twitter will eventually be competing with Apple in terms of App stores. Facebook sort of already is with their extensive apps platform, however that’s just competing for developer attention. Twitter doesn’t really have an equivalent today (developers mainly build clients and interact with data), but don’t underestimate their clout.

The reason I say this is that Facebook and Twitter have become identity gatekeepers on the net. Already you can login to many sites via accounts with one of the two sites. Creating the API’s to handle purchase/subscriptions and transparently handling the billing to effectively turning a HTML5 site into an “app” is the next logical step. They could undercut Apple and still walk away with a handsome profit for not doing terribly much more than leveraging their size and reach. These apps would work on any device with a web browser. Desktop or mobile.

Given both sites need to diversify revenue streams (something Google never figured out), it seems only logical to make this step. $0.99 for Angry Birds seems more than plausible.

And yes, there are offline abilities in a browser.

Make Login Pages Autofocus

I see this way too often and it gets on my nerves. If you have a page that’s main purpose is a form, such as a login page, please make the page autofocus to the first field in the form. Having to tab or click on the first field is a nuisance. Even big sites make this mistake.

If you don’t care about IE you can do it as simply as:

<form method="post" action="/">
<p>
    <label for="username">Username:</label>
    <input type="text" name="username" id="username" autofocus="autofocus"/>
</p>
<p>
    <label for="password">Password:</label>
    <input type="password" name="password" id="password" />
</p>
<p><input type="submit" name="login" value="Login"/></p>
</form>

Since autofocus is boolean you technically don’t even need to specify an attribute value.

To do it with IE in mind you could use the following JavaScript below the form (no library needed):

function focusForm(){
    setTimeout(function(){
        try {
            // id of element to focus on
            var elem = document.getElementById(‘username’);
            elem.focus();
            elem.select();
        } catch(e){}
    }, 50); // setTimeout to fix IE bug
}
focusForm();

Note the use of select() so if the form reloads due to an incorrect password the field is not just in focus but the contents highlighted. There is also a setTimeout() since IE, at least some older versions have trouble with this if it happens too quickly. 50 should be fast enough that it won’t be noticed by humans.

See how simple that is? No excuses for not fixing this ;-) .