Viele Designer kennen es: "Grafiken für die Entwicklung exportieren". Gerade für Android können da bis zu sechs verschiedene Auflösungen für ein Icon anfallen. Aber auch für iOS sind es mittlerweile drei Auflösungen, in denen man die Grafiken bereitstellen muss. Das Problem: Es ist eine mühselige Arbeit, die schnell viel Zeit beanspruchen kann.

Grafiken mit Hilfe bestehender Dienste exportieren

Über Scripte oder Webseiten gibt es bereits die Möglickeit, Grafiken in verschiedenen Auflösung herausrechnen zu lassen. Einen webbasierten Dienst bietet beispielweise der Generic Icon Generator. Man lädt eine SVG-Grafik hoch und kann sich ein ZIP-Archiv herunterladen, das die Grafiken in den verschiedenen Auflösungen enthält. Wir haben den Icon Generator getestet. Allerdings sind wir mit dem Ergebnis nicht ganz zufrieden. Bei den verschiedenen Endgrafiken treten unschöne Interpolationsfehler an den Rändern auf. Das zeigt sich vor allem bei Geräten mit hochauflösenden Displays. Dort kann es den Effekt haben, dass zum Beispiel Icons unscharf aussehen, obwohl sie in der richtigen Auflösung vorhanden sind. Ein weitere negativer Punkt ist das Fehlen einer Auflösung (xxxhdpi).

Beispielgrafik mit Interplationsfehler an den Rändern 

Für Photoshop gibt es ebenfalls verschiedene Wege, Grafiken zu exportieren. Entweder man arbeitet mit Slices oder seit Photoshop CC hat man auch die Möglichkeit, diese über die "Elemente extrahieren"-Funktion automatisch herauszurechnen. Das ist prima, wenn man Icons und Grafiken direkt in Photoshop erstellt. Allerdings ist unser Tool der Wahl Adobe Illustrator und deshalb stellte sich uns die Frage: Wie können wir effektiver Grafiken aus Illustrator exportieren?

Jetzt kommt Magic ins Spiel: AI-Assets für Illustrator

Als Benny bei Katharine bei einem interdisziplinären Projekt zusammen saßen, kamen sie zum Schluss "Das muss doch einfacher geh'n". Bis dato hatten wir den Workaround Illustrator - Photoshop - Illustrator .... Generell ein umständlicher Workflow. Und wie gesagt, brauchen wir eine Lösung, die ein qualitativ hochwertiges Ergebnis liefert.

Beispielgrafik ohne Interpolationsfehler

 

Benny tauschte sich daraufhin mit Roli aus und implementierte kurzer Hand ein Skript für Illustrator. Es gab ein paar Praxistests bei uns im User-Experience-Design-Team mit anschließender Feedbackschleife. Die Zitate von Katharine und Roman sprechen Bände:

Das Illustrator Skript ist wirklich der HAMMER, da es einem die lästige Arbeit abnimmt, Grafiken in allen Auflösungen manuell abzuspeichern: Einfach Speicherort auswählen, Dateinamen eingeben und schon purzeln die Grafiken in den gewünschten Formaten raus. (Katharine)

 Manchmal können ein paar Zeilen Code viel Arbeit ersparen! (Roman)

Deshalb wollen wir es euch nicht vorenthalten. Auf GitHub https://github.com/inserteffect/ai-assets steht es zum Download bereit, inklusive Bedienungsanleitung.

 

Viel Spaß damit!

Nina

Freigegeben in Blog
Montag, 09 Februar 2015 16:01

Icondesign - Icon ist nicht gleich Icon

Gleich mal zu Beginn des Posts eine Frage: Für was könnten folgende vier Icons stehen?

icons 

Und im Kontext der mobilen Webseite des Videoportals Vimeo, der Gmail-App und der Fotoalbum-App?

Icons im App-Kontext

Bei Vimeo steht das Herz-Icon für “Like” und das Papierflieger-Icon für “Share”. In der Gmail-App hingegen wird das Papierfliger-Icon für “Senden” verwendet. Die Fotoalbum-App benutzt das ShareThis-Icon und ein Stern für Favoriten. Nicht selten sieht man allerdings das Herz auch als Symbol für Favoriten. Welches Icon soll man nun für welchen Begriff verwenden?

