Just about the time I was ready to call OpenID a total failure, something clicked and, if you asked how I thought “OpenID was doing,” I’d have to say that it’s largely a success. But it certianly took long enough to get here.

Lets back up and give some context.

OpenID is a system for distributing and delegating authentication for web services to third party sites. Basically to the end user, rather than signing into a website with your username and password, you sign in with your profile URL on some secondary site that you actually log into. The site you’re trying to log in, asks the secondary site “is this legit,” the secondary site prompts you (usually just the first time, though each OpenID provider may function differently here.) then you’re good to go.

Additionally, and this is the part that I really like about Open ID is that you can delegate the OpenID of a given page to a secondary host. So on tychoish.com you’ll find the following tags in the header of the document:

<link rel="openid.server" href="http://www.livejournal.com/openid/server.bml" />
<link rel="openid.delegate" href="http://tychoish.livejournal.com/" />

So I tell a third party site “I wanna sign in with http://tychoish.com/ as my OpenID,” it goes and sees that I’ve delegated tychoish.com’s OpenID to LiveJournal (incidentally the initiators of OpenID if memory serves,) and LiveJournal handles the authentication and validation for me. If at some point I decide that LiveJournal isn’t doing what I need it to, I can change these tags to a new provider, and all the third party sites go talk to the new provider as if nothing happened. And it’s secure because I control tychoish.com and contain a provider-independent identity server, while still making use of these third party servers. Win.

The thing is that OpenID never really caught on. Though managing a single set of authentication credentials, and a common identity across a number of sites has a lot of benefits to the users, it never really caught on. Or I should say, it took a very long time to be taken seriously. There are a number of reasons for this, in my understanding:

1. Third party vendors wanted to keep big user databases with email addresses. OpenID means, depending on implementation that you can bypass the traditional sign up method. This isn’t a technological requirement but can be confusing in some instances. By giving up the “traditional” value associated with sponsoring account creation, OpenID seemed like a threat to traditional web businesses. There were ways around this, but it’s confusing and as is often the case a dated business model trumped an inspiring business model.

2. There was and is some fud around security. People thought if they weren’t responsible for the authentication process that they wouldn’t be able to ensure that only the people who were supposed to were able to get into a given account. Particularly since the only identifying information associated with an account was a publicly accessible URL. Nevertheless it works, and I think people used these details to make people feel like the system isn’t/wasn’t secure.

3. There are some legitimate technological concerns that need to be sorted out. Particularly around account creation. This is the main confusion cited above. If someone signs up for an account with an OpenID, do they get a username and have to enter that, or do we just use the OpenID URL? Is there an email address or password associated with the account? What if they get locked out and need to get into the account but there’s no email? What if they need to change their OpenID provider/location at some point. These are legitimate concerns, but they’re solvable problems.

4. Some users have had a hard time groking it. Because it breaks with the conventional usage model, and it makes signing into sites simple it’s a bit hard to grok.

What’s fascinating about this is that eventually it did succeed. More even than joy at the fact that I get to use OpenID, finally, I think OpenID presents an interesting lesson in the eventual success of emergent technological phenomena. Google accounts, flickr accounts, and AIM accounts all provide OpenID. And although “facebook connect” is not using OpenID technology, it’s conceptually the same. Sites like StackOverflow have OpenID only authentication, and it’s becoming more popular.

OpenID succeeded not because the campaign to teach everyone that federated identity vis a vis OpenID was the future and the way we should interact with web services, but rather because the developers of web applications learned that this was the easier and more effective way to do things. And, I suspect in as much as 80% or 90% of cases when people use OpenID they don’t have a clue that that’s the technology they’re using. And that’s probably an ok thing.

The question that lingers in my mind as I end this post is: is this parallel any other optimistic technology that we’re interested in right now? Might some other “Open*” technology take away a strategic lesson from the tactical success of OpenID? I’d love to see that.

Onward and Upward!

The file system is dead. Long live the File system.

We live in an interesting time. There are two technologies that aim to accomplish two very goals. On the one hand we have things like Amazon’s S3, Hadoop, NoSQL, and a host of technologies that destroy the file system metaphor as we know it today. The future, if you believe it, lays in storing all data in some sort of distributed key/value store-based system. And then, on the other hand we have things like “FUSE” that attempt to translate various kinds of interfaces and data systems onto the file system metaphor.

