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

Wer kennt es noch? Das Glücksrad? Lief früher auf Sat 1. Die Kandidaten haben das Glücksrad mit verschiedenen Geldsummen gedreht und konnten dann einen Konsonanten wählen. Abhängig davon, ob dieser in dem gesuchten Begriff vorkam, wurde dann die Geldsumme auf ihrem Konto gutgeschrieben. Vokale wurden meist mit "Ich kaufe ein E" gekauft. Wer das Rästel lösen konnte, konnte danach shoppen gehen.

 

Weshalb schafft es jetzt das Glücksrad auf unser Blog? Wir haben vor einiger Zeit die Buy-A-Feature-Methode erfolgreich in einem Kunden-Workshop durchgeführt. Vom Prinzip her ähnlich, allerdings kann man sich keine Waschmaschinen oder Staubsauger kaufen, sondern Features.

Um was geht's?

Die Buy-A-Feature-Methode hat das Ziel, Features zu priorisieren. Außerdem soll sie sichtbar machen, bei welchen Features es sich um "Monsterfeatures" aus Auftraggeber-, Entwicklung- oder Usabilitysicht handelt. Ein "Monsterfeature" kann für hohen Umsatz sorgen oder die Benutzbarkeit des Produkts erhöhen. Gleichzeitig kann es in der Umsetzung sehr aufwändig und somit teuer sein.

Wie funktioniert das?

Bei uns kam die Buy-A-Feature-Methode in einem Workshop mit FEGA & Schmitt zum Einsatz. Dieser fand nach einem ersten Kennenlernen statt und hatte unter anderem das Ziel, den Funktionsumfang der iOS- und Android-Apps festzulegen und zu priorisieren, da der Zeitplan eng war. Teilgenommen haben Stefanie Wegmann von FEGA & Schmitt, Caro aus dem Vertrieb, Roli und Martin stellvertretend für die Entwicklung und ich, verantwortlich für Usability, Konzept und Design. Zunächst erklärte Caro, die Moderatorin, die Spielregeln:

- Die Featureliste wird auf den Tisch gelegt und ggf. noch erweitert / erklärt.
- Jede/r bekommt Geld, mit dem Features gekauft werden.
- Es gibt keine Währung.
- Der Preis kann auf Geschäftswert / Entwicklungsaufwand / Nutzerwert etc. basieren.
- Jede/r hat 10 Minuten Zeit, die Features zu kaufen.
- Nach den 10 Minuten erklärt jede/r, weshalb und warum er/sie das Feature für den genannten Betrag kaufen würde.

Danach begann Stefanie, die Kundin, Features zu kaufen. Sie hatte dafür folgende Scheine zur Verfügung:

- 6 x Schein 1

- 3 x Schein 5

- 3 x Schein 10

- 2 x Schein 50

- 1 x Schein 500

Bei der Auswahl der Scheine haben wir darauf geachtet, dass man sich auf alle Fälle entscheiden muss, welches Feature man gerne hätte. Während des Verteilens hat sie bereits erklärt, warum sie sich für bzw. gegen ein Feature entschieden hat.

Den gleichen Durchlauf haben dann Roli und Martin gemacht, da es wichtig ist, Team-Mitglieder zu Wort kommenzulassen. Während sie ihre Scheine verteilt haben, konnten sie bereits kurz anschneiden, weshalb zum Beispiel der "Barcodescanner" oder "Filiale in der Nähe anzeigen" teuer ist, dagegen "Warenkorb speichern" eher günstig.

Last, but not least habe ich dann noch die Features aus Usability-Sicht gekauft. Den Barcodescanner habe ich mit dem 500-Schein gekauft, weil bekanntermaßen Texteingabe auf mobilen Endgeräten Zeit rauben kann und oft auch frustrierend ist.

Stefanies Fazit

"Es war eine spannende neue Erfahrung und besonders hilfreich, da man direkt vor Augen hatte wie unterschiedlich die Features von den verschiedenen Bereichen bewertet werden. Besonders wertvoll waren dabei auch die Erläuterung zu den Gründen für die Bewertung."

Unser Fazit

Erstmal Danke an Stefanie, dass sie bereit war, diese spielerische Methode zusammen mit uns durchzuführen.

Unser Eindruck von der Buy-A-Feature-Methode war sehr positiv. Mit einfachen Mitteln kann man den Kunden dazu anregen, sich Gedanken zu "Was will ich auf jeden Fall in der App haben" zu machen . Aber auch das Entwickler-Feedback ist sehr wertvoll, damit der Kunde versteht, weshalb die Umsetzung eines Features entsprechend teuer sein kann. Um letztendlich den Kreis zu schließen und auch die Nutzersicht zu berücksichtigen, sollte immer auch ein Usability-Experte an dem Workshop teilnehmen. Es ist auch möglich, das Ganze auszuweiten und mit realen Nutzern die Buy-A-Feature-Methode anzuwenden.

Zum Schluss muss ich einfach auch noch sagen, dass so ein Workshop mit spielerischen Elementen Spaß macht!

Übrigens die Apps sind mitterweile umgesetzt und in den jeweiligen Stores zu finden:

Link zur Android-App im Google Play Store: https://play.google.com/store/apps/details?id=de.fega.shop

Link zur iOS-App in Apples App Store: https://itunes.apple.com/de/app/fega-schmitt/id915746911?mt=8

Noch eine kleine Anmerkung dazu: Zielgruppe der App sind bereits registrierte Fega-&-Schmitt-Kunden/Händler.

Nina

Freigegeben in Blog
Mittwoch, 26 März 2014 08:00

Pixel ist nicht gleich Pixel

Wenn über Pixel gesprochen wird, kann es bei uns zwischen Grafikern und Entwicklern, aber auch mit Kunden, zu Verwirrungen kommen. Nämlich dann, wenn Grafiken auf unterschiedlichen Smartphones und Tablets dargestellt werden sollen.

espresso kaffeebohnen 720x160

Im Werbeslogan eines bekannten deutschen Kaffeerösters heißt es: "Kaffee ist nicht gleich Kaffee". Über Sinn oder Unsinn dieser Aussage kann man sich streiten – bei Pixeln trifft das aber unter Umständen zu.

Warum ist das so?

Es wird viel von Retina-Displays, Pixeldichte und dpi geredet, aber was genau verbirgt sich dahinter, und warum ist es bei der Erstellung von Grafiken für Apps und Webseiten so wichtig?

Aufgekommen ist alles mit dem iPhone 4 mit Retina-Display. Grafiken in Apps und auf Webseiten wurden zwar wie bisher dargestellt, man kann aber bei genauerem Hinsehen eine leichte Unschärfe oder Verpixelung wahrnehmen. Betrachtet man die Struktur dieses Displays in vereinfachter Weise genauer, erkennt man auch, warum.

Pixeldichte

Nicht von Apple erfunden, aber populär angewendet, wurde bei diesem Display die Anzahl der Pixel vervierfacht, gleichzeitig der Abstand zwischen den Pixeln verringert. Das ergibt von außen eine gleiche physikalische Größe wie beim "Standard-Display", es können aber auf gleicher Fläche viermal so viele Pixel angezeigt werden.

Man spricht hier von Pixeldichte. Die Angabe erfolgt dabei in dpi (dots per inch), also der Anzahl der Pixel pro Zoll.

Nimmt man eine Grafik und ordnet alle Pixel 1:1 den Displays zu, ergibt sich ein Unterschied in der Größendarstellung. Um diesen Größenunterschied auszugleichen, werden die Bilder in Standardauflösung auf die native Auflösung des Displays hochskaliert. Diese Aufgabe wird automatisch vom Betriebssystem übernommen, dadurch ergibt sich aber unter Umständen der genannte Pixel- und Unschärfeeffekt.

Verschiedene Pixeldichten

Links: Display mit hoher Pixeldichte – Rechts: Display mit geringer Pixeldichte

Natürlich gibt es mittlerweile außer dem iPhone noch andere Geräte mit hochauflösenden Displays. Und das macht es so komplex, da wir uns beispielsweise bei Android-Geräten im Bereich von 120 dpi bis 640 dpi bewegen.

Wie geht man damit um?

Grundsätzlich ist diese Tatsache erstmal nicht schlimm, und es muss auch nichts getan werden. Vielen Nutzern fällt es meist gar nicht auf, ob die Grafiken in einer höheren Auflösung vorliegen. Möchte man aber die Vorteile dieser Displays nutzen, muss man sich vor der Erstellung fragen, auf welchem Gerät diese angezeigt werden. Susanne wird darauf in einem folgenden Artikel näher eingehen.

Bis dahin hinterlasst gerne eure Erfahrungen und Fragen zu Pixeldichte & Co in den Kommentaren.

Christian

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

Wir haben uns die Frage gestellt: Ist es im mobilen Kontext sinnvoll, verstärkt auf Gesten zu setzen? Wie so häufig kann man auch hier sagen: "Es kommt darauf an ..."

