Die einfachste, aber auch kostenintensivste Möglichkeit ist, einen Juristen damit zu beauftragen, Allgemeine Geschäftsbedingungen für den eigenen Webshop zu erstellen. Wer sich allerdings ein Angebot von einem Rechtsanwalt erstellen lässt, bekommt oft ein Angebot im fünfstelligen Eurobereich.

Vor allem für kleinere Onlineshop-Betreiber sind derartige Kosten alles andere als wirtschaftlich.

Manche Onlineshop-Betreiber kopieren sich AGB von fremden Onlineshops und verändern diese ihren Vorstellungen entsprechend. Davon ist allerdings stark abzuraten, da man dadurch eine Urheberverletzung begeht. Es ist nicht gestattet, fremde Daten zu kopieren und für seine eigenen Zwecke zu nutzen.

In Österreich bietet die Wirtschaftskammer kostenlos für jede Branche ausgesprochen gute Vorlagen, welche durch Juristen erstellt wurden und durch den Shopbetreiber beliebig verändert werden dürfen.

Wer kein Mitglied der österreichischen Wirtschaftskammer ist kann auch im World Wide Web einige Vorlagen für AGB finden.

Empfehlenswert ist es, diese Vorlagen durch einen Rechtsanwalt speziell für die jeweiligen Zwecke verfeinern zu lassen. Hierbei belaufen sich die Kosten meist im dreistelligen Eurobereich, was auch für Betreiber kleinerer Onlineshops leistbar ist.

Geltung von AGB im Internet

Werden bei Geschäftsabschlüssen über das Internet AGB verwendet, dann muss deren Geltung vertraglich vereinbart werden, damit sie Bestandteil des konkreten Rechtsgeschäftes werden. Der Unternehmer muss daher darauf hinweisen, dass er dem beabsichtigten Vertrag seine AGB zu Grunde legt, was vor dem Vertragsabschluss zu erfolgen hat, und der Kunde muss zumindest die Möglichkeit haben, sich Kenntnis vom Inhalt dieser AGB zu verschaffen.

In der Praxis werden AGB auf der Website eines Online-Händlers oftmals durch einen eigenen Link auf den Text der AGB zur Verfügung gestellt. Der Kunde kann sich dadurch Kenntnis vom Inhalt dieser AGB verschaffen, in dem er den entsprechenden Link anklickt. Dies genügt, um dem Erfordernis zu entsprechen, dass der Vertragspartner die Möglichkeit haben muss, sich Kenntnis vom Inhalt der AGB zu verschaffen. Ob er sie dann tatsächlich durchliest, ist seine Sache.

Das Fernabsatz- und Auswärtsgeschäfte-Gesetz (FAGG) sieht bei Verträgen mit Konsumenten (B2C) die unter ausschließlicher Verwendung eines oder mehrerer Fernkommunikationsmittel (zB E-Mail oder online) geschlossen werden, bestimmte Informations- und Bestätigungspflichten vor.

Danach muss der Verbraucher rechtzeitig vor der Abgabe seiner Vertragserklärung über folgende Informationen verfügen:

• die wesentlichen Merkmale der Waren oder Dienstleistungen
• Namen oder Firma sowie Anschrift ;gegebenenfalls Telefon, Fax und E-Mail
• gegebenenfalls  Geschäftsanschrift für Beschwerden
• gegebenenfalls Namen/Firma und Anschrift jener Person, in deren Auftrag der Unternehmer handelt, sowie die Anschrift dieser Person, für Beschwerden
• Gesamtpreis inkl aller Nebenkosten (wenn nicht möglich: Art der Preisberechnung)
• bei unbefristeten oder Abonnementverträgen: Gesamtkosten oder Kosten pro Monat (wenn nicht möglich: Art der Preisberechnung)
• Kosten der für den Vertragsabschluss eingesetzten Fernkommunikationstechnik, sofern nicht nach einem Grundtarif berechnet (kostenpflichtige Mehrwertnummern)
• Zahlungs-,Liefer– und Leistungsbedingungen, sowie Lieferzeitraum
• Bei Bestehen eines Rücktrittsrechts: Bedingungen, Fristen und Vorgangsweise für die Ausübung dieses Rechts inkl Muster-Widerrufsformulars
• gegebenenfalls Hinweis, dass der Verbraucher im Rücktrittsfall die Kosten für die Rücksendung der Waren zu tragen hat
• gegebenenfalls Hinweis, wenn vom Verbraucher ausdrücklich gewünscht, dass mit einer bestellten Dienstleistung noch innerhalb der Rücktrittsfrist begonnen wird und dass er für die erfolgte Dienstleistung im Rücktrittsfall ein anteiliges Entgelt zu zahlen hat.
• gegebenenfalls Hinweis über das Nichtbestehen eines Rücktrittsrechts oder die Umstände, unter denen der Verbraucher sein Rücktrittsrecht verliert
• Hinweis auf das Bestehen des gesetzlichen Gewährleistungsrechts
• gegebenenfalls der Hinweis auf allfällige Garantien und deren Bedingungen
• gegebenenfalls der Hinweis auf Verhaltenskodizes
• gegebenenfalls die Laufzeit des Vertrags oder die Kündigungsbedingungen
• gegebenenfalls die Mindestdauer der Verpflichtungen
• gegebenenfalls der Hinweis auf Kaution oder sonstige Sicherheiten
• gegebenenfalls die Funktionsweise digitaler Inhalte und Schutzmaßnahmen
• gegebenenfalls die Interoperabilität digitaler Inhalte mit Hard- und Software

• gegebenenfalls Zugang zu einem außergerichtlichen Beschwerdeverfahren

Diese Informationen, die oftmals typischer Inhalt von AGB sind, müssen dem Verbraucher klar und verständlich in einer dem verwendeten Fernkommunikationsmittel angepassten Art und Weise erteilt werden

Das E-Commerce Gesetz (ECG) wiederum sieht ausdrücklich vor, dass ein Diensteanbieter die Vertragsbestimmungen und allfällige allgemeine Geschäftsbedingungen dem Nutzer so zur Verfügung zu stellen hat, dass er sie speichern und wiedergeben kann. Diese Verpflichtung kann nicht zum Nachteil des Nutzers abbedungen werden und gilt für Verbraucherverträge  (B2C) genau so, wie bei Verträgen zwischen Unternehmern (B2B).

Dieser Link muss in der Abfolge des Bestellvorganges im Internet (auch) vor der definitiven Absendung der Bestellung bereitgestellt werden, da andernfalls der Kunde keine Möglichkeit hätte, vor Abgabe seines Vertragsangebotes den Inhalt der AGB zu lesen. Unzureichend ist es daher, den Hinweis auf die AGB (nur) versteckt auf der Website zu platzieren, während AGB, die dem Bestellicon unmittelbar vorangestellt werden, ausreichend sind. Sinnvoll ist es, die AGB sowohl allgemein auf die Website zu stellen, damit der Kunde sie in Ruhe lesen kann, und sie für die Gültigkeit im konkreten Vertrag im Bestellvorgang zu integrieren.

Tipp: Richten Sie Ihre Website so ein, dass der Kunde vor Abgabe der Bestellung auf einen Button drücken muss, mit dem er bestätigt, dass er die AGB zustimmend zur Kenntnis genommen hat.

