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.

Zwiegespalten: Twitter und Appdotnet

Seit ein paar Wochen versuche ich mit zwei sozialen Netzwerken umzugehen: Twitter und Appdotnet.

Wie Twitter mit den Entwicklern umgeht, finde ich einfach nur schlimm. Das Twitter anscheinend inzwischen von BWLern beherrscht wird und man sich in Profitmaximierung versucht auf Kosten der Nutzer finde ich auch einfach nur schlimm. Dazu kommt, dass Twitter seinen eigenen Desktop-Client aufgibt und ggf. in einem Update der API-Guidelines Desktop-Clients verbietet. Meiner Meinung nach ist Twitter einfach unberechenbar geworden, auch wenn sie die Änderungen schon vor einem Jahr ankündigten.

Und dann gibt es jetzt auch Appdotnet (ADN). Für ADN zahlt man aktuell pro Jahr $50 und dafür wird es wohl werbefrei eine Plattform für soziale Netzwerke geben. Es entwickelt sich technisch sehr schnell, bei der Anzahl der Benutzer macht es allerdings einen anderen Eindruck. Aktuell fühlt sich ADN wie Twitter in einem frühem Stadium an aufgrund der geringen Nutzerzahlen. 

Inzwischen ist es featuremäßig bei Twitter angekommen. Seit kurzem gibt es auch Favs (Stars) und native Retweets (Reposts). Es gibt aktuell keine Listen, dafür 256 Zeichen zum Vertippen. Sieht alles ähnlich aus, nur hat es generische Namen und damit weniger Charme. Clients gibt es noch nicht viele, aber es befinden sich so einige in Entwicklung und ich bin mit meiner aktuellen Wahl (Appetizer unter OS X und Spoonbill unter iOS) recht zufrieden, auch wenn zumindest Spoonbill noch nicht alle ADN-Features unterstützt.

Technisch hat es den Nachteil, dass es nirgends integriert ist es wie Twitter. Weder in Instapaper, noch in Reeder und ganz böse und das wird vermutlich nie kommen: direkt in iOS oder OS X.

Was stört sind aktuell immer noch die fehlenden bzw. die nicht-postenden Nutzer. Nicht jeder mag sich $50 für ein soziales Netzwerk leisten, Twitter geht ja auch noch gut genug und sehr viele sind da. Andere haben zwar einen ADN-Account, posten da aber nichts. Gleichzeitig sind Crossposts, sprich Posts von Twitter nach ADN weiterleiten oder umgekehrt, von vielen aus unterschiedlichen Gründen verpönt (wer beides richtig liest, bekommt doppelten Content; RTs sind über Accounts, die es nicht gibt oder die falschen sind etc). Damit könnte ADN sich aber zumindest bootstrappen. Wenn die Leute, die bei beiden SNs einen Account haben, aber aktuell nur Twitter nutzen, zumindest ihre Posts weiterleiten, könnte man ADN nutzen und zumindest die Posts derer trotzdem nicht verpassen. Ich hab’s versucht in die eine und in die andere Richtung. Auf ADN ist es weniger verpönt als auf Twitter, aber glücklich macht beides nicht.

Ich selbst habe versucht die letzten Tage sehr wenig Zeit und hauptsächlich Zeit mit ADN zu verbringen und dabei so einiges erstmal für mich aufgesetzt. Eine IFTTT-Regel, die alle Links von Twitter nach Pinboard umlenkt, damit ich die gesammelten Links habe, da ich inzwischen für mich meine Timeline recht gut zusammengestellt habe. Dann eine IFTTT-Regel für einen ungenutzten Zweitaccount auf Twitter ohne nennenswerte Followerschaft, um cross zu posten, um die Twitterintegration von Programmen/Betriebssystemen zu nutzen. Und retweeten versuche ich auf Twitter zu vermeiden, sondern verlinke hier auf dem Blog interessante Links, wie in einem Linkblog und poste das dann zu beiden SNs, da mein Blog anscheinend, nahezu gar nicht über RSS-Feeds gelesen wird. Macht allerdings auch mehr Arbeit. Damit lässt sich aber irgendwie leben. In meinem ADN-Stream geht auch schon ein wenig was.