In der Konzeption von mobilen Applikationen gibt es regelmäßig Trends, die dann in vielen Apps umgesetzt werden. 2010 war das beispielsweise das Dashboard. Zu sehen unter anderem bei Facebook, Qype oder Twitter.

Facebook iPhone App Screenshot des Dashboard aus dem Jahr 2010    Qype iPhone App Screenshot des Dashboard aus dem Jahr 2010    Twitter Android App Screenshot des Dashboard aus dem Jahr 2010

Quelle: Facebook-Screenshot: http://bit.ly/1arTeeH

Quelle: Qype-Screenshot: http://bit.ly/MsIHVs

Quelle: Twitter-Screenshot: http://bit.ly/1btBr54

Gesten auf dem Vormarsch

Im Jahr 2014 geht der Trend hin zum vermehrten Einsatz von Gesten. Das heißt, Aktionen werden durch Gesten ausgeführt, wie zum Beispiel das Beenden von Apps durch Wischen von unten nach oben (iOS) oder rechts nach links (Android). Die clear-App war ein Vorreiter, was die App-Bedienung ausschließlich per Geste angeht.

Luke Wroblewski hat auf seiner Seite einen tollen Überblick mit den gängigen Gesten: http://www.lukew.com/ff/entry.asp?1071. Ausgedruckt eignen sie sich auch hervorragend zum Erweitern von Scribbles oder Wireframes. 

Seit iOS 7 wird auch im mobilen Safari verstärkt auf Gestensteuerung gesetzt. Löschen von Tabs durch das Wischen von rechts nach links, oder zurück zur vorigen Seiten navigieren durch das Wischen von links nach rechts. Wichtig ist dabei, dass die Geste bereits außerhalb der Displays beginnt. Gleiches Verhalten wird unter Android für das Anzeigen der side-navigation, auch off-canvas-navigation genannt, verwendet.

Swipe Geste zum Löschen von Tabs im mobilen Safari      Side Navigation in der Podcast App für Android

 

Ist es sinnvoll, verstärkt auf Gesten zu setzen?

Generell empfiehlt es sich, mit Gesten zu arbeiten, weil dadurch die Bedienung einer App vereinfacht wird. Allerdings sollte man darauf achten, dass es zu keiner "Gestenkollision" kommt. Wenn zum Beispiel in einer App weitere User-Interface-Elemente, etwa ein Karussell, verwendet werden, ist Vorsicht geboten. Wir haben zwei Videos aufgenommen, die verdeutlichen, was wir unter einer Gestenkollision verstehen.

 

Beispiel 1 - Safari Swipe vs. Karussell Swipe

{youtube}T8agO8Oslj4{/youtube}

 

Beispiel 2 - Side Navigation Swipe vs. Listen Swipe

 

{youtube}nodmCea3dzI{/youtube}

 

Wie viele Gesten sind gut? 

Es kommt darauf an. Wichtig ist darauf zu achten, dass sich die Gesten wie im obigen Beispiel nicht in die Quere kommen. Das heißt sich öfter mal die Frage stellen, wie viele Gesten habe ich im Einsatz? Welche Gesten nutzt der User häufig? Erleichtern diese Gesten die Bedienung in der App? Wenn man darauf achtet, Gesten gezielt einzusetzen und dabei auf bekannte Muster zurückgreift, erreicht man eine einfache Benutzerführung und ist trotzdem noch voll im Trend.

Nachtrag

Anscheinend haben nicht nur wir uns die Frage gestellt, sondern mit Erscheinen der Facebook Paper App in den USA, erregt das Thema auch die LeserInnen des Blogs von Scott Hurff.

Freigegeben in Blog
Sonntag, 16 Dezember 2012 14:16

heise online - iPhone, iPad, Android App

heise online zählt zu den erfolgreichsten deutschsprachigen Nachrichten-Portalen. Konzept, Design und Entwicklung der Android- und iOS-Apps übernahm insertEFFECT.

Auf die Inhalte von heise online sowie der dazugehörigen Channels können die Nutzer jederzeit zugreifen - auch offline. Unter Android passt sich die App den Displaygrößen von Smartphone und Tablet automatisch an. Speziell für iPhone und iPod touch gibt es zudem einen Barcode-Scanner sowie den heise-online-Preisvergleich.

 mockup heise

 

Wir haben mit insertEFFECT eine professionelle und angenehme Zusammenarbeit erlebt, in der eine App entstanden ist, die bei unseren Nutzern sehr gut ankommt und die genau an dem Tag fertig war, den wir zu Beginn des Projekts besprochen hatten.
Michael Wilde - Leiter Web-Entwicklung

 Download on the App Store Badge DE 135x40 1001 android en app rgb wo 45