Der reine Hinweis auf der Website, dass der Text der vertragsrelevanten AGB dem Kunden auf Wunsch zugesandt werden kann, genügt nicht dem Erfordernis der Kenntnisnahme vor bzw bis zum Zeitpunkt des Vertragsabschlusses und widerspricht auch dem ECG.

Vertragssprache

Es gibt keine ausdrückliche gesetzliche Bestimmung, die vorschreibt in welcher Sprache AGB abgefasst werden müssen, damit sie rechtsverbindlich werden. Dies kann im Bereich des Internet zu Zweifelsfragen führen, insbesondere dann, wenn der Kunde auf der Website eines fremdsprachigen Internethändlers bestellt.

Die herrschende Auffassung geht diesbezüglich  davon aus, dass es genügt, wenn der Text der AGB in jener Sprache abgefasst ist, wie der abzuschließende Hauptvertrag. Wenn somit mit einer englischsprachigen Website geworben wird, genügt es für die Verbindlichkeit der AGB unter diesem Aspekt, wenn auch die AGB englisch verfasst sind.

Allerdings kann diese Beurteilung bei Verträgen mit Konsumenten im Sinn des Konsumentenschutzgesetzes auch anders ausfallen, wenn das im Konsumentenschutzgesetz normierte Transparenzgebot so ausgelegt wird, dass Vertragsbestimmungen in AGB schon deshalb als unklar oder unverständlich abgefasst sind, weil sie nicht in deutscher Sprache verfasst sind. Höchstgerichtliche Rechtsprechung fehlt zu dieser Thematik noch, nicht zuletzt wegen der relativen Neuheit dieser Problematik.

Tipp: Sinnvoll ist es auf jeden Fall, sich am „Zielstaat“ zu orientieren, also jene Sprache(n) zu wählen, für die das Internetangebot gedacht ist und das auch auf der Website ausdrücklich (beispielsweise durch Länderwappen) klarzustellen.

Quelle: https://www.wko.at/Content.Node/Service/Wirtschaftsrecht-und-Gewerberecht/E-Commerce-und-Internetrecht/Vertragsrecht-im-Internet/AGB_im_Internet_-_allgemeiner_Ueberblick.html

http://www.ecommerce-blog.at/frontend/scripts/index.php?setMainAreaTemplatePath=mainarea_news.html&newsId=131

The post Webshop Bestimmungen appeared first on Mobile USTP MKL.

Was Google PageSpeed aber damit sagen will ist, dass externe CSS-Dateien (eingebunden via `<link>`) das Rendern der Seite im Browser blockieren. Das heißt, dass das Rendern erst fortgesetzt wird, wenn die Dateien geladen sind. Was auch logisch ist, die Informationen müssen ja erst heruntergeladen werden, was durch Latenz und Dateigröße zu Verzögerungen führen kann. Die Empfehlung ist daher den CSS-Code aufzuteilen: Ein Teil inline, den Rest wie üblich in der CSS Datei.

Der Inline-Teil (also direkt im `<head>` durch `<style>`) soll alles beinhalten, was zum rendern des Sichtbereichs („above-the-fold“, der Begriff kommt von Zeitungen, wenn diese gefaltet sind, ist nur der obere Bereich der Zeitung sichtbar) notwendig is. Dieser Teil wird als „critical“ bezeichnet. Der Begriff „critical“ kommt von Ben Edwards, der diese Teile im CSS mit „critical“ angegeben hat.

Welcher Code ist kritisch?

Hört sich im Prinzip einfach an, aber wie kommt man jetzt an den Code der benötigt wird? Man könnte schon während der Erstellung darauf achten und diesen dann manuell kopieren. Das Ganze natürlich für die mobile und Desktop Ansicht ermittelt werden.

Es gibt dazu ein paar nützliche Tools:

• CriticalCSS.js: Code in die Browser-Konsole kopieren und mit URL ausführen.
• Critial Path CSS Generator: URL eingeben, CSS eingeben, generieren.
• Chrome Dev Tools Snippet (kann als Snippet in den Dev Tools angelegt werden): CriticalCSS Bookmarklet and Devtool Snippet.js

Wenn der kritische Teil des CSS eingebunden ist, kann auch noch zusätzlich der restliche Teil asynchron geladen werden, z. B. mit loadCSS.

Automatisierung

Schöner wäre es allerdings, das ganze zu automatisieren. Dazu kann man z. B. das Build System Gulp verwenden. Auf der Github-Seite von Addy Osmani gibt es dazu ein umfassendes Tutorial. Der Workflow mit Grunt wird im NPM Critical Package beschrieben.

Der Ablauf für den Task ist wie folgt:

• Stylesheet-Dateien vom Quellverzeichnis in das Build-Verzeichnis kopieren.
  Notwendig für Fallback, falls kein JS aktiviert.
• HTML-Datei einlesen und critical CSS ermitteln (dazu können Parameter wie Breite und Höhe angegeben werden).

Das wars auch schon. Vorher sollte man in der HTML-Datei die `<link>`-Tags mit den CSS-Dateien annotieren, die man zu einer Datei zusammenfassen will. Die kritischen CSS-Regeln werden automatisch eigebunden. Außerdem ein Script (loadCSS), das sich um das asynchrone Nachladen der CSS-Dateien kümmert.

Nachteil: Die CSS-Dateien werden nicht geändert, d. h. die Regeln werden doppelt ausgeliefert, da mit dem Package die kritischen Regeln so gut wie möglich zusammengefasst werden. Hier besteht sicher noch Optimierungsbedarf des Packages. Dies kann z. B. mit CSS-Preprozessoren umgangen werden, indem man seine Dateien aufteilt und sich selbst um den Above-the-Fold-Code kümmert (also wieder manuell).

Ich habe das auch mit Gulp und der MFG-Website getestet, was auch ohne Probleme funktioniert hat. Da die MFG-Website aber ohnehin recht schnell lädt, konnte ich keinen Unterschied feststellen. Was lange gedauert hat zu laden, waren die Schriften (Stichwort: „FOIT“).

gulp.task('critical', function() {
    critical.generateInline({
        // Verzeichnis mit den Quelldateien
        base: 'src/',
        // HTML-Datei im Quellverzeichnis
        src: 'index.html',
        // Datei die das kritische CSS enthalten soll
        styleTarget: 'dist/critical.css',
        // Neue HTML-Datei mit kritischem CSS und "loadCSS"
        htmlTarget: 'dist/index.html',
        // Breite die abgesucht wird
        width: 320,
        // Höhe die abgesucht wird
        height: 480,
        // Minify
        minify: true
    });
});

Fazit

Auf kritisches CSS zu achten, ist zeitaufwendig, kann sich aber bezahlt machen. User sind schnell wieder weg, wenn sie das Gefühl haben, zu lange auf die Seite warten zu müssen. Und gerade bei mobilen Geräten verschafft es einen zusätzlichen Schub. Ob sich der Aufwand lohnt (vielleicht lässt sich die Seite auch in anderen Punkte optimieren? Vielleicht muss ich gar nicht so viele Ressourcen ausliefern?) muss jeder für sich entscheiden.
Wer HTTP/2 einsetzt, könnte auf solche Maßnahmen verzichten, denn damit lassen sich mehrere Requests mit einer Verbindung verarbeiten (Multiplexing) und Ressourcen können sich nicht mehr gegenseitig blockieren. Bis HTTP/2 aber allgegenwärtig ist dauert es sicher noch einige Jahre.

