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

Though short, this week has been pretty good. I’ve been doing cool things at work, I’ve been writing and posting blog entries, and fiction(!), I’m on top of email, and the sweater is growing. I hope this isn’t just a fluke and that I can keep this up and also expand slightly into doing a bit more reading. Small steps.

I’ve done a little bit of work on the wiki and site. Notably, selected entries are mirrored on Planet Emacsen. Also consider the following links to updates on the wiki and other sites:

• Discussion of “/posts/make-emacs-better”, which has been incredibly productive and an interesting discussion of emacs adoption and use by non-programmer niches. I think this discussion and the original post connect pretty well with a post that made the rounds a few weeks ago: Lets Just Use Emacs
• A link from my father on the history of computing. I replied to him with Code Quarterly Interview with Hal Abelson.
• I’ve also collected a few LaTeX System links, of related projects, ideas and collaborators. I’ve also had a few conversations that I need to transcribe into the wiki. Watch this space.
• Then there’s emacs-instapaper, which isn’t exactly a FaiF web service, but the functionality is great for the subway, and I like being able to keep Firefox closed more of the time.

That’s all for now!

Being a critic is not simply looking for the points of failure, shortcomings, and breaking points in cultural artifacts (e.g. music, art, literature, software, technology, and so forth.) Criticism is a practice of comparison and rich analysis and a way of understanding cultural production. One might even call criticism a methodology, though “methodologizing” criticism does not give us anything particularly useful, nor does it make any practices or skills more concrete.

Criticism is really the only way that we can understand culture and cultural products. In short, criticism renders culture meaningful.

I wrote the above in response to this “On Being a Critic” post that a long time reader of this site wrote a while ago. Most of the differences between our approaches to criticism derives from technical versus non-technical understandings of critical practice. With that in mind, and in an effort to consolidate some thoughts about methodology, criticism, and theoretical practice, I’d like to provide two theses that define good critical practice, and provide some starting points for “getting it right:”

• Criticism is comparative. If you analyze a single thing in isolation, this analysis is not criticism. By contrast, one of the best ways to make poor criticism more powerful is to include more information (data) to strengthen the comparison. Comparison should highlight or help explain the phenomena or objects you are critiquing, but should always serve agenda and goals of the criticism to avoid overloading readers with too much information.
• Criticism ought to have its own agenda. It is impossible to avoid bias entirely, and from this impossibility springs criticism’s greatest strength: the power to productively examine and contribute to cultural discourses. While critical essays are perhaps the most identifiable form of criticism, there are others: novels, lectures, films, art, and perhaps even technology itself, can all be (and often are) critical practices in themselves.

Everything else is up for grabs.

I’ve been milling over this post about big data in the IT world for quite a while. It basically says that given large (and growing) data sets, companies that didn’t previously need data researchers suddenly need people to help them use “big data.” Everyone company is a data company. In effect we have an ironic counter example to the effect of automation on the need for labor.

These would be “data managers” have their work cut out for them. Data has value, sure, but unlike software which has value as long as someone knows how to use it,¹ poorly utilized data is just as good as no data. Data researchers need to be able to talk to developers and help figure out what data is worth collecting and what data isn’t. Organizations need someone to determine what data has real value, if only to solve a storage-related problem. Perhaps more importantly data managers would need to guide data usage both technically (in terms of algorithms, and software design) and in terms of being able to understand the abilities and shortfalls of data sets.

There’s a long history of IT specialist positions: database developers, systems administrators, quality assurance engineers, release engineering, and software testing. Typically we divide this between developers and operations folks, but even the development/operations division is something of a misnomer. There are merits to generalism and specialization, but as projects grow, specialization makes sense and data may just be another specialty in a long tradition of software development and IT organization.

Speicailization also makes a lot of sense in the context of data, where having a lot of unusable data adds no value and can potentially subtract value from an organization.

A Step Back

There are two very fundamental points that I’ve left undefined: what “data” am I talking about and what kinds of skills differentiate “data specialists” from other kinds of technicians.

What are big data?

Big data sets are, to my mind, large collections of data, GIS/map based information, “crowd sourced” information, and data that is automatically collected through the course of normal internet activity. Big data is enabled by increasingly powerful databases and the ubiquity of the computing power, which lets developers process data on large scales. For examples: the aggregate data from foursquare and other similar services, comprehensive records of user activity within websites and applications, service monitoring data and records, audit trails of activity on shared file systems, transaction data from credit cards and customers, tracking data from marketing campaigns.

