Anyone who isn't familiar with Topgear (at least in the English speaking part of the world) may deserve a smack on the back of his/her head for ignoring popular culture.
Just in case, here's the short version: Topgear is a terribly popular television show broadcasted by the BBC. It's about cars – fast and awesome cars of any kind. And about the three guys hosting it who are as funny and witty as it gets.

I redesigned their Android app, because, well… it was awful. This is a showcase of what I did and how I pulled it off.

1. The Original Material

You can see clearly that this was ported straight from the iOS and just doesn't work for Android.

2. The Concept

In scribbled wireframes I have laid out what is to become a solid, nicely working Android app. You get the notion: it is pretty complex at first, but that's exactly what a good UI design should do: break apart complex structures and make them accessible for the user. Here you get some insight on the information architecture and the thoughts I put into it, featuring the overall purpose of the app, the structure of the presentation, and the proposals for individual screens.

3. The Redesign Process

From the scribbled layouts of the app screens, the content structure and the navigation, I dove into Illustrator to really take everything apart and build it anew.

So now, to the individual screens of the app: I stuck very closely to the Android guidelines, as you will see. No gradients or skeuomorphisms – everything's flat now. You really start focusing on the content instead of the UI, which is even more important for such a feature rich, complex app as this one. One more aspect that shouldn't be forgotten is staying true to the branding as much as possible.

The News Screen

The Seasons Screen

The Car Reviews Screen

Oh yeah, and don't forget about the rich notifications:

4. The Results

Initially, I laid out a hierarchy of the app. With this in mind I designed the screens to make them match:

Now think way, way back: remember the original material? The result has little in common with it anymore. Man, that was easy. I wonder what took me so long.

There has been a lot of discussion about the recent trend towards flat design as opposed to the skeuomorphic approach that became so popular with iOS. Although the existing commentary on the topic has many valid points, I haven’t seen anyone discuss the more fundamental shift behind the visual flatness.

In practice, skeuomorphism is about thinking visual and interaction design in terms of metaphors. Skeuomorphic UIs have, almost by definition, a strong focus on the UI chrome. The focus on the chrome is not exclusive to skeuomorphism though. For instance, UI realism is on the same boat with the imitation of real-world textures and materials. So, how does flat design differ from that?

Windows Phone and Android are the most prominent mobile platforms currently adopting flat design. Here are some words by Mike Kruzeniski, former design lead for Windows Phone, from an interview published in The Mobile Frontier book:

One of the main concepts we focused on with both the Kin and Windows Mobile 7 was to create a truly content-driven interface. While the iPhone is beautiful, its UI and the UI of many other devices is built on the desktop metaphor. Most of the mobile interfaces we see in the market today are built upon entrenched metaphors inherited from the PC—folders, icons, desktop spaces, and chrome elements that are rendered to represent real materials.

On the Android side, here’s what their official design guidelines say under the Put Content Forward section:

Many apps focus on the content display. Avoid navigation-only screens and instead let people get to the meat of your app right away by making content the centerpiece of your start screen. Choose layouts that are visually engaging and appropriate for the data type and screen size.

Beyond the visual flatness, what both Windows Phone and Android have in common is their focus on content. The visual simplicity of flat design is an effective way of moving the focus from the UI chrome to the content.

In other words, the real deal about flat design—in my opinion anyway—is really about moving away from the traditional embellishing of UI metaphors torwards an all-digital content-driven approach to product design.

+Illustration by Agata ENDO Nowicka

It's on

One of the great things about the trade of creating stuff for the web is that, perhaps more than any other business, it reflects the society we live in and different positions in that society. Even if – or especially because – it is a superfast, almost ephemeral medium that we change with light speed, there are two predominant positions always waging war with one another, although we hardly notice it anymore: Innovation and Conservatism.

I'll save that for later

The internet is a very conservative medium. This statement may strike you as odd if you consider what I just said in the paragraph above. But if there's something like an Ur-conservative (in the literal, truest sense of the word) claim, it would probably be: "If it isn't broken, why fix it?" Or even: "It might be broken, but I might still need it and I will continue to use it. Or just keep it." The internet is conservative because it is concerned with keeping things, conserving them.
Conservatism may be defined as disposition and tendency to preserve what is established, the opposition to change or making something new. We are so tempted to be digitally conservative, because computers and the web are, to some extent, designed to keep things: hard drives and externals, the cloud, Dropbox, servers, … – they all help us do exactly that. We don't need to get rid of anything anymore. There is nothing like a digital River Lethe that beckons us, with its pure and sparkling water, to drink – and forget. Don't get me wrong: in its own right, this is something great. But there is always this connotation of stagnation and outdatedness. How terrible is it when you can't let go of things that don't do anyone any good? It is the hoarding, even digital hoarding that makes us feel a burden of "too much", of things that should be forgotten. Because there is a physical and psychological limit to capacity, maybe not digitally, but personally. Computers and the internet are still about the people that use them.

Screw this, I'll make a new one

The innovator holds against the conservator: "Even if it worked perfectly – which it possibly cannot – I will make a new one anyway. A completely new one. It's gonna blow your fuckin' mind."
It's easy to be tempted to give way purely to the holy grail of innovation. It just feels right: that air of revolution, pushing the limits, making use of creativity, creating something that wasn't there before, breaking all the rules established by someone we probably wouldn't like anyway.
Innovation is profusely pouring out change. But this excessive desire for change can also easily lead to pushing the constraining limits into boundless nonsensicalness, changing things only for change's sake, making the actual change obsolete.

Or I'll just be a carpenter

Maybe we should take the conservatism that is probably at least embryonically inherent in everyone and replace it with consistency.
Think of it as something like a traditional craft. Take carpentry, or Japanese pottery. In their best form, the products created here are timeless, precisely because they have been consistently developed over time, always adapting to technological possibilities and customers' needs. What you do is: you pick something, you practice, refine, improve, polish, make it great, but you don't ignore the room for innovation. You use the benefits of variety but don't let the sheer immenseness of possibilities blind and shield you from your actual project or your general craft. In Aristotelian logic, something is consistent if it does not contain a contradiction; if all the interpretations of it are coherent, they are true. Innovation, like a piece of marquetry, can be fit perfectly into your consistent model. Let's innovate consistently, let's conserve the good things, but let's also consistently forget a little.

About the Illustrator

Agata Nowicka is one of Poland's most renowned illustrators. Additionally to being a lovely and debonair person, she has worked for terribly big clients, her work is featured on the covers of magazines with dizzying circulation, she has exhibitions all over the world, and she kindly let us use her wonderful illustration for this blog article.

Icondesign still seems like the highest form of art within the field of interface design. While this is definitely true for large Play- and Appstore logos, visual cues and navigation icons have become much simpler to create and style with the rise of mobile design.

In this article, I quickly want to give you a rundown on how to create a nice set of icons very fast, and the pitfalls to look out for – I'm assuming you can handle your graphics tool, be it Photoshop, Illustrator, Inkscape or anything else that makes working with simple shapes easy.

Sketch

Let's always start with some sketches. You want to make sure, that your client deals with the metaphor and only the metaphor, instead of focusing on all the colors and details in the first place. Maybe this is a good point to offer some alternatives, if you're not 100% sure about a certain item.

Shape

After all the sketches are signed off on, jump straight to the basic shapes with your preferred editor. Depending on the size of the icons, I would suggest caring for pixel-perfection already, since this will be much harder to get right later on in the process, especially if you're recycling single elements throughout the set. Try to stay within the grid for all horizontal and vertical shapes and strokes. Still, stay away from the color.

Color

Now let's throw in some color. Most iconsets are related to a certain branding, so you might want to take a good look at the styleguides or try to stay as close to the brand as possible. Remember: Most icons are used together with others, so try to not have every icon scream for the same attention. Use color wisely to balance out importance and differentiation across the set and the UI. Also, this might be a good time to test your icons against different background colors and shades of grey.

Weight

This might be the step most young designers skip in the beginning. Your icons will probably never show up on their own. This is even more important if you're working on the same set with other artists, or tying into an existing set. While all icons are based on the same square frame most of the time, you have to carefully balance the weight of the icons across the set. Plane shapes with a filled body need to be much smaller within the artboard, while complex shapes with fine elements should use as much space as possible.

Light, Shadow & Effects

At this point, all icons should work nicely without any additional effects. If that is the case, why not add a little for extra appeal? How about just giving the bottom pixels a slightly darker tone for each color and highlighting the top ones equally? Try out some gradients, drop shadows or bevels if it matches nicely with the brand. Just don't overdo it. Icons are meant to emphasize certain elements of the UI, not distract from them.

