...
(funktional, Szenario)
- Ziel: Informationen / Signale aussenden, die bei (menschlichen) Empfängern eine Verbesserung der Handlungsfähigkeit auslösen / den handlungsrelevanten Informationsstand bei den Empfängern erhöhen - d.h. proaktiv, wartet nicht auf Anfrage
- Empfänger suchen diese Signale nicht explizit, sondern nehmen sie erst mal peripher und dann vielleicht bewusst war und interagieren vielleicht am Ende noch mit dem Gerät (ohne aber etwas bestimmtes zu suchen) - d.h. Entdecken anstelle von Suchen, kein Kiosk, d.h. Aufmerksamkeit muss erregt werden, Walk-Up-And-Use, Joy-of-Use, ...
- Es ist schon möglich, dass Empfänger den Informationsstrahler gezielt aufsuchen - aber nicht, dass sie auf / mit dem Informationsstrahler vorher festgelegte Fragen beantworten
- die Nutzung ist normalerweise nur kurz
- gleichzeitige Nutzung durch mehrere Nutzer möglich / wahrscheinlich; dabei verschiedene Typen der Nutzung in verschiedenen Interaktionszonen (Entfernungen vom Informationsstrahler)
Schaffung von Gewahrsein / Awareness - zu Personen und was die machen (INFMirror), zu Aktivitätsmöglichkeiten (UrbanLife+), ...
Grundstruktur
Wandbildschirm
- interaktiv (siehe unten)
- groß O(1m) -> dadurch Multi-User-fähig (in verschiedenen Interaktionszonen aber auch in derselben)
Darstellung der Signale / Information
- hauptsächlich visuelle Ausgabe (auf dem Wandbildschirm)
- akustische Signale eventuell zur Ergänzung (Ton von Videos, …)
Interaktionsmöglichkeit
- nicht um gezielt etwas zu suchen, sondern um
- noch mehr Ungesuchtes zu entdecken
- um entdeckte Information zu vertiefen
- primär über Touch-Interaktion
- eventuell auch Embodied Interaction
Einordnung der Anwendungsklasse "interaktiver Informationsstrahler / Community-Mirror" zwischen
- Digital-Signage (immer nur ein Signal, versucht Aktivität zu erzielen - nicht Wissen zu generieren) und
- Kiosk (aktive, bewusste, zielgerichtete Beschäftigung)
siehe auch Begriffe rund um das Projekt
CommunityMirror - Architektur
...
- UI-Hardware (großer Wandbildschirm mit Touch-Erkennung) - siehe Auflistung aktuell verfügbarer Hardware in Große Wandbildschirme
- Rechner-Hardware: ein Rechner zum Laufenlassen der Software - TBD: diesen Teil noch auf eigener Seite ausführen ...
- Software: Eine Instanz des CommunityMirrorFrameworks (d.h. CMF mit speziellen Konfigurationen, Templates)
- Service: Eine Instanz des CommunityMashup auf einem Server um die Daten einzusammeln und aufzubereiten
- - oder auch anderes
Wichtigstes Konzept ist dabei die Trennung der CommunityMirror-App (Instanz des CommunityMirrorFrameworks) und der CommunityMashup-Instanz, von der die Daten bezogen werden (und auf die verwiesen werden kann für eine Referenz / URL auf die Daten).
Für die CommunityMirror-App gibt es weitere Architekturüberlegungen:
- das CMF nutzt JavaFX um Objekte zu zeichnen und zu animieren
- das CMF stützt sich auf Funktionen einer Abstraktionsschicht namens CommunityInteractionFramework um Touch-Events zu empfangen
- diese Abstraktionsschicht stützt sich aktuell dann entweder auf JavaFX oder auf GestureWorks
- Aktuelle Probleme: GestureWorks läuft nicht stabil; JavaFX unterstützt folgende Features nicht: Inertia (bei Drag), Multi-User (Drag)
Im CMF kann folgendermaßen konfiguriert / gethemed werden:
- TBD
TBD Aktuellen Stand dokumentieren
Verschiedene Dokumente zur Architektur (teilweise veraltet)
Siehe hierzu auch die Ausführungen zum Gesamtprojekt.
CommunityMirrorFramework / CM-Anwendungen/Anwendungsklassen
...
Hier eine Liste der verschiedenen Elemente in der UI: TBD: Überarbeiten und Aktualisieren(Nicht alles ist unbedingt in allen CMF-Versionen umgesetzt.)
- Info Particle: Visuelle Repräsentanz eines Informationsobjekts (aus dem Mashup). Hat mehrere Zustände, z.B. MicroView, Preview, DetailView (die ggf. noch anders benannt werden).
- View: Globales Layout (Hintergrund) + Visualisierung der Informationsobjekte und deren Verhalten zueinander (optional, beispielsweise Fisch), NICHT Interaktionskonzept mit den Informationsobjekten (das ist bei allen Views gleich), aber insbesondere "Erschein- und Verwindelogik", reagieren ggf. in 2.0 auf Kontext (beispielsweise über iBeacon für Benutzererkennung):
- FischView
- FlowView: Standardpartikelfluss. Hier v.a. auch Logik für Partikel-"Verdränung" erforderlich, damit Workspace-Inhalte noch gut erkennbar sind - auch für andere Views relevant.
- MicroPostView (z.B. klasische TwitterWall oder ggf. auch Lavalampen-Metapher)
- NavigationView (Terminal an der Wache)
- Workspace (=Browser, = Userzone): (Ggf. visualisierter) Bereich, der benutzerspezifisch mehrfach auf dem Bildschirm auftauchen kann und primär der Exploration dient. Im Workspace wird ein Graph angezeigt.Sofern Benutzer identifizierbar ist, wird der Workspace einem Benutzer direkt zugeordnet und kann in 2.0 ggf. personalisiert werden.
- Graph: Enthält Verbindungen der Partikel untereinander sowie zusätzliche dynamische Entrypoints je nach Inhalte des Informationsobjekts. Graph sollte sinnvollerweise in irgendeiner Art "offen" bleiben, um Benutzern den Bezug zu geben, wo sie herkommen. Ggf. können Automatismen sinnvoll sein (2.0?), um zu große Graphen vom Ende her wieder zu "schließen" bzw. zu verkleinern.
- Entrypoint: Mit spezifischen Daten vorbelegter Selector zur einfachen Auswahl einer Teilmenge von Informationsobjekten. Unterschieden wird zwischen
- Dynamischen Entrypoints: Tauchen direkt als verbundene Nodes im Graph innerhalb der Workspace auf und erlauben beispielsweise das schnelle "Browsen" zu Teilmengen wie "Personen gleicher Institution", "Inhalte vom gleichen Ort", etc.
- Anwendungsspezifische Entrypoints: Stellen je nach Anwendugskontext (z.B. MeetingMirror auf wissenschaftlichen Konferenzen) potenziell interessante Entrypoints zur Verfügung (z.B. "Vorträge innerhalb der nächsten 2 Stunden", etc.)
- Selector(s): Verschiedene Klassen von Visualisierungen und Interaktionsmöglichkeiten für Entrypoints. Erlauben die Vorbelegung mit verschiedenen "Mashup-Suchkriterien", ermöglichen die (weitere) Einschränkung der Informationsobjekte und zeigen die aktuelle Auswahl dynamisch in einer SelectorPreview an. In 2.0 sind Selektoren ggf. kombinierbar, so dass beispielsweise Vorträge aus Bayern am nächsten Tag ausgewählt werden könnten. In irgendeiner Form sollte eine Art "History" bzw. zumindest ein "Weg zum aktuellen Selektor" (z.B. Pfleil, der am aktuellen Hauptpartikel des Graph hängt). Beispiele für Selektoren sind:
- MapSelector
- TagcloudSelector
- AlphabeticListSelector
- TextSearchSelector - hier v.a. Touch-Tastatur erforderlich
- TimelineSelector
- ...
- SelectorPreview: Vorschau der aktuellen Entrypoint- bzw. Selektorauswahl. Sinnvollerweise als "Konstante", die dem Benutzer bei Selektionen immer einen direkten "Effekt" darstellt. Verwendet im Optimalfall existierende Renderer (z.B. MicroView) und zeigt parallel insbesondere die Anzahl der aktuell ausgewählten Elemente an.
- Toolbox: Enthält anwendungsspezifischen (und dynamische?) Entrypoints in einer ggf. nach bestimmten Kriterien gruppierten / sortieren Übersicht. Kann ggf. auch ohne Partikel "aufgerufen" werden (z.B. Tap & Hold).
Partikelsystem
Generell: Soweit möglich, sollte alles über die Partikel-Metapher abgebildet werden, d.h. statt großer INTRApartikelinhalte (beispielsweise Darstellung von Autor / Organisation zu einem Content) sollte die Information besser über INTERpartikel-Beziehungen (beispielsweise das "Dranhängen" eines Autoren- bzw. Organisationspartikels an einen Content) abgebildet werden.
Folgendes ist auch nicht unbedingt alles genau so in allen CMF-Versionen realisiert.
Partikeldetaillierungsgrade und -zustände
...