Words

Well That Was Fun.

David Hu — Mon, 23 Apr 2012 22:17:54 -0400

Protip—Never put this in a Chrome extension.

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

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

David Hu — Wed, 04 Apr 2012 22:19:59 -0400

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.

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

David Hu — Mon, 27 Feb 2012 02:17:26 -0500

We can’t even standardize a simple subdomain?

Developer

Developers

Dev

https://dev.twitter.com

And then there’s this guy.

http://msdn.microsoft.com

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.

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

David Hu — Wed, 15 Feb 2012 19:42:30 -0500

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
`^in` `^In`	lin Lin	insanity → linsanity
`^li` `^Li`	lin Lin	library → linbrary
`^.in`	lin	winning → linning
`lin/i`	LIN	slinky → sLINky
`ling$`	LIN'	styling → styLIN'
`Lin`		Jeremy Lin → Jeremy

Google Chrome: Bringing Fitts's Law To You

David Hu — Tue, 07 Feb 2012 11:14:32 -0500

Google has always had decent UX practices, notwithstanding their complete lack of Android UX guidelines before 4.0 and the occasional dubious Doodle. Tabbed browsing can suck sometimes (and I’ve tried to make it suck less before), but this feature of Chrome has always made me happy:

This image shows me in the middle of closing a bunch of tabs in Chrome by clicking the “close” button on one of the tabs on the left. Notice a few things:

Generally when you close tabs, they will either resize 1) uniformly to a predetermined “natural” size or 2) to fill the tab bar, whichever property is satisfied first.
Here though, the tabs are not resizing, or else they would have been resized to fill the tab bar (note the empty space on the right, indicating they’re being forced to not resize)
This makes it easier for the user to close the tabs: I don’t have to keep moving my mouse to hit another “close” button. I would be chasing “close” buttons if the tabs kept resizing.

This in and of itself is already pretty cool. But notice how I’ve always been clicking “close” on the 4th tab from the left. What happens when there are, say, 3 tabs left? Because the tabs aren’t resizing, my cursor would no longer be over a “close” button.

Should the width of the tabs stay consistent until I indicate I’m done clicking “close” buttons? Since I’m no longer hovering over a “close” button, should the tabs go with option 1 above and reset to their “natural” sizes? No. What Chrome does here is downright genius:

The tabs start resizing, but they resize so that the “close” button of a tab stops just under my mouse cursor—ready to be clicked. I can keep clicking to close more tabs without moving my mouse at all. Note the difference between the image above and the one below, where I moved my cursor and caused the tabs to resize to their “natural” sizes.

To paraphrase Fitts’s Law, the further away a target is, the longer time it will take to acquire and act upon that target, and the more frustrated your users become. If you think about it, Google here is actually bringing Fitts’s Law to you. Instead of you moving your mouse to acquire a target, the target comes to you.

There’s an awful “In Soviet Russia” joke in here somewhere.

