Bislang ist die Web-Version von uns eher stiefmütterlich behandelt. Einige Features gehen nicht, manche sehen etwas seltsam aus. Bei einigen Funktionen ist uns absolut unklar, warum sie nicht funktionieren und teils aus Zeitmangel, oft aber auch aus Mangel an technischer Kompentenz werden diese Sachen einfach ignoriert. Wenn es in den App-Versionen läuft, passt das. Disclaimer vorne ran und gut.
An einigen Sachen wird sich zwar immernoch nichts ändern, dennoch wird der Web-Version ab der neuen Major-Version eine größere Bedeutung zukommen.
Nutzung durch Dritte
Eigentlich schon von Anfang an, war die Überlegung, den GC Wizard nicht nur als eigenständige App zu betrachten, sondern auch Dritten die Möglichkeit zu geben, auf die zahlreichen internen Tools zugreifen zu können. Wie wäre es, wenn man einer Webseite sagen könnte: „Bitte den markierten Text vom GC Wizard mal eben entschlüsseln!„; oder wenn Apps wie c:geo sofort den Code im Listing lösen könnte?
Der eine Weg wäre, dass die Apps eben eine eigene Tool-Sammlung implementieren und man darauf wartet, dass sich der x-te Programmierer findet, der ROT-13 zum aberhundertsten Male programmiert, diesmal eben spezifisch für jene Webseite. Der GC Wizard war immer als Community-Projekt gedacht. Und damit ist nicht nur die Kostenfreiheit und das OpenSource-Ding gemeint, sondern auch, die Nutzung durch Dritte. Doch der Weg dahin erwies sich als viel viel steiniger als ich es anfangs erwartete.
App-Anbindungen
Es gibt zahlreiche Diskussionen auf diversen Plattformen, auf denen wir bereits untersuchten, wie wir mit Apps wie c:geo direkt kommunizieren könnten. Früher wäre das alles gar nicht so kompliziert gewesen, doch mit den Jahren wurde aus Gründen der Sicherheit von Google und Apple ein einfacher Kommunikationsweg immer mehr verbaut. Es gibt zwar noch immer Möglichkeiten, zwei Android-Apps miteinander interagieren zu lassen, aber wir haben es beim GC Wizard eben nicht mit einer klassischen Android-App zu tun. Der GC Wizard basiert auf einer Technologie, die Android und iOS (und natürlich Web irgendwie) unterstützt, welche sich somit, grob gesagt, als eine Art Zwischenschicht vor das Betriebssystem setzt. Das macht alles ungleich komplizierter. Nun könnte man sagen, man schreibt eben getrennt einen Kanal für Android und einen für iOS, aber wir haben weder Zeit für zweigleisige Entwicklung noch entsprechendes iOS-Knowhow.
Der Weg, den wir jetzt sehen, ist, dass wir die Web-Version so ertüchtigen, dass Dritte nicht unsere App, sondern unsere Webseite um Hilfe bitten.
Deep Links
Nun wird den meisten von euch schon aufgefallen sein, dass die Web-Version gerade dann Probleme hat, wenn man auf spezifische Tools direkt zugreifen möchte. Es fehlt schlicht die Möglichkeit, ein solches via URL im Browser direkt anzusteuern. Wenn man das als normaler menschlischer User nicht schafft, wie sollte dann der Entwickler einer App das schaffen?
Somit ist der erste Schritt, endlich die so genannten Deep Links einzuführen, also die URLs für konkrete Funktionen. Wir haben es bisher deswegen nicht gemacht, da uns ein nachträglicher Einbau sehr kompliziert schien. Vor allem hieß dies, dass wir jedes einzelne Tool direkt anfassen mussten, was bei der schieren Menge einfach keiner machen wollte.
Mike hat jetzt allerdings einen Weg gefunden, diese Arbeit mehr oder weniger im Code zu automatisieren und konnte vor einigen Tagen mit einer Testversion aufwarten, die eine direkte Ansteuerung der einzelnen Funktionen erlaubt.
Web-API
Nun ist es also möglich, die URL für das entsprechende Tool als bekannt voraus gesetzt, von jeder beliebigen Stelle, einer App oder anderen Webseite, mit einem Klick das Tool aufzurufen. Eine Installation der App ist (obwohl natürlich gewünscht 😉 ) hier nicht einmal mehr notwendig. Allerdings natürlich dann ein Internet-Zugang. Das ist leider ein möglicher Nachteil.
Der nächste Schritt ist dann, dass der zu entschlüsselnde Code auch gleich mit übertragen wird, damit man nach einem Webseitenaufruf des GC Wizards nicht noch manuell den Text in das Feld eingeben muss.
Mittels sogenannter Query-Parameter ist auch dieser Schritt bereits erfolgt. In der URL kann alles mitgegeben werden, was das entsprechende Tool zum Arbeiten benötigt. Allerdings ist hier tatsächlich viel manuelle Arbeit zu leisten. Jedes GC Wizard-Tool ist in seiner Funktion sehr unterschiedlich. Jedes Tool benötigt andere Optionen und Parameter. Somit lässt sich hier leider nur wenig automatisieren. Deshalb haben wir uns dazu entschieden, diesen Schritt erst einmal nur mit einem beschränkten Set an Tools zu gehen und dann bei Bedarf Schritt für Schritt zu erweitern.
Nun ist es also möglich, von außen die GC Wizard-Webseite direkt mit dem gewünschten Tool aufzurufen, es mit Werten zu bestücken und das Ergebnis anzeigen zu lassen. Nach diesem Schritt haben wir die ursprüngliche App verlassen und starren auf einen Browser. Für die Benutzbarkeit der ursprünglichen App ist dies eher unschön, da man das Ergebnis a) nicht in dieser App direkt sieht und b) der Nutzer gezwungen ist, zwischen Browser und App hin und her zu wechseln. Eine richtig schöne Schnittstelle sollte eigentlich den Weg der Informationsgewinnung verschleiern. Klick – und schon steht der entschlüsselte Text da. Dass intern der GC Wizard um Hilfe gebeten wurde, sollte für den Nutzer eigentlich unsichtbar bleiben. Auch wenn wir uns dabei irgendwie um den eigenen Ruhm bringen, zugegeben 😉
Der letzte Schritt ist also, eine Schnittstelle anzubieten, die bei entsprechendem Aufruf einfach nur die Berechnung durchführt und die Daten – anstelle sie auf der eigenen Webseite anzuzeigen – direkt wieder an das Dritt-Tool zurück sendet. Dies wäre dann eine echte Web-Schnittstelle, eine sogenannte API.
Erste Tests von Mike sehen vielversprechend aus. Ob die Version 3.0 gleich eine entsprechende Reife dafür hat, werden wir sehen, aber sicherlich sind wir auf einem sehr guten Weg!
Erste Abnehmer für solch eine Schnittstelle stehen schon in den Startlöchern. So hat @capoaira schon vor vielen Monaten angefangen, ein Firefox-Plugin zu bauen, das es erlaubt, von beliebigen Webseiten aus den GC Wizard direkt ansprechen. Ich bin selbst sehr sehr gespannt, wie das wird!
Sollte der GCWizard nicht der Nachfolger von GCC sein und sich auf das Smartphone beschränken?
Was bringt es, den GCWizard noch weiter aufzublähen, wenn es im Internet schon genug Seiten gibt, die Codes via Browser entschlüsseln können, wie z. B. kryptografie.de ? Da ist auch jeder Code ellenlang erklärt. Das lässt keine Wünsche offen. Warum darauf Zeit verschwenden?
Der GCWizard soll doch bitte das bleiben, was er immer sein sollte: Nachfolger des GCC und damit eine Smartphone-App, die man unterwegs ohne Internet benutzen kann. Das ist für mich der Einsatzzweck.
Darum fänd eich es ganz toll, wenn die Zeit auf den Ausbau der Smartphone-App benutzt werden würde und das Rad nicht noch ein zweites Mal erfunden wird.
Danke für das Feedback.
Der GCW war mal als inoffizieller Nachfolger vom GCC angetreten, hat aber den Funktionsreichtum lange ein- und überholt. Natürlich wächst die App weiterhin, viele Features stehen in den Startlöchern. Und du kannst weiterhin völlig offline alle diese Tools zu benutzen. Das ist immer oberste Direktive und wird auch so bleiben. Da brauchst du keine Angst haben. Und natürlich steht es dir frei, weiterhin im Browser die anderen Tools zu benutzen.
Ich verstehe ehrlich gesagt nicht, warum du einerseits in Frage stellst, dass der GCW weiter „aufgebläht“ wird, du aber auf der anderen Seite den Ausbau der App forderst.
Die Webseite gcwizard.net war schon immer Teil des Projektes und gibt es von Anfang an. Es gibt sogar User, die die App gar nicht kennen oder benutzen, sondern nur die Online-Variante. Der GCW hat genau eine einzige Codebasis. Wenn wir ein Feature in die App einbauen, existiert es im Web genauso. Da gibt es keine bzw. nur bedingte Trennungen zwischen den Plattformen. Und nur deshalb können wir das so auch anbieten, sonst würden wir das nicht tun – dann gäbe es aber auch keine iOS-Version bspw. Unser Fokus lag immer auf der App (und wird es primär auch zukünftig bleiben), doch die Webseite kommt nun einmal einfach noch hinten mit raus, das kostet uns exakt 2 Minuten Arbeit pro Release mehr. Das nehmen wir dann einfach mit. Man kann sie aber auch prima ignorieren und weiterhin zu den anderen gehen. Gar kein Problem.
Das, was hier beschrieben ist, soll jedoch die Verwendbarkeit des GCW entscheidend erhöhen. Es geht nur sekundär um eine Webseite, sondern primär darum, dass die von uns geschriebenen Funktionen (wie gesagt, ob App oder Web ist egal, weil der gleiche Code) eben direkt in andere Tools integriert werden können, wie in andere Apps, etc. sodass du eben NICHT MEHR den Browser aktiv verwenden musst. Es geht darum, die Entwickler anderer Tools zu entlasten, damit sie nicht gezwungen sind, noch einmal Funktionen wie ROT-13 programmieren zu können, sondern auf unseren reichhaltigen Fundus direkt zugreifen können. Damit können die sich voll und ganz auf ihre eigentliche Arbeit konzentieren. Zusammenarbeit ist hier das Stichwort. Und das bietet bislang keine andere Online-Toolsammlung, soweit ich weiß – hier wird das Rad nicht zum zweiten, sondern zum ersten Mal erfunden.
Mir ist also, ehrlich gesagt, nicht ganz klar, was deine Bedenken sind. Nur weil wir zusätzliche Funktionen einbauen, ohne die alten zu beschränken, kannst du den GCW doch nach wie vor wie gewohnt nutzen. Die Offline-Fähigkeit der App wird doch durch eine Web-API nicht beeinflusst. Dich stören andere Neuerungen doch gar nicht. Für dich ändert sich nichts. Und wir werden dir auch weiterhin neue Features schenken – gebaut in unserer Freizeit.
Was UNSERE App „sein sollte„, das zu entscheiden überlass „doch bitte“ uns. Bitte denke immer daran, dass hier ein paar Leute sitzen, die einfach nur Spaß am Programmieren haben. Wir werden nicht dafür bezahlt und auch nicht von beruflichen, familiären oder anderen Pflichten dafür freigestellt. Wir sind auch niemandem etwas schuldig. Was wir mit unserer restlichen Freizeit anfangen, entscheiden wir „doch bitte“ absolut alleine. Und wir haben eben entschieden, in ebenjener Freizeit, den Radius des GCW ein wenig erweitern zu wollen. Einerseits weil es uns einfach Spaß macht und spannend ist, etwas neues zu lernen – was der Hauptmotivator für unser Tun ist – und andererseits, weil wir durchaus den Bedarf und Nutzen innerhalb der Geocaching-Softwarewelt sehen und glauben, noch mehr beitragen zu können.
Aber für dich wird sich nichts ändern.
Ich bitte tausend mal um Entschuldigung, falls ich dich / euch eventuell gekränkt habe.
Das war nicht meine Absicht. Ich wollte einfach nur meine Meinung äußern, die vielleicht auch andere teilen. Wollte da nichts lostreten… Und dir / euch schon gar nichts vorschreiben. Werde mich in Zukunft zurückhalten… wenn das so schnell missverstanden wird.
Es geht nicht um die Kritik oder kritische Nachfragen. Solange sie sachlich formuliert sind, sind wir immer froh darüber und bereit, sie zu bedenken oder zu diskutieren. Manchmal jedoch ist es der „Ton“. Und auf unserer Seite kam der für uns fordernde Ton bei allen komisch an.
Ok, der war nicht so gemein, alles gut. Schwamm drüber! 🙂
Wenn du weitere Fragen oder Hinweise hast, kannst du uns gern eine Email nach geocache.wizard@gmail.com schicken. Das ist vermutlich die bessere Plattform, um technische Details ausführlich zu besprechen.
> Erste Abnehmer für solch eine Schnittstelle stehen schon in den Startlöchern
Vor längerer Zeit gab es schonmal Überlegungen, den GC Wizard in den Formellöser von c:geo zu integrieren. Dann könnte man im Formeleditor etwas eintragen wie z.B.
GCW(BUCHSTABENWERT, „ABCDE“)
oder auch natürlich auch mit Variablen. Wenn diese Schnittstelle dann auch noch mit der App-Version funktionieren würde, könnte man das sogar offline umsetzen.
Ja, wir haben mit euch schon mal darüber philosophiert (https://github.com/cgeo/cgeo/issues/12389). Leider haben wir bis heute keine technische Lösung gefunden, die eine offline API bereit stellt. Also via Flutter und für uns natürlich möglichst plattformunabhängig. Wenn sich einer bei euch damit auskennt, dann ist er natürlich herzlich willkommen 🙂
Aber deswegen schlagen wir jetzt erstmal den Weg einer Web-API ein, um überhaupt ein wenig weiter zu kommen mit dem Thema. Ist dann leider eben nicht offline und es wird eben NICHT die installierte App angesprochen, sondern ein Server bei uns, der die API bereit stellt. Offline wäre ein Traum…