leŭksman

We finally replaced my fiancée’s ancient PC with a shiny new Dell laptop. While ordering, I couldn’t help myself and tossed in a Inspiron Mini 9 for myself:

This little cutie weighs in at just 2.26 pounds, less than half of my MacBook’s hefty 5 pounds. I’ve found that the Mini is much more back-friendly than my MacBook; I can painlessly lug it to the office with my laptop bag slung over my shoulder (easier for getting on and off the subway) instead of nerding it up in backpack mode.

The top-end model I picked packs 16GB storage and 1GB RAM running on a 1.6 GHz Atom processor — far more powerful than the computer I took with me to college in 1997. Admittedly, my iPhone also beats that computer at 8GB/128MB/300MHz vs 6.4GB/64MB/266MHz.

The compact form factor does have some impact on usability, though. The 1024×600 screen sometimes feels too tight for vertical space, but they include a handy full-screen zoom hotkey for the window manager which opens things up.

The keyboard feels a bit cramped, and some of the keys are in surprising places (the apostrophe and hyphen are frequent offenders), but it’s still a lot easier to type serious notes or emails on than the iPhone. I had to disable the trackpad’s click and scrolling options to keep from accidentally pasting random text with my palms while typing…

The machine shipped with a customized Ubuntu distribution which is fully functional; they include a “friendly” launcher app which can be easily disabled, and even the launcher doesn’t interfere too badly. The desktop launch bar that’s crept into Gnome nicely handles my “I need Spotlight to launch stuff with the keyboard” fix. Firefox works fine (after uninstalling lots of Yahoo! extensions), Thunderbird installed easily enough, and I even got Skype to work with my USB headset! (AT&T’s international roaming charges can bite me…)

The biggest obstacle for me to use this machine every day is my Yojimbo addiction. I use Yojimbo for darn near everything — random notes, travel plans, budgeting, grocery lists, recipes, encrypted password stores, saving articles and documentation for future references. It’s insanely easy to use, the search works, I don’t have to remember where I saved anything, and it syncs across all my Macs. But… it’s Mac-only.

I’m trying out WebJimbo, which provides an AJAX-y web interface for remotely accessing your Yojimbo notes. It’s very impressive for what it does, but I’m hitting some nasty brick walls: editing a note with formatting drops all the formatting, but I use embedded screen shots and coloring extensively in my notes.

I’ve seen some reports of people hacking Mac OS X onto the Dell Mini — very tempting to avoid OS switching overhead. But I think if I really want that, eventually I should just suck it up and buy a MacBook Air. The form factor is the same as my MacBook (full keyboard, roomier 1280×800 screen), but at 3 pounds it’s much closer to the Mini than to my regular MacBook in weight, so should be about as back-friendly for the subway commute and air travel.

Of course, the Air costs $1799 and I got my tricked-out Mini for about $400, so… I’ll save my pennies and see.

After a previous reworking of MediaWiki’s stylesheet-handling code to allow adding handheld stylesheets, I’ve gone ahead and implemented bug 2889 adding per-site customizable MediaWiki:Print.css and MediaWiki:Handheld.css pages.

The ability to specify some handheld tweaks is needed to be able to work around issues with certain kinds of layout formatting, especially the big beautiful multi-column table layouts which are popular on portal and main pages.

While lovely on a large screen, on a small device they tend to either make the columns reaaaally tiny or push things out off screen. On English Wikipedia I’ve thrown in some quick style hacks to flatten out those tables on the main page (this was applied already by Opera Mini’s classic view, but not Opera’s other browsers in small-screen mode):

Before:

After:

There are still improvements that can be done, but it at least helps things fit on screen! MediaWiki:Handheld.css can be edited on each of our wikis to tweak things up as desired/required.

Of course it’s always best to try to use clean, scalable styles that work on small screens to begin with.

For MediaWiki 1.14 I’m doing some refactoring of the CSS configuration to simplify some of the ugly and dupe code and to make things like adding handheld-friendly stylesheets easier…

An older experimental handheld CSS for MonoBook got trashed some time ago after complaints from some Opera folks that it just didn’t seem to work properly… so to experiment with this anew, I’ve added a site config option. By setting $wgHandheldStyle, you can now specify a custom style to use for browsers that think they’re “handheld” media. (These would normally exclude the regular stylesheet anyway, which is listed for “screen” user-agents.)

I’ve currently got it set on Wikipedia to specify the “Chick” style sheet, which is just an extra style variant on the MonoBook HTML, so fits rather conveniently.