Ok, so the truth is that the opposition between the “lets replace file systems” with non-file based data stores folks and the “lets use the file system as a metaphor for everything,” is totally contrived. How data is stored and how we interact with data are very different (and not always connected) problems.

Let’s lay down some principals:

• There are (probably) more tools to interact with, organize, manage, and manipulate files and file system objects than there are for any other data storage system in contemporary technology.

• Most users of computers have some understanding of file systems and how they work, though clearly there are a great diversity of degrees here.

• In nearly every case, only one system can have access to a given file system at a time. In these days of such massive parallel computing, the size of computer networks, (and the associated latency) this has become a rather substantial limitation.

• From the average end user’s perspective, it’s probably the case that file systems provide too much flexibility, and can easily become disorganized.

• There are all sorts of possible problems regarding consistency, backups, and data corruption that all data storage systems must address, but that present larger problems as file systems need to scale to handle bigger sets of data, more users, and attach to systems that are more geographically disparate.

  Given these presumptions, my personal biases and outlook, and a bit of extrapolation here’s a basic feature set for “information storage system.” These features will transcend the storage engine/interface boundary a bit. You’ve been warned.

• Multiple people and systems need to be able to access and edit the same objects concurrently.

• Existing tools need to be able to work in some capacity. Perhaps using FUSE-like systems. File managers, mv, ls, and cp should just work, etc.

• There ought to be some sort of off-network capability so that a user can loose a network connection without loosing access to his or her data.

• Search indexing and capabilities should be baked into the lowest levels of the system so that people can easily find information.

• There ought to be some sort of user facing meta-data system which can affect not just sort order, but also attach to actions, to create notifications, or manipulate the data for easier use.

These sorts sorts of features are of course not new ideas. My sygn project is one example, as is haven, as is this personal information management proposal.

Now all we need to do is figure some way to build it.

I’m quite fond of saying “I’m not a programmer or software developer,” on this blog, and while I don’t think that there’s a great chance that I’ll be employed as a developer, it’s becoming more apparent that the real difference between me and a “real developer” is vanishingly small. Stealth Developer, or something. In any case, my ongoing tooling around with common lisp and more recently the tumble manager project have given me opportunities to think about lisp and to think about why I enjoy it.

This post started when a friend asked me “so should I learn common lisp.” And my first response was something to the effect of “no, are you crazy?” or, alternately “well if you really want to.” And then I came to my senses and offered a more reasonable answer that I think some of you might find useful.

Let us start by asking “Should You Study Common Lisp?”

Yes! There are a number of great reasons to use Common Lisp:

• There are a number of good open source implementations of the common lisp language including a couple of very interesting and viable options. They’re also stable: SBCL which is among the more recent entrants to this field is more than a decade old.
• There are sophisticated development tools, notably SLIME (for emacs) which connects and integrates emacs with the lisp process, as well as advanced REPLs (i.e. interactive mode). So getting started isn’t difficult.
• Common Lisp supports many different approaches to programming. Indeed, contemporary “advanced” languages like Ruby and Python borrow a lot from Lisp. So it’s not an “archaic” language by any means. Dynamic typing, garbage collection, macros, and so forth.
• CL is capable of very high performance, so the chance of saying “damn, I wish I wrote this in a faster language,” down the road isn’t terribly likely. Most implementations run on most platforms of any consequence, which is nice.
• You’re probably tired of hearing that “Learning Lisp will make your a better programmer in any language,” but it’s probably true on some level.

The reasons to not learn Lisp or to avoid using it are also multiple:

• “Compiled” Lisp binaries are large compared to similarly functional programs in other languages. While most CL implementations will compile native binaries, they also have to compile in most of themselves.
• Lisp is totally a small niche language, and we’d be dumb to assume that it’s ever going to take off. It’s “real” by most measurements, but it’s never really going to be popular or widely deployed in the way that other contemporary languages are.
• Other programmers will think you’re weird.

Having said that all of I think we should still start projects in CL, and expand the amount of software that’s written in the language. Here’s why my next programing project is going to be written in lisp:

• I enjoy it. I suspect this project like many projects you may be considering is something of an undertaking. Given that I don’t want to have to work in an environment that I don’t enjoy, simply because it’s popular or ubiquitous.
• Although Lisp isn’t very popular, it’s popular enough that all of the things that you might want to do in your project have library support. So it’s not exactly a wasteland.
• The Common Lisp community is small, but it’s dedicated and fairly close knit. Which means you may be able to get some exposure for your application in the CL community, simply because your app is written in CL. This is a question of scale, but it’s easier to stand out in a smaller niche.

Of course there are some advantages to “sticking with the crowd” and choosing a different platform to develop your application in:

• If you want other people to contribute to your project, it’s probably best to pick a language that the people who might be contributing to your application already know.
• While there are libraries for most common things that you might want to do with Common Lisp, there might not be libraries for very new or very esoteric tasks or interfaces. Which isn’t always a problem, but can be depending on your domain.
• The binary size problem will be an issue if you plan to deploy in limited conditions (we’re talking like a 15 meg base size for SBCL, which is a non issue in most cases, but might become an issue.)
• If you run into a problem, you might have a hard time finding an answer. This is often not the case, but it’s a risk.

Onward and Upward!

A few weeks ago a coworker walked into my office to talk about the architecture of a project, complete with diagrams, numbers I didn’t grasp (nor really need to,) and the examples of potential off the shelf components that would make up the stack of the application at hand. I asked scores of questions and I think it was a productive encounter. Normal day, really. I seem to be the guy developers come to and pitch ideas to for feedback. Not sure why but I thin think that the experience of talking through a programing or design problem tends to be a productive learning experience for everyone. In any case the details aren’t terribly important

What stuck in my head is that an off the self, but non-trivial part of the system was written in Java.

We all inhaled sharply.

I don’t know what it is about Java, and I don’t think it’s just me, but the moment I find out that an application is written in Java, I have a nearly visceral reaction. And I don’t think it’s just me.

Java earned a terrible reputation in the 90s, because although it was trumped as the next big thing every user facing application in Java sucked: first you had to download a lot of software (and hope that you got the right version of the dependency) and then when you ran the app it took a while to start up and looked like crap. And then your system ground to a halt and the app crashed. But these problems have been fixed: the dependency issue is more clear with the GPLing of Java, GUI bindings for common platforms are a bit stronger, computers have gotten a lot faster, and perhaps most importantly the hopes of using Java as the cross platform application development environment have been dashed. I think it’s probably fair to say that most Java these days runs on the server side, so we don’t have to interact with it in the same sort of hands on way.

This isn’t to say that administering Java components in server operations is without problems: Java apps tend to run a bit hot (in terms of RAM,) and can be a bit finicky, but Java applications seem to fit in a bit better in these contexts, and certainly have been widely deployed here. Additionally, I want to be very clear, I don’t want to blame the language for the poor programs that happen to be written in it.

Here are the (hopefully not too leading) questions:

1. Is the “write once run everywhere,” thing that Java did in the beginning still relevant, for server-based applications? It’s a server application after all, you wouldn’t be loosing much by targeting a more concrete native platform.

2. Is the fact that Java is statically typed more of hindrance in terms of programmer time? And will the comparative worth of Java’s efficiency wear off as computers continue to get more powerful

Conventional wisdom being that while statically typed apps “run faster,” but take longer to develop. This is the argument used by Python/Perl/Ruby/etc proponents, and I don’t know how the dynamics of these arguments shift in response to the action of Moore’s Law.

3. One of the great selling points of Java is that it executes code in a “managed” environment, which provides some security and safety to the operator of the system. Does the emergence of system-level visualization tools make the sandboxing features of the JVM less valuable?

4. I don’t think my experiences are particularly typical, but all of the Java applications I’ve done any sort of administrative work with have been incredibly resource intensive. This might be a product of the problem domains. Using Java is often like slinging a sledge hammer around, and so many problems these days don’t really require a sledge hammer.

5. At this point, the amount of “legacy” Java code in use is vast. I sometimes have trouble understanding if Java current state is the result of all of the tools that have already been invested in the platform or the result of actually interesting and exciting developments in the platform. Like Clojure. Is Clojure (as an example,) popular because Lisp is cool again and people have finally come to their senses (heh, unlikely) or because it’s been bootstrapped by java and provides a more pain free coding experience for Java developers?

Anyone have ideas on these points? Questions that you think I’m missing?

