Sometimes, when looking for a design solution we try to make things pretty and functional when functional might be enough. I would even go beyond that and say that functional and simple is the key.

Let’s take If This Than That (ifttt.com), as an example. If you already tried it, one thing you notice right away is that it’s not pretty. Everything is displayed on a white background with huge letters, and I mean huge! I should tell you that after about an hour setting up and tweaking my account, when I opened Gmail, my first thought was: “Why is everything so small?”.

But it works. It works and provides a simple and useful service. For those of you that don’t know it, it allows you to automate some actions based on triggers. For instance, you can create triggers like: If I publish a new article on my blog then send a tweet – or – If someone re-tweets one of my tweets then send him/her a thank you message, among other possibilities.

This is the actual size of the first step to create a task on Ifttt.

Simplicity of layout, simplicity of service

Once you log in into the service, it’s like entering a new world. A world of giants, where everything is the size XL. But somehow, you’re not overwhelmed, because everything works the way it’s supposed to. I’m not saying that it is perfect, there are some things that can be improved, but you can start to build your triggers right away without much doubt about what you’re doing.

Even the triggers can’t be made more complex. It would be useful to have things like If (This Or This) Then (That, That And That), but you can’t. It’s “If This That That”, period. You might think that this cripples the service, but it doesn’t, you just have to make more triggers.

Complex If statements are quite usual for coders and they can easily understand them, but this service is not designed for coders, it’s for people who just want to have simple shortcuts to make their on line tasks easier.

Function first

Having a “running prototype” – honestly, it’s what Ifttt looks like – allows you to have something up and running, and getting feedback before achieving full potential (and saving some time and money). By the time you have a “sexy” product, it will have all the features it needs to succeed. Hell, look at Google, it’s only recently that their products started to receive some deserved beautification. They were focused on making it work.

So before you tackle your next project, thing about this: Does it work? Is it simple? After answering yes to both questions, then you can start to beautify it. I myself have been caught in the beauty trap. Maybe it is because all the beautiful apps and products that you see every day. When see them, you must have something looking that good.

Mobile devices with touch-screens are starting to be more and more popular. When you’re building your site or web app, you should take this in consideration when designing the interface. Some people might use a mouse, other will use the fingers. This two have different needs and limitations, but with a little planning you can make the most of both.

Drop-down menus

First of all, when designing a drop-down menu, the trigger should have a visual hint, to let the user know that there’s one. It’s usually a small triangle, or arrow.

Horizontal menu prototype. Can you find which option has a drop-down?

Upon clicking the option, or sometimes on mouse over, the menu expands. How should it behave in order to provide the best experience for mouse and touch-screen users?

The expanded drop-down menu.

Most of the options that trigger drop-down menus that I see online, usually behave differently upon mouse-over and click. Typically mouse-over expands the menu and clicking takes you to a different page. In this case, a touch-screen user will never see the menu.

This is how your horizontal menu should behave.

Most of the times, the click on the option that expands the menu is really unnecessary, because it just takes you to a page with a more or less complex list of the drop-down menu options. It just adds one more step.

As I state on the picture above, you should trigger your menu with a mouse over or click. This approach will be acceptable for mouse and touch-screen users, providing real shortcuts for both.

What happens after the drop-down menu is expanded?

As any normal drop-down menu, you can close it with the mouse out event. It’s an expected behavior for a mouse user. But what if you don’t have a mouse? How can you close the menu if it doesn’t have the option you were looking for?

The answer is simple: Another click on the same button, or anywhere else on the page, should close it. This closing behavior can also be hinted by the change of the icon on the button, as you can see on the picture.

Be careful when using a time out to close your menu. You can program it to close after, let’s say, 5 seconds. This time can be more than enough for some people to check if the menu has the options they’re looking for, while others might find it too short. This kind of events should be tested and only be used if there is a real advantage – most of the times there isn’t.

Mouse over candy

You can have a mouse over candy on your menu. However touch-screen users won't see it.

