Im Zuge einer Recherche sind wir so auf eine andere, auf diesen Use-Case hin optimierte Lösung gestoßen: Mixpanel.

Mixpanel – wie funktioniert es

Mixpanel basiert im Wesentlichen auf zwei Elementen: Events und Profile. Nach der Anmeldung erhält man einen API Key und ein Script zum Einbinden in der eigenen App – das funktioniert ähnlich wie bei Google Analytics. Für Android und iOS (und einige weitere Plattformen) gibt es entsprechende SDKs – in diesem Artikel wird jedoch nur die JavaScript Einbindung behandelt.

Nun kann man gleich anfangen, Events zu schicken. Dazu gibt es im Wesentlichen eine Funktion:

mixpanel.track(
  "eventname",
  {
    "property 1": "Blue",
    "property 2": "Red"
  }
);

Die Funktion nimmt zwei Parameter: einen Eventnamen (Case-Sensitiv! login != Login) und optional ein JSON Objekt mit beliebigem Inhalt, welcher einfach angehängt wird. Wie das genutzt wird, bleibt dem Entwickler komplett selbst überlassen. In Herculess routen wir das Tracking über eine eigene Funktion, die vereinfacht so aussieht:

trackAction: function(name, options) {
  if(env !== "development") {
    mixpanel.track(name, options || null);
  }
}

Das sorgt dafür, dass während dem Development nicht ständig unnötig Events getrackt werden.

Profile

Zusätzlich gibt es auch die Möglichkeit, Profile anzulegen. Dafür muss man zumindest beim ersten Besuch eines Users für diesen Einstellungen festlegen:

mixpanel.identify(user_id);
mixpanel.people.set({
  "$first_name": "Joe",
  "$last_name": "Doe",
  "$created": "2013-04-01T09:02:00",
  "$email": "joe.doe@example.com"
});

Bei folgenden Sitzungen reicht die erste Zeile zur Identifizierung. Nun kann man alle Events diesem Profil zuordnen und so noch besser analysieren.

Mixpanel – Auswertung

Mixpanel bietet zahlreiche Möglichkeiten zur Auswertung der gesammelten Daten, welche genau zu Erklären den Rahmen dieses Artikels sprengen würde. Im einfachsten Fall kann man das Vorkommen von Events nach Zeitraum analysieren:

Zusätzlich dazu kann man diverse Filter nach Event-Art, Zeitraum und diversen Parametern wie Browser, Land etc. filtern.

Somit ist schon eine Analyse völlig individueller Parameter möglich. Ich kann zum Beispiel die Anzahl der erstellten Projekte je nach Bildschirmgröße analysieren, was mit Tools wie Google Analytics nicht so einfach möglich wäre.

Bei der Analyse der Profile sieht man, dass das ganz schön unheimlich werden kann:

Das eignet sich zum Beispiel sehr gut für Fehlersuche: Man kann sehr gut nachvollziehen, was vor dem Auftreten eines Fehlers passiert ist.

Weitere Funktionen

Man kann bei Mixpanel außerdem sehr individuelle Filter anlegen und auch automatische Emails bei gewissen Ereignissen konfigurieren. zB: Wenn ein User sich 2 Wochen nicht einloggt, dann schicke ihm ein Mail mit dem Inhalt. Außerdem gibt es für iOS eine A/B-Testing Suite sowie zahlreiche weitere Funktionen, welche man in der Developer Documentation findet.

Nutzungsbedingungen

Mixpanel ist kostenlos für max. 25 000 Events / Monat sowie max. 1 000 Profile. Wenn man in seiner App ein Mixpanel-Logo einbindet, erhöht sich das auf 200 000 Events bzw. 6 000 Profile. Danach gibt es diverse Pläne, beginnend mit 150$/Monat für 500 000 Events.

The post Mixpanel: Analytics für (mobile) Applikationen appeared first on Mobile USTP MKL.

Die Probanden bekommen Zugangsdaten und können sich danach in das System einloggen. Danach werden sechs vordefinierte kleine Aufgaben durchgearbeitet. Alle Beobachtungen und Anmerkungen der Testperson werden dabei notiert und danach noch ein paar offene Fragen gestellt.

Warum Usertesting?

Durch diese Tests können wir unsere App laufend optimieren. Außerdem bekommen wir zusätzlich Informationen über das Nutzungsverhalten abhängig von Alter und Beruf. Hier werde ich die bisher wichtigsten Erkenntnisse beschreiben. Die folgenden Screenshots sollen helfen die nachstehenden Punkte besser verstehen zu können.

1) Persönliche Übersicht

2) Projektübersicht ohne Aufgaben

Beschriftung/Wording

Viele Begriffe die in Herculess verwendet wurden, wie beispielsweise “Dashboard” oder “Task” waren den Testpersonen nicht geläufig. Während für uns als Webprofessionals diese Begriffe Gang und Gebe sind, haben die Probanden ihre Bedeutung teilweise nicht verstanden. Deshalb haben wir die Begriffe gegen Deutsche Wörter ausgetauscht: zum Beispiel wurde aus Dashboard Übersicht und aus Task Aufgabe.

Datum

Das Datum für Aufgaben war im Format “20. Mai, 2014” angegeben. Die Tests ergaben, dass Zusätze wie heute, morgen oder gestern hilfreich wären. Außerdem wurden Wochentagsangaben gewünscht, sowie relative Zeitzusätze wie “noch 2 Wochen”.

Layout

