Niels K. logo Niels K.

My GTD-workflow

This is a blog post which is in the pipelines for several years now. But since I got asked now directly, I decided to finally write down what my take on Getting Things Done, in short GTD is. I read the book by the same name by David Allen in 2005 or 2006 after it got recommended to me with the comment “Since I use this system my desk is always tidy”.

I never took the book as a ruleset but with the words of Captain Barbossa from the first Pirates of the Carribean-movie: “the code is more what you’d call ‘guidelines’ than actual rules”. So, I created my own “system” to get things done. And I have to be honest, it doesn’t always work and from time to time I succumb to slacking but this is probably some part of my nature and hard to fight. But I give my best.

The system had several iterations and began its life on paper with the Hipster PDA and a hacked Moleskine but needed actually computer programs to really work. What it needs is something you have always with you like a smartphone that syncs its data to your computer.

Trust and Outsourcing

The most important parts of what I learned from the book are essentially the following two:

  1. Have a trusted system.
  2. Write everything down.

Without a trusted system, everything I am writing here about isn’t a solution at all. When you don’t trust your system, you might even create more workload for your brain. After all you have to remember then what you have written down and what not and maybe even care about wether nothing gets lost in your system.

The second one only works, when you have a trusted system. Write everything down. Move stuff out of your brain into your system. Essentially outsource task management from your brain to your todo-system. The good thing is that in contrast to an economy, there will be no hollowing-out, since no one looses his or her job and will have problems to find a new one. No, you make ressources free, to be able to focus on the tasks, you have to do right now. The more you write down, the lesser the chance that your brain will pop right into an important task with a modal reminder dialogue that you shouldn’t forget to get salt at the super market, so your dinner won’t taste bland.

But number two works only if you have a trusted system. So create one and then write everything down.

The Setup

Inboxes

First get your inboxes in order. In my case it is a pile situated on my desk of loose papers, my mail inbox and the inbox of the current app of choice on my smartphone and its equivalent on my computer. And in general I try to follow the principle that fewer inboxes are better because that means that I have to trust less things to work. In my experience the pile of paper is the most untrustworthy one. But hey, there is still so much paper floating around.

I prefer using some todo-apps on my Mac and their iOS-clients. But at work I have only Windows available, so I am using there a plain-text-system and sync it to an iOS-client via Dropbox. Makes more inboxes but the Mac-clients are worth it.

Areas of Responsibility

The next thing I need for getting order into my tasks are larger groups, that are defined by areas in my life. In Things I am using “Areas of Responsibility”. In OmniFocus I used folders, in plain-text solutions I usually use one text-file per area. Depending on the system I have more areas. In Things or a text-file system I have some “projects” converted to “Areas of Responsibility” or would have in a text-file-system in its own file.

I have defined for myself six areas:

  • Home
  • University
  • Work
  • Administration
  • Blogging / Podcasting
  • Hobby

Home: Everything I have to do privately or are family matters. Cleaning the apartment, repairing toys from my child, getting something new for the apartment, water the flowers etc.

University: This one is for everything related to my studies. Texts that I have to read, questions I have to research, extending the dates when I have to return books to the library and so on.

Work: Since I am a student who has to pay rent, has to eat something and wants from time to time just buy stuff, I have to work. Everyting work-related comes into this area. Usually I have a secondary system just for work, since I have to work with Windows at work but prefer actually a Todo-app that is only available for OS X.

Administration: This is the area for paperwork and paying bills.

Blogging/Podcasting: Well, I have a blog and am part of two podcasts. I could fit those also into the Hobby-area but I prefer to keep them separate. Henceforth ideas and everything I have to do for those get into this area.

Hobby: A child, work, studying, blogging and podcasting still can leave a bit of free time that wishes to be filled. So, I have a few hobbies, like a monthly pen&paper-role playing session, dancing and karate classes. From time to time I have to do something for them, too like advancing my character or just getting new equipment like laces for my dancing shoes or a new belt when I was succesful in a belt trial.

