Mit Facebook-Infografiken könnte man inzwischen sicher mehr als nur ein Buch füllen. Heute wollen wir noch eine Weitere hinzufügen, die wir aber im Gegensatz zu viele anderen Grafiken als wichtig empfinden. Denn es geht um eure Privatsphäre auf Facebook und wie ihr mit dem Start der Graph Search noch mehr auf diese achten solltet.
Natürlich rufen wir nicht dazu auf, in Zukunft alle Posts auf “Privat” zu setzen, sondern vielmehr geht es darum, bei jedem Post bewusst zu überlegen, wer diesen sehen soll und auch darf.
Da Michael Kamleitner bereits auf der Developer Conference in Berlin einen großartigen Vortrag abgeliefert hat, wussten wir ja ,was auf uns zu kommt. Auch wenn der Titel es anders vermuten lies verabschiedete sich Michael keineswegs vom Gewinnspiel-Tab, er wagte viel mehr einen Neuanfang und zeigte an konkreten Beispielen, wie Promotions und Gewinnspiele auf Facebook viel besser funktionieren können. Im Zentrum stand dabei natürlich der Open Graph mit seinen vielen Möglichkeiten für Unternehmen. Wer den spannenden Vortrag verpasst hat, kann sich an dieser Stelle nochmals die Folien ansehen: (weiterlesen …)
Unmittelbar nach der Veröffentlichung der “New Graph Search” Beta im Januar dieses Jahres kam es zu einer Reihe an Spekulationen über eine entsprechende Entwickler-Schnittstelle (API / Application programming interface). Nach den Vorstellungen oder Wünschen der Marketing Industrie, sollte die neue API 1:1 den Funktionen der neuen Graph Search, wie sie dem (Beta) Nutzer zur Verfügung steht, ebenbürtig sein. Um den wichtigsten Punkt hierfür vorwegzunehmen: Dato existiert weder eine “New Graph Search API” in diesem Umfang, noch wird es selbige jemals geben.
Dennoch: In einer abgewandelten Form wird es eine New Graph Search API geben. Wesentliche Details hierzu wurden uns bei der Mobile DevCon in New York – mehr oder weniger exklusiv – von Facebook mitgeteilt.
Der Status Quo
Momentan befindet sich Facebook in einer Konzeptphase, wie die neuen Technologien für Entwickler (bzw. Drittanbieter) zugänglich gemacht werden soll. Die Technik ist vorhanden, man hat genügend Zeit, um das Produkt zu gestalten. Dabei spielen unterschiedliche Stakeholder eine Rolle: Die Privatsphäre der Nutzer, Facebooks Marktmacht sowie der Wille die Plattform für Entwickler zu öffnen, sodass diese eigene, kreative Anwendungen auf Basis der API entwickeln können. (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.
Zusammen mit euch machen wir Facebook etwas schlanker und wieder besser nutzbar. Dazu haben wir drei kleine Minifolgen im Programm: Facebook Pages, Facebook Apps und Facebook Freunde.
Heute kümmern wir uns als Allererstes um die Facebook Pages. Denn in den letzten Monaten hat sich da sicher wieder einiges angesammelt. Vieles davon einfach nur, weil man bei dem Gewinnspiel unbedingt ein iPhone oder eine Reise gewinnen wollte und dann vergessen hat, die Seite wieder zu “entliken”.
Win-Win-Fail Situation
Bei den Facebook Pages aufzuräumen ist eine Win-Win-Fail Situation: (weiterlesen …)