Zusätzliche Links & Quellen

• Authoring Critical Fold CSS – CSS Tricks
• Authorign Critical Above the Fold CSS – Ben Edwards
• Critical CSS – Smashing Magazine
• Penthaus Critical CSS Generator
• Critical CSS Filament Group
• Sammlung von Tools für Critical CSS
• Screenguide #28

The post Critical CSS appeared first on Mobile USTP MKL.

Durch Zufall bin ich zu einem Microsoft Band gekommen (die erste Version, nicht das 2015er, dass ja erst vor Kurzem vorgestellt wurde) und habe es mit einer Testperson getestet. Die Testperson benutzt wenig Technik (kein PC, kein Smartphone) wollte das Band jedoch unbedingt probieren. Davor wurde der Person natürlich bewusst gemacht, dass die erhobenen Daten des Bandes zur Auswertung an Microsoft gesendet werden müssen. Der folgende Bericht bezieht sich also auf das Band ohne der Verwendung eines Smartphones.

Funktionsumfang

Das Band hat 10 Sensoren:

• Optischer Herzfrequenzmesser
• Drei-Axen-Beschleunigungssensor
• Gyrometer für Drehbewegungen
• GPS
• Mikrofon
• Licht Sensor
• Sensor für (psycho)galvanische Hautreaktion
• UV Sensor
• Haut Temperatur Sensor
• Kapazitiver Sensor

Der Akku hält lt. Website zwei Tage, so war es auch beim Test. Innerhalb von 1,5 Stunden war er wieder voll geladen. Leider ist nur ein USB-Kabel dabei, aber kein Adapter für eine Steckdose. Um das Band zu verwenden benötigt man ein Microsoft Konto (mit Angabe von Daten wie Geburtstag, Geschlecht, Größe, Gewicht), sonst kann man das Band nicht aktivieren und auch die Daten nicht auswerten.

Zur Aktivierung kann man entweder die mobile App „Microsoft Health“ verwenden (für WP 8.1, iOS 7.1+, Android 4.3+) oder die Software Microsoft Band Sync für Windows oder OS X downloaden. Man braucht also kein Smartphone um das Band zu verwenden.

Das Band zeichnet während der Benutzung über den Tag hinweg Schritte, Puls, Distanz und verbrannte Kalorien (berechnet auf Basis Puls) automatisch auf. Es bietet viele Fitness-Features die als kleine Apps (Microsoft: Tiles) dargestellt werden: Programme für Laufen (Distanz-Aktivitäten, also auch Wandern, Gehen, Schifahren etc.), Radfahren, Workout (Fitness-Übungen wie Liegestütz, Sit-Ups, etc.) Schlaf, Golf und einen Trainigsplaner. Mit dem Trainingsplaner lassen sich Pläne auf das Band synchronisieren mit einem definierten Ziel. Das Web-Dashboard schlägt selbstständig (auf Basis der Daten) Pläne vor, man kann aber auch gezielt nach Plänen suchen bzw. welche anlegen.

Zusätzlich bietet es Tiles um es mit dem Smartphone zu koppeln: Neue Nachrichten anzeigen,  eingehend eAnrufe anzeigen, Kalendertermine anzeigen, Uhrzeit, Wecker und noch einige andere, die einzeln aktiviert bzw. deaktiviert werden können. Hat man ein Windows Phone kann man auch Cortona (Sprachassistent) verwenden.

Sehr positiv ist, dass man das eigene Smartphone beim Sport nicht dabei haben muss. Das Band reicht um alle notwendigen Daten aufzuzeichnen.

Für Entwickler gibt es SDK um eigene Microsoft Band Apps zu erstellen.

Daten

Das Web-Dashboard der Microsoft Health App bietet eine sehr gute Übersicht über die gesammelten Daten. Man sieht nicht nur die Daten sondern auch immer eine Bewertung ob man sich verbessert oder verschlechtert (Kardioleistung) hat bzw. Bestleistungen. Es ist auch möglich, sich mit anderen Personen zu vergleichen. Man sieht also wie Personen im selben Alter, etc. abschneiden.

Die Aktivität Radfahren zeigt zum Beispiel an, welche Distanz man gefahren ist, wieviele Kalorien man verbrannt hat, wo und wie schnell man gefahren ist und wie hoch der Puls war (Karte), geschätzte UV-Strahlung, Höhenmeter, ob man sich zur letzten Einheit verbessert hat und auch eine erwartete Erholungszeit.

Tragekomfort und Optik

Die Testperson trägt täglich eine Uhr und empfindet das tragen des Bandes deshalb auch nicht anders als das tragen einer Uhr (das ist sicher Gewohnheit bzw. individuelles Empfinden). Es gibt 3 verschiedene Größen (S, M, L) die sich dann auch noch etwas feiner am Arm einstellen lassen.

Optisch gefällt das Band der Testperson. Es ist in schlichtem Schwarz gehalten und sieht modern aus. Die Farbe der Benutzeroberfläche lässt sich in der App ändern.

Bedienung

Das Band einzurichten ist für Smartphone-BenutzerInnen sicher kein Problem. Die App downloaden, Bluetooth aktivieren, Konto anlegen und schon kann man die Daten synchronisieren. Auch am Pc ist es einfach: Programm downloaden, installieren, Band mit USB-Kabel verbinden, Konto anlegen, Synchronisieren.

Die Bedienung ist ebenfalls einfach. Man hat einen Standby-Button (sperren/entsperren des Geräts) und einen Action Button (Starten/Stoppen von Programmen). Die restliche Bedienung folgt über Touch. Auf der linken Seite gibt es immer einen Zurück-Pfeil um wieder ins Hauptmenü zu kommen.

Da das Display länglich ist und dem Band entlang läuft kann es manchmal schwierig sein Einstellungen darauf vorzunehmen. Deshalb wird das Band auch oft am Unterarm getragen, das macht das Ablesen und die Bedienung etwas leichter.

Was fehlt?

Das Band und die Software befinden sich in stetiger Entwicklung. Derzeit hat man keine Möglichkeit Musik zu wiedergeben, man kann auch mit Smartphone nicht die Musik-App des Smartphones steuern. Auch eine Navigations-Funktion ist nicht vorhanden. Alles in allem bietet es aber schon jetzt umfangreiche Funktionen.

Datenschutz

Leider muss man, um eine Auswertung seiner Daten zu bekommen, die Daten an Microsoft senden. Microsoft versichert zwar, mit den Daten sorgfältig zum zu gehen, ich verstehe jedoch den Grund nicht, warum man nicht auch eine lokale Software anbietet, die es mir ermöglicht meine Daten offline auszuwerten, ohne sie ins Unbekannte zu versenden. Es wird ja wohl nicht eine Serverfarm zur Auswertung nötig sein. Es könnte dem Benutzer selbst überlassen werden ob er sich mit anderen vergleichen will oder nicht.

Fazit