Projects

Not every task needs a projects. Therefore I have in OmniFocus some projects with the name “miscellaneous” and Things and text-file-approaches support those tasks easily out of the box. And not every task that can be broken down into single steps needs a project. The task “pay electric bill” is enough for me to know that I have to get the bill and make the wire transfer.

Otherwise I use projects for the obvious: bigger tasks that have to be broken down to get an outcome.

I have two special projects that will never be closed. In Things I created Areas of Responsibility for them because of the way the side bar works. I just don’t want to see them right in the top of the projects.

Watch Later: For listening something later I use Huffduffer, for reading a text later I use Instapaper. For videos, web projects, software or other stuff I want to have a look at, when I am at my desktop I put a task into this project. So, when I have some free time, I just pull up this project and have a look here.

Shopping: I don’t need a special shopping list-app. After all, those are only lists and todo-apps are pretty good in maintaining lists. So, I use my todo-app for my shopping list. When we plan what we need from the supermarket, I am often at home and can input in on my computer which is faster than on the iPhone. It’s the best way for me to keep my shopping list up to date. Of course, when I want to get something from Amazon or the AppStore which I can’t or don’t want afford right now, it usually comes into this project, too.

Templates

There are some projects that I have to do again from time to time. The three most used templates by me are a template for paying doctor’s bills, since that takes several steps, a template for a new episode of the retrogaming-podcast I am part of and the last one is tidying up the apartment (which could also be recurring one). I just have an inactive project for those and have them in an are called templates. When I have to get one up and working, I duplicate it, move it to the appropriate area, make a bit of customization (bill number, episode name, things like that) and set them active if necessary depending of the GTD-tool I am using.

Getting Things Done

So, now everything is set up and I actually have to get things done. If I have an idea or in a discussion comes something up, I note it immediately down and excuse myself, that I have to do that for not forgetting it. After all, we don’t want to be rude and stare at our smartphones all day long ;)

Task Name

I read on several blogs that a task name should look like “Verb object”. That’s fine for English, but try that with other languages. In German that works only well with an imperative and I don’t like to have a commanding voice in my head. In addition there are many verbs that get split up, so one part goes before the object, another one after the object. So that doesn’t usually work. “Object Verb” works most of the time but actually I don’t need all the time a verb. And for my Shopping-list the item name is more than enough as is a URL for my Watch Later-list.
Therefore I write my tasks down like bulletpoints:

  • 1 lection Duolingo (that’s a very recommendable site for learning languages)
  • Read 1 Pomodoro (more about that later)
  • tooth paste

In combination with the area or even a project that already gives me enough context, that I know what to do.

Copy & Pasting

Quite often input comes from mails or social networks. When I have the possibility to use the OmniFocus Maildrop, I just forward the mail or the app.net-post to Maildrop and I am done. Usually I adjust the subject because that becomes the task.

When I am using a system that doesn’t have something available like Maildrop, I usually do the following:

  • the mail-body gets copied and posted into the notes-field of a task and I add a short todo as the task
  • I copy the text of an app.net/twitter-post and make that the task.

This works and is fast. And if it’s about mail, I usually have enough ways to find my mails in MailMate

Contexts and Tags

I think that contexts are an invention for people who have far more to do than they can handle. The clientele of David Allen which he is consulting. In OmniFocus I usually add a context because it is so fast and easy, in Things I feel like they discourage one from doing so the way input of tasks on the iPhone is set up. I have contexts that describe “locations”:

  • home
  • computer
  • phone
  • online (so doable on a computer, smartphone whatever as long as I am online)
  • mail
  • library
  • errands
  • waiting for

