The year of the Linux tablet? [LWN.net]

The year of the Linux tablet?

Posted Aug 24, 2011 15:55 UTC (Wed) by iabervon (subscriber, #722)
In reply to: The year of the Linux tablet? by smoogen
Parent article: The year of the Linux tablet?

Among proprietary systems, none of them have the same interface on desktops and smartphones. It's unclear (to me, anyway) which, if either, tablets really ought to match, and whether the proprietary systems have picked smartphones to match for reasons that don't really apply to an alternative. (If you have different kernels for different processors, you may not want to put in the work to port the desktop kernel to the tablet processor.)

to post comments

The year of the Linux tablet?

Posted Sep 5, 2011 10:59 UTC (Mon) by rlhamil (guest, #6472) [Link] (1 responses)

No, but Apple is clearly moving in the direction of increased uniformity across platforms. OS X 10.7 ("Lion") borrows a lot of interface features from iOS: an App Store, a similar-looking launcher, scroll-bars that auto-hide by default (and by default work "backwards" compared to usual desktop experience, so that touchpad motion corresponds to dragging the content, and the scrollbar indicates in a minimalist way the portion of the content visible in the window), a side-by-side arrangement of workspaces rather than a grid (that latter annoyed a lot of people, since unlike the others, there's no way to revert to the old behavior or ignore it).

There's no question but that Apple has a vision and is willing to sometimes shake things up to follow it. That of course isn't always popular (Final Cut Pro X was different enough, and apparently gave up enough functionality in favor of a new vision of ease-of-use, to garner a lot of mixed-to-negative reviews), but at least it's better than stagnation.

One doesn't need to approve of a license philosophy to learn from both the successes and failures of those that take creative chances, esp. when it's those that for all practical purposes had the first _viable_ tablet, and still the one that others would have to beat, despite the limitations of its locked-down environment.

So...I doubt one could have exactly one interface across devices ranging from a handset to a desktop, without excessive compromises. But one could have a reasonably _similar_ interface, both to the user and as an API, allowing a reasonable amount of user and developer experience to apply across the range.

Take an opposite example: Angry Birds on the Mac looks perhaps too much like the iPhone version, as if they did no more than they had to in the way of adjustments. To me, it's a little harder to use, and seems to crash more easily.

Or take another example: the problems getting Java to really deliver on "write once, run anywhere". Good on the server side (if the developer doesn't neglect efficiency), but a bit problematic on the user-facing side, to put it mildly. Some of the latter could have been better managed, but I wonder if _any_ environment would let a single implementation without platform-specific tweaks work equally well everywhere.

While reasonably consistent interfaces may make it more a matter of adjusting applications to different platforms than truly porting them, some adjustments may always be needed. (think how fonts at low resolutions just about need manual hinting added to look decent; this seems to me a metaphor for how extremes may exceed what any automatic adaptation can handle well) And no less important, _testing_ on each platform will probably not be something that can be dispensed with any sooner.

Any attempt at a cross-platform environment therefore has a balance to achieve to preserve familiarity across devices without creating or encouraging excessive compromises of the end user experience. And that balance may over time allow more uniformity, as interfaces with just the right adaptability and flexibility are developed. An environment that's expected to last for awhile not only needs to hit an acceptable balance for now, but needs to be able to be adjusted over time, as well.

The year of the Linux tablet?

Posted Sep 6, 2011 3:14 UTC (Tue) by tshow (subscriber, #6411) [Link]

I think you're on the nose with this.

Personally, I think Apple has gone too far in attempting to unify their interfaces across devices, at least from the point of view of an advanced user.

As an example, the new auto-hide scrollbars mean you can no longer tell at a glance how much of the document there is or where you are in it. Unless some of the content is actually visibly clipped by the edge of the scrollable area, you have no indication that you're looking at something that scrolls.

The real problem with a unified interface is trying to wedge all the differing capabilities of your device set into a unifying metaphor that doesn't stretch too badly.

I'm coming at the problem from a game development point of view; I do console and mobile phone games, we've developed a cross-platform game engine that (in an OS kind of way) presents a unified programming interface regardless of the underlying hardware.

Or that's the theory, anyways. In practice, there's abstraction breakage, sometimes severely. As an example, consider the situation we faced when the Wii came along; we had a couple of implicit assumptions in the engine design that the Wii violated.

Single Pool of System Memory: The Wii has two banks of system memory, one slow and large, the other fast and smaller.

Many Gamepads, One Mouse/Keyboard: The Wii controllers all have lightgun capabilities, so they can all have screen positions.

Gamepads Don't Change: The Wii controller has dockable subcontrollers.

This kind of thing breaks your abstractions, often badly. You either wind up having to wrap a superset of all possible cases around everything (in which case the game has to understand the platform it's on to access the functional parts), use capability detection (in which case the game has to be modular based on the capabilities reported by the hardware), or find a new abstraction that hides the differences once again.

With our game engine, we have the luxury of retooling our abstractions whenever a new platform arrives; we don't need to have a stable API or ABI because we're effectively our only user.

General purpose operating systems and development ecosystems don't have that luxury. Even if you aggressively deprecate your old mechanisms for new software, you have to keep the old stuff working.

The same is somewhat true for GUIs. You can only change so much out from under your users before they revolt. More to the point, if you change things too much, and your users have to relearn everything, you lose all your "lock in" effect from user experience. If they have to re-learn everything, they may well chose to go learn a different system instead, perhaps one that won't yank the rug out from under them every time the major version number changes...