Gehen wir nochmal einen Schritt zurück. Ein Icon soll laut Definition “eine Information durch vereinfachte grafische Darstellung vermitteln”. Ein Herz, ein Papierflieger, ein Stern sind eine einfache Darstellung. Beim ShareThis-Icon ist es schon etwas schwieriger zu beschreiben, was es ausdrücken soll. Allerdings stellt man fest, dass die Icons, trotz anscheinend einfacher Darstellung, häufig unterschiedlich verwendet werden. Wie schafft man es nun, für den Nutzer Icons zu gestalten, die die Benutzbarkeit einer Anwendung unterstützen?

Tipps aus der Praxis

In einem vergangenen Projekt hatten wir die Aufgabe die Dashboard-Icons der bauen.de Android-App neu zu gestalten. Es galt jeweils ein Icon für folgende Begriffe zu gestalten:

  • Grundstücke

Funktion: Grundstücke suchen

  • Typenhäuser

Funktion: Typenhäuser suchen

  • Merkzettel

Funktion: Merkzettel anzeigen

  • Ratgeber

Funktion: Ratgeber für Hausbau, Ausbau & Renovierung, Neue Energien & Umwelt, … anzeigen

  • Musterhäuser

Funktion: Musterhäuser in einer Kartenansicht anzeigen

  • Hauskataloge

Funktion: Hauskataloge anzeigen

  • Prospekte

Funktion: Prospekte anzeigen

Hinzu kam, dass die alten Icons durch die neuen ersetzt werden sollen. Das heißt, es gibt Nutzer, die die Iconsprache bereits gelernt hatten.

Schritt 1 - Freie Recherche

In einer ersten Phase haben wir erstmal gängige Muster für Icons recherchiert. Also Haus, Lupe, Karten, usw. Ziel war es, für den Nutzer bekannte Icons zu finden. Außerdem gemeinsam mit dem Kunden entschieden, welchen Style die Icons haben sollen. Das heißt, sind die Icons zum Beispiel monochrom oder mehrfarbig, 2D oder 3D. Gepaart wurde diese Phase mit den Google-Vorgaben zu Icondesign. Entscheidend war noch, dass die Icons auf dem Dashboard nicht selbsterklärend sein müssen, da dieses aus Icon und Text besteht.

Schritt 2 - Scribblen

Nach der Recherchephase entschieden wir uns für mehrfarbige Icons in 2D. Die Icons sollten sowohl aus einer Aktion und der dazugehörigen Information bestehen. Wir suchten also Icons zum Beispiel für “Grundstück” und “suchen”. In einer gemeinsamen Scribble-Session entstanden dann erste Entwürfe. In der Phase war uns wichtig, dass wir erstmal nur die Iconsprache und nicht das Design diskutieren. Für die Trennung sprach, dass es oft schwierig ist, den Fokus auf die Iconsprache zu legen, sobald die Gestaltung mit ins Spiel kommt.

scribble icons

Schritt 3 - Iconsprache verfeinern

Die Entwürfe dienten als sehr gute Grundlage, um Nutzer- und Kundenfeedback einfließen zu lassen. Das heißt, wir haben diese unseren Kolleginnen und Kollegen gezeigt und gefragt, was sie darunter verstehen. Nachdem wir dieses Feedback eingearbeitet hatten, gingen die Entwürfe an den Kunden. Dieser gab nochmals Feedback aus Kundensicht:

Es ist gut, dass das Icon unförmig ist und nicht mehr wie ein DIN A4 Papier aussieht. Allerdings hat das Icon für uns zu sehr Ähnlichkeit zu einem Haus- oder Wohnungsgrundriss.

Wir würden uns wünschen, wenn das abgebildete Grundstück im Verhältnis zu weiteren Grundstücks-Parzellen stehen würde, eventuell sogar mit kleinen Details wie eingezeichneten Wegen und Bäumen etc

 

