Kategorie: Software und Tools

Fazit vorweg: Conduit ist sehr einfach zu benutzen, scheint mir sehr durchdacht, sehr vielseitig und hat mir gut gefallen.

Ja, nun habe ich eine eigene App – so schnell ging das. Mittels „Conduit Mobile“ funktionierte das Erstellen rasch und schmerzlos und (bisher) sogar kostenlos. Die kleine Einschränkung „kostenlos“ rührt daher, dass nach 500 Downloads Schluss ist bzw. dann (aus meiner Sicht erhebliche) Gebühren von 29 Dollar im Monat fällig werden. Diese Summe reicht auch nur bis 5000 Downloads, danach wird es nochmals teurer.
Nun gut, aber zum Testen reicht das allemal, und mehr wollte ich in dem Fall gar nicht. Hier ein Erfahrungsbericht.

Screenshot des Web-Interfaces von Conduit bei der Entwicklung

Wie ist der Workflow beim Erstellen einer App mittles Conduit?
Über die Webseite http://mobile.conduit.com kann man sich nach Eingabe seiner Webseiten-URL eine App aus verschiedenen Bausteinen zusammen bauen. Dabei hat man stets die Möglichkeit, sich in einem Emulator anzuschauen, wie das Bisherige auf verschiedenen Systemen ausschauen würde: Das funktioniert ausgesprochen gut und man kann sich das Ganze im Quer- oder Hochformat anschauen. Bis dahin benötigt man noch keine Registrierung bei der Firma: Erst wenn man das Ergebnis sichern möchte, muss man sich registrieren. Danach kann man weiter an der App editieren oder gleich zum Veröffentlichen übergehen. Dies beginnt mit einer Art Marketing-Formular mit weiteren Daten zur App.

Dann geht alles ganz schnell: Die Web-App wird erstellt und die Android-App gleich mit dazu. Eine Windows-Phone-App wohl auch, aber das konnte ich mangels Gerät noch nicht testen. Eine iOS-App gibt es erstmal nicht, dafür wären weitere Schritte, u.a. die Zertifizierung durch Apple, nötig. Conduit legt sehr viel Wert auf Marketing, d.h. man erhält für seine Nutzer automatisch eine individuelle Webseite mit QR-Code  (s. Bild unten). Öffnet man diese mit einem Mobil-Gerät, so wird man sofort auf die Web-App weitergeleitet oder erhält die Möglichkeit zum Download der native App. Für iOS-Geräte reicht es übrigens, einfach die Web-App-URL auf den Home-Screen abzulegen, worauf man beim Aufruf der Seite gleich hingewiesen wird!
Apropos Kosten: Wenn man mit seiner App anschließend richtig in die bekannten App Stores möchte, enstehen erstens noch weitere Kosten und zweitens im Falle von Apple auch noch einige Arbeit. Die Gebühren für einen Android-Developper-Account liegen laut Conduit bei einmaligen 25 Dollar, die Gebühren für einen entsprechenden iOS-Developper-Account bei jährlich 99 Dollar.

Was kann man im Einzelnen mit den vorgefertigten Bausteinen tun?
Mein Eindruck: Conduit legt dabei den Schwerpunkt auf bekannte soziale Netzwerke und Web2.0-Dienste. Da muss man nur noch die URL und den öffentlichen Account-Namen (und vielleicht noch eine Playlist oder ein Album) eingeben und das war’s schon (Twitter, YouTube, Flickr). Mein eigenes Blog wurde per rss-Feed auch gut erkannt. Gar nicht erkannt wurde hingegen mein Podcast-Feed aus Loudblog; da musste ich mir dann einen Audio-Baustein manuell mit den gewünschten Podcast-Dateien und Texten zusammen bauen. Aber das ging ja auch. Wie ich meine php-basierten Diashows hineinbekommen hätte, weiß ich nicht und daher habe ich für den Test darauf verzichtet.
Man kann bei der Gestaltung der App aus verschiedenen Vorlagen wählen, wo und wie man die einzelnen Menüpunkte bei der App gerne hätte und auch die Farbgestaltung ist flexibel. Sehr schön und einfach also.
Das Ergebnis hat bei mir nicht so viel mit meiner eigentlichen Webseite zu tun und ich glaube auch nicht, dass man mittels Conduit eine 1:1 Mobile-Variante erstellen kann, aber das ist auch nicht Sinn der Sache. Sondern die Stärken liegen eher darin, verschiedene Quellen zu bündeln und über eine App anzubieten.
Meine Test-Bausteine finde ich in der Kombination auch nicht unbedingt einer App wert, aber mir ging es ja auch darum, zu testen, was technisch machbar ist. Mit diesem Hintergrundwissen könnte ich nun abschätzen, was mittels dieser Technik eine sinnvolle App wäre 😉