Besonders positiv wurde von allen Probanden das “aufgeräumte” Layout erwähnt. Die Tester haben schnell erkannt, dass das Plus rechts oben für das Erstellen von Aufgaben und Projekten vorgesehen ist. Auch wenn zu Beginn keine Aufgabe vorhanden war, haben sie durch den kurzen Beschreibungstext sofort gewusst was zu tun ist.

Icons

Das Thema Icons ist sehr schwierig, besonders wenn man ein Icon nicht nur zur Unterstützung einer Beschriftung in einem Button verwendet, sondern es keine Beschriftung hat. Das Plus für Hinzufügen und der Haken zum Abschließen wurde von allen Probanden verstanden. Probleme gab es aber bei dem bekannten Hamburger Icon für das Menü. Besonders ältere Probanden erkannten das Icon nicht. Im Gegensatz zu den jüngeren Testpersonen, die das Icon dann einfach “ausprobiert” haben, hatten die älteren hier mehr Scheu. Gegen das Hamburger Icon gibt es zurzeit einiges an Kritik in der Online-Community. (Siehe beispielsweise: Before the hamburger button kills you). In der Erstversion werden wir das Hamburger Icon so belassen, wobei wir wahrscheinlich “Menü” dazu schreiben werden, dazu werden wir aber noch ein paar Tests machen. Am Desktop ist das Menü ohnehin immer eingeblendet. Allgemein hatten aber nach dem Test alle Probanden angegeben keine Probleme beim Navigieren durch die App gehabt zu haben.

Gesten

Während wir in einer anderen Studie “Touchgesten in Webbrowsern am Smartphone”, welche diesen Sommer publiziert wird, untersuchen ob User Touchgesten überhaupt verwenden, haben wir während des Herculess-Tests herausgefunden, das kein Proband bisher Swipe-Right für Details oder Swipe-Left zum Aufschieben verwendet hat. Der Indikator für Optionen in der Listenansicht ist aber bei einem Großteil der Nutzer gut angekommen. Diese haben darauf geklickt & somit die Optionen in der Liste eingeblendet, um eine Aufgabe abzuschließen.

Die Liste mit gefundenen Optimierungsmöglichkeiten könnte ich hier noch viel länger fortsetzten, jedoch sind das meist sehr spezifische Dinge. Falls jemand noch mehr darüber wissen möchte oder einfach nur allgemein Fragen zu der App hat, stehen wir jederzeit zur Verfügung.

Fazit

Solche Tests sollten keine einmalige Sache bleiben. Einen kurzen Testleitfaden mit kleinen Aufgaben zu erstellen ist, wenn man seine App kennt, wirklich kein großer Aufwand & diesen Testleitfaden kann man dann, mit kleineren Adaptionen, über eine längeren Zeitraum verwenden. Jeder unserer Tests hat nicht  länger als 10 Minuten gedauert und viele wichtige Erkenntnisse für unser Projekt gebracht. Es ist sehr wichtig, dass man bei solch großen Projekten nicht das Gefühl für die “echten” User verliert, denn im Normalfall ist der Durchschnittsnutzer kein Computerprofi, der den Großteil seiner Zeit online verbringt.

The post Usertesting einer Webapp appeared first on Mobile USTP MKL.

Die Themen der Konferenz waren sehr vielfältig. Das Spektrum reichte von Entwickler-Themen wie Angular JS und weiteren JavaScript Vorträgen über Responsive Web Design und SASS bis hin zu User Interface Design und Daten Visualisierung. Dadurch konnte sich jede/r die interessantesten Themen heraussuchen.

Einer der spannendsten Vorträge war der des Gründers des bekannten Smashing Magazine, Vitaly Friedman (Twitter: @smashingmag), über Responsive Web Design. Der Talk mit dem Titel “Real-Life Responsive Web Design” deckte sehr viele wichtige Aspekte ab, die heutzutage für die Erstellung von flexiblen Web-Projekten wichtig sind.

Auch sehr spannend war der Vortrag von Monica Dinculescu (Twitter: @notwaldorf). Sie arbeitet bei Google an der Entwicklung des eigenen Browsers Chrome und sprach über sechs Tricks, wie Google seine Chrome User glücklich macht. Damit gab sie einen spannenden Einblick hinter die Kulissen der Arbeit von Google.

Die Designer/innen und Entwickler/innen der Masterklasse Mobiles Internet konnten sehr viel aus den verschiedenen Vorträgen mitnehmen und werden auch bei der nächsten Konferenz in Österreich wieder dabei sein.

The post codefront.io appeared first on Mobile USTP MKL.

Pickadate.js, der etablierteste responsive Datepicker, funktioniert zwar am Handy, allerdings – für mich – auch nicht wirklich zufriedenstellend. Das Problem an der ganzen Sache ist, dass die nativen Datepicker der Smartphones ja eigentlich sehr gut funktionieren. Warum also nicht einfach das native HTML5 Input Type “Date” verwenden?

Der native Datepicker unter Android 4.4

Warum nicht HTML5 Datepicker verwenden?

Somit stellt sich die Frage, ob die Benutzung der nativen HTML5 Date-Eingabefelder nicht optimal wäre. Dabei kommen jedoch folgende Probleme auf:

• Selbst wenn man alte Browser aus dem Spiel lässt, ist der Support für <input type=”date” /> leider sehr schlecht. Während Smartphones es sehr gut unterstützen, funktioniert es im Firefox gar nicht und im Chrome bietet der native Datepicker leider eine sehr schlechte User Experience.
• Das Datumsformat lässt sich bei nativen Datepickern leider nicht anpassen. Laut W3C-Spezifikation soll das Ausgabeformat immer “YYYY-MM-DD” sein, während das Anzeigeformat den Browserherstellern überlassen wird (im deutschen Chrome zB. ist es “DD.MM.YYYY”)

Meine Recherche nach einer wirklich zufriedenstellenden Lösung hat leider kein Ergebnis geliefert – also entschloss ich mich, mich selber daran zu versuchen. Herausgekommen ist ein jQuery Plugin auf Basis von Pikaday, welches ich PikadayResponsive getauft habe. Das fertige Plugin ist auf Github verfügbar.

Die Idee

Der Datepicker soll so funktionieren:

• Auf Desktop-Geräten kann über den Pikaday-Datepicker das Datum ausgewählt werden.
• Auf mobilen Touch-Devices kann über den nativen Datepicker das Datum ausgewählt werden.
• Das Anzeige-Format des Datums kann dabei einheitlich eingestellt werden.
• Das Ausgabe-Format kann dabei ebenfalls angepasst werden. (Standardmäßig als UNIX-Timestamp)

Mit Ausgabe-Format ist das gemeint, was man beim Abschicken des Formulars dann herausbekommt.

Der Ansatz

PikadayResponsive ist der Einfachheit halber ein jQuery-Plugin geworden. Dieses kann man auf ein Input-Feld anwenden.

Das Input-Feld erhält den type=”hidden”. Es dient nur noch dazu, den Ausgabe-Wert zu enthalten. Nun überprüft das Plugin via Modernizr (oder einer alternativen Feature-Detection Library), ob Touch-Support UND HTML5-Date Support vorhanden sind. Wenn nein, wird ein Input-Field erzeugt und Pikaday darauf angewandt. Wenn ja, wird ein readonly-Feld erzeugt, in welchem dann die Anzeige dargestellt wird. Direkt darüber wird ein zweites Eingabefeld mit type=”date” erzeugt, welches absolut positioniert wird und via CSS und “opacity: 0” gestylt wird.

Wenn man nun auf das Eingabefeld klickt, öffnet sich der native Datepicker. Via “onchange” wird jede Änderung am nativen Datepicker abgefangen und auf Basis dessen ein Datum mit der gewünschten Formatierung in das readonly-Feld geschrieben.

Das ganze klingt komplizierter, als es ist 😉 Eine kleine Demo zeigt, wie das Ganze funktioniert:

http://fnovy.com/projects/PikadayResponsive/

Und am Smartphone:

Die Umsetzung

Der komplette Code ist auf Github verfügbar. Ich werde hier kurz die einzelnen Schritte herzeigen und erklären.

Da das Ganze ein jQuery-Plugin ist, gibt es einige Einstellungen die man wählen kann. Details finden sich auf Github, für hier sind nur die Einstellungen “settings.displayFormat” und “settings.outputFormat” wichtig. Diese können Datumsformate enthalten, welche mit der JS-Library Moment.js geparst werden. Standardmäßig ist displayFormat “DD.MM.YYYY” und outputFormat “unix” (=UNIX Timestamp).

Als Erstes wird das eigentliche Input-Field auf hidden umgestellt und das Ganze in einem Container gewrappt. Der Container ist notwendig, damit das readonly-Overlay absolut positioniert werden kann.

var elem = $(this);
// Original Input-Field is hidden and will contain the final output value
elem.attr("type", "hidden");
// Wrap the input in a container
elem.wrap("<span class='pikaday-container'></span>");
var container = elem.parent(".pikaday-container");

Nun gibt es zwei Möglichkeiten, die ich einzeln erklären werde. Wenn Touch ODER HTML5-Date NICHT verfügbar sind, wird der Pikaday-Picker angezeigt:

var input = $("<input class="pikaday-display" type="text" />");
container.append(input);
var picker = new Pikaday({
    field: $(input)[0],
    format: settings.displayFormat,
});

