Designs

[Chris M.]

Jetzt habe ich auch die Unterstützung für Icons hochgeladen. In den Mappings und im Label-Text kann jetzt neben normalen Text (in beliebiger Mischung!) auch ein Element des Typs <icon> verwendet werden - einfach mal die Demo-Config ansehen...

[2ndsky]

Ich weiss zwar nicht was das damit zu tun hat, aber nehmen wir mal an, das Auto würde die persönliche Potenz steigern: das sieht der Nachbar (im Gegensatz zur Visu) wenigstens, ob er will oder nicht

Das passt aber nicht mit deinen Aussagen zusammen, dass man nur ne übsche Visu will um den Nachbarn zu beeindrucken. Und selbst wenn manche eine hübsche Visu wollen um den Nachbarn zu beeindrucken... so ist das nichts anderes als dein Auto

Das Auto hat man weil es Spass macht, ich würde deswegen nicht auf die Idee kommen, mir selber eins zu schweissen, weil mir die eine eckige Kante nicht gefällt..
Und das ist eben der Punkt - ich versuche gerne nach Kräften - an der "perfekten" Visu mitzuarbeiten aber ich kanns mir nicht verkneifen das ein oder andere mal zu sagen, wenn man in eine Sackgasse rennt die ich schon gut kenne

Da gebe ich dir recht, ich kaufe mir auch lieber das Auto, das mir am besten gefällt und mir technisch zusagt (natürlich in meiner Preisklasse) und ändere zur Not Dinge die mir nicht passen (und wenn es nur die Felgen sind). Aber dennoch wähle ich ein Auto primär erstmal nach dem Aussehen.
Das eine one man show nicht die ideale Voraussetzung für eine langfristige Visu ist sehe ich ein, ich will damit ja nur sagen, was viele andere auch ausdrücken wollen, dass die CV viel erfolgreicher wäre, wenn sie eine grafisch aufwändigere Oberfläche hätte. Mit dem Erfolg der CV steigt unweigerlich auch der Erfolg des Wiregate. Diese stimmen werden hier im Forum eindeutig laut (Chris hat das glaub verstanden und geht darauf ein). Du versuchst eher die CV schön zu reden. Wenn ich als Otto Normal User die Wahl habe zwischen schöner Visu die lange zu konfigurieren ist oder einfach zu konfigurierender Visu wo ich aber lang habe die schön zu machen, dann würde ich die erste Variante bevorzugen. Warum? Weil ich schonmal sehe, wie das Ding aussehen kann wenn es fertig ist, was auch die Motivation steigert. Bei der CV brauche ich wirklich Vorstellungsvermögen und muss wissen, dass ich das Design mittels CSS anpassen kann. Wenn wir aber beim Otto Normaluser bleiben wird der lieber im Experten rumklicken, als sich in CSS einzulesen. Und das ist nun mal Fakt und wird durch die Aussagen auch andere User hier bestätigt, ob du das jetzt eingestehen möchtest oder nicht!
Mit persönlich ist das ja wurscht, sobald der Hausbau endgültig abgeschlossen ist, werde ich mir die CV so zurechtbiegen (optisch) wie es mir gefällt.

[greentux]

keine Frage, das die anderen totgeburten sind bei 1 vs. 30+ Entwickler, naja

Das kann man so nicht stehen lassen. Es spiegelt jedenfalls nicht den "Spirit" wieder, den es auch unter den CV Entwicklern gibt. Speziell hier im Unterforum.
Ich frag mich ja, wie der Torvalds damals gegen Microsoft anstinken konnte, 1 vs. 6.000. Aber naja. Der Vergleich hinkt, trotzdem ist die Aussage oben unfair.

[Chris M.]

[WICHTIG]Alle möglichen Vergleiche hier hinken, aus den verschiedensten Gründen - die ich auch nicht weiter erörtern möchte. Bitte bleibt wieder On-Topic![/WICHTIG]

[makki]

Der Vergleich mit dem Auto hinkt ganz besonders weil der deutsche für sein liebstes Kind (ich nehme mich da nicht aus!) komischerweise bereit ist bei weitem mehr auszugeben als es sinnvoll ist.. (bei der Dämmung/Heizung wird gespart, die man 30J hat, am Auto für 3J nicht..)

-> Daher: lieber machen als lang darüber reden, Chris hat vorgelegt.. - wobei es eigentlich immer klar war, das es auch mit sinnlosen Bildchen ginge wenn man wollte! die kosten halt nur auch zusätzliche Zeit; (die sollten prefetched werden, das sieht sonst k** aus..)
Und ich persönlich komme von der "malen-nach-Zahlen"-Superdollen-HS-Visu und bin daher mit der jetzigen CV mehr als glücklich.
Aber vielleicht ists auch ein wachrüttler, der ja durchaus erkannt wurde, das geht recht zielgerichtet an den Stolz (positiv gemeint), wenn so ein halbgares Strickwerk, wo mal nur max. 10% wirklich funktionieren, mit der CV verglichen wird - nur weil der Screenshot besser aussieht

