.NET GUI

Hi,

mich würde interessieren, wie der Entwicklungsprozess in Bezug auf Usability bei euch so aussieht? Ich meine damit wie die Schnittstelle zwischen dem Entwickler und dem UI-Designer definiert wird. Oftmals hat eine Person beide Jobs zu machen, aber wie läuft das wenn dies zwei getrennte Personen sind? Dort entstehen bei uns manchmal Schwierigkeiten über die Zuständigkeit eines Problems oder es verändern sich die Anforderungen aus dem UI während der Implementierung. Klar ist hier Flexibilität gefragt und die bieten wir natürlich. :) Aber mich würden trotzdem eure Erfahrungen oder Ideen dazu interessieren, wie man so etwas verbessern könnte.

Grüße,

Lars

http://blog.lars-keller.net

In Bezug auf eine spezielle Technologie (ASP.NET, WPF, ...) oder ist deine Frage allgemeiner Natur, d.h. unabhängig der eingesetzten Technologie?

ja ich meinte mehr allgemeiner Natur. Es gibt, denke ich, immer Schwierigkeiten zwischen diesen beiden Welten, würde mich mal interessieren wie ihr damit so umgeht.

Grüße

Lars

Meiner Meinung nach hängt das von der verwendeten Technologie ab. Bei einigen ist eine Trennung einfacher und bei einigen erweist sie sich als recht schwierig.

Einfach:

• WPF
• ASP.NET

Schwierig:

• Windows Forms

Bei der WPF oder bei ASP.NET ist es wirklich möglich, den Designer hinzusetzen und an seinem Design arbeiten zu lassen, während ein Entwickler seinen Code schreibt. Natürlich muss auch hier eine gute Kommunikation stattfinden, da es in einigen Situationen unerlässlich ist, dass miteinander gesprochen wird. Ganz klar. Hast du jedoch eine Windows Forms Anwendung, kannst du zwar die Entwickler (je nach Größe des Projektes) aufteilen (jeder arbeitet an einem anderen Teil der Logik), hast aber sicherlich Schwierigkeiten, den Designer zu integrieren. Warum? Nun, es fehlt einfach an der Möglichkeit, den Designer etwas machen zu lassen. Er müsste hier schon mit Visual Studio im Forms Designer arbeiten. Dies endet jedoch sehr schnell, wenn Steuerelemente ein bestimmtes Aussehen besitzen müssen. In dem Fall sind Ableitungen notwendig, die ein Designer (sofern er nicht auch Entwickler ist) nicht machen kann.

Also in Sachen UI-Entscheidungsfindung gehört der Entwickler imho allerhöchstens noch eingebunden, um ihn zu fragen ob dieses oder jenes angedachte UI-Feature so realisierbar ist. Ansonsten hat der Entwickler das dann einfach umzusetzen, was an Vorgaben vom Designer kommt.

Bei uns haben sich in bezug auf ASP.NET-Projekte eigentlich 2 Wege etabliert:

1. Der Entwickler baut einen Dummy, z.B. ein Formular und deutet allerhöchstens an, was der Designer zu beachten hat (Positionierung der Elemente ggf.). Wenn der Dummy fertig ist und soweit funktioniert wie er soll, kommt der Designer ins Spiel und fängt an das Ding zu stylen. Im besten Fall war es das dann, im Normalfall muss natürlich hier und da auch vom Entwickler noch was geändert werden. Ein ständiger Austausch ist sowieso Grundvoraussetzung.
   
   
2. Der Designer liefert das Design und setzt dieses in XHTML und CSS exakt um.
   
   Das nämlich würde ich nicht wirklich als Entwickler-Arbeit bezeichnen, auch wenn viele Entwickler das zu ihrem Aufgabenbereich zählen - aber dementsprächend sehen dann oft auch die Resultate aus (vor allem wenn sich Desktop-Entwickler an Web-Applikationen machen ...).
   
   Der Entwickler geht dann her und haucht dem Ganzen, evtl. einfach nur eine dummy.html, "Leben ein". D.h. auszublendende <div />s werden durch <asp:Panel /> ersetz, Button-Events definiert usw. usf.
   
   