And only a tag like library has sub-contexts. I do not even have sub-contexts for Errands anymore except Amazon and AppStore to get an additional information for what device it is. But all in all it was too tedious to think about where I get something when entering the tasks. Also I am going for errands nearly every day, so I just go where I need to buy stuff. When I look at my errands, I usually know when I get some stuff at specific places. But for example tooth paste I get everywhere. It’s rare that I get something at only one place.

Waiting for is a special context which is reserved for the case that I have to wait onto some event to happen or on a person. Usually those tasks get also in the task-text a “Waiting for” and get either scheduled or a due date for following up, if nothing happened. I always set this context and never get sloppy with that one. The reason are that I can easier find them in my review and since I depend in that case on external factors, I have to be extra careful.

Tags are nice but in the end I am not using them. Things is so good in convincing me that I don’t need them, that I usually do not enter them and it still works.

I tried using those new contexts which are about energy levels and all but I never got them to work for me. They are a nice idea but looking at my today- and projects-list I usually know what I am capable to do and what not. And I actually don’t want to think about that beforehand when entering the task. For what reason? If the task is “solve complex math-problem”, I know that I am not able to do it at 10pm after I just had a training unit of karate that felt like two.

If my workload would suddenly quadruple, that would all change though I guess.

Start and Due times

Never set due dates or times when it is not absolutely necessary. But try to set start dates (or schedule tasks in Things) as often as possible. In my experience a lot of tasks can be done only starting from a certain date. When you set start dates, you can remove those tasks out of your sight until their time comes and you have to re-decide, if you can set another start date or if you really want to see those tasks every day. I even set start times because I know that I can’t do certain tasks before the afternoon because I am at work. That way they only pop up, when I am on my way home and check what I have to do after work.

Many people seem to set due dates because they expect that they do want to do a certain task at a certain date but in the end they won’t and just tons of tasks that are overdue pile up. Just set due dates when something bad happens when a task is not done latest on a certain date.

And then there are due times. Let’s say I want to do something to do, like getting something from the supermarket, I like to set me a due date for a certain time where I should be near one. The tasks becomes then overdue but I get reminded about it. I can remove the due date if necessary. There are apps that don’t support due times, only dates (I look at you Things). Then I have to use some other app to remind me. That adds a second inbox but it works somehow.

Today-list

In the morning I go through my tasks and have a look what I want and have to do today. Then I flag/star everything and off I go. There Things shines by the way in contrast to OmniFocus. The Next-list works for me far better than all the perspectives I tried and having all scheduled tasks turning up for review in the beginning of the day, makes it easier as well.

Pomodoros

I know that I need for some tasks concentration or that are ongoing and at least doing something for a certain time for a day brings me forward, even so I actually do not really want to do it. In those cases I use Pomodoros. If you have never heard of the concept, it is just a series of timers:

Do something for 25 minutes, take a 5 minute break, do something for 25 minutes etc. An interval of 25 minutes is called a pomodoro. After four pomodoros you get an extended break of 15 minutes. Sounds a bit strange but it works. Silence your phone and computer, switch off any instant messengers, mail programs or whatever, start your timer and begin doing it. Even if it is a long task, with those intervals you will fulfill them at some time, instead of never because you just procrastinate over it.

Reviews

Reviews are an important part that you can trust your system. I do right now a weekly review sundays and monthly review on the beginning of a month, but when my workload is huge I do a daily one. My weekly review is taken from Creating Flow with OmniFocus from Kourosh Dini. Even when you are not an OmniFocus-user this book might be interesting for you because he has a lot of interesting ideas how to set up workflows.

My weekly recurring project has the following tasks:

  • Get all inboxes to zero
  • Collect loose papers and materials
  • Empty your brain
  • Do a review (look through all your active projects)
  • Look at Someday (or look at all your inactive projects)
  • Review the Waiting for-context
  • Review previous calendar data (one week back for the weekly review, one month for the monthly)
  • Review future calendar data (again one week or one month)
  • Be creative (come up with new stuff, you want to do)

The monthly review is actually just an addition for setting up and reviewing my budgets and setting goals for the month, so what do I want to achieve this month.