Remember that the mouse over effects can’t be seen by a touch-screen user. These can be used for visual hints only when using a mouse. Fancy menus like like the Lava Lamp Menu, for instance, don’t look that good on a tablet.

Visual information upon click will be visible to both mouse and touch-screen users.

Active states and mouse down effects are also advisable. These provide a response to the user action. It could compensate for the lack of a mechanical response that you have on a physical button or keyboard. By having a down state, you remove the doubt of the user’s mind: “Did I really tapped it?”.

This is more important when your site takes more time to respond. When the user taps something, he expects a result. If nothing happens straight away, he’ll tap again, and again, and again, sometimes with disastrous results. The down state can help prevent this.

Mouse over exploration

You should never rely on mouse over alone to reveal or help navigation. On the image below there’s an example of a carousel used at Delicious.com.

Delicious.com carousel. Static.

Without a mouse over you don’t have any clue that you can scroll it. In a carousel like this, you should allways have the arrows on each side, to serve as visual hint for the user, to let him know that there’s more information. A mouse user would click the arrows, and a touch screen user could tap the arrows or drag to scroll.

When you put the mouse over it, you'll see that there's more to it than meets the eye.

Another good hint would be if the carousel scrolled automatically from time to time, which it doesn’t.

Different behaviors for different platforms

If you want, you can detect the OS or system that’s accessing your site and deliver different contents/behaviors for each one. On the carousel pictured above, one could detect the access through a mobile device and display the navigation arrows.

I really don’t agree with this way. Your user might be accessing your site or web app on a tablet and later access it through his computer. If you change things, the way it works or the visual language, you’re creating a barrier. You shouldn’t make your user learn it, or try to figure it out again.

Finger sized elements

Another thing to take into consideration, is that a finger is not as precise as a mouse cursor. When creating your clickable elements think about two things:

Size and Proximity: Your elements should be big enough and sufficiently far apart for a finger to tap them without error.

Placement: Is your element correctly positioned so that it is usable by a touch screen user?

Size and Proximity: Which one do you think is more suitable for a touch screen user? If it's good for the finger, it's good for the mouse.

Placement: Remember that on a touch screen, the user's hands hide everything below the elements. Here are some examples of elements that clearly don't work.

Final considerations

Tablets, smart phones and even some desktop computers have touch screens, and these are starting to be a more usual way to get to websites or web apps. When the users use their fingers, there’s no mouse over, and you shouldn’t cripple the navigation because of it. Do not rely on things like tool tips to explain what a certain icon does. Everything should be clear and self explanatory.

Good usability is invisible. People use it without thinking about it or without having to stop to ask for directions. So make your layouts and interfaces so clear and transparent that they become invisible (but beautiful).

In this article I’ll be focusing on the reasons why I believe that a native App is the wrong choice to sell newspapers and magazines. The written media is a sector that’s going through difficulties, mainly because of the free information that everyone can find through sites and blogs, and because it’s lacking a business model that can consistently make money through digital channels. They have good information, but they can’t sell it.

The app fever

Almost every publishing company wants to have a app on iPad and Android. I even know some companies that wanted one just to “be there”, without even considering if it was the right step or not. Some of them, are just a digital version of the printed magazine or newspaper, like a PDF file with a bit of special effects like some videos and some weird horizontal and vertical scrolls that dazzle and confuse the user and don’t really take any advantage of the digital medium itself. So is it really necessary to develop an app?

Websites were made for reading, everything on HTML is suitable for “traditional” media. I remember that one of the first sites I ever visited, when I connected my modem to the Internet, looked very much like a magazine. So why are the news companies investing on native apps instead of building up on this existing transverse technology?

The difficulties of a native app

Platform dedicated apps are difficult to maintain, specially on systems like Android that have a lot of different hardware specifications scattered through different versions of the OS itself. Not to mention that different OS have different User Interface languages which, if you want to build the best app for each platform, will make you different GUI for each one to match the system’s User Experience (UX).

