In der letzten Zeit wurde ich häufiger gefragt, wann Gamification sich von seiner Rolle als Nischenthema emanzipieren wird und in den Mainstream gelangt. Seit Mitte 2016 bin ich mir sicher, dass wir uns gerade inmitten dieser Emanzipation des Themas befinden und ich will auch gerne verraten, warum ich dieser Auffassung bin.

Im letzten Jahr war Gamification im deutschsprachigen Raum ein medial sehr präsentes Thema: Viele TV-Dokumentationen, Zeitungsberichte und Fachartikel berichteten über die Potenziale des Einsatzes spielerisch, motivationaler Elemente in nicht spielerischen Kontexten. Doch nicht nur das Medienecho fiel durchweg positiv aus – auch bei Centigrade erreichten uns zahlreiche Anfragen für Gamification-Projekte von denen wiederum wieder einige Projekte in die Umsetzung gingen und sich nun z.T. in der täglichen Anwendung befinden.

Doch eine zentrale Frage bewegt viele unserer Kunden: Wie viel Spiel ist dem entsprechenden Nutzungskontext und den Bedürfnissen der eigenen Mitarbeiter oder Kunden angemessen? Die Frage ist insofern wichtig, als dass sich spielerisch, motivationale Elemente in ganz unterschiedlichem Maße in Prozesse und Produkte integrieren lassen. Eine weitere Frage, die sich unsere Kunden in diesem Zuge häufig stellen, ist auch die nach der passenden Manifestierung des Spielerischen: Reichen ein paar Spielelemente oder sollte es vielleicht doch ein vollständiges Spiel sein, um die angestrebten Mehrwerte zu erzielen?

Gamification vs. Serious Games: Trotz vieler Gemeinsamkeiten gibt es einige bedeutsame Unterschiede in dem Einsatz spielerischer Elemente

Aufgrund dieser Fragestellung werde ich mich in diesem Artikel der Frage nach Gemeinsamkeiten und Unterschieden von Gamification und Serious Games widmen, um ein besseres Verständnis von den Potenzialen und Einsatzmöglichkeiten beider Ansätze zu vermitteln und die Entscheidung für oder gegen einen der Ansätze zu erleichtern.

weiter lesen…

Ein Schichtführer steht in einer großen Maschinenhalle und überwacht die Produktion. Von seinem Standpunkt aus kann er die gesamte Halle überblicken. Er hat keinen Laptop bei sich, auch kein Tablet, nicht einmal ein Smartphone. Stattdessen trägt er eine unscheinbare Brille und lässt den Blick langsam über die einzelnen Maschinen schweifen. Lässt er seinen Blick auf einer der Maschinen ruhen, so öffnet sich in seinem Sichtfeld ein Fenster, das die wichtigsten Informationen zum aktuellen Status der Maschine enthält. Der Schichtführer kann so kontrollieren, an welchem Auftrag die Maschine gerade arbeitet, wie hoch die bereits produzierte Stückzahl ist und ob alle Werkzeuge fehlerfrei funktionieren. Wendet er seinen Blick von der Maschine ab, so verschwindet das Fenster wieder und er kann sich erneut frei in der Halle umschauen.

Eine vielversprechende Vision, aber ist sie auch realistisch? Mit dem heutigen Stand der Technologie (März 2017) muss man wohl sagen: „Leider noch nicht.“
 

Update 2018: Mittlerweile finden die Ergebnisse dieser Studie bereits Eingang in konkrete Augmented Reality und Virtual Reality Projekte. Informieren Sie sich hier über unsere 3D Dienstleistungen.

Doch die Fortschritte von Unternehmen wie Microsoft, Magic Leap oder auch DAQRI bei der Entwicklung von entsprechenden Brillen legen nahe, dass Augmented Reality bereits in naher Zukunft einsatzbereit sein wird. Dies bedeutet einen gewaltigen Schritt hin zur Industrie 4.0: Über den gesamten Produktherstellungsprozess hinweg könnten Werker bei ihrer täglichen Arbeit unterstützt werden. Doch wie können wir diese neue Technologie nutzen? Wie können wir schon jetzt Erfahrungen sammeln, um beim Erscheinen der einsatzfähigen Geräte benutzerfreundliche Anwendungen entwickeln zu können, mit denen sich Augmented Reality effizient und effektiv in den Arbeitsalltag integrieren lässt?

Mit dem Projekt DeepSight haben wir bei Centigrade einen Weg gefunden, schon jetzt Augmented Reality Anwendungen zu prototypen und dabei zugleich auch mögliche Vorteile dieser vielversprechenden Technologie erkennen und nutzen zu lernen. Dazu haben wir auf eine andere Technologie zurückgegriffen, die in diesem Kontext überraschend wirken könnte: Virtual Reality.

weiter lesen…

Microsoft eröffnet sich mit Xamarin Forms das Feld der Plattformunabhängigkeit für WPF. Dabei existiert bereits seit Langem ein Framework, das auch ohne erneute Implementierung unter den Betriebssystemen Windows, MacOS, Linux und seit Version 5 auch unter iOS, Android, Sailfish OS und anderen läuft. Die Rede ist von Qt. Ausgesprochen werden die beiden Buchstaben wie das englische Wort für niedlich: cute [kju:t].

#include „maincontroller.h“ 
#include  
#include  
#include  
#include  
#include  

int main(int argc, char *argv[]) 
{ 
    QApplication app(argc, argv); 

    QQmlApplicationEngine engine; 

    QQmlContext* context = engine.rootContext(); 

    QString currPath = QDir::currentPath(); 
    context->setContextProperty(„currentPath“, currPath); 

    QScreen *screen = QApplication::screens().at(0); 
    int width = screen->availableSize().width(); 
    context->setContextProperty(„availableWidth“, width); 
    int height = screen->availableSize().height(); 
    context->setContextProperty(„availableHeight“, height); 

    MainController* mainController = new MainController(); 
    context->setContextProperty(„mainController“, mainController); 

    engine.load(QUrl(QStringLiteral(„qrc:/main.qml“))); 
    return app.exec(); 
} 

LISTING 1: MAIN.CPP

Qt existiert bereits seit 1992. Die spätere Firma Trolltech vertrieb das Framework lange Zeit kommerziell. Für den Linux- Desktop KDE gab es eine freie Version, die später auch unter die GPL gestellt wurde. Beide Versionen unterschieden sich durch die Verfügbarkeit bestimmter Module. Ab Version 4.5 im Jahre 2009 wurde die LPGL hinzugefügt. Auch die aktuelle Version 5.x liegt in einer kommerziellen und einer freien Version vor. Mittlerweile liegen die Rechte bei The QT Company.

Das Besondere an der Qt-Entwicklung war das Signal/Slot- Prinzip. Während viele andere Frameworks noch auf Events setzten, wurde hier schon das spätere Publish-Subscribe-Pattern eingesetzt. Ein Button stellt das Signal clicked() bereit, eine View-Komponente kann dieses Signal an einen eigenen Slot onClicked() binden.

Mit der Version 4.7 wurde die Qt Markup Language QML eingeführt. Generierte der Designer vorher noch den fertigen Quellcode, kann man nun die Oberfläche in einer JSON-artigen Sprache beschreiben. Die Bildschirmelemente können durch JavaScript manipuliert, Werte und Listen gebunden werden. Man erreicht insgesamt eine Architektur, die Model- View-Delegate genannt wird. Für den vorliegenden Artikel wurde Qt in Version 5.6 verwendet. weiter lesen…

Stellen Sie sich vor, Ihnen wird die Aufgabe übertragen, in der Firma das Thema „Digitalisierung“ voranzutreiben. Und natürlich klingen Ihnen dazu die Stimmen aus Politik und Wirtschaft im Ohr. Sie haben mehr als eine Messe besucht, deren Hauptthemen, „digitale Transformation“ und „Industrie 4.0“, zuerst vollmundig angekündigt, dann aber eher dürftig aufgearbeitet worden sind. Woher kommt diese Diskrepanz? Haben wir es hier mit einer Worthülse zu tun? Einer schillernden Seifenblase ohne Substanz? Reinem Unfug? weiter lesen…

Das App-Icon ist nur ein kleiner Teil der ganzen Anwendung, aber der erste, den Benutzer sehen – und dieser erste Eindruck kann lang wirken. Deshalb ist es sehr wichtig, dass eine App ein attraktives, klares und aussagekräftiges Icon hat. Aber wie kommt man zu diesem Icon? Ich möchte hier meine Erfahrungen teilen, wie man die Herausforderung mit Stift, Papier und Illustrator meistert. Ich habe viele Jahre als Icon-Designerin gearbeitet und gestalte immer noch von Zeit zu Zeit selber Icons. Vielleicht hilft Ihnen meine Erfahrung, und einige meiner Tipps lassen sich vielleicht auch in ihren Projekten anwenden.

