Google's OpenSocial

OpenSocial ist eine Menge von Programmierschnittstellen für Anwendungen in webbasierten sozialen Netzwerken. OpenSocial wird von Google entwickelt und wurde am 1. November 2007 veröffentlicht. (Quelle: Wikipedia-OpenSocial)

Stichworte zum Bauen von Social Applications

• Gadgets bestehen hauptsächlich aus HTML und JavaScript.
  
• API Namensräume (Javascript) sind opensocial.* und gadgets.*
• Als Views gibt es in der Klasse gadgets.views.ViewType: Profile View, Canvas View und Home View.
• Datenhandling/Persistenz findet über opensocial.DataRequest statt. Hierzu zählt auch der Zugriff auf Personen, Beziehungen, Aktivitäten und Nachrichten.
• Der soziale Graph ist über opensocial.Person erreichbar. Rollen werden in VIEWER und OWNER unterschieden.
• Aktivitäten: opensocial.Activity. Activity Templates können hierbei häufige Updates kumulieren.
• Nachrichtenversand: opensocial.Message
• Internationalisierung über Message Bundles in der XML-Spezifikation des Gadgets möglich.
• Backend Requests, die über die Möglichkeiten von JavaScript und HTML hinausgehen sollen, können mit gadgets.io.makeRequest() abgesetzt werden. Somit ist der Transfer von HTML-, XML-, JSON- und ATOM-Files möglich. -> JSON, XML und AtomPub können auch über die RESTful API genutzt werden, die neben der JavaScript API existiert.

Quelle: OpenSocial Artikel von Matthias Häsel und Karsten Rieke - http://www.springerlink.com/content/d7624423x371w5v6/

Weitere Infos
Host OpenSocial Apps basierend auf Java oder PHP: Apache Shindig
Let's get this Shindig started

XING und OpenSocial:
XING and OpenSocial

Related articles by Zemanta

• What is Shindig? (jroller.com)
• Google Friend Connect API Available in Labs (google-code-updates.blogspot.com)
• Google Friend Connect Launches API (searchenginewatch.com)
• Developing for LinkedIn's Application Platform (slideshare.net)

7 Regeln der Usability

FlashCamp Berlin
aus Vortrag von Ron Hofer: User Experience & Fireflow

Für positive User Experience (UX) sind unter anderem folgende 7 Regeln der Usability notwendig:

1. Aufgabenangemessenheit (Musikwahl bei einer elektrischen Zahnbürste sprengt den Rahmen und ist daher zu vermeiden)
2. Selbstbeschreibungsfähigkeit (Dieser Punkt beschreibt sich von selbst)
3. Erwartungskonformität (Eine Fahrstuhltür öffnet sich wieder, wenn ich mich dazwischen stelle.)
4. Fehlertoleranz (Ein fehlertolerantes System schlägt mir automatisch on-the-fly z.B. einen freien Benutzername vor, wenn der gewählte bereits vergeben ist. Gutes Bsp. Twitter-Anmeldung)
5. Steuerbarkeit ("Der Nutzer gibt den Takt an!" Mentales Modell des Nutzers darf nicht gebrochen werden.)
6. Lernförderlichkeit (Neue Nutzer sind Anfänger des Systems und werden bei der Benutzung immer mehr zu Experten.)
7. Individualisierbarkeit

UX bedeutet: Was brauche ich? + Was WILL ich?
Die Erwartungen, die an ein Produkt gestellt werden, steigen über die Zeit vom ersten Kontakt (z.B. Werbung) über den Kauf und der Nutzungszeit. Die UX muss ÜBER der Erwartung liegen, um mit dem Produkt zufrieden zu sein. Das heißt im Umkehrschluss, dass das System so eingerichtet sein muss, dass die Zufriedenheit mit der Benutzungsdauer steigen kann!

• Generelles Problem bei Systemen: Je flexibler ein System ist, um so schlechter ist die Usability.
• 20% der Funktionen können 80% der Aufgaben erledigen, die restlichen 80% kann man z.B. in Menüs "verstecken".

