Wertebereich für Color im Device Control

Hi!

Mal was zum "Punkt oder Komma":
Ich habe mich bei einer betriebsinternen Erfassung auch damit abgefunden, dass es für den User einfacher ist, das Datum so flexibel wie möglich einzugeben. Es muss ja schnell gehen (ist ein Interface zur Arbeitszeiterfassung). Daher lass ich alle Kombinationen zu und wandle um. Es ist also egal was der User eingibt:

• 01.12.2017
• 1,12,17
• 1/12/17

Ich bin einfach ein Nutzer des Ziffernblocks. Schätze mal da bin ich wohl nicht alleine. Und da liegt dummerweise im deutschen Layout das Komma.
Und was die Usability der Diskussion 1 oder 100 angeht: Wie man oben sieht, bin ich faul den Finger zu weit zu bewegen. Demnach ist es für mich im Workflow auch "gefühlt" zuviel bei 50% den Wert 0.5 einzugeben. Es ist eine Stelle/Taste mehr...
Denn mal ernsthaft, wer gibt denn da wirklich ständig Kommawerte ein? Also ich meine jetzt der normale Nutzer. Solange es "tut" wird sich jeder an 0-100 geradzahlig orientieren und erst wenn man es wirklich braucht, dann in die Kommazahlen gehen. Statt "5" muss man dann "0.05" tippen, was 3 Tasten mehr sind. Klar, die "100" verliert gehen die "1"... Das ist aber schon der einzige Wert mit weniger Tastenanschlägen.

Nur so meine Gedanken dazu.

Hoc

Die Idee ist ja grundsätzlich schlecht! Jetzt möchte ich rot z.b auf 52% einstellen. Dazu nehme ich immer das Num-pad. Da hab ich leider kein . ! Muss also meist im Dunkeln noch das Komma suchen...

Aus IT Sicht kann ich es nachvollziehen, aber als User?

Gruß
Nutzer99

Ich glaube Stein des Anstoßes ist die komplizierte Eingabe mit dem "Komma". Was ich mir Vorstellen könnte wäre sowas wie eine Eingabehilfe.

Wir nehmen die Eingabe (z.B. 127) und teilen die so lange durch 10, bis es passt

127 => passt nicht => 12,7 => passt nicht => 1,27 => passt nicht => 0,127 => ok

dadurch könnte man auch die Kommazahlen schnell eingeben. Wer von 0 - 100 arbeiten kann kann das, weil wenn er 100 eingibt wird das automatisch in 1 übersetzt, wenn er 99 eingibt 0,99.

Evtl. wäre das eine gute Lösung.

Gruß Arne

Guter Ansatz, aber was passiert mit der 1? 1? 0.1? 0.01? Jeweils geteilt (oder halt nicht) und alles korrekt.

1 bleibt 1

Quote from Soon5

Wir nehmen die Eingabe (z.B. 127) und teilen die so lange durch 10, bis es passt

Öhm, verwirrt das nicht? Denn dann hätten wir tatsächlich ein inkonsistentes Verhalten zwischen 1 und 2 (2 wird zu 0.02, 1 bleibt 1). Das wäre meiner Meinung nach kontraproduktiv. Ich glaube, über die Frage 0.53/0,53 oder 53.0/53,0 kann man leidenschaftlich diskutieren, denn es gibt für beide Seiten gute Argumente. Ist halt die Frage, in welche Richtung man optimieren möchte (saubere Darstellung <=> schnelle Eingabe). Ich wäre z.B. auch ehr auf der Seite 53.0/53,0, einfach, weil es schneller einzugeben ist und man die Nachkomma-Werte eigentlich erst braucht, wenn man eine genauere Abstufung braucht.

Was Punkt und Komma betrifft, kenne ich das von manchen Programmen auch (z.B. CATIA), dass beide Eingabewege gleichzeitig unterstützt werden, solange man bei der Eingabe in einem Feld nur konsistent ist. Man kann also sowohl 43,7 als auch 43.7 eingeben. Beides wird akzeptiert und zu 43.7 umgewandelt. Wenn man in einem Eingabefeld rechnet, müssen halt alle eingegebenen Werte das selbe Format verwenden.
Viele Grüße
JP

Wenn man Punkt und Komma nehmen könnte, dann wäre es auch nicht viel mehr.

Anstelle von "50" müsste ich ",5" eingeben, weil die 0 nicht benötigt wird.

Ich bin für:

RGB: 0-255 (8bit) bei rgb das ist auch Webstandard (viele nutzer kennen das schon aus Photoshop usw.) und entspricht bei fast allen Scheinwerfern den DMX-Werten. 16bit wären dann hat einfach 0.5er Schritte, 32bit 0.25er usw.

Dimmer: 0-255 (genauer)16bit dann halt über 0,5; 32bit 0.25, oder 0-100% (intuitiver)

Ich hasse dieses 0 bis 1: komplett unintuitiv, viel zu tippen (Komma/Punkt-Problem).
Da sind die 8bit RGB Werte umeiniges einfacher. Intern kann es ja bei 0 bis 1 bleiben aber die Oberfläche sollte entweder einstellbar, oder zumindest intuitiv sein.

Gruß
Scyte

Sehr gut geschrieben. Der Meinung bin ich auch.

Dann wäre es aber nicht 0 - 255 sondern 0.0 - 255.0, nur um das klar zu stellen. Man könnte dann auch 123,124 eingegeb oder 254,999

Quote from Scyte