A daily review just looks at a few projects, creates the above mentioned today-list on the evening before instead of the morning and has an additional look on future calendar data and waiting for-tasks to stay on top of everything.

As stated above: Reviews are important and in my opinion actually the most important part to keep your system a trusted system. Even if you are sloppy with entering your and checking off your tasks, the review still keeps the system trusted. OmniFocus helps with reviewing since you can tell it that you want to review projects at certain times like weekly, biweekly or even more seldom.

Conclusion

Now I wrote a lot about how I set up my system and how I enter and work through my tasks. In the end a short round up is in order.

  1. Trust your system
  2. Write everything down
  3. Rarely use due dates, often use start dates
  4. Create Pomodoros for large tasks you likely procrastinate on
  5. Do your reviews to keep on top

I guess that’s it. I hope this helps and gives you some inspiration. I am happy to answer questions in the comments.

Wenn ich mit meinem geschützten Account jemand ne Mention schreibt, der mit nicht folgt, kann er die dann lesen?

App.net: Sending PMs to people who can't receive them results in…nothing

Last weekend I sat together with @map and we noticed the following behavior on app.net: When you send someone a private message that has his privacy settings set in a way, that the person can’t receive a message from you, then well, nothing happens. For you it look likes that they received the message, but they won’t get it.

Except one of two things is happening:

  • they send you a private message
  • they change their setting to something that they can receive a private message from you and you send her a private message

In both cases they will see all private messages sent previously.

To understand that behavior I have to get a bit technical here and since I am not a developer, I hope that I do not mess up :)

Sending someone a private message creates something called a channel. Depending on the private message-settings of the user, you have the ability to subscribe her to this channel or not. If not, the channel will be created, it will look like you both are a member of that channel but in fact only you are (at least in my tests it seemed that way).

Now my question: Why doesn’t the sender get an error message? After all for the sender it will look like you are ignoring her and not as if you cannot get the message. Which can lead to real life social problems (like people thinking you are a prick).

From what I gathered my understanding what the reasoning on app.nets side is that:

  • the receiver could have a setting in place that he intentionally ignores you (like a mute)
  • clients could implement it, if they wanted

Do you see already the contradiction in that argumentation?

If not, I will explain it to you. You can check if you can subscribe a user to a channel (there’s a flag for it in the user details when you ask for it called “you_can_subscribe”). If the user has privacy settings in place that she can’t receive messages from you, the flag is set to false.

Now what happens, if a user has muted you but has her private messages set up in a way that she can receive private messages from all? Well, “you_can_subscribe” is set to true, but she won’t see your message.

Well, if a client implements a check wether you can send someone a private message or not, the client would as I understand it check for “you_can_subscribe”. When the person has appropriate privacy settings in place, the flag is set to false, if not it is to true, wether or not she is muting you. Thus people who intent to ignore you will still seem to ignore you.

And now again my question: Why the hell doesn’t get the sender an error message? As in an error from the API? Clients usually have already something implemented to show you error messages - they are not always look nice, but they can do it. But the check for it, is an extra step that has to be implemented. And since they can only implement it in a way an error message from the API could show it, the API could directly throw the error. That way, when it gets implemented even clients that are not getting updated often (I look at you Netbot) could have this feature immediately. Or am I seeing something wrong here? If yes, please correct me in the comments.

If you see it similar to me, that there should be an error message thrown by the API, please write the app.net-staff.

Best chances are probably to write support@app.net and writing directly to @dalton, @berg and @mthurman. The more who write them, that this is a problem, the better the chances that it gets corrected in the API. After all, it is a network where we are the customers and which thrives not only from good clients and happy developers but also from happy users. And I know already some unhappy users because of this.

Double-Dipping and the DIP

Yesterday the guys from Riposte released an update of one of their clients, which is fairly popular. Originally it cost $5, then went free and now they added an in-app-purchase for $5 for some additional “pro”-features.

