Fragen zum Projekt 'Eine App entsteht'

  • Moin!


    Nachdem ich einen anonymen Tipp bekommen habe, das eventuell auftauchende Fragen im Eine App entsteht ungestellt bleiben könnten, da befürchtet wird den Fluss zu unterbrechen:


    Hier also können alle Fragen, Anregungen und Diskussionen diesbezüglich landen.

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Daraus folgt: je mehr Käse, desto weniger Käse.


    »Dies ist ein Forum. Schreibt Eure Fragen in das Forum, nicht per PN!«

  • Da es relativ unüblich ist Buttons in Android andere Formen zuzuweisen (hab ich so zumindest in keiner Systemapp je gesehen), würde ich noch den Tipp geben, stattdessen die Farbe des Buttons je nach Funktionalität zu ändern.


    PS: Github bietet eine Übersicht (Aber die ist natürlich nicht so schön wie die deiner vorgestellten apps, ich kann auch in der kommandozeile "git history" und "git diff" empfehlen.) https://github.com/marcofeltma…racker/TimeRecording.java

  • Zwei gute Hinweise (und danke für's Pinnen).


    1) Aktuell kann der geübte Entwickler am Layout erkennen, dass das zwei ganz simple Systembuttons mit unterschiedlichen Texten sind, die auch noch weit voneinander entfernt sind.
    Nicht weit genug, um auf einem ldpi Display und ausladender Beschreibung auf Hebräisch das Überlappen der Buttons zu verhindern.
    Farben, Formen, Größe, Positionen sind allesamt (laut Test) vollkommen undefiniert. Fest steht nur:

    • 2 Buttons (wo auch immer platziert, wie auch immer gestaltet.)
    • Einer mit lokalisiertem Titel für 'Kommen', einer mit lokalisiertem Titel für 'Gehen'.
    • Beide sind nie gleichzeitig zu sehen.

    Alles Andere wurde vom UX Team noch nicht definiert (die UX Akzeptanztests in einer repräsentativen Gruppe von Freiwilligen laufen noch) und wird daher vom Test auch nicht abgedeckt.


    Man sieht schön: Tests verhindern Fehler nicht. Sie garantieren nur, dass das, was einmal galt, auch weiterhin gilt.


    2) Da hast Du natürlich völlig recht.
    So ein beherztes git log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n'' %C(white)%s%C(reset) %C(dim white)- %an%C(reset)' --all hat die Übersicht schön und ist wesentlich performanter als die Apps.
    Ich hatte ursprünglich den Weg dieser Online-Maßnahme gewählt um es dem Interessenten möglichst einfach zu machen Änderungen auf Dateiebene verfolgen zu können.
    Leider hat mich meine Erinnerung da getrollt und mich die wirklich informative (und überladene) UI von BitBucket mit der simplen und zügigen (dafür leicht unübersichtlichen) UI von GitHub verwechseln lassen.


    Git-Profis, SCM-Freunde und alle, die täglich damit zu tun haben wissen auch, wie sie effektiv an die Informationen ran kommen.
    Als ich mit dem Kram angefangen habe, wurde CVS gerade von SVN abgelöst und keine Sau hat sich um Mercurial geschert. SVN war state-of-the-art und es war gelinde gesagt die Hölle, das irgendwie zum Laufen zu bekommen - trotz einiger fähiger UI Anwendungen.
    Sehen, benutzen, vergleichen ist da irgendwie einsteigerfreundlicher. Und das geht mit diesen Apps intuitiver als über GitHub (oder gar die Konsole.)

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Daraus folgt: je mehr Käse, desto weniger Käse.


    »Dies ist ein Forum. Schreibt Eure Fragen in das Forum, nicht per PN!«

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!