Das Band bietet umfangreiche Möglichkeiten um seine Gesundheits- und Fitnessdaten über den Tag aufzuzeichnen. Auch die Auswertung wird übersichtlich dargestellt. Man benötigt auch kein Smartphone um das Band zu verwenden. Dadurch kann man sicher spannende Dinge erfahren und auch gezielt Sport betreiben und seine Fortschritte beobachten. Das Band bietet sicher zusätzliche Motivation zum Sport. Alles in allem eine super Sache, doch großer negativer Punkt: man muss die Daten an Microsoft senden um eine Auswertung zu bekommen.

Links

• Microsoft Band
• Get Started
• Privacy Commitment
• Privacy Policy

The post Microsoft Band (2014) appeared first on Mobile USTP MKL.

Was ist ownCloud?

Mit ownCloud kann man seine eigene Cloud-Plattform einrichten, ohne die Daten in die Hand von Dritten geben zu müssen. Man benötigt einen Server mit PHP und optional auch MySQL/MariaDB oder PostrgreSQL, d.h. das Hosting der Daten wird in den meisten Fällen nicht selbst vorgenommen, denn die Wenigsten haben eigene Server zu Hause.
Von ownCloud gibt es eine Community Edition und eine Enterprise Version. Die Enterprise Version bietet zusätzliche Funktionen. Aktuelle Version (Stand: August 2015) von ownCloud ist 8.1.1.

Installation

Einfache Installation

Nach dem Download von ownCloud werden alle Daten auf den Server übertragen. Beim Aufruf im Browser muss man nur einen Benutzername und Passwort wählen, sowie die Speicheroption und gegebenenfalls die Zugangsdaten für die gewählte Datenbank.
Beim ersten Einstieg in ownCloud wird man auch gleich darauf hingewiesen, dass man sich verschiedene Apps downloaden kann, um auf die Daten zugreifen zu können. Es gibt eine iOS App, Android App und Clients für Windows, OS X und Linux.

Willkommen bei ownCloud

Seit Version 8.1 geht die ownCloud in die Richtung zu einer Platform für Apps. Man kann somit verschiedene Anwendungen nachladen, z.B. eine App für Notizen. Dies ermöglicht auch Programmierern Anwendungen zu erstellen und diese auch zu verkaufen. Standardmäßig sind die Apps „Dateien“, „Aktivität“ und „Bilder“ aktiviert.

In den Administrator-Einstellungen (rechts oben auf den Benutzernamen klicken und „Administration“ wählen) kann man jetzt noch verschiedene Einstellungen vornehmen, z. B. die Verschlüsselung für die Daten am Server aktivieren. Danach muss man aber noch in den Apps das „Default encryption module“ aktivieren. Nach einem erneuten Login ist das Modul aktiviert und die Daten werden verschlüsselt. Man kann sich auch einen Wiederherstellungs-Schlüssel erstellen, um im Notfall die Daten wieder entschlüsseln zu können. Um wirklich sicher zu sein, sollte man aber auch HTTPS verwenden, damit die Daten auch bereits bei der Übertragung verschlüsselt sind.

Dateien

Wie schon erwähnt bietet ownCloud kostenlose Clients für Windows, OS X und Linux an. Für iOS und Android gibt es ebenfalls eine App zum Download, diese kostet jedoch knapp 1 Euro. Mit diesen Clients kann man auf Dateien zugreifen.

Alternativ kann man mittels WebDAV-Protokoll auf die Daten zugreifen. Die meisten Betriebssysteme bieten dafür Möglichkeiten an. Die Daten werden dann aber nicht lokal gespeichert sondern direkt abgerufen.

Man kann zwar vorhandene Daten (z. B. Kalender, Kontakte) aus einem vorhandenen Programm exportieren und in ownCloud importieren, leider kann man aber nicht einfach vorhandene Daten mit ownCloud verknüpfen. Das heißt, man muss zuvor Daten einspielen, um diese dann abzurufen, es geht nicht umgekehrt. Ein Programm kann also vorhandene Daten nicht hochladen.

Kontakte und Kalender

ownCloud Kontakte

ownCloud Kalender

Mit ownCloud kann man die Protokolle CardDAV und CalDAV verwenden, welche den Zugriff auf Kontakt- bzw. Kalenderdaten ermöglichen. Viele Softwareprodukte bieten diese Möglichkeiten an. Zuerst müssen die beiden Apps in ownCloud installiert werden. Diese finden sich unter „Apps – Produktivität“.

Wie gesagt, kann man auch Daten importieren. Für die Kontakte habe ich einfach drei Testkontakte angelegt. Um den Kalender zu testen, habe ich einen Kalender mit Terminen für Fußballspiele als ICS-Datei heruntergeladen. Bei den Kontakten gibt es eine eigene Import-Option (links unten), den Kalender braucht man nur als ICS in die Dateien hochladen und öffnen, danach bekommt man die Import-Option. Zum Testen hab ich auch in den bereits vorhandenen Kalender „Persönlich“ drei Termine eingetragen.

iOS (8.1.2)

Für Apple User gibt es die iCloud. Laut Apple werden dort auch alle Daten verschlüsselt übertragen und gespeichert und der Schlüssel nur am Gerät des Benutzers abgelegt.

Unter “Einstellungen – Mail, Konakte, Kalender – Account hinzufügen – Andere – CardDAV-Account hinzufügen“ kann man die Adresse sowie die Zugangsdaten von ownCloud eingeben. Die Adresse findet man in der ownCloud Kontakte-App links unten. Das Synchronisieren hat gleich funktioniert, leider dann aber die erste Überraschung (siehe “Bug” weiter unten).

iPhone Kalender

Da zwei Kalender erstellt wurden, möchte ich einen zur Bearbeitung freigeben und den anderen nur zum lesen. Dazu habe ich in ownCloud einen neuen Benutzer erstellt, für den die Kalender freigegeben werden. Der Kalender wird gleich hinzugefügt wie die Kontakte. Bei der Kalender App für iOS darf man allerdings nicht den CalDAV-Link verwenden, sondern für iOS und OS X gibt es einen separaten Link, dieser findet sich links unten in den Einstellungen der Kalender App. Der einzige Nachteil hier ist, dass Benutzer, die mit eingeschränkten Rechten auf die Kalender zugreifen, die Einträge scheinbar ändern/löschen können, nach dem Abgleich mit dem Server diese dann aber wieder zurückgesetzt werden. Hier wäre es besser, wenn das iPhone sofort erkennt, dass man hier nichts ändern kann.

Das Ganze funktioniert auch am Mac (OS X 10.10.2) mit der Kalender- bzw. Kontakte-Anwendung. Für den Kalender muss man hier aber die PrimäreDAV-Adresse verwenden. Lokaler Sync zwischen einem PC/Mac und iPhone funktioniert über iTunes. Kommt jedoch ein drittes Gerät dazu kann es zu kleineren Problemen kommen.

Android (5.1.1)

Bei Android wird’s richtig unangenehm, denn das Gerät allein lässt sich ohne Google Konto schon fast nicht vernünftig nutzen. Man wird bei fast jeder Aktion darauf hingewiesen, dass man doch ein Google Konto anlegen soll, um die Daten zu synchronisieren.