With so much activity online, it’s easier for software developers and users (which is basically everyone, directly or otherwise) to create and collect a really large collection of data regarding otherwise trivial events. Mobile devices and linkable accounts (OpenID, and other single sign-on systems) simplify this process. The thought and hope is all this data equals value and in many circumstances it does. Sometimes, it probably just makes things more complicated.

Data Specialists

Obviously every programmer is a kind of “data specialist” and the last seven or eight years of the Internet has done everything to make every programmer a data specialist. What the Internet hasn’t done is give programers a sense of basic human factors knowledge, or a background in fundamental quantitative psychology and sociology. Software development groups need people who know what kinds of questions data can and cannot answer regardless of what kind or how much data is present.

Data managers, thus would be one of those posistions that sits between/with technical staff and business staff, and perhaps I’m partial to work in this kind of space, because this is very much my Chance. But there’s a lot of work in bridging this divide, and a great deal of value to be realized in this space. And it’s not like there’s a shortage of really bright people who know a lot about data and social science who would be a great asset to pretty much any development team.

Big Data Beyond Software Development

The part of this post that I’ve been struggling over for a long time is the mirror of what I’ve been talking about thus far. In short, do recent advancements in data processing and storage (NoSQL, Map Reduce, etc.) that have primarily transpired amonst startups, technology incubators, and other “Industry” sources have the potential to help acdemic research? Are there examples of academics using data collected from the usage habits of websites to draw conclusions about media interaction, reading habits, cultural particpation/formation? If nothing else are sociologists keeping up with “new/big data” developents? And perhaps most importantly, does the prospect of being able to access and process large and expansive datasets have any affect on the way social scientists work? Hopefully someone who knows more about this than I do will offer answers!

The Debate

Computer programmers want data to be as structured as possible. If you don’t give users a lot of room to do unpredictable things, it’s easier to write software that does cool things. Users on the other hand, want (or think that they want) total control over data and the ability to do whatever they want.

The problem is they don’t. Most digital collateral, even the content stored in unstructured formats, is pretty structured. While people may want freedom, they don’t use it, and in many cases users go through a lot of effort to recreate structure within unstructured forms.

Definitions

Structured data are data that is stored and represented in a tabular form or as some sort of hierarchical tree that is easily parsed by computers. By contrast, unstructured data, are things like files that have data and where all of the content is organized manually in the file and written to durable storage manually.

The astute among you will recognize that there’s an intermediate category, where largely unstructured data is stored in a database. This happens a lot in content management systems, in mobile device applications, and in a lot of note taking and project management applications. There’s also a parallel semi-structured form, where people organize their writing, notes, content in a regular and structured manner even though the tools they’re using don’t require it. They’d probably argue that this was “best practice,” rather than “semi-structured” data, but it probably counts.

The Impact

The less structured content or data is the less computer programs are able to do with the data, and the more people have to work to make the data useful for them. So while we as users want freedom, that freedom doesn’t get us very far and we don’t really use it even when we have it. Relatedly, I think we could read the crux of the technological shift in Web 2.0 as a move toward more structured forms, and the “mash up” as the celebration of a new “structured data.”

The lines around “semi-structured” data are fuzzy. The trick is probably to figure out how to give people just enough freedom so that they don’t feel encumbered by the requirements of the form, but so much freedom that the software developers are unable to do really smart things behind the scene. That’s going to be difficult to figure out how to implement, and I think the general theme of this progress is “people can handle and developers should err on the side of stricture.”

Current Directions

Software like org-mode and twiki are attempts to leverage structure within unstructured forms, and although the buzz around enterprise content management (ECM) has started to die down, there is a huge collection of software that attempts to impose some sort of order on the chaos of unstructured documents and information. ECM falls short probably because it’s not structured enough: it mandates a small amount of structure (categories, some meta-data, perhaps validation and workflow,) which doesn’t provide significant benefit relative to the amount of time it takes to add content to these repositories.

There will be more applications that bridge the structure boundary, and begin to allow users to work with more structured data in a productive sort of way.

On a potentially orthogonal note, I’m working on cooking up a proposal for a LaTeX-based build system for non-technical document production that might demonstrate--at least hypothetically--how much structure can help people do awesome things with technology. I’m calling it “A LaTeX Build System.”

