When pretty beats practical

“Wouldn’t it be cool if” is the phrase that is usually the precursor to either an amazing idea or a terrible one. I’ve no idea what the percentages to either is at this point, but I find few exceptions or middle ground in its execution. It’s a statement of blind, raw concept, and as such unfounded in its proposal. There’s nothing wrong with it per se, not all good concepts have a basis in reality, at least not in its conception. However, “wouldn’t it be cool” tends to have a funny way of pushing concepts that should stay concepts, or guiding us in ways that distract from our main goals.

I find that when design flys off the rails at an agency, its because of some sort of feature creep or request. I find that often it doesn’t come from design, necessarily, though from account managers, marketers, sales, or perhaps spinelessness towards directing a client away from an idea because we can exploit it and make more money that way. I do have to wonder about how practical any of that is. Sure, we appease the client’s tastes now, but what happen when the proposed idea no longer is in style, or if leadership changes on the clients end and they decide that they hate the work? What happens when someone higher up on the food chain realizes that the additional services and features we are proposing do not solve the main issues of the client and aren’t all that well thought out to begin with?

Read More

Flash Floods & Flood Zone

So, occasionally I hop over to my analytics and see what’s going on with the traffic for my websites, and see spikes in traffic for Flood Zone NYC. Naturally, since Flood Zone is a local site, its traffic is effected heavily by local news and events. Baseline, the site gets about 100 visitors per day, which I find fascinating considering that I really only built the site in case of hurricane related emergencies. On Wednesday, Flood Zone saw a mild spike of 472 visitors.

Read More

No, you can’t use that typeface.

Read More

So you want to be social

Perhaps the most groan inducing thing I’ve come to hear attached to damage near everything that I’ve come to work on in the last few months is the want to be social. It seems as though everyone has missed the plot when it comes to the concept of being social. Being social is not just having a twitter account or pushing a feed onto your website or on some monitor. Social is about interaction, it is about feedback, and it is about allowing users to interact with both your service and with one another.

So then, how is a Facebook, Pinterest, or Twitter feed social if I cannot contribute to it? What is the point of its existence as a Twitter feed vs as just another content bucket? Are users impressed with the fact that we have a Pinterest account? I doubt it. Right now we have new emerging technologies such as Web sockets which will enable us to easily make real time connections between what we are showing and our users. We can give them control of our monitors and websites in fun, interactive ways and not be afraid that they’re going to write a text wall of profanity. And users will find finally have an organic reason to engage with us, and not because we pester them to follow us on Facebook, or whatever.

Being social was never about having a Facebook or Twitter account, and the fact that we have allowed these services to corrupt our industry speaks I’ll of our ability to innovative, but a revolution is coming, and soon we will come to realize the true meaning of social again, user generated content, not user profiles.

Swipe gestures & placement

Something I’ve taken a shine to on my mobile and responsive websites is the inclusion of swipe gestures as interactive elements. The are easy enough to implement once you wrap your head around javascript touch events, and add a nice element of discoverable interface for users. I do not use any of them by default mind you, for example my in progress portfolio update has the ability to toggle menu visibility by swiping, in addition to simply clicking the menu button.

There are some rules and considerations to consider, however. For one, I usually do not toggle such events without crossing a certain threshold of pixels the user has swiped, and only if it is within a fairly small margin of error in the direction the direction the corresponding action takes place. Say, for example, I want a swipe to move a menu bar from offscreen on the left towards the right in order to make it visible. I would set a margin of error for the swipe +/- 5px vertically from the swipe origin, and a minimum swipe of about 20px before the interaction registers a response. Even the 20px mark I feel is a bit too shallow in my own testing and am considering raising it to 30 or 40 px.

There are roadblocks that the browsers set up, naturally. On Chrome for Android, swiping from the left and right edges of the screen causes the user to toggle between tabs, so naturally we don’t want to place any interaction that relies on the user swiping from the edge of their screens since Chrome’s native swipe would override our JavaScript based swipe commands. Both iOS and Android feature drop down bars at the top of their monitors, so we really don’t want to place anything there either since the user is likely to trigger the OS to show that instead of our content. On Android, the new default experience is to place OS interactions at the bottom of the screen, and iOS’s safari has a persistant action bar fixed to the bottom of the screen, so naturally this is a no go for our actions as well.

As I said before, I do not use these as default methods for use, rather simply as additive interface options for advanced users, and I really wouldn’t advise anyone to default on using them for anything other than completely app-like experiences, otherwise it feels clumsy.

Mobile dev and design environments

Mobile UI is one of those areas where I feel that you cannot properly design for without having devices to at least project images on to in order to test things like sizing, margins, flow, and appropriateness for the operating system in question. As a consequence, I have 5 different devices that I test and develop with in order to round things out; three Android devices and two iOS devices. Two of those are tablets, the rest are mobile devices.

When working with mockups, I usually use some screen projection software so I can just push whatever screens I’m currently working on to the device/platform I’m working with. Android is actually better with this than iOS, since they provide Design Preview, a program which clones a portion of your monitor onto a device screen. Very useful in dual monitor setups where your primary monitor has your working window, and your second monitor has a duplicate window with the image at 100% size. For iOS, I use a program called LiveView, virtually identical to Design Preview in function.

Read More

PSDs are a poor deliverable

Occasionally, I’m asked where I sit on the spectrum between design and development. I usually retort that I am a designer and that development is a means to an end. So what does that mean? Well, at present there are four major browser rendering engines on the market, Webkit (Chrome & Safari), Gecko (Firefox), Trident (Internet Explorer), & Presto (Opera), each come with their own slight differences in default styling, abilities, and bugs. To further complicate matters, we also have to design for a wide variety of devices and settings.

Why then would one default to using solely PSDs to create web design is beyond me. The are, by default, static constructions that cannot possibly have any basis on what these various engines will output. They do not consider what will happen when the browser breaks or when certain features are not present.

Read More