In response mostly to my own comentary of the iPad I’d like to lead a collective brainstorming of input and computer interact modalities in “the next wave.”

What’s the next wave? That thing that’s always coming “soon,” but isn’t quite here yet, the thing that we are starting to see glimpses of, but don’t really know. Accepting for a moment that things like Blackberries, netbooks, Kindles, iPads, iPhones and the like are these “harbingers” of the next wave.

The “make or break” feature of all these new and shiny things is the input method: how we get stuff from our heads into a format that a computer can do something with. While I’m a particularly… textual sort of guy, the “input question,” is something everyone who uses technology will eventually come to care about. Blackberry’s sell because they speak “messaging,” and because most of them have hardware keyboards. The iPad, with its bigger onscreen keyboard and external keyboard dock, is--to my mind--an admission that the little onscreen keyboard of the iPhone doesn’t work if you want enter more than 50 or 60 characters at any given time.

I love a good hardware keyboard. A lot, and I’m not just talking about the kind on the blackberry, but a real keyboard. The truth is I can’t even quite bring myself to justify one of the little “netbooks” on the principal that everything I do involves massive amounts of typing. And fundamentally, at the moment there doesn’t seem to be a good replacement for getting data into a computer system, that doesn’t involve a keyboard. Clearly this can’t hold out forever, and so I’d like to pose two questions:

1. What kind of computer interfaces will replace the command line?

So in 2010 most people interact with their computers by way of the mouse and a lot of pretty pictures. Even mobile environments like the iPhone/iPad/etc. and the Blackberry have some sort of a pointer that the user has to manipulate.

But the truth is that this kind of modality has always been inefficient: switching between the mouse and the keyboard is the greatest time sink in current user interfaces. Graphical environments require increasingly sophisticated graphics hardware, they require users to memorize interfaces in a visual way that may not be intuitive (even if we’re accustomed,) and they have incredibly high development costs relative to other kinds of software. Furthermore, most of us use a lot of text-based interfaces weather we know it or not. Google is a command line interface, as are most web browser’s address bars. And although my coworkers and I are hardly typical, we all have a handful of terminals open at any given time.

Clearly shells, (e.g. bash, zsh, and the like) are not going to be around forever, but I think they’re going to be around until we find some sort of solution that can viably replace the traditional shell. We need computer interfaces that are largely textual, keyboard driven, powerful, modern, lightweight, fast, and designed to be used interactively. I’m not sure what it looks like, but I know that it needs to exist.

2. What kind of interfaces will replace the keyboard for data entry?

When I was writing the iPad reflection, I thought it might be cool to have an input device that was mostly on the back of the device, so that you hold the device in both hands, your fingers make contact with some sort of sensors on the back, with your thumbs touching something on the front, and there’s some sort of on-screen interface that provides feedback to make up for the fact that you can’t see “the keys.”

I’d be inclined to think that this would be QWERTY derived, but that’s as much a habit as it is anything. I’m a pretty good touch typist, not perfect, and not the fastest, but I don’t have to think at all about typing it just happens. But I don’t know or think that the QWERTY keyboard is going to be the interface modality of the future. While I do want to learn DVORAK typing--but haven’t managed to really feel inspired enough to do that--I think its more productive to think about replacements for the keyboard itself rather than alternate layouts.

Thoughts?

I’ve been thinking recently about the relationship and dynamic between the corporations and “enterprises” which participate in and reap benefits from open source/free software and the quasi-mythic “communities” that are responsible for the creation and maintenance of the software. Additionally this post may be considered part of my ongoing series on cooperative economics.

When people, ranging from business types, to IT professionals, to programmers, and beyond, talk about open source software we talk about a community: often small to medium sized groups of people who all contribute small amounts of time to creating software. And we’re not just talking about dinky little scripts that make publishing blogs easier (or some such), we’re talking about a massive amount of software: entire operating systems, widely used implementations of nearly all relevant programing languages, and so forth. On some level the core of this question is who are these people, and how do they produce software?

On the surface the answer to these questions is straightforward. The people who work on open source software are professional programmers, students, geeks, and hacker/tinkerer-types who need their computers to do something novel, and then they write software. This works as model for thinking about who participates in open source, if we assume that the reason why people contribute to open source projects is because their individual works/contributions are too small to develop business models around. This might explain some portion of open source contributions, but it feels incomplete to me.

