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!

I want to put together a series of posts about cyborg perspectives on industrial IT practices. This post introduces that series.

The “cyborg analysis,” makes difficult to ignore that most problems with technology, even seemingly outright “technological problems” are better as understood as problems at the intersection of humans and technology. Ignoring either people or technology, leads to imperfect analysis. While, false divides between “problems with users,” and “problems with technology” aren’t helpful either, this might be a conceptually useful exercise.

I’ve been thinking that many of the seemingly technological problems of IT policy are really not technological problems at all, and are better thought of as “people problems.” I’m thinking of “problems” like file permissions, access control, group and user management, desktop management, and data organization. Obviously, some problems, like workflow and tool optimization, are seen human problems while others are often targeted as technological problems.

I think of human solutions as those responses to technology issues that address misunderstanding by providing training and education to users. There’s also a class of automations that make these human solutions easier to provide: for example, test harnesses of various sorts, code/text validation, and some template systems. Technological solutions, by contrast are those that, through the use of code, enforce best practices and business objectives: web filters, access management systems, and anything that are designed to “break” if business policy are not satisfied.

The divides between solutions are not natural or clear, just as problem domains in IT are rarely neatly or easily “silo’d.” There is often a fine line between writing code to automate a process to make users' work easier and writing code to control users and save users from themselves.

This post, and the series that follows it, are thus to explore this tension, and what I suspect are under-realized opportunities for human-solutions. I would like to think that problem domains in the larger IT world, particularly with thorny issues that require lots of code, may be better addressed with more human-centric solutions. Current thoughts revolve around:

• The practice and method of software design.
• The development and use of software developed for “internal use,” rather than as a software product.
• Refraining the discussion about digital security to address it from a human angle rather than from a purely technological angle.

As always, I’d like to invite comments and discussion.

I’ve never really figured out how to do work with anything less than a full computer. I’ve tried everything: Palm Pilots and Pocket PCs in the early 2000s, laptops, and eventually I just settled on just dragging a (smaller) laptop almost everywhere circa 2005. I get the feeling that, most people who have been thinking about mobile technology and productivity assume that the only impediments to mobile productivity are better hardware and software. Contemporary (multi)touch screen devices are the current embodiment of this theory.

I’m convinced that the theory is wrong.

Having better and more powerful technology doesn’t hurt anything. I’m a huge fan of the smaller, integrated, and more powerful devices. Software written specifically with mobile users in mind does improve the potential for productivity. These technological improvements, however, make the underlying problem more apparent.

The challenge of getting things done when mobile has little to do with the capabilities of the mobile platform, and more with the way people think about and plan work when mobile. Not only is this hugely frustrating to users, but technological capability that people can’t use threatens the ongoing development and adoption of new technology.

Using Mobile Technology More Effectively

The solution, here, I think is two-fold:

Fully Integrated Applications

Let’s develop integrated applications, not just integrated devices with different applications. Just as we didn’t need separate devices for every mobile function: telephony, music playing, book reading, mobile internet, and so forth. We don’t need different applications for every function: calendaring, messaging, email, contact management, notes, reading, and so forth.

At the very least applications need to be highly interoperable, so that users can send data between application functions easily, and synchronize data back to desktop and web portals seamlessly.

Task Planning Strategies for Mobile Productivity

I don’t think that the “user stories” for mobile technology are really fully developed, and as a result any interaction with a mobile device that isn’t responsive (i.e. there’s an alert of a new event, and people respond to it,) is either “twiddling nobs” (i.e. non productive,) or entertainment focused (i.e. playing music, video, or opening a book.) Perhaps that’s enough for some uses, but these this kind of workflow covers a small percentage of what people do with computers.

If mobile technology is going to replace a general purpose laptop, ever, even in limited situations, we need to figure out how to work in different ways. I know that I am loosing a great deal of time, when I’m using my phone switching between the notes app, the reader, the task list, and the calender. This task switching gets in the way of doing things to a much larger extent than similar behavior does when using a conventional computer. I would even posit that, the cost of context switching is inversely related to the size of the interface.

Better application integration will help this, but I think the real solution is providing a method for people to organize their mobile time more effectively. 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.