Web-App oder Native-App?
Per Conduit erhält man Beides – aber natürlich ist entscheidend, was man eigentlich als Quelle und Bausteine benutzt hat. In meinem Fall wäre die App offline absolut unbrauchbar, weil ich nur Online-Dienste eingebunden habe, die einen Netz-Zugang erfordern.
Native Apps haben aus meiner Sicht generell 4 Vorteile:

• Man könnte einrichten, dass Inhalte offline nutzbar wären (was ich immer noch für den Hauptvorteil halte).
• Man könnte Dinge nutzen, die technisch nur als native App programmierbar sind (also man hätte u.U. weitere attraktive Funktionen).
• Man kann Dinge übersichtlich zusammen bauen, die technisch auf einer Webseite nicht zusammen abbildbar wären (verschiedene Server etc.).
• Es ist natürlich cooler, eine eigene App in einem der bekannten Stores zu haben.

Für mein gewähltes Testbeispiel greifen diese alle nicht, da reicht also die Web-App-Variante.

Statistik
Als eingeloggter Nutzer erhält man bei Conduit eine ausführliche Nutzungs-Statistik der App: bisherige Downloads, Art der Systeme, Land etc.

Quelle
Auf Conduit aufmerksam geworden bin ich übrigens durch einen Bericht in der Zeitschrift „Page: Ideen und Know-how für Design, Werbung, Medien“, Ausgabe 04.12, Seite 094

Last but not least – Der Link zu meiner neuen App:

http://idethloff.mobapp.at/

 

P.S. Meine ersten Web-App-Versuche liegen schon lange zurück, damals per iWebKit, das mir sehr gut gefallen hat (s. Blogeintrag vom 11. April 2010)

 

Update 2018: Die Links sind außer Betrieb; das Projektergebnis existiert nicht mehr.

Ansicht auf dem iPad während einer Beamer-Keynote-Präsentation

Mobiles Lernen finde ich nicht nur ein wichtiges Thema, sondern beschäftige mich auch selbst recht intensiv damit. Veschiedenste Geräte mit iOS und Android zu testen, um zu schauen, wo Möglichkeiten und Grenzen liegen, finde ich sehr spannend.

iPad und Beamer
Der iPad lässt sich dann doch leichter mal zu einem Termin oder auf eine Tagung mitnehmen als mein Macbook Pro, insbes. wenn es nur darum geht, mitschreiben zu können oder im Web etwas zu zeigen. Leider treffe ich bei Webseiten doch recht häufig auf Probleme (Flash, Java oder Formularfelder, in die sich nichts eingeben lässt…). Dafür ist das Gerät unschlagbar schnell einsatzbereit und leise – die Displaygröße ist dabei sehr brauchbar und die Bildschirmtastatur sehr gut zu benutzen. Das eduroam hat auch schon gute Dienste geleistet und funktioniert wunderbar auf dem iPad.

Interessant wird es dann, wenn man sich den Dock-VGA-Adapter für den iPad leistet: Da kommt nicht etwa das heraus, was man erwarten würde (nämlich ein 1:1-Bild), sondern entweder nichts (das ist bei den allermeisten Apps so) oder tatsächlich das gewünschte Bild. Das Ganze ist abhängig von der jeweiligen App.
Durch Recherche vor dem Kauf des Adapters wusste ich das zwar, war aber erstaunt, dass Nutzerbeschwerden von 2010 immer noch dermaßen aktuell waren: Warum hat Apple etwas dagegen, dass man Webseiten auf den Beamer projiziert??

Folgende Apps haben bei mir gut an verschiedenen Beamern funktioniert:

• Keynote
• Videos
• Fotos(-Diashow)