Beides funktioniert gut und ist, wenn das Team eingespielt ist, auch effizient. Vor allem ermöglicht es auch, dass sich jeder auf seine eigenen Themen konzentrieren kann und nicht der Entwickler zum Designer und umgekehrt mutieren muss.

Hallo zusammen,

Thomas Bandt:

Bei uns haben sich in bezug auf ASP.NET-Projekte eigentlich 2 Wege etabliert: [..]

wird bei uns ähnlich gehandhabt.

Thomas Bandt:

Der Designer liefert das Design und setzt dieses in XHTML und CSS exakt um.

Ist einer der gängigsten Wege, wenn auch dein Erstgenannter häufiger in Verwendung sein sollte. Nur betrifft das eben die Webgeschichte, wo sich die Trennung zwischen Präsentation und Logik schon vor längerer Zeit durchgesetzt hat. Gerade aber in der Client-Entwicklung sieht das dann doch noch immer anders aus, zumal wir erst mit WPF eine gute Möglichkeit bekommen haben, dies genauso zu machen, wie es bei Webanwendungen bereits seit Jahren praktiziert wird.

 

Norbert Eder:

Nur betrifft das eben die Webgeschichte, wo sich die Trennung zwischen Präsentation und Logik schon vor längerer Zeit durchgesetzt hat.

 

Da wäre ich ganz vorsichtig. Ich behaupte eher, dass 90% aller Websites/Webanwendungen immer noch aus feinstem Spaghetti-Code bestehen, ohne Trennung von Layout und Logik. Das ist noch immer eher der Idealfall.

(Und das es auch wieder rückwärts geht, zeigt z.B. ASP.NET MVC ...) 

Thomas Bandt:

1. Der Entwickler baut einen Dummy, z.B. ein Formular und deutet allerhöchstens an, was der Designer zu beachten hat (Positionierung der Elemente ggf.). Wenn der Dummy fertig ist und soweit funktioniert wie er soll, kommt der Designer ins Spiel und fängt an das Ding zu stylen. Im besten Fall war es das dann, im Normalfall muss natürlich hier und da auch vom Entwickler noch was geändert werden. Ein ständiger Austausch ist sowieso Grundvoraussetzung.
   
   
2. Der Designer liefert das Design und setzt dieses in XHTML und CSS exakt um.
   
   Das nämlich würde ich nicht wirklich als Entwickler-Arbeit bezeichnen, auch wenn viele Entwickler das zu ihrem Aufgabenbereich zählen - aber dementsprächend sehen dann oft auch die Resultate aus (vor allem wenn sich Desktop-Entwickler an Web-Applikationen machen ...).
   

Ja genau so in der Art läuft das auch bei uns, aber da kommen öfter auch mal Probleme auf. Beispielsweise, wenn der Designer eingebunden wird nach Weg 1. Der Designer stellt aber plötzlich fest, dass bestimmte Funktionalität gebraucht wird, weil er sein Design/Vision umsetzen möchte. Oftmals kommen gute Ideen bei der Arbeit am Design, sich vorher soweit in ein Projekt rein zudenken, würde ja bedeuten man macht vorher komplette Designentwürfe machen würde. (wäre sicherlich der schönste Weg, aber nicht jeder Kunde zahlt das oder man muss mit einer Werbeagentur zusammen arbeiten, wo das Internet-Know-How manchmal "begrenzt" ist.) Hier genau setzt meine Frage an, wie geht ihr damit um, gibt es spezielle Iterationsphasen wo noch Änderungen zurück in die Entwicklung gegeben werden können oder entscheidet ihr das von Fall zu Fall? Ist mir schon klar, dass es schwer ist sowas pauschal zu beantworten, aber vielleicht kennt ihr ja diese Problematik und handhabt die mit einer speziellen Prozedur (mein neues Lieblingswort, habe gestern Apollo 13 gesehen ;-)).

Zu Weg 2: Dieser Weg klappt nicht wirklich, wenn das Projekt eine bestimmte Größe überschreitet. Der Designer muss sehr viel Know-How aus der Entwicklung haben, damit er nicht irgendwelche "wilden" User Interface, mit Funktionalitäten die in der Entwicklung sehr Zeitaufwendig sind oder gar nicht gehen, designt.