Makki

[2ndsky]

Aber vielleicht ists auch ein wachrüttler, der ja durchaus erkannt wurde, das geht recht zielgerichtet an den Stolz (positiv gemeint), wenn so ein halbgares Strickwerk, wo mal nur max. 10% wirklich funktionieren, mit der CV verglichen wird - nur weil der Screenshot besser aussieht

Dann kam ja doch was an und die Diskussion war nicht ganz umsonst

[mumpf]

Jetzt habe ich auch die Unterstützung für Icons hochgeladen. In den Mappings und im Label-Text kann jetzt neben normalen Text (in beliebiger Mischung!) auch ein Element des Typs <icon> verwendet werden

Danke! Hab ich gleich ausprobiert - sieht auch gleich besser aus!

Falls man noch Wünsche äußern darf: Jetzt müssten nur noch <group> und <page> zusätzlich zum name-Attribut auch ein <label> erlauben, und der <text> sollte wie ein <label> funktionieren. Dann kann man schon mal Icons an den relevanten Stellen hinterlegen.

Gruß, Waldemar

[Chris M.]

Falls man noch Wünsche äußern darf: Jetzt müssten nur noch <group> und <page> zusätzlich zum name-Attribut auch ein <label> erlauben, und der <text> sollte wie ein <label> funktionieren.

Mit Revision 826 kann nun auch <text> mit Icons verwendet werden. Außerdem werden nun die Types und Flavours unterstützt - und all das in der Demo-Config gezeigt.

Zu <group> und <page>:
Ein Label bei <group> kann ich mir noch vorstellen. Aber was soll das bei <page> machen? Den Link auf Button-Breite kürzen?

[mumpf]

Zu <group> und <page>:
Ein Label bei <group> kann ich mir noch vorstellen. Aber was soll das bei <page> machen? Den Link auf Button-Breite kürzen?

Sorry, hab mich nicht klar genug ausgedrückt. Ich wollte eigentlich nur sagen, dass ich es schön fände, wenn es auch Icons für die page- und group-Überschriften gäbe.

Damit das geht, dachte ich, müssten sie das <label> nutzen können... natürlich gibt es auch andere Lösungen! War ein bisschen verquert gedacht - mir ging es um die Icons.

Und danke für <text> mit icons, ich hatte mir schon testhalber mal Dein Icon-Coding ins text-widget kopiert, um zu sehen, ob es klappt. Aber ich nehme natürlich viel lieber das Original.

Gruß, Waldemar

[JuMi2006]

Die Navbar ist bei mir noch ein bisschen tricky ... die Anpassung der Größe will nicht so richtig. Da kam mir aber dann eine andere ?gute? Idee.

Das pagejump Widget sieht auf der Startseite deutlich besser aus als der einfache TextLink zur entsprechenden Seite. Da hab ich dann nämlich einen schönen Button für. Das Problem ist dann aber der doppelte Eintrag (page/pagejump). Pagejump ist also eine größere Baustelle. Oder man müsste das Aussehen von page ändern - sicherlich einfacher. Dann wäre ein icon im pagelink von Vorteil und könnte so signalisieren dass es es sich um eine weitere Seite handelt.

Wünschenswert, und für die Übersicht besser fände ich eine Ausgliederung der einzelnen Seiten, das geht aber ganz arg in die Syntax. Könnte aber bei der ID für die einzelnen pages helfen.

Zu den icons:
In der vorherigen Rev. wurden die Icons skaliert. Wie mach ich das mit Type? Eine fixe Größe sieht unter Umständen komisch aus.


P.S.:
Wie bekomme ich die Überschrift unter der Stausbar oben ausgeblendet.
Die braucht man nicht wirklich wenn die Statusbar mir oben anzeigt wo ich mich befinde. Wer sie dennoch braucht kann sie sich ja mit dem Textwidget reinholen. Meine css-Versuche sind da gescheitert.

[kleinklausi]

Wie bekomme ich die Überschrift unter der Stausbar oben ausgeblendet.
Die braucht man nicht wirklich wenn die Statusbar mir oben anzeigt wo ich mich befinde. Wer sie dennoch braucht kann sie sich ja mit dem Textwidget reinholen. Meine css-Versuche sind da gescheitert.

Du musst in der custom.css (nur SVN) folgendes einfügen:

.page h1, div#loading {
    display: none !important;
}

Die custom.css sollte es für jedes Design geben. Das schöne an custom - es wird nicht vom Maintainer überschrieben.

Gruß Moritz

[Chris M.]

Die Navbar ist bei mir noch ein bisschen tricky ... die Anpassung der Größe will nicht so richtig. Da kam mir aber dann eine andere ?gute? Idee.

navbar ist nur initial vorhanden, da muss ich schon noch nachlegen.
Ich bin aber gerade an einem neuen Design ("planet") dran, das davon deutlich Gebrauch machen wird. In dessen Rahmen wollte ich die navbars auf einen brauchbaren Stand bringen. Dauert halt noch ein paar Tage.