Als Beispiel möchte ich ein Icon für „WeatherEvent“ gestalten, eine hypothetische Versicherungs-App, die vor gefährlichen Wetterereignissen wie Gewittern oder Wirbelstürmen warnt und passend zur Situation Versicherungen vorschlägt. Ich werde Sie durch alle acht notwendigen Schritte führen. Fangen wir an! weiter lesen…

Im ersten Teil dieses Artikels habe ich geschildert, warum es zwar intuitiv, aber nicht minder gefährlich ist, sich bei der Etablierung eines HMI Styleguides an CD Styleguides zu orientieren. Ein Problem besteht z.B. darin, dass ein HMI Styleguide im Gegensatz zu einem CD Styleguide nicht nur für Gestalter, sondern vor allem auch für Software Engineers funktionieren muss. Die Dokumentform ist zudem zu rigide für die Dynamik moderner HMIs. Besonders wichtig ist die folgende Erkenntnis: der HMI Styleguide kann es generell nicht leisten, die alleinige Basis zu sein, auf deren Grundlage Software Engineers konsistente, ästhetische und intuitive HMIs entwickeln. Aufgrund meiner Erfahrung mit großen HMI Design Projekten in meiner Rolle als UX Berater bei Centigrade weiß ich: hier kann nur die Kombination aus flüssig ineinandergreifenden Methoden, Tools und Prozessen zum Erfolg führen.

Abbildung 1: Centigrade unterstützt TRUMPF bei der Etablierung konzernweiter HMI Gestaltungsrichtlinien

weiter lesen…

Mit der Intuition ist es so eine Sache. Der Mensch profitiert oft von ihr, lässt sich aber auch immer wieder von ihr täuschen. Ein HMI so zu gestalten, dass es intuitiv bedienbar ist, scheint eines der erstrebenswertesten Ziele moderner Software-Entwicklung zu sein, erspart es doch kostenaufwändige Schulungen, Fehlbedienungen und vieles mehr.

Auf dem Weg dorthin unterliegen jedoch viele Software Engineers und sogar HMI Designer der Täuschung Ihrer eigenen Intuition. Sie sagen sich (noch korrekterweise): „Ein HMI Design muss konsistent und ästhetisch aufgebaut sein, damit Bediener aus bereits erlernten Mustern auch in neuen Nutzungskontexten profitieren können. Können sie eine Maschine bedienen, können sie dann praktisch jede Maschinen bedienen.“ Manche schlussfolgern jedoch falsch weiter: „Wer Konsistenz im HMI Design schaffen möchte, tut gut daran, sich bei der Nachbardisziplin des Corporate Design zu bedienen – denn dort existieren bereits seit Jahr und Tag Regelwerke zur Schaffung von Konsistenz in Markenerlebnissen: die Corporate Design (CD) Styleguides.“

Leider ist dies eine falsche Analogie: genauso wie es in den Anfangsjahren des Fernsehens eine schlechte Idee war, die Tagesnachrichten in gleicher Manier wie im Radio einfach vorzulesen oder erste Internetseiten wie Zeitungsartikel mit jeder Menge Fließtext in Serifenschrift zu gestalten, ist dies zwar intuitiv (weil bereits bekannt), aber trotzdem falsch. Die Regelwerk-Philosophie traditioneller CD Styleguides kann nicht so einfach auf moderne HMIs und deren Entwicklung übertragen werden.

Sogar Amazon und Apple irrten damals, als sie glaubten es sei eine gute Idee, das aus dem Medium „Zeitung“ erlernte Gestaltungswissen 1:1 auf das neue Medium „Internet“ zu übertragen.

weiter lesen…

Visual Studio Code ist eine recht neue Erscheinung, hat aber seit seiner Veröffentlichung im November 2015 bereits viel Beachtung gefunden. Auf den ersten Blick könnte man meinen, Visual Studio Code sei nur eine weitere Iteration der Visual Studio-Familie, dem ist aber nicht so. Visual Studio Code ist eine komplette Neuentwicklung und hat abgesehen vom Namen „Visual Studio“ nur wenige Gemeinsamkeiten mit seinen Namensvettern vorzuweisen.

Es gibt viele gute Gründe die dafür sprechen bei einem neuen Projekt auf TypeScript zu setzen, anstatt auf JavaScript. So bietet einem TypeScript unter anderem die Möglichkeit seinen Code in Klassen zu strukturieren, um nur mal einen Vorteil zu nennen. In diesem Beitrag möchte ich darauf eingehen wie man ein TypeScript-Projekt mit Visual Studio Code debuggen kann. weiter lesen…

