Topic: Productivity

This post is mostly just an overview of Epistle by Matteo Villa, which is--to my mind--the best Android note taking application ever. By the time you read this I will have an Android Tablet, but it’s still in transit while you read this and that’s a topic that dissevers it’s own post.

Epistle is a simple notes application with two features that sealed the deal:

1. It knows markdown, and by default provides a compiled rich text view of notes before providing a simple notes editing interface. While syntax highlighting would be nice, we’ll take what we can get.

2. It’s a nice, simple application. There’s nothing clever or fancy going on. This simplicity means that the interface is clean and it just edits text.

For those on the other side there’s Paragraft that seems similar. While in my heart of hearts I’m probably still holding out for the tablet equivalent¹ of emacs. In the mean time, I think developing a text editing application that provide a number of paradigmatic text editing features and advances for the touch screen would be an incredibly welcome development.

In the end there’s much work to be done, and the tools are good enough to get started.

I have a question for my system administrator readers. And maybe the rest of you as well.

I run a web server on my laptop that hosts about 8 test sites. Nothing special: mostly test and development sites for various public sites, but from time to time I think, “shit, wouldn’t it be nice if I could just give someone a link to this.” My solution is generally to copy whatever it is that I’m working on up to the server that runs this website, and while that generally work just fine, it could be better.

So here’s what I’m thinking:

I’d like to be able to hook my laptop up to the internet and be able to let people access (some) of the content running on this web server. I don’t want it to be automatic, or open my entire machine to the world (though… I could secure it, I suppose.) The options I’ve considered.

• I set up a VPN that I can connect to the public server (that hosts this website) from the laptop, and I have a virtual host (or set of virtual hosts) that proxy requests to the laptop. Wherever I am, it works. I’m not worried about the bandwidth or the strain on the server given the usage pattern I’m expecting.

  • Pros: Simple, Secure, works even if I’m on a weird local network. Potentially useful for other kinds of nifty hacking including tunneling all traffic through the VPN on insecure connections.
  • Cons: Way complex, and I’m not sure if it will work. I’ll need to set up VPN software. And it’s total overkill.

• Some sort of scripted dynamic DNS solution, probably involving running my own DNS server.

  • Pros: less proxy madness. Pretty simple.
  • Cons: running a DNS server. Won’t work on some (most) local networks.

• There has to be some sort of alternate approach using a minimalist tunneling solution. There are a few of them, I think they’re nifty, and it would probably be perfect. I’m just not sure what it is.

  …and then half the night later, I finished deploying the VPN. I have to say that I’m really pleased with it:

• It can (and has) replaced my ssh tunnels for sending email. That’s pretty great.

• The web server stuff works, though I don’t have anything really up there yet. I feel like I need some sort of access restriction method, but I don’t really like any of the options. HTTP Auth is annoying rather than protective, SSL is terribly imperfect and fussy, host based control isn’t very tight.

• I think I will be able to finally sacrifice a laptop to the “homeserver” because aside from dis/re-enabling the “sleep on laptop close” function. If needed it’ll be dead simple to convert a sever laptop to a mobile laptop.

Thoughts?

The ideal writing application is emacs, at least for me. In the absence of emacs (as on a tablet,) I’ve been thinking about what features I actually need in a writing application. While I’ve grown to admire the power of a full Lisp machine in my text editor, I accept that it’s not, strictly speaking required. Here’s a first stab at the list of requirements. Feel free to comment or submit a patch to this page.

• Simple, primarily full screen editing.
• The ability edit very large files, 100kbs should present no issue.
• Some sort of syntax highlight during the editing process, preferably support for LaTeX, Markdown, and org-mode.
• Word count generation for the entire files and for current selections.
• Auto-save as crash protection.
• Undo/Redo last typing action.

Nice to have (but not crucial) features:

• The ability to edit one file and reference another (or potentially edit) at the same time. Bonus points for being able to switch between to parts of a single file at once.
• The ability to hide or collapse some sections of a file.
• Optional spell checking.
• Parenthetical and double-quote matching.
• Soft and hard line/word wrapping.

Other than that I don’t think there’s anything that I really need to have to get writing done 90% of the time. How about you?

