© Excellent backgrounds/Shutterstock.com
Java Magazin
Entwicklung für mobile Geräte heißt UI-Entwicklung

Ein Herz für UI

Wir benötigen eine App, aber wie, auf welcher Plattform und wer macht das? Wir entwickeln ohnehin für Unix und Linux, wie schwer kann es sein, für Android zu entwickeln? Kennen Sie diese Argumentationslinie aus Ihrem Unternehmen? Dann sind Sie hier richtig.

Jörg Pechau


Im ersten Teil dieser Artikelserie haben wir uns mit der Ausgangslage in Unternehmen, den technischen Voraussetzungen und der Aufgabenteilung in den Teams beschäftigt. Nach dem „Backend“ kommt jetzt ein sehr wichtiger Teil: die UI-Entwicklung. Neben dem durch die Beschränkungen von Smartphones wieder aktuell gewordenem Thema „Ressourcen“ ist wahrscheinlich die Notwendigkeit, sich auch auf UI-Entwicklung einlassen zu müssen, die größte Herausforderung für „klassische“ Softwareentwickler. Wer von den Lesern schon einmal Java-Entwickler für Projekte oder zur Einstellung gesucht hat, kennt vielleicht diesen Disclaimer: „UIs entwickele ich nicht so gerne, lieber serverseitig...“. Da in der Java-Enterprise-Entwicklung seit Langem der Trend Richtung webbasierten UIs geht, wird das UI-Design häufig ein Thema von Designern. Softwareentwickler programmieren häufig diese Entwürfe nur noch aus. Das andere Extrem ist, dass UIs gar nicht entworfen werden, sondern irgendwie „entstehen“, was auch nicht unbedingt zu besseren Ergebnissen führt. Die Frage nach dem Interaktionsdesign [1], nach der Aufgabenangemessenheit [2] stellt sich häufig nicht, sondern ist ein PAL (Problem anderer Leute [3]).

ArtikelserieTeil 1: Einleitung, notwendiges VorwissenTeil 2: UI-Entwicklung

Im letzten Artikel haben wir den Zusammenhang zwischen Ressourcen, Programmiermustern und der „User Experience“ bereits hergestellt: Wenn wir es z. B. dem Anwender beim Start unserer App zumuten, erst einmal ein Dutzend Garbage Collections abwarten zu dürfen, erzeugt das keine Begeisterung sondern eher die Frage, warum der Start so lange dauert. Wenn eine Synchronisation lange dauert und den Anwender im Unklaren lässt, ob überhaupt und was eigentlich gerade geschieht, egal ob wir uns gerade in einem Funkschatten aufhalten oder Dank eines ungeschickten Informationsdesigns viel zu viele Daten übertragen, dann fühlt sich das für Anwender schlecht an.

Wenn wir unseren Job einigermaßen ernst nehmen, wollen wir aber, dass unsere App gerne genutzt wird, dass sie weiterempfohlen wird, dass sie ein Aushängeschild für uns und bzw. oder unser Unternehmen ist. Was wir nahe unserer Komfortzone, d. h. im Softwareentwurf, machen können, haben wir zuvor angeschaut – das andere große Thema sind UIs.

Interaction Design

In der Regel können wir davon ausgehen, dass unsere App ein UI haben wird. Im Erleben der App nimmt ein Anwender meist die App und das Gerät als Einheit war. Er interagiert nicht über das Gerät mit der App sonder...

Java Magazin
Entwicklung für mobile Geräte heißt UI-Entwicklung

Ein Herz für UI

Wir benötigen eine App, aber wie, auf welcher Plattform und wer macht das? Wir entwickeln ohnehin für Unix und Linux, wie schwer kann es sein, für Android zu entwickeln? Kennen Sie diese Argumentationslinie aus Ihrem Unternehmen? Dann sind Sie hier richtig.

Jörg Pechau


Im ersten Teil dieser Artikelserie haben wir uns mit der Ausgangslage in Unternehmen, den technischen Voraussetzungen und der Aufgabenteilung in den Teams beschäftigt. Nach dem „Backend“ kommt jetzt ein sehr wichtiger Teil: die UI-Entwicklung. Neben dem durch die Beschränkungen von Smartphones wieder aktuell gewordenem Thema „Ressourcen“ ist wahrscheinlich die Notwendigkeit, sich auch auf UI-Entwicklung einlassen zu müssen, die größte Herausforderung für „klassische“ Softwareentwickler. Wer von den Lesern schon einmal Java-Entwickler für Projekte oder zur Einstellung gesucht hat, kennt vielleicht diesen Disclaimer: „UIs entwickele ich nicht so gerne, lieber serverseitig...“. Da in der Java-Enterprise-Entwicklung seit Langem der Trend Richtung webbasierten UIs geht, wird das UI-Design häufig ein Thema von Designern. Softwareentwickler programmieren häufig diese Entwürfe nur noch aus. Das andere Extrem ist, dass UIs gar nicht entworfen werden, sondern irgendwie „entstehen“, was auch nicht unbedingt zu besseren Ergebnissen führt. Die Frage nach dem Interaktionsdesign [1], nach der Aufgabenangemessenheit [2] stellt sich häufig nicht, sondern ist ein PAL (Problem anderer Leute [3]).

ArtikelserieTeil 1: Einleitung, notwendiges VorwissenTeil 2: UI-Entwicklung

Im letzten Artikel haben wir den Zusammenhang zwischen Ressourcen, Programmiermustern und der „User Experience“ bereits hergestellt: Wenn wir es z. B. dem Anwender beim Start unserer App zumuten, erst einmal ein Dutzend Garbage Collections abwarten zu dürfen, erzeugt das keine Begeisterung sondern eher die Frage, warum der Start so lange dauert. Wenn eine Synchronisation lange dauert und den Anwender im Unklaren lässt, ob überhaupt und was eigentlich gerade geschieht, egal ob wir uns gerade in einem Funkschatten aufhalten oder Dank eines ungeschickten Informationsdesigns viel zu viele Daten übertragen, dann fühlt sich das für Anwender schlecht an.

Wenn wir unseren Job einigermaßen ernst nehmen, wollen wir aber, dass unsere App gerne genutzt wird, dass sie weiterempfohlen wird, dass sie ein Aushängeschild für uns und bzw. oder unser Unternehmen ist. Was wir nahe unserer Komfortzone, d. h. im Softwareentwurf, machen können, haben wir zuvor angeschaut – das andere große Thema sind UIs.

Interaction Design

In der Regel können wir davon ausgehen, dass unsere App ein UI haben wird. Im Erleben der App nimmt ein Anwender meist die App und das Gerät als Einheit war. Er interagiert nicht über das Gerät mit der App sonder...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang