Design-Wahl

[daviid]

Hoppla falscher Thread ...

[Chris M.]

Dann müsste man vorher einen Bildausschnitt definieren, der zu verwenden ist.

Oder einfach von der Demo-Config nen Bild einbinden dürfte das beste sein, also von jedem Design in der Demo-Config nen Screenshot und gut is.

Ich befürchte die Demo-Config ist zu groß, bzw. würde zu viel Platz weg nehmen.

Was ich mir gut vorstellen könnte, wäre ein Bild von einem Button. Da sieht man schon das meiste. Ggf. mit einem Stück <line>

Was dann noch fehlt sind die Flavours. Die gehören für mich elementar zu den Designs - aber die werden irgendwie nicht angenommen. Zumindest haben die Nicht-pure-Designs AFAIK noch keine definiert...
(Geht dieses Feature am Markt vorbei?)

[makki]

Ich weiss, ich bin zu spät
Ein Default-Design in der config und eine Präferenz im Cookie fände ich schon sinnvoll, einen "override" per URL-Parameter aber noch sinnvoller (ein AW speichert sich eher einen bookmark als das er überhaupt weiss, was ein Cookie ist.. nur meine 5ct..)
Das Default deswegen, weil man das ja auch mal von bisher unbekannten Endgeräten aus nutzt, irgenwas muss da gelten..

Makki

Edit: @Chris: Die Flavours gehen IMHO nicht am Markt vorbei, aber ich hab irgendwie (bis vor kurzem) auch ziemlich gebraucht, den tieferen Sinn zu verstehen Da machen wir dann drei Kreuze vor Patrik, der sowas dokumentieren kann

[greentux]

Da gilt dann das, was man auswählt, sobald man das erste Mal zugreift.

[Chris M.]

Da gilt dann das, was man auswählt, sobald man das erste Mal zugreift.

Das finde ich als Pauschal-Fall nicht glücklich.

Stellt euch vor, jemand kommt um die Ecke und bringt (endlich!) das LCARS Design. Das hat hat von mir aus nicht 2 oder 3 Spalten, sondern 7 Zeilen und jede <line> trennt horizontal statt vertikal.
Die Visu-Config ist von den Elementen natürlich darauf angepasst und würde unter jedem anderen Design doof aussehen.

Würde bei jedem ersten Zugriff nun erst mal der Auswahl-Dialog kommen, würde ein unbedarfter Anwender vermutlich auch noch zum falschen Design greifen... (Denkt nicht nur an den Fall des Einfamilienhauses wo ihr der Administrator seit und jedem sagt, was er zu tun hat, bzw. schnell mal helft. Denkt auch an ein Büro-Gebäude das den Mitarbeitern vom Arbeitsplatz aus die Jalousien und die Lichter steuern lassen möchte.)

=> IMHO brauchts einen stabilen Weg ein Design festzulegen und das auch ausrollen zu können.

Und um später wartbar zu sein und nicht alle PCs anpassen zu müssen braucht es IHMO auch eine Möglichkeit um zentral das Design ändern zu können.
(Beispiel: Es gibt ein neues, moderneres Design. Dazu wird auch die Config angepasst, da beides ja gut zusammen passen muss. Dass soll nun auf allen Rechnern ausgerollt werden)

=> IMHO ist das gut durch das Vorschreiben eines Designs (aber gerne per URL übersteuerbar) in der Config-Datei lösbar.

[greentux]

Das passiert pro Gerät genau 1 Mal. Danach sollte es sich gemerkt werden.
Wenn ich nun aber 10 Geräte habe, von denen ich einmal 2 mit dem einen Design, zwei andere mit nem anderen Design und die 6 restlichen mit nem dritten Design betreiben will. Wie komme ich dann mit Deiner Methode zum Ergebnis?

[Chris M.]

Entweder kein Design in der Config angeben und damit die Design-Auswahl erzwingen.

Oder ein Haupdesign festlegen, das insb. für neue und temporäre Geräte gilt (z.B. eines für Smartphones wenn man die oft wechselt) und das in die Config-Schreiben und dann per URL übersteuern.

Man könnte ja auch definieren, dass wenn der URL-Parameter gesetzt aber leer ist, der Auswahldialog kommt.

Auch wenn's sich so lesen mag, als ob ich hier vehement eine Lösung vertrete, ist mein Anliegen ein anderes: ich will einfach die beste Lösung.
Keine Ahnung ob's die ist, die ich mir überlegt habe oder nicht. Ich will hier nur Input geben, dass der, der es umsetzt (ich nicht, mir reicht die aktuelle Lösung) eine Lösung nimmt, die die wichtigsten Anwendungsfälle optimal abdeckt.

[greentux]

Ist schon klar, keine Frage. Die beste Lösung finden wir aber nur, wenn wir die Anwendungsfälle kennen.
Ich kenne derzeit nur:
Inbetriebnahme von 3 - 6 Geräten, einmalig.
Geräte sind vermutlich entweder komplett homogen (weils ein i-House ist) oder heterogen (von TV bis Smartphone).
Ansonsten wird alle 2 Monate mal ein neues Gerät ins Netz gelassen.

Kennt jemand weitere Anwendungsfälle?

[JNK]

Entweder kein Design in der Config angeben und damit die Design-Auswahl erzwingen.

Oder ein Haupdesign festlegen, das insb. für neue und temporäre Geräte gilt (z.B. eines für Smartphones wenn man die oft wechselt) und das in die Config-Schreiben und dann per URL übersteuern.

Das finde ich jedenfalls deutlich besser als so, wie es jetzt ist. Ich rufe die Visu immer mit "visu/visu" (visu ist ein DNS-Alias auf wiregateXXX) auf, was ich meiner Frau für ihr iPhone auch noch gerade beibringen kann. Obwohl ein design voreingestellt ist, kommt IMMER der Auswahl-Dialog, und das senkt den WAF ganz erheblich. Und "visu/visu/?design=discreet_slim" kann sich ein nicht Tech-Freak schlicht nicht merken.

Gruss,

der Jan

[netzkind]

Und "visu/visu/?design=discreet_slim" kann sich ein nicht Tech-Freak schlicht nicht merken.

Der Argumentation kann ich jetzt nicht so recht folgen, denn genau dafür gibt es in jedem Browser Lesezeichen. Das fängt schon damit an, dass ein normaler User keine DNS-Aliase einzusetzen weiß.

Ich versuche nur zu verstehen, was für den echten Endverbraucher die ideale Lösung ist...

Grüße,
Julian

[greentux]

Auch wenns nervt. Aus meiner Anwendersicht:

Wenn ich erstmalig ein Gerät in Betrieb nehm ("Gast kommt und soll auch auf die Visu mit seinem Androiden") ist eine Auswahl "nett", ja sogar sinnvoll.
Danach muss das für alle Zeiten nur noch manuell möglich sein (via Visu, ggf zusammen mit Flavour, wenns denn Stimmungsdesigns gibt ).

Vl. hatte ich mich vorher zu kompliziert ausgedrückt.

[makki]

Ich hab jetzt nochmal nen Tag drüber nachgedacht (naja wenigstens ein paar Minuten dieses..):

Ich denke das Design sollte in der visu_config fix, ggfs. per URL übersteuerbar sein, sonst nichts, nicht am Client gespeichert werden.

Szenarien:
- Design vorhanden, neues gefällt besser, man will umstellen: -> zu allen 5 Geräten latschen, auf einem embedded-System mit Kiosk-Browser im stehen das Cookie löschen:
(Steigerung: 100 Visu-Clients, z.B. alle Anwender-PC's..)
- Spezifische config fürs (mobile) Endgerät: hat man IMHO eh so, weil man am Handy keine 1000 Details, Tooltips, Inline-Graphs etc. braucht): gleiche Lösung, Design wird wenn zentral 1x geändert
(daher übrigens der Gedankenanstoss zur Diskussion für "includes": alles was es überall geben soll könnte man includen, ins jew. Design, alles was eher speziell ist in eben der jew. config halten)

Makki

[Chris M.]

Wie oft will man lokal an einem Gerät von dem in der Config vorgegebenen Design abweichen?

Wenn's um unterschiedliche Geräte-Klassen geht, wird man dann nicht sogar eher unterschiedliche Configs haben?
Erst recht wenn jetzt noch 2D und 3D dazu kommt?

Anwendungsfälle fallen mir spontan ein:

• PC / Laptop (Cookies werden gerne mal gelöscht; Bookmarks lassen sich relativ leicht anpassen)
• Visu-PCs am Touch in der Wand (Cookies bleiben, URLs anzupassen ist erhöhter Aufwand)
• Mobile Geräte (Werden oft getauscht; Bookmarks sind doof zu ändern)
• Wohngebäude (verschiedene Clients, Administration entweder zentral durch einen begeisterten oder bei der Visu aber auch durch SI / Elektriker, der jedes mal anreisen muss...)
• Bürogebäude mit zentraler Administration und Vorgaben

[Chris M.]

(daher übrigens der Gedankenanstoss zur Diskussion für "includes":

Sind die eigentlich schon im Feature-Request drinnen?

Wenn die 3D nicht so viel länger dauern würde als gedacht...
(Ich will die aber unbedingt schnell zumindest prototypenhaft einbinden, damit wir dann die Config-Syntax weiterentwickeln können und der Editor die lernen kann...)

[makki]

Wie oft will man lokal an einem Gerät von dem in der Config vorgegebenen Design abweichen?

Ack, falls es unklar war: genau das meine ich auch, das hat IMHO dezentral nicht verloren daran zu drehen oder es einzustellen..

Makki