App | Chrepps Blog

Tag: App

Fühlt sich wie Arbeit an – Rook Assistant Teil 6

Die TODO-Liste wird kleiner und das Ende ist in Sicht. Zählt man HTML und JavaScript zusammen, komme ich sogar schon auf 500 Zeilen Code. Vielleicht lässt sich das ja noch etwas entschlacken. Heute habe ich einen Stand, dem hauptsächlich noch diese Funktionen fehlen:

Mitspieler nicht eingeben, wenn 720 oder 1005 geboten wurde
Leere Eingaben verhindern Button-Klick
Prüfung, ob jemand mehr als 1000 oder weniger als -1000 Punkte gesammelt hat
Gewinner-Seite
Zurück-Funktion lieber nicht? (Die war einfach so bei Onsen UI dabei, aber ich bin nicht sicher, ob man sich damit nicht zu viel kaputt macht.
TESTEN!!! (Ja, ist keine Funktion, aber es muss ja irgendwo stehen)

Hey, das klingt ja fast nach einem klassischen 80% Status. Der Zeitpunkt, zu dem Entwickler in große Gefahr geraten, das „F“-Wort zu verwenden. Vorsicht! Sag lieber „Das Feature funktioniert auf diesem System mit folgenden Parametern“ oder „ich habe ein gutes Gefühl“. Sagt nicht „fertig“. Schon gar nicht zu einem Projektmanager!

Das bringt mich zu dem anderen Punkt für heute. Ich brauche mal ne Pause! Heute habe ich bemerkt, dass sich bei mir die gleichen nervösen Zuckungen ergeben, wie bei meinem richtigen Job, weil ich ja gerade nichts anderes mache als bei meinem richtigen Job. Es ist schon interessant, dass ich das Gefühl in der Planungs- und Konzept-Phase nicht hatte. Blöde Sache. Vor allem, wenn man wirklich gerne programmiert. Man sollte es wohl einfach nicht zu viel machen.

Lassen wir es also locker angehen. Besonders jetzt in der heißen Phase des Projekts, in der so manche eklige Sache aufploppen kann.

Pet projects will put you in your grave – Rook Assistant Teil 5

13. Juli 2018 / Christian / 0 Comments

Ich musste viel über den Satz nachdenken, den Dan Olson in einem Video über kreative Motivation brachte: „Pet projects will kill you“. Der Hintergrund dazu ist, dass er ein Verfechter davon ist, Projekte möglichst schnell abzuschließen. Er erwähnt auch eine Challenge, in der man sich vornimmt, etwas anzufangen und nach einer bestimmten Zeitspanne als fertig erklärt. Nicht „schau mal, was ich hier angefangen habe“, sondern „Es ist fertig“. Wenn man viele kleine Projekte beginnt, trainiert man die Fähigkeit, etwas anzufangen. Diese Übung trainiert die Fähigkeit, etwas abzuschließen.

Und jetzt stehen wir hier mitten in einem „Pet Project“, das einen unbekannten Fertigstellungsgrad hat. Mein erklärtes Ziel ist, dass dieses Projekt nicht meine Zeit unnötig auffrisst und ich will auch nicht in die Sunk-Cost-Fallacy rutschen, indem ich mir sage, dass ich ja schon bestimmt mehrere Tage in dieses Projekt gesteckt habe und ich es darum auch zu Ende bringen MUSS. Ich erinnere mich jetzt hiermit selbst daran, dass das Ergebnis nicht zu komplex sein sollte.

Onsen UI und meine Definition von Modi

Wo wir gerade bei komplexen Problemen sind: Ich benutze jetzt Onsen UI als Template fürs App-Design. Es hat eine Integration mit Vue.js und man kann typische App-Design-Elemente verwenden, ohne viel darüber nachzudenken. Es sieht ganz hübsch aus und ob die Verwendung einfach ist, muss ich noch herausfinden. Es macht aber einen guten Eindruck.

Erstmal muss ich wohl meine gerade gefundene Terminologie ablegen, denn in der Onsen-Welt (und in der restlichen Welt wohl auch) spricht man nicht von einem Modus, sondern von einer Seite. Im Kontext einer App klickt man etwa auf einen Button (<v-ons-button>) und der löst eine Event namens „pushPage“ aus, das eine andere Seite anzeigt. Diese Seiten funktionieren nach derselben Logik wie meine Modi, nur dass sie nicht so einen coolen Namen haben.

Leider musste ich fast alles von meinem bisherigen Code wegschmeißen, weil manche Sachen, die ich selber gebaut habe, automatisch von Onsen erledigt werden. Danke Onsen! Bisher habe ich noch nicht alles nachgebaut, was man beim letzten Mal gesehen hat, aber ich finde es eigentlich schon ganz nett.

Jetzt gehe ich zurück in meinen Alltag und die nächste Folge kommt dann… bald. Bestimmt!

Tutorial und erste Anpassungen – Rook Assistant Teil 4

11. Juli 2018 / Christian / 0 Comments

Ich wühle mich durch das Tutorial und schreibe parallel die ersten Zeilen HTML und JavaScript. Dabei fällt mir direkt eine Verbesserungsmöglichkeit im Design auf.

Der Startscreen

Den ersten und zweiten Schritt aus dem Konzept kann man zusammenfassen, weil der erste Schritt ja wirklich nur aus „Spiel starten“ besteht. Vielleicht füge ich irgendwann Optionen oder Statistiken hinzu, aber mit den Problemen kann sich Zukunfts-Christian beschäftigen.

Der neue Startscreen wird also direkt die Möglichkeit enthalten, ein Spiel mit vier oder fünf Spielern zu starten. Grundsätzlich verfolge ich das Ziel, die Anzahl der Modi so klein wie möglich zu halten. Darin liegt die Komplexität der App.

Konzept und Praxis

Über den Startscreen hinaus hat es sich als sehr nützlich herausgestellt, dieses recht ausführliche Konzept gemacht zu haben, weil ich direkt wusste, welche Elemente auf welcher Seite zu sehen sein sollten. Die verschiedenen Modi habe ich, nachdem ich die ersten zwei Seiten des offiziellen Tutorials (https://vuejs.org/v2/guide/index.html) gelesen hatte, direkt mit einer simplen Vue.js-Funktionalität umgesetzt, die sich „v-if“ nennt. Bei dem folgenden Code handelt es sich um meine aktuelle Version des Startscreens:

<div v-if="isVisible('screen_welcome')">
   <rook-headline v-bind:item="text.screen_welcome"></rook-headline> 
   <div><button v-on:click="startNewGame(4)">Spiel mit vier Spielern</button></div>
   <div><button v-on:click="startNewGame(5)">Spiel mit fünf Spielern</button></div>
</div>

Hier sieht man in der ersten Zeile direkt das „v-if“ und es bewirkt, dass der ganze Block nur dann angezeigt wird, wenn das Innere („isVisible…“) wahr ist. Der Modus hier nennt sich nun „screen_welcome“, also wird dieser Block nur dargestellt, wenn „screen_welcome“ als sichtbar gekennzeichnet wird. Auf diese Weise habe ich bereits die ganze Klick-Strecke umgesetzt. Sie hat noch keine Logik, also die Tabelle wird nach einem Stich noch nicht aktualisiert und die Optik war erstmal vollkommen egal. Hier ist ein kleiner Einblick als Gif:

Sehr praktisch war hier das Tool ScreenToGif. Es lässt sich einfach bedienen und liefert genau das, was ich brauche.

Das ist aber nicht so schön!

Anstatt die Logik zu Ende zu schreiben, werde ich mich jetzt doch schon mit der Optik beschäftigen. Mir ist da nämlich ein Framework über den Weg gelaufen, dass mir ganz gut gefällt. Es heißt Onsen UI und bis zum nächsten Artikel werde ich damit rumspielen.

Modi und Moden – Rook Assistant Teil 3

8. Juli 2018 / Christian / 0 Comments

Ein Teil meiner ursprünglichen Idee war, die App in mehrere Modi zu unterteilen. Das hilft mir, zu bedenken, was der Nutzer zu welchem Zeitpunkt sehen muss. Ob Modus der richtige Begriff ist? Es ist für mich jedenfalls ein hilfreicher Begriff. Man könnte es auch Unterseiten oder Schritte nennen. Hier sind die Modi, die mir bisher vorschweben:

Startbildschirm
Auswahl der Spieleranzahl
Eingabe der Spielernamen
Punktetabelle
Gebot-Abgabe
(optional) Erhöhung des Gebots
Mitspieler-Eingabe und Spielausgang
Punkte es gegnerischen Teams
Spielende

Noch schöner ist natürlich so „hübschen“ Wireframes wie da unten im Bild. Das hat tatsächlich länger gedauert, als gedacht. Fast das ganze Viertelfinalspiel zwischen Russland und Kroatien (incl. Elfmeterschießen) hat es gedauert. Es war aber auch ein spannendes Spiel. Zu beachten ist noch, dass das neunte Bild hier die Punktetabelle zeigt. Das war für mich der nächste logische Schritt hier. Vor allem, weil das Spielende nicht wirklich viel Funktionalität bietet. Wir kriegen das schon hin.

Wireframe der Modi

Welches Tool benutzt du da eigentlich zum Malen?

Sehr gute Frage. Also erstmal male ich nicht – ich bin ja kein Maler. Das Tool, mit dem ich diese Grafiken und auch das Flussdiagramm von Teil 1 gestaltet habe, ist draw.io! Wirklich ein tolles einfaches Tool für Grafiken aller Art. Aber keine Malereien.

Warum sind die Texte im Wireframe eigentlich englisch? Und was heißt Wireframe auf deutsch?

Irgendwie kam mir das Gestalten der Oberfläche schon wie Programmieren vor, also bin ich direkt ins Englische geswitcht. Natürlich werde ich nachher die echten Texte auf deutsch drin haben. Es soll ja für mich und meine Mitspieler sein. Wireframe heißt Drahtmodell und meint nichts anderes als einen Design-Entwurf, der rein funktional gedacht ist. Farben, Formen und Abstände sollen nicht beachtet werden. Es geht darum, sich und anderen klar zu machen, wie es funktionieren soll. Auch die räumliche Anordnung wird angedeutet, aber kann nachher noch verändert werden.

Warum stelle ich mir selber hier die Fragen?

Weil ich es kann! Und aus demselben Grund hier noch ein anderes wichtiges Thema: Modus ist ein viel besseres Wort als Status, weil die Mehrzahl im Deutschen wenigstens logisch ist. Wer kommt auf die Idee, dass die Mehrzahl von Status Status (Statuuus) ist und nicht Stati? Kann mir das irgendwer erklären?!?

Bis zum nächsten Artikel.

Konkrete Pläne – Rook Assistant Teil 2

7. Juli 2018 / Christian / 0 Comments

Beim letzten Mal habe ich grundsätzlich meine Überlegungen geteilt, wie der „Rook Assistant“ funktionieren sollte. Seitdem ist mir bereits aufgefallen, dass ich eine kleine Sache bereits übersehen habe. Für den Sieg ist es nämlich notwendig, zu behalten, ob jemand bereits ein Gebot gewonnen hat (nicht den Stich – nur das Gebot). Darum notiere ich es hier einmal. Ich könnte auch das Flussdiagramm anpassen, aber da es jetzt schon hier steht, ist es ja dokumentiert. Ihr könnt mich ja darauf hinweisen, falls diese Abfrage im Endprodukt fehlt.

Design

In einem ordentlichen Prozess käme jetzt der Punkt, an dem Konzeptioner und Designer das Aussehen des Produkts bestimmen. Man kann die App ja beliebig hübsch machen. Stattdessen werde ich mir wohl die komplette Funktionalität erstmal Programmierer-mäßig ohne besonderes Aussehen zusammenbasteln. Das heißt, ich schreibe alles schwarz auf weiß in einfaches HTML und sorge dafür, dass es das tut, was es soll.

Dem ganzen Spaß setze ich dann später eine Portion Bootstrap auf. Damit habe ich schon sehr lange nichts gebaut. Bootstrap ist extrem verbreitet und sollte in der Lage sein, die Bedürfnisse meiner App abzubilden. Am besten wäre natürlich eine schicke App-Optik. Da muss ich wohl noch etwas Recherche reinstecken.

Technologie

Jetzt wird es technisch! (Aber keine Angst, ich halte es oberflächlich) Nachdem die Entscheidung gefallen war, das Progrämmchen nicht als Android- oder iOS-App zu entwickeln, dachte ich zuerst, dass ich es einfach stumpf runterprogrammiere. Aber es sollte ja wenigstens eine kleine Lern-Lektion für mich sein, also bin ich nach etwas Grübelei zu dem Schluss gekommen, das Vue.js-Framework zu benutzen. Wie ich hörte ist das ja gerade total in. Vue.js ist wohl eine gute Wahl für schlanke Single-Page-Applications (SPA, also im Prinzip eine App, die auf einer Website läuft) und der Rook-Assistant wird mit Sicherheit eine SPA. Es gibt keine Server-Kommunikation oder so – alles läuft da wo man es sieht. Vermutlich werde ich nur die Basis-Funktionen von Vue.js benutzen, aber immerhin habe ich dann mal einen Blick in die Vue-Welt geworfen und meine Füße ins kühle Nass gesteckt.

Nächste Schritte

Offensichtlich steht erstmal ein Blick ins Vue.js-Tutorial an. Ich denke, ich hangele mich dort entlang und versuche, auf dem Weg schon ein Daten-Modell für die Rook-Assistant-App zu entwickeln. Mir schwebt da schon ein Array vor, der Objekte enthält, die Namen und Punktzahl des Spielers enthalten. Achja und ob der Spieler schon einmal ein Gebot gewonnen hat. Nicht vergessen!

Ein kleines Neben-Projekt – Rook Assistant Teil 1

6. Juli 2018 / Christian / 0 Comments

Rook ist ein Kartenspiel, für das es keine deutschsprachige Wikipedia-Seite gibt und es macht süchtig. Man kann es sich wie Skat vorstellen insofern, dass man vorher bieten muss und man spielt, wenn man das Gebot gewonnen hat, mit einem Mitspieler. Mehr will ich hier gar nicht zu den Regeln sagen. Entscheidend ist, dass man nach jeder Runde die gesammelten Punkte notiert und derjenige, der als erster mehr als 1000 Punkte hat, gewinnt das Spiel. Hat ein Spieler weniger als -1000 Punkte, werden auch die Punkte gezählt und derjenige mit den meisten Punkten gewinnt.

An sich ist es kein gewaltiger Aufwand, eine Tabelle auf einen Zettel zu schreiben, bei der die Spalten die Mitspieler (4 bis 5) sind und die Zeilen die Spiele, aber ich dachte mir, es wäre doch eine interessante Herausforderung, dem „Schreiber“ die Arbeit zu erleichtern, indem man die Ergebnisse in eine einfach App eingibt, die dann den Zwischenstand hübsch ausgibt, während man spielt.

Da real MVP

Als wir im letzten Herbst spät abends mit der Familie über eine solche App brainstormten, ist mir schnell klar geworden, dass wir ein sehr einfaches Minimum Viable Product (MVP) definieren sollten. Es gibt viele Features, die man sich gut vorstellen könnte, aber meine Zeit ist kostbar und es soll ja auch tatsächlich fertig werden. Darum habe ich entschieden, dass die App wirklich nur die Features bieten soll, die eine Papier-Tabelle auch liefert, aber etwas komfortabler. Wenn der Stand erreicht ist, kann man über weitere Features nachdenken.

Anforderungsaufnahme

Ok, ich entwickle die App ganz alleine und vermutlich könnte ich eine funktionierende Version an einem entspannten Nachmittag runterhacken, aber ich versuche jetzt mal, möglichst formal vorzugehen, ohne zu übertreiben. Meine App sollte wenigstens die folgenden Features beinhalten:

Neues Spiel starten (4 oder 5 Mitspieler)
Namen der Mitspieler eingeben
Neues Blatt starten
Gebot eingeben
Erhöhen (auf 360, 720, 1005)
Kartengeber eingeben
Ggf. Mitspieler eingeben
Eingeben, ob der Stich gewonnen oder verloren wurde
Eingeben, wie viele Punkte die Gegenseite gesammelt hat

Ist das alles? Am besten mache ich noch ein Flussdiagramm. Das eigentliche Spiel wird nicht abgebildet, sondern nur die Funktionen, die meine App haben soll.

Was jetzt? Ich denke, eine Art technisches Konzept wäre jetzt angebracht. Ein paar Ideen habe ich schon. Gegen eine native App habe ich mich bereits entschieden, weil es ja ein kleines Projektchen werden sollte und darum wird die Sprache wohl JavaScript sein. Mehr dazu schreibe ich dann im zweiten Teil.

Chrepps Blog

Bunt und granatenstark