Blog

The “race” car didn’t require that much work this year (replace water pump, replace oil seals, fix a blown strut, install a new seat, repaint the hood), we decided to make our pit buggy look like a mini-Festiva.  Soon after we slapped a bit cardboard on as a roof, we realized the pit buggy was almost the exact height of the Festiva already.  Since the pit buggy has tiny wheels, we knew we couldn’t do a super-deformed style either.    We just decided to wing it and see what came out!

After the roof was on, I just started cutting.  We ended up buying a few rolls of yellow duct tape.  Hours of middle-school-level crafting later, we had this:

Gorgeous, eh?

Android started naming their upcoming releases based on sweet treats.   1.5 was Cupcake, 1.6 was Donut and now 2.0 is Eclair.   The next version will be Flan and they are toying with using Gingerbread after that.   How long will they be able to keep this up?   I tried to come up with my own list and failed at X and obviously had to look some others up:

• Gelato / Gummy Bear
• Hard Candy / Hasty Pudding
• Ice Cream
• Jumble / Junket
• King Cake / Krumkake
• Layer Cake
• Macaroon / Marzipan
• Nanaimo Bar
• Oatmeal Cookie
• Panettone / Petit Fours
• Quaresimali / Quindim
• Rice pudding
• Snickerdoodle / Sorbet / Sponge Cake / Stollen
• Twinkie / Tarte Tatin
• Upside Down Cake
• Vanille Kipferl / Vaselopita
• Wafer
• X
• Yogurt
• Zabaglione / Zeppole

The first symptom was Clare’s laptop having trouble burning a CD through iTunes.  A few reboots later and some odd anti-virus dialogs started popping up.  A few web searches and another reboot later, the machine was completely owned.

Boot up was taking five times as long and was punctuated with incessant dialogs and tooltips from the system tray.  Having tackled a few bits of malware in the past, I immediately turned to Malware-Bytes Anti-Malware and ComboFix.  Unfortunately, the malware-writers know all about these tools and try so very hard to keep the system.   Here are some of the cute steps they took to keep the system in lock down:

• Disabled access to the Task Manager
• Disabled CD and USB drive access
• Turned off automatic updates
• Disabled all executables!

That last one was ridiculous.  If you could find a way to get a file onto the computer (don’t forget, no USB disks, no CDs), you couldn’t even execute the file.  I tried all sorts of tricks and literally everything was locked down.  Finally, a little research explained that only a few executables are allowed to run.  If you rename your app to explorer.exe, it’ll run.   Using that trick and Process Explorer, I was able to kill the offending processes.  A few registry hacks, exeFixer, ComboFix and finally Malware-Bytes and I think the system is fixed.

Oh, who am I kidding, I don’t trust a once-rooted system.  Time to wipe and install Windows 7!

Instead of just complaining about Android, I decided to do something about it.  It’s open source, eh?  I dove into the code and tried to figure out why the Browser was so jumpy.   I discovered that a single case statement controls a lot of the motions.  It checks if the drag threshold is reached and if so, it then continues with the normal drag code.  Unfortunately, it doesn’t reset the drag amount so you suddenly get this big jump when you start dragging.   If you reduce this by a large factor (I chose 80% after some testing), the jump is removed and you’re still able to drag quickly.

Here’s my bug report including a code patch for fixing it: http://code.google.com/p/android/issues/detail?id=4262

A better solution would be to unravel how motions are tracked and put the drag check in a different state from the drag start.  My coding ability is way too rusty for that.

• The MOTODROID startup sequence (warning, sound kicks in right at the end): http://www.youtube.com/watch?v=JBuLij0l7SU
• A great use for Google Wave (warning, NSFW audio): http://www.youtube.com/watch?v=xcxF9oz9Cu0

With the recent announcement of the first Android phone with the Snapdragon processor, the Acer Liquid, I had hopes that the browser would finally be up to snuff with the one found on the iPhone!   Instead of waiting for the Liquid to be released, I realized I could do some testing on my desktop.   The Android emulator, while not flawless, should be a pretty good indication of how the device would work with more CPU power.

