Skip to content
This repository has been archived by the owner on Nov 3, 2023. It is now read-only.

Reihenfolge der Felder von Image settings anpassen #7565

Closed
MacKP opened this issue Jan 13, 2015 · 15 comments
Closed

Reihenfolge der Felder von Image settings anpassen #7565

MacKP opened this issue Jan 13, 2015 · 15 comments
Assignees
Labels
Milestone

Comments

@MacKP
Copy link

MacKP commented Jan 13, 2015

Inzwischen ist es ja so, das man erst Angeben muss, wie man ein Bild verkleinert haben möchte. Vorher kann man gar nicht in die Felder für die Breite und Höhe von einem Bild.
Das ist schon mal sehr gut so wie ich finde.
Leider ist es von der Reihenfolge sehr unlogisch aufgebaut, da der resize mode rechts neben der Breite und Höhe steht.
Von der Reihenfolge sollte das also so geändert werden, das der resize mode an erster Stelle kommt.
Auch für Blinde Redakteure wäre das wichtig!

Viele Grüße

@leofeyer
Copy link
Member

Ich finde das unlogisch. Das Feld heißt "Bildbreite und Höhe" und nicht "Verkleinerungsmodus". Zudem gibt es kein anderes Widget, was zuerst das Select-Menü und dann das Input-Feld hat.

@leofeyer leofeyer removed this from the 3.5.0 milestone Mar 27, 2015
@MacKP
Copy link
Author

MacKP commented Mar 27, 2015

Hallo Leo,
ich kann deine Einwände verstehen. Wobei es immer noch unlogisch bleibt so wie es ist: Die Lese und Tab Richtung ist nun mal genau umgedreht.
Wenn die Beschriftung also für dich unlogisch wird, dann sollten wir überlegen die dann auch anzupassen. Im Grunde genommen ist es ja ein Verkleinerungsmodus. Ansonsten müsste man da gar nichts angeben ;-)

@discordier
Copy link
Contributor

@leofeyer Es geht Marc ja genau um das Widget, dieses ist von der usability nun "falsch", da es erst zwei deaktiverte Felder hat.
Verwende es mal bitte mit Tastatur only, da tabst du dich erst mal zum select, dann waehlst du was aus und dann shift tabbst du dich zur Hoehe und dann shift tabst du dich zur Breite um danach mit 3fach Tab zum naechsten Eingabefeld zu kommen.

Wenn man im Widget das Select vor die Breite und Hoehe setzt, dann kann man einen normalen Tab Workflow wieder haben. Das ist es was Marc moechte.

@leofeyer
Copy link
Member

Wenn es darum geht, können wir auch die Tab-Reihenfolge anpassen, oder?

@MacKP
Copy link
Author

MacKP commented Mar 27, 2015

Ja, dann haben immer noch die sehenden Redakteure das Problem, das die wie ein Honk in das Feld klicken und da nichts eingeben können.. bis die eben erst das rechte Feld auswählen. Das kann man machen, wenn man von rechts nach links lesen würde, was hier in dem Breitengrad aber nicht so weit verbreitet ist ;-)
Das ist eben nur ein Punkt mit der Tab Reihenfolge. Und auch da bin ich eher für eine Logische Reihenfolge, als per Tab-Reihenfolgen Anpassung vorgehen zu müssen (sowas vergisst man auch immer gerne anzupassen).

@frontendschlampe
Copy link

Also ich sehe das genauso wie Marc: Natürlich könnte man nur die Tabreihenfolge anpassen, aber das änder trotzdem nichts an dem Sachverhalt, dass die Reihenfolge falsch herum ist - auch als Sehender. Ist denn die Namensanpassung und die Änderung der Reihenfolge so problematisch? Problem ist halt, dass die Redakteure denken, dass sie nichts eingeben müssen, weil ja die Felder deaktiviert sind und das ist natürlich ungünstig.

@leofeyer
Copy link
Member

Behoben in a806ec0.

@ausi
Copy link
Member

ausi commented Apr 27, 2015

Wir haben uns in #7436 (comment) auf 'includeBlankOptions'=>true geeinigt, warum ändern wir das jetzt?

Warum drehen wir nicht nur die Felder um, so wie von @MacKP vorgeschlagen?

Soll ich einen pull request dafür machen?

@Toflar
Copy link
Member

Toflar commented Apr 27, 2015

Das macht keinen Sinn Leo. Das macht Sinn:

  • Blank Option braucht's, weil gar keinen Verkleinerungsmodus = Blank Option
  • Verkleinerungsmodus-Dropdown kommt an erster Stelle
  • Die Felder Breite und Höhe sind ausgegraut bei
    • Blank Option
    • Image Size

@leofeyer
Copy link
Member

Es macht auch keinen Sinn, die Felder zu drehen. Das Feld heißt "Bildbreite und -höhe", daher sollte man auch standardmäßig die Bildbreite und -höhe eingeben können. Der Verkleinerungsmodus legt im zweiten Schritt fest, wie die gewählte Bildgröße erreicht wird.

Ich gebe zu, dass die jetzige Lösung auch nicht optimal ist, aber von allen nicht-optimalen Lösungen ist sie noch immer die beste. Außerdem ist das wieder das Verhalten aus Contao < 3.4, das die Leute gewohnt sind, und die vielen Tickets haben ja gezeigt, dass die Leute mit der Umgewöhnung ihre Probleme hatten.

@Toflar
Copy link
Member

Toflar commented Apr 27, 2015

Das Feld ist zuständig für die Verkleinerung von Bildern und erfordert keine Breiten- und Höheneinstellung wenn eine vordefinierte Einstellung gewählt wird. Ich find's falsch so wie's jetzt ist, egal was sich die User gewohnt sind. Es ist unlogisch.

@MacKP
Copy link
Author

MacKP commented Apr 27, 2015

@leofeyer dann müsste man das Feld auch umbenennen. Dann wäre es auch aus der Sichtweise logisch. Warum nicht direkt richtig machen?

@ausi
Copy link
Member

ausi commented Apr 27, 2015

Das Verhalten aus Contao < 3.4 ergibt aus meiner Sicht nur Sinn wenn wir die Image-Sizes wieder entfernen.

Das Feld heißt „Bildbreite und -höhe“ und genau das wählt man in der Select-Box aus, eine Bildgröße mit Breite und Höhe, alternativ kann man einen Resize-Mode wählen und die Breite und Höhe direkt vergeben. Die Bezeichnung „Bildbreite und -höhe“ passt aus meiner Sicht perfekt mit der Reihenfolge select zuerst zusammen.

@leofeyer
Copy link
Member

Geändert in 652cac7. Ich finde die Lösung jedoch gar nicht gut und behalte mir vor, die Änderungen rückgängig zu machen, sollten die Anwender damit ähnlich schlecht zurecht kommen wie mit der Lösung aus Contao 3.4.

@ausi
Copy link
Member

ausi commented Apr 27, 2015

Abgesehen von 652cac7#commitcomment-10914413 finde ich es so in Ordnung.

leofeyer added a commit that referenced this issue Apr 29, 2015
leofeyer added a commit that referenced this issue Apr 29, 2015
leofeyer added a commit that referenced this issue Apr 29, 2015
leofeyer added a commit that referenced this issue Jun 3, 2015
leofeyer added a commit that referenced this issue Jul 23, 2015
leofeyer added a commit that referenced this issue Sep 5, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

6 participants