Das „i“ in dem Buchrücken ist ohne die dazu gelieferte Erklärung leider nicht bei jedem gleich ersichtlich gewesen. Eventuell wäre es besser, wenn man das „i“ als extra Icon darüberlegt (wie bei der Lupe). Alternative zum „i“ wäre z.B. auch das „?“.

Dieses nahmen wir auf und setzen es direkt beim Reinzeichnen in Illustrator um.

Schritt 4 - Reinzeichnen

Illustrator ist unser Tool der Wahl, wenn es um Icons geht. Im mobilen Umfeld benötigt man Grafiken für die verschiedenen Auflösungen. Bei iOS ist das eine einfache, doppelte und seit dem iPhone 6 Plus auch eine dreifache Auflösung. Für Android stellt man Grafiken in mdpi, hdpi, xhdpi und xxhdpi bereit. Deshalb haben wir diese als Vektorgrafik angelegt. Ein weiterer wichtiger Punkt ist der Icon-Status, also das Touch-Feedback. Tappt der Nutzer mit dem Finger auf das Display, kann man ihm eine Rückmeldung geben, dass er ein Element ausgewählt hat. Dies erfolgt durch das Anzeigen einer anderen Grafik. 

Touch Feedback

Fazit

Das passende Icon zu finden, ist nicht immer einfach. Vor allem, wenn das Icon selbsterklärend sein muss. Bei Apps und Webseiten für mobile Endgeräte haben Icons den Vorteil, dass man durch deren Verwendung Platz sparen kann. Wichtig ist für uns, dass man zwischen Scribble und Design trennt, um die jeweils richtigen Fragen, wie "Erkennt der Nutzer den Unterschied zwischen Musterhaus-Suche und Grundstück-Suche?" oder "Passen die Icons in die Corporate Identity des Kundes?" beantwortet zu bekommen. Für uns war die enge und konstruktive Zusammenarbeit mit dem Kunden sehr hilfreich, um zum einen an dessen Wissen über die Zielgruppe und zum anderen an den Funktionen hinter den Icons teilzuhaben.

Zum Abschluss noch ein Vorher-Nachher Vergleich des bauen.de Dashboards.

Nina

Vorher-Nachher-Vergleich

Freigegeben in Blog

Nimmt man die Überschrift des Artikels her, so kann man die Aussage auf viele Bereiche der mobilen Welt anwenden: die Technik, die Geräte, die Nutzer selbst - und eben auch das User Interface mobiler Webseiten. Wir wollen einen Blick zurück wagen und zeigen, was sich geändert hat oder eben auch nicht. Wie weit zurück? Also nicht bis ins Jahr 1910, als die erste Idee eines tragbaren Telefons entstand. Sondern bis ins Jahr 2007. Vor fast genau sieben Jahren entstand die erste Version der mobilen Webseite von speisekarte.de. Anhand derer lässt sich schön veranschaulichen, was sich im User Interface Design mobiler Webseiten alles getan hat.

Unser Testexemplar - die mobile Webseite m.speisekarte.de

Gehen wir also auf die Reise und beginnen diese gleich mit einer Grafik.

user interface 2007

Die Grafik zeigt von links nach rechts die Startseite, das Suchergebnis und die Detailseite.

Was ist im Jahr 2007 wichtig?

  • Wir designen und konzepten für Feature Phones, Geräte mit einer Hardware Tastatur. Am besten sieht man das an den accesskeys, also dem [1] und [2] vor den Navigationspunkten (siehe Grafik unten).
  • Außerdem war die Seite sehr reduziert, was Grafiken und Elemente angeht, um die Ladezeit zu verringern. Hat man damals die Webseite, zum Beispiel im Browser des Motorola Razr V3 aufgerufen, war die Navigation folgende:

motorola razr

  • Der sichtbare Bereich ist bei den kleinen Displays das Kernstück der mobilen Webseite. Das heißt Inhalte müssen so gestaltet werden, dass sie auch auf Sony Ericsson W810i mit einer Auflösung von 176x220px sichtbar sind.
  • Das Layout ist so gestaltet, dass der Inhalt vertikal dargestellt wird. Es ist ein absolutes No-Go, dass der Nutzer horizontal scrollen muss. Die Gefahr, dass man sich in den Tiefen der Webseite verliert, ist einfach zu groß. Auch wenn es auf den ersten Blick nicht offensichtlich ist, aber der Grund dafür ist das Gesetz der Nähe, um eine bessere Usability zu bekommen.
  • In Bunt und Farbe: Dem Einsatz von Farbe spricht nichts entgegen. Die meisten Geräte besitzen bereits ein Farbdisplay. Beispielsweise stellt das damals weitverbreitete Sony Ericsson K800i ungefähr 250.000 Farben dar (im Vergleich dazu heute das iPhone 5S 16,7 Millionen). Was heißt das nun für das User Interface Design? Flächen zu designen ist kein Problem, allerdings wird es bei Verläufen schwierig, denn diese sehen auf den Displays flächig und stufig aus.

Touchscreens auf dem Vormasch - das Jahr 2009

Bevor wir uns auf die Designprinzipien um das Jahr 2009 stürzen, hier eine Grafik des User Interface Designs von speisekarte.de – damals:

userinterface 2009

Was fällt auf?

  • Der Wurst-Finger-Effekt gewinnt an Bedeutung. Buttons, Links - eben alles, was antappbar ist, muss mit dem Finger gut auswählbar sein. Dazu tragen beispielsweise die Guidelines von Apple bei, in denen steht, dass man von mindestens von 44x44px ausgehen soll. Dort wird explizit auch auf mobile Webseiten eingegangen. 
  • Die mobilen Browser legen technisch zu: immer mehr setzen auf WebKit als HTML Rendering-Engine. Von nun an kann man auch mit abgerundeten Ecken, Boxen und weiteren Gestaltungselementen arbeiten, die direkt im CSS umgesetzt werden. Somit bekommen Designerinnen und Designer mehr Gestaltungsspielraum.
  • Es wird plastischer und Verläufe kommen zum Einsatz (vgl. Buttondarstellung im mobilen Safari).
  • Mobile Webseiten nähern sich an die Oberflächen von Apps an. Vor allem wird oft das native Verhalten von iOS-Apps kopiert, indem feste Header mit einem zurück-Button eingebunden werden oder auch die Hochglanzverläufe, welche auffallend oft auf mobilen Webseiten anzutreffen sind.
  • Ein weiterer Punkt, der durch Apple an Wichtigkeit gewinnt: Usability von mobilen Webseiten ist wichtiger denn je. Die Nielsen Norman Group veröffentlicht einen Bericht mit 85 Design Guidelines für mobile Webseiten.

Nächster Halt: das Jahr 2014

Warum plötzlich ein Schritt von 5 Jahren? Die Entwicklung der letzten Jahre lässt sich nicht mehr so gut in eindeutige Meilensteine für das User Interface einteilen. Auf der Reise bis in die Gegenwart haben wir einen Zwischenstopp an folgenden, ausgewählten Stationen gemacht:

  • Responsive Design: Die Webseite für Smartphones wird nicht mehr als ein separater Bereich der Desktop-Seite gesehen oder gar als eine Kopie von nativen Apps. Vielmehr wird plattformunabhängig gestaltet und konzeptet. Das heißt, wir sehen immer häufiger das Hamburger Icon auf mobilen Webseiten. Wer mehr zur Geschichte des Hambuger Icons erfahren möchte und sich auf diese Zeitreise begibt, dem sei "Who Designed the Hamburger Icon" empfohlen.
  • Designprinzipien, die allgemein gelten, werden auch im mobilen Web angewendet. Aktuell sieht man viel den Parallaxe-Effekt. Auch auf dem Smartphone funktioniert das Prinzip, wie zum Beispiel die Seite parallax.js zeigt.
  • Gesten kommen zum Einsatz, um eine benutzerfreundliche User Experience zu erlangen. Die Benutzer erwarten, dass man zum Beispiel wischen oder auf- und zuziehen kann.
  • Es wird flach. Android 4.0 und iOS 7 machen es vor - das mobile Web geht mit. Flat Design ist in vollem Gange. Klickt man durch das Sammelsurium an mobilen Webseiten auf http://www.mobileawesomeness.com/listings/gallery/24/1/ sticht dieser Trend eindeutig ins Auge. Gut zu sehen am grün farbenen Button auf m.speisekarte.de.
  • Design im Browser: Der Workflow zum Erstellen von mobilen Webseiten hat sich geändert. Ein cross-funktionales Team aus UX Designern und Entwicklern erstellt das Frontend. Der Vorteil: verschiedene Perspektiven und das Optimum aus beiden Welten fließt ein. Nach diesem Prinzip begann übrigens auch Ende 2012 die Überarbeitung von m.speisekarte.de.