Webseiten
Definitiv nicht über Beamer gehen: Safari, Opera mini, Atomic Lite – d.h. normale Webbrowser-Apps. Nach einiger Recherche habe ich dann aber doch eine aktuelle App gefunden, die über VGA Webseiten zeigen kann, nämlich „2ScreensLE“ für 1,59 Euro. Wenn man mal davon absieht, dass bei mir hin und wieder genau der interessante Button zur URL-Eingabe verschwand, hat der Rest gut funktioniert.
Jedoch finde ich es ziemlich erstaunlich, dass Apple offensichtlich keinen Bedarf sieht, Safari Beamer-fähig zu machen.
Ich frage mich, wie viele iPad-Nutzer schon einen VGA-Adapter gekauft haben und sich dann bei Vorträgen wunderten, dass sie keine Webseiten zeigen konnten…

Ein Vortrag mittels iPad
Vorgestern abend bei meinem Hörsaal-Vortrag auf dem RNIT-Frauen-Treffen habe ich es einfach mal versucht: Meine ursprünglichen PPT-Folien vorher nach Keynote importiert, kleine Korrekturen gemacht (es wurden nicht alle Schriften erkannt, einige Abstände stimmten nicht) und dann von Keynote aus den Vortrag gehalten.
Es hat hervorragend funktioniert: Die Einstellung mit 2 Folien nebeneinander ist wirklich brauchbar und der in Keynote integrierte Pointer eine feine Sache. Akku war kein Problem und Hitzeentwicklung auch nicht.

Meine schöne Idee, sozusagen als Intro zum Vortrag im Hintergrund per Diashow Bilder zu E-Learning laufen zu lassen, hat nur halb funktioniert. Die Screenshots, die ich zuvor direkt am iPad gemacht hatte, waren halt alle senkrecht und haben dadurch viel Platz verschenkt. Die Idee dazu kam mir leider erst kurz vorher, sonst hätte ich auch normale waagerechte Bilder erstellen und dann per iTunes-Album auf den iPad synchronisieren können. Das nächste Mal 🙂

 

Fast 1 Jahr nach meinem ersten Bericht habe ich mir aus aktuellem Anlass heute wieder mal die mTouch-App (nun Version 2.1.0) angeschaut.
Die magische Zahl meiner per mtouch angezeigten Kurse liegt immer noch bei 21, d.h. nach wie vor fehlen etliche Kurse in meiner Ansicht. Dafür werden Wikis, Lektionen, Tests, Befragungen etc. jetzt in einem internen Browser (und nicht über die Safari) angezeigt – d.h. man bleibt bei Ansicht dieser Aktivitäten in der mTouch-App, was ich deutlich besser finde. Übrigens habe ich heute auch die Logout-Möglichkeit gefunden – man muss einfach auf „Login“ klicken – nicht gerade nahe liegend, funktioniert aber.
Nach wie vor gilt für mTouch die Einschränkung auf Studenten.

Was inzwischen neu ist, ist die spezielle mTouch-App für iPad namens „mTouch+“, die sich nach der Beschreibung im AppStore und den dortigen Screenshots deutlich von der anderen unterscheidet. Dafür wollte ich jetzt aber keine erneuten 2,39 ausgeben. Und außerdem denke ich, dass der iPad-Bildschirm groß genug ist für eine Moodle-Nutzung per Webbrowser.
(2,39 ist offensichtlich der Preis, den der Hersteller für alle Apps nimmt, denn die dritte im Bunde namens „moodlEZ“, offensichtlich ab Moodle 2.x, kostet auch 2,39.)

Und was machen die Alternativen? Seit ich das letzte Mal geschaut habe, kostet nun auch die mPage-App etwas (zumindest eine der beiden angebotenen Apps namens „mPage 2G“). Und nach wie vor brauchen sowohl mPage als auch die App „mBook“ eine Serverseitige Änderung. Von daher kommen die beiden für mich derzeit nicht in Frage.

Interessanter dann vielleicht die Entwicklungen bei Moodle 2.x für die „official mobile apps being developed by Moodle HQ“ (s. http://docs.moodle.org/dev/Mobile_app). Wobei die Umstellung auf Moodle 2.x derzeit bei uns noch kein Thema ist.