zlacker

>>iBelie+(OP)
My primary concern with this is that different applications are inherently optimized for the platform on which they were originally designed. There are some applications that have a very dense UI because there's simply alot of functionality that the program handles (think of a video editor, an IDE, etc). Trying to slim down those applications to make them reactive so that they will scale onto a phone or tablet just seems silly, and I fear that in the name of making "everything work everywhere", we're going to compromise a bunch of apps that worked beautifully on one platform in favor of making them work adequately on several platforms.

I mean, if someone said, "I've successfully ported Vim to Android!", my first thought would be, "Why in god's name would I want to run vim on my phone?"*

* Ruling out, of course, someone plugging their phone into external KVM.

>>Admira+K7
Some folks, myself included, reel at the conventional wisdom that a small screen necessarily means reduced functionality.

While I agree that it can be difficult to design information-dense UIs for small displays or provide navigability to a large feature set, I strongly applaud efforts to unify computing and work through these challenges.

I very much want all of my computing devices to be unified. In fact, I want a model where I have one computing device and multiple views ("terminals" if you wish) [1]. But a consistent experience as Purism is pitching, and which Microsoft attempted with Windows 8 + Windows Phone 8, are viable first steps. There is learning to do here and it's great to see people taking on the challenge.

> I mean, if someone said, "I've successfully ported Vim to Android!", my first thought would be, "Why in god's name would I want to run vim on my phone?"

Sure, but if they find it useful, fun, or just plain cool, I applaud it. I want more desktop-class computing capabilities on my phone-sized device and I routinely find myself deferring important actions until I can get in front of a "real computer." Many things are just too challenging or limited on today's mobile operating systems. Even with "convergence," as Purism calls it, there will still be cases where I simply want to use a larger screen, so I'll defer until I can dock the device and use some large form-factor I/O devices. But with the stance Purism is taking, I would no longer experience the frustration of software limiting me even when I am willing to endure the limitations of my hardware.

[1] http://tiamat.tsotech.com/pao

>>bhauer+Om
To me the biggest hinderance is no the small screen, but the touch UI. Think of something simple like text editing. Because the UI has to differentiate simple taps and everything else, there is an inbuilt delay between the simple tap, and the more functional tap-and-hold. But since there is only one tap and hold, then it becomes tap-and-hold-and-select-action-from-menu-then-complete-action. Thats how I think of the simple action of selecting some text. Something the keyboard or mouse both accomplish much faster.

I don't use my phone for much of anything but calling and bored web browsing anymore, but I'd genuinely love for my iPad to be more functionally useful, but the issue above is similar to a lot of other interaction limitations. I really can't imagine using any mobile app on my desktop, and I can't imagine using any of my desktop apps on mobile (admittedly the desktop apps I use are on the more complex side things.)

>>abruzz+5p
Indeed, tap-and-hold is an inefficient gesture on touch-powered devices. Swipes and taps are much more convenient. (In fact, I don't even think that the gesture is used for anything on touchpads, even though it could be. Even for drag and drop, you activate it by "double-tapping" and then swiping away, not letting the double-click register. In general, UI-interaction on touchpads is quite advanced, and proves just how much ground there is to cover on mobile.)

The biggest obstacle to a genuinely productive UI on mobile, I find, is the lack of pervasive and easy confirmation and error-recovery for potentially-unwanted inputs. System management interfaces (e.g. community-built "recovery/modding" environments) get this right (everything that's potentially unwanted gets a "perform a swipe to confirm input" prompt), but almost nothing else does.