Showing posts with label Android. Show all posts
Showing posts with label Android. Show all posts

Thursday, April 4, 2013

App Design

In the recent time I thought a lot about app development and especially about the aspects of design and functionality. I asked myself: "How can I create an app that really impresses the user by its appearance and brings value to the user?". When you talk about getting value of the functionality of an app, you have to name the concrete topic or the issue what the app is about. OK - I want to create a recipe app for the Android platform. Only a few words to the intention that I have. Actually there is no recipe app that feels like an equal replacement for a physical cook book. Of course, there a lot of apps that simply let you create recipes or fetch them from the the web. But none of those lets you do more things (publish / share / high quality print / discuss) with your recipes nor there is any app that does it in an attractive way, too. If you find an app with some of the desired functionality it either costs money or it is ugly or slow (like the german Chefkoch.de-app). The next thing is, I want to collect my own recipes or recipes that I got from family or friends. So it is a very personal thing, just like a diary or a scrap book. The last point is that I want to have the option to export and share recipes. Maybe I want to print a physical recipe book of a collection of special recipes to give it as a present to a dear friend. So this print layout has to be in a high quality, just like the layout of a professional cook book that you can buy in a book store.

So far, this is the intention of the app. Now as I described the problem, I can talk about the issues that I discovered at the design of functionality and the user interface. Maybe you have heard the term of featuritis? First of all let's have a look at the definition at wikipedia (http://en.wikiquote.org/wiki/Featuritis). Featuritis is a phenomenon that you can discover quite often if you grab an arbitrary app from the Play Store. Often I can't figure out what are the main functions of an app. This is partially caused by a bad or overloaded view design and partially caused by a missing focus on the main intention of the app.
I also have had this problem when I developed my first apps. How can you face this problem?
First, one has to have a vision of the base idea of the app. Can you describe the functionality and the value of it in only a few sentences to other people? Are there other apps out there in the Play Store (or other app stores) that do the same or similar like your app should do? If yes, how can you distinguish yours from the other? Is there a use case or a reason why one should or would use your app instead another one? Serves the app a value to a user at all?
If you can answer these questions clearly and positively (this is what I tried to do in a short way above), you may begin designing and developing your app. Next you need a simple, catchy and expressive name and a logo. The logo and the name brings more motivation to me and lets me identify myself with the app to be developed. This is definitevly no easy step and very hard to describe rules for. So I will go on. ;-)