Some bits of the HTML output for the curious:

<link rel=”stylesheet” href=”/skins-1.5/monobook/main.css?164″ type=”text/css” media=”screen” />
<link rel=”stylesheet” href=”/skins-1.5/chick/main.css?164″ type=”text/css” media=”handheld” />

You can preview it on-screen by adding &handheld=yes on the URL, just like &printable=yes for the print stylesheet.

I’m still a bit unclear on what devices actually support the ‘handheld’ media type, but I’m pushing for adoption of it with some device makers. Note that the iPhone/iPod Touch doesn’t grok ‘handheld’, probably quite deliberately since they want it to understand real ’screen’ styles most of the time. You can make the iPhone (and Opera Mini in its new, fancier default view mode) use the handheld style by setting $wgHandheldForIPhone to true, which transforms the media types to use CSS3 media type queries on the screen size.

It’s a little funky-looking, but theoretically totally backwards-compatible.

Currently I’m not using this option live as the Chick style is still pretty awkward, and there’s no good way to disable the ‘only screen and (max-device-width: 480px)’ stylesheet if you don’t like it (well, other than adding UI and cookie crap).

So you can play with the handheld style on… Opera in “small screen” mode, Opera Mini in “mobile view”, and… anything else that you’ve found that I haven’t.

Been here in Portland for a couple days for the start of OSCON, but still recovering from Egypt time… Some notes on the Open Mobile Exchange sessions…

A lot of the sessions told the same sad story. To make a long (sad) story short:

The good news:

Highly-capable “real web” browsers are here and becoming more widespread. WebKit, Gecko, and Opera-based browsers are shipping now on various devices or available for installation, and the Mozilla folks are working on a next-generation Gecko-based mobile browser.

Making the “mobile web” actually able to reach the real web is a huuuuuge boon:

• People can reach sites that haven’t been optimized for mobile access (eg, 99.99999% of the web)
• Mobile-targeted versions of sites can actually look good and be useful
• Developers finally have a chance in hell of testing their mobile-targeted sites — the desktop versions of the browsers provide many of the same capabilities as the mobile ones, so you can preview faster and more reliably during iterative development.

The bad news:

Oh, where to begin! First, the bubble-burster:

• Phones with good browsers are expensive! To reach those oft-touted billions who will own a mobile phone before setting eyes on a computer, we’re going to need the browsers in the $20 commodity phones, not just the $500 luxury smartphones.
• Phones with good browsers are a tiny, tiny, tiny percentage of those out there today — even a tiny percentage of those shipping now.
• To wit, for many years we’re going to see a lot of phones with no or crappy browsers.

Now, we can hope that Moore’s Law For Phones will push all the cool stuff into the commodity devices Real Soon Now, but I didn’t see anybody showing me evidence that it’s actually happening. Even the Symbian guys, who boast their OS runs “90% of the world’s smartphones”, realize they have only a tiny share of the total phone market.

We’ll consider this a “growth opportunity”.

The second challenge is that web apps today, while very capable with AJAXy stuff, have several major limitations:

• No access to native device capabilities (camera, GPS, telephony)
• No consistent system for offline functioning and data storage — you lose access to the world when your train goes in a tunnel or you get on a plane
• Performance problems due to running JavaScript on top of HTML on a relatively slow, limited CPU

You can get around these limitations by writing native applications, but Here There Be Dragons.

• Huge array of incompatible OSs, with
• incompatible development models, and
• incompatible application delivery formats

The “Linux mobile” people like the LiMo foundation are putting effort into standardizing some of the base software which should help with that, but honestly even us Penguin lovers hate that it’s virtually impossible to build a distro-independant package for the desktop and server Linux worlds. Do we really expect it’s going to be different for mobile Linux?

Even if that was solved, you still have to produce your Windows Mobile, iPhone, Android, and Java FX Mobile 2ME P2P WTF versions just for starters.

It seems to be everyone’s hope that native apps will “fade away” in importance as web apps become more capable.

But this is going to depend on the various browser makers and device makers agreeing on some things:

• Sensible offline code & data storage. There’s motion on this with things like Gears and HTML 5 work, so I’m optimistic here.
• Creating, then hopefully standardizing interfaces between web and native capabilities. This feels like a coming browser war… worst case is we can hope that JS libraries will abstract away the competing interfaces. Sigh.

So in the meantime, we’ll all make our pretty little web apps, churn out the occasional iPhone or Android or Mobile Linux app to use geolocation data or the camera or work offline, and wait for things to get better.