There are a number of software projects that use open source/free software licenses, with accessible source code, supported by “communities,” which are nonetheless developed almost entirely by single companies. MySQL, Alfresco, and Resin among others serve as examples these kinds of projects which are open source by many any definitions and yet don’t particularly strike me as “community,” projects. Is the fact that this software provides source code meaningful or important?

Other questions…

1. If there are companies making money from open source code bases, particularly big companies in a business directly related to software, does this effect participation of people who are not employed by that company in the project?

In my mind I draw distinctions between technology businesses that use/sell/support open source software (e.g. Red-Hat, the late MySQL AB, etc.) and businesses that do something else but use open source software (i.e. everyone with a Linux server in the basement, every business with a website that runs on Apache, etc.)

2. Does corporate personhood extend to the open source community. Are corporate developers contributing as people, or as representatives of their company?

I largely expect that it’s the former; however, I’d be interested in learning more about the various factors which affect the way these contributors are perceived?

3. Do people participate in open source because it is fun or for the enjoyment of programming,

4. Has software become so generic that open source is a current evolution of industry standards groups. Do we write open source software for the same reason that industries standardized the size and threading of bolts?

5. Are potential contributors disinclined to contribute to software that is controlled by a single entity, or where projects

6. Is the cost of forking a software project too high to make that a realistic outcome of releasing open source software?

Conversely, were forks ever effective?

7. Do communities actually form around software targeted at “enterprise” users, and if so in what ways are those communities different from the communities that form around niche window p managers or even community projects like Debian?

I don’t of course have answers yet, but I think these questions are important, and I’d love to hear if you have any ideas about finding answers to these questions, or additional related questions that I’ve missed.

I’ve been thinking about how ideas, projects, and ideas scale a bit in the past few weeks, and as usual, I wanted to collect a few of these thoughts. This post is generally in my series of posts of “Extrapolations from Systems Administration.” Inspirations and origins of these ideas come from, in part:

• My Tumblr Killed the Tumblelog Star post.
• My Google reader unread count.
• Savage Minds Post on Social Enterpernurship and Anthropology post.
• All the television I don’t watch.
• The nginx HTTP Proxy module.
• Seeing the Forest for the Brand

The internet is a big place, you don’t need me to tell you this, but I think that it’s really incomprehensibly big. Even the small corners of the internet that we (well, I at least,) inhabit contain vast amounts of information and it’s very difficult to keep your head above water, to feel like you’re in touch with what’s happening. Strategies for managing this information successfully are as concerned with “figuring out what to ignore,” as they are about figuring out how to absorb information successfully.

Scaling an idea or a concept (like a blog, or a piece of software or a web server) to be able to address problem sets (like an audience, or a given set of data, or both) of different sizes is just as difficult. It’s tough to get a web server to be able to host really large loads, its difficult to be able to write a blog that appeals to a huge audience: the this nexuses of related problems are quite large.

I think, however, we can begin to draw some conclusions. I do hope that you’ll be able to help me add to this list. Perhaps in a wikish page.

1. Be the biggest fish in the smallest possible pond.

   The core strategy here is to avoid having to figure out how to scale up to “full speed,” by reframing the problem set. You don’t have to become the most popular or widely consumed blogger/novelist: you just have to become the most popular blogger about cyborg philosophy, or the political economics and philosophy of the open source world. You have to become the most popular post-colonial historiography space opera novelist.

2. Don’t participate in the proliferation of crap: only build/use what you need to.

   I see lots of people say something along the lines of “I want to make a websites for all of the people interested in what I’m interested in, and we’ll need a wiki and some discussion forums, and some sort of blogs, maybe a lot of blogs, and…” This inevitably leads to a bunch of organization and building of things for their websites, and then everything is built and… no one is interested in using the crap.

   This is a classic premature optimization problem. Don’t build things that you think you might need later. Build things that you need now. Or things that you really needed last week. Focus on the thing you do, and build the infrastructure as you need it, when you need it.

3. Work in a scalable and sustainable manner, and assume that other people will need to pick up on your projects.

   While you shouldn’t expend the effort to scale before you need to, because that could end in failure, it’s common sense to approach your projects with the assumption that other people might have to finish them for you, if things take off and you need to delegate later you’ll be ready for them. Consider the possibility that you might need to scale a project when you’re in the initial planning stages and avoid getting backed into a corner by a decision.

