Ich bin mir nicht sicher, ob dieser Post nicht an den Stammtisch gehört, aber ich poste hier, weilichdenk, hier lesen ihn mehr, die sich damit auskennen.
Also:
wpf wurdeja auch beworben mit dem Argument, man könne nun Design und Funktion trennen, also Designer-Fachkräfte machen das Design, und Programmierer die Funktionalität.
Zum einen habich Vorbehalte gegen "Designer-Fachkräfte", also Leute, die aufgrund irgendeiner Ausbildung denken, sie könnten eine bessere Useability konzipieren als Programmierer.
Ich stelle mir unter Designer-Fachkraft jemanden vor, der die neueste Mode an KlickiBunti verinnerlicht hat, und denkt, das wäre Useability. Dabei hat IMO Useability kaum was mit KlickiBunt zu tun, sondern läßt sich letzlich wissenschaftlich mit Wahrnehmungs-Psychologischen Versuchsreihen belegen. Die Regeln, die dabei herauskommen, sind übrigens nicht mal viele, und im Grunde trivial:
sich an Gewohnheiten und Erwartungen der Kundschaft orientieren (Innovationen kleinschrittig einführen)
Wesentliches hervorheben
Überladungen vermeiden, sowohl an Menge, als auch an Effekten
Wenn man in die Richtung konzipiert hat, kann man sich IMO überlegen, wieviel an Klickibunti man da einbauen möchte.
Zum anderen sehe ich nicht, dass eine Designer-Fachkraft eine Xaml-Oberfläche programmieren kann. Jdfs bei mir entwickeln sich View und Viewmodel gemeinsam, und mir scheint unmöglich, das zu trennen. Also müsste die DesignerFachkraft über fundierte Programmiererkenntnisse verfügen, so oder so:
Auch wenn der Designer sein Viewmodel beim Programmierer in Auftrag gibt, musser immer noch fähig sein, eine programmier-fachliche Diskussion zu führen, zb. sagt der Programmierer: "mann - Visibility-Property - Quark! Nimm einen BooleanToVisibility-Converter, und verwende die bereits bereitgestellten bool-Property.".
Auch das Xaml selbst, mit seine Trigger, DataTemplates, Styles, Converters, Storyboards, ControlTemplates,... das ist Programmierer-Arbeit vom Feinsten - ich kann mir nicht vorstellen, dass ein Absolvent der HDK (Hochschule der Künste) - Studiengang Design da auch nur ansatzweise Land sieht.
Ja, meine Frage: Weiß jmd, wie das in der Praxis aussieht, mitte Trennung in Designer-Fachkräfte und Programmierer-Fachkräfte - oder war das nur ein Reklame-Bla?
Bei komplizierten Benutzerinterfaces würde ich das auf keinen Fall einen Programmierer gestalten lassen, denn dann sieht es meistens auch so aus.
Es gibt die Möglichkeit, einen Interface-Designer mit dem Entwurf zu beauftragen. Das sind Leute, die haben damit Erfahrung und gehen ganz anders an die Sache heran.
Es gibt auch Interface-Designer, die sich auf WPF spezialisiert haben, die können mit Microsoft Expression Blend einen oder mehrere Prototypen umsetzen und evtl. auch das Endprodukt.
Weeks of programming can save you hours of planning
Interessanterweise verstehe ich genau, was du meinst - mit solchen Anwendungen bin ich zuhauf gestraft :(.
Aber ich denke, das liegt am Programmierer, dasser sich für die Useability seines Produkts einfach nicht interessiert, oder sich damit auseinandersetzt. Btw. dass ihm keiner in die Richtung auf die Füße getreten ist.
Die Auseinandersetzung mit Useability wäre aber sehr einfach für Programmierer, schließlich arbeitet man ja mit Programmierwerkzeugen, die größtenteils vorbildlich sind vonne Useability her.
Da kann man sich vor genialen UI-Konzepten ja kaum retten (Intellisense, Undo-Funktionalität, Fly-Out-Panel, Dragging, TabControls, PropertyGrid, Treeviews, verschiedenste Designer, Smart-Tags, ...).
Und alles effektiv eingesetzt, also nix mit "Jetzt machnwa auch ein Dragging dran, weils schick ist" - wo's ein paar Checkboxen auch täten. - Solche Proggis finden sich ja auch.
Ich kann kaum glauben, dassich eine Ausnahme bin, wennnich will, dass meine Teile mindestens hinreichend useable sind. Und darüberhinaus der Ansicht, dassich gute von schlechter Useability unterscheiden kann.
Aber ok - "Interface-Designer" scheint mir eine Berufsbezeichnung mit deutlichem programmiererischen Schwerpunkt auszusagen, das ist sicher auch etwas, auf das man sich spezialisieren kann.
Aber ich denke, das liegt am Programmierer, dasser sich für die Useability seines Produkts einfach nicht interessiert, oder sich damit auseinandersetzt. Btw. dass ihm keiner in die Richtung auf die Füße getreten ist.
Das ist so nicht richtig finde ich. Ich fuehle mich als Entwickler im Klassendesign wesentlich wohler als im GUI-Design, das ueberlasse ich gerne Leuten, die ein Gefuehl fuer Oberflaechen (Farben, Anordnung, Strukturierung,...) haben.
Bei meinem Ex-Arbeitgeber hatten wir einen Mediendesigner, der die XAML Oberflaeche in Blend designed hat, die Logik wurde vom Entwickler gemacht - Probleme gab es keine, der Designer besaß mit viel ach und krach rudimentaere Programmierkenntnisse.
Ah - interessant!
Musses da nicht einen intensiven Austausch geben, damit das Viewmodel abgestimmt wird? Wenn der MedienDesigner eine Information draggable haben will, oder einen TreeNode clickable, dann muß man doch das VM entsprechend designen, nach meinem Wissensstand.
"Gefühl für Oberflächen" im Sinne von Farben, Anordnung, graphische Strukturierung habich auch nicht.
Aber ich weiß, welche Daten man per Combo anbieten sollte, welche per Listbox, und welche Flächen sizeable sein müssen, und sowas. Und natürlich, ob hierarchische Daten als Treeview anzuzeigen sind, oder als Parent-Child-View, und wo ich einen Einzelblatt-View ergonomisch finde - also funktionale Strukturierung ist schon was für mich.
das würde in die Richtung Behaviors gehen. Das ist völlig okay. Der Designer müsste sich damit theoretisch auskennen. Es gehört mehr oder weniger zur UI. Was getan wurde, ist nichts anders, als vom Entwickler eine Klasse bereitzustellen, die nichts anders als ein Stück Logik enthält. Es ist so eine Grenze zwischen UI und Entwicklung. Trotzdem wäre es die Richtung UI. Man kann es kapseln. Das ist der Punkt. Man kann es auch mit ViewModels gleichsetzen.
Ich werfe einfach mal zwei Gedanken in den Thread: 1.) Man kann eine UI auch ohne ViewModels aufbauen. Ein Beispiel wäre BeeHive. 2.) Die UI kann man von der UI-Logik trennen und wiederrum auf Schichten verteilen. Die UI wäre noch lascher.
Um auf den Punkt zu kommen: Man kann nicht sagen "richtig" oder "falsch". Es gibt zwei Logiken. Eine Logik auf der UI, eine im ViewModel! Je tiefer du gehst, desto mehr gehst du vom ViewModel weg. Die andere Richtung wäre dann extrem gesehen eine komplett losgelöste UI. Noch tiefer: Perspektive wäre jetzt eine Frage!
Aber ich weiß, welche Daten man per Combo anbieten sollte, welche per Listbox, und welche Flächen sizeable sein müssen, und sowas. Und natürlich, ob hierarchische Daten als Treeview anzuzeigen sind, oder als Parent-Child-View, und wo ich einen Einzelblatt-View ergonomisch finde - also funktionale Strukturierung ist schon was für mich.
Musses da nicht einen intensiven Austausch geben, damit das Viewmodel abgestimmt wird? Wenn der MedienDesigner eine Information draggable haben will, oder einen TreeNode clickable, dann muß man doch das VM entsprechend designen, nach meinem Wissensstand.
Soweit ich weiss hat der Designer schlichtweg gesagt welcher Event bedient werden muss, wie das dann letzten Endes implementiert wird ist das Bier des Entwicklers gewesen.
Musses da nicht einen intensiven Austausch geben, damit das Viewmodel abgestimmt wird? Wenn der MedienDesigner eine Information draggable haben will, oder einen TreeNode clickable, dann muß man doch das VM entsprechend designen, nach meinem Wissensstand.
Klar!
Ein besseres Beispiel wäre vielleicht auch noch die Entscheidung, ob es z.B. einen "Speichern"-Knopf geben soll, oder ob Änderungen sofort übernommen werden. Dadurch ändert sich zwar das View nicht wirklich, das ViewModel aber immens.
Daher ist IMHO sogar eher sinnvoll, das ViewModel nach dem View zu erstellen - erst dann weiß man ja, was es alles können muss, um genau zu dem View zu passen.
Eine wirkliche Trennung von View und ViewModel halte ich weder für sinnvoll noch für möglich.
Zu jedem View muss es ein ViewModel geben.
Aber wer ist hier Henne oder Ei ?
Normalerweise wird ja die Anforderung an die SW gestellt, z.b. eine Adresse editierbar zu machen.
Jetzt hat das VM alle Properties und Commands zur Verfügung zu stellen, die dabei Sinn machen.
Jetzt kann sich der Designer richtig austoben.
Validierungen im VM helfen dabei das der UI Designer nichts machen kann, was nicht möglich sein soll.
@ErfinderDesRades:
Zitat
"Gefühl für Oberflächen" im Sinne von Farben, Anordnung, graphische Strukturierung habich auch nicht.
Und deshalb sehen Programme von SW Entwicklern meist bescheiden aus.
Ich habe vor 15 Jahren mal eine UI Designerin kennengelernt, die hat die UI für die Controlsoftware bei einem kanadischen AKW gemacht.
Wenn du dich mal mit sojemandem unterhälst, wird dir schnell klar, das du/wir keine Ahnung hast/haben, was bei gutem UI Design so alles wichtig ist.
"Gefühl für Oberflächen" im Sinne von Farben, Anordnung, graphische Strukturierung habich auch nicht.
Und deshalb sehen Programme von SW Entwicklern meist bescheiden aus.
Das Aussehen in diesem Sinne (Farben, Anordnung, graphische Strukturierung) ist mir auch gar nicht wichtig. Wichtig ist mir die Usability.
In dem Zusammenhang fandich Mr Sparkles Hinweis auf User-Experience besonders wertvoll, da wird User-Experience definiert als zusammengesetzt aus Look, Feel und Usability.
Ich kann jamal ein schlimmes Beispiel für verfehlte Usability beschreiben, nämlich unsere wöchentliche interne Lebensmittel-Bestell-Software:
Da muß man zunächst einen Datum-Dialog öffnen (dauert 2s, bis das öffnet), und ein Datum auswählen.
Dann muß man die Liste der Produkte aufrufen (dauert 2s).
Dort muß man die Produkte auswählen, die man braucht.
Danach erscheint ein weiterere Dialog (2s), wo die ausgewählten Produkte gelistet sind, dort muß man hinschreiben, wieviel man von jedem Item will.
Bestätigen klicksen, und den nächsten Tag in Angriff nehmen.
Es existiert keine tabellarische Übersicht, was in einem gewissen Zeitraum bestellt wurde. Andererseits wird die heute abgegebene Bestellung frühestens in 3 Tagen geliefert.
Wenn also heute Brot zu Neige geht, müsste ich zunächst mich durch 3 Bestellungen klicksen, und nachgucken, was die Kollegen für morgen, übermorgen und überübermorgen bestellt haben, ansonsten kann sein, am Donnerstag sitzen wir auf 6 Broten.
Weil niemand dieses Geklickse auf sich nimmt (er müsste ja nicht nur rumklicksen, sondern die Bestellungen auch notieren, es geht ja um 10-15 Produkte, mit je verschiedenem Vorrats-Stand und Verbrauchs-Geschwindigkeit), sind Brot-Schwemmen und Margarine-Notstand regelmäßig Mißstand bei uns.
Sowas proggen SW-Entwickler, denen man nicht auf die Füße tritt.
Denn technisch ist es kein Problem, das Warenangebot in einer Wochen-Tabelle anzuzeigen, inklusive der bereits bestellten Sachen, und was man in 3 Tagen und danach braucht, könnte man auch dort eingeben.
Das ist reine Usability, hat mit Look und Feel noch nichts zu tun, und das können dieselben SW-Entwickler, die obiges Beispiel produziert haben, auch, wenn man ihnen nur gesagt hätte, dasses sollen (oder wenn sie Interesse dafür aufbrächten).
Obs ein Designer kann, mit Schwerpunkt Farben, Anordnung und graphische Strukturierung, bleibt dahingestellt - gute Leute können das bestimmt, vlt. auch hervorragend.
Jdfs. kann ich dir nicht zustimmen, wenn du sagst, ich/wir hätten keine Ahnung davon, was wichtig ist beim UI, und müssten das Leuten überlassen, dies besser wissen.
Vlt nicht die volle Ahnung in allen möglichen Belangen, aber Ahnung auf jeden Fall.