I’ve only had the tablet for a few weeks, but I’m pretty sure the tablet incarnation of Android is probably 80% of what most users need in a workstation. I’m not most users, but I figure: hook up a big screen and a real keyboard. Create some key bindings to replace most of the gestures, and write a few pieces of software to handle document production, presentations, and spreadsheets in a slightly more robust manner, and you’re basically there. I wouldn’t give up my laptop today for a tablet, and I think the platforms still have a ways yet to go, but that’s not insurmountable.

Prediction: in the next decade, we’ll see embeded tablet-like devices begin to replace desktops computers for some classes of use and users. General web surfing, reading, quick email, and watching videos on YouTube seem like the obvious niche for now. I started to explore this in “Is Android the Future of Linux,” but it’s not abusrd to suggest that Android or iOS like devices might begin to address more “general purpose desktop computing.”

I want to be clear: we’re not there yet. These systems aren’t versatile and fully featured enough to keep up with full time use on an extended basis. This is mostly an application/software problem. As applications evolve and as more functionality moves to remote systems anyway (this is the “cloud,” we’ve heard so much about,) tablet operating systems will seem much more capable for general purpose work. Better mobile productivity software will help as well. Eventually, I think Android and similar platforms will have a shot at the desktop market for most usage because:

• IT departments will get a lot more control over intra-organization information flow, which could save a lot of money for various IT categories: administration, support, and data protection costs.

• Behind the firewall dropbox-like services, and creating some sort of centralized workstation configuration management (which makes sense for a flash based device,) means backups can happen automatically, and if devices need to be re-imaged or are lost or damaged, it only takes a few minutes to get someone back to work after a technology failure.

• Limited multi-tasking ability will probably increase productivity.

• Disconnecting keyboards from the screen will probably lead to better ergonomic possibilities.

• Eventually, it will be easier to integrate Android-like devices with various workflow management/content management systems.

  The technology needs to mature and workers and IT departments need to become more comfortable with tablets, without question. Also, there are some fundamental developments in the technology that need to transpire before “desktop tablets” happen, including:

• More power user-type interface features.

• Split screen operation. There are enough “common tasks” that require looking at two different pieces of information at the same time that I think tablets will eventually have to give up “full screen everywhere,” operation. Conventional windowing is unnecessary, and I don’t think anyone would go for that, but displaying two different and distinct pieces of information at once is essential.

• Better “Office” software for spreadsheets, presentations and document preparation. A necessary evil.

• Behind the firewall (preferably open source) solutions to replace services like Dropbox/Box.net and whatever other services emerge as essential parts of the “tablet/smartphone” stack.

• VPN clients and shared file system clients that are de ad simple to use. I think these are features for operating system vendors to develop.

Thoughts? Onward and upward!

This post is adapted from a post I made to the org-mode email list a few weeks ago. I proposed an application to compliment MobileOrg for writing. Where MobileOrg collects the core bits of org-mode’s task planning functionality in a form that makes sense for smart phone users, the parts of org-mode functionality that people use to for writing and organizing the content of larger form projects isn’t particularly accessible.

I spend (or should spend) 70% or more of my time in front of a computer writing or editing something in org-mode. Most of my org files have tens of thousands of words of blog posts, notes, drafts of articles, and so forth. While I can store that data on an android device with only minor problems using a little script that I put together, and I can capture content into my org-files using email and some nifty filters, and there are text editors that can let me edit these files: it could be better.

The proposal is simple. Can we build something like Epistle for org-mode? It might just render org-mode text to HTML, and frankly that would be enough for me. If the editing interface had an org-indent-mode equivalent, org-syntax highlighting, and even collapsing trees or org-narrow-to-subtree, that’d be kind of like heaven.

I’m not a mobile developer, so I can’t promise to start making an app this instant if there’s interest but if anyone’s bored and thinks this might be a good idea (or knows of something that might work better for this.) I’d love to hear about it. If someone wants to start work on this, I’ll do whatever I can to help make this a reality.

Onward and Upward!

I’ve been using FBReaderJ to read .epub files on my tablet recently, and I discovered a nitfty feature: you can adjust the screen’s brightness by dragging your finger up or down the left side of the screen. Immediately this felt like discovering a new keybinding or a new function in emacs that I’d been wishing for a while time. Why, I thought, aren’t there more tricks like this?

