Sehr schön beschrieben. Qualitativ hochwertige Software würde berücksichtigen zu wann der Umzug stattfindet und ggf. auch eine Historie aufbauen, sodass man nachvollziehen kann, wann sich was geändert hat.
Ich habe noch vor wenigen Jahren genau das so gelernt bekommen, dass REST eben genau CRUD ist. Liest man ja auch sonst überall anders genau so. Allerdings bin ich dann auch als "nur" programmier interessierter über die genannten probleme beim valideren oder ähnlichem gestolpert. Demnach bin ich genau deiner Meinung.
Ich bin zwar noch nicht in der IT beruflich tätig, aber als Student finde ich es intuitiv richtig, wenn man vor allem die fachliche Seite nicht außer Acht lässt. Die technischen Gegebenheiten können noch so gut sein, wenn jedoch der Anwender sich erst in die UI einarbeiten muss, sich gar an neue Begriffe gewöhnen muss, ist das insgesamt schlecht. Gute Softwarequalität heißt für mich, das neben der technischen Umsetzung auch der Benutzer, der letzten Endes mit dem System kommuniziert, sich nahzu mühelos darein denken kann, weil man eben die Fachtermonologie auch berücksichtigt. Dann nämlich ist der Kunde zufrieden, weil er weniger Zeit benötigt um das System zu verstehen und man hat verstanden, worum es am Ende geht. Eine gutes Softwaresystem zu entwickeln.
Sehr guter Beitrag und klingt auch schlüssig, ich habe nur ein großes Fragezeichen im Kopf wie die UI dann aussehen sollte/könnte. Man kennt ja wie von Tobias schon beschrieben den generischen "Stammdaten bearbeiten" Dialog den du hier berechtigterweise kritisierst, aber wie bilde ich denn alle X fachlichen Fälle im UI ab ohne eine Liste zu schreiben "Haben Sie geheiratet?", "Sind Sie umgezogen?", ... also mit ordentlicher UX ?
[gr] Ich weiß, dass die Antwort erst einmal nicht sehr befriedigend ist, aber - wie so oft - es kommt darauf an. Ich nenn Dir erst mal zwei, drei Beispiele, um zu zeigen, wie unterschiedlich man das lösen kann: Ich weiß nicht, ob Du jemals mit Windows Server zu tun hattest (und ich weiß auch nicht, ob das heute noch so ist, ich beziehe mich so auf Windows Server 2003, so um den Dreh …). Wenn Du den herunterfahren oder neu starten willst, gehst Du - wie unter Windows üblich - auf's Startmenü, klickst dann auf "Beenden" (oder wie genau das bei Windows heißt), und dann kommt aber, anders als bei den Desktop-Varianten, erst mal ein Dialog, der Dich auffordert, anzugeben, warum Du beenden / neu starten willst. Das sind dann IIRC vier Radiobuttons gewesen, und ein Textfeld, und Du musstest eins anklicken und etwas eingeben, ansonsten konntest Du nicht neu starten. Das ist eine Möglichkeit. Dann, stell Dir einen Kalender vor, so was wie in Outlook. Wenn Du den verschieben willst, verschiebst Du ihn mit der Maus im Zeitraster. Wenn Du ihn verlängern oder verkürzen willst, machst Du das auch im Zeitraster, aber mit einer anderen Aktion. Und wenn Du ihn absagen willst, markierst Du ihn und drückst Backspace. Hier hast Du drei fachliche Aktionen ("Meeting verschieben", "Meeting verkürzen oder verlängern", "Meeting absagen"), und das ergibt sich einfach aus der Darstellung und einer schlau gemachten UI. Klar hätte man das auch alles hinter einem "Meeting bearbeiten"-Dialog mit zig Eingabefeldern und einem "Speichern"-Button abbilden können, aber mit dem Zeitraster ist es intuitiver und bildet die tatsächliche Fachlichkeit viel besser ab. Soll heißen: Häufig genügt es schon, wenn man von "langweiligen" Formularen weg geht, dass sich daraus andere UI/UX-Muster ergeben. Das ist natürlich nun in Bezug auf die Stammdaten schwer, weil die wiederum tatsächlich ein Formular darstellen. Aber warum eigentlich? Stell Dir das weniger als Formular und mehr wie eine Karte vor, mit grafischen Elementen. Zum Beispiel so eine kleine Figur und daneben steht der Name. Ein Klick auf die Figur und Du änderst Eigenschaften der Person. Ein Klick auf das Häuschen neben der Adresse und Du willst offensichtlich etwas ändern, was sich auf den Ort bezieht, nicht direkt auf die Person. Und die konkrete Intention kannst Du dann zum Beispiel wieder so erfragen, wie in Windows Server. Also Bearbeiten lassen und dann nach dem Grund fragen. Oder, ein Klick auf die Figur bringt einen Assistenten hoch, der Dir erst einmal anbietet, was Du nun tun kannst - und je nachdem, was Du auswählst, geht es anders weiter. Worauf ich hinaus will: Man muss gedanklich weg von Formularen, und man muss weg von "ich bearbeite Daten". Natürlich willst Du am Ende keine 30 verschiedenen Buttons haben, aber die Beispiele zeigen glaube ich ganz gut, dass man das auch durchaus auf andere, kreativere Weisen lösen kann. Und zugegeben - das Beispiel mit den Stammdaten ist nicht besonders gut, da ist mir auf die Schnelle keine wirklich gute Lösung eingefallen. Ich bin mir aber sicher, wenn man sich Zeit nimmt, und sich mal mit einer UI/UX-Designerin oder einem UI/UX-Designer zusammen tut, dann kommen da überraschend gute Lösung bei raus. Hope that helps 😊
Wenn ich das Beispiel Umzug vor Augen habe, dann stelle ich mir die fachliche Umsetzung wie folgt vor: Die Mitarbeiterin aus dem Büro klickt auf den Mitarbeiter und dann auf Daten bearbeiten, anschließend öffnet sich ein Assistent auf dem der Grund der Änderung gefragt wird. Die Mitarbeiterin klickt dann auf Umzug, dann öffnet sich ein zusätzliches Formular was ausschließlich relevante Daten für einen Umzug ändern lässt. Im Anschluss wird die Änderung an die API geschickt und zwar an eine Funktion in der API die ausschließlich den Umzug behandelt und validiert. Soll ich mir die fachliche Umsetzung so vorstellen?
@@thenativeweb @Tobias , eigentlich klickt man nicht unbedingt auf ein Abstraktes "dann auf Daten bearbeiten" - sondern geht direkt in den fachlichen Dialog "privater Umzug eines Mitarbeiters", der genau die relevanten Felder zur Änderung anzeigt oder abfragt. Ein abstraktes "Daten bearbeiten" entspricht ja der allgemeinen "update" Funktion. Dies sollte im UI höchstens zur Gruppierung im Menu für alle semantisch verwandten Änderungen genutzt werden. Da gibt es vielleicht die Gruppen "private Änderungen" und "betriebliche Änderungen", die jeweils unterschiedliche fachliche Aufgaben gruppieren. Soweit mein Verständnis von Fachlichkeit und Auswirkung auf das UI.
Bei uns ist es leider ausschließlich technisch. Das führt auch tatsächlich immer wieder zu Problemen. Wir verwenden eine objektorientierte Datenbank (Schon esoterisch genug...) und das sieht man auch im UI immer wieder mal. Es ist alles nicht so wirklich einfach zu bedienen und alles wird sehr verschachtelt. Wenn wir das dann etwas platt klopfen wollen, versuchen wir die Daten im Frontend entsprechend umzustricken und machen dann JSON => Server => DB, wenn man so will. Klappt an sich auch. So kommt man an die Fachlichkeit ran, aber schön is dat net. Wir haben zwar einzelne APIs, aber die sind eher auch technisch, wie z.B. Alle Mitglieder aus einem Arbeitsbereich ausladen oder übertragen.
[gr] Ja, verstehe … klingt so ein bisschen nach "man versucht halt, das Beste draus zu machen" … Gibt es denn Ansätze oder ist das ein Thema bei Euch, daran potenziell etwas zu ändern?
@@thenativeweb nicht wirklich. Da die Software schon 25 Jahre alt ist haben wir da ganz andere Probleme. Teilweise sind da Implementierungen drin, die es jetzt in Python geschafft haben, die wir aber trotzdem nicht nutzen können, weil die inkompatibel sind und eine Änderung die Stabilität massiv gefährden würde.
Sehr schön beschrieben. Qualitativ hochwertige Software würde berücksichtigen zu wann der Umzug stattfindet und ggf. auch eine Historie aufbauen, sodass man nachvollziehen kann, wann sich was geändert hat.
Sehr guter Ansatz. Schön, dass nochmal vor Augen geführt zu bekommen :-)
[gr] Vielen Dank 😊
Sehr guter Beitrag!
Vielen Dank.
[gr] Vielen Dank, das freut mich 😊
Ich habe noch vor wenigen Jahren genau das so gelernt bekommen, dass REST eben genau CRUD ist. Liest man ja auch sonst überall anders genau so. Allerdings bin ich dann auch als "nur" programmier interessierter über die genannten probleme beim valideren oder ähnlichem gestolpert. Demnach bin ich genau deiner Meinung.
[gr] REST = CRUD ist ja auch so - nur ist das leider, anders als oft behauptet, IMHO kein Vorteil.
Ich bin zwar noch nicht in der IT beruflich tätig, aber als Student finde ich es intuitiv richtig, wenn man vor allem die fachliche Seite nicht außer Acht lässt. Die technischen Gegebenheiten können noch so gut sein, wenn jedoch der Anwender sich erst in die UI einarbeiten muss, sich gar an neue Begriffe gewöhnen muss, ist das insgesamt schlecht. Gute Softwarequalität heißt für mich, das neben der technischen Umsetzung auch der Benutzer, der letzten Endes mit dem System kommuniziert, sich nahzu mühelos darein denken kann, weil man eben die Fachtermonologie auch berücksichtigt. Dann nämlich ist der Kunde zufrieden, weil er weniger Zeit benötigt um das System zu verstehen und man hat verstanden, worum es am Ende geht. Eine gutes Softwaresystem zu entwickeln.
[gr] Da kann ich nur zustimmen 😊
Sehr guter Beitrag und klingt auch schlüssig, ich habe nur ein großes Fragezeichen im Kopf wie die UI dann aussehen sollte/könnte. Man kennt ja wie von Tobias schon beschrieben den generischen "Stammdaten bearbeiten" Dialog den du hier berechtigterweise kritisierst, aber wie bilde ich denn alle X fachlichen Fälle im UI ab ohne eine Liste zu schreiben "Haben Sie geheiratet?", "Sind Sie umgezogen?", ... also mit ordentlicher UX ?
[gr] Ich weiß, dass die Antwort erst einmal nicht sehr befriedigend ist, aber - wie so oft - es kommt darauf an. Ich nenn Dir erst mal zwei, drei Beispiele, um zu zeigen, wie unterschiedlich man das lösen kann:
Ich weiß nicht, ob Du jemals mit Windows Server zu tun hattest (und ich weiß auch nicht, ob das heute noch so ist, ich beziehe mich so auf Windows Server 2003, so um den Dreh …). Wenn Du den herunterfahren oder neu starten willst, gehst Du - wie unter Windows üblich - auf's Startmenü, klickst dann auf "Beenden" (oder wie genau das bei Windows heißt), und dann kommt aber, anders als bei den Desktop-Varianten, erst mal ein Dialog, der Dich auffordert, anzugeben, warum Du beenden / neu starten willst. Das sind dann IIRC vier Radiobuttons gewesen, und ein Textfeld, und Du musstest eins anklicken und etwas eingeben, ansonsten konntest Du nicht neu starten. Das ist eine Möglichkeit.
Dann, stell Dir einen Kalender vor, so was wie in Outlook. Wenn Du den verschieben willst, verschiebst Du ihn mit der Maus im Zeitraster. Wenn Du ihn verlängern oder verkürzen willst, machst Du das auch im Zeitraster, aber mit einer anderen Aktion. Und wenn Du ihn absagen willst, markierst Du ihn und drückst Backspace. Hier hast Du drei fachliche Aktionen ("Meeting verschieben", "Meeting verkürzen oder verlängern", "Meeting absagen"), und das ergibt sich einfach aus der Darstellung und einer schlau gemachten UI. Klar hätte man das auch alles hinter einem "Meeting bearbeiten"-Dialog mit zig Eingabefeldern und einem "Speichern"-Button abbilden können, aber mit dem Zeitraster ist es intuitiver und bildet die tatsächliche Fachlichkeit viel besser ab.
Soll heißen: Häufig genügt es schon, wenn man von "langweiligen" Formularen weg geht, dass sich daraus andere UI/UX-Muster ergeben.
Das ist natürlich nun in Bezug auf die Stammdaten schwer, weil die wiederum tatsächlich ein Formular darstellen. Aber warum eigentlich? Stell Dir das weniger als Formular und mehr wie eine Karte vor, mit grafischen Elementen. Zum Beispiel so eine kleine Figur und daneben steht der Name. Ein Klick auf die Figur und Du änderst Eigenschaften der Person. Ein Klick auf das Häuschen neben der Adresse und Du willst offensichtlich etwas ändern, was sich auf den Ort bezieht, nicht direkt auf die Person. Und die konkrete Intention kannst Du dann zum Beispiel wieder so erfragen, wie in Windows Server. Also Bearbeiten lassen und dann nach dem Grund fragen. Oder, ein Klick auf die Figur bringt einen Assistenten hoch, der Dir erst einmal anbietet, was Du nun tun kannst - und je nachdem, was Du auswählst, geht es anders weiter.
Worauf ich hinaus will: Man muss gedanklich weg von Formularen, und man muss weg von "ich bearbeite Daten". Natürlich willst Du am Ende keine 30 verschiedenen Buttons haben, aber die Beispiele zeigen glaube ich ganz gut, dass man das auch durchaus auf andere, kreativere Weisen lösen kann. Und zugegeben - das Beispiel mit den Stammdaten ist nicht besonders gut, da ist mir auf die Schnelle keine wirklich gute Lösung eingefallen. Ich bin mir aber sicher, wenn man sich Zeit nimmt, und sich mal mit einer UI/UX-Designerin oder einem UI/UX-Designer zusammen tut, dann kommen da überraschend gute Lösung bei raus.
Hope that helps 😊
@@thenativeweb das hilft auf jeden Fall, vielen Dank für die ausführliche Antwort!
@@boris8983 [gr] Das freut mich 😊
Wenn ich das Beispiel Umzug vor Augen habe, dann stelle ich mir die fachliche Umsetzung wie folgt vor:
Die Mitarbeiterin aus dem Büro klickt auf den Mitarbeiter und dann auf Daten bearbeiten, anschließend öffnet sich ein Assistent auf dem der Grund der Änderung gefragt wird.
Die Mitarbeiterin klickt dann auf Umzug, dann öffnet sich ein zusätzliches Formular was ausschließlich relevante Daten für einen Umzug ändern lässt.
Im Anschluss wird die Änderung an die API geschickt und zwar an eine Funktion in der API die ausschließlich den Umzug behandelt und validiert.
Soll ich mir die fachliche Umsetzung so vorstellen?
[gr] Ganz genau 👍
Also natürlich gibt es verschiedene Varianten, wie man das in der UI umsetzen kann, aber im Prinzip ja 😊
@@thenativeweb @Tobias , eigentlich klickt man nicht unbedingt auf ein Abstraktes "dann auf Daten bearbeiten" - sondern geht direkt in den fachlichen Dialog "privater Umzug eines Mitarbeiters", der genau die relevanten Felder zur Änderung anzeigt oder abfragt. Ein abstraktes "Daten bearbeiten" entspricht ja der allgemeinen "update" Funktion. Dies sollte im UI höchstens zur Gruppierung im Menu für alle semantisch verwandten Änderungen genutzt werden. Da gibt es vielleicht die Gruppen "private Änderungen" und "betriebliche Änderungen", die jeweils unterschiedliche fachliche Aufgaben gruppieren. Soweit mein Verständnis von Fachlichkeit und Auswirkung auf das UI.
[gr] Das ist eine super Anmerkung, vielen Dank! 😊
Vielen Dank 👍
[gr] Gerne 😊
Bei uns ist es leider ausschließlich technisch. Das führt auch tatsächlich immer wieder zu Problemen. Wir verwenden eine objektorientierte Datenbank (Schon esoterisch genug...) und das sieht man auch im UI immer wieder mal. Es ist alles nicht so wirklich einfach zu bedienen und alles wird sehr verschachtelt. Wenn wir das dann etwas platt klopfen wollen, versuchen wir die Daten im Frontend entsprechend umzustricken und machen dann JSON => Server => DB, wenn man so will. Klappt an sich auch. So kommt man an die Fachlichkeit ran, aber schön is dat net. Wir haben zwar einzelne APIs, aber die sind eher auch technisch, wie z.B. Alle Mitglieder aus einem Arbeitsbereich ausladen oder übertragen.
[gr] Ja, verstehe … klingt so ein bisschen nach "man versucht halt, das Beste draus zu machen" …
Gibt es denn Ansätze oder ist das ein Thema bei Euch, daran potenziell etwas zu ändern?
@@thenativeweb nicht wirklich. Da die Software schon 25 Jahre alt ist haben wir da ganz andere Probleme. Teilweise sind da Implementierungen drin, die es jetzt in Python geschafft haben, die wir aber trotzdem nicht nutzen können, weil die inkompatibel sind und eine Änderung die Stabilität massiv gefährden würde.
[gr] Verstehe… nur ist das ja keine Lösung auf Dauer, weil Ihr Euch ja immer weiter von dem entfernt, wie es sein sollte (aber wen erzähle ich das)…
Klingt auch so bissel nach „das sind halt so gewachsene Strukturen“ 😉
Eines machst du damit kaputt: Geld verdienen mit Schulungen zu der Software 😉
[gr] 🤣🤣🤣