userinterface 2013

Screenshot der aktuellen Version von speisekarte.de für Smartphones. Im mittleren Screenshot sind einige Listeneinträge gelöscht, da er sonst zu lange wird.

Was bleibt? Was wird kommen?

Wir können definitiv sagen, dass wir nach wie vor Punkte aus dem Jahr 2007 auch im Jahr 2014 berücksichtigen, wenn wir Webseiten für mobile Endgeräte gestalten und konzepten. Dazu gehört zum Beispiel, dass der sichtbare Bereich immer noch extrem wichtig ist. Allerdings haben wir neue Gestaltungsmöglichkeiten, um diesen noch attraktiver zu machen und besser zu nutzen. Webseiten werden auch 2014 so gelayoutet, dass sie vertikal scrollbar sind. Aber wer weiß, vielleicht wird sich das in Zukunft ändern? Eine Auswahl weiterer (Future) Buzzwords aus dem User Experience Bereich sind:

Gibt es weitere Begriffe, die eurer Meinung nach unbedingt dazu gehören? Noch mehr Future Buzzwords und vor allem spannenden Vorträge erwarten uns auf der diesjährigen Mobile First Night, die am 22. Oktober im Rahmen der Web Week Nürnberg stattfinden wird.

Nina

Freigegeben in Blog
Donnerstag, 03 April 2014 00:00

Designs für Android erstellen

Christian hatte letzte Woche schon den Blogpost "Pixel ist nicht gleich Pixel" geschrieben, der sich mit Bildschirmauflösungen und Pixeldichten auf unterschiedlichen Geräten beschäftigt. Ich möchte heute nochmals auf diese Thematik eingehen. Designen für Android kann schwierig sein, denn Modelle gibt es in einer unzähligen Vielfalt an Bildschirmgrößen und -auflösungen. Wir helfen durch den Android-Design-Guidelines-Dschungel.

Android Devices

Eine kleine Auswahl unserer Android-Testgeräte.

Sehr oft möchte der Kunde ein Design sehen, bevor die App in die Entwicklung geht. Verständlich. Beim Design für eine iPhone-App legen wir normalerweise fest, ob für iPhone 4 oder 5 entworfen wird. Bei der iPhone-4-Variante dann noch, ob Retina oder nicht, oder beides. Mehr Größen gibt es in der iPhone-Welt nicht. Im Moment zumindest. Wie sieht es jedoch bei Android aus? Modelle und Auflösungen gibt es in einer unzähligen Vielfalt und Kombination. In welcher Auflösung also designen, damit der Kunde ein realistisches Bild hat, wie Größenverhältnisse und Schriften aussehen? Sinnvoll ist es, sich zunächst über die ganzen Begrifflichkeiten einen Überblick zu verschaffen und zu verstehen, was diese bedeuten.

Bildschirmauflösung (resolution) und Pixeldichte (density)

Android-Geräte gibt es in einer unüberschaubaren Anzahl an Bildschirmgrößen. Um das wenigstens ein bisschen zu vereinfachen, teilt Android die Bildschirmgrößen in vier unterschiedliche Einheiten auf:

  • xlarge mit einer Mindestauflösung von 960 dp x 720 dp
  • large mit einer Mindestauflösung von 640 dp x 480 dp
  • normal mit einer Mindestauflösung von 470 dp x 320 dp
  • small mit einer Mindestauflösung von 426 dp x 320 dp

Mit der Bildschirmauflösung ist es unter Android aber nicht getan. Es gibt noch die sehr wichtige Einheit "Density" oder Pixeldichte. Was ist der Unterschied? Im Android-Developer-Guide wird es folgendermaßen erklärt:

Auflösung (resolution) = die Anzahl der physikalischen Pixel auf einem Bildschirm.

Pixeldichte (density) = die Anzahl der Pixel innerhalb eines physikalischen Bereichs auf dem Bildschirm. Diese werden normalerweise DPI (dots per inch) genannt. Bei einem "low-density"-Bildschirm befinden sich auf einem bestimmten physikalischen Bereich (z. B. 1 cm²) weniger Pixel als auf einem "high-density"-Bildschirm. Die Anzeige wirkt also auf einem "high-density"-Bildschirm schärfer, weil die einzelnen Pixel kleiner sind und irgendwann vom menschlichen Auge nicht mehr als solche wahrgenommen werden. Apple bewirbt solche Bildschirme sehr medienwirksam als "Retina-Display".

Auch hier werden die Pixeldichten von Android in Einheiten heruntergebrochen, um es uns ein (ganz, ganz, ganz klein) wenig zu erleichtern. Im Moment sind am verbreitesten:

  • LDPI
  • MDPI (160 dpi) - baseline
  • HDPI (240 dpi)
  • XHDPI (320 dpi)
  • XXHDPI (480 dpi)
  • XXXHDPI (640 dpi)

Verschiedene Pixeldichten

Verschiedene Pixeldichten, Ausschnitt von ca. 2 cm². Links HDPI-Display, Rechts MDPI-Display.

Um noch mehr zu verwirren: Dichte-unabhängige Pixel dp (density independent pixel)

Es gibt noch eine dritte Einheit: Dichte-unabhängigen Pixel. Diese sind eine virtuelle Einheit, die verwendet werden sollte, um UI-Layouts (z. B. Dimensionen oder Positionen) unabhängig von der Pixeldichte zu definieren. Styleguides und Vorgaben für Android-Entwickler sollten also immer in dp definiert werden.

Ein Dichte-unabhängiger Pixel ist die Entsprechung eines physikalischen Pixels auf einem 160 dpi (MDPI) Bildschirm. MDPI beschreibt die Basisdichte (baseline density) für einen Bildschirm in "medium-density". Alle Angaben im Android-Design-Styleguide sind in dp angegeben.

Und was heißt das jetzt alles für mich als Designer?

Ja, zugegebenermaßen ist das alles ziemlich verwirrend. Wie fangen wir jetzt also an? Android selbst schlägt als eine Möglichkeit vor, mit dem Basis-Standard zu arbeiten. Das heißt also in einer normalen Bildschirmgröße (mind. 470 dp x 320 dp) und einer MDPI (160 dpi) Pixeldichte. Eine andere Möglichkeit ist, für das Gerät mit dem größten Bildschirm zu designen und dann herunterzuskalieren, um zu sehen, ob das Design auch auf kleineren Bildschirmen funktioniert.

Die Crux an der ganzen Sache – wenn der Kunde das Design wirklich genau beurteilen will (z. B. Schriftgrößen), muss er sich dieses auf einem Gerät ansehen, für das die Datei erstellt wurde. Um das Ganze noch viel verwirrender zu machen: Es ist nicht so, dass ein Gerät mit "normaler" Bildschirmauflösung auch unbedingt eine MDPI Pixeldichte hat. Eine kleine Auflistung, welche Geräte, welche Pixeldichte haben, wurde auf der Seite Screen Sizes and Densities im Android Developer Guide erstellt. An dieser Liste erkennen wir schon, dass heutzutage fast keine Geräte mehr eine geringere Pixeldichte als MDPI haben (jedenfalls hier in Deutschland, in Ländern in denen ältere Geräte verwendet werden, mag das wieder anders aussehen).

Und nun ein konkretes Beispiel

Wenn wir ein Design in einem Grafikprogramm erstellen wollen, haben wir dort als Maßeinheit nur Pixel. Wir müssen also dp in Pixel umrechnen. Da MDPI unsere Basis ist, entspricht ein dp einem px. Die Umrechnung in andere Pixeldichten wird im Android-Design-Styleguide erklärt. Als kleine Hilfe gibt es aber auch online einen Umrechner von dp in px.

