Gründer und Geschäftsführer der buddybrand GmbH, dort verantwortlich für Entwicklung und Technologien.
Als Agentur für Markenführung in Social Media kann buddybrand auf 2 Jahre Erfahrung in der Kreation und Umsetzung von digitalen Freundschaftsstrategien zurückgreifen. Internationale Kunden wie z.B. ŠKODA AUTO a.s. werden bei der Strategieentwicklung und Umsetzung von integrierten Social Media Kampagnen unterstützt.
Der Cloudservice Parse hat vor kurzem den Besitzer gewechselt und wurde von Facebook gekauft. Bei Parse handelt es sich um einen Service, der einem mobilen App-Entwickler die lästigen aber notwendigen Aufgaben abnimmt, welche mit der Netz-Infrastruktur zusammenhängen bzw. eben eine solche benötigen. Dies beginnt beim simplen Speichern von Daten bis hin zum Handling der Push-Notifications. Alles in allem sollen App-Entwickler sich nur noch auf den eigentlichen Kern fokussieren. Alles andere erledigt sich mit einem API-Aufruf, ohne dass man Infrastruktur bereitstellen oder, noch viel wichtiger, ohne, dass Infrastruktur skaliert werden muss.
Parse unterstützt Anwendungen für OSX, iOS, Android und .NET. Für den Rest steht auch noch ein Javascript-SDK und eine REST-API bereit. Im Folgenden eine kurze Zusammenfassung der Dienste, die Parse bereitstellt: (weiterlesen …)
Open Graph Objekte benötigten bisher immer eine im Web hinterlegte URL als “physische” Manifestation. Der Open Graph durchzieht die unendlichen Weiten des Netzes mittels seiner Meta-Tags. Das war ein Problem für einige native Apps, die eben genau nicht im Web stattfinden. Viele native Apps sind nur bessere Zugänge zu den jeweiligen Webservices und haben ohnehin eine Repräsentation im Netz – aber eben nicht alle. Für diese gibt es nun eine Lösung, denn ab sofort können Open Graph Objekte auch direkt bei Facebook erstellt und gehosted werden. Ein interessanter Paradigmen-Shift, um nativen Apps entgegen zu kommen.
Mit dem Object Browser gibt es zum schnellen prototypisieren das entsprechende Tool. Ähnlich wie im Graph API Explorer werden die Aktionen gleich im Kontext der eigenen Anwendung und mit dem richtigen Access Token ausgeführt. Die Objekte können maschinell über die neue Object API angelegt werden. Die Object API kann mit der Achievements API verglichen werden. Es werden Objekte mit entsprechenden Eigenschaften erstellt und anschließend per eindeutiger ID ausgelöst, wenn die entsprechende Aktion eingetreten ist.
Mit der ID kann das Objekt wie gewohnt über die Graph API veröffentlicht werden. Aber eben mit der Objekt-ID anstelle der URL.
Das Ergebnis ist nun von außen nicht zu unterscheiden. Mit der einzigen Ausnahme, dass jetzt sehr einfach im Object Browser nachträglich die Eigenschaften, z.b. URL oder Titel, geändert werden können.
Die Objekte können im Kontext eines Nutzers oder im Kontext der Anwendung erstellt werden. Der Unterschied:
Objekte im Kontext der Anwendung sind global verfügbar.
Objekte im Kontext eines Nutzers haben die Privatsphäre, die der Nutzer für die Anwendung definiert hat.
Neben der eigenen Anwendung kann im Object Browser auch der Nutzer, in dessen Kontext die Objekte erstellt werden sollen, ausgewählt werden.
Fazit:
Es kann begrüßt werden, dass immer mehr Daten direkt bei Facebook liegen. Ein Umzug der Domain ist weniger ein Problem, wenn Facebook nur noch eine ID anstelle einer URL speichert. Vermutlich ergibt sich auch durch besseres Caching ein Vorteil.
Allerdings wird damit auch ein Teil der Infrastruktur an Facebook ausgelagert. Datenschützer könnten dies kritisch sehen. Allerdings kann dadurch noch schneller, noch simpler, und noch mobiler entwickelt werden. Und schlussendlich ist es ja optional – nur ein Angebot an Entwickler nativer Anwendungen für eine noch bessere Integration der Plattform.
Heimlich, still und leise hat Facebook den Developern ein Settings-Menü eingerichtet. Den Zugang gibt es über http://developers.facebook.com/ oben rechts.
Der Inhalt gliedert sich grob in Developer Settings und Company Settings. Es ist nicht unbedingt ein verifizierter Entwickler-Account notwendig, um darauf zuzugreifen.
Facebook hat ein neues Feature gelaunched: Apps und Spiele können in Zukunft Gruppen erstellen!
Es scheint, als wäre das Feature in erster Linie gelaunched worden um Clans oder Spielegemeinschaften zu organisieren. Deshalb wird hier auch in erster Linie die Rede von Spielen sein.
Erstellt ein Spiel eine Game Group, wird auch gleichzeitig eine “normale” Facebook Gruppe erstellt. Die Policies besagen, dass das dem Erstellenden auch transparent im Interface des Spieles dargestellt werden muss. Ebenso muss bei einem Beitritt dies dem Beitretenden im Nutzerinterface dargestellt werden, dass er damit auch einer Facebook Gruppe beitritt. Einladungen finden programmatisch im Hintergrund via der Graph API statt.
Ingame-Content in einer Game Group. (Quelle: Facebook)
Facebook will, dass der auf Facebook geteilte Content in Zukunft qualitativ hochwertiger wird, denn nur dieser verbreitet sich auf Facebook weiter.
Da sich der Faktor Mensch in der Auswahl der geteilten Nachrichten aber nur schwer einschränken lässt, geht das Netzwerk jetzt einen anderen Weg und beginnt erst einmal den Entwicklern Regeln mitzugeben, wie qualitativ hochwertiger Content aussieht und was in Zukunft nicht mehr erlaubt und möglich ist.
Dazu hat Facebook heute Nacht eine entsprechende Ankündigung im Entwickler Blog gemacht. Die geplanten Änderungen werden in 90 Tagen umgesetzt.
Klaus erklärt im folgenden Gastbeitrag detailiert worum es sich bei den Änderungen handelt und wie diese sich auf den Newsstream jedes einzelnen Nutzers auswirken werden.
builtin vs. custom
Um nicht für Verwirrung zu sorgen, vorab eine kleine Begriffsklärung: Generell wird bei Aktionen im Open Graph zwischen den von Facebook angebotenen builtin-Actions und den selbst von Anwendungen definierten Aktionen, den custom-Actions unterschieden. Die builtin-Actions kennt man wahrscheinlich von allen “großen” wie z.b. Spotify oder dem Washington Post Social Reader benutzt. Von den builtin-Actions gibt es momentan fünf verschiedene: like, follow, read, watch und listen.
Fokus auf hochwertige Open Graph Actions
Drei der eingebauten Open Graph Actions (read, listen, watch) werden beim konsumieren von Inhalten ausgelöst. Und bei diesen drei soll es dafür auch bleiben: Jegliche andere custom-Action, die ausgelöst wird, wenn der Nutzer Inhalte irgend einer Art konsumiert, wird abgeschalten. Wenn ein Online-Shop z.b. jedes von einem Nutzer aufgerufene Produkt mit einer Aktion ala “Klaus hat angesehen..” in den Open Graph geschrieben hat, soll dies mit der Änderung in Zukunft nicht mehr möglich sein.
