leŭksman

“Hello, may I speak to Donald (something) please?”

“Sorry, you have a wrong number.”

… pause …

“Oh, I really *do* have the wrong number. I thought I didn’t for some reason. Sorry!” *click*

o_O

Nothing earth-shattering in the announcement, but some pleasing things…

• Rumor is it gets better reception — might be very welcome here in San Francisco, where you get 5 bars on one block and 0 bars the next…
• Faster download speeds are great… assuming I get any reception…
• Longer battery life — I charge it every night anyway, but might be nice during travel.
• GPS — more accurate placement for maps would be handy, but I’ve found it good enough on the old system.

Otherwise it’s pretty much the same, hardware-wise. New software will be available on the old model too, and there’s still not a model with 32GB storage. 16’s not quite enough for my full music library, so I don’t have a huge incentive to upgrade from the 8GB model unless the reception really is good enough to… say… successfully make phone calls from my flat.

As for pricing… the purchase price is lower, but the the plan’s an extra $10/month, which more than makes up the savings over the contract lifetime.

On the plus side, the draconian requirement to activate your contract at the store means our European friends will stop pestering us to buy iPhones for them to take home and unlock. >:D

The HAWHAW library used for our Hawpedia-based mobile gateway does this cute thing where on a “grown-up” web browser it squishes the formatted output into a tiny rectangle, with a cute picture of a mobile phone around it.

This “simulator” mode makes it … sort of… look like an actual mobile device. But IMHO this causes more harm than good. Two main problems:

• Unrecognized devices can end up being shown the simulator skin, often horribly misrendering it (like the Palm Treo at right — hopefully recognized since a few weeks ago)
• It’s harder to actually get a feel for the variety of behavior on devices with different screen sizes. There’s everything out there from the tiniest cell phone to the iPhone to the Amazon Kindle reader’s big ol’ 6″ screen. There’s no way to resize the tiny rectangle, so you can’t estimate how things are going to feel on the medium screens.

I’ve now disabled this. With the simulator / “big screen” mode off, regular web browsers and unrecognized devices get pretty much the same output style that you see in things like the iPhone. It’s reasonably clean, and will properly scale and wrap with your screen size.

Velocity
June 23-24 - Burlingame, California

Domas Mituzas, slayer of slow database queries and WMF board member, will be giving a talk on Wikimedia’s operations. Since we’re having a staff meeting here in San Francisco around the same time, the whole tech team will be out for the conference; come ’round and say hi!

Wikimania
July 17-19 - Alexandria, Egypt

Awwwww yeah

OSCON
July 21-25 - Portland, Oregon

I’ll be taking a detour through scenic Portland on my way back from Egypt to hit OSCON; I’m particularly interested in checking out the Open Mobile Exchange to get a sense of what’s going on in the mobile web & rich mobile app space.

Portland is the birthplace of Wiki, of course, so a pilgrimage is required. Hope to run into some wiki-friendly folks while I’m up there…

We had a post come in this morning on mediawiki-l about an extension for adding a hash-based duplicate file check on upload.

A similar check had been recently added to MediaWiki core, but only on the file description page — it wouldn’t stop your upload while you were in the process. Since all the required backend was there I’ve gone ahead and added it in as a built-in feature for MediaWiki 1.13:

(Note that since we can’t get the file content hash until you upload, there’s still no way to give the warning before you actually upload it. But at least now it lets you cancel at that point instead of having to ask a sysop to come delete your file!)

While rebooting to install software updates…

Just for kicks, I cleared my cookies & caches and loaded up Wikipedia’s “Frog” article fresh to see what the breakdown of network bandwidth would look like…

645,947 bytes of data content are transferred, not counting any HTTP headers:

This would take about 90 seconds to download on a 56kbit connection. It’s easy to forget what low-bandwidth feels like for those of us with broadband, but people outside cities may not have good broadband, and mobile devices are often stuck on pretty slow networks too. Compare regular Wikipedia against our mobile gateway on your mobile phone sometime; even a fancy browser like the iPhone’s will feel like molasses trying to load the full site, while loading things up lickety-split from the more minimal mobile gateway.

Fairly simple compression improvements could save 128kb of that:

• 64k by gzipping JS and CSS files that are currently served uncompressed
• another 64k through smarter compression of thumbnails (animated GIF optimization, use of JPEG for some PNG thumbs)

That would save approximately 18 seconds of download time for our hypothetical low-bandwidth user.

Details at mw:Wikipedia_data_size_test…

Magic quotes strike again!

I’ve disabled magic_quotes_gpc on our mobile transcoder’s PHP configuration, fixing access to articles with apostrophes or double quotes in their names:

Of course, it should be fixed to detect and undo this data corruption on input. At least this misfeature is finally going to die in PHP 6…

Okay folks, as of a couple hours ago unified login is available opt-in for all Wikimedia accounts!

In addition, we’ve enabled the site-wide global session cookies (which have been in testing for the SSL interface on secure.wikimedia.org for a few weeks). Some people may not be able to successfully get that working across domains (we’ve got reports of Norton blocking the login-cookie-fetching images), but it seems to be working for most people so far.

This means that not only will your global, unified account have the same password on say English Wikipedia and Commons, but once you’ve logged in on one you’ll be logged in on the other, without having to log in a second time. Handy!

Note that to do this fully automatically, when you visit a new wiki for the first time it will autocreate a local account for you, linked to your global account. Initially this was spamming the Recent Changes lists with account creation logs, but I’ve now pulled that (they’re still logged in Special:Log, however). (This has been disabled for now, as it’s spamming logs and user lists faster than expected, even through “invisible” links like shared JS and CSS. You’ll still get your shiny local accounts by going through the regular login form, and once you’ve done it once your sessions remain shared.)

Big thanks to Tim Starling who’s done a huge amount of work on CentralAuth in the last couple months, as well as Andrew Garrett who’s helped a lot with the cross-domain cookie logins and global Steward group management.