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?
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.
No, you can’t use that typeface.
I constantly get mock ups that use typefaces that cannot be used on any of the project that we’re working on, and I always have to go back to the visual designer and explain typeface licensing. Once I was told that type licensing “wasn’t a big deal” and that we could just change the name of the font and get away with it. Well, you might not, and I don’t want to open myself up to the same sort of litigious fury NBC faced in 2009 from Font Bureau to the tune of at least $2 million dollars in damages. With that said, here’s your primer in font licensing.
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
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.
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.
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.