Re: Geizhals-App

Hier mein Feedback, da es etwas länger wird unterteile ich es in Abschnitte und beschränke mich auf die Android app, da ich diese selbst verwende.

Design:

1) Die App folgt nicht den Design Guidelines für Android. Das bedeutet nicht, dass die App frei von Branding sein soll, aber Standardelemente wie Navigation sollten doch besser den Guidelines folgen, damit ein User nicht erlernen muss, wie sich die Elemente bei Interaktionen verhalten.

2) Von Back Buttons in der Actionbar wird abgeraten. (da Android einen Back Button hat)

3) Die vorhandene Up Navigation wird wird nicht durch einen Pfleil erkennbar gemacht.

4) Das Microfon Icon ist redundant, da es ein Teil der Suche ist und folglich aufklappen sollte im Input Feld wenn das Suchicon gedrückt wird. Ebenso könnte man den Barcode Scanner in die Suche verlagern, da es ebenfalls Teil der Suchfunktion ist.

Hier ein Beispielbild wie das aussehen könnte:

vor dem starten der Suche:
https://lh6.ggpht.com/TNkgA1wg7EbZrWleQgGkuAXw_0S-DFXx_0kW0bzhGuht37zMI5xr9TYVXZf_PSkF8Q=h900-rw

nach dem starten der Suche:
https://lh3.ggpht.com/iKrKMEdyV6Ujefl9GlClqVmLiA8_pzuuZrn_XQH87cmBBi3BygdM353vAz4jO_w2jMY=h900-rw

5) Es ist noch ein Legacy Menü Button vorhanden, obwohl Menüs seit Android 4.0 nicht mehr auf diese Weise versteckt werden sollen. (4.0 ist immerhin bereits 2011 released worden)
Auch ist dort die Suche noch einmal vorhanden.

6) Iconographie: Es sind keine hochauflösenden Icons vorhanden. So ist das App Icon auf einem Nexus 5/ Galaxy SIV verschwommen. Auch folgen die Icons nicht den Design Guidelines.

7) Tablet Unterstützung auf Android nicht vorhanden. Ich würde annehmen, dass Android Nutzer eher Geizhals Nutzer sind, da sie öfter auch ihre Rechner aus Einzelteilen bauen, oder zumindest aufrüsten. Aber da könnte ich auch falsch liegen.

Funktionalität:

1) Suche: Habe dazu eher gemischte Gefühle. Neige aber eher dazu zu sagen, dass die Suche nicht die Kategorien filtern sollte, und stattdessen auf Produkt Eben filtern sollte.

Da ist die Frage, wie die Nutzer häufiger suchen. Geben sie beispielweise eher allgemeine Wörter wie "CPU" ein, und erwarten sich alle Kategorien in der jeweiligen Hierarchie Ebene, auf die "CPU" zutrifft (Ist Zustand), oder geben sie häufiger Produktnamen wie "Lenovo W520" ein, und erwarten sich als Ergebnis das tatsächliche Produkt, statt der Kategorie Hierarchie, durch die man sich erst korrekt klicken muss.

2) User Experience beim Filtern von Ergebnissen:

Ich würde bevorzugen, wenn die Ergebnisse der Subkategorie zuerst geladen werden, und dann in Echtzeit darauf vom User gefiltert wird. Aktuell lädt man anscheinend zuerst alle möglichen Filter in einer Query (die sehr lange dauert), stellt anschließend die gewünschten Filter ein, und dann wird noch einmal das gefilterte Ergebnis in einer zweiten Query geladen. (dauert noch viel länger - 5 Sekunden und mehr)

Das ist insofern problematisch, als dass man beim nachjustieren der Filter wieder und wieder in einem sehr langen Ladevorgang gefangen ist, da man immer wieder herausspringen muss, und die App anscheinend keinen Cache zur letzten Suche anlegt. Da verliert man schnell die Lust um nach einem Produkt zu suchen.

Würde also vorschlagen entweder die Datendichte dessen was angezeigt wird zu reduzieren, damit man es Cachen kann, oder (und das finde ich besser) die Anzahl der gelieferten Ergebnisse zu limitieren, und nach Bedarf im Hintergrund nachzuladen wenn der User runter scrollt.

Wieso sollte die API 2000+ Ergebnisse zurückliefern und somit die Request Time vervielfachen, anstatt nur 50 zu liefern und im Hintergrund nachzuladen? (sodaß der User nichts davon merkt)

Damit sollte auch die Request Time auf unter 1 Sekunde gebracht werden können. Auf diese Weise könnte man dann dem User das Gefühl geben, er würde den Datensatz in Echtzeit filtern.

3) Technische Probleme: Auf meinem Nexus 5 geht die CPU in die Knie (unter 5 Frames/Sekunde) wenn durch eine Liste mit 2000+ Ergebnissen (die nur Text enthalten) schnell gescrollt wird. Die Lösung für diesen spezifischen Fall wäre die View Holder Pattern zu implementieren, (Link: http://developer.android.com/training/improving-layouts/smooth-scrolling.html ) aber generell kann man sagen, dass aufgrund der Tatsache, dass die App scheinbar keine Libraries verwendet das Rad ständig neu erfunden wird, und dieses Rad qualitativ nicht mithalten kann mit den großen Open Source Lösungen, die schon in tausenden Apps Verwendung finden, und von vielen Entwicklern laufend verbessert werden.

Da geht sicher einmal etwas bei den HTTP Requests verloren, auch wird die UI generell nicht so schnell gerendert wie das eigentlich ginge.

Sonstiges:

1) Keine Share Funktionalität: Ich rate dazu, dem User die Möglichkeit zu geben, seinen Freunden/Bekannten einen Link zur App schicken zu können. Das muss gar nicht im Vordergrund stehen, macht es jedoch der zufriedenen Usern weitaus leichter auch andere auf die App aufmerksam zu machen.

2) Kein Analytics: Ist zwar eventuell etwas das von euch abgelehnt wird, aber dennoch ist es eine Überlegung wert. Ich nutze es meistens, da ich ansonsten nur schwer die Key Performance Indikatoren messen könnte.

Andernfalls wird es schwierig zu ermitteln, ob ein neues Feature gut ankommt, oder welche Teile der App überhaupt nicht genutzt werden, und folglich überarbeitet/entfernt werden sollte.

Man kann sicher auch über die API Nutzung messen, jedoch kaum mit dieser Präzision.

Hoffe ich war hilfreich. Falls Interesse besteht, können wir euch gerne bei der Umsetzung unterstützen. (Website: http//sparrowlabs.at Kontakt office@sparrowlabs.at)

Eine andere Möglichkeit ist auch einen/mehrere Entwickler als dem EU Ausland zu holen (Rumänien/Spanien/Italien) da es in Österreich leider nur wenige gute Mobile Developer gibt, und diese meist so wie ich selbstständig sind.

Aktuell sucht man ja teilweise über ein Jahr lang, bis man jemanden findet der ein paar große Apps rausgebracht hat.

09.06.2014, 21:11 Uhr - Editiert von sparrowlabs.at, alte Version: hier