To SquareSpace or not to SquareSpace?

Here’s the thing.

I still manage multiple WordPress blogs and, with the exception of one of them (on a unique host), I can generally upgrade to the latest release in under 5 minutes. As far as I recall, that was one of the reasons for switching to SquareSpace – get out of the maintenance job.

What were the other reasons? From memory (though I probably blogged about it at the time) one other reason was the “everything is drag and drop” aspect. But really, that’s only of any use when I’m changing the look and feel or basic structure of the site. Which is, frankly, not very often. In any case, I’ve found SquareSpace’s limitations to be quite constraining on a number of occasions.

There’s always the promised “Version 6″ engine from SquareSpace. Eventually. Goodness knows when it will actually be released. If I match the current marketing hype to the reality of Version 5, then I’m really not expecting much of value from Version 6.

To be honest, the biggest reason to stick with SquareSpace right now is the amount of effort it will take me to switch back to WordPress. It’s not even so much the migration of the posts – which will be more difficult going back the other way – as the mucking around with domain records.

So, to SquareSpace or not to SquareSpace? That is the question…

Kumbaya

I’ve tried to refrain from writing this post for quite some time now, but the time has come.

Android is Linux. That is a very simple statement of fact because the Android OS is based on a Linux kernel. But I also mean it in another sense. Using Android is like using Linux.

Take a look around your friends and colleagues and see who is using Linux on a daily basis as their desktop OS. I’d wager they number very few. I know a lot of people who’ve tried Linux or use it in a secondary capacity. I know exacty two people who claim to use it daily. And that’s from all the people I know in real life and on the internet. Yet, if you go back 10 or even 15 years you’ll find numerous articles expounding Linux and how it is going to take over the world – on their desktops. But it didn’t. It hasn’t. Most likely, it never will. Why?

I’ll tell you why. Because computers have been promoted from toys to tools to appliances. Most people just want their computer to work and do not want to spend any time making sure they work. I know this because of lot of them come to me for help. And I have friends in similar situations.

Sticking with the desktop for a little longer, most people buy Windows PCs. The only reason they do this is because they are being marketed to. Give me a room full of computer users and I will find you a disgruntled Windows user. It’s not hard. I could tap myself on the shoulder as a fallback. However, most of these people get by.

Next up, I’ll give you a room of computer users and I’d like you to find me a Linux user. I’ll give you $10 if you can find one. I think my money is quite safe. The reason it’s quite safe is because Linux is not marketed, you might think. But the real reason you won’t find one in the average room full of computer users is that Linux requires geek credentials.

I’m a geek. I’ve tried Linux. My geek cred is not sufficient. I’ve tried Linux about four times from memory. Every time I’ve come unstuck on what should be a relatively simple task. The last time, I wanted to install a simple game and got stuck in an impossible loop of package dependencies. Therein lies the power and the Achilles Heel of Linux. If you know what you’re doing, and are prepared to invest the time, you can do just about anything.

This is how Android is the same. Every time I read an anti-Android comment the retort inevitably includes something like “you just install…” and often it includes “you just root the phone…” These are not the types of actions that normal users are likely to understand. Yes, Android is flexible, powerful (on the right hardware) and lets you do things your way. If you are a geek.

Up to this point, however, I’ve just been talking about pure Android. In the Linux desktop world you have choice. There are hundreds of different Linux variants. Even if we stick to “popular” there are several. There are even two popular and competing GUI frameworks to choose from in some. So it is in the Android world, also. Because with very few exceptions, any Android phone is not running pure Android.

This extra layer added by phone vendors complicates support and fractures the Android experience. If it were just bundled “crapware” it mightn’t be such an issue, but the vendors are skinning the OS and providing their own versions of key functionality. As a result, a new version of Android may not necessarily make it to any given handset even if the hardware is good enough to support it. If it does make it, there will inevitably be delays.

So do upgrades and updates matter to the average user? Maybe not. Should it? Yes! In today’s cyber-world, updates provide protection. If you’re not running the latest, then you are exposing yourself to exploitation through known vulnerabilities. All OSes have them.