Akzeptanz/Nutzen von neuen Funktionen lassen sich gut wie folgt testen:

• Die Feature werden in Form von "Produkten" abgebildet. Jedes Feature entspricht einem Produkt. Der virtuelle Preis ergibt sich aus dem Umsetzungsaufwand der Funktion.
• Testpersonen bekommen eine begrenzte Menge an virtuellem Geld und können damit einige der "Produkte" kaufen.
• Die meistgekauften Produkte sind die Feature, die man für die ausgewählte Zielgruppe umsetzen sollte.
  

Tom Allison: Human side of Human-Computer Interaction

Flash Camp Berlin 2009

Vortrag von Tom Allison: Human side of Human-Computer Interaction

Emphasizing the Human Side in Human Computer Interaction (HCI)

• Sensemaking (->"Sinnerzeugung" Anm.: eher "Sinnergebung" ?) in a complex ...
• "Make mistakes faster!"
• HTA: High Tech Anthropologist (TM) + Target Persona Experience + Co-Location + Paired Work (Anm.: Pair Programming as Knowledge Transfer. co-location might work in case of pair programming.)
• Development itterations on a weekly base. (but: Analysis in this week is deployed in the next week.)
• Building project focus via Target Personas (all CEOs, HTAs and Project Manager in)  -> is a "red ink" process with following three steps:

1. Story Cards: each employee writes story cards, above mentioned persons are decide what, when, who does it.
2. SoftControl
3. Green Dot: HTA can set a project as done with a green dot. Red dot means: project stucks (e.g. missing server)
   

Slides can be found online.

Thomas Reppa: PureMVC - Introduction + Best Practise

Image via Wikipedia

Flash Camp Berlin 2009
Vortrag von Thomas Reppa: PureMVC - Introduction + Best Practise


PureMVC ist ein leichtgewichtiges Framework um MVC Anwendungen in sehr modularer Weise zu erstellen.

• PureMVC ist eher ein Regelwerk
• PureMVC ist sprachenunabhängig (impl. in vielen Sprachen vorhanden)
• Man programmiert Inseln, die man anschließend zusammenfügt.
• PureMVC ist Kommunikationsschnittstelle zwischen Views und Models.
• „Code in the Speed of Thought.“

Meine Gedanken:
PureMVC ist ein vielversprechender Ansatz. Allerdings konnte mich der Vortrag leider noch nicht überzeugen, ob in großen (also richtig großen) Projekten das Problem der verwirrenden Verbindungen zwischen Views und Models hiermit zufriedenstellend gelöst werden kann, da nur kleine Beispiele in dem Rahmen gezeigt werden konnten.

Jede Bedingung eröffnet Möglichkeiten

Heute habe ich einen lustigen Ausschnitt in: "Wenn das Meer zu Besuch kommt", von Alexander Frater gelesen. In dem Artikel geht es um den Monsun:

"In der Warden Road gibt es eine Senke, in der während der Regenzeit das Wasser bis zu einem Meter tief steht. Die Kinder in der Gegend bauen in der Mitte einen Sockel, auf den sich eines von ihnen stellen muss. Autofahrer sehen dann ein Kind, dem das Wasser nur bis zu den Knöcheln reicht, und fahren ungebremst durch die Senke. Wenn dann der Motor abstirbt, tauchen Freunde des Kindes auf und verlangen ein Vermögen dafür, dass sie das Auto aus dem Wasser schieben."

--mare No.74 Juni/Juli 2009

Besonders lustig finde ich nicht nur die Idee, mit der die Kinder die Autofahrer übers Ohr hauen, sondern -- zumindest erscheint die Beschreibung in dem Artikel so -- die Tatsache, dass es als das Normalste der Welt erscheint, wenn Kinder als "Spitzbuben" den Erwachsenen einen Streich spielen (der in meinen Augen nicht ohne ist), und anscheinend mit einer Natürlichkeit toleriert wird, dass man selbst dort gerne als Kind einer dieser "Spitzbuben" wäre.