Google Dienste verschlüsseln ihre Daten nicht, zumindest findet man keine Informationen darüber. Aus Sicht von Google macht das auch wenig Sinn.

Alternativ kann man eine andere Android Version wie Replicant oder CyanogenMod nutzen.
Zum Synchronisieren mit der eignen Cloud braucht man dann noch zusätzliche Apps wie aCal, CalDAV-Sync Free Beta/CardDAV-Sync Free oder DAVDroid. Der Download so einer Anwendung funktioniert üblicherweise (es gibt Umwege) auch über den Play Store, für den man einen Google-Account braucht. Ist das geschafft, funktioniert die Synchronisation mit ownCloud und den Kontakte ähnliche gut wie bei iOS. Beim Kalender gibt’s Probleme, da Änderungen und neue Termine nicht übernommen werden. Dazu habe ich die Apps CalDAV-Sync Free Beta und CardDAV-Sync Free verwendet. Für die Synchronisierung der Kalenderdaten gibt es auch auf GitHub den Hinweis, dass diese noch fehlerhaft ist und bei sensiblen Daten nicht verwendet werden sollte. DAVDroid kostet ca. € 3,- dürfte sich aber bei regelmäßiger Verwendung lohnen und scheinbar gibt es damit auch keine Probleme (ungetestet).

Ein lokaler Sync funktioniert mit Tools vom jeweiligen Handyhersteller (Samsung Kies, HTC Sync Manager etc.).

Windows Phone (8.1)

Der Cloud-Dienst von Windows heißt OneDrive und bietet nur für Business und SharePoint User Verschlüsselung an oder mit zusätzlichen Tools.

Um das Windows Phone 8.1 mit ownCloud zu synchronisieren, muss man einen Trick anwenden. Man geht auf „Einstellungen – E-Mail-Konten + andere – Konto hinzufügen – iCloud“ und gibt falsche Zugangsdaten ein. Das Gerät versucht zu synchronisieren. Danach kann man die Einstellungen des Kontos ändern. Leider akzeptiert das Windows Phone 8.1 (älter Versionen dürften CardDAV und CalDAV noch unterstützen) nur Server die HTTPS verwenden.

Obwohl die Server der FH auch über HTTPS erreichbar sind, habe ich es leider nicht hinbekommen mit ownCloud zu synchronisieren. Ich habe einiges versucht (Port 443 hinzufügen, Datum und Uhrzeit stellen, WLAN, Neustart) erhielt aber immer den Fehlercode 80072F06, was wohl auf ein Problem mit dem Zertifikat zurückzuführen ist. Man muss das Zertifikat selbst signieren und installieren, das war mir zu mühsam.

Schade, dass das Windows Phone CardDAV und CalDAV nicht unterstützt, man zwingt den Benutzer damit andere Dienste (z. B. OneDrive) zu verwenden. Eigentlich wäre ja schon die Basis dafür vorhanden (iCloud und Google verwenden CardDAV/CalDAV). Positiv ist aber, dass man viele andere Konten (iCloud, Google etc.) hinzufügen kann.
Auch ein lokaler Sync ist nicht vorgesehen, z. B. mit Outlook und funktioniert nur mit zusätzlichen Tools wie AkrutoSync.

Leider unterstützt Outlook von Microsoft von Haus aus auch kein CardDAV oder CalDAV sondern nur unter Verwendung von Plugins.

Bug: Kontakte

iPhone Bug Kontakte

Bei der Eingabe der Kontakte in ownCloud gibt es einen Bug (es gibt dazu bereits ein Issue auf Github). Gibt man den Namen im Feld „Name“ ein, wie man das auch vermuten würde, wir der Namen dann nicht richtig in Vor- und Nachname aufgeteilt, sondern im Feld „Nachname“ steht dann „Nachname;Vorname;;;“. Trägt man die Namen separat ein, funktioniert es. Auch ein Eintrag über das Gerät direkt hat funktioniert.

Fazit

Die Synchronisation von Kontakten und Kalenderdaten hat mit ownCloud am Besten mit dem iPhone funktioniert. Am schlechtesten mit dem Windows Phone. Bei Android funktioniert es halbwegs unter Verwendung von zusätzlichen Apps.
Interessant wäre noch zu wissen, ob und wie eine Synchronisation der restlichen PIM-Daten (Kontakte, Kalender, Aufgaben, Notizen) funktioniert.
Für ownCloud gibt es auch noch zahlreiche andere Apps (z.B. Fotos/Videos, Nachrichten, Bookmarks), auch hier wäre der Ablauf für die Synchronisation und gemeinsamen Zugriff/Nutzung spannend.
Der gegenseitige Zugriff der drei Cloud Anbieter (Apple, Google, Microsoft) funktioniert – teilweise direkt, teilweise mit zusätzlichen Apps – über alle 3 Geräte.

Quellen

Verlinkt

• ownCloud
  http://ownCloud.org/
• ownCloud Server or Enterprise – owncloud.com
  https://owncloud.com/owncloud-server-or-enterprise-edition/
• iCloud Sicherheit – apple.com
  https://support.apple.com/en-us/HT202303
• Google Verschlüsselung – heise.de
  http://www.heise.de/security/artikel/Warum-Google-uns-echte-Verschluesselung-verweigert-2191797.html
• Verschlüsselung in OneDrive – microsoft.com
  https://technet.microsoft.com/en-us/library/dn905447.aspx
• Boxcryptor
  https://www.boxcryptor.com/de/onedrive
• ownCloud und Windows Phone 8 – owncloud.org
  https://forum.owncloud.org/viewtopic.php?t=17433
• GitHub ownCloud Contacts Issue – github.com
  https://github.com/owncloud/contacts/issues/1028

Zusätzlich

• http://www.golem.de/news/owncloud-8-1-erschienen-wenn-die-cloud-zur-app-plattform-wird-1507-115091.html
• http://www.heise.de/ct/ausgabe/2013-11-Kalender-und-Kontakte-ueber-OwnCloud-synchronisieren-2322019.html
• https://blindfoldwindows.wordpress.com/2014/11/30/windows-phone-8-1-und-caldavcarddav-mit-baikal/
• PIM: https://de.wikipedia.org/wiki/Personal_Information_Manager
• https://fsfe.org/campaigns/android/liberate.de.html
• https://github.com/gggard/AndroidCaldavSyncAdapater/wiki/2-way-sync
• http://www.thewindowsclub.com/encrypt-secure-onedrive-files

The post ownCloud und mobile Geräte appeared first on Mobile USTP MKL.

User Accounts

Um schnell und einfach eine Benutzeranmeldung zu ermöglichen kann man folgende Packages hinzufügen:

meteor add accouts-password accounts-ui

Jetzt kann man in einem Template mit `{{> loginButtons}}` die Oberfläche für die Benutzeranmeldung hinzufügen. Welche Inhalte ein Benutzer sehen darf, bestimmt man am Besten vor den Router-Actions:

    /** About route */
    this.route('about’, {
        path: '/about,
        onBeforeAction: function() {
            if (Meteor.userId()) { // Wenn eingeloggter Benutzer
                this.render('header', { to: 'header' });
                this.render('about');
            } else { // Wenn nicht eingeloggt
                Router.go(‚index’); // oder „this.next() um bei der „action:“ weiter zu machen
            }
        }
    });