The iPhone (and the iPad by extension) as well as Android make two major advances over previous iterations of mobile technology. First, they’re robust enough to run “real” programs written in conventional programming environment. Better development tools make for better applications and more eager developers (which also makes for better applications.) Second, the interfaces are designed to be used with fingers rather than stylus (thanks to capacitive touch screens) and the design aesthetic generally reflects minimalist values and simplicity. The mobile applications of today’s app stores would not work if they were visually complex and had multi-tiered menus, and hard to activate buttons.

The tension between these two features in these platforms makes it difficult to slip nifty features into applications. Furthermore, th economy of application market places does not create incentives for developers to build tools with enduring functionality. The .epub reader I mentioned above is actually free software.¹ I write a couple of posts a while back on innovation (one and two) that address the relationship between free software and technological development but that’s beside the point.

Given this, there are two major directions that I see tablet interfaces moving toward:

1. Tablet interfaces will slowly begin to acquire a more complete gestural shorthand and cross-app vocabulary that will allow us to become more effective users of this technology. Things like Sywpe are part of this, but I think there are more.

2. There will be general purpose systems for tablets that partially or wholly expect a keyboard, and then some sort of key-command system will emerge. This follows from my thoughts in the “Is Android the Future of Linux?” post.

I fully expect that both lines of development can expand in parallel.

I read something recently that suggested that the health of an open source project and its community could be largely assessed by reviewing the status of the bug tracker. I’m still trying to track down the citation for this remark. This basically says that vital active projects have regularly updated bugs that are clearly described and that bugs be easy to search and easy to submit.

I’m not sure that free software communities and projects can be so easily assessed or that conventional project management practices are the only meaningful way to judge a project’s health. While we’re at it, I don’t know that it’s terribly useful to focus too much attention or importance on project management. Having said that, the emergence of organizational structure is incredibly fascinating, and could probably tolerate more investigation.

As a starting point, I’d like to offer two conjectures:

• First, that transparent issue tracking is a reasonably effective means of “customer service,” or user support. If the bug tracking contains answers to questions that people encounter during use, and provide a way to resolve issues with the software that’s productive and helps with support self-service. Obviously some users and groups of users are better at this than others.
• Second, issue tracking is perhaps the best way to do bottom-up project/product management and planning in the open, particularly since these kinds or projects lack formal procedures and designated roles to do this kind of organizational work.

While the overriding goal of personal task management is to break things into the smallest manageable work units, the overriding goal of issue tracking systems is to track the most intellectually discrete issues within a single project through the development process. Thus, issue tracking systems have requirements that are either much less important in personal systems or actively counter-intuitive for other uses. They are:

• Task assignment, so that specific issues can be assigned different team members. Ideally this gets a specific developer can “own” a specific portion of the project and actually be able to work and coordinate efforts on the project.
• Task prioritization, so that less important or crucial issues get attention before “nice to have,” items are addressed.
• Issue comments and additional attached information, to track progress and support information sharing among teams, particularly over long periods of time with asynchronous elements.

While it’s nice to be able to integrate tasks and notes (this is really the core of org-mode’s strength) issue tracking systems need to be able to accommodate error output and discussion from a team on the best solution, as well as discussion about the ideal solution.

The truth is that a lot of projects don’t do a very good job of using issue tracking systems, despite how necessary and important bug trackers. The prefabricated systems can be frustrating and difficult to use, and most of the minimalist systems¹ are hard to use in groups.² The first person to write a fully featured, lightweight, and easy to use issue tracking system will be incredibly successful. Feel free to submit a patch to this post, if you’re aware of a viable systems along these lines.

Ok, I caved and got a tablet. This is a post about my experiences with the tablet and some general thoughts on the format.

I opted for the Motorola Xoom. It’s an Android device, I appreciate the Motarola build quality, and I’m very pleased with my choice. First impressions first:

• Reading on the tablet is great. I have a Kindle, and while I respect how lightweight the Kindle is itself. Despite the extra weight, the slightly larger screen and the back light is very very nice and very welcome.
• I don’t expect that I’ll be doing a lot of writing on the tablet, a laptop is never really going to be that far away, but I’m really surprised by how easy it is to (almost) touch type on the tablet. A number of very simple and probably straightforward innovations to the keyboard could make things so much better.
• I think all devices need some sort of “don’t auto rotate” hardware switch. In fact, I think apple’s whole “lets get rid of hardware buttons,” movement to be really annoying. Buttons should be overloaded, sure, but I hate having to hunt through menus to modify basic behavior. Having said that, the “software control bar” at the bottom of Android 3.0 is brilliant and a good move (given screen rotation.)
• I lament not having a Google voice widget for the tablet. Makes sense that they wouldn’t want this for tablets that had data plans, but I just have a wifi tablet.
• The Kindle app doesn’t let you bookmark your place in periodicals. Which might make sense if you were reading the Times, but doesn’t make a lot of sense when reading fiction magazines with articles in the rage of 10k words.
• I’m in love with the calendar application, except for the “full month view,” in which you scroll by weeks, not by months. Even with this glitch, I’m curious as to why there aren’t (stand alone) calendar applications of this quality for desktops.
• I’ve tended to use the tablet for situations where I want to have a distraction free experience (usually for reading,) or where I want to do “computer things” in a situation where I might need to interact with other people. Having a tablet in your lap is more social than a laptop. As such, I don’t think it would ever be able to replace a “real” computer for very long, but that doesn’t make it less useful.

I’ll be writing more about the tablet experience and some cyborg features of tablet use and usability.

Onward and Upward!

This post is a continuation of my human solution to IT and IT policy issues series. This post discusses a couple of ideas about “enterprise” software, and its importance the kind of overall analysis of technology that this posts (and others on this site) engage in. In many ways this is a different angle on some of the same questions addressed in my “Caring about Java” post: boring technologies are important, if not outright interesting.

There are two likely truths about software that make sense upon reflection, but are a bit weird when you think about it:

1. The majority of software is used by a small minority of users. This includes software that’s written for and used by other software developers, infrastructure, and the applications which are written for “internal use.” This includes various database, CRM, administrative tools, and other portals and tools that enterprise uses.
2. Beautiful and intuitive interfaces are only worth constructing if your software has a large prospective userbase or if you’re writing software where a couple of competing products share a set of common features. Otherwise there’s no real point to designing a really swanky user interface.

I’m pretty sure that these theories hold up pretty well, and are reasonably logical. The following conclusions are, I think, particularly interesting:

• People, even non-technical users, adjust to really horrible user interfaces that are non-intuitive all the time.

• We think that graphical user interfaces are required for technological intelligibility, while the people who design software use GUIs as minimally as possible, and for the vast majority of software the user interface is the weakest point.

  The obvious questions then, is: why don’t we trust non-technical users with command lines? Thoughts?

I was paging through a list of things that I made for myself during a call I was in a few weeks ago, and was utterly dismayed by how useless the items were on the list. I wasn’t sure what needed to be done, I couldn’t remember what things meant, and I was left with the sinking suspicion that I had forgotten something crucial. I write this, in part, as a lesson to my past self on how to write good task list items.

Hopefully you’ll find it useful.

Task items must be actionable. You need to be able to read the subject or summary and know: what the project is, what kind of work it is, what needs to be done, and what very next thing you need to do is.

Tasks cannot be open ended. It’s really tempting to write tasks in the form of “work on a project” or “make progress on email backlog,” but don’t. How do you know if you’ve done the task? Is all progress the same? Is the actual work activity plainly obvious from an open ended task description?

Tasks need to concise. I’m a big fan of including some sort of status information and some sort of instruction and context with your tasks, but you need to be able to look at a task list and triage what to do next without thinking very much and without spending more than a few seconds deciphering messages from your past self. Write good summaries.

Try to organize your projects and tasks so that most of your task items are not dependent upon other items. Sometime dependencies are unavoidable, but I find if you’re clever, you can chop things up into parallel tasks that are easier to work on but that accomplish the same goal. In some cases, long strings of dependent tasks can be just as troublesome as large open tasks, because in the moment they amount to clutter.

Also your feedback and suggestions from your own experience may be of interest to all of us! I look forward to hearing from you!