Grüße

Lars

Thomas Bandt:

Da wäre ich ganz vorsichtig. Ich behaupte eher, dass 90% aller Websites/Webanwendungen immer noch aus feinstem Spaghetti-Code bestehen, ohne Trennung von Layout und Logik. Das ist noch immer eher der Idealfall.

(Und das es auch wieder rückwärts geht, zeigt z.B. ASP.NET MVC ...) 

Ok, anders formulieren: Wo seit Jahren die Möglichkeit einer sauberen Trennung bestünde ...

LarsKeller:

Ja genau so in der Art läuft das auch bei uns, aber da kommen öfter auch mal Probleme auf. Beispielsweise, wenn der Designer eingebunden wird nach Weg 1. Der Designer stellt aber plötzlich fest, dass bestimmte Funktionalität gebraucht wird, weil er sein Design/Vision umsetzen möchte. Oftmals kommen gute Ideen bei der Arbeit am Design, sich vorher soweit in ein Projekt rein zudenken, würde ja bedeuten man macht vorher komplette Designentwürfe machen würde. (wäre sicherlich der schönste Weg, aber nicht jeder Kunde zahlt das oder man muss mit einer Werbeagentur zusammen arbeiten, wo das Internet-Know-How manchmal "begrenzt" ist.) Hier genau setzt meine Frage an, wie geht ihr damit um, gibt es spezielle Iterationsphasen wo noch Änderungen zurück in die Entwicklung gegeben werden können oder entscheidet ihr das von Fall zu Fall? Ist mir schon klar, dass es schwer ist sowas pauschal zu beantworten, aber vielleicht kennt ihr ja diese Problematik und handhabt die mit einer speziellen Prozedur (mein neues Lieblingswort, habe gestern Apollo 13 gesehen ;-)).

Nö, da gibt es bei uns keine "Vorschriften" ;-). Es kommt ja auch tatsächlich immer darauf an wer an so etwas beteiligt ist, also sowohl intern als auch extern. Extern gibt es natürlich massive Unterschiede, das reicht bei uns von gelieferten Photoshoplayouts wo ich dann die immer gleichen Rückfragen stellen muss (Wie sieht die Navigation ausgeklappt aus? Wie das Layout auf meinem 1680x1050 Pixel großen Monitor?), bis hin zu Agenturen wo vom Wireframe bis zum fertigen Layout alles durchkonzeptioniert und abgestimmt ist, bevor es umgesetzt wird.

Wir handhaben dass dann immer ganz pragmatisch, Designer und Entwickler müssen sich sowieso ständig abstimmen.

 

LarsKeller:

Zu Weg 2: Dieser Weg klappt nicht wirklich, wenn das Projekt eine bestimmte Größe überschreitet. Der Designer muss sehr viel Know-How aus der Entwicklung haben, damit er nicht irgendwelche "wilden" User Interface, mit Funktionalitäten die in der Entwicklung sehr Zeitaufwendig sind oder gar nicht gehen, designt.

 

Siehe meine erste Antwort - sehe das etwas anders - Interfaces werden nicht von Entwicklern gemacht, sondern von Designern. Entwickler bindet man in den Entwicklungsprozess "nur" ein, um solche Fehlentwicklungen eben zu vermeiden, aber zu entscheiden haben sie das nicht ... die haben andere Baustellen.

Hallo Zusammen

Eine andere Frage... Kennt Jemand von Euch ein Buch über das Thema, welches er/sie empfehlen kann?

Viele Grüsse

Özgür Aytekin

Zu welchem Thema genau? 

Und wer kümmert sich um die Ergonomie?

Bin da eher der Meinung, dass dies eine Sache des Enwicklers ist, aber bin mir da noch nicht all zu Sicher.

Gutes Aussehen und Features sind zwei Wichtige Dinge, aber streiten sich die beiden dann was Ergonomie und Usability angeht?

Was qualifiziert denn hier per se gerade den Entwickler?