GUI Vorschlag: RouteConverter 2.0

[stoffel]

Christian ist mein Genörgel wohl etwas auf den Wecker gegangen und er hatte mich gebeten, meine Vorschläge mal ein wenig zu veranschaulichen.

Hallo stoffel,

vielen Dank für die Vorarbeiten. Das war sicher mühsam, gerade die Icons gefallen mir besser als die bisherigen. Ein paar Dinge sind mir aufgefallen:

1. Bislang gab es einen klaren Ablauf von oben nach unten im Konvertieren-Tab: laden, modifizieren, speichern. Das wurde von Nutzern gut verstanden. Durch den Speichern-Knopf ganz oben rechts geht das Prinzip verloren und der Neu-Knopf paßt von der Funktion ebenfalls nicht direkt hinter den Dateinamen. Ich bin etwas ratlos wie das eleganter geht, hast Du eine Idee?

2. Du schreibst

„Analysieren“ -> „Höhenprofil“ Kann mir nicht vorstellen, dass hier in nächster Zeit noch andere Analysen außer Höhenprofil
angeboten werden

-- es gibt den wie ich finde sinnvollen Vorschlag (und auch dazu passenden Programmcode) die Geschwindigkeit auch als Profil anzuzeigen.

3. Die Bedeutung der Funktionen von den beiden Aufreihungen von Icons ober- und unterhalb der Liste erschließen sich mir nicht. (Drum gibt es in Deinem Dokument auch den Abschnitt 2.1 ;-)) Ich wollte schon mit der Maus drüber fahren, um Tooltips zu bekommen. Gerade die Pfeile nach oben und untern schreien m.E. nach einer Platzierung neben der Liste, wo ihre Funktion sofort klar wird. Der MS Office Style mit den Icons plus danebenstehendem Text wie im angehängten Screenshot löst das m.E. besser, oder nicht?

4. Du schreibst

1.2 Combobox „Speichere als“ und Checkbox „Speichere als Route, Track und Wegpuktliste“ interessieren den Anwender nur in Kontext Speichern. Warum werden sie dann im zentralen Reiter immer angezeigt? Lösung: Verschieben der Elemente in
den Speicherndialog (s.u.)

-- Das wäre auch die von mir präferierte Lösung, sie ist jedoch mit Java Swing nicht zu realisieren ohne den gesamten Speicherndialog neu zu implementieren. Vielleicht könnte man auf die Option ganz verzichten? Vor 2 Jahren hat mir das viele Nachfragen vom Hals gehalten, doch nun steigt die Anzahl der Nachfragen, wieso aus 1 Positionsliste nun 1 Route, 1 Track und 1 Wegpunktliste werden.

5. Du schreibsts

2. Unter „Datei“ steht nur der Dateiname nicht der Pfad (den braucht man nicht zu sehen, ist sowieso in der Regel viel zu lang)

-- die Intention ist klar: weniger Information, doch dann laufen der anzeigte und der benutzte Dateiname auseinander, was kaum verständlich ist für Nutzer. Wie wäre, wenn ich das Feld beim Verlust des Fokus' nach rechts scrolle, damit der Namen stets zu lesen ist? Oder könnte ein Tooltip helfen?

Zu 1.) Habe schon verstanden, dass du durch die Anordnung einen "Workflow" abbilden willst. Das "Verstreuen" von File-Operationen auf weit auseinander liegende Maskenbereiche halte ich allerdings auch nicht für geglückt. Ich habe den Speichern-Button zunächst gar nicht gefunden!

Auch ist der angedachte Workflow nur idealisiert. Ggf. will ich nur Laden und dann sofort in anderem Format speichern.

Aus meiner Sicht insb. bei Umsetzung von 4. MUSS der Button in die Nähe des Datei-Feldes.

Zu 2.) Wenn dem so ist, bleibe bei der Benennung. Hat für mich keine hohe Prio.

Zu 3.) Hier gleich vorweg: Dieser Punkt hat für mich höchste Prio!

Bedeutung und Funktion der Buttons erschließt sich aus Position, Icon und Tooltip, so wie bei hunderttausenden von Buttons in tausenden von Applikationen. Die Buttons gehören über oder unter die Liste weil sie im Kontext der Liste agieren. Schau dir bitte mal andere Anwendungen an. Es gibt zahllose Beispiele die eine ähnliche Anordnung wählen. Die Unterschiede zwischen Über und Unter habe ich hinreichend erläutert, denke ich.

Locker verteilt links oder rechts neben der Liste zusammen mit ganz anderen Aktionen (Laden und Speichern) haben sie in meinen Augen nichts zu suchen. Nur weil auf 2 Buttons ein Pfeil oben oder unten steht und deshalb eine vertikale Anordnung etwas passender erscheint ist kein Grund von dieser Prämisse abzuweichen. Die Beispielbuttons mit Icon + Text brauchen viel zuviel Platz wenn sie noch einen aussagefähigen Text beinhalten sollen und Platz war es ja was wir sparen wollten... Hinzu kommen noch ein paar Problemchen mit I18N...

Ganz klar: Wir können da jetzt noch lange drüber Diskutieren wo die Buttons hingehören, können es aber auch bleiben lassen! Ich denke ich habe mich hinreichend über die Vorteile des gewählten Ansatzes ausgelassen. Wenn du dieser Philosophie nicht folgen willst, kannst du meinen Vorschlag im Prinzip vergessen!

Zu 5.) Welche Info liefert mir ein Abgeschnittener Pfad im Feld "Datei:"? Warum kann ich dieses Feld editieren? Was passiert wenn ich zum Beispiel den Pfad ändere? Nichts! Der geänderte Pfad wird in keiner Weise ausgewertet. Den Dateinamen kann ich beim Speichern erneut ändern.

Mein Vorschlag: "Keep it simple". Verwirre den Anwender nicht mit Funktionen wo keine sind! In dem Feld steht der Dateiname, mehr nicht. Meinetwegen kann man den auch ändern (obwohl eigentlich nicht zwingend erforderlich). Beim Speichern wird dieser (geänderte) Dateiname übernommen und erneut abgefragt (Aber bitte auch komplett und nicht nur bis zu ersten '.' => BUG). Den kompletten Pfad kannst du in einem Tooltip am Feld oder in der Titelzeile der Anwendung darstellen (da ist mehr Platz) und es suggeriert keine Änderbarkeit.

Gruß
Stoffel