Termtter
Yesterday i discovered termtter (thanks to a twit from antirez). From the author’s description:
Termtter is a twitter client software working on terminal emulators, which is very easy to extend functions
Here is a view of its interface:
Updating your status is as simple as writing u my new status at the program prompt and installing it is just a matter of doing a
sudo gem install termtter
at the terminal.
Termtter will ask you for your twitter username and password the first time it’s run, and it will write them to the ~/.termtter/config file. It would be a lot better if it used OAuth but being opensource it should be easy to add (albeit being a bit of a challenge being a terminal, client application).
The config file is also the place where you can setup and enable various plugins and extensions, e.g. :
You can post the 100th fibonacci number to twitter by (1) uncomment the line “plugin ‘fib’” and reboot termtter and (2) type “fib 100″ on the termtter. http://twitter.com/ujm/status/1330652098 from the readme
I think that “very easy to extend” is an understatement from a rubyist point of view. Writing a plugin is just a matter of creating a ruby file in the ~/.termtter/plugins directory. A plugin can contain new command definitions, status view filters and hooks to take actions on different events (e.g. before or after posting an update). There are a lot of examples in there and here is one i wrote:
It adds a retwit command (with shortcut RT) which just retwits the given update (takes a single argument, the twit ID to be retwitted).
As you can see it’s really easy to personalize Termtter to fit one’s own usage of Twitter and to experiment with it.
Invisible Applications
As developers we fight with the desire to build useful new services and applications which can attract many users while at the same time reducing the friction that makes it difficult for our average user to try and keep using our creations.
I started observing how people usually hate learning and using too many different tools (except possibly for us geeks), this happens because we have limited resources and look for the maximum utility (this happens most at the cross of the business and consumer markets).
Uncertainty also plays a role in forming our decisions as users, where the perceived value of a new application is decreased by the lack of knowledge about how well it can fit the problems that we need to solve.
This has a few consequences: resistance in adopting new tools since it takes a too big effort to learn and preference for generic tools since they are perceived as more flexible and adaptable to our needs.
To overcome this we may reduce the visible part of the application to a level where the user stops noticing while making sure the user can easily reach the value we add. In the end it will all be about finding a way to give increasing returns for the same effort.
One way to follow this path is leveraging the tools that people are already using, integrating into or with them thus giving new ways to use those “old” and generic applications to do new things. Our invisible application will integrate within the flow of information that the user is receiving, it will remove modality from the interactions and augment the context around the documents and data that the users already handle to enrich the interaction with the same old services. Also, an important role will be played by allowing deep adaptation of the interface, whether automatically or via manual customization by the user (for the italian readers, look also at this presentation by Luca Mascaro).