The WebKit-based browser on Android has always bugged me, mostly because I’m used to the silky smooth browser on the iPhone.  Scrolling, flicking and nudging all work fantastically on the iPhone.   As I’ve mentioned before, it feels like the page is resting on a sheet of glass as there is no hesitation to the scrolling.  Also, the flick scrolling physics are calibrated to a usable level.   A full-speed flick will scroll down about two pages worth of data.  Any more than that and a user will lose context of where they are on the page.

I fired up the Android emulator and did some tests.   I found one glaring flaw and one issue that could be fixed quickly.  The reason why the browser seems so jerky is because it always starts with a jump!   Just try it:  the browser ignores the scrolling motion until a certain threshold is hit.  The threshold isn’t time-based but distance-based, 25 pixels to be exact.  Once that 25 pixel threshold is hit, the browser doesn’t just start scrolling but moves the page those 25 pixels immediately.  The iPhone has a threshold but it is much smaller and the initial threshold value is ignored.   The screen doesn’t immediately jump to have the screen position catch up to the finger.

The smaller issue is how far the page moves once it’s flicked.  Using Google REader as my test platform, a full-speed flick will scroll down by 10 list items on the iPhone but 29 items on Android.  It’s a tough compromise, trying to find a multiplier that works for all scenarios.  If a user is scrolling at normal speed, the page should move at a 1:1 ratio.  With a flick, the user obviously wants to move through the content faster but at what rate?  The iPhone takes a conservative approach and moves at roughly 2:1, scrolling down about two pages for a full-page flick.   Android takes a reasonable approach and scrolls at almost 5:1.  For a long page, you could flick through lots of content very rapidly on Android.  Unfortunately, 5:1 is just too great.   You can’t really process all five pages that just whipped past you.   2:1 might be too small but 5:1 is far too quick.

I can only assume the 25 pixel threshold was to keep the user from initiating scrolling too easily, especially if they were just trying to click on a link.   Initiating press-and-hold on an object would be even more important as the user needs to press a specific area for at least a second.  I think this 25 pixel threshold is too high and the jump is completely unnecessary.  Android is open source, right?  Where can I submit a patch to fix this?

Update:  Ha, I found the actual line in the code!

http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=core/java/android/view/ViewConfiguration.java:

private static final int TOUCH_SLOP = 25;

25 is too big!

• Two guys in a Ford GT (with at least two other cars acting as spotters) avoid the cops after hitting 140 MPH on a highway:  http://www.youtube.com/watch?v=TclJW9v2dLU

I’m a huge RSS fan and scan at least 500 articles a day.  The Google Reader desktop site is my go-to as the usability is enormous.   Clean design, snappy page loads, infinite scrolling lists, keyboard shortcuts and more make for a really painless experience.

On the mobile side, I’ve ended up using the Google Reader Mobile site.   I tweeted awhile ago about wanting a version of Google Reader that supported Gears.   Pretty much the only thing that trips me up on the mobile site is the loading times.  If it was Gears-enabled, I could have it sync up automatically, effectively killing the loading times.   Otherwise, the mobile site is fantastically efficient and meets all of my primary use cases.   Google knows the use case for reading RSS feeds on the go will be different than sitting down at a desktop.  The biggest difference is the need to digest news in smaller quantities.

On the desktop, the site lets you pull up every article from a feed and can even mark as read once you’ve scrolled past it.  You can organize your feeds by tags or folders but I’m a fan of just reading each feed separately.   I process the information better if it is not coming from multiple sources at once.  The mobile site also lets you read per feed and by default, shows 15 articles at once.   Fifteen is a reasonable default as it accounts for slow cellular data and supports the chunk approach to reading.    If I have scanned a headline and do not want to read the article, I definitely want to mark it as read.   I can scan fifteen headlines in a few seconds and go on to the next chunk.   If something else grabs my attention, I can just mark the ones I’ve scanned as read.   My mental model (“I have seen this article and don’t need to see it again”) and the software model match making the mobile site a breeze to use.

I had the pleasure of vacationing in Hawaii recently and thought I’d try an iPhone app that does offline syncing.  Five hours on a plane and I’ll get sick of my current book or Nintendo DS and thought catching up on my RSS feeds would be a good use of time.  From current reviews, it seemed like Byline would fit my needs best.  It does offline syncing, supports syncing with Google Reader and was quoted as having a blazing fast interface.  Unfortunately, I forgot to set it up until I was at the airport.  No wifi = no article caching.   I can’t fault Byline, I screwed up.   A little dejected that I impulsively spent $5 on an iPhone app (don’t laugh, $5 is considered high-roller territory in the iPhone app world), I gave up on Byline until I returned from the trip.