Nicht jeder mag Google Produkte. Dennoch werden sie von fast jedem Menschen verwendet, der über einen Computer, ein Tablet oder ein Smartphone verfügt. Es ist faszinierend, wie eine von zwei Studenten gegründete Firma einen Großteil des Markts eroberte, zum begehrten Arbeitgeber wurde und uns jedes Jahr mit innovativen Ideen überrascht. Und es ist noch faszinierender, dass eine Firma mit 60.000 Mitarbeitern sich anscheinend keine guten Interfaces leisten kann.

Google und das Google-Logo sind eingetragene Marken von Google Inc., Verwendung mit Genehmigung.

weiter lesen…

Ich erinnere mich immer noch an den Moment, als ich vom Himmel auf Frankfurt blickte. Ich war angespannt und aufgeregt. Im Juni 2015 zog ich aus meiner Heimatstadt Hongkong in das Land von Bier, Wurst und fürchterlich kalten Wintern: Deutschland. Tatsächlich eine ziemlich anstrengende Umstellung, da ich nie zuvor nach Europa gereist war. Und jetzt lebte und arbeitetete ich dort plötzlich als UX Designerin.

International sein – Nicht nur eine Frage der Geografie

Nachdem ich den Kulturschock hinter mir hatte, merkte ich, dass es nicht nur eine Frage der Geografie ist, ein internationaler Designer zu sein. Man wird nicht schon dadurch international, dass man in ein anderes Land reist und dort lebt. Wenn man sich nur engstirnig auf das Verhalten und die Gedanken konzentriert, mit denen man sich nicht identifizieren kann, aber die kulturellen Einflüsse dahinter nicht sieht, bleibt man in seiner „fremden“ Perspektive verhaftet. weiter lesen…

Im Folgenden steigen wir in die fiktionale Gedankenwelt eines naiven Designers ein. Die Meinungen sind bewusst überspitzt dargestellt, um die scheinbaren Schwierigkeiten aufzuzeigen, mit denen sich Designer konfrontiert sehen, die ihren eigenen Auftrag missverstehen und nicht das Gesamtbild eines Designprozesses mit den unterschiedlichen Stakeholdern auf Kunden- wie auf Anwenderseite vor Augen haben. Die „erweiterte“ Perspektive wird jeweils den vermeintlichen Kritikpunkten gegenüber gestellt.

Das erste Feedback

Es ist Montagmorgen. Ich öffne Outlook und siehe da: Die Mail, die ich am Freitagmittag verschickt hatte, wurde schon beantwortet. Es gibt Feedback zu den letzten Designentwürfen – yay. Mit schmerzverzerrtem Gesichtsausdruck entnehme ich der Mail, dass fast alles ganz ok aussieht. Was meiner Künstlerseele wie eine schallende Ohrfeige vorkommt. Denn was soll „…fast alles…“ und „…ganz ok…“ schon bedeuten, wenn nicht, dass mein visuelles Gesamtkonzept zusammenbrechen wird?

Die ganze Arbeit umsonst: Stundenlanges Recherchieren für die perfekte Schriftart. Jeder Abstand wohlüberlegt. Die Farbpalette mit dem Pantonekatalog auserwählt, den ich extra noch im Baumarkt geklaut hatte. Und jetzt soll wieder etwas an diesem Werk geändert werden? Musste da Vinci Anpassungen an der Mona Lisa machen? Hat Picasso Usability Tests gemacht? Hat Van Gogh jemals seine Mails gelesen? Wer weiß das schon… Ich jedenfalls weiß sofort: Das gesamte Design ist eigentlich für die Tonne und ich bin auch noch derjenige, der es verunstalten muss.

weiter lesen…

Im letzten Artikel ging es um die Frage, wie wir die Zukunft der IT-Branche in Deutschland durch Nachwuchsarbeit weiter sichern können und die große Frage, wie sich Software-Teams besser aufstellen können. Als Analogie zum Software Engineering beziehe ich mich auf Fußball als Sportart, die uns viel über Teamarbeit lehren kann und der ich selber mit Leidenschaft seit meiner Kindheit nachgehe.

Wie wird aus interdisziplinären Experten ein Team?

Im letzten Teil haben wir die Vorteile von breit aufgestellten Gruppen aus Experten kennen gelernt. Doch wie wird aus einer Gruppe von unterschiedlichen Menschen, die in unterschiedlichen Disziplinen arbeiten, wirklich ein Team? weiter lesen…