Wie schon bekannt, ist der Code im Lib-Ordner („lib“) am Client und Server verfügbar. Das heißt, jemand könnte die Datei ändern und Zugriff zu der Route haben, obwohl er nicht eingeloggt ist. Das ist richtig, deshalb ist es umso wichtiger, dass man dem Client nicht vertraut und Server Methoden verwendet um die Daten zu prüfen und nur autorisierten Benutzern entsprechende Daten liefert.

Mehr dazu:

• Meteor Accounts
• Restrict Routes auf Stack Overflow

Formulardaten und Template Context

Im ersten Artikel habe ich erklärt, dass jQuery bereits mitgeliefert wird und man deshalb auch einfach auf Formulardaten zugreifen kann. In Meteor gibt es aber einen eleganteren Weg, nämlich den Template Context zu verwenden.

Man übergibt das Template der Funktion und kann mit „.find()“ oder „.findAll()“ die gewünschten Daten holen.

/**
 * Form event listener
 */
Template.TemplateName.events({
    /**
     * Submit form
     *
     * @param  object e Event
     * @param  object t Template
     * @return bool   False, for preventing default action
     */
    '#form submit: function(e, t) {
        console.debug(t.find(‚#value’).value;
        
        t.find('#form').reset(); 

        return false;
    }
});

Durch die Verwendung vom Template kann man, wenn man eine verschachtelte Datenstruktur hat, auch auf die Elternelemente zugreifen. Mit „t.data“ stehen alle Daten zur Verfügung.

Im Template selbst kann man beim Rendern auch Ebenen nach oben gehen.
Hat man zum Beispiel ein Objekt von Benutzern („users“) und diese Benutzer haben mehrere Autos („cars“) mit Nummerntafeln und man möchte aber auch neben jeder Nummerntafel nochmal den Namen stehen haben, kann man in den Schleifen nach oben gehen.

{{#each users}}
    {{firstname}} {{lastname}}

    {{#each cars}}
        {{num}} belongs to {{../lastname}}
    {{/each}}
{{/each}}

Mehr dazu:

• Blaze TemplateInstance findAll
• Accessing Parent data in Meteor

Formulardaten und Reaktivität

Meteor setzt stark auf Realtime. Das heißt, dass sich alle Variablen in den Templates selbst automatisch aktualisieren, wenn es nötig ist bzw. wenn sich die Daten ändern.

Das funktioniert ohne weiteres zutun, wenn man Daten in die Datenbank speichert. Will man aber jetzt nur den Status am User-Interface ändern ohne die Werte schon zu speichern, weil zum Beispiel noch andere Angaben gemacht werden und die Eingabe evtl. auch noch abgebrochen werden kann.
Dazu verwendet man Sessions.

Ein Beispiel für einen Range Slider:

<!— Template „testSlider“ —>

<lable for=„slider“>Slider:</lable>
<input type="range" id=„slider“ name=„slider“ min="0" max="50" step="1" value="0" />
<output for=„slider“>{{slider}}</output>
```

```JavaScript
Template.testSlider.helpers({
    slider: function() {
        if (!Session.get(‚slider‘))
            Session.set(‚slider‘, 0);

        return Session.get(‚slider‘);
    },
});

Template.testSlider.events({
    'input #slider‘: function(e) {
        Session.set(‚slider‘, e.target.value);

        return false;
    }
});

Jetzt wird beim ändern des Sliders der aktuelle Wert in eine Session gespeichert und bei Bedarf ausgelesen.

Mehr dazu:

• Meteor Sessions

Template Helpers

Mit Template Helpers kann man zum Beispiel Ausgaben formatieren oder andere Daten anhand der ausgegebenen Daten nachladen.

Man kann für jedes Template eigene Helper definieren

Template.TemplateName.helpers({
    helper: function(context) {
        // do something…
    }
});

oder für alle Templates

Template.registerHelper(‚helper‘, function(context) {
// do something…
});

Verwendet wird das dann so im Template:

{{helper ouputVar}}

Der übergebene Context kann auch weggelassen werden, wird er verwendet, wird dementsprechend der Wert von „ouputVar“ der Helper-Funktion übergeben.

Mehr dazu:

• Meteor Template Helpers
• A look at a Meteor Template (Discover Meteor)

Up Next

Die nächsten Schritte wären, zu schauen, ob und wie die Sicherheit weiter verbessert werden kann und wie man das vorhandene Login-System verbessert (Benutzerprofile, etc.) bzw. ein Eigenes bauen kann. Ein weitere Schritt wäre, sich mit MongoDB weiter auseinander zu setzten, um bei größeren Projekten eine vernünftige Datenbank-Struktur aufbauen zu können.

The post Meteor – Teil 3 appeared first on Mobile USTP MKL.

Ordnerstruktur

Grundsätzlich ist die Ordnerstruktur frei wählbar. Bereits im ersten Artikel wurde eine Startstruktur vorgestellt, die auch in der Meteor Dokumentation vorgeschlagen wird. Diese Struktur habe ich auch beibehalten und man kann damit gut arbeiten. Wenn man ein größeres Projekt plant, sollte man vielleicht genauer darüber nachdenken (z.B. Ordern “views”, “models”, etc.). Es gibt dazu verschiedene Ansätze im Web.

• client
•     css
•     js
• lib
• private
• public
•      img
• server

Im „client“ Ordner habe ich noch zwei Unterordner („css“ und „js“) angelegt. Direkt im Client-Ordner befinden sich meine HTML-Templates, im JS-Ordner die dazugehörigen JavaScript-Dateien. Der CSS-Ordner enthält alle CSS-Dateien. Diese kann man auch wieder nach belieben organisieren, da gibt es verschiedene Ansätze (SMACSS, BEM, OOCSS, etc.).

Der Lib-Ordner (Zugriff von Server und Client) enthält eine Datei, die Collections von MongoDB lädt. Außerdem eine Datei „routes.js“, dazu unten mehr.

Der Private-Ordner ist derzeit noch leer (hier kommen Dateien hin, die nur vom Server gelesen werden können). Im Public-Ordner habe ich einen Unterordner „img“ angelegt, der meine Bilder enthält, die ich für das Layout (z.B. Logo, Sprites, etc.) verwende.

Im Server-Ordner gibt es eine Datei „methods.js“. Diese stellt Methoden für den Datenbankzugriff zur Verfügung und ist nur vom Server aus erreichbar. Genauso wie die Datei „publish.js“, die festlegt, welche Daten von der Datenbank zum Client geschickt werden.

Servermethoden und Sicherheit

Grundsätzlich kann jeder Benutzer alles in der Datenbank verändern. Um das zu verhindern, ist es am Besten, wenn man Servermethoden definiert. Also statt direkt am Client die Datenbankoperationen aufzurufen (Insert, Update, Remove, etc.) erstellt man Servermethoden. In diesen kann man dann z.B. prüfen, ob die Daten korrekt sind oder der User auch wirklich autorisiert ist die Datenbankoperationen auszuführen.

Zuerst muss man das Package „insecure“ entfernen:

meteor remove insecure

Dieses Packet erlaub es die Daten vom Client aus zu ändern. Das mag für Prototyping sinnvoll sein, aber nicht für echte Anwendungen. Nach dem entfernen des Packets funktionieren keine Datenbankänderungen mehr vom Client aus. Jetzt muss man Servermethoden verwenden.
Das schaut zum Beispiel so aus:

// „server/methods.js“

Meteor.methods({
    /**
     * Add record
     *
     * @param int id Id of record
     * @param boolean status New status, true or false
     * @return boolean True for success, otherwise false
     */
    updateActive: function(theId, setStatus) {
        if (!Meteor.userId())
            throw new Meteor.Error('not-authorized');

        return Record.update(theId, { $set: { status: setStatus } });
    },
});

Am client ruft man jetzt die Funktion auf:

Meteor.call(‚updateActive’, 1, false);

Damit lässt sich der Datenbankzugriff einschränken. Außerdem hat man einen weitern Vorteil der sich „Latency Compensation“ nennt. Während der Client den Request sendet, läuft eine Simulation direkt am Client die das Ergebnis anwendet. Wenn ein Ok vom Server zurück kommt, bleibt alles wie es ist, wenn nicht, wird das Resultat rückgängig gemacht.

Publish und Subscribe

Mit „Publish“ und „Subscribe“ gibt es eine weitere Sicherheitskomponente. Um nicht alle Daten an den Client zu schicken (z.B. private Benutzerdaten) wird zuerst das Packet „autopublish“ entfernt:

meteor remove  autopublish

Jetzt kann man im Ordner „server“ eine Datei „publish.js“ anlegen. Hier wird definiert, welche Daten zum Client geschickt werden sollen.

// „server/publish.js“

/**
* Publish user data
*
* @return object User
*/
Meteor.publish('userdata', function() {
    return Events.find({
        owner: this.userId
    });
});

Das vorherige Beispiel zeigt, wie man z.B. nur die Daten des aktuellen Benutzers zurückliefern kann, damit dieser Benutzer nicht andere Benutzerdaten einsehen kann. Am Client muss dann noch die Methode

Meteor.subscribe(‚userdata);

aufgerufen werden. Wenn man dann die Collection lädt und abruft, erhält man am Client nur noch die Daten des aktuellen Users.

Data = new Mongo.Collection(‚userdata);

var d = Data.find();

Die Variable „d“ enthält jetzt nur alle Daten bei denen die Eigenschaft „owner“ (Id des Benutzers), der des aktuellen Benutzers entspricht.

Iron Router

In Meteor kann man zwar verschiedene Templates dynamisch laden, wenn man jedoch separate Seiten mit einer eindeutigen URL erstellen will, stößt man schnell auf „Iron Router“.

Iron Router ist zwar nicht in Meteor enthalten, lässt sich aber einfach nachinstallieren und ist quasi der Standard-Router bei Meteor-Projekten.

meteor add iron-router

Mit Iron Router lassen sich Routen definieren und je nach Route verschiedene Templates rendern. Außerdem kann beim Routing schon bestimmt werden, welche Daten dem Template zur Verfügung gestellt werden und was angezeigt werden soll während die Daten laden.

Um das ganze dynamisch zu gestalten, kann man auch eine Layout-Template wählen in welches die Routen (an der Stelle „{{> yield}}“) gerendert werden. Außerdem können spezielle Regionen definiert werden, wie im folgenden Code („header“), der es erlaubt verschiedene Header zu rendern.

<!-- „client/layout.html“ -->

<head>
    <title>App Title</title>
</head>

<template name="layout">
    <header>
        {{> yield "header"}}
    </header>

    <main role="main">
        {{> yield}}
    </main>

    <footer>
        Footer
    </footer>
</template>

// „lib/routes.js“

/**
 * Router config
 */
Router.configure({
    layoutTemplate: 'layout' // Datei „layout.html“ im Ordner „client“
});

/**
 * Define routes
 */
Router.map(function() {
    /** Index route for all */
    this.route('index', {
        path: '/',
        action: function() {
            this.render('header', { to: 'header' }); // Template mit Namen „header“
            this.render('index'); // Template mit Namen „indes“
        }
    });

    /** About route */
    this.route('about’, {
        path: '/about,
        action: function() {
            this.render('header', { to: 'header' });
            this.render('about');
        }
    });
});

Das Beispiel zeigt ein einfaches Routing mit zwei Routen. Wenn man keine Action oder sonstiges hat, kann man auch z.B. einfach nur `this.route(‚contact’);` schreiben, dann wird beim Aufruf von „/contact“ das Template „contact“ gerendert.

Mehr zu Iron Router:

• Iron Router GitHub
• Iron Router Tutorial by Manuel Schoebel
• Meteor Tips – Iron Router Part 1
• Meteor Tips – Iron Router Part 2

Up Next

Im nächsten Artikel werde ich auf User Accounts und Templates (Verarbeitung von Formulardaten, Context, Helpers) eingehen.

The post Meteor – Teil 2 appeared first on Mobile USTP MKL.

Was ist Mobile Payment?

„Mobile Payment“ bedeutet, dass man Waren aller Art bei einem Händler mit mobilen Geräten (nicht nur Smartphones, sondern auch z.B. Mobiltelefone oder PDAs) bezahlen kann. Das Bezahlsystem beschreibt wie ein Kunde oder Kundin bezahlt bzw. die Transaktion abläuft.

Warum ist Mobile Payment wichtig?

• Reichweite
  2,2 Milliarden Menschen auf der Welt haben kein Bankkonto, aber 1,7 Milliarden dieser Menschen haben ein mobiles Gerät.
• Zusätzlicher Absatzkanal
  Es bietet dem Konsumenten einen zusätzlichen Weg um Käufe abzuwickeln
• Reduzierung von Kosten
  Mobile Payment erhöht die Kundenbindung und reduziert die Kosten für Banken, den Banken benötigen so weniger Ressourcen (zum Beispiel MitarbeiterInnen am Schalter), da Kunden von unterwegs Zahlungen und Überweisungen tätigen können.
• Gebühren
  Bei Kreditkarten-Transaktionen sind 5 Parteien (Konsument, Verkäufer, Handelsbank/Acquirer, Kartenaussteller/Issuer, Zahlungsnetzwerk) involviert, während bei mobilen Bezahlsystemen nur 3 Parteien (Konsument, Verkäufer, Payment-Provider). Somit fallen weniger Gebühren an.

Aktuelle Möglichkeiten

Account-Based Payment

Für „Account-Based Payment“ wird ein Konto bei einem Dritten benötigt, zum Beispiel bei einer Bank.

• Mobile Phone-Based Payment
  Bezahlt wird über die Rechnung des Mobilfunkanbieters.
  Beispiel: Kauf eines Tickets für die U-Bahn via SMS.
• Smart Card Payment Systems
  Basieren auf Karten die mit einem Chip ausgestattet sind.
  Beispiel: Bankomatkarte
• Credit Card Mobile Payment Systems
  Telefonnummer wird mit Kreditkartendaten verknüpft, statt über die Rechnung des Mobilfunker abzurechnen.
• Mobile POS (Point-of-Sale)
  Bezahlt wird mit einer Smartphone App.
  Beispiel: Starbucks App. Man zeigt dem Verkäufer den QR-Code der App. Dieser scannt den Code und kann zuvor aufgeladenes Guthaben abbuchen.

Mobile Wallets

Softwareanwendungen die auf mobilen Geräten laufen und Details des Konsumenten (Kontodaten, Kreditkartendaten, etc.) nennt man „Mobile Wallets“.

Hier gibt es zwei Unterscheidungen:

• Client Wallets
  Alle Informationen sind am Gerät gespeichert. Nachteil: Upgrades durch Wallet-Anbieter sind schwierig, da geräteabhängig, Restrisiko bei Diebstahl des Geräts.
• Hosted Wallets
  Daten werden auf dem Server des Anbieters gespeichert. Dadurch hat der Anbieter mehr Kontrolle über die Funktionalität und Sicherheit der Daten. Nachteil: Man muss die Daten einem Dritten anvertrauen, Restrisiko durch Hockerangriffe.

Probleme und Herausforderungen

Wie bei jeder neuen Technologie gibt es auch bei Mobile Payment verschiedenste Herausforderungen, nicht nur technologisch sondern auch kundenspezifisch.

• Kundenakzeptanz
  Aktuell gibt es kein einheitliches System. Während sich Unternehmen mit der Technik dahinter beschäftigen, machen sich Konsumenten mehr Gedanken um Datenschutz, Komfort, Mehrwert oder Sicherheit. Viele Personen wissen, dass es die Möglichkeit für mobiles Bezahlen gibt, nutzen es aber einfach nicht.
• Benutzerfreundlichkeit
  Solche Systeme müssen eine niedrige Lernkurve haben, einfach zu verstehen sein und Zeit sparen. Mobile Zahlungssysteme müssten die Benutzerfreundlichkeit von Bargeld erreichen.
• Sicherheit
  Ein System soll logisch und nicht manipulierbar sein (Daten dürfen nicht kopierbar sein). Anonymität muss möglich sein. Außerdem müssen Konsumenten den Anbietern vertrauen, dass diese ihre Daten gut schützen.
• Überprüfung/Kontrolle
  Konsumenten wollen überprüfen können, wann sie wo was ausgegeben haben. Dies steht etwas im Konflikt mit Sicherheit und Anonymität. Bargeld bietet zum Beispiel Rechnungen als Nachweis.
• Universell
  Mobile Bezahlsysteme müssen alle möglichen Szenarien abdecken: B2B, B2C, C2C, Inlandsüberweisungen, Auslandsüberweisungen, Micropaymment, Macropayment
• Zusammenspiel von Systemen
  Die unterschiedlichen Systeme müssen miteinander funktionieren und kompatibel sein.
• Kosten
  Es dürfen nicht mehr Kosten entstehen als bei der Verwendung von gängigen Systemen (z.B. Kreditkarte)
• Geschwindigkeit
  Durch die Verwendung von mobilen Zahlungssystemen darf keine zusätzliche Wartezeit für sich selbst oder Andere entstehen.

Erfolg

Es gibt durchaus Erfolgsgeschichten die das Potential von mobilen Bezahlmöglickeiten zeigen. Die folgenden Faktoren hängten stark mit dem Erfolg in Zusammenhang.

• Routine
  Wenn es sich mit den Gewohnheiten der BenutzerInnen vereinbaren lässt, finden solche Systeme mehr Akzeptanz. Zum Beispiel für Personen die jeden Morgen zu Starbucks gehen, lässt sich die Starbucks-App gut verwenden und in die tägliche Morgen-Routine einbinden.
• Sinn
  Personen die an einem Test teilgenommen haben, gaben an, dass ihnen manchmal spontan einfällt eine Rechnung bezahlen zu müssen. Dies ist mit mobilen Bezahlsystemen überall und jederzeit möglich. Außerdem gaben viele Personen an, oft ihre Geldbörse zu vergessen, nie aber ihr Smartphone.
• Gamification
  Es gibt Anbieter, die spielerische Element ein ihre Anwendungen einbinden. Das heißt, wer oft die Anwendung benutzt, bekommt Punkte oder Rabatte.
• Soziale Wahrnehmung
  Personen die solche Anwendungen verwendet haben, fühlten sich im Moment der Anwendung sozial stärker wahrgenommen. Sie beschreiben ein positives Gefühl, wenn andere Personen sie dabei sehen, wenn sie ihr Smartphone zum Bezahlen verwenden. Es ist fortschrittlich und nicht etwas Besonderes, denn nicht jeder verwendet es.
• Value Added Services
  Das Einbinden von Ergänzungsdiensten steigert den wahrgenommenen Nutzen von Anwender/-innen. Zum Beispiel kann man mit der Starbucks-App nicht nur bezahlen, sondern auch andere Informationen abrufen.

Lösungsansätze

Nicht alle Probleme und Herausforderungen haben Lösungsansätze. Aber es gibt gewisse Voraussetzungen die erfüllt sein müssen, damit sich Kunden/-innen auf mobile Bezahlsysteme einlassen.

• Geeignet für jeden Geldbetrag
  Zahlung von kleinen als auch von großen Geldbeträgen müssen möglich sein
• Verfügbarkeit/Szenarien
  Es müssen so viele Szenarien wie möglich abgedeckt werden. Bezahlsysteme dürfen nicht auf bestimmte Benutzergruppen (z.B. nur iOS Anwender) beschränkt sein.
  Serviceprovider, Banken und andere Parteien müssen zusammenarbeiten um die Kompatibilität der unterschiedlichen Systeme zu ermöglichen.
• Standards
  Service Provider sollen sich an existierende Standards halten um das Wachstum von mobilen Zahlungssystemen zu steigern.
• Live Demonstrationen
  Forschungen haben gezeigt, dass Live Demonstrationen (BenutzerInnen live zeigen wie sie die Systeme verwenden können und welche Vorteile sie dadurch haben) einen große Einfluss auf potentielle NutzerInnen haben. Der Bedienkomfort solcher Systeme ist ein wichtiger Faktor und solche Vorführungen steigern die Wahrnehmung der Anwenderfreundlichkeit.

Resümee

Die Seminararbeit und die Recherche haben gezeigt, dass es aktuelle eine unüberschaubare Anzahl an Lösungen im Mobile Payment Markt gibt. Einen eindeutigen Hardware- oder Softwarestandard gibt es (noch) nicht.

Ein Blick auf Entwicklungsländer hat gezeigt, dass dort mehr Potential besteht, da in diesen Ländern das Finanzsystem nicht so etabliert ist wie zum Beispiel in Amerika.
Kunden/-innen haben außerdem ein starkes Verlangen nach Datenschutz, Sicherheit und Transparenz. Es ist sicher ein schwieriges Unterfangen all diese Anforderungen an ein gutes System zu erfüllen, aber sicher nicht unmöglich.
Dennoch, wenn die Kunden ein System nicht akzeptieren, dann sollte nicht mit Zwang versucht werden eines zu etablieren. Schuld an mangelnder Akzeptanz ist nicht der Kunde, sondern das Produkt. Außerdem wäre es besser, die Kunden nicht nur zu befragen sondern Experimente und Live-Demonstrationen durchzuführen.

The post Mobile Payment: Bezahlmöglichkeiten, Probleme, Herausforderungen und Erfolgsfaktoren appeared first on Mobile USTP MKL.