Of course there were immediately some people that felt ripped off, it had a bit of bad taste for me but not for long and then there was also at several places a discussion about the Developer Incentive Program (henceforth DIP), too.

What is the DIP?

If you know what the DIP is, just jump to the paragraph after the next one. So, what is the DIP? Each month users of app.net get an e-mail from app.net to rate the usefulness of clients they used. If you are a subscriber to app.net your vote counts, if you are a user of a free tier, your vote is “just” important for the statistics. It was promised if I remember correctly that the developers will get at one point the feedback from those mails, thus the “free vote” is important here as well.

Developers can apply for their clients for the DIP and if they get accepted, any user who uses the client will get asked in the feedback-mail to rate that client. Then there is an unknown algorithm that weights the votes by the kind of API-calls the client does (specialized client or a client that does all you can think of) as far as I understood it and then developers will get a share of $30.000 (subject to change - with more users this amount will rise). That’s the DIP.

Some history

Now some recent history. Netbot got released by Tapbots and cost a certain amount of money. Everybody expected that they will be pretty succesful, since they are famous from their Twitter-client and many people still see app.net as a paid form of Twitter (which it isn’t). After some weeks they made Netbot free because sales dropped with the reasoning that they want to get more users to the platform, their client will help to do that and with more people using Netbot, they will get a bigger share of the DIP.

There was a big uproar in the community, and I have to say that I was also one of the people who didn’t like the move. After all a very popular client that will get guaranteed downloads from Twitter-switchers and it will be hard to get people use other clients. In addition Netbot makes app.net look like Twitter to them because they get the exact same experience as with Tweetbot. Therefore it might even hurt app.net.

But Netbot wasn’t the first client to be free. The first client on iOS for app.net was Rhino and that was free from the beginning. Another popular app.net-client called Rivr was free, too. It just offered an in-app purchase for push notifications. All the other clients cost money. But since they won’t attract users as easy as Netbot, it is in my opinion a bit of a different story.

After Netbot got free, Riposte, a very polished client that cost $5 got free. The reasoning was more or less: Netbot got free, our sales dropped, so we correlate that to Netbots gone free and to have a chance at all, we go free, too and hope for the DIP. Thank you all who paid, with that our push-servers are financed for quite some time.

Other clients went free as well, but none with the fanfare as Riposte (and hAppy went free and when some users complained that Felix still cost money while so many clients are free, Dominik Hauser, the Dev of hAppy began charging again for hAppy).

Double-Dipping?

Now Riposte released an update and added an IAP for $5 with some neat “Pro”-features. Naturally there were users who felt double-dipped. Others got Riposte for free and pay now $5 to get the features and they have paid after all $10 when they wanted the Pro-features. I had a bit of a bad taste in my mouth but then thought, well the first time I paid for it, I put some money in the pool for as all having push notifications with Riposte. That’s ok with me. Would be nicer if I got the features for free, but hey, it is their decision. And for people who use Riposte as their main client, then they probably use it on a daily basis. And $10 for a software I use daily is not a lot of money. Especially I have the feeling that people only feel that they get double-dipped because Riposte went in the meantime free and others get the whole package for $5 instead of $10 and so feel treated unfairly. But to be honest, how should the developers handle it? They can get their client out for free and if you really like the client, you can upgrade it. I don’t see how they could check when you bought the app, a separate app is not good, either etc. So, don’t feel double-dipped. If you don’t like it, don’t pay for it. If you think other clients are more feature-rich than use those. So why oh why all the time whining?

I think Riposte Pro looks interesting but it’s a bit hard to justify for me the payment since I have so many clients. But the features look very interesting. And it is the first time for a long time that a client could convince me to move from Felix for my day to day usage to it.

DIP - Pain or Gain?

But what about the DIP? In the Patter-room German there was a short discussion again about the DIP if it is an incentive for devs or if it hurts the platform, since it prevents further development. And now I have to come back to Netbot and Riposte going free.