Hopefully, this short tutorial made icondesign a little less frightening. While you should leave the core icons of a set or product to the professionals, creating a quick favorite-star or bookmark-ribbon might make the difference in your app's UI, without the need to hire an expensive designer.

It's so common sensical: if you do great work and you want others to know – so they can give you more great work to do – you need a portfolio. This regardless, if you are focused on code or design, on copywriting or app development. So the first step for creating a great portfolio is obtaining good references of projects you did (duh!).

Then, once you have accumulated a pool of awesome products for reference, you need to figure out how you're going to present them. You'll want to ask yourself: What do I want to present? Obviously, you want to only select the projects you're most happy with. This includes a certain uniqueness of either the project, your realization of it, or ideally both.
Consequently, your next question is how you want to present your projects. One way would be a link to an external reference, such as a website you designed or an app store where your product is presented. This is a reasonably good way a portfolio can work, because it shows your work in context. However, it might not give the attention to detail you desire your portfolio-viewer to see. Maybe you spent a lot of effort trying to get the interaction or navigation just right. Maybe there's a story behind the project that might be of interest. Maybe you reworked some illustrations several times and you want to show the progress you made incorporating the feedback of a customer or reviews of your colleagues. The way to go about, then, would be to have a special sort of reference where you have all the freedom in the world, presenting everything you want just the way you want it. A case study. There, it doesn't hurt to link to the finished product and you have everything all at once.
Additionally, and this goes almost without saying: spend time on typography, selecting and cutting the right assets, widespace, importance and presentation of elements, etc.

It's not a crime to get inspired by other portfolios. Use structures that you like and that make sense for your own portfolio. Use everything you can but make something unique out of it. No one like copycats. For reference and inspiration, check out the following links to portfolios we think are especially worth noting because somebody did an excellent job on them.

1. Focuslab
2. Opoloo
3. Simon Foster
4. zinni
5. Sagmeister & Walsh

If you decide in favor of a case study...

...think about the following things concerning your product:
– What does it do?
– What is it for?
– What did you do? (Code, Design, Concept, Realization, UI, UX, …)
– How did you do it?
– Why did you do it the way you did it?
Focus on the special features of your product, your favorite parts of it, the story of the genesis of the project. At the same time, don't write a novel that nobody wants to read. Put the most weight on the visual representation, let it do most of the talking.

As far as presentation and strategy are concerned: this is not advertising. It is a showcase that works as a presentation of your skill. Like a piece in a museum, but structured in the way that the visitor can relate to the construction process or whatever you focus on. By this it automatically serves as an advertisement of your skill.
As a finishing, more pragmatical note: It might be very sensible to create solid, flexible templates, so your portfolio is a coherent experience in itself. Also, this comes in handy when you create new case studies because you don't have to start over again every time.

Illustration by Jo Chapman

The man was already a little tired. Although he wasn't really that old, he already felt the weight of time on his shoulders. Though he wasn't sure how many days and years had passed exactly since he had been sitting there, waiting, it might have been more than 10 already.

The man typed some cryptic commands on his keyboard. He had been doing this for a long time. The server didn't respond. Not for a long time. Finally, he thought, power has run out in here as well. So it had in most parts of the world.

The man took a deep breath. To be honest, he didn't expect any other reaction. He launched the browser, again, with a couple of quick hits to the old keys in front of him. There it was. A black page with white letters. Big fonts in the upper left corner simply said IM ALONE. Nothing more.

The man tried to smile, but his face didn't move. Not even a little. He remembered previous iterations of his site with detailed descriptions of his location and well-being, with long paragraphs of what had happened and how to move on, with links to other people and sites, offering more rich advice of what to do and where to go next.

The man remembered how he changed the site, according to his mood and abilities. From a colorful, dramatic presentation, with interactive elements, trying to reach out, his site became more and more a reflection of himself. Colors faded, as did visitors and the news. In the end, the only thing that remained was a short message in black and white.

The man scratched his head. What an irony. The web was built decades ago to establish communications, to withstand war and other catastrophes. And a war they had.

The man wasn't sure who had started it and what really had happened along the way. The only thing he knew was that he had been building websites all his life. Vivid and rich, interactive and large, emotional and perfect. An that's what he did.

