Apple’s Overseas Manufacturing

Apple’s logistics and manufacturing is extremely complicated, secretive and critical. The NY Times has a great story on it and how it is a great example of jobs leaving the US:

Apple executives say that going overseas, at this point, is their only option. One former executive described how the company relied upon a Chinese factory to revamp iPhone manufacturing just weeks before the device was due on shelves. Apple had redesigned the iPhone’s screen at the last minute, forcing an assembly line overhaul. New screens began arriving at the plant near midnight.

A foreman immediately roused 8,000 workers inside the company’s dormitories, according to the executive. Each employee was given a biscuit and a cup of tea, guided to a workstation and within half an hour started a 12-hour shift fitting glass screens into beveled frames. Within 96 hours, the plant was producing over 10,000 iPhones a day.

“The speed and flexibility is breathtaking,” the executive said. “There’s no American plant that can match that.”

There’s lots more, go read it.

How Read Only Programming Languages Are Born

One day a man was writing an email when he left the room to get something to drink. In his absence, his cat walked over the keyboard and among the myriad of characters entered into the body managed to send the email off. The man returned and soon realized what had transpired. Wondering what the recipient might think receiving such a random unsolicited email, he decided to pass it off as a new programming language. He named it after his cat – Perl.

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 ;-) .

Littoral Combat Ship Problems

Interesting read on Gizmodo on the shortcomings of the Littoral combat ship:

It’s bad enough that the Navy’s newest ship has had wicked problems with corrosion, missed out on the latest naval wartime missions and is generally something of a Frankenstein’s monster. Now the Pentagon’s top weapons tester has found problems with its abilities to find and withstand mines – which is a big problem for a ship that’s supposed to be the Navy’s minehunter of the future.

Since it floats (until it corrodes) we’ll call it a time limited beta. Sounds like there’s a lot of work that needs to still be done here.

localStorage With Cookie Fallback

I mentioned the other day that localStorage can be used as an alternative for cookies. The benefit is that localStorage doesn’t sent it’s data back on every request to the server like a cookie. Headers are uncompressed in http making that very costly. However not every web browser out there supports localStorage. Most however do.

Here’s an example based on jQuery and jQuery.cookie. It’s designed to turn objects into JSON and store the JSON representation. On retrieval it restores the object. This doesn’t handle things like expiring cookies (it simply defaults to 365 days). I just had this around from an old project with these very specific requirements and figured I’d post it as-is in case it can help anyone and to demonstrate. This isn’t ideal for reuse, but for someone playing with the idea, maybe it will motivate ;-) .

function storeData(type, obj){
    var data = jQuery.toJSON(obj);
 
    // If using a modern browser, lets use localStorage and avoid the overhead
    // of a cookie
    if(typeof localStorage != ‘undefined’ && localStorage !== null){
        localStorage[type] = data;
    }
 
    // Otherwise we need to store data in a cookie, not quite so eloquent.
    else {
        jQuery.cookie(type, data, { expires: 365, path: ‘/’ });
    }
}
 
function loadStoredData(type){
     var data;
 
    // If using localStorage, retrieve from there
    if(typeof localStorage != ‘undefined’ && localStorage !== null){
        data = localStorage[type];
    }
 
    // Otherwise we have to use cookie based storage
    else {
        data = jQuery.cookie(type);
    }
 
    // If we have data, lets turn it into an object, otherwise return false
    if(data){
        return jQuery.secureEvalJSON(data);
    }
    return false;
}

Pretty simple right? It’s still a key/value API.

Google Open Sesame

Google quietly put up a new login method via QR code. Essentially the way it works is you view the QR code viewed on a computer or tablet. Then use your smartphone to open the QR code and login via your browser. That process remotely validates the session and that computer can then access your account until you logout. Essentially eliminating the need to enter a password on that computer.

Presumably the idea is to work around keyloggers that may record passwords. However, if you don’t trust a computer enough to use a password, do you really trust that it’s not watching everything you are doing? If the computer hardware or software is compromised not even SSL will save you. This might be better, but I’d think it’s only marginally so. I personally just make a rule of not using computers I don’t trust. Given I have a smartphone in my pocket, this is pretty easy to live by these days. Given computers are getting smaller and cheaper, I question if encouraging the use of shady terminals is worthwhile.

Regardless, pretty innovative and clever.

90% Of Web Traffic Is Video

There’s a lot of talk about the prediction from YouTube’s Robert Kyncl that video will be 90% of internet traffic. This sounds shocking until you realize it’s not, and doesn’t really mean much in context of the internet.

This number presumably is at least partially based on a prediction by Cisco who makes routers that carry that internet traffic. They even bought Flip (an unfortunate tale) simply to help drive video on the internet and presumably drive up the need for routers, their main business. They might have a bias.

