Our Way To The Final Logo Design

A while ago I wrote about how to design a successful app (to the post) whereby I referred to my own app project. I'm currently developing a recipe app for Android with my project partner Marlene Knoche (her blog). The basic concept for this app is about collecting personal recipes. Personal means that you got these recipes from other friends or your family (maybe your grandma). I personally wrote those recipes in a notebook (out of paper). typical problems with such paper books are:

• When you use them, the paper gets dirty or even wet (from cooking), letters get blurred.
• When the book is full you have to chose a new book or put in single sheets of paper.
• You cant reorganize your recipes.
• You typically document the instructions of a recipe only with words. There is no multimedia content

Maybe you know more problems, to me they are enough to build an app :-) So why build an own app, as there are a lot of apps for recipes out there? Most existing recipe apps don't meet my needs. Most apps let you capture your recipes, but you can't export or reuse them with other apps or tools. Other apps (like Evernote Food) give me that ability, but they are not providing me or any other user a fixed  data structure supporting at which contents to create for a recipe. Evernote Food especially is mixing up my recipe notes with traditional notes in the regular Evernote app, which I do not like. There are still more features that I want to realize in my own recipe app. But the most important is the export functionality. This export should be a high quality print layout. So that when you do a print export, you get a pdf file that contains a set of recipes arranged by yourself to be given to a print shop, that prints your own recipe book. This is a really great idea for a personal gift, too. So this is what I want to have.

 I already reached the end point of the logo design phase and currently I create the basic views and their design. The process of the logo design is what I want to reflect in this post.

Actually, the time to design the logo that finally is used in the recipe app was quite long and we've took a lot iterations to get clear of the base idea behind the logo design. To name it immediately at the beginning, it actually took that much time as the app name wasn't determined at all, too. This, as you will see, reflects in the variety of different design approaches.

Everything began with a spontaneous mind mapping session with my project partner. First we inspected names and design ideas of other recipe apps. The result of this overview was:

• Most logo designs contained typical cooking symbols like cutlery, chef's hat, dishes, etc.
• Often the logos are of a illustrative and iconic type.
• All kinds of cooking metaphors are used to much.

Then we started brain storming and mind mapping.

This mind map indeed captures quite good the essential idea of the app. For defining a name and the logo it is necessary to have this idea in mind.

Then we noted all name ideas for the app. There came lots of good and bad ideas: Cook Stories, Food Stories, Cook Time, Media Meal, Food Print / Printfood, Augenschmauß ... these names are just some of the many ideas we had. But there was not really a great idea.

Some time later we had a nice idea:

GREATFOOD - sounds like Grapefruit, so a logo idea was born, too

I really liked the idea of the logo. But unfortunately there is a quite subtle connection to the NBC logo and there are already quite similar apps in the Google Play store. So we dropped that thought of the name and went on.

Next we just tried to create a logo and maybe we would derive of this the name. Here are only some results of all iterations we took:

The top right logo draft should correspond to the German word play "Mahlzeit", which actually means meal, but in German consists of the two parts meal ("Mahl") and time ("zeit"). As you may see we came to this idea with the kettle, the magic stick and the recipe note. To me and my project partner the graphic design of the logo looked beautiful. The colors we have chosen are fresh which correlates with the whole cooking and grocery topic. And by chance green is my favourite color.

Then we had an idea of the name for the app: "RezepTour". The problem with the logo was, when I showed it to other people (with the size of a real app logo on a device) they could not figure out clear enough what this app should be for. They said something like: "Is this a magic topper?" - the magic stick matches to that interpretation, additionally. To me it was a bit surprising that only few of them interpreted this app logo as it was intended, first.

So, next iteration!

Actually the next idea was quite spontaneous and is about the export and print feature of the app. Falling late into sleep the night before and thinking about the app - there it was: Printzept! The name sounds unique, the idea behind the name corresponds with the most important feature of the app. Like the previous name this one also is mixed out of two words: Print + Rezept (German: recipe). The logo design was done immediately next morning. I drew the name and some styled letters of it to paper.

My project partner opened the vector graphic program, looked at some free fonts and just created the logo that until now is our very final version ;-)

Some days ago I read a really informative and great article: http://www.adhamdannaway.com/blog/branding/a-systematic-approach-to-logo-design

According to this article I would classify this logo as a typographic logo. This actually distinguishes very much from existing recipe app logos. As mentioned above, most logo designs are of an illustrative or iconic type. The simplicity comes from the flat design and the reduced color selection. Knowing the name "Printzept" it is still readable or recognizable when the logo is shown in app icon size.

Unique & simple - I love it!

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.

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.

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