The man opened his tool for the last time and wrote:

DEAR WEBSITE. YOU'VE BEEN MY BEST FRIEND OVER THESE LAST YEARS. YOU'VE BEEN A CONSTANT SUPPORTER, ALWAYS UNDERSTANDING AND BEING THERE FOR ME. NOW TIME IS RUNNING LOW. SOON, THERE WON'T BE ANY ENERGY LEFT TO POWER YOUR SERVER, LIKE EVERYWHERE ELSE IN THE WORLD.
GOOD-BYE, FAREWELL, YOURS TRULY

The man hit send and got up, left the small cabinet close to the power station, and started to walk down the street, away from the place where he had spent more than the last 10 years of the end of the world, doing what he had done his whole life. Building websites.

The sky was grey, and light rain started to fall. And someone else, somewhere else wrote on an old, worn out keyboard on his own little site: IS THERE ANYBODY OUT THERE.

Every once in a while I get kicked out of doors, just so you can profit from that. It was a grim and grey day, the view was all in lines, but my little Canon 60D and I were happy as a lark.
Right around the corner from our office, I shot some nice wallpapers for your desktop, phone, or tablet.

For those techies interested in some specs:

I used a Canon 60mm/2.8 macro lens. Exposure: 1/400 - 1/1,250. In the finishing process I adapted intensity and contrast slightly and carefully added some grunge-bokehish texture, as well as touching up on the gradients. When shooting pictures like this, take care that your background is far enough back, so it doesn't distract you from the actual object.

Enough said. You can download a .zip file with those Winter Wonder Wallpapers right here.

You're welcome.

Designing a good icon is an art form in itself. For decades now, we're trying to craft a perfect language that has no global barriers and lives on our large and small screens.

But there is a holy grail for icon designers which I've come across many times in the last 10 years. In fact, it's the most requested icon on Androidicons, that I still refuse to deliver – the 'Save' icon, a small floppy disk that came up in the 80s and has been loitering about ever since.

The problem is pretty obvious: Still, one of the most used functions in digital processing is represented by a visual metaphor that is already outdated by many years and will probably never come back.

While we tried to find alternatives like the hard drive or most recently a cloud to move the idea along, the metaphor for 'save' always gets stuck at some point, due to the rapid change of the technology it refers to. It's about time we break out of that cycle.

Every time I get asked about that particular icon, I suggest to skip the floppy icon and better go for an auto-save function. But to be honest, this does not solve the problem at all. Some apps do need a clear indicator of saving things at a certain point in time. Maybe there's a fundamental flaw in our expectation when it comes to data manipulation and conservation?

In the real world 'saving something' is to physically put an object to a place where it is protected from any kind of manipulation or distribution. But saving something in the digital world means conserving a document at a certain state of production, at a certain point in time. You definitely want to pick up where you left it, rather sooner than later, sometimes even in the middle of production. Think of this as opening or importing a document, working on it and saving it in regular steps, and finally exporting it. Here, saving is not the final state of your document – exporting is. Saving is rather the process of fixing the state of the document at a point in time.

Pretty complicated, right? But read on. As long as we agree that saving is not necessarily the final state of a document, we're good. Let's also agree that saving as we're using it in digital production refers to a state in time. Now time can easily be represented as a circle – compare our visual representation of a clock, or even a backup. Besides, the universe expands and collapses all the time, starting from the beginning again and again ... I'm driving you nuts, right? We're almost there.

So: starting a project or a document would mean to open or import your file into a certain frame of time – your workflow – a simple arrow into the circle representing time will do.

Now while you're working on the document, you might want to fix its progress from time to time within the workflow – you want to fix its state in time. Would two arrows pointing inside the circle work nicely?

Finally, once you've finished the project and want to save it permanently, you're going to export the document. Maybe you even want to continue working on it with another tool? Again: import, save progress a couple of times, and export eventually. How about simply an arrow pointing out of the circle?

Pretty easy, right?

To wrap this up, I crafted those three icon proposals as Android actionbar icons in Holo Light and Holo Dark. Grab them for free right here if you're feeling brave enough to leave the floppy disk behind, once and for all.

What is wrong with Germany?

