What’s Essential to Know about SVG

SVG is a relatively new technology that allows for improved rendering of image-like content. It’s a preferred method for adding artwork to mobile and web apps because it performs faster than traditional jpg and png images.

SVG are essentially vectors – you can increase and decrease their size without losing quality (using code)

SVG are better than icon fonts because: they are image tags, which makes them better for accessibility and they have more controls (e.g., class name).

Apps are built using templates. Here’s how to templatize SVG:
use inline HTML, and wrap the SVG in a DEF tag, as DEF prevents it from rendering. You can use it one time and then point to it in the templates. SVG is rendered in the DOM, so there’s no HTTP request (HTTP requests slow apps down) – then use CSS and JavaScript to make it increase or decrease in size, animate, etc.

cautions:
1) a PNG might render faster if the SVG has a lot of vector points – thus SVG is more for boxier artwork, such as charts and graphs or logos that don’t contain a lot of complex lines

2) SVG needs fallback support for Android 2 (and IE8)

based on LukeW’s notes from C.Coyier’s lecture:
http://www.lukew.com/ff/entry.asp?1921

icon set in this artwork can be found here:
http://graphicdesignjunction.com/2012/10/25-free-vector-icons-pack/

My Mantra for Mobile Design

There’s a lot of mantra in discussing mobile, such as ‘keep it simple’, ‘feature rich, user poor’, and ‘remember the 80/20 rule’. With such competition, i’m hard pressed to think of a new catch phrase to describe the process of mobile design.

I suppose if i was using mobile to type my mantra, it would come out in the form of a short text character burst: ‘delight them with simplicity and efficiency’.

Ok, so I guess I just wrote my mantra.

Well, now that i’ve written it, i have to consider how to advise accomplishing it. One thing that can’t be omitted – so we might as well start there – is knowing our users.

Of course, it’s easier to know our users if we already have an existing product. Then again, it’s easy to assume we know our users because we have an existing product – and the tried and true response to assume is don’t assume, or you make an ass out of u and me.

So how do we really get to know our users? *User interviews is irrefutably the best way. However, analytics helps too. For those with an existing product, examining the analytics to see which 20% of our features are being used on mobile devices is a primo place to start.

Then there’s the startups with a unique idea – they don’t have users yet. Therein lies the benefit of not having to edit somebody else’s work, i.e., you can start from scratch. Have you ever been handed a document that’s been authored by others, and that you have to edit? The task can be overwhelming. It’s like inheriting a code base developed over several years – versus creating the whole application from scratch. Or a piece of furniture from Ikea – and being told to add onto it, but make sure it matches.

My advice? Go Japanese – design, design, design – add layer upon layer upon layer – then start taking away, stripping down, removing, re-shuffling – heck, throw it away, breathe, then start from scratch. Ultimately, you’ll enjoy the process because you’ll be constantly problem solving – and you’ll wind up with something so simple – and efficient – that it delights. The quality will surface in your work, while the waste will get siphoned down the drain.

This Japanese design process i’m referring to applies to whether you’re re-writing an inherited design; or starting from scratch with a new one. In the case of a code base, Git Hub is our hero – and in the case of a tech spec, I simply duplicate my document and keep a series of sequential revisions in Google Docs. (For you Ikea builders, you’re on your own).

In summary, when designing for mobile, in order to ‘delight them with simplicity and efficiency’, we have to understand our users through user interviews and analytics – and we have to iterate by building and tearing down, forgetting and rebuilding – over and over again. As a result of our design process, we’ll understand our product so intuitively that we’ll be able to serve up it’s good parts and omit the rest. In return, our users will feel delight for the efficiency in our design and (hopefully) fall in love with our creation.
*note: in that we can’t user test without user interviewing, I’m bundling user interviews and user testing into the one term user interviews