Allerdings musste ich feststellen, dass mir ganz viel Content von Leuten fehlt, die ich auf Twitter gerne lese. Spontan fallen mir da z.B. @map, @no_vem_ber, @mrtoto, @nsemak, @jakeadelstein, @hirokotabuchi und noch eine ganze Reihe anderer ein (wehe, es fühlt sich jemand beleidigt an, weil ich sie oder ihn nicht genannt habe…aber die Liste ist zu lang). Teils haben die genannten Accounts, posten aber nichts auf ADN, teils haben sie keinen und werden sich vermutlich auch nie einen zulegen. Und das macht halt entweder Twitter oder ADN einfach zu einer weiteren Inbox mit anderen Leuten. Da Crossposts verpönt sind, muss man sich auch irgendwie entscheiden für welches Publikum man schreibt (meine Blogposts gehen in beide SNs). Ehrlich gesagt, läuft das bei mir darauf hinaus, dass ich an einem Tag entweder nur auf Twitter oder nur auf ADN schreibe. Ich hatte schon ein Problem damit Facebook und Twitter gleichzeitig zu nutzen, als ich noch Facebook versuchte aktiv zu nutzen und da hatte ich wirklich unterschiedliche „Follower“.

Aktuell führt es dazu, dass ich mich „schlecht“ fühle, wenn ich Twitter benutze, da ich eigentlich Twitter verlassen will für den ganzen Mist den sie verzapfen. Das Gejammer über Twitter bringt halt nichts, wenn man es weiter benutzt. Bei mehreren Hundert Millionen Nutzern ist das Twitter egal und wenn die Alpha-Nerds zu was anderem ziehen, ist ihnen das auch egal, so lange nicht alle Nutzer wegziehen. Die Alpha-Nerds sind auch die, die sich über Werbung aufregen, aber Werber zahlen vermutlich mehr, als die Nutzer bereit wären zu zahlen. Und für Twitter zählt aktuell anscheinend Profitmaximierung und nicht glückliche Nutzer. So lang sie es auf dem Level halten, dass die Nutzer Twitter gerade nicht verlassen, ist alles schön für Twitter. Und die meisten sind ziemlich schmerzbefreit, wenn man sich überlegt wie viele Leute Facebook benutzen (keine wirklichen 3rd-Party-Apps, kein Desktop-Client, Privacy ist ein Fremdwort und Spammen durch Freunde ist eingebaut).

Gleichzeitig will ich ADN benutzen, weiß aber, dass ich eigentlich noch Twitter lesen muss, um alles mitzubekommen, was ich mitbekommen will. Das nervt. Kolossal. Vermutlich bin ich der einzige dem es so geht, aber es stört mich massiv. Was nun also tun? Twitter-Account verkümmern lassen, ab und zu reingucken und irgendwann heißt’s „Aus den Augen aus dem Sinn“, noch mehr der knappen Zeit in das Lesen von zwei SNs und Posts reinkippen oder ADN ADN sein lassen und wie so viele andere warten, dass es was wird? Aber wenn zu viele so denken, dann wird das mit ADN nie etwas. ADN ist erst ein paar Wochen alt, aber gefühlt tut sich nach dem Anfangshype zumindest nutzertechnisch nicht viel. Um genau zu sein viel zu wenig. Die Unique Users waren heute 939 (als ich diesen Post schrieb), vor ein paar Tagen waren es ca. 1500. Das ist a) so gut wie gar nichts und b) scheint sich das nicht zu steigern. Kurz: Mit ADN ist das irgendwie alles blöd und das Momentum scheint trotz Clients in Entwicklung abzunehmen. Clients sind halt nicht alles.

Manno, ich find das alles doof und verschwende eigentlich viel zu viele Gedanken auf sowas wie die Entwicklung von sozialen Netzwerken… >_<