It's no secret that Germany seems to be behind in some IT aspects. Maybe because so many Germans still think in the classic Bavarian paradigm:
1. We've always done it this way.
2. We've never done it that way.
3. Any Hooray Harry could come along and change things …
Consequently, we're fairly slow in adapting new technologies, simplifying bureaucratic procedures and applying the stuff that's already working much more efficiently in other countries. Just like Ruby on Rails.
But we at Opoloo have a long history of looking at the world askew, so our coder Jochen used Rails right from the beginning. And slowly but surely, although there are still not enough Rails developers in Germany to meet the demand for them, people over here are coming to their senses.

Our Rails History

Remember the Rails Hype back in 2005 when Twitter used Ruby? Quite untypical for a hype, however, it was well-founded, substantiated by a strong backbone. It was persistent. It was elegant. After working with Rails for 2 years, we quickly hit the walls; we were on our capacity limit. Here in Germany, this was a problem. Xing was looking for a Rails developer for 2 years! We wanted to work together, share our knowledge with other local Rails developers, but there weren't any. So we thought.

The Rails Society

Funnily enough, almost as if by accident (or by special providence, we are almost inclined to believe), there were people close to us who had quite some experience with Rails as well. We were glad to have found other Railiens and decided to get together to enjoy each others' company and talk nerd, to use synergies, to work together and be able to tackle larger projects.
So we founded The Rails Society as a platform, as a reference institution. It now consists of eight experts with regard to everything relevant for project realization. Here's a short introduction (I'm dead serious about this):
Jochen: Code Cookie Monster & Super Programmer Extraordinaire
Christian: Medical and Code Doctor, E-Commerce Entrepeneur
Josh: Code (and Word) Acrobat & Mr. Nice Guy
Hannes: Frontend and UI/UX Aestheticist & Checked Shirt Expert
Guenther: Presiding Chief of Design & meticulous UI/UX Advocate
Matze: Content Sunnyboy, Game Development and Code Hero
Sandra: Professor of Light Catching & Tough Template Lady
Nino: Wordworker & Content Choirmaster

Our Projects

What we did so far, surprisingly even to us, reads like a pretty good overview of what's possible with Ruby on Rails. Configuration tools, Android & iOS apps, e-commerce, multiplayer online game backend, communication tools, a photography service, frontend development. We don't get tired.

Come Play With Us

It's not as dangerous to play on the railroad tracks as most people think. Besides, we love to be challenged by those big passenger trains, Transsiberian Railways, overnighters, freightliners – in short: We're always happy to take on impossible projects. Also, if you're affiliated with Rails in any way, let's have a coffee and a talk (even if only virtually). We’re definitely interested in collaboration. That’s why created this Railiens platform in the first place. We’d like to motivate an exchange of ideas, philosophy, practice, projects, helping hands. Do say hello!

Illustration by Jo Chapman

All my life, my heart has yearned for a thing I cannot name.
- Andre Breton

The Name

Towel around waist, feet slapping kitchen tiles, I got to my notebook, scratched down a particularly pressing idea and titled it: “On Naming Things”.

Ideas tend to slide on stage when I'm doing my best to ignore them: showering, sleeping, sexing and such. Naturally I continue ignoring, while they make obscene gestures and threaten to run off. This continues ’til I roll my eyes, and capture it in my nearest notebook (either analog or digital).

Water still dripping I quickly scribbled out “Things”. I despise all-encompassing uses of the word “Things” as much as I despise most uses of “They”*.

Left with “On Naming” I evaluated.

I didn't want to focus on the method. I wanted to focus on the act. “On Naming” comes across formal, possibly pretentious, and wrong. I scribbled out “On”.

The Idea

“Naming” fit the idea that ousted me from an otherwise relaxing shower:

Naming is the emotional human act of experiencing something significant enough to take existing mental structures (metaphors and morphemes), and link them to the experience. Creating a contextual tag to easily recall and share.
- Refined from my original scratching.

Distillation

That’s a mouthful, so I swilled then distilled to:

Naming: repurposing the known to define the new.

We find the name for an idea through the relationships of other ideas. Representing and expressing it with just a word or few.

Conclusion

A is name more than a label. It is context. A searchable, shareable linguistic #tag representing the experience and information that goes with it.

I hope this thought helps, the next time you make a name.

I'd like to explore the act of Naming more.

For now we have the name.