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).
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†.
- 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.
(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 email@example.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.
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 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 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