And so to my conclusion. Android is a wonderful concept, just like desktop Linux. But unlike desktop Linux, Android is being marketed to ordinary people with typical “ooh, aah!” pizazz. Given the current state of affairs, this is disingenuous of Google and of the handset vendors. I guess we should expect it from the vendors but I do not believe Google is providing the experience they really intended to. Only Google can unify the experience for end users so that it is simple and staightforward to keep up to date (subject to hardware support) and ideally provide an experience that is near uniform across devices. I sincerely hope they do that.

Why? Because much like I hate supporting Windows users, I currently refuse to support Android users. Partly because I know very little about the innards of Android, but mostly because every darned phone is different. I’m not wasting my time gaining any knowledge because of the fractured landscape.

A final note. This is not “Android hate speech.” It is a plea for the many Android defenders to realise it is a platform with a fundamental issue given its widespread adoption (outside geekdom). It is an issue far more likely to be solved if there is uproar from the faithful.

There is a phrase often used in reference to open source: “Free, as in beer.” For the current state of Android, I have coined another: “Free, as in anarchy.”

Comments debunking my claims are welcome. Hate speech will be deleted. Anti-Apple sentiment (it’s fairly well known I’m an Apple fan) will be deleted – this post is about Android.

The case against threads?

I’m currently reading Walter Isaacson’s biography of Steve Jobs. There is a chapter in there which describes Apple’s visit to Xerox PARC where they discovered the marvellous new concept of the desktop metaphor for a graphical user interface (GUI). The general idea was if the computer screen could mimic a real, physical environment, it would be more intuitive to use.

Now while I’ve not seen a lot of buttons on real desks, they are nevertheless real objects. You find them on phones, on appliances, on remote controls and in lifts (elevators for you Americans). So the concept of pushing a button to the point at which it engages some function – a dial tone for instance – is fairly straight forward.

In recent years, however, I have discovered an annoying trait of some button hardware, principally in lifts. You see, when you push that button, two things happen. Your floor is selected so that the lift control system knows where to send the lift and a light comes on which hopefully signals you that the selection has been made. But not always.

In some lifts I have been repeatedly surprised by a button that lights up, but does not select the floor and indeed does not stay lit! My muscle memory for pushing a lift button is to stab at it with my finger and wait to see a light. I only need a few milliseconds of light before my attention falls away and my mind tells me the floor is selected. Sometimes I glance back at the button to discover it is not lit. Indeed sometimes this is prompted by the inaction of the lift itself.

I figure there are two electrical circuits involved. One to light up the button as simply as a light switch and one to signal the selection to the control software. The latter action then feeding back that the button should remain lit. By hitting the button too lightly or too momentarily, I believe I am only engaging the first function.

As a programmer, this behaviour annoys the hell out of me. It’s not deterministic from the user’s point of view and, well, why are these two functions disparate? It makes no sense at all. What is the point of lighting up a button merely to reflect that I pushed it? It sounds like a scene from The Hitchhiker’s Guide To The Galaxy. (It could at least admonish me to not push the button again.)

But at least when we return to the desktop metaphor, this kind of non-deterministic behaviour is not a problem, right? Wrong! Microsoft Windows XP, bless its little cotton socks, does exactly the same thing!

I don’t see it often, but I saw it again today. My mouse pointer movement was not as accurate as it could have been so the tip of the arrow rested on the very edge of the button in question. I clicked anyway and was rewarded with the “pressed” view of the button. But no action! My suspicion is that, much like the disparate circuits in the lift, there are multiple threads of code in the GUI handling the physical appearance of the button and the actioning of its related function. These two threads must be using different models of where the bounds of the buttons are. There is, after all, the bevel and the border to consider as “in” or “out” in each case.

PLEASE STOP IT!

That’s my message to programmers. Steve Jobs was a stickler for detail. He never settled for “good enough”. Sometimes he wouldn’t even settle for “great”, instead striving for “insanely great”. This is why Apple products are pleasant to use. The physical metaphors have been tuned to the point where they are intuitive.

There may be a sound reason to separate the functions in button processing – indeed the Model View Controller (MVC) paradigm may insist it is the best solution. But if you’re going to divide up a task, please ensure the resulting subtasks add up to the original concept.

When I push a button I expect the same result every time. It has two states – pushed or not. Any more – like I saw today – and it’s just sloppy.

56 is not enough. Or is it?

Now that a lot of the hubbub has died down, I feel it an appropriate time to give my comments on the passing of Apple co-founder Steve Jobs.

The news affected me more than, in hindsight, I would have epxected. I didn’t tear up, like some seem to be doing. I did disbelieve for just a moment – until I realised the source was Apple – and then the primary thought hit me.

Bugger.

My thoughts did not turn to Apple at first, but to the man who must have had a hell of a time in the last 6-9 months in the knowledge (it has been reported) that his time on this planet was very limited. And then they turned to his family, for if he lived his personal life with anything like the vision and determination he put into Apple, then his passing will be an incredibly difficult event to deal with.

And thirdly, my thoughts turned to Apple. I don’t for a second believe the company will falter any time soon, but to lose such a leader must inevitably hit them square in the chest and give pause even if only for a moment. I firmly believe that the company’s next move will be to carry on with the plan and continue the success that Steve has enabled.

Steve left this world at the tender age of 56. Far too soon for any human of our time. Too soon for the man, but too soon for the world? We can only wonder what the mind of Steve might have turned out in the next 10, 20, 30 or more years, but we should not forget that in his lifetime he has already contributed far more than most, and we would have been privileged to have been given even a tenth of it. The pipeline inside Apple will doubtless continue to produce his ideas for a while to come, so the journey is not over for the world just yet.

To the people who knew Steve, and they are few, I feel for your loss. For the rest of us, who know him through his company, now his legacy, let’s mark the date and continue our lives, enriched by the ideas of the man. And be thankful.

Anti-fanboy

Hello all.

If you read my blog you’ll have seen my post titled “What’s a podcast?” in which I wonder just what is the distinction between blogging, podcasting and any other type of content creation on the internet. What you’re hearing now is an experiment in the direction I discussed.

At this time I’m not going to say too much of interest as this is more about getting something out there to see how this might work.

But I do have something to say. In fact, I have a request.

Can someone please help me either find or coin a term that can be used to counter the word “fanboy?” I want something which describes a person with a rabid, but unfounded dislike of a brand or product.

Answers on the back of a blog post please (i.e. leave a comment).

Thanks.

What’s a podcast?

I’ve had this discussion with people in the past and it seems the definition is not the same for everyone. Or, to put it another way, not clear to anyone.

Podcast iconSome believe a podcast is an episodic audio (or indeed video) production on a common theme. Some say not all of these aspects need to be present. Some say it is any audio (or video) delivered as a download (as distinct from streaming only), although other listening (or viewing) methods are allowable.

Possibly the only consistency is that there is audio or video content.

So, what’s a blog post? Is it necessarily a topical (to someone) piece of text, perhaps with some images embedded? What about an embedded video? Yes? What about embedded audio?

Unusual, I will grant you. I’m struggling to think of any blog post I’ve seen with an attached audio component. You see, the audio component normally takes centre stage and the text is the supporting matter. It’s then probably called a podcast. After all: audio file, in a blog post, with an RSS feed. That’s a podcast. Isn’t it?

Yet it is awfully common to see a ‘blog post’ with an embedded video. So why isn’t that a podcast? Maybe it is, but it doesn’t fit my subconscious definition.

You see the problem? I see a problem.

My problem is that I frequently don’t have either the energy or time or state of mind to do a themed, episodic audio recording as I have, on and off, done for much of the last 5 years. Did I say regular? I didn’t. Doing so on a regular basis is even harder. I know several ‘podcasters’ reasonably well and they all, on occasion, mention the hardship of producing on a schedule. I know that hardship well. It’s what caused the first hiatus in my production schedule a year ago.

Note that it’s not the fact that I don’t enjoy creating an audio production that stops me. It’s the regularity, the theme to be followed and the fact that the audio is the core product. Following this train of thought leads me to the conclusion that I could record audio when appropriate, possibly as an adjunct to more solid material in written form. I mean, why not?

SDP logoThink, for a moment if you will, of the Sitting Duck Podcast. It’s a podcast containing music. It’s not a podcast about music. The whole idea of the podcast, way back in 2006, was to get the music out there. Over the years I tried doing other things to add interest to the podcast. Some created more work, some not. Some I think added real interest, some not. For the most part I’ve just rambled on topical subjects between the music. Rambled on topical subjects – just like I do in my blog posts.

