GySy,
das hat schon mit dem Kartenproblem zu tun.. denn das ist die Konsequenz bzw. das Ergebnis schlechter Programmierung, vorausgesetzt dem ist tatsächlich so.
und zu
ZitatAls (ehemaliger) Entwickler möchte ich was dazu sagen:
Als Entwickler brauchen ich Feed-Back vom Endkunden!
Ich weis was ich programmiert habe und wie es zu bedienen ist und komme damit gut klar. Und wenn ich teste, dann kann ich auch nur das testen, woran ich gedacht habe. Was ich "vergessen" habe kann ich daher auch nur schwer finden.
Ich war mein ganze Berufsleben, fast 50 Jahre in der QS der Automobilindustrie tw. auch an Entwicklung und sehr oft an Problemlösungen beteiligt. Über Jahre hat sich da in den Methodiken sehr viel geändert. U. A. war ich die letzen 15 Jahre „Mitglied einer Usabilty Gruppe“ von sog. Alltagsautofahrern, also normalen Kunden.
In sog. Dummy Situationen ähnlich einem Fahr- oder Flugsimulator mussten wir Bedienungssystem die vor der Einführung standen auf ihre Verständlichkeit und Anwendbarkeit testen.
Am Ende kommt aber dann noch ein Punkt der natürlich die Emtwicklung erschwert, die sog. 80/20 Regel. Will heißen 80% der Anwender kommen mit den Standardanwendungen aus und brauchen nicht ein Mehr an Funktionen, sieht man bei den Festeinbauten, die fasst alle nur von A nach B Routen und allenfalls für die aktuelle Strecke eine „Planung“ von Zwischenstops erlauben und dann den 20 %, die weit mehr erwarten, was die Geräte dann nicht hergeben oder in der Bedienbarkeit wenn irgendwo vorhanden schwierig macht.
Gerade Garmin versucht dann noch bisher übrigens als einziger Anbieter bei den Navis eine sehr große Bandbreite abzudecken, ohne hier kostenmäßig auszuufern. Kann man positiv wie negativ betrachten.
Positiv weil es die Bandbreite gibt, negativ weil der Versuch, alles z.b. von der Sportuhr bis zum Kleinschiffahrtnavi in einer Basissoftware, die da wahrscheinlich hinter steht, abzudecken halt auch Grenzen aufwirft.