I’d love to hear what you think, either about this “structure question,” or about the LaTeX build system!

Most of the sites I visit these days are: Wikipedia, Facebook, sites written by people I’ve known online since the late 1990s, people who I met online around 2004, and a few sites that I’ve learned about through real life connections, open source, and science fiction writing. That’s about it, it sounds like a lot, and it is, but the collection is pretty static.

As I was writing about my nascent list of technical writing links, I realized that while I’ve been harping on the idea of manually curated links and digital resources for for a single archives for a couple of years now, I’ve not really thought about the use or merits of manually curated links to the internet writ large.

After all you can find anything you need with Google. Right?

I mostly assumed that if I could get people to curate their own content, “browsing” would become more effective, and maybe Google technology could adapt to the evolving social practice?

Though the inner workings of Google are opaque, we know that Google understands the Web by following and indexing the links that we create between pages. If we don’t link, Google doesn’t learn. Worse, if we let software create all the links between pages, then Google starts to break.

Put another way: the real intelligence of Google’s index isn’t the speed and optimization of a huge amount of data--that’s a cumbersome engineering problem--but rather our intelligence derived from the links we make. As our linking patterns change, as all roads begin to lead back to Wikipedia, as everyone tries to “game” Google (at least a little) the pages that inevitably float to the top are pages that are built to be indexed the best.

And Google becomes a self-fulfilling prophecy because whatever page we do find out about and create links to are the links that we’ve found using Google. We’ve spent a lot time thinking about what happens if google becomes evil, to think about what happens to us as Google stops providing new and useful information. We’ve spent considerably less work considering what happens when Google becomes useless.

I love emacs. I’m also aware that emacs is a really complex piece of software with staggering list of features and functionality. I’d love to see more people use emacs, but the start up and switch cost is nearly prohibitive. I do understand that getting through the “emacs learning curve” is part of what makes the emacs experience so good.

That said, there really ought to be a way to make it easier for people to start using emacs. Think of how much more productive some developers and writers would be if the initial experience of emacs was less overwhelming. And if emacs were easier to use, developers could use emacs as a core (embeded, even) component of text-editing applications, for instance, some sort of specific IDE built with emacs tools, or a documentation creation and editing toolkit built with emacs. I’d go for it, at least.

To my mind there are three major challenges for greater emacs usability. Some of these may be pretty easy to change non-intrusively, others less so. Feedback is, of course, welcome:

1. The biggest problem is that there’s no default configuration. While I appreciate that this provides a neutral substrate for people to customize emacs for themselves, you have to write lisp in order to do pretty much anything in emacs other than write lisp. And customize-mode is well unmentioned, but not particularly usable.

Perhaps one solution to this problem would be to create a facility within emacs to build “distributions,” that come configured for specific kinds of work. That way, emacs can continue to be the way it is, and specialized emacs can be provided and distributed with ease.

2. Improve the customize interface. I like the idea of customize, but I find it incredibly difficult to use and navigate, and end up setting all configuration values manually because that’s easier to keep track of and manage. I’d prefer an option where you configure your emacs instance the way you want (through some sort of conventional menu system), and then have the option of “dumping state” to an arbitrary file that makes a little more sense than the lisp structure that customize produces. Then, as needed, you could load these “state file(s),” But then I’ve never used the menu-bar at all, so perhaps I’m not the best person to design such a system.

This strikes me as a more medium term project, and would make it easier for people who want to modify various basic behaviors and settings. I don’t think that it would need to totally supplant customize, but it might make more sense.

3. Improve and add the ability to extend emacs beyond emacs-lisp. I initially thought emacs-lisp was a liability for emacs adoption and I don’t think this is uncommon, but I’ve since come to respect and understand the utility of emacs lisp. Having said that, I think offering some sort of interopperability between emacs and other languages and interperators, might be a good thing. Ideas like ParrotEmacs and using the Guile VM to run existing emacs-lisp in addition to other new code would be great.

This is a longer term project, of course, but definitely opens emacs up to more people with a much more moderate learning curve.

I’ve been working (slowly) on getting my base configuration into a presentable state that I can push it to a git repository for everyone to see and use, which (at least for me) might start to address problems one and two, but three is outside of the scope of my time and expertise. The truth is that emacs is so great and so close to being really usable for everyone, that a little bit of work on these, and potentially other, enhancements could go a long way toward making emacs better for everyone.

Who’s with me? Let’s talk!