One of my two majors in university is political economics (which I already finished) and there we talk a lot about incentives. The aim of an incentive is to steer people in a certain direction. The aim of the DIP, as I understand it is to steer the developers to continue to enhance their clients and try some other concepts as well. Since when they do good, they not only get a lot of usage of their apps, but also get continually money from the DIP. Since app.net determines the weighing regarding the API-usage, they could even steer developers into certain directions to develop certain clients. For example if they would be transparent in how their algorithm works, and they say now: Clients that only do a few specialized API-calls get weighted triple in comparison to a client that tries to do everything, it incentivices developers to develop specialized clients instead of a swiss army knife. If they would say API-calls for showing the stream of a users without any filters will loose some weightening, it could steer developers into a direction to not develop further clients that expose the microblogging-part of app.net.

But all that will only work, when app.net is transparent regarding their weighing. Otherwise it is just a bonus to development.

The next question is, wether only non-free clients should be included in the DIP. After all it seems that there are clients that can make some kind of a living just from the DIP. And since they are free, they have a bigger chance of broadening their usage and therefore broadening their share from the DIP. In addition they drive the prices down for other developers, since people will expect that clients are free or at least very very cheap (as in not more than 1 or 2 bucks).

I can understand that reasoning but at the same time those clients loose out on sales. When the free tier got released, I really wondered how much money Netbot could have made, if it wouldn’t have been free. Loads of the newcomers went probably straight to Netbot and would have gone there also if it wouldn’t have been free.

In addition it makes things really complicated. What do you do with clients that do some kind of promotion and go free for a day? Should they be removed from the DIP forever? What about clients that cost only $1 instead of 5? It would make the whole concept so complicated that no one could really handle it. So, I think free clients should be in the DIP as well.

Does it hinder clients from getting developed further? Well, there is the case of Netbot, which is a clone of Tweetbot with some small updates and which doesn’t get a love for some time now. It is still pretty popular. So, they might still get money from the DIP. But as long as income is not high enough to justify further development, it is a move I can fully understand from Tapbots to just let it sit there. Why should they put in more development time, if it is just too expensive because income is so low? I don’t say that I like it, but I can understand them. And the longer Netbot doesn’t get updated, the more users will search for alternatives. And over time the DIP-share will decrease. And at some point Tapbots will make their mind up wether there is enough money in the app.net-client-market or not. And it doesn’t cost them any money to have Netbot sitting there in the AppStore.

So usually you get money from your sales and with app.net you get a bonus because of the DIP. The better your client, the more money you get. And since the number of users for app.net is relatively small, it is not a lot of money you can get from sales. We have now ca. 90k users. Let’s say all use iOS and buy a client for $5 from the AppStore. Then it is $450.000 what you would make. That is actually not a lot, when I think about what it means to work full-time on a client. So the DIP adds the extra that could mean that your succesful client in the small market gets further developed, even so sales will be low because of the market size. If a government would do it, we would call it a subsidy. The effect of subsidies is that they distort the market. In terms of app.net this means that it distort the market in a way that clients get developed or continued to be developed, that wouldn’t have been developed in the first place or would stopped being developed because feeding your family is actually more important and so you would rather work on another project.

In addition it works as a signal (yep, signalling-theory is nice, too ;)) for developers that app.net cares about developers. They do not pay them to develop for their platform. That would send another signal. Microsoft is doing that as far as I know for Windows Phone. That signal would say, hey, we need desperately clients, so we pay you for doing it.

No, they give you a bonus, an incentive to develop for the platform. You still have to make something on your own that is succesful to get your share of the pie. It shows that they care enough to give out some of the subscription money to the developers. And this is probably far more cost-effective than paying directly.