Freigegeben in Referenzen
Mittwoch, 04 April 2012 15:01

Immowelt iPhone, iPad, Android App

Das Immobilienportal immowelt.de ist mit monatlich bis zu 4,2 Millionen Miet- und Kaufinteressenten (Unique Visitors laut comScore, Stand: September 2012) und bis zu 1,2 Millionen Immobilienangeboten pro Monat eines der meistbesuchten Immobilienportale.

Mit der iPad-App von immowelt.de verpassen Sie jetzt auch unterwegs keine Immobilienangebote mehr!

Sie sind gerade in einem Stadtteil, der Ihnen besonders gut gefällt? Mit der iPad-App von immowelt.de finden Sie schnell heraus, ob es freie Immobilien in der Nähe gibt.

 

mockup immowelt

Mit insertEFFECT haben wir einen zuverlässigen Partner an Bord. Gemeinsam konnten wir in den letzten Jahren unterschiedlichste mobile Anwendungen für die Immobiliensuche realisieren. Unser aktuelles Projekt, die neu entwickelte iPad- Applikation, ist einfach und schnell zu bedienen. Damit wird die mobile Immobiliensuche noch bequemer.

Jürgen Roth - Vorstand, immowelt AG

Download on the App Store Badge DE 135x40 1001 android en app rgb wo 45

Freigegeben in Referenzen
Mittwoch, 07 März 2012 11:25

Entwicklung

Wir entwickeln schon seit vielen Jahren Anwendungen für mobile Plattformen. Das haben wir vielen anderen voraus. Unser Ziel ist, stets die Möglichkeiten maximal auszureizen – egal, ob:

  • Native App oder Hybrid-App
  • iPhone, iPad, Android, Windows Phone & Co.
  • Mobile Webseite oder WebApp
  • Tablet, Smartphone, Feature Phone

Aufgrund unserer langjährigen Erfahrung können wir Lösungen entwickeln, die nicht nur heute schnell und flüssig reagieren, sondern auch in Zukunft wart-, skalier- und erweiterbar sind.

Und das Ganze für jede Plattform – passgenau und maßgeschneidert.

Freigegeben in Kompetenzen
Mittwoch, 07 März 2012 10:57

Konzeption

Frühzeitig sehen und testen. Mit Clickdummys machen wir Ihre Ideen noch vor der Umsetzung klick- und somit be-greifbar.

Wir legen Wert auf eine umfassende Konzeptionsphase, bei der sowohl Designer als auch Entwickler mit am Tisch sitzen. Mit einem Clickdummy möchten wir Ihnen ein erstes Gefühl für die Anwendung geben und nicht bloß abstrakt über Konzepte diskutieren. Denn manchmal scheint ein geplantes Feature auf dem Papier sinnvoll, zeigt sich auf dem Endgerät aber wenig userfreundlich. Wir setzen zudem auf Clickdummys, weil:

  • es endlose Überarbeitungsschleifen und Meetings vermeidet
  • so Timelines und Budgets strikt eingehalten werden können
  • die Machbarkeit bereits im Vorfeld geprüft wird
  • die Usability enorm verbessert wird
  • eine rasche Umsetzung sichergestellt wird

Durch den engen Austausch entstehen häufig auch zahlreiche neue Ideen. Vor allem aber können Sie Ihre Anwendung bereits zu einem frühen Zeitpunkt sehen und testen.

Freigegeben in Kompetenzen
Mittwoch, 07 März 2012 10:53

Design

In Form und Farbe gegossen. Wir stimmen Usability und Design optimal auf Plattform und Displaygröße ab. Ein perfektes Nutzererlebnis vom ersten Moment an entscheidet, ob Ihre Webseite genutzt, Ihre App in den Bestenlisten geführt oder gleich wieder gelöscht und negativ bewertet wird. Mobile Design ist daher für uns mehr als nur perfektes Aussehen. Es steht für:

  • Individuelle Screendesigns: Detailtiefe oder schlichte Eleganz
  • Plattformspezifische Anforderungen zu berücksichtigen (z. B. Icon- und Navigation-Design)
  • Features auf Performance, Funktionalität und Verständlichkeit zu überprüfen
  • Umzusetzen, was visuell wünschenswert und technisch sinnvoll ist
  • Corporate Design-Vorgaben immer Blick zu haben

Dabei zahlen sich unsere Begeisterung für ästhetisches Design sowie unser langjähriges technisches Know-How aus.

Freigegeben in Kompetenzen
Seite 1 von 2