Mobile Productivity Discussion
This post has inspired an ongoing conversations with alaric that I've moved to "cyborg/interoperability." We'll continue that conversation there. --tychoish
jfm and tychoish
I personally don't find context-switching to be a big problem on my Android tablet. What I find most limiting is the limited input bandwidth. But that's not a scheduling or task management problem; it's a platform problem. I've been following what you've been writing on task management and on mobile usage, but I'm still somehow not understanding exactly what exactly the problem you've identified with planning mobile work is. Is there another way you could approach the problem to explain it?
-- jfm
So, I think the input bandwidth problem is really a different side of the same coin. The core problem is in having a block of time and a piece of device that does somethings better than other things and not being able to plan for that time effectively. In the post I said:
The task list that we build for ourselves when we're doing "conventional" work (i.e. things that we need to remember to do, open projects, open issues,) aren't particularly useful or usable when we're looking at a tablet or a phone. If we don't know what we ought to be doing, it doesn't matter what the device or software is capable of in theory.
It's true that someone could probably design input methods that were more effective than onscreen keyboards. I think swype is a good start for phones, and we need something like that for tablets. I'm personally convinced that some sort of device that lets hold the tablet with your fingers on back (in the "intuitive" way to hold a tablet) and then type that way, is the way, but we'll see.
In the mean time, the problem is figuring out what you can do at 60% (or whatever) of your optimum input speed, and then forward all of those things to yourself for "tablet time." And in parallel, be able to forward yourself "laptop time" tasks when you're using the tablet.
Context switching costs is the manifestation of the "different tasks need doing at different time with different devices," problem; Input is how this problem seems to manifest for you.
At least, that's how I'm reading this.
Hope this helps.
-- tychoish
tc and tychoish
I'm no digital native/road warrior, but a recent laptop-free, nine-day trip left me to conclude that I use online resources in ways that often flop between consumption and creation (view a post, then choose to comment on it).
Simply put, the context switch that stymies me isn't between tasks, but between passive and creative modes.
And it's the creation bit that mobile (so far) kinda sucks at.
Perhaps there's finally a role for that voice-to-character technology that is always just about to obsolete the keyboard and mouse, but mobile -- even our expensive, fragile iPad -- fares pretty poorly when you're trying to do anything more expansive than flip pages or cough up a short reply to an email.
The idea of parsing tasks based on the device being used is interesting; I'd gather you envision a cloud-based app that organizes based on due date or GTD or whatever -- and the device being used to access it?
Interesting, but -- given my admittedly personal (and anecdotal) "flop between consumption and creation" reality, it probably sounds better than it is.
Of course, I have to ask the question of the moment; is attempting to make "productive" use of time spent waiting in lines really productive at all? The mind needs some respite to simply think, and the kind of lazy surfing I might accomplish in line at the grocery store seems only marginally more useful than perusing the scandal sheet headlines...
I found Nicholas Carr's excellent book (The Shallows) about the Internet's apparent affects on our attention spans worth a little examination. We're not machines, and I view the erosion of the barrier between work/personal life when corporations started sending laptops home as a worrisome example.
And besides, I can't seem to run Emacs on my phone (though I'm sure someone has), so why bother?
--TC/Writer Underground
I've been playing with the "thumb keyboard," for the android tablets, and I think there's potential there. I'm convinced that there's a tablet input interface that isn't an on screen keyboard and is consistent with the idiom. For instance, the Motorola Backflip (an android phone) had a touch receptor behind the screen, which was a great idea on an otherwise lackluster phone.
Input problems have always been, and remain a constant challenge in mobile computing. You can always add keyboards, but given the state of laptops these days, I think tablets need to figure out a way to do input without forcing them to compete with laptops (i.e. adding a hardware keyboard, removes the size/fuss benefit of a tablet, and makes the tablet a sort of under-featured laptop.) I think this is trending in the right direction so maybe in 5 years or less?
As for emacs. I've had some conversation with madalu on the topic, I think it's a nice idea, and the instant that it's even tangentially usable, I'm there. Having said that I think there are two major realities that affect emacs use in the mobile context:
Emacs needs to have more mobile-friendly interface. My emacs windows are white with a mode-line and a mini-buffer. That's it. While I adore this minimalism, it's more efficient to have command or command fragments as buttons in mobile interfaces. Emacs has some widget support, and that's great, but emacs and us lisp-hackers need to figure out how to write these kinds of interfaces.
In most cases we don't need full-emacs in a mobile text editing interface. It might turn out that the easiest way to get good text-editing usability and functionality on a tablet is get a working emacs-port running. Having said that, I think the parts of emacs I need on a tablet is significantly smaller than a full lisp machine, and 60-80 megs of lisp code.
We'll see though.
-- tychoish