Oder man müsste das Aussehen von page ändern - sicherlich einfacher.

Wenn dann das. Pagejump ist "nur" ein Link auf vorhandene Seiten.

Wünschenswert, und für die Übersicht besser fände ich eine Ausgliederung der einzelnen Seiten, das geht aber ganz arg in die Syntax. Könnte aber bei der ID für die einzelnen pages helfen.

Das verstehe ich jetzt nicht.

Das "verschieben" beim Seitenwechsel ist ja nicht willkürlich, das soll dem Anwender durchaus helfen die Seitenstruktur im Kopf nachzuvollziehen und sich so schneller zurechtzufinden.

Zu den icons:
In der vorherigen Rev. wurden die Icons skaliert. Wie mach ich das mit Type? Eine fixe Größe sieht unter Umständen komisch aus.

Type soll zwischen möglichen Variationen des selben Icons wählen können. Idee wäre aber, dass man das normalerweise nicht braucht (daher auch Type "*")

P.S.:
Wie bekomme ich die Überschrift unter der Stausbar oben ausgeblendet.

Hat Moritz schon gut beantwortet

[hannes loehr]

Zitat von JuMi2006
Wünschenswert, und für die Übersicht besser fände ich eine Ausgliederung der einzelnen Seiten, das geht aber ganz arg in die Syntax. Könnte aber bei der ID für die einzelnen pages helfen.


Das verstehe ich jetzt nicht.

Hi,

ich klinke mich hier mal ein. Ist mit "Ausgliederung" gemeint, dass pages nicht mehr geschachtelt werden sollen, sondern alle parallel nebeneinander definiert werden. Wenn ja, dann kann ich das unterstützen mit dem Hinblick auf eine JQuery Mobile Portierung, an der ich gerade experimentiere. Dafür wäre eine flache Hierarchie mit festen händischen page-ids sehr hilfreich. Es steht leider konträr zum momentanen automatischen Generieren von Links.

Falls man in die Richtung mit Jquery Mobile gehen möchte, würde die XML-Struktur wohl etwas durcheinandergewirbelt. Neben den structure-Dateien für die Widgets müssen die globale index.html oder template_engine.js geändert und Features wie rowSpan, colSpan oder die navBar dort etwas anders gehandhabt werden. Wenn ich etwas zum vorzeigen fertig habe, würde ich das einmal als Testballon in einem eigenen Unterverzeichnis ins SVN einstellen, um die "normale" Entwicklung nicht zu verwirren.

Gruß
Hannes

[Chris M.]

ich klinke mich hier mal ein. Ist mit "Ausgliederung" gemeint, dass pages nicht mehr geschachtelt werden sollen, sondern alle parallel nebeneinander definiert werden. Wenn ja, dann kann ich das unterstützen mit dem Hinblick auf eine JQuery Mobile Portierung, an der ich gerade experimentiere. Dafür wäre eine flache Hierarchie mit festen händischen page-ids sehr hilfreich. Es steht leider konträr zum momentanen automatischen Generieren von Links.

Feste, aber dafür manuelle, Page-IDs sollten kein Thema sein. Müssen halt nur implementiert werden...

Dazu ob die Pages geschachtelt oder serialisiert sein sollten kann ich momentan wenig sagen. Wenn die bestehenden Designs (ggf. nach entsprechender Modifikation) auch damit bei gleichem UI funktionieren, dann habe ich prinzipiell nichts dagegen.

Falls man in die Richtung mit Jquery Mobile gehen möchte, würde die XML-Struktur wohl etwas durcheinandergewirbelt. Neben den structure-Dateien für die Widgets müssen die globale index.html oder template_engine.js geändert und Features wie rowSpan, colSpan oder die navBar dort etwas anders gehandhabt werden. Wenn ich etwas zum vorzeigen fertig habe, würde ich das einmal als Testballon in einem eigenen Unterverzeichnis ins SVN einstellen, um die "normale" Entwicklung nicht zu verwirren.

Klar, wenn's was gibt, können wir gerne drüber sprechen. Die aktuelle DOM-Struktur ist so wie sie ist, da ich hoffte maximal flexibel zu sein und sie gut per CSS für die jeweilige Anwendung anpassen zu können. Wenn's was besseres gibt: warum nicht?

Über jQuery Mobile habe ich gehört(! - d.h. kein eigenes Wissen dazu) das man sich das sparen kann, wenn man eh eine eigene Template-Engine hat, wie wir. Sonst würden wir ein "Layout" generieren dass die jQ-Mobile Engine dann nochmal durchpflügt...
Sollte dem so sein, dann würde ich eher dazu tendieren dort die relevanten Aspekte zu "klauen" und hier einzubauen.

[makki]

Die navbar gefällt mir übrigens so richtig gut!
IMHO grosser usability-Fortschritt, beim planet-design muss man vielleicht dann noch eine "farb-entschärfte" Variante oder Flavour für nicht LCARS-Fans auflegen

Makki