^†In their defense though, Firefox for OS X does seem to behave this way as well. However, this "resizing to the cursor" feature seems to be missing in some other favorite apps with tabs, such as Safari, Sublime Text 2, and Terminal (well, it's not that I have that many tabs open... I just have really small Terminal windows sometimes).

Fuck It I Need To Study

David Hu — Wed, 18 Jan 2012 00:44:20 -0500

SOPA and its Senate cousin, PIPA, are really bad things. Many well-known websites are participating in a demonstration against the two acts, including Wikipedia English, which is blacking out its entire site.

I do not support these bills, nor the intents behind them. Never have I appreciated Wikipedia and free information on the Internet more. But sometimes you’re a kid in college and you just really have to study. If you’re like me, you can use the bookmarklet below to uncensor any English Wikipedia page^†.

Stop SOPA, Read Wiki

To use:

Drag the link to your bookmarks bar
Navigate to a Wikipedia English page
Click the bookmarklet

You’ll need to re-click the link again on every Wikipedia page, but hey, at least you can view them.

Of course, you can always also view everything in Polish.

^†Sometimes each click will also open up a link to americancensorship.org. Take action.

And Then There Was Bwog

David Hu — Tue, 03 Jan 2012 17:33:44 -0500

(Otherwise known as: Because I have a blog again and I’m allowed to be narcissistic.)

With Gmail yelling at me at least three times last semester “you’re maxing out your inbox!” I thought it would be interesting to do some analytics and figure out some patterns in my 87,455 email messages. Using a handy Python script, mail-trends, I verified what pretty much everybody already knew: you get a shitton of email when you join a campus organization.

Below is how my mail breaks down by year in terms of volume. I came to Columbia in Fall ‘09 and joined Bwog that first semester.

Because the exponential growth in mail could just be attributed to general college shenanigans, the breakdown of email recipients for 2009 (the “To:” field in an email) really verifies the Bwog Effect on mail:

(The blue “David Hu” is my Columbia email address, and there are multiple Bwog aliases for technical reasons. Other recipients are hidden for privacy reasons.)

And by 2011, there were more emails addressed to tips@bwog.com than my email address in my own damn inbox:

However, just like how it’s important to be reminded of friendships and friends when work for school or a campus group seems to take over your life, it’s good to realize that in a sea of Bwog-related email threads (subjects hidden), sometimes conversations among friends still reign supreme.

Intensishot

David Hu — Sat, 31 Dec 2011 16:00:41 -0500

I’ll be working with Android as part of my new job at kikin next semester, so what better way to familiarize myself with the platform than make a simple app? Check it out!

Thoughts on Android

While they’re still fresh, a few thoughts on working with the platform for the first time.

Java

Java is nice.

Android UX Conventions

I believe one of the more important things in app development is sticking to a platform’s UI/UX conventions (otherwise known as “visual language” if you’re a tool (jk (sorta))). One thing you immediately begin to realize is that the interaction paradigms of Android are not the same as iOS, or even designed to be similar. iOS makes heavy use of bottom tabs; this pattern isn’t even one of the default layouts for Android. There is no established meaning for a long-tap on iOS; it almost always brings up a contexual menu on Android. In general, this blog post does a great job of breaking down the differences between Android and iOS UI conventions, and Android Patterns has some great info on Android conventions specifically.

Supporting Multiple Screens

Lesson: Do not use hard-coded pixel values in your application code. The need to support multiple screen resolution, densities, and physical sizes is a pain. I’ve dealt with this somewhat with web development, but the concept of densities was foreign to me. I currently solve the multi-screen problem by scaling a single set of graphics, but this can obviously be improved upon: on bigger screens, graphics deteriorate.

The Developer Experience

When compared to the other dominant mobile platforms, iOS and Web (sorry WP7 & WebOS), setting up the Android dev environment was a little more painful than necessary. Installing the SDK is a guide that needs an edit or two. Steps 2 and 3 sent me on an infinite loop because Step 2 never actually tells you to install the starter package.

Eclipse is alright.

Publishing was a breeze. It was possible to export my app to an APK and be in the Android Market within 30 minutes. The fact that I also have the freedom to distribute my app as a stand-alone APK download without being tied to a specific online marketplace is a big plus as well.

LogCat

LogCat is my friend.

Continuation of the App

The app is currently technically at version 0.1, and a few things I plan to do before officially calling it 1.0:

Better support for multiple screen densities
Add a “history” feature that tracks intensities throughout a night and resets every day at 6 pm
Improved instructions label

Hello Words

David Hu — Sat, 24 Dec 2011 23:49:49 -0500

Yes, I’m starting (another) blog. And there’s nothing you can do about it.

I’ve been meaning to start a blog for a while, and various things kept preventing me, but alas here we finally are. I hope that Words will be a little different than my previous foray into personal blogging in a number of ways:

I hope to focus mainly on topics concerning the web, programming, CS, or any other issue relating “technology” or “the industry.” I guess it’s broad by design.
I hope this won’t devolve into a personal blog in the style of a LiveJournal; I have Facebook already. Expect the occasional funny picture though.
I hope to update this more often than I did my personal blog in the later years. I may eventually go back to updating that too.
I hope this will be a steady creative outlet. As I stopped writing daily posts for my last foray into non-personal blogging and started assuming other duties, I started missing the writing, and I hope this will help me scratch the itch.

In the end though, I just hope for this to be seen as merely my words, and nothing more. They really carry little weight if you think about it.

But I hope you’ll humor me and join me for the ride.