The reality is video already is, and will continue to be the vast majority of Internet traffic. However that doesn’t mean people are spending as much time on it as the numbers will make you believe. Video per minute of online activity is just insanely high bandwidth and expensive. The percentage of bandwidth is meaningless, what matters is where people spend their time.

Video compresses very poorly in comparison to text and audio (interestingly, speech compresses fairly well these days). Video these days either streaming or progressive download is still a very bandwidth intensive activity.

This webpage is likely under 160 KB for you and loads in about 300 ms. You’ll spend statistically a few minutes reading this, perhaps slightly less if you just skim for the numbers. The takeaway is experiencing: this blog post is about 160 KB over a few minutes assuming you visit the site, and don’t use an RSS reader (go ahead RSS users, try it).

Now lets figure out what video is typically. Most web video these days is still H.264, and generally 640×480 (480p) or 1280×720 (720p). Most laptops today are pretty cheap and just can’t handle 1080p, certainly their displays aren’t good enough to show a measurable difference, not to mention the buffering time annoys people, so we’ll ignore it’s existence.

I want to make this a little realistic, so to figure out a bitrate, we’ll use the standard formula for what Adobe calls ‘ideal’ in the H.264 Primer, and what most seem to use these days:

[image width] x [image height] x [framerate] x [motion rank] x 0.07 = [desired bitrate]

For 1280×720 that means:

1280 x 720 x 24 x 2 x 0.07 = 3,096,576 bps = ~3000 kbps

And for 640×480:

640 x 480 x 24 x 2 x 0.07 = 1,032,192 bps = ~1000 kbps

This sounds about right. As of today, Wikipedia lists the bandwidth range for 720p at 2–2.9 Mbit/sec and for 480p at 0.8–1 Mbit/sec. So we know we’re on track.

That’s all the math we really need to do. Google can do the conversions for us:

For 720p:

3000 kbps = 1,318.35938 Megabytes / hour = 22 MB / min

For 480p:

1000 kbps = 439.453125 Megabytes / hour  = 7.3 MB / min

Going back to the example of this blog permalink, at 160 KB for a few minutes of reading vs. 7,475 KB for one minute of 480p video. That is why video is 90% of traffic.

Video growth is huge, but it’s not nearly as one sided as the stats will lead you to believe.

Define Mute

One of the tricky things about building products is defining the details. When you say “mute switch” as you’d see on a phone like the iPhone, what exactly do you mean my “mute”? App sounds? Calls? What about an alarm? Muting an alarm sounds reasonable, but perhaps the reason for using the switch is so you can sleep until your phone wakes you up in the AM (I suspect that’s actually a very common use case).

John Gruber has a pretty good insight on the iPhones mute switch design, which doesn’t cover alarms as one New York Philharmonic audience member learned the other night. I agree that it’s an edge case, however think an alert the first time you switch it (and then never again) would be a reasonably good UX. Doing so every time as he explains wouldn’t be workable since you often do use the switch without taking your phone out of your pocket. I know I do it all the time.

In “the old days”, you’d just make that a 3 way selector: mute all sounds, mute all but alarm, all sounds on. 5% of users would figure out how it works.

Privacy Issues Behind localStorage

Browsers need to overhaul their privacy settings to account for things like localStorage and bring control back to the user. In the days of cookies it was relatively simple for a user to wipe any identifiers (excluding IP address) from their browser. Simply clear cookies.

Firefox has two basic abilities, you can clear cookies, or you can browse and delete cookies. That’s great but not terribly clear that there’s more than cookies.

Firefox Cookie Privacy

Chrome as far as I know has no cookie browser like Firefox has, but (edit: Erunno notes in the comments you can via chrome://settings/cookies) explicitly lets you “Delete cookies and other site and plug-in data”. That’s pretty good.

Chrome Cookie Privacy

Today, I think Safari’s UI is the closest to perfect. Each hostname shows exactly what it has. My only gripe is that Safari doesn’t let you see what’s there. That’s a “power-user” feature however and I think it does an adequate job regardless.

Safari Cookie Privacy

Websites use more than just cookies these days. I discussed this a little over a year ago. The reason evercookie is controversial is that browsers don’t quite give users the level of control (real or perceived) that they expect for objects other than cookies.

Here is another use case for why this is needed. Google Analytics is used on perhaps half the internet’s websites. It sets a cookie every time. That means 230 bytes added to every http request for a lot of websites. Google could switch to localStorage and free up that 230 bytes. While they technically could do this, in practice, this could create a firestorm of attacks against them. The problem is it would be spun as Google trying to evade cookie deletion and and a privacy violation. The same storm that evercookie created. I suspect that’s why it hasn’t been done to date. The truth is the Google Analytics team has done a lot for improving performance including making it entirely async. But this move would be controversial.

It’s no longer about “cookies”, but “user data”.