This brings us another problem: Viewing a magazine on an iPad might be different from viewing the same magazine on Android. This doesn’t make sense. So why not build a Web App, instead of native apps?

Build a Web App instead

The solution, in my opinion, is to build a web app instead of a native app. Nowadays, with things like HTML5, CSS3 and JQuery, you can build a functional app, running on a browser and with perfect User Experience. It also has the advantage of having to build it just one time, without worrying about different hardware systems or OS versions. Using responsive design techniques, you can use the same Web App on smart phones, tablets, computers and even on TVs.

An App that runs in a browser has everything to better reach your readers: The user can log into it from any platform with no installation hassle and (almost) without leaving any traces which even allows him to be social showing his “magazine” in his friends gadgets, like you do with a real magazine or newspaper.

Besides, new versions and implementations are visible straight away without having to update or download. And there’s no worry about free memory to download the issues or managing subscriptions.

Drawbacks of a Web App

In my experience, many readers like to have magazines, books or newspapers available offline, to read on the plane, while waiting for something or at the bar. A Web App, by definition, is to be used online. However offline reading capability can be achieved, within certain limits, that I believe to be acceptable.

How about the differences between the User Experience for each OS? When you use different OS, you have different ways to get things done, different options, different gestures. By not using a native app, you’ll break this rules. This might not be that serious, as long as you keep it simple to use and intuitive, with generic common solutions. It is also important that you follow Internet usability standards because your users, accessing your app in a browser will rely on that kind of usability, like being able to use the back and forward button, and be taken to the homepage when clicking on the logo (or a home link), just to name a few.

So the disadvantages aren’t really disadvantages… if you tackle them the right way.

New Business Models

This approach will even allow publishers a more dynamic way to explore different business models, depending on their public and needs. For instance, you can use the usual pay-per-issue/subscription method, or pay-per-view, selling articles by subject. As long as you have a simple payment method, you’re only limited by your imagination. Most importantly, you can change the way you sell information much faster, if you feel the need.

Are people ready to pay for information? I believe that nowadays, people are starting to be aware of the fact that, what they read on the Internet might not be all true or might be biased. They’re starting to be aware that paying for good and timely information is acceptable. I think that this kind of business will start to flourish. Especially now, that you can take your computer under your arm, everywhere you go. The important thing is that what you have to offer is complete, readily available and practical.

I would even go a bit further, to say that a good Web App should feel like a club that people are willing to be a part of. It should offer good reading, good interaction, and great quality services that can’t be found anywhere else. If you achieve this, people will pay.

What your Web App should look like

Don’t just make a fancy site, give it a good and solid User Experience behaving like an app and maintaining the good features of web navigation and that everyone is used to.

Focus on reading, your objective here is not page views. The user already paid for the information, give him full attention to what he’s reading without interruptions.

No freaking ads jumping up and down. This has something to do with the previous paragraph. These days, the ads you see on sites come from ad servers that don’t respect what you’re reading about, who you are, or even your eyes. Some of them try to, but there are too many flaws. However ads are allowed on a payed web app,, as long as don’t bother the reader and have to do with your publication. They can be used, for instance, before of each article – like a full page add – but never in the article itself.

Cross link carefully, your cross-references between articles should be carefully chosen, be sure that these are pertinent to the subject in question. They are also useful to bring in a bit more money, selling a new article or issue.

Comments allowed? For this one, there’s no sure answer. It depends on your public and your content. Some things are certain: Comments should never be visible, viewing should be optional upon the action of the user; Anonymous comments are not allowed, real name is always shown. Paying users shouldn’t be bothered with commenting trolls that most of the times hide behind anonymity. Then again, as we all know, some commentators might be poisonous and they can even argue that if they’re paying they can say whatever they want. So it’s a double-edged sword. Aren’t comments always?

It’s important to choose the right platforms for companies to be competitive, sometimes it means not going after the new trend and use something that can achieve your objective on a more easy and effective way. How about you? You think the Web App is the way to go? Leave your thoughts and ideas on the comment area.