4. Ignore everything you can possibly stand to.

   There are so many things that you could be doing with your time. There are so many distractions. Email lists, RSS feeds, the work of other people in your field. Charity projects of one sort or another. All of these things are important and you should participate fully in the communities that surround your work, but be fully aware that humans as individuals don’t scale well, and succeeding at [your project] is dependent upon your ability to ignore everything that you can stand to.

5. Consume information on your terms, in the formats that make the most sense to you.

   As a corollary to the above, the way to successfully engage and manage everything that you can’t possibly stand to ignore is to as much as possible engage on your terms. Figure out what your terms are first, and then work to consume content in these terms.

6. Use technology and media to build relationships rather than accumulate information.

   Too often, I think, the geekier among us (and I count myself among this number) are interested in technology because it’s cool, and we’re tempted to solve technological problems and learn about the inner workings of stuff because they interest us. And that’s okay, as a hobby: in the pursuit of doing work, technology is only useful insofar as it allows you to get things done. And in most cases, the core function that technology provides is to enable relationships. So focus on that, and fiddle with the technical underpinnings, only when you must.

Onward and Upward!

This post represents two major ideas, first of “app stores,” and second of “Sass” or “software as a service,” which seems to be the prevailing business model for contemporary technology companies that aren’t stuck in the 80s. With reflection on free software, open source, and the technology industry as a whole. Because that’s sort of my thing.

On the one hand the emergence of these tightly controlled software distribution methods represent a fairly serious threat to free software, as does SaaS particular insofar as SaaS exploits a GPL loophole. On the other hand these models, potentially, represent something fundamentally awesome for the technology and software world, because it represents a commonly accepted paradigm where users of software recognize the value of software, and the creators of software can get compensated for their work. It’s not without its flaws, but I think it opens interesting possibilities.

Free and Freedom

Obviously app stores present a quandary for those of us involved in the free software world. On the one hand app stores are not free, which is a trivial complaint. It’s not the cost, around which “free software” is truly centered, the true failing here is that creators of software cannot choose to participate in an app store system and distribute source code: the interaction and relationship between developers and users is very scripted and detached. These issues all grow out of the reality that app stores--by design--are they’re controlled by a single institution or organization.

Which isn’t itself a bad thing--there are contexts where centralized organization means things get done more effectively, but centralized authority is not without risk. So while this question isn’t resolved, it’s also the kind of question that requires ongoing attention and reflection.

Paying for Software

At the same time, I think it’s very true that the “app store model” and indeed the more successful “Web 2.0” business models (e.g. new businesses on the web, post-2003/2004) have posited that:

Software is a thing of value that users should expect to pay for.

And that’s not, at least to my mind, a bad thing for the software world. Free or otherwise. Or not always a bad thing, particularly for end-user software. For larger pieces of software (in the “Enterprise”) money is largely exchanged for support contracts and for services related to the software: custom features, IT infrastructure, etc. For end user software, support contracts and custom features don’t tend to make a lot of sense in context: so perhaps moving back to the exchange of money for software isn’t a bad thing.

The connection between “value” (which software almost certainly creates), and currency in the context of software is fraught. Software isn’t scarce, and will never be (by nature.) At the same time it does have value and I think it’s worth considering how to arrange economies that involve exchanging money for software. There are a lot of factors that can effect the way that app stores might work, and I think given the possibility for causing interesting things to happen we shouldn’t dismiss them out of hand.

Related Reading

Despite my (potential) lack of clarity at the moment, I think the following posts reflect some of my earlier thoughts on this subject.

• Package Management and why your Platform Needs and App Store
• iPad Reactions
• Free Network Businesses
• There’s a Widget for that
• Owning Bits

Ok, so not really.

This post is mostly about playing a head game with yourself, in an effort to get more organized. But not “head games” in a bad way. On my to do list for the past few weeks I’ve had something like “write a blog post about todo list item titles,” because in light of this post about org-mode it seems like a topic in need of further definition. Basically my goal is to explore, the best way to think about what we have to do, to allow us to accomplish what we want to. The GTD system which so many people are enamored of present a few ideas on the topic, and while the GTD way is a good place to start thinking, it’s not a good place to stop thinking.

We’ve all done it. Made a todo list that we didn’t end up using for one reason or another. Todo lists, need to be useful: they should help us organize our day, and help us keep track of all the things wee need to accomplish. In a lot of ways, maintaining focus over our day and all of the tasks that nag at us are contradictory, so todo lists are failed by design.

The first, and frequent issue in my own organization are lists and plans that go too far and list too many “actionable items.” This divides your time and actions into too many little pieces, leading to a number of outcomes. The first risk is that you might start to ignore the list entirely because it’s too long and complicated, even if it’s an illusion caused by the size of the items on your list. Ergo, the total length of the list you “work off of,” needs to be manageable and comprehensible.

The second risk, is that, an overactive todo list is one where you over plan for yourself, such that your list--while accurate and comprehensible--isn’t useful. Beyond simply providing “outboard memory,” the best todo lists allow us to structure and make plans for our working time. When working (e.g. writing, at the computer, etc.), I like to have my projects chopped up into pieces that can conceivably get done in the time I have to work on them, but that give me the time and freedom to bury myself on a side project, or follow inspiration or a train of thought to its completion when needed. While effective todo lists help you structure your time, flexibility is still valuable.

There are issues on the other end of the spectrum as well: when lists are too short, and the “actionable items” on a list are too conceptually large, the effectiveness of lists is degraded as well. A reminder to “write a novel,” even a specific novel, is less than helpful for helping you accomplish something in the moment. Even a dozen items, on a list where you end up checking something off once every day or two doesn’t help you figure out “Ok, what do I need to work on now.” Besides the chances are, if the items are too large and the list is too small, that you probably have it memorized anyway.

Right? Other strategies?

As you all might have heard that Amazon (finally) released a Kindle Application for the Blackberry. When I heard this I thought that this would be a good thing, as I have (and quite enjoy) both my Blackberry and Kindle. Here’s the rundown:

• The Kindle App for the blackberry is probably the most well designed blackberry application I’ve seen thus far. Having said that, the bar isn’t terribly high.

  In a lot of ways, the way (before the Kindle app) to make a “successful” blackberry application is one that figures out how to make its data “fit” into an email or messaging context and then blend that data into the messaging/event feed in a useful sort of way.

  This doesn’t do that, and I think learns a great deal from advancements made in iPhone app development. The resolution on the Blackberry Bold is amazing (same number of pixels as the iPhone, much greater density.) and the buttons/interface is really intuitive and well designed. The app itself gets as many thumbs up as I can manage.

• I’ve been having phone angst recently. I don’t use it very much, I need to have better filtering of my email and reorganize how I do my voice mail, and while this is easy enough to say here it’s a much more substantial project than I’ve got time for now.

• The Kindle App isn’t a replacement for the kindle, but it’s a great compliment, and it makes it much more possible to lighten the load in my back-bag, and it makes it easier for me to entertain myself with my phone. This might not seem like a bit deal, but I think it is.

  There are also situations where the Kindle isn’t usable (in bed when the lights are off and various other low light situations) and that’s alright, but the Kindle app is. So that’s a good thing indeed.

• I had hoped that the kindle would make it easier to read in the in between moments throughout the day when I might read but didn’t. That isn’t exactly true, as it turns out. Reading on the Kindle still requires a fair piece of directed attention, and it’s not the kind of thing you can idly whip out while you’re waiting in the grocery check out line.

  I’m not sure at this point, of course, but I do think that having access to the Kindle on the phone will improve this usability feature.

• I’m sort of annoyed by the lack of subscriptions. While you can have multiple devices attached to your Kindle account, when you subscribe to a periodical, that content is only accessible to you on one of your devices. I don’t really like this, and it represents a huge loss of value for the Kindle store.

While I got the Blackberry shortly after the first iPhone 3g came out, the “app explosion” hadn’t really happened yet. I must confess some “app jealousy.” The Blackberry is awesome, and really it does the messaging quite better than anything else around (I’m convinced.) And I love the hardware keyboard. But when I think “I’d like to do something with my phone,” the chance of getting a Blackberry app to do that is… unlikely. I don’t know if I want a lot of apps on my phone, in the end, but I know the hardware is capable, and it’s nice to take advantage of that from time to time. In any case…

Onward and Upward!