Maybe you have heard of the hierarchy of needs by Maslow yet? Actually this hierarchy (or pyramid) is related to the needs of a human being. In this hierachy physiological needs like breathing, food, sleep etc. form the base of the pyramid. Only if those needs are met, there come up further needs (security needs) like a secure home, employment and so on. There are still more steps that come after these two. As you may expect there is an adopted concept of this hierachy of needs for the domain of (app) design. You will see it in the following figure. I found this in a Google IO talk with the topic "Android Design For Success" (https://www.youtube.com/watch?v=2NL_83EG0no).
You also may have noticed that I already talked about the first step (utility and purpose) quite at the beginning. So, by going the second step, the real development can begin. Now you should start to think of the structure of your app and how the user will navigate through your screens later. To consider this step technical you should think of which fragments are needed, to present the information in the related views. You have to arrange the views and define which information should be presented in what kind of view. This brings us to the question: "How can you provide a consistent structure and layout?".  Each view transition should be logical and understandable to the user. Fulfill the expectations of a person, that knows how Android-4-apps behave!
When you have come so far, you can take the next step. Now you can bring a simple branding into your app. Provide it with your logo and some simple design resources, like icons. Furthermore think of the huge variety of devices, their formats and different versions (API level). You should ask yourself now: "What do I want to support and what kind of devices should get a special layout to accommodate their special abilities and properties?". Maybe you will have to add support libraries or frameworks like ActionBarSherlock. To integrate this libraries into your project you will only have to change some imports. There are also some little API differences that you will have to regard. Applying these changes should not be too complicated, but it would also be recommendable to do these things in the project setup.

If you have applied these rules to your project, your app should result in a consistently and useful designed app. Users should understand the idea of your app and know how to use its features. Also the design should be alligned to the Android platform guidelines. Especially if there are already some apps that seem to be equal to yours or claim to be for the same purpose, you will have to differentiate your app from all the others. Make the user remembering your app and try to bring enthusiasm to the user. To make the user remember your app, you will have to make your app unique. This is done in the fourth step. The key is common identity (CI)! the most popular companies have a special theme or design rules applied to color, font and forms in all products that represent the company. A simple example is Facebook: So simple. A single small, white "f" with a blue backgound. And of course the like-button all over the internet. Everyone knows and recognizes Facebook at these simply and clearly designed elements. This is what you have to find for your app or for your whole project. This should burn your appearance into the users brain.

The last point is in my opinion not the most important one for success, as you already fit into the design concept of the platform by distinguishing yourself from others by your CI at the same time. But I would call it to cause the wow-effect. I think Apple with its iPhones and the whole app platform did it as the first company. There are many apps that let the user feel the elegance of the gadget merged with the design and the functionality of an app. The app is unified with the gadged and the user is just impressed by a special app.  The positive feelings for the device are transferred to the app and vice versa. This is a very emotional moment which is caused by some simple methods. Let your app feel smooth. Add custom and organic transitions or other eye candy effects. Obviously such eye candy is not neccessary to make an app useful and therefore popular. But it serves the emotional and subjective character of the human mind and so puts rational aspects in another perspective. Don't get me wrong at this point. With eye candy I do not mean as much effects as possible. In contrast the trend to more simplicity and flat design shows that the simplest design might be usable and nice without having many effects or so called eye candy. It is about a natural look and feel of the user interface. This might be reached by using some animations, transitions or other effects, but it is no dogma. As it is with many other things, too: It is about the right balance! This may be the nice topping of the design of your app. Then your app will hopefully successful.

Saturday, February 23, 2013

Das OSIT-Modell

Beim Lesen des Web Magazins habe ich einen wirklich interessanten Artikel über das UI-Design gelesen. Beflügelt von den darin erläuterten Konzepten möchte ich ein wenig darüber schreiben bzw. überlegen wie man diese Konzepte auf die Entwicklung von (Mobile) UIs übertragen kann oder wo diese schon Anwendung finden.

In Ausgabe 1.2013 des Web Magazins stellt Prof. Wolfgang Henseler das Konzept NUI (Natural User Interface)  und als ein weiteres hilfreiches Modell für die Konzeption von UIs das OSIT-Modell vor.  Das folgende Zitat fasst recht kurz zusammen, was NUI ist und welche Intention dahinter steht:

"Von visueller Gestaltung zur Gestaltung von Verhalten. Dieser erste Einblick verdeutlicht sehr gut, wohin sich, neben den Geschäftsmodellen, das Design verändern wird. Nicht mehr die Gestaltung des Aussehens - Look - ist von entscheidender Bedeutung, sondern die Gestaltung des Verhaltens - Feel - rückt in den Mittelpunkt designerischen Denkens Spielte also bei den grafischen Benutzungsoberflächen die Grafik, das Visuelle, eine zentrale Rolle bei der Gestaltung, so verlagert sich dies bei Natural User Interfaces in Richtung Verhalten. Das bedeutet nicht, dass es in Zukunft keine visuellen Interaktionselemente mehr geben wird, nur ist eben deren Verhalten für den effektiven und effizienten Umgang mit der Software wichtiger als ihr Aussehen. ..."

Es geht also darum, das ein User Interface den Nutzer in seinen Arbeitsprozessen unterstützen soll. Es ist nur ein Vermittler in der Mensch-Maschine-Interaktion. Ein NUI fügt sich in das Verhalten des Benutzers ein und dessen Elemente halten sich dezent im Hintergrund. Erst, wenn der Nutzer ein Element für eine Aktion benötigt, erscheint es. Dafür ist jedoch das Verhalten des Nutzers von Bedeutung. Anwendungs- bzw. UI-Entwickler müssen dieses Verhalten analysieren, kennen lernen und dem entsprechend die Ui gestalten. Als ein Modell für das Beschreiben des menschlichen Verhaltens bzw. des Handels kann das OSIT-Modell herangezogen werden. OSIT ist ein Akronym aus den folgend aufgelistenten und erläuterten Worten:
  • Orientieren: Der Mensch versucht eine Übersicht über bestehende Objekte zu erlangen. Er will Kontrolle über die Situation erlangen. Er orientiert sich.
  • Selektieren: Der Mensch trifft Entscheidungen. Er wählt ein Objekt aus.
  • Informieren: Der Mensch will mehr Details / Informationen zu dem ausgewählten Objekt. Er betrachtet das Objekt genauer, oder näher.
  • Transagieren: Der Mensch macht mit dem Objekt etwas (Transaktion).
Das OSIT-Modell ist aus der Physiologie des Menschen abgeleitet und trifft deshalb auf alle Menschen gleichermaßen zu. Dieses gilt es bei der Verhaltensanalyse eines Anwenders oder einer Anwendergruppe zu nutzen. Eine resultierende Benutzerschnittstelle sollte diese menschlichen Verhaltensweisen berücksichtigen und unterstützen. Für die App-Entwicklung könnte die Anwendung des Modells auf die UI folgende Auswirkung haben.

Mobile Apps sind Programme und typisch für Programme ist, dass Nutzer häufig über diese mit Daten arbeiten. Neben den Daten als Objekte kann man auch die Funktionen einer App als Objekte betrachten. Diese gilt es dem Nutzer übersichtlich zu präsentieren. Der Nutzer muss einen Überblick über alle Daten oder Funktionen erhalten. Gibt es beispielsweise viele Daten, braucht der Anwender vielleicht eine Filterfunktion, die die Menge der Daten reduziert. Der Anwender muss eine Auswahl treffen können. Für Funktionen mag dies bedeuten, dass nur die Funktionen angezeigt, werden, die auch wirklich sinnvoll erscheinen. Die Funktionen werden kontextsensitiv angezeigt.
Der Nutzer trifft eine Auswahl unter seinen Optionen und wählt etwas aus. Dabei sollte dieser so gut wie möglich unterstützt werden. Im Bereich der Mobilen Systeme, wie Android oder iOS kann man schon häufig ein intelligentes Verhalten der UI feststellen. Diese brachten, denke ich, erst das Umdenken in Sachen UI-Design richtig in Gange.

Aktuell beschäftige ich mich mit der Entwicklung einer App, bei der ich solche hilfreiches Wissen gern anwenden möchte. Ich hoffe ich werde in diese Richtung gehend noch weitere interessante Ansätze, Modelle oder Konzepte entdecken.

Monday, January 9, 2012

Android und Maven

In einem aktuellen Projekt habe ich mit Webservices und Android zu tun. Wenn ich bisher mit Java EE zu tun hatte, habe ich Maven als Projektverwaltungstool benutzt. Nun möchte ich auch das Android-Projekt von Maven verwalten lassen. Im Netz habe ich unter folgendem Link einen extra Archetype für solche Maven-Projekte gefunden.
https://github.com/akquinet/android-archetypes/wiki/android-quickstart-archetype
Dort ist ein ganz einfaches Beispiel beschrieben, wie ein solches Maven-Projekt aufgesetzt wird. Dies sieht wie folgt aus:
 mvn archetype:generate
-DarchetypeArtifactId=android-quickstart
-DarchetypeGroupId=de.akquinet.android.archetypes
-DarchetypeVersion=1.0.7
-DgroupId=your.company
-DartifactId=my-android-application
Dies funktionierte ohne Probleme. Danach kopierte ich die Dateien eines bestehenden Android-Projekts in das durch Maven generierte Projekt. Die danach aufgetretenen Fallstricke möchte ich in diesem Post kurz erklären.
  1. Das ist zwar ein Standardfehler, bei meinen Android Projekten, aber er trat wieder auf. Wenn wieder mal Eclipse neu eingerichtet wird und dann das Android-Eclipse-Plugin für Android installiert wird, sollte man nicht vergessen den Installationspfad zum SDK zu setzen.
  2. Ebenso ist der Pfad in der Maven-Konfiguration des Android-Build-Plugins zu setzen.
  3. Das Build-Plugin fordert ebenso eine minimale Maven-Version, die ich ebenso nachinstallieren musste. Dies ist die Version 3.0.3.
  4. Im Android-Manifest sollte man die benötigte Android-API-Version (android:minSdkVersion)noch prüfen.

Wednesday, October 26, 2011

Android: Der Vortrag in der Java User Group Görlitz

Hallo an alle Android-Interessierten!

in diesem Post möchte ich die Folien und das Eclipse-Android-Projekt vom Java-User-Group-Vortrag zum Download zur Verfügung stellen. Bei dem Projekt handelt es sich um eine ganz primitive Memo-App. Wer noch Fragen hat, ist dazu angehalten diese zu stellen.


Hier die zwei Links:
Weiterhin gibt es noch die gratis Version des Buches "Android - Grundlagen und Programmierung" (Arno Becker und Marcus Pant) unter folgendem Link zum Download:
Beim Durcharbeiten ist bitte zu beachten, dass an einigen Stellen Fehler enthalten sind, bzw. einige Erläuterungen fehlen. Dazu sind auf der Website zum Buch unter der Rubrik Errata Korrekturen und Anmerkungen zu lesen, die dann hilfreich sind, wenn irgendetwas im Buch nicht nachvollziehbar ist.

Viel Spaß

    Sunday, July 24, 2011

    Android: Eine kleine Radio-App

    Oft hat es mich bereits gefrustet, dass es vom MDR bereits für Jump eine Android-App gab, mit der man den Internetradio-Stream hören konnte, aber für mein geliebtes Figaro dagegen nicht. Einen Livestream haben Sie zwar schon, jedoch ist dieser nur über die Internetseite von MDR Figaro abspielbar.

    Nun ja, das stimmt nicht ganz, man kann auch noch eine Wiedergabeliste dafür herunterladen. Ein beliebiger Player kann den Stream dann abspielen. Nachdem ich mir die Wiedergabeliste, eine pls-Datei, mal im Texteditor angeschaut hatte, war mir klar, dass ich auch selbst was damit anstellen könnte.

    So schaut eine pls-Datei aus:

    [playlist]
    numberofentries=1
    File1=http://c22033-l.i.core.cdn.streamfarm.net/22007mdrfigaro/
    live/3087mdr_figaro/live_de_128.mp3
    Length1=-1

    Gestern früh kam mir dann der Gedanke: Jetzt wo ich selbst ein Android-Telefon besitzte und ich auch noch Java kann, sollte ich mir doch mal eine eigene Figaro-App schreiben.

    Den entsprechend geeigneten Player zu finden , der von Android für Internet-Audiostreams geboten wird, war nicht schwer. Der AsyncPlayer ist sehr einfach zu benutzen. Man übergibt einen URI und sagt ihm, dass er den Stream abspielen soll. Nach ein paar Sekunden beginnt er. Will man die Wiedergabe anhalten, ruft man die Stop-Methode auf. Mehr kann man mit diesem Player nicht anstellen. Folgender Code zeigt ein Beispiel:

    android.media.AsyncPlayer player = new AsyncPlayer("StreamPlayer");
    Uri uri = Uri.parse("http://c22033-l.i.core.cdn.streamfarm.net/22007mdrfigaro/
      live/3087mdr_figaro/live_de_128.mp3");
    player.play(this, uri, true, AudioManager.STREAM_MUSIC);
    // Der Stream läuft
    player.stop();
    // Der stream ist gestoppt. Pause gibt es nicht.

    Die App kommt aufgrund der Einfachheit mit einer Activity aus. Leider habe ich doch mehr als 5 Stunden daran gesessen. Grund dafür ist die bescheidene Android-Oberflächengestalltung. Das Layout macht nie das, was es soll :-) Die Beschreibung der View in XML ist eine saubere Sache, da Logik und Anzeige getrennt werden. Jedoch wäre es meines Erachtens nach gut gewesen, sich bei der Beschreibung der Oberfäche an XHTML und CSS zu orientieren. Lange Rede, kurzer Sinn: Die entworfene Oberfläche ist sehr einfach gehalten. Ein Play/Pause-Button und ein Stop-Button sowie ein Hintergrundbild habe ich für die View verwendet.

     Wer Interesse an der App hat, kann Sie sich unter folgendem Link herunterladen.

    http://dl.dropbox.com/u/3538883/Downloads_Max_Blog/MDRFigaroWebRadio.apk