There are probably a dozen or more solutions to this problem, but here’s my first stab at it. What if there was a way to “forward tasks” to ourselves when we’re on the run, but have a few moments? We all loose time waiting in queues, or waiting for trains, and these seem like ideal phone times. If we had a way to queue things for ourselves, so we could spend the time doing something. Even better, would be software that would not only collect and display the queue but would also connect with the application where whatever needed to be done was and then record the results and send the back to our desktops when we were done.

Thoughts?

While this week flew by in many respects and I only got a couple of posts out, there is much change and progress afoot. This post is an attempt to catalog some of the work I (and others) have been doing that hasn’t made it onto the blog:

• Discussion of the “Better Task List” post by jfm`. Including spoilers for posts that I hope to have ready next week.

• Further discussion of the make emacs better post. I’m thinking that it’s probably nearly time to split that into a few pages. There’s a lot of great content there and people have added a lot. I’m a huge fan.

• Not a link, except to say that I did some fairly substantial tweaks of the site’s design, which is probably only worth mentioning because I suspect most people read the site on RSS. Different fonts in the headers, and I rearranged the masthead to be a little more clean, and changed the links a bit.

• I’m in the slow process of cleaning up the Cyborg Institute site which I’ve neglected for far too long. I’m importing a lot of the content that I wrote over there, notably sygn and tubmle-manager. Next up, some straggling blog posts, and a clean up of the existing content to match my current projects and work.

• The knitting posts, which is collected separately from rhizome posts is in full swing, and I hope to be able to post a few things there every now and then.

• There’s now a real tag index and a tag cloud that looks like something. I’d avoided putting together a page like this for some time, because there were a lot of junk tags and enough really big tags that the cloud didn’t really work. I’ve mostly cleaned that up, leaving the wiki with a rather awesome tag cloud

  I’ve also found a few things on the web that I think you might enjoy on the web:

• A new blog called observatory. I’ve been talking to the author a bit. I realized that there aren’t very many blogs that are so verbose. I suppose ByteBaker is another example, but there aren’t many of them around.

• undo-tree-mode is a nifty little emacs hack that makes undoing and redoing much less complicated and weird. (From that make emacs better discussion.) Though I have to admit that I no longer have a problem with the default behavior, even if I know it’s a bit counter intuitive.

• I’ve been reading Strange Horizons more than I have in the past, thanks mostly to instapaer and InstaFetch for Android. I was particularly found of Genevieve Valentine’s column/review of a glorious mess of a movie trope.

That’s all I have for this week.

Comments Undo-tree also allows for undoing based on time (see here), apparently a feature that vim has.

I’ve mentioned a few times that I’ve been doing more knitting recently. Nothing for the most part to get excited about. But, now that I have a bit more free time its became apparent that I can’t write all the time and it’s good to have something to do with my hands when other things require a bit of extra attention.

An explanation of my current knitting requires a bit of a back story. There always is and I think that is part of the joy.

The last sweater I started during college is probably the best one I’ve ever made. This isn’t to say that it’s the most impressive, or that it took me the longest, or was the most complicated, or was the most striking, or the had simplest pattern. No. If I had a dozen of this sweater, I’d wear them constantly all winter. It’s warm without being unbearably warm except during the coldest week of the year. The sleeves are big enough to support layering without weird bunching. The sweater fits me without being too tight or too baggy. It looks great over long sleeve t-shirts and oxfords. And it was a lot of fun to knit, both because of the yarn (Harrisvile Shetland,) and the pattern (a modified snowflake design of Swedish inspiration.)

A lot of the sweaters I knit after that were too complicated: I was trying to show off my knitting prowess, or I was experimenting with different yarns. In any case, I’ve come to the following conclusion:

• Two color stranded patterns are the best kind of pattern. The pattern affects the shape of the knitting stitches (in a good way!) and the drape of the eventual fabric, in a way that provides a bit more structure. If you make the right design decisions for the pattern itself, the act of knitting becomes so much more captivating and rhythmic.
• The best neck lines are basically crew necks, but are open to mid-chest like polo or henley shirts. I don’t tend to put button holes or clasps and just leave them open. The effect on the sweaters is that they are wearable over any kind of shirt (unlike v-neck sweaters) and are well ventilated (unlike unmodified crew neck sweaters.) I tend to leave the front corners of the collar squared and unmodified, but they can be rounded.
• I’ve gone back and forth on this a bit, but now, I’m firmly of the opinion that turned hems are better on stranded garments than corrugated ribbing. Knit a hem facing, purl two rounds, and then start the pattern, and join the hem at the appropriate moment. Done. Corrugated ribbing is really appealing, but it’s not really ribbing, and it’s very loud, on finished garments.
• After much experimentation with different shapes, I’ve decided that plain old drop-shouldered fisherman-style shaped sweaters are the only way to go. I’ve gotten pretty good at making saddle shoulders, set in sleeves, modified drop shoulders, and pretty much anything else. But at the end of the day I have a chest of funny looking shoulders that I don’t really wear.
• Patterns need to draw the eyes up along vertical lines, which is incredibly flattering on most people’s bodies and is more fun to knit because panels of pattern can interact in cool ways up and down and across the sweater.I’ve been in a Swedish/Scandinavian kick for a while now, and have been working on variations on a ~26 row snowflake pattern.
• Shetland yarn is really the best yarn in the world. It’s robust without being too itchy, and it doesn’t pill. I like Harrisvile’s selection because you can buy the yarn on cones, it’s consistent, and I think they have enough colors.

So I’m making more sweaters like this.

Just about everyone keeps a task list of some sort, or has at some point. To the casual observer, task list management might seems like a simple problem that could be augmented with a little bit of automation for great effect. Fire up your nearest “app store” and I would bet money that you’ll find a at least a few developers that have had the same thought.

For such a seemingly simple engineering problem there is an inordinate amount of really bad software. While this might tempt us to reassess the complexity of the task management problem, I don’t think this is really true. What happens, I’m convinced, is that people (i.e. cyborgs) make lists of tasks to solve different problems in their realities, and these different lists often require different automation. So while there are 10-20 basic task management applications, the number of distinct usage profiles exceeds that by several times. That’s the theory at any rate.

Archetypes

Allowing for large amount of diversity, there are still a few generally useful task list “archetypes” that we can use to characterize how people use task lists. I just want to enumerate them, here for now. I might move them out to another page, and you should feel free to edit the page (it’s a wiki!) if you think I’ve missed anything!

• Collaboration Facilitation: Teams need systems to keep track of and work on shared issue queues. These are “bug trackers,” and are totally essential when items or “issues:” take a significant time to complete, require the effort/input/awareness of multiple people, and need to be created or added by a number of people.
• Memory Enhancement: People create todo lists when they’re working more things than they can comfortably remember at any one time. The lists tend to be ephemeral, the items can be quickly resolved, but we make these lists so we don’t have to remember a long list of things while working. Think post-it notes.
• Obligation Management: These lists bring us close to calendars, but we keep them to make sure we remember to do required tasks. Often these lists are helpful in helping people make sure that they’re “caught up,” so that they can enjoy and use free time without interruption or nagging.
• Task Prioritization: When time is limited, a list of tasks is useful in organizing an order, and making use of available time, so that it’s possible to keep track of all open tasks, while also being able to allocate effort and time to tasks in a smart way that accounts for available time, importance, and deadlines. The goal is to get the most crucial things done while also never wondering what one could be doing with a few free moments.
• Progress Tracking: These lists are less to track things todo and more to track have done. When working on a number of long term and short term projects, a list of what’s open, what’s been finished, along with a status of where things are is useful to avoid loosing track of projects and tasks.

Based on this, I think we can distill a number of overriding qualities of task lists from these five archetypal use cases. That working list is:

• item granularity,
• project-level organization,
• scheduling and deadlines, and
• use of priority markers. ## Personal Case Studies

When I had an epic commute my issue was that while I had free time, it was all in 20 or 40 minute segments on trains. The challenge was to be organized and focused enough to really use this time. It was early and while I was awake enough to get work done, I wasn’t always awake enough to figure out what needed my attention. And I didn’t have enough routine minutia or enough other free time to be able to spend these blocks of time doing minutia. I needed a task list that told me what to do and when to do it. I needed Task prioritization with a little obligation management or something close to that. I chopped every task into the smallest actionable items, which is annoying in creative projects and often not very useful, and then scheduled items out so that I could do 6 or so things a day, and anytime I opened the laptop there was a list of things I could jump into. It worked, more or less.

Now, I have free time. I even have a few hours strung together. The issue is less that I need help filling in every little moment with something to do, and more that I have too much that I could be working on, and I need help figuring out what the status is of ongoing projects are and where I ought to things are and what needs my attention the most. Progress tracking, more or less with a little task prioritization but in a very different way than I’d been doing. it. I’ve got a lot of things, and I need to be able to see where projects, and what needs attention now. I’ve not figured out the best solution, but I think less scheduling and bigger conceptual task objects is more the way to go.

Does this way of thinking about things make sense to other people?

Philadelphia is replacing, or at least promising to replace, the trains that run the commuter rail system. The new trains are 35-40 years newer than the usual fair, and are replete with “new technologies,” one of which is an automated (I believe GPS-based) announcement system, which figures out what station is next, and which line you’re on. This is great in theory, but there’s a problem.

This system gives you too much information. Trains in Philly are named by their terminus, and all trains converge (and pass through) downtown. There’s history here which makes things a bit easier to understand if you’re a transit geek, but after every stop--including outlying stops--the train tells you what line you’re on, and which stops it makes or skips. The problems:

• At most outlying stations, you can tell by the station you’re at, which line you’re on. It’s sometimes useful to know where the train you’re on is headed, but the trains only tell you that on the outside of the train, until you get downtown, when the announcements change from “where you’ve been,” to “where you’re going.”
• The “this is the train you’re on,” announcements don’t change as you pass stops, so you hear where the train’s been at every stop after even you passed the relevant stops. The announcements make sense, as there are 5 or six “main line” stops that some trains stop on, and others don’t, so as you’re heading towards doubtful stops, it’s useful information, when you’re passed them: less so.
• All announcements are displayed on screens in written form and read by a speech synthesizer. I understand the accessibility concerns, but there are still conductors and I’m not sure that the information is presented in a way that is usable by people who don’t already have a significant understanding of the transit system.

Given this background, as a technical writer, and someone who geeks out on information presentation, I felt that there are a number of things that can be learned from this case:

• More information is sometimes confusing, and can make concepts harder to grasp.
• Figuring out what people need to know in any given situation is more important (and more difficult) than figuring out what is true or correct.
• Sometimes multi-modal presentation may not actually add value in proportion with the amount of annoyance it generates.
• Presentation matters. The speech synthesizer does not sound very good and it’s inefficient.

I think the difference between writing technical documentation and knitting patterns is not terribly significant, and I’ve been known to talk at some length about this connection. While I’ve always been technically inclined, I started writing documentation after learning how to write knitting patterns. In the end, the things you have to know and do to write clear instructions is less about knowing about the technical underpinning, more about the mechanics of writing clear instructions and understanding process abstractly.

Shortly after I started my first technical writing job, I realized that all of the things I was learning about writing documentation was applicable to knitting patterns. In retrospect this makes a lot of sense to me: My interest in knitting is the process, not the design. At about this time, I came to terms with the fact that I liked to design boring knitting. Sweaters with plain shapes and fairly repetitive designs, look great and have a lot of appeal but I tend to make the same basic sweater with only minor variations, if any.

So I started writing what I hoped would be a series of essays about designs and sweaters that I’d knit. My hope was to get a collection of these pieces written and put together as a book, and I made some headway in this project I never finished one of these essays. I was writing essays that a knitter could read and be able to knit a sweater that looks like the one I knit, but also just enjoy the story and a collection anecdotes. Then, as life, singing, dancing, and writing got in my way knitting slowed and changed, and I was working on other writing projects, and for a thousand reasons it became a languished project.

And then my world calmed down, I started knitting again, and after beginning a new sweater (or two,) and I thought: it might be worth putting a little more time into the project. Which brings us mostly to the present.

The second piece of this is that, as a reader of knitting content (books, blogs, etc.) I’m most interested in learning about design decisions, creative inspirations, and how people’s knitting parallels and reflects life beyond the needles. When I look at a sweater I’ve made, I can instantly remember where I was when I was knitting it, and why I decided to attach the sleeve just so. The great thing about these stories is that unlike shelf space for finished sweaters, or potentially garish designs, they are endless and endlessly useful: as inspiration, as comfort, and sometimes just plain comedy.

I’ve not written about knitting on this site for quite a while, and I think that knitting is one of those subjects that might be better served by a little bit of segregation from my more regular fare. So this post is the first in a new knitting series that I’ve put together. Posts will still show up in the main index

I won’t be posting full descriptions of sweaters, I want to experiment with this writing apart from the blog and publication cycle for a while, but I think it’ll be nice to post notes on progress or on interesting little parts of sweaters. If nothing else a little blogging ought to make it easier for me to stay on track with knitting for the project.

Onward and Upward