I fired Byline up once I was back in the confines of a home replete with wifi.   So, it’ll only grab the most recent 50 articles?   It won’t let me view by feed?  My first impressions were of confusion and confirmed I shouldn’t have spent $5.  Once I decided just to take a look at the crappy “50 most recent, no sorting” view, the really whammy hit.   On the Google Reader Mobile site, it’ll feed you a list of articles.  You can see the full headline and if there’s space, a snippet of the article itself.   Clicking on a headline expands that item, showing the full article and any associated pictures.  As you scroll, the rest of your headlines are still there.  You aren’t taken to another page.   In Byline?    Clicking on an article takes you to a new page.  You either have to hit back to go to the full list or you’re given up and down arrows to move to the next or previous item.   This is _terrible_ for reading feeds.  I don’t want to use the up and down arrows because I’m not sure I want to read the full article.  I just want to see the headlines.   I don’t want to use the back button as there is a perceptible delay every time you change views.  To make matters even worse (yeah, this is getting bad), Byline doesn’t even show the full headline.   It crams as much as it can into a two line list item.  If the headline doesn’t fit, it gets trimmed.  Just trying to _read_ feeds is tiring:

I did a bit of digging and found that Byline will show you a “folder view”.   This required making folders on the desktop site and then organizing every single one of my feeds.    There was also a setting that would increase the 50 limit to 200.   Not sufficient, but an improvement.  With these changes, I could actually view my feeds in a slightly more organized fashion.  Unfortunately, the flow for reading feeds was still so mentally taxing!   Every single click required some amount of delay.  The great thing about the mobile site is that, once the headlines are loaded, there is almost no delay.    Clicking on a headline opens the article immediately and the images are loaded soon after.  Google got it right; instead of adding a delay with every action, they bundled it all together.   I might have to wait 5 seconds for a batch of headlines to load but once that has loaded, it’s instantaneous.

I might be giving Byline a bad rap; it’s probably a good application but Google Reader Mobile is already a great application… and it’s free.   Can I still ask for a version with Gears support though?

• Thursday:  Pies & Pints with Jeev’s crew for his birthday.
• Friday:  Txori for dinner then Patton Oswalt at the Moore with Damon & Knifer.
• Saturday:  Clare finally let us start watching Dexter…  seven episodes later, I ended up seeing Jeev’s crew again for The Beatles: Rock Band and cake.
• Sunday:   Hmm, we seem to have already finished the first season of Dexter….   we then hung out with her younger brother Nate and finally got him a haircut.  1.5 years of growth was a little excessive.

Overall:  Satisfactory.

I’m at a different hotel spot than usual at work.  Instead of my normal HP dock and basic-but-effective Microsoft Compact Optical Mouse 500, I have an Apple chiclet keyboard and a Mighty Mouse.  Two clicks into using the thing and I’m already annoyed.   I understand the desire for a solid click _feel_, but does that have to be accompanied with a piercing click _sound_?  I’m a voracious clicker; I’m either designing something at a rate of 30+ clicks a minute or I’m web browsing and often clicking different interface elements.  I’m self-conscious using this mouse; I feel that my coworkers are annoyed by the rifle-bolt-loud clicking that is echoing off my desk at semiautomatic machine gun rates.

Regardless of annoying others, the ergonomics annoy me deeply.  The bar of soap shape fits the palm alright, if you lay your palm flat on a mouse.  No one that needs precise motion does this, though!   I normally grasp a mouse with my thumb and pinkie finger and keep my pointer and middle fingers resting on the left and right buttons.    On most mice, a quick swing of your pointer finger is all it takes to go from the left button to the scroll wheel.  On the Mighty Mouse, the scroll wheel is a little track ball set too far medially.  I need to pull my finger to the right, pull my finger back and pull it so the tip of the finger is activating the scroll ball.

On top of all that, the cord is way too short to use on any non-Mac device and it costs $70.   1/5 stars.   The mouse would have to infect me with SIDS to get a lower score.