Nun gibt es ein Input-Field mit Pikaday, jedoch fehlt noch eine korrekte Ausgabe. Wenn das Form abgeschickt wird oder man versucht, den Value mit $(“#date”).val() oder ähnlichem auszulesen, erhält man natürlich keinen Wert, da die Eingabe ja in ein anderes Feld erfolgte. Deshalb achten wir via onchange auf ein Ändern des Wertes des Pikaday-Feldes, und tragen dann entsprechend etwas in das ursprüngliche Eingabefeld ein.

input.change(function() {
	var date = moment($(this).val(), settings.displayFormat);
	var val;

	if (!date.isValid() || date.unix() < 0) {
		// Date is not valid
		input.addClass("is-invalid");
	} else {
		// Date is valid
		input.removeClass("is-invalid");

		// Output format can be unix or a Moment.js string
		if (settings.outputFormat === "unix") {
			val = date.unix();
		} else {
			val = date.format(settings.outputFormat);
		}
		elem.val(val);
	}

	elem.trigger("change");
});

Was passiert hier?

Zuerst wird überprüft, ob das eingegebene Datum valide ist. Wenn nicht, erhält das Ausgabe-Feld eine CSS-Klasse. Wenn das Feld valide ist, wird ein Ausgabewert erstellt – entweder ein UNIX-Timestamp oder ein beliebig formatiertes Datum. Dieser Wert wird dann in das ursprüngliche Element (elem) geschrieben.

Auf Smartphones ist das Ganze grundsätzlich ähnlich. Zuerst werden zwei statt nur einem Input-Feld erzeugt:

// The following element will be read-only and click-through
// and will only be used to display the formatted date
var display = $("<input class="pikaday-display pikaday-display-native" type="text" readonly="readonly" />");
container.append(display);

// The actual input field
var input = $("<input class="pikaday-invisible" type="date" />");
container.append(input);

Ganz wichtig ist hierbei, dass diese via CSS passend gestylt sind. Ein minimal-Style wäre:

.pikaday-container {
	display: inline-block;
	position: relative;
}

/* Height and width has to be equal! */
.pikaday-display, .pikaday-invisible {}

.pikaday-display-native {
	pointer-events: none;
	cursor: pointer;
}

.pikaday-display.is-invalid {
	background: rgba(255,0,0,0.05);
}

.pikaday-invisible {
	opacity: 0;
	position: absolute;
	left: 0;
	top: 0;
}

Die wichtigsten Punkte dabei sind:

• pikaday-display und pikaday-invisible müssen gleich groß sein
• pikaday-invisible muss absolut positioniert sein und opacity: 0 haben
• pikaday-display-native muss pointer-events: none haben, damit man nicht darauf klicken kann.

Die onchange-Funktion für den native Datepicker sieht dabei quasi genauso aus wie die für Pikaday, nur dass zusätzlich noch die Anzeige gesetzt wird:

// ...
display.val(date.format(settings.displayFormat));

Das fertige Script enthält noch ein paar weitere Optionen und Optimierungen. Ich freue mich über Fragen, Anregungen oder Kritik.

The post Erstellung eines wirklich responsive Datepickers mit JavaScript appeared first on Mobile USTP MKL.

Smartphones: Funktionen und Unterschiede

Erstes Smartphone von IBM

Die gesamte digitale Branche ist sehr schnelllebig, besonders gut sieht man das am Beispiel des Smartphones. So wurde das erste Smartphone erst vor ca. 20 Jahren (1992) von IBM entwickelt und eine erste wirklich gut nutzbare Kamera wurde erst vor genau 10 Jahren in unsere heute so gewohnte Handytechnik integriert.

Die damalige Kamera war mit 1 Megapixel herausstechend für diese Zeit und heute gibt es bereits Smartphones die eine bessere Auflösung als so manche Digitalkameras mitbringen (z.B. Nokia Lumia 1020 mit 41 Megapixel). Heute haben unsere Smartphones teilweise schon die Leistung eines normalen Computers und bieten jede Menge an Extras. So gehört es beispielsweise zur Standardausstattung mit einem Smartphone Emails zu versenden, im Internet zu surfen, Spiele zu spielen, Videos zu machen/bearbeiten sowie hochauflösende Bilder zu erstellen. Bei dieser schnellen Veränderung kann man sich vorstellen, dass in diesem Bereich noch lange nicht alles entwickelt wurde.

Nokia Lumia 1020 mit 41 Megapixel Kamera

Preisklassen und Betriebssysteme

Grundsätzlich kann man Smartphones in Ober-, Mittel- und Unterklasse einteilen. Die Oberklasse- Smartphones sind meistens neben besonderer technischer Komponenten am höheren Preis erkennbar. Die Mittelklasse ist etwas preisgünstiger, hat aber meistens auch den benötigten Funktionsumfang. Die Unterklasse Modelle werden meist recht günstig verkauft und haben einige Einschränkungen wie zum Beispiel schlechtere Kameraauflösung. Für den Otto Normalverbraucher ist ein Mittelklasse Smartphone vollkommen ausreichend. Besonders wichtig bei der Anschaffung von Smartphones ist ein dazu passender Tarif, der vor allem die Internetnutzung ausreichend abdeckt, da dies sonst schnell zu einer Kostenfalle werden kann. Hier sind besonders Tarife, die entweder unlimitiert Internet beinhalten oder ab einem gewissen Konsum die Geschwindigkeit des Internets drosseln, zu empfehlen.

Außerdem gibt es unterschiedliche Betriebssysteme: iOS (Apple), Android (Google), Windows Phone, Blackberry.

QR Codes

QR-Code MFG-Blog

Aus dem schwarz-weißen Muster/Wirwarr wird man kaum schlau. Dennoch sieht man diese Codes immer öfter auf Verpackungen und Etiketten. Was genau also sind QR-Codes und wozu können wir sie speziell in der Waldpädagogik verwenden? QR steht für Quick Response (schnelle Antwort) und das ist auch genau das Ziel der Codes – schnell zu Informationen zu kommen. Die QR-Codes wurden entwickelt, um viele Informationen auf kleiner Fläche unterzubringen und sollten auch funktionieren, wenn sie teilweise verschmutzt oder zerstört sind. So kann der QR-Code selbst dann noch gescanned werden, wenn bereits 30% des Codes zerstört wurden.

Die Post zum Beispiel nutzt sie als digitale Briefmarken und die Bahn als digitale Fahrscheine. Auf Werbeplakaten führen sie meistens zu den Webseiten der Anbieter.

Scannen & Erstellen eines QR-Codes

QR Codes lassen sich mit jedem Smartphone und einer kostenlosen App dazu problemlos lesen. Dazu startet man einfach die App. Man klickt auf einen Button „Mit Kamera scannen“ und hält das Handy so über den Code, dass man ihn auf dem Display sieht. Der Code wird danach automatisch von der App erkannt und zeigt die enthaltenen Informationen. Bekannte Scanner sind zum Beispiel Qrafter, Barcode Scanner oder i-nigma.

Der Code besteht aus dem Muster und 3 schwarzen Quadraten an den Ecken. Diese helfen den QR Code immer zu erkennen, auch wenn er von einer anderen Richtung aus gescanned wird. Ein QR Code kann ganz einfach über einige Online-Plattformen selbst erstellt, gedruckt und verwendet werden (z.B. http://goqr.me/). So können solche Codes zum Beispiel mit Informationen befüllt werden, um einen Lehrpfad im Wald zu gestalten. Man kann sich also gewisse Punkte aussuchen, wo ein QR-Code mit den dazu passenden Informationen aufgehängt wird. Jeder, der ein Smartphone besitzt, kann dann ganz einfach an den verschiedenen Stationen die Informationen abrufen.

Augmented Reality für Waldpädagogik

Augmented Reality, auf Deutsch erweiterte Realität, beschreibt die Erweiterung der Realität unterstützt durch Computer. Darunter wird im Allgemeinen verstanden, dass ein reales Bild mit zusätzlichen Informationen wie Texten, Bildern und Videos angereichert wird.

Die Anwendungsmöglichkeiten für AR sind sehr vielfältig. Erfolgreich genutzt wird dieses Konzept beispielsweise für Navigationssysteme in Gebäuden, im Freien oder im Auto. Der Unterhaltungsbereich ist ebenfalls ein Feld in der AR gerne und oft genutzt wird. Doch auch für Waldpädagogik gibts es einige interessante Szenarios.

Ein Blick ins Innere

Mit Augmented Reality ist es möglich Dinge darzustellen, die mit freiem Auge nicht sichtbar sind oder ganz im Verborgenen liegen. Das Bild zeigt dieses Konzept anhand des Menschen. Mit Hilfe eines Smartphones oder Tablets kann das Innere des menschlichen Körpers dargestellt werden. Zusätzlich dazu kann sich der User detaillierte Informationen anzeigen lassen.

In Bezug auf Waldpädagogik wäre es vorstellbar ins Innere eines Baumes zu blicken und Vorgänge wie Nahrungsaufnahme oder Wachstum zu veranschaulichen. Aber auch um Tiere zu zeigen, die im Inneren eines Baumes leben wie Insekten, Nager oder Vögel.

Interpretation der Umgebung

In der Natur kommen viele Tiere und Pflanzen vor. Doch nur Spezialisten oder Hobbyexperten wissen über alle vorkommenden Spezies bescheid. Mit Augmented Reality ist es möglich, die Umgebung zu entdecken. Anwendungsbeispiele sind Fährtenlesen aber auch die Identifikation von Bäumen, Sträuchern, Kräutern oder Pilzen.

Virtuelle Welten

Ein weiteres beliebtes Szenario für Augmented Reality ist das Erscheinen lassen von Objekten, die in der Realität nicht da sind. So kann es beispielsweise möglich sein Hirsche in ihrer natürlichen Umgebung zu beobachten und ihre Verhalten zu studieren. Der User kann hautnah dabei sein, auch wenn er nicht das Glück hat das Tier in Wirklichkeit zu sehen.

– Carina Skladal

Die Waldfibel

Die Waldfibel wurde vom deutschen Bundesministerium für Ernährung und Landwirtschaft umgesetzt.

Die App ist kostenlos für Android und iOS erhältlich sowie als PC Software (aufgrund der großen Nachfrage). Ich habe die App unter Android 4.4 auf meinem Nexus 5 getestet. Die App versucht spielerisch einen Zugang zur Waldthematik zu ermöglichen.

Funktionen

Die Startview der App ist ein Waldpanorama, in dem man sich nach rechts und links bewegen kann. Das Panorama selbst enthält verschiedene Bäume, Tiere und Wegweiser. So kann man interaktiv durch den Wald navigieren.

Wählt man zum Beispiel ein Tier aus, kann man alles über das Tier lesen, sowie die Tierlaute des jeweiligen Tiers anhören.  Die Wegweiser verbergen Hinweise und einige Quizzes. So kann man sein Wissen über gewisse Blätter-und Baumarten überprüfen.

Mein persönliches Highlight ist der Baumhöhenmesser. Man kann ein Foto von einem Baum machen (der Baum muss in seiner vollen Größe ins Kamerafenster passen), danach geht man in normalen Schritten auf den Baum bis zum Stamm. Dabei werden die Schritte von der App mitgezählt und die Höhe berechnet.

Neben der Panoramaansicht kann man sich die Inhalte noch von A-Z ansehen sowie nach Schlagworten von A-Z suchen.

Fazit

Mein persönlicher Eindruck der App war sehr gut! Das App hat ein durchgängiges Design und wirkt sehr “rund”. Besonders viel Spaß hatte ich an der Panoramaansicht, weil ich dort ausprobieren wollte, welche Elemente “interaktiv” sind, um mehr darüber zu erfahren. Besonders der Sound der Tierlaute war in der Detailansicht sehr hilfreich! Wie von Carina Skladal im ersten Absatz beschrieben könnte die App vielleicht noch von mehr Augmented Reality Integration profitieren, indem das Panorama zum Beispiel über eine “wirkliche” Waldansicht gelegt wird.

– Lisa Gringl

Anymals+plants

Anymals+plants gibt es als Android (getestet), iPhone, iPad und Windows Phone App. Sie bietet im Wesentlichen zwei Funktionen: Eine Artenliste und einen Identifikationsmodus. Dabei greift die kostenlose Applikation auf eine sehr große Datenbank von Tieren und Pflanzen zurück.

Was man bei der Benutzung von Anymals bedenken sollte, ist, dass die einzelnen Daten zu verschiedenen Flora- und Faunagruppen erst heruntergeladen werden müssen. Die Daten sind zwar kostenlos (und Deutsch), aber messen je nach Paket mehrere MB. Da Anymals grundsätzlich international ist, gibt es ein sehr praktisches Feature, um nur relevante Daten herunterzuladen: die App kann die eigene GPS-Location ermitteln und anhand der Position bestimmen, welche Arten in der Umgebung vorkommen können. Diese Daten werden dann heruntergeladen.

In der Artenliste ist es möglich, selber Fotos zu einzelnen Arten anzuhängen oder Arten zu markieren. So kann man Sichtungen festhalten. Außerdem kann man direkt auf die Wikipedia-Artikel zu den Arten zugreifen – dafür ist jedoch (im Gegensatz zu den restlichen Features) eine Internet-Verbindung erforderlich.

Das Identifikationstool basiert auf schriftlichen Fragestellungen, teilweise ergänzt durch Bilder. Dabei wählt man zuerst eine Grundkategorie (z.B. “Amphibien und Reptilien”). Danach muss man nach und nach die Fragen beantworten und grenzt so immer weiter ein, welche Art gerade vorliegt. Die Fragen beziehen sich dabei stets auf das Aussehen der Art.

Die Daten der App werden teilweise durch User ergänzt, somit ist die Datenbank sehr groß und weitläufig.

Fazit

Obwohl die App optisch nicht unbedingt beeindruckend aussieht, so hat sie doch einen bemerkenswerten Funktionsumfang. Durch die clevere Nutzung von GPS-Daten und die (weitgehende) Möglichkeit der Offline-Nutzung ist die App für die Nutzung im Wald sehr gut geeignet.

– Francesco Novy

NABU Vogelführer

Obwohl man während der Schulzeit viele Vögel gelernt hat, die in unseren Wäldern heimisch sind, ist dieses Wissen bei vielen Menschen später anderen Dingen gewichen. Der Naturschutzbund Deutschland stellt deshalb einen umfangreichen Vogelführer zur Verfügung.

Funktionen

Mit dem NABU Vogelführer wird einem über alle Smartphoneplattformen hinweg ein durchgängiges Erlebnis geboten. Er ist für Android, iPhone und Windows Phone verfügbar und kann darüber hinaus über eine mobile Webseite aufgerufen werden. Mit dem Vogelführer lassen sich gesehene Vögel anhand verschiedener Merkmale bestimmen und Informationen dazu anzeigen. Neben Schnabel, Füße, Größe und Gefieder kann man auch den Lebensraum, in dem man das gewünschte Tier gesehen hat, angeben. Danach erhält man eine Liste mit allen Vögeln, die diesen Merkmalen entsprechen. Wählt man ein Tier aus, erhält man vielfältige Informationen dazu. In den jeweiligen Apps können Lieblingsvögel zu Favoriten einteilen, um Infos zu diesen immer griffbereit zu haben.

Fazit

Der NABU Vogelführer glänzt durch seine Plattformunabhängigkeit und seinen vielfältigen Infos. Vor allem die Filtermöglichkeiten sind sinnvoll gewählt, denn so können gesehene Vögel leicht wiedererkannt werden. Die jeweiligen Smartphone Apps benötigen zudem keine Internetverbindung und können so auch in Funklöchern zuverlässig verwendet werden. Wünschenswert wäre noch, dass die jeweiligen Vogellaute über das Handy abgespielt werden können.

– Thomas Ederer

iForest

Mit iForest lassen sich einheimische Bäume und Sträucher leicht bestimmen. Durch einfaches Auswählen der diversen Pflanzeneigenschaften wird das Suchergebnis immer weiter eingeschränkt bis nur noch die passende Pflanze übrigbleibt. Dazu erhält der Nutzer dann umfassende Informationen zu den Merkmalen, Standorte und Verbreitung, Geschichte, Heilkunde und vieles mehr.
Die Applikation hat auch eine integrierte Suchfunktion mit Hilfe dessen direkt nach dem Namen der Pflanze gesucht werden kann. Außerdem hat man die Möglichkeit, seine Lieblingsbäume oder -sträucher als Favorit zu speichern, um sie später schneller wieder zu finden.
Des Weiteren hat die App eine Trainingsfunktion, mit der ein Frage-Antwort Quiz gespielt werden kann. Dabei wird immer ein Bild angezeigt und darunter stehen drei Antwortmöglichkeiten zur Bestimmung zur Verfügung.

Test

Beim Testen der Applikation unter Android wurde festgestellt, dass diese sehr rund läuft und Farben sowie Layout ansprechend gestaltet sind. Ein Kritikpunkt ist die etwas zu klein gewählte Schrift bei langen Detailtexten.
Außerdem können die gewählten Filter nicht alle auf einmal wieder gelöscht werden. Um eine neue Pflanze bestimmen zu können, müssen die gesetzten Filter wieder einzeln deaktiviert werden.

Auch der Praxistest hat gezeigt, dass die Pflanzeneigenschaften sehr gut dargestellt und erklärt sind, wodurch eine Bestimmung von Bäumen und Sträucher leicht möglich war. Lediglich der Salbei im Garten wurde von der Applikation nicht gefunden.

Alle nötigen Daten werden bei der App-Installation geliefert, wodurch die Verwendung auch im Wald ohne Internetempfang möglich ist.

Die Applikation ist für Android und iOS verfügbar und kostet rund 13€.

– Michael Kräftner

Käferkunde

Käferkunde

Die App Käferkunde für  das iPhone ermöglicht das Nachschlagen, Bestimmen und Erlernen von unterschiedlichen Käferarten. Zur Zeit umfasst die App rund 150 Käfer. Laut Herausgeber wird die Bibliothek aber stetig erweitert. Außerdem enthält die App einen Lernmodus, in dem die eigenen Kenntnisse über Käfer abgefragt werden. Nebenbei können gefundene Käfer auf einer GPS-Karte eingezeichnet und mit Hilfe von Fotos dokumentiert werden.

Die App hat ein sehr schönes Design und eine durchdachte Bedienung. In der Praxis funktionierte das Käferbestimmen mit Hilfe des Filtern ganz gut. Auch der Lernmodus mit dem Quiz macht Spaß und erweitert das Käferwissen. Mit 7 Euro kostet die App aber schon relativ viel. Immerhin ist die Idee ja nicht ganz neu und ähnliche Anwendungen kosten oft nur die Hälfte. Abheben kann sich die App aber trotzdem durch das herausragende Design und den Lernmodus.

– Christian Gradl

The post Das Smartphone im Einsatz in der Waldpädagogik appeared first on Mobile USTP MKL.

Schlussendlich wurde ein Plakat erstellt sowie eine Website, auf der man abstimmen kann sowie das Abstimmungsergebnis sehen kann. Während das System technisch für beliebig viele Fragen ausgelegt worden ist, wurde im Endeffekt nur eine Frage genutzt.

Umsetzung

Ein Plakat wurde in Adobe Illustrator entworfen, in A3 gedruckt und an einigen Stellen in der FH aufgehängt.

Kernidee war es, dass auf dem Plakat direkt zwei Optionen sichtbar sind. Durch das Scannen eines der beiden Codes wurde auf der Abstimmungs-Seite die entsprechende Option bereits vorausgewählt. Die Idee dahinter war es, dass User das Gefühl bekommen schon durch das Scannen an sich eine Aktion zu setzen, anstatt erst zu Scannen um danach zu sehen was man eigentlich tun kann/soll.

Je nach gescanntem Code wird eine Option größer und farbig angezeigt.

Nach dem Bestätigen einer Option gelangt man zum Ergebnis-Screen. Dort sieht man den aktuellen Stand der Umfrage. Außerdem gibt es die Möglichkeit, noch ein schriftliches Feedback zu geben. Dieses wurde anonymisiert abgespeichert. Zum Verhindern mehrfacher Votes wurden verschiedene Clientseitige Lösungen wie LocalStorage und Cookies genutzt. Diese Möglichkeiten bieten natürlich keine 100-prozentige Sicherheit gegen doppelte Votes, jedoch ist anzunehmen dass der nötige Aufwand für diesen speziellen Anlass zu groß ist als dass viele User das machen würden: ein “Betrug” hat für Benutzer eigentlich keinerlei Nutzen.

Der Ergebnis-Screen zeigt ein Piechart auf CSS3-Basis sowie ein Formularfeld zum Feedback geben.

Zielsetzung und Ergebnis

Ziel des Projektes war es, 50 Abstimmungen zu erreichen. Dieses Ziel wurde mit 40 tatsächlichen Stimmabgaben knapp verfehlt. Zusätzlich haben 8 User schriftliches Feedback gegeben. Insgesamt finden 2/3 (67%) der User, die teilgenommen haben, dass der eCampus vorher besser war als nachher. Vor allem die mobile Version wurde im schriftlichen Feedback viel kritisiert. Die gesammelten Informationen werden zum Projektabschluss an das zuständige Organ der FH weitergegeben, um das Usererlebnis des eCampus verbessern zu können.

The post eCampus Feedback via QR-Codes appeared first on Mobile USTP MKL.

Während Ember-Data somit extrem hilfreich ist und auch für sehr komplexe Applikationen geeignet ist, stießen wir auf das Problem, dass man zwar einstellen kann, ob man die Daten über eine REST-API oder den LocalStorage persistieren möchte, aber nicht beide Optionen gleichzeitig nutzen kann. Für Herculess brauchen wir aber eine Funktionalität, die standardmäßig Daten vom REST-Server holt und nur im Offline-Fall auf zwischengespeicherte Daten aus dem LocalStorage zurückgreift.

Der Weg zum Ziel

Die Lösung dieses Problems war nicht ganz einfach und hat erst einmal zu diversen Fehlversuchen geführt. Erste Ansätze waren es, den bestehenden LocalStorage-Adapter von Ember-Data umzubauen und um eine Hintergrund-Synchronisierung zu ergänzen. So hätte Ember immer lokal im LocalStorage gearbeitet und nur im Hintergrund wären die Daten von der REST-API in den LocalStorage geschrieben worden. Das Problem hierbei war jedoch, dass Ember, um stets eine Datenintegrität zu gewährleisten, es nicht ermöglicht, zur Laufzeit alle Daten aus dem LocalStorage zu erneuern. Es hätte stets nach dem Update von der REST-Schnittstelle eine kompletter Seitenrefresh durchgeführt werden müssen, was wiederrum die unbemerkte Synchronisierung unmöglich gemacht hätte.

Nachdem diverse Experimente in diese Richtung fehlgeschlagen sind, haben wir einen neuen Ansatz ausprobiert: Wenn die App offline ist, sollen die Ajax-Calls einfach statt an den Server an eine (offline verfügbar gemachte) Datei geroutet werden und diese dann aus dem LocalStorage zwischengespeicherte Daten in derselben Form wie die richtige REST-API zurückgeben. So könnte der Client immer gleich arbeiten und nur die URL der AJAX-Calls müsste geändert werden. Das Problem hierbei ist natürlich, dass man lokal nur JavaScript/HTML zwischenspeichern kann und diese clientseitig keine reinen JSON-Responses zusammenbauen können: Die AJAX-Calls parsen die Responses ja nicht, sondern geben nur den Dateiinhalt zurück.

Somit sind wir schlussendlich bei einer Adaption dieser Idee gelandet. Anstatt eine Pseudo-API zu implementieren, fangen wir alle AJAX-Calls ab und liefern mithilfe des jQuery-Plugins jquery.ajax.fake selbst zusammengebaute JSON-Responses zurück.

Unsere Lösung

In der Praxis sieht das wie folgt aus:

Der erste Schritt ist es, die Daten überhaupt einmal zwischen zu speichern. Dafür haben wir eine JavaScript-Klasse erstellt, welche für alle Synchronisations-Vorgänge zuständig ist. Diese ist komplett unabhängig von Ember.

Diese Klasse hat eine „sync()“ Funktion. Diese Funktion holt sich von der REST-API über eine eigene Route „/downSync“ eine Kollektion aller wichtigen Daten für diesen User. Diese Kollektion enthält alle Tasks und Projekte, die für diesen User wichtig sind.

Das Sync-Objekt speichert diese Daten dann in den LocalStorage. Danach wird nach einigen Sekunden erneut sync() aufgerufen und die Daten im LocalStorage aktualisiert. Somit sind die Daten im LocalStorage immer (bis auf seltene Ausnahmen) eine Spiegelung der Daten von der REST-API.

Der nächste Schritt ist es, abzufragen, ob gerade eine Internet-Verbindung besteht. Das machen wir beim ersten Seitenaufruf über „navigator.onLine“, welcher den Online-Status zurückgibt. So wird ein Cookie „is-offline“ auf true oder false gesetzt. Danach wird bei jedem Sync-Versuch dieser Cookie angepasst, falls der Sync-Versuch fehlschlägt oder doch wieder klappt.

Falls die App erkennt, dass man plötzlich offline geht, schaltet sie auf jquery.ajax.fake um. Dafür verändern wir über die jQuery-Funktion „$.ajaxSetup“, welche Voreinstellung für alle folgenden $.ajax-Calls setzen kann, das Attribut „fake: true“. Dieses braucht jquery.ajax.fake, um zu wissen dass dieser Request gefakt werden soll.

Zusätzlich dazu muss man, damit die Fake-Responses funktionieren, für jede URL einstellen, welcher Response kommen soll. Da es unmöglich wäre, hier im Vorfeld alle möglichen URLs einzustellen (da wir ja auch Parameter wie IDs mitsenden), muss das automatisch geschehen. Das haben wir so gelöst, dass wir in der Ember-Data Methode, die für die AJAX-Aufrufe zuständig ist, noch eine Zeile hinzugefügt haben, die – vor dem Senden – zu der nun gleich gesendeten URL immer die gleiche Funktion aufrufen soll.

$.ajax.fake.registerWebservice(url, function(data) {
    return restSyncer.fakeAjax(data);
});

Außerdem fügen wir vor dem Senden die URL als Parameter zum AJAX-Request hinzu.

Die Funktion, welche die Fake-AJAX-Responses zusammen bauen soll, kann dann über den so mitgelieferten Parameter „url“ ermitteln, welche Route angesprochen wurde, und dann aus dem LocalStorage entsprechend einen Response zusammenbauen und zurückgeben. Die eigentliche App merkt so nie, ob die Daten jetzt wirklich vom Server oder aus dem LocalStorage kommen. Sobald die App wieder online ist, wird automatisch umgestellt – ohne, dass der User es merkt.

Während diese Methode, soweit bisherige Test gezeigt haben, sehr gut und nahtlos funktioniert, hat sie auch zwei Nachteile: Jede Änderung der REST-API muss genau im Client gespiegelt werden, und es entsteht zusätzlicher Traffic durch das Syncen im Hintergrund. Letzteres werden wir in späteren Versionen optimieren, indem wir einen Timestamp der letzten Synchronisierung mitschicken und so nur neue Einträge erhalten. Außerdem soll man in der App die Frequenz der Sync-Abfragen einstellen können oder auch nur manuell synchronisieren.

Die aktuelle Implementation funktioniert bereits für alle GET-Requests. POST, PUT oder DELETE Requests sind aber genauso lösbar: Hierfür werden wir alle solche offline getätigten Requests eigens im LocalStorage speichern, und wenn die App wieder online geht werden diese gespeicherten Requests einer nacheinander erneut an den Server gesendet. Hierbei ist es besonders wichtig, den Status mitzuspeichern: Erstens muss der User immer wissen, ob gerade etwas synchronisiert wird oder ob alle Daten aktuell sind, und zweitens muss die App immer wissen, ob ein Request erfolgreich beim Server angekommen ist oder ob es wieder einen Fehler gab und es später erneut versucht werden muss, um den Verlust von Daten zu verhindern.

The post Offline REST Fallback via LocalStorage appeared first on Mobile USTP MKL.