RGB: 0-255 (8bit) bei rgb das ist auch Webstandard (viele nutzer kennen das schon aus Photoshop usw.) und entspricht bei fast allen Scheinwerfern den DMX-Werten. 16bit wären dann hat einfach 0.5er Schritte, 32bit 0.25er usw.

Zu der Scyte: 9 bit Entsprechen 0,5er Schritte und 10 bit 0,25 Schritte, wenn man den Bereich 0,0 bis 256 betrachtet und 256 nicht erreicht werden kann.1 Bit mehr verdoppelt die Anzahl der möglichen Werte.

Viele Grüße
soekkle

Korrekt. Die Schrittweite von 8 => 16 Bit ist nich 0,5 sondern 1 / 256 => 0,00390625

Quote from Scyte

16bit wären dann hat einfach 0.5er Schritte, 32bit 0.25er usw.

Achtung! Ganz böse Fehlerquelle!. Das ist so falsch.

Beispiel:
2 Bit (Werte 0-3) und 3 Bit (0-7)
Jetzt ist 0 <=> 0 jeweils das Minimum und 3 <=> 7 jeweils das Maximum.
Umrechnung wäre dann so:

Das geht leider nicht auf mit 0.5 Schritten. (Kann jeder gerne für 16-bit und 32-bit selbst nachrechnen)

Es hat seinen Grund warum man überall da wo es genau sein soll und unabhängig von 8-bit, eben ein normalisiertes Intervall nimmt (im Normalfall halt 0-1). Die 0-255 macht einfach nur da Sinn wo das 8-bit Muster gegeben ist. Ja das mag in Web und Photoshop verbreitet sein, kommt da aber halt auch durch das gegebene 8-bit Muster. Sobald man eine Anwendung hat die eben nicht mehr 8-bit basiert ist wird man keinen Standard finden der 0-255 verwendet.

DMXControl hat jetzt numal das Feature mit Farben beliebiger Auflösung umzugehen (Mal unabhängig was hinterher beim Gerät ankommt, das ist ja die Grundidee des HAL). Die Entwickler stehen dann jetzt vor dem Problem ob man ein Schema (in dem Fall die 0-255 Einteilung) beibehält obwohl dieses für ein ganz anderes Einsatzgebiet erstellt wurde (feste 8-Bit Auflösung) oder eben ein neues Schema (0-1 Intervall) für das neue Einsatzgebiet wählt.

Ganz blödes Beispiel: du würdest ja auch nicht versuchen eine Orange mit einem Kartoffelschäler zu Schälen:
Kartoffel = 8-bit basierte Farben: Web / Photoshop
Kartoffelschäler = 0-255 Bereich
Orange = Auflösungsunabhängige Farbverwaltung wie es DMXControl macht.

Ich sehe ja auch ein, dass es Sinn macht zu versuchen bestehende Konzepte so weit möglich beizubehalten, um es dem User so einfach wie möglich zu machen, was Gewöhnung und Neueinstieg bedeutet (ist nicht umsonst ein Kriterium für gutes Softwaredesign). Aber manchmal muss man halt abwägen, wann es einfach besser ist für ein neues Feature ein neues Konzept zu starten, weil die Weiterführung bestehender Konzepte es eigentlich nur verschlimmbessert und dann ganz neue Probelme mit sich bringt (siehe z.B. Tabelle).

Viele Grüße
Moritz

PS: Weiteres Beispiel das man Eventuell vom Licht kennt: Wenn man exakt 50% will, nimmt man dann 127 oder 128. (Die Mitte wäre halt eigentlich 127.5) Das hat man bei 0-1 (oder auch 0-100) nicht.

Edit: Zu lang Geschrieben die Vorposter warn schneller xD

Hallo,
naja, die Festlegung auf eine 8bit-Betrachtung ist ja eigentlich genau das, was wir hier vermeiden wollen, denn damit legen wir uns wieder auf eine Ausgabe fest und wie Arne ja schon sagte kann man das ja nicht einfach auf "0,5"- oder "0,25"-Schritte festlegen. Eine Prozentangabe auch für Farben ist da schon deutlich natürlicher, weil man hier die Farben meiner Meinung nach wie "einen gefärbten Dimmer" ansehen kann. Einzig die Skallierung würde ich von 0 - 100 statt 0 - 1 machen, denn Prozentangaben werden eben wie beim Dimmer von 0 - 100 gemacht (ist intuitiver).
Viele Grüße
JP

da stimme ich JPK zu! Ich habe auch kein Problem, wenn da 100.00000000 steht. Ich will den Punkt nur nicht eingeben müssen:)

Wenn ich mal 16 bitte benötigen sollte, dann tippe ich halt die stellen ein. Das wichtigste bei den 16 Einstellungen ist aus meiner Sicht nur das Faden und der 10% Bereich bei den LEDs, damit es nicht so ruclelt. Aber das ist ja unabhängig von dem Wert, den ich einstellen will.

Mit 0 und 1 verbinde ich immer An oder Aus. Bin das halt aus meinem Beruf auch so gewöhnt nur mit aganzen zahlen zu arbeiten.

Gruß
Nutzer99

Ihr könnt euch auf die Lösung freuen, mit der sind Wir dann aus dem schneider

Quote from Qasi

Ihr könnt euch auf die Lösung freuen, mit der sind Wir dann aus dem schneider

Was Patrick sagen will ist, wir haben parallelen zu einer anderen Aktivität gefunden die wir sowieso für die 3.2 geplant hatten, und lösen das Problem da irgendwie mit.

Kommt das jetzt in der 3.1.1 oder 3.2

Sorry, peinlicher Gedankenfehler.