Nun ist es noch sinnvoll zu überlegen, für welche Geräte man das Design erstellen möchte. Hier hat sich bewährt, mit dem Kunden abzustimmen, welche Testgeräte dieser zur Verfügung hat. Bei unserem letzten Projekt hatte der Kunde ein Samsung Galaxy SIII Mini als Testgerät mit einer Bildschirmauflösung von 480x800 Pixel und einer HDPI Pixeldichte. Aus diesem Grund haben wir die Datei in Photoshop mit 480 Pixeln Breite angelegt. Da wir hier mit einer HDPI Pixeldichte arbeiten, müssen wir Größen umrechnen. Wie bereits erwähnt sind im Android-Design-Styleguide die Maße in MDPI angegeben. Beispielsweise ist dort die Höhe der Actionbar mit 48 angegeben. Diesen Wert muss man nun in HDPI umrechnen. Das heißt die Basis-Maße (MDPI) x 1,5 nehmen, hier im Beispiel also 48 x 1,5 = 72. In Photoshop wird deshalb die Actionbar mit einer Höhe von 72px angelegt.

Dieses Design kann auf einem Samsung Galaxy SIII Mini, Samsung Nexus S oder HTC Desire angesehen werden. Das Design wird dann nicht verzerrt dargestellt und alle Schriftgrößen und Proportionen können richtig beurteilt werden.

Und wenn der Kunde nun sehen will, wie es auf seinem brandneuen Android-Gerät mit xxxhdpi-Pixeldichte aussieht? Die Antwort ist tatsächlich, dass dann eine neue Photoshop-Datei in der entsprechenden Auflösung erstellt werden muss. 

Und eure Erfahrungen?

Wir sind natürlich neugierig, was ihr für Erfahrungen gemacht habt und wie ihr vorgeht, wenn ihr Designs für Android-Apps erstellt. Oder habt ihr weitere Fragen? Wir freuen uns, wenn ihr eure Erfahrungen hier als Kommentar hinterlasst. :-)

 

Susanne

Freigegeben in Blog

Viele Apps sind mittlerweile auf eine gute Usability bedacht. Es gibt Bücher, Experten oder ganze Geschäftszweige, die sich mit dem Thema beschäftigen. Das Programm muss intuitiv zu bedienen sein - am besten ohne Einarbeitungszeit. Dies erreicht man durch eine selbsterklärende Benutzeroberfläche. Doch was ist in welchem Rahmen für jemand bestimmtes selbsterklärend?

Freigegeben in Blog
Donnerstag, 27 Oktober 2011 17:19

E-Book: Mobile Design & Usability

Mobile Design & Usability – warum soll man sich darüber überhaupt Gedanken machen?

In unseren Workshops, Projekten und bei unzähligen Kundengesprächen werden uns immer wieder Fragen rund um das Thema Design von Apps gestellt. Fragen, die uns zu diesem E-Book insprierten.

Das Ergebnis ist eine komprimierte Einführung in das Thema “Mobile Design & Usability”. Es gibt einen Überblick über die Design-Philosophie sowie die wichtigsten User-Interface-Elemente von Android- und iPhone-Apps und geht außerdem auf die Grundprinzipien von User-Interface-Gestaltung ein. Um die Herangehensweise noch besser zu verdeutlichen, haben wir uns eine fiktive Android- und iPhone-App ausgedacht und sie designt: Lokuskop, eine App, mit der nach öffentlichen Toiletten im Umkreis gesucht werden kann.

Wir würden uns freuen, wenn Sie es auch Ihren Freunden, Kollegen, Bekannten und für wen es auch sonst interessant sein könnte, weiterempfehlen. Natürlich sind Feedback, Anregungen für zukünftige Updates sowie Lob jederzeit willkommen.

Think of design as communication between you and the user.
Jim Palmer auf der Google I/O 2010

E-Book herunterladen
Version 1.1 (PDF, 4,2 MB)

Freigegeben in Downloads