In the age of touch devices, some days it seems like a day will come when we will not have to use a keyboard to interact with computers. A significant part of our relationship with technology passes through interfaces that were not common a decade ago: touch screens, accelerometers, cameras and microphones.
Keyboards, however, are still the most efficient way to interact with a computer, and not only for typing email. From code editors like Emacs to advanced image manipulation tools like Photoshop, it is no wonder that most advanced programs can be controlled more efficiently by means of keyboard shortcuts.
The learning curve for shortcuts is generally quite steep: while some of them are standard across programs and can be easily guessed, most shortcuts are complex abstract key combinations (as ⌘-Control-Shift-3 on Mac, that takes a screenshot to the clipboard) and therefore not easy to remember.
Some applications, however, are introducing smarter ways to control our computers using a keyboard.
Desire paths are a common pattern in landscape design: born as simple footpaths when someone takes a more direct, shorter way to their destination, they often evolve to proper paths and roads after a while.
While architects and garden planners often regard those paths as unesthetic and try to prevent them by using fences and the well known _keep off the grass_ signs, desire paths tell a lot about the needs of people traversing a space. Some urban planners even use those paths to guide them when revising the original design by adding new roads or altering the original project.
Desire paths are important because they give insights about points where the original design is lacking from a functional point of view. Sure, they may not be as pleasant to the eye as a perfect, regular lawn, but they often show a more effective way to solve a problem: getting from one point in physical space to another.
I am posting about landscape design here because the same phenomenon can occur when observing the way users interact with software products. Users often compensate for missing features by and taking shortcuts and by adopting workarounds which, eventually, leave a persistent mark on the system they are using.
For most people of my generation, the phone system is broken. And it is not all about costs or devices: as Andreas Klinger once said, telephone numbers are a disgrace to our generation.
His main point, one I agree with, is the disconnect between phone numbers and the identity of the people behind them. He says:
I have friends that have three numbers in their signature. US, UK, local-european-country-no-one-knows. This whole system assumes I want to call their cellphones. Which is not true – I want to call them. The people behind that numbers, simcards and devices…
Andreas stresses the need for a means to reach people regardless of where they are, what phone operator they are using or other details that are insignificant from the point of view of the caller.
In the era of email and, now, social networks, phone numbers are a legacy of the old days. Especially since the introduction of personal mobile phones, they often constitute an unnecessary level of abstraction between us and the person we are trying to reach.
As Andreas points out, what modern phones would need is an identity system to abstract phone numbers out of the way, just like DNS does with IP addresses.
While this is a significant problem that needs solving, it would require some infrastructure to be in place, as you can see by looking at the scenarios explored in the post.
However, there is a smaller problem that can actually be addressed with resources that already are in place. And I am sure we all experienced it at least once.
As I already had the chance to write in a previous post, I really appreciate distributed version control systems; I consistently use them at work and for many of my side projects. I typically switch between git and mercurial repositories, with the former being my primary choice lately, and there is one specific command that always troubles me when I do that: pull.
There is one wonderful piece of inconsistency between the two systems, one that often leads to confusion for new adopters and unnecessary hassle for experienced users. If you are familiar with both systems, you may already be thinking about the culprits. If you are not, you may be more careful about the pull and fetch commands after reading this post.
Last Friday, a blog post on Channel 9 announced Achievements for Visual Studio, an extension for the Microsoft IDE that tracks the actions of programmers as they write code and unlocks badges based on their behaviour.
Now that the concept of Gamification has become (even too much) mainstream, it is not surprising that this is not the first time an idea like this is proposed. Jason Rudolph has published an excellent blog post about programming achievements. Websites like coderwall already inspect source code repositories on GitHub and others in order to build achievement-based profiles for coders. There even is an earlier project, called Strokes, that added achievements and challenges to Visual Studio.
Introducing mainstream achievement support right within the IDEs, however, can have a stronger effect on the way we write software, as those tools can inspect code right while we are writing it. The strong link between action and reward lead to a stronger feeling of accomplishment when we earn those achievements, and programmers are likely to be receptive towards game mechanics (most of us have a background as gamers). But there is more than that.
While issue trackers originate as tools to manage projects more effectively, during the last years of work I have been through some situations where their misuse backfired.
Tools originally conceived to improve workflows and project lifecycle became a significant burden for the team using them, occasionally making difficult situations even worse.
This post is a collection of bad patterns I have seen happening. It is not a survey of all the possible situations that can occur. It is not meant to be an argument against issue trackers (if it tells anything, it will probably be about the teams I was part of), but rather an overview of things that went wrong because of the way a particular team used those systems.
In retrospective, most of the problems were due to a lack of discipline and experience of the project teams, and they are less frequent – if present – in a team of seasoned professionals. But, while training and education can certainly help, I would love to consider a different aspect: the issue tracking systems were not helping as they could have.
Here is a summary of the most common and annoying problems I encountered
The issue tracking system is misused: Lots of issues are duplicates The system imposes over-engineered processes Bug reports do not include enough information The way priorities are managed is broken I would love to build on top of each negative experience, with a constructive attitude, by exploring how a better designed system could induce a better behavior.
There is one thing that often frustrates me and yet it happens quite often: I am driving and listening to the radio, and at some point they play a song I like. I would love to buy it, but I don’t know neither the song title nor its author.
Sometimes radio announcers say it immediately after, but some other times (most, actually) they do not, leaving no alternatives other than firing up Shazam to discover what is the song you like. And, well, if you are driving, that generally is a poor choice.
Now, just think about how we could redesign that process to make it more effective, using present-day technology and infrastructure.
Here is one possibility I would love to see happen.
…is not the device itself, but it is the whole ecosystem that surrounds it.
I have received my Kindle as a gift at the beginning of this year, and it quickly became my favorite gift of all time.
That can be quite surprising, knowing me. I own many different devices, gadgets and computers, but I have always been fond of the smell and feeling of paper books. Knowing that, some people were ready to bet that I would use the Kindle for just a few days and neglect it shortly after for something else (e.g. my iPad).
I must admit that I am sure this is exactly what would have happened with any other e-reader device. My experience with the Kindle, however, was (surprisingly) awesome, and it due to reasons I didn’t expect.
Knowing how much I enjoy indie games, a dear friend of mine bought me a new treat for Christmas. It’s called Machinarium, from Czech-based Amanita Design.
We just finished it today, and although it wasn’t very long, we enjoyed it so much that I thought it was worth mentioning.
If you are curious about the game, you can find out more here. (I strongly encourage you to check it out.)
In Milan, like in many other cities, public transport tickets have a magnetic strip on the side that is used to check their validity by means of electronic readers.
Even now, some years after the introduction of the new tickets, a lot of people still insert their tickets in the readers in the wrong direction, and can’t pass the turnstiles until they get it right. The technical reason for that is the magnetic strip placed on one side of each ticket so that it can be read by a machine, but it’s a poor design choice forcing people to pay attention to a puny detail such as this.