Yet I have two web sites. One set up for a podcast production – audio files with supporting text – and one for ramblings of a general nature. It has become clear that the mechanism used for podcasts (i.e. RSS feeds, iTunes listings etc) does not, in and of itself, provide anything that a regular blog can’t. Oh sure, there’s ‘exposure’ in the iTunes Store. Yeah, right. Ever looked for a podcast in there other than when you know exactly what you’re looking for? I didn’t think so.

No, audience comes predominantly from word of mouth. The mouth can be ‘in real life’, in a blog, even in a podcast. Most of the podcasts I currently listen to I have found by means of other podcasts. Most of those I would add to my list if I had the time have been found through online social contacts. People with like interests. It’s an organic thing, not mechanical. It works for blogs and other types of web site too. Again, most of the sites I follow (ironically via RSS) have been found from other sites and through social contacts.

And so to my plan…

One Site to rule them all, One Site to find them,
One Site to bring them all and in the network bind them
In the Land of The Internet where the Content lies.

While I will still have distinct sites for other purposes (such as business interests) it is my goal to put what I will call ‘whimsical content’ in one place. Text, images, audio and video, on whatever takes my fancy, in one place. No order, no schedule, no grand plan. Just a collection point for that which whimsy makes me want to share. With you all.

And whimsical it shall all be. I shall be experimenting with the musical angle for sure. I still love the music, I still want it to be heard, but I don’t see that means I have to fall into the themed, episodic, regular groove that until recently I believed was required.

This should be interesting. There is much to ponder, much to figure, much to do. Watch this space.

How Google fixed (and broke) email

Email, in essentially its current form, has been around for quite a long time. Almost as long as me, in fact. The design has been modernised since its inception but, for the most part, the same basic structures and protocols have been used for at least 10 years.

Despite email having changed little in 10 years (indeed not much in 24 years), the ubiquity of personal and corporate email addresses and the equipment and networks we use to exchange these messages have advanced by leaps and bounds. Around the time of the last significant change (being RFC 2822) a person inside Search giant Google began developing what came to be known as GMail.

Three key features of GMail were the concepts of labelsarchiving, and conversations. These features have upset the apple cart in the email world for very different reasons.

Labels

Since very early days, email clients (more correctly Mail User Agents) have offered folders as a means of filing email for later retrieval. The concept of a folder is simple – a container into which one can place one or more emails. It is very similar in concept to the drawers of a filing cabinet, where a document can be placed in any one drawer. With the advent of IMAP (initially published in 1988), these folders were present on the server, too. IT was filing nirvana. Or was it?

I have been using corporate email for more years than I care to remember. Essentially since the beginning, I guess, as I distinctly recall using IBM’s PROFS system which predates the email we know today. In that time I have struggled to work out a structure of folders that I can reliably and easily file my emails into. I’ve never achieved it. I never will, either, because about 4 years ago I realised it was futile. A respected colleague had an impressive array of nested folders which he religiously filed his emails in. I stopped being jealous of this when I realised it didn’t help him one bit. Every time he was looking for an email that he remembered, he would look in at least two folders, often three or four. If you can’t go straight to the correct folder to find the email, what’s the point in filing it in the first place?

But using folders for filing presents a significant problem – the problem of giving each email a single classification. Although in some professions work can be fundamentally divided into discrete buckets this is certainly not true of the IT sector where I work. If I receive an email supplying two timesheet codes for different projects from the same project coordinator, then where on earth do I file it? Under “timesheet codes”? Perhaps. I can’t store it under a single project folder. What if the email also mentions a deadline for each project? Do I need a deadlines folder? This approach leads to either mutiple copies of emails (which I know some people do) or a huge number of highly specialised folders that become inefficient.

Labels solve this problem elegantly. A label is merely a tag, a sticker, a coloured flag. It is an attribute of the email, rather than an exclusive container for it. Because of this, multiple labels can be applied. For the example above I could apply the labels “deadline”, “timesheet”, “project A” and “project B”. This single copy of the email can then easily be located from any of those angles. Instead of viewing the contents of a folder, I filter my view of email to those that have at least the tag I am looking for, even if they have other tags. I can get smarter, too. I can ask for all emails with both ”project A” and “timesheet” which means I can quickly find exactly the information I am looking for. No folder structure could achieve that.

Archiving

However, even labels may not be necessary for efficient filing. At work, I am stuck using Microsoft Outlook, backed by an Exchange server. Outlook has categories which are similar to labels, but these are notoriously difficult to use and are therefore inefficient from the beginning. I do have a handful of folders to get things like automatic notification emails out of my inbox. But other than that, virtually nothing ever leaves my inbox. Rather than “inbox zero” I have “inbox infinity”. This is not ideal and I suppose I could cure it with a single folder to which everything gets moved when actioned. I do have “auto archiving” turned on which slowly empties out my inbox (which is all stored on the server) into a local file. This stops me hitting maximums, but I have to manage per-year archives to avoid maximums there.

Google solved this very elegantly with their version of archiving. Because no mail exists “in” anything in GMail, the inbox doesn’t actually exist – it is simply a label. If you archive an email in GMail, it simply removes the inbox label and the email seems to disappear. Except it doesn’t. It’s still there, whether with other tags or not. Combined with Google’s generous allocation of space (38 times the size my employer offers on the server), archiving is the ideal means of keeping email present without it cluttering up your current inbound emails and without having to think about “where to move it?”

And this is where Google’s core business comes into play. Search. Why tag your email when you can just search? Although I’m not fortunate enough to get to use GMail for work, I have used various products which index and allow searching over ALL of my email. It is by far and away the most effective means of locating emails I have ever used. Sure, sometimes I struggle coming up with the search terms, but this is no different to struggling to think which folder to place emails in. There’s no free lunch. I have recently taking to adding keywords to some of my outbound emails for the purposes of searching.

So you can see the combination of labels and archiving should be able to meet the needs of most people and meet them very efficiently. Google has advanced the state of play for the better, right? Unfortunately, no.

This where the “(and broke)” of the title comes in. Because Google are the only ones to make these advances and because no standards have been updated to account for these two differences, you are stuck using Google’s web interface if you actually want to make efficient use of them. As soon as you add an email client on any platform, you are into workaround territory. Labels pretend to be folders and your archive, which exists inside nothing, now has to live somewhere. This means lots of duplicate emails and contrived or impossible machinations to make any changes through the client that will make sense in GMail terms.

I’ve spent considerable time looking at email clients for my Mac and have repeatedly come to the conclusion that the web interface is the only practical one. Every other approach brings limitations or inefficiencies or both.

Conversations

So I already covered the fixing and breaking of email. Why are conversations left to last? Because Google have gone the opposite way here. They took something that worked perfectly fine and broke it in the name of “ease of use.” I don’t even think they achieved that.

The way Google build their conversation view is by crudely matching subject lines. This gives rise to “conversations” that are no such thing, such as a stream of notification emails from the same service. It can also give rise to broken conversations when someone changes a subject line. Although relatively rare, it is good email etticut to change the title of an email “trail” if the topic wanders. Google will split the newly titled email out of the original conversation, potentially losing the context of the discussion.

As far back as the original email specification (RFC 733, from 1977) there was provision for emails to be threaded by reference. Every email has a unique identifier in it and every forward and reply quotes the identifier of the original email. This makes it trivially simple for an email client to follow the actual thread of conversation, regardless of the subject line. I was using such an email client in the early 90s before the world wide web even existed. Quite how Google “invented” this inferior method (which was available in that early email client) and thought it feature-worthy is beyond me. It’s nothing more than a crude hack.

Conclusion

I’m tied into the Google email ecosystem for various reasons so it is unlikely I will change any time soon. But I do tire of the web interface easily (the new look one in the wings is worse!) and would like to be able to operate a native email client at least on my Mac. As of today, I don’t think that’s happening any time soon.

And if anyone is thinking of mentioning the Sparrow email client – I already own it. Their implementation of labels (which I do use on some of my GMail accounts) completely misses the point.

A roaringly good move

It’s hard, for me, not to imagine Hugh Laurie uttering that title. But I digress.

I’m not going to spend too much time here dissecting Apple’s newly released OS X 10.7 Lion. There are better places to do it. However, there is one particular feature of the new release which is dividing the faithful along love/hate lines.

On all previous versions of OS X, and indeed even earlier operating systems from Apple and also all of Microsoft’s, when you spin a scroll wheel (or ball) or vertically swipe a touch surface, the direction of the scroll it generates has been consistent. Scrolling the top of the wheel towards you translates to a downward direction in the basic mouse-to-screen relationship and the window concerned ‘scrolls down’. Which is to say you see further down the page than you were. This, many people contend, seems natural. I disagree.

It seems familiar. To lend weight to my argument, I present to you the iPhone. And the iPad. And the Motorola Xoom. And the Blackberry Playbook, countless Android-powered phones and tablets and more. All armed with touch screens, the need to translate from a horizontal plane to a vertical one is gone. So what happens when you move that finger down?

You see futher up the page than you were. This is the opposite of the previously described scrolling activity. And yet I’ve not heard anyone call this unnatural. Nor have I heard of anyone having problems switching between these touch devices and any of the traditional (i.e. pre-Lion) operating systems.

To understand the problem (some) people are having requires a look behind the scenes. If you’ve ever programmed a GUI system you’ll quite likely have come across the concept of a ‘viewport’. You can construct a ‘canvas’ on which your application paints its information and controls and the window on the screen serves as a viewport onto this canvas.

Until Lion, when you move the scroll wheel (or perform an equivalent action) you are moving the viewport, not the document. This must surely have been an arbitrary decision in the early days of GUI design and, I contend, not a good one. You are instructing the viewport to move down the document but the viewport doesn’t move –the document does!

It took touch devices, where you are actually touching the document, to sort this out. Ask yourself how completely natural this state of affairs was when you first used a touch screen device? Think about putting a scroll bar control on the side of your phone/tablet screen – how it would feel with the actual viewport in your hand, to push your finger in one direction only to have the document move in the other. It wouldn’t feel right.

While thinking through the backstory to this I think I came across the actual genesis of the problem. When I started working in 1987 I was privileged to play a part in the operation of an IBM System/36. Termed a ‘midrange’ system (not a mainframe), it was a large series of boxes to which you connected dumb terminals. It is to these terminals I now return my mind. All of the early models had what were called “roll keys”, which were used for scrolling. Usually combined with the basic directional arrow keys by means of the Shift key, the ‘roll up’ action was achieved by pressing Shift-up-arrow. Indeed, the document you were viewing on the screen ‘rolled up’ – exactly the opposite to the now accepted Page Up.

I remember it was in the days of the early PCs (XTs and ATs) that the terminal keyboards began to change to match the PC keyboards (before the PCs themselves took over the role of the terminal). Instead of roll keys we had Page Up and Page Down and we had to get used to the switching of directions not only in name, but also in relative position of the keys. The change had been made.

And now it’s being undone. Apple have had the wisdom, and indeed fortitude, to see the fallacy that Page Up and Page Down brought on us some 20+ years ago and right the wrong.

Lion’s scrolling may be unfamiliar to many, but it is most definitely natural. I welcome its return.

The danger of ‘the cloud’.

Ok, having sucked you in with that title, here’s my story. Or rather, my wife’s story.

On Wednesday 15th June my wife turned on her Mac and it failed to boot. I tried a few things and decided it had a very serious problem. Once it reached a particular point in the boot sequence all the hard drive noise stopped completely and it never went any further. I also rang a friend who used to be a tech fixing these machines. His advice was to take it in for service. (It still being under warranty.)

I was advised on the morning of Wednesday 29th that it had been fixed.

What has this got to do with the cloud? Well, my wife runs a small business. It’s small enough that the books are kept in actual books without much trouble. However the customers are 100% online. Most of the sales are done through TradeMe and eBay and also some from our web site. Payments are mostly processed via PayPal although some monies that need moving around are done via internet banking. Pretty much every action for the business occurs online until we’re ready to send out the product.

So, without a computer for 10 days, what was she to do? Simple, borrow my son’s computer. Log into GMail, TradeMe, PayPal, the bank and carry on as normal (albeit on a slightly smaller screen and with competition for screen time).

What do you think would happen if all that email was stored on her machine? Would it have been backed up? Hell yes. But the backup isn’t much use unless you go through some significant setup on an alternate machine – which you’re then going to stop using. If the bookkeeping were done electronically, I would probably have it in Google Docs and that could have carried on too, with zero interruption.

So next time someone moans that the cloud is a fad and is a weak point or single point of failure – so is your computer on your desk. And I’d wager Google or PayPal or whoever will fix their problem a LOT quicker than 13 days.

 

This is the picture

Continuing the theme of using song titles as post titles I have once again drawn from Peter Gabriel and his album So.

I have a problem. I forget stuff. I can remember the birthday (including year) of every member of my extended family. I can remember anniversaries too. I can remember a lot of streets and where they lead. These are all things that have been learned by repetition. Repetition can teach you some very arcane things – like Pi to 30 decimal places (this is typed in directly with no reference material) – 3.141592653589793238462643383279. I only learned that to annoy my father.

I can also remember some things without repetition. But those things generally need to be very important to me or exciting to me. Though I do forget important and exciting things sometimes, too. Which is why I really need a task list, or “To Do” list. I have one. In fact I have one in three places. On my Mac, on my iPhone and on my iPad. They all synchronise with one another. They’re even easy to use and, generally, I see my list every day in at least one of those places. Sometimes even the act of placing something on the list makes me remember it.

So, all good, right? Well, no. There are fundamental problems with all task management software I have ever used. I’d like for someone to solve this for me.

I first recognised this disconnect when I was working in a busy team of technical support people a few jobs ago. My idea then was to build something I would call “Team of Consciousness.” Get it? Like stream of consciousness – which is what it would be – but for a team. I still think the name is pretty clever. But that’s as far as I ever got.

Here is the first fundamental problem with task management software. I’m not single and self-employed. I am part of a family and part of a team at work. If my wife and I are going to go out for lunch then we both need to keep that item in our task lists. It is only a single item, but involves two parties. Yet if I have a dentist appointment then it only involves me. Task managers generally do not have assignment as part of their makeup. Some do, but those I’ve tried managed assignees very badly. Sending an email to someone is fine for notification, but unless there is a single, central definition of the task it just won’t work.

But wait a minute. We have a family (Google) calendar that we can put shared appointments on. (When I can get other family members to remember to update it) it works really well. Lunch and the dentist appointment are on specific days at specific times – lunch on the family calendar and the dentist on my personal calendar (these display simultaneously). Problem solved. Almost…

Does this sound familiar? I’m sitting in the lounge one evening during the week and my wife says “We should go and look at new beds. Ours needs replacing.” Simple enough, right? Let’s put that on the shared calendar. Uh, when? Next time we’re both free and not tired and the weather isn’t horrible and no-one needs to be at home for the kids and the shops are open. Uh, no, that’s not going to work. So it needs to be somewhere without a fixed date or time. So the task list would be a good place – except it’s not. Not only is there no easy way to share a task, but all unscheduled tasks just get chucked into a big bucket.

Here is the second fundamental problem. Although I do not have a specific time in mind, I would like to perform the task within a wider timeframe – when other variables allow. I would like it to show as “due” but not “overdue” for the next month. Perhaps towards the end of that month it could escalate up our lists.

These examples just cover a simple home life. At work, it gets even more complex. I work in a team that predominantly provides assistance to others. We also provide standard services, though they have variable components. On top of all that we have work we would like to complete for ourselves. We do not have the luxury of estimating the time by which a piece of work will be completed because we have no idea how many calls for help will arrive or if more important things will crop up. But we still need to keep these tasks on the radar so they are not forgotten.

Also, there are times when something needs to stay in the front of your mind even though there is no actual task. In that old job we used to have occasional customer visits on site. During those visits – often spanning a few days – we were required to pay careful attention to what we were discussing in the office, what we might have written on whiteboards or even on paper on our desks. This is something the whole team needed reminding of constantly, yet there was no “deliverable” at all. Some items may even be of infinite duration. Put your team goals or vision in there so everyone is reminded of them every day.

From all this came my idea of the Team of Consciousness. A one-stop portal to what you should be thinking about now. Some that need doing, others that just need awareness. Some things tied to a specific deadline, others not. Some that are for you alone, some for you and another and some for the whole team. No calendar or task management software I’ve ever seen can come close to this because they all rely on highly defined information and rarely consider a team environment. This could even be extended beyond the basic, everyday team. I have a team lead who has a manager who manages other teams. Some items may be shared across all of those teams. It could even go all the way to the top, where corporate items could live.

I once roughed out a database design that could support all of these possibilities but never quite nutted out how it would be presented. I imagine something like a Google Calendar view with bars of colour, but it could probably be done many ways. There would need to be different views – for an individual, for the team and for the team leader. Also for different levels of team. Calendar and list views would be useful and who knows what other possibilities.

So, that’s what I want. Who’s going to build it for me?