Hi, my name is David and these are just some of my words.

by David

Well That Was Fun.

Protip—Never put this in a Chrome extension.

chrome.tabs.onUpdated.addListener(function(tabId, changeInfo, tab) {

23 April 2012

The Three Numbers of Lumia: 900, 800, and 480

The reviews for Nokia and Microsoft’s Lumia 900 have been exploding online as the flagship phone sets to launch on April 8 and a media embargo on reviewing it got lifted at 9:00pm last night (TechCrunch called this “awkwardly timed,” but come on guys, it’s the Lumia 900). They all mostly say the same thing: it’s a beautiful and striking phone; a sure competitor at its $100 price point that includes an LTE radio; and perhaps most of all, how the 900 will be the two former giants’ “make or break” handheld device here in the States.

While different reviews have honed in on different critical flaws (many of which I disagree with: Engadget blames its blandness, Pogue claims it’s WP7’s lack of apps, the Verge decrees the WP7 OS isn’t quite up to snuff), each have mentioned in passing the same deficiency of its screen resolution: the merely-acceptable 800x480. When compared against the iPhone’s retina display or some Android devices’ 720p resolution screens, the difference in the display quality will surely be grossly evident, making potential buyers question the “flagship” label of this device.

This has always boggled me, and I’m afraid this is actually the biggest flaw of not only the 900, but Windows Phone 7 itself.

According to the original Windows Phone 7 design guidelines, “All Windows Phone 7 phones will have WVGA screens at 800 x 480 pixel resolution, no matter the screen size.” It seems that the operating system and SDKs were designed with this in mind, and I can think of no better way for a platform to shoot itself in the foot from the very beginning. Even after Microsoft refreshed their docs after the much-loved 7.5 “Mango” update, design guidelines still refer to “the full 480 x 800 pixels” as the only real estate available for app developers.

It’s easy to understand why the WP7 team may have chosen to lock the mobile operating system’s resolution. On a system based so heavily on typography and small but charming details, more control over what is displayed means a better and more unified end-to-end user experience. I mean, isn’t that the Apple Way? (And look at how successful they are at it.)

But this analysis is missing perhaps the most critical component of the Apple Way: the hardware integration. iOS is not a platform that is licensed to many manufacturers, so it’s okay that they restrict it to only a single (or two, depending on how far back you go in device history) resolution(s). On the other hand, Windows Phone 7 is licensed to many manufacturers—which, for better or worse, are very fond of producing many different phones with many different display sizes. Restricting your platform to a single screen resolution in this case makes it more difficult for manufacturers to have the freedom to choose display technologies and sizes, which makes it harder to make deals, and ultimately, satisfy the end user.

I hope to see Windows Phone support more resolutions in the future.

04 April 2012

Developer, Developer, Developer... Developers? Dev?

We can’t even standardize a simple subdomain?




And then there’s this guy.

Can’t we make all the subdomains for developer resources under http://developer.*? All the non-developer domains I listed above already redirect http://developer.{facebook, google, twitter, microsoft}.com to their respective subdomains. It doesn’t quite work the other way around: http://developers.{apple, android, twitter, mozilla}.{com, org} all lead nowhere.

This just cries out the fact that the developer subdomain is pretty standard. A great parlor trick is to navigate to http://developer.x.com when looking for developer resources because you’ll probably end up finding what you were looking for, but a better way to address the issue is to standardize the subdomains themselves.

26 February 2012

Milking It For What It's Worth: #linsanity Edition

Because it’s much more fun than doing an alternative analysis on quicksort and I found the current site devoted to Jeremy Lin puns a little abysmal, I decided to create my own.

Behold: #linify it.

It’s actually a dead simple site that I threw together mostly during a class, and its core revolves around a few key regular expressions and replacing instances of them. Below are the ones I currently use—do you have any suggestions?

Pattern Replacement Example
insanity → linsanity
library → linbrary
^.in lin winning → linning
lin/i LIN slinky → sLINky
ling$ LIN' styling → styLIN'
Lin Lin Jeremy Lin → Jeremy Lin

15 February 2012

← Previous posts Next posts →