Henceforth I guess in terms of signalling it is a very good thing that it exists. So it might also be called the Developers Signalling Program. But if they would make the weighing of the algorithm public, it could also be a powerful mechanism to steer development of certain types of clients. But my gut feeling tells me that people wouldn’t like it, when app.net started to directly influence which type of clients people develop with the DIP. So they are probably better off in not doing it in a transparent way.

Short reviews of app.net-clients

Today I created a bunch of app.net posts for short reviews of app.net-clients. All reviews have a max size of 256-characters. I hope you enjoy them. You can find a client that suites your needs on ADNCC which enables you to select features and operating systems to give you all clients that match the selected values.

Now for some short reviews for several clients. FYI the clients on my homescreen are Felix, hAppy, Patter and Sprinter. Have a look at http://adncc.nigma.de by @chemiker based on the client feature matrix by me to find a client that suites your needs.

Alphred: A workflow for Alfred2, the popular launcher on OS X. It allows to send a post or a pm right from Alfred incl. link entities. One of my favorite ways to do a post or reply to a private message from my main account.

Chapper: The only client I use on Win7. Support for Patter included. Feels cramped but in an upcoming update is theming support which enables me to set it up in a comfortable way. Good,could be better, previews from the upcoming update look very promising.

Chimp: Feature-rich, even with support for public Patter-rooms and it has push. An interesting UI-concept, which you might know from Path. Lots of information on the posts & can feel a bit cramped. Feels a bit slow. Nice client with a lot of potential.

Climber: The point & take a short video of app.net. 11 seconds have to be enough. Clean and fast interface, also support for the Places-API to set your location. Don’t forget to set the #Climber-hashtag.

Felix: Feature-rich and a good experience with a full-screen mode. Now also with support for multiple accounts and a dark theme. Has a clever implementation of link entities. To top it off it gets all the time updates. I use it all the time.

hAppy: Probably the feature-richest client. Sadly no push. Multiple account-support, link entities, a dark theme and the best client when your connection is slow. Also Complete Patter-support. Could I install only 1 client on my iPhone, this would be it.

Kiwi: A good client for Mac OS X. The only OS X-client with support for private messages. Regrettably no support for link entities or multiple accounts. My main client on OS X.

Netbot (iPhone / iPad): Feature-rich and some clever ideas, especially its support for “repost from” when you want to repost a post from another account. There’s also a good search. It has push, but not for PMs. Looks exactly like Tweetbot. For experiencing app.net like Twitter that might be the client of you choice.

Patter: The cleanest experience for chatting in Patter-channels. It supports PM and all features of Patter, incl. broadcasting. Otherwise features are missing like push or copying URLs etc but those are in development. Just for chatting it is great.

Riposte: A clean interface, with a good UI streamlined to be used with only one hand. Push, multiple accounts, dark theme, pictures are shown completely inline and it is really fast. Regrettably it has no support for link entities. But it is free.

Sail: A client that allows me to send a post fast on OS X with link entities to any of my accounts. Just a window, write a post, select your account, send. That’s it. Clean and quick.

Screenfeeder: Have several social feeds? Having your iPhone or iPad lying next to you or somewhere very present? Screenfeeder will show those feeds post by post to you. Your own neatly designed app.net-wall so to say.

Spoonbill: One of the first clients for the iPhone. The only client that supports an alternative but real threading-view for threads. Just for that it is worth a look. Featurewise there is not so much to say and feels a bit overdesigned.

Sprinter: The point & shoot of app.net. Open the app, make a photo, apply a filter, write your post, don’t forget to add the #Sprinter-hashtag, add a location based on the Places-API and send it out. Clean & fast. But it feels like something is missing.

Stream: Stream is clean and looks very polished, reminds me a bit on the old Tweetie for the iPhone. It has push, no link entities, no support for private messages. Needs to work on its features and could become a very good client.

Wedge: A good client for OS X that I use for my secondary account. Unfortunately no private messages but a nice interactions-view. Sadly it seems that it is not in development anymore. It was the first real good client for OS X.