State of current master in github for iOS (note the mixed, incomplete icons on the toolbar, and the laundry list of things that don’t work):
Also a not yet fully-functional mockup for Android tablets:
Mostly poked at mobile today – switched it from an iframe to loading into a div, fixing some of our scroll & click through issues and fixing it for Android 4.
Experimented with iscroll 4 library to handle the scrolling and add zoom, but too slow for now.
A little more poking at EmbedScript experiment; I have a sandbox domain temporarily on a Wikimedia Labs VM. Will show off more on this later.
My Galaxy Nexus arrived in the mail on Friday; I’ve been fiddling with it intermittently since. (You’ll go blind!)
Some first & second impressions:
What I kinda want is the same phone, but with a 4″ diagonal screen at 1024×640. Make it fit the hand better, rather than going for that hugeness. I don’t watch a lot of movies on my phones, but I do hold it in one hand and read/write news & messages every day.
Can now post comments on bugs! Auth prompt at post time. No offline queuing yet.
Bug list defaults to showing recently filed bugs. Various search and sort options, incomplete but a start. Doesn’t handle huge return lists well; server gives chronic order oldest first, we want the opposite.
Initial appcache for offline usage. Limited as there’s no persistent data cache yet, but you can load the page when offline.
Restructured bug view to put comments first.
More details in bug list items.
High-density displays are already here on small screens, and should start hitting tablets, laptops, and desktops in the next couple years. Apple’s iPhone 4 and current-model iPod Touch sport a best-of-breed 326dpi display, while lots of Android and Windows Phone devices have an intermediate 240dpi resolution. With the new Galaxy Nexus, Android’s entering the 320+dpi world as well.
The most immediate effect is of course that text renders as sharply on screen as in print. As a web-based application, Wikipedia gets this über-shiny text rendering “for free”… but for graphics, we’ll have to work a little harder.
Most images you’ll find on the wikis are either largeish raster images that are being scaled down for in-article viewing, or scalable SVG drawings that are being rasterized to PNG on the servers for broadest browser compatibility.
Unfortunately neither automatically takes advantage of a high-density display!
For SVG drawings, we can simply start serving the original SVGs instead of the rasterized PNG images, and they’ll look lovely (images from Gas giant article mobile view, rendered on an iPod Touch, with high-res versions swapped in by this bookmarklet):
We’ll need to make sure we can do this with a good fallback to PNG however — while all major desktop and mobile browsers in their *latest* versions support SVG, there’s still a lot of Internet Explorer users and Android users who can’t view SVG. Some less capable mobile devices may also be unable to handle full SVG (Android is rare among smartphones; SVG support is missing on most Android phones today but is present in Android 3.x tablets and upcoming 4.x phones).
We also need to make sure that file sizes and rendering times are reasonable; large maps might be very expensive to transfer and render client-side when we really only need a small map. See my SVG-Open 2009 slides for some data on PNG vs SVG sizes and the need for work on shrinking files.
Other files are usually available in a size larger than they’re shown on default-density screens, so putting a 1.5-sized or double-sized thumbnail into the same screen space makes it match the screen’s actual density. This is particularly useful for diagrams that were created as raster images instead of SVGs, since they often contain fine lines and text which benefits from the full resolution:
SVG and PNG images used for icons and diagrams are probably the highest-priority for high-density images. Photographic images can also benefit, but usually scale up better than line drawings and text because they have fewer sharp edges to begin with.
Math equations are another thing; currently we render most math equations to PNG images (via LaTeX); these also render poorly compared to other text on a high-density display. The best solution for this appears to be to migrate towards client-side math rendering based on the MathJax library; using MathML or HTML and CSS, this system is able to use the browser’s native text rendering much more effectively for math. Equations rendered this way look stunning at high resolution!
I’ve been looking for a good solution to catching up on bug reports on my morning commute. The regular Bugzilla user interface doesn’t scale down well to mobile, and using the regular web interface is too flaky when connectivity goes in and out.
Enter BugTender: a preliminary HTML web app with a mobile-friendly interface to browse (and later, comment on & triage) your bugs.
Using HTML and jQuery Mobile lets the app run on multiple platforms and browsers — it won’t be tied to just WebKit, and works in a regular desktop browser as well. Wrapping that in PhoneGap for a ‘native app’ will allow further integration, such as access to the camera and photo gallery on iOS and older versions of Android — think uploading screenshots straight from your phone about problems in the browser!
Anyway, that’s how I spent chunks of my Thanksgiving weekend… more to come.
Driven by curiosity, I went ahead and preordered an Amazon Kindle Fire tablet, which I’ve been using off and on for the last week.
I’ll leave super review details for dedicated reviewers, but here’s a few notes from me:
On the software freedom front: the Fire actually fares better than I expected. Like most Android devices it defaults to allowing only apps from ‘known sources’ to install (in this case, the Amazon App Store) but this can be flipped easily in preferences, and you can install .apk packages from direct download or USB transfer.
Hooking up to a computer for debugging over USB works but requires some tweaks to get the Android SDK to recognize it. This is the only way to do screenshots, since self-hosted screenshots weren’t added until Android 4.0 (grrrr! my fave little feature from iOS since the 2007 iPhone release).
As a practical matter, lack of access to Google’s Android Market is inconvenient; even many free apps haven’t set themselves up on the Amazon store and don’t offer direct downloads. Additional alternate app installers can be used as well though, such as F-Droid or the various custom markets folks have been using in some areas.
A few weeks ago I threw together a quick demo HTML canvas game ‘FlatRoller’; I’ve updated it this weekend to add a few things:
It’s a little sluggish on my first-gen iPad, but runs very nice in Metro IE 10 on my Dell Inspiron Duo tablet/notebook convertible. Yay!
I’ve also tried it out on my Android phone (Nexus One) and tablet (Kindle Fire), both running Android 2.3. Unfortunately both run pretty slow in both the stock browsers and Firefox, and only appear to pick up a single finger’s worth of touch events so the jump control doesn’t work.
Got your shiny new Amazon Kindle Fire tablet in the mail today? Desperate to check out rendering & app compatibility issues but taking “screen shots” with your cameraphone is getting old?
Plug the Kindle Fire in to your computer with any micro-USB cable, and ‘adb’ and ‘ddms’ etc will work. Yay!
Note that screenshots taken from ddms appear to come out in landscape orientation, regardless of the actual orientation of the device.
Already noticed some layout issues with some of Wikimedia’s fundraising banners in the browser.
Google Reader for android is great… if you’re always online. If you have a subway commute, fly a lot, or otherwise like to catch up on your blogoverse when the rest of the world isn’t talking to your phone, you’ll quickly discover that the app’s offline sync feature is poor enough to be more frustrating than not having it at all.
They seem to have done a lot of things right; starring or marking things read works just fine while offline and queues the server updates transparently for later. And when an article is available offline it fetches it cleanly and quickly.
There are basically three problems:
First, there’s no way to tell what feeds will actually be pre-downloaded. It claims to fetch your “most read feeds” but it gives no indication which those are. After several weeks of use I’m still getting confused by what is or isn’t being fetched.
The second problem is that the list displays do not distinguish between new feed entries *that have been reported to exist by the server* and those that have already been downloaded. You can see a clear count of entries and be faced with a “no network; retry” screen. Worse, if the connection is intermittent it’ll try to connect for a few seconds before telling you there’s nothing to see.
And to add insult to injury, images are not prefetched, consigning subway warriors to a pure-text life devoid of photos, screenshots, charts, icons, diagrams, maps, etc.
I could probably whip something up that does what I want, but polishing it won’t be trivial and I’m sure there are other tools out there that would suit my needs; anybody know a good offline-friendly feed reader of Android, preferably with Google Reader sync or import?