On Going Responsive (responding to Where to Start)

trent-walton-thumbI needed to write this up about going responsive in response after reading Where to Start (by Trent Walton of Paravel) about getting started with responsive web design. Thanks for sharing your thoughts Trent, I agree whole heartedly. In my experience it is the same. I wanted to share his post and also add my commentary for the parts that I really think Trent is spot on. Some dynamite points.

Longer On-Ramps Have Benefits

I believe Trent is talking about the on-ramp of beginning to create responsive sites. But when I first read the headline about the benefits of a lengthy on-ramp I was thinking about the ‘pre-design’ work that goes into a website. All that work that comes before design and has always been super beneficial to proceed thoughtfully with content strategies, sketching, architecture, wireframes and prototypes. This ‘on-ramp’ stage is even more important in RWD. The time well spent upfront before getting into designs and especially programming really really pays off. Think through all scenarios and purposes and requirements of the site before you hit the ground running. Or else you may get to the finish line realizing you forgot the baton. This is so important concerning responsive from the beginning, when making wireframes for example, we really must think about the available space to render the content.


It’s no longer for prescribing exactly what a site should look like. Instead, it’s used for quick layout exploration and asset creation. As for which view/layout size one should start with, I don’t think it matters. Remember, a single photoshop comp will only express a sliver of the layout potential a fully-flexible responsive site has. It’s impossible to accurately assess a responsive layout in .JPG form.

Yes! Agencies (and clients alike, but I feel that the agencies and developers need to lead the way) need to move past the relic ideal of pixel perfect websites. Not that they should look bad, but they should not all look the same. The nature of the web is to be flexible, right? Let’s embrace progressive enhancements and move on when old browsers don’t see it as nice as current browsers.


All my values are relative (em, rem, etc.) and based on the 100% 16px base, so I can move code around without losing proportion.

Yes, Again! We need to be relative and fluid all the time. We’ve all picked up some bad habits along the way, but RWD can be seen as a good excuse to remove these.

Breakpoints should always be dictated by our content. Not by `insert popular device of the day`. We should be starting to learn that we shouldn’t rely on any specific device or measurement, because they change all the time. Let’s FORGET device resolutions at the media query stage. These dimensions should be thought out earlier and influence our content strategy. Nothing wrong with using 480 as a breakpoint if it makes sense for your content, but don’t force a square peg into a circle hole. Who knows, next year all these circle holes may become triangles (or spheres) and then we’re stuck shoehorning the square we started with again or starting over. Weird analogy, but I’m just going to let it be.

Regarding Grids, I agree here too. It seems that when using a grid for Responsive Web Design I feel constrained to the grid more than I should. Plus I think it takes the fun out of the process of laying out the content as prescribed. I love the idea of ‘content coreography’ too. It really adds to the sense the required craftsmanship by the developers/designers behind the site well done RWD. It also makes me think of site creators as the directors who layout and present data and lead the story telling of the site.

I’ve said it before, but I’m constantly excited by the web design industry because as it is such a young field, we are still making up the rules and discovering as a community what processes are best. At the same time, the technology driving the field is changing so fast that just when we start to settle into a routine it all gets flipped on it’s head and we’re reconsidering everything again.

Please read Trent’s full article as I’m sure it’s packed with good nuggets for you too.

When making the transition to building responsive websites, the hardest part can be getting started.

I get my fair share of questions about how to choose a direction and chart out the first few steps from industry comrades and potential clients. It can seem daunting, so I thought I’d attempt to sum up a few of my own current thoughts on the matter.

via Where to Start | Trent Walton.

Android App Development Keystore for Beginners

Getting into some mobile app development for Android and I was unprepared for the keystore file that is required to be included in the apk file. Using PhoneGap Build to compile my app the interface requires a keystore file uploaded.
Screen Shot 2013-02-05 at 1.55.07 PM
After some digging on google it seems that the most common way to create a keystore file is by using some Java IDE like Eclipse, but the whole reason I was using build phonegap was because I didn’t want to fool with one of those. I finally pieced together what I needed with a few posts and wanted to put it all together to help at least myself in the future.
phonegap keystore upload alias
Luckily with a mac apparently you can do this with terminal! Following a couple tutorials, I managed to create a proper file, and going through a few steps to set the expiration or validity and the alias.

To create a keystore on mac OSX, first, open terminal. We’ll type keytool and then there are some commands to type and our keystore file will be created. -genkey (generates the key), -v turns on verbose mode so full details will be output, -keystore tells it what to name the actual file (it actually saves to the root directory, I’m sure there’s a way to specify location somewhere) and you type the filename (including the .keystore file extension). Once you enter this in you are prompted to fill out your name and company name and info like city, state and country. Then it verifies everything and you must type ‘yes’. Then it will prompt twice for a password, remember this it is how you will update/rebuild your app.

keytool -genkey -v -keystore file_name.keystore

This got me going but I had to do some back and forth to know some other requirements specifically for android marketplace and working with PhoneGap. PhoneGap Build was asking for the alias when I uploaded the keystore file to build my project, but I hadn’t set one. I had no idea what it would be and after trying my name and company and even filename I had to do some more digging. We can in fact set the alias name when I create the key with the -alias command. It doesn’t matter what this is, you just have to remember it. I think of it like the username to my previously entered password. The default is set to mykey, so you don’t really need to set it. This got me through the Build process with PhoneGap, and then I set up my app on the android marketplace (after paying the $25 license fee). Once I uploaded my first apk file I was getting errors regarding the keystore again. The marketplace was telling me that the validity was not large enough. The validity (or expiration) of the key by default is set to 90 days, but the marketplace requires at least 10000 days… quite a difference, no? So to set validity we add the -validity command followed by the value of 10000. Once i did this round I re-uploaded the keystore to PhoneGap, rebuilt the app and resubmitted to the Android Marketplace and it was accepted! Wow.

keytool -genkey -alias alias_name -validity 10000 -v -keystore file_name.keystore

terminal creating a keystore file for android apk

I hope that helped someone. I’m surprised that the PhoneGap doesn’t aleviate some of the pain in this process. Since the whole point of using Build PhoneGap is so that I don’t have to set up an IDE or get complicated. A simple online keystore gen process would go a long way, and better yet if they automated it somehow!

Did I miss any steps? Are there better ways to do this? (I sure hope so) Share a comment.

Also, check out the app I made from web technologies html, css and javascript with the help of PhoneGap. It’s a quiz that tests and teaches users facial recognition of leaders at church. It’s called LDSQuiz and shows images of modern day prophets and apostles and asks you to identify them by name.

Reference links that helped me:

Style Tiles

Style Tiles are about designing a system or guide to style a website rather than full comps and mockups. They really come in handy when talking about Responsive Web Design since it frees the designer from having to think about different layouts (as much, it should already be addressed in the wireframe stage). The designer can then focus on thinking about styling the elements and setting rules for a system that will be followed throughout the rest of the site. I really like the thought that style tiles are for when mood boards are too vague and design comps are too precise. Though, It really makes me think about designing a style guide rather than designing a webpage. Then the developers building the website can follow the guide dictated by these style tiles and make simple future-friendly/object oriented/SMACSS/modular css (or sass/less if you prefer). This also leans towards the late trend of moving more of the web design process into the browser.

Ethan Marcotte refers to static comps during the responsive design process as a “catalog of assumptions” Style Tiles are the perfect complement to that catalog, whether it be in place of comps or to reinforce visual themes. Style Tiles don’t imply dimensions nor device; only that the design will be digital.

In addition to Style Tiles, “Component Style Guides” can help with carrying a particular style through specific functionality without designing full web “pages.” These guides are very helpful for responsive designs across a wide number of devices and for implementing design systems for a CMS platform.

Develop a design system rather than designing fixed-width pages.

via Style Tiles.

I’m constantly excited by the web design industry because as it is such a young field, we are still making up the rules and discovering as a community what process are best. At the same time, the technology driving the field is changing so fast that just when we start to settle into a routine it all gets shook up and flipped on it’s head.

How do you see style tiles benefiting your process? Have you used style tiles in a project?

Adding Viewport Meta Tag via WordPress Theme Functions

Add the viewport meta tag with a WordPress hook via your theme’s functions file to allow responsive web design and mobile-friendly themes

meta-viewport-thumbWith all the responsive web design activity over the past few years, I hope that any theme or site we work on we’re able to make responsive to some extent. An important part of making a web site responsive is adding a viewport meta tag to your html. Without explicitly stating our viewport, the mobile browsers will scale down the website to fit into their ‘viewport’. This is a good thing, since if it was a full website and the browser didn’t scale it down, you’d only see the top left corner, or some small section of the site. This viewport was introduced by apple for iOS and has spread to most mobile devices since. There are viewport properties or parameters we can set with this meta tag such as width and scale and can even use some device aware variables (like ‘device-width’) to set these values.

A WordPress Meta Viewport Hook

I usually end up using the following hook to add a viewport meta tag to my head in wordpress. I set the viewport width to match the width of the device. Then I set the initial scale to 1. Some go and set the maximum-scale to 1 as well. This would prevent users from zooming in on your site. I advocate that we should allow users to zoom if they wish since it is a gesture they may be used to and may still need (no matter how nice your RWD is, they may need/want to see it bigger). RWD is about giving the user a better layout for whatever device they are on, not restricting how they view it.

[cc lang=”php”]
// Add viewport meta tag to head
function viewport_meta() {

Mobile Strategy and the Case Against Apps

Great points about apps and the web in this article.

Apps compete with the web for dominance over where people get their content. Apps as games and tools are perfect, but apps for content are not. Content is best on the web, because the web is built for sharing content. The web is open! The web is consolidated and instant and accessible (meaning that any device/browser/screen size/location/etc can already access the web and you can update it anytime and all users see the update instantaneously). The web is also accessible via the defining url. Meaning that it’s a required standard that all assets and bits of content have an address. You can take this address and share it and return to it easily, apps – not so much. You want to share an experience or idea from an app with a friend (sure, some have a process built in), you first check to see if their device has this app available, they want to go through the steps of finding the app and then installing it (likely having to pay money) and then you send them a link have to explain how to get to where the magic happened.

Newfangled, a web agency I respect for being very smart has a great article about this. It was then moved into the basis for a chapter in their ‘The Strategic Web Designer’ Book. I highly recommend them both!

Planning a Mobile Strategy.

HTML5 Is Ready – Rebuttal to Facebook’s native app

Here’s a great “HTML5 Love Story” about the team at Sencha, who is passionate about using proper technologies for the one open web, who knew better than to trust that the failure of Facebook to create a reliable HTML5 app for users was because HTML5 wasn’t ready (as Facebook claimed). They built this demo to prove that HTML5 can do all that the now gone native FB app does and faster. The trick is you have to know what you are doing. Something it seems, FB doesn’t. Ready the full story and watch the comparison video: The Making of Fastbook: An HTML5 Love Story | Blog | Sencha. Or go try it yourself. Visit http://fb.html5isready.com on your favorite mobile browser.

When we started what became Sencha, we made a bet on the web: a bet that modern application development didn’t need anything except the browser, a great set of frameworks and a great set of tools. With those three weapons in hand, we knew developers could build applications that would delight users. The advent of HTML5 upped the game and it gave developers even more tools to let them treat the browser as an application development platform and not a page rendering engine. Developers sprang at the opportunity and unleashed a torrent of apps — on both desktop and mobile — that leveraged the new HTML5 capabilities to build amazing applications using web standards.

So, when Mark Zuckerberg said HTML5 wasn’t ready, we took a little offense to the comment.

We thought to ourselves: HTML5 can’t really be the reason that Facebook’s mobile application was slow. We knew what the browser on modern smart phones was capable of and what kind of rich capabilities HTML5 offered. We saw the latest generation of mobile devices — running at least iOS 5 or Android 4.1 — push ever increasing performance and HTML5 implementation scores. But perhaps most importantly, we’d seen what our customers were building and the amazing things they were creating using HTML5.

I totally agree with this sentiment and believe that native apps are the new flash to the web. They are fun and seem to be the way, but give it a few years and these native apps will quickly give way to web based apps that are browser based and offer speed and flexibility and consistence to the web experience. Sure, flash can do things that html still can’t. But I’m pretty sure no one would want to build their whole site in flash today. They would put the parts that need to be or the parts that belong in flash in flash and let the rest be standards compliant open web. Facebook has essentially built a flash based website for phones to access their website content. They will have to maintain and update this separate from their “real” version.

Our smart phones are helping us converge our devices, as in we no longer need a phone a camera a gps a notepad a … But it is not helping us converge our internet or content. We currently need to use a website in one way at our desk and another way on the go. Websites and the internet should have the same capabilities and the same uses no matter where we decide to use it. Sencha is showing us that, built correctly, HTML5 truly is ready to handle many things that belong in the browser rather than in a native app. We should never need to download a native app to access website data that we normally would just login at our desk. That’s inefficient, divergent and complicated. It’s against the openness and standards everyone preached and pined for and indeed “won” when flash-haters succeeded in ousting flash from mobile browsers. I actually respect Adobe for finally pulling the plug there because they too, believe in the web (and at the time, I was a full-time flash developer). I believe in the web too and that’s why I call it the one open web.

Web vs Mobile – For The User

I agree with this idea from Ryan that the web has big advantages. I am constantly hearing stats and projections that Mobile is taking over. And sure, I agree that I use my phone to browse more sites, but when it comes down to it I’m just casually browsing – not working. I love the post he’s links in the first line: Vibhu Norby has a detailed post on why his startup is pivoting from mobile first to web first.

Vibhu details that he’s done the mobile startup thing and has learned from the complications. He explains that most of these have been solved in the desktop browser already and a lot of it relates to usability.

Another big point is that mobile apps must be installed (actually they must be found, installed, opened and setup), whereas a web app can be as simple as a link- click, and then the user is already using it. Adoption is much easier on the web.

And even another point is updates and testing and whatnot. YOu can do various tests and even update the whole app relatively fast on the web. There is the one version to support – the live one. While with apps, you can’t do much in the arena of testing and updating is sluggish plus it relies on the user to update (some don’t know how to update and even less care).

I think a web app that is mobile friendly wins. You can give mobile users access, but they aren’t stuck on mobile. They can use it anywhere. While so many are talking about responsive design and produce sites that are device agnostic mobile apps are very device centric.

I’m a fan/advocate of future friendly at least, and strive for future proof (although I understand that’s near impossible). I also hold that there is ONE web and mobile myths.

Web versus Native Economics and User Adoption | Ryan Stewart – Mountaineer Coding.

Apple "support" with fixed position layouts

This really echo's the reasons why I still have trouble with the 'thoughts on flash' mentality (although, I know flash is irrelevant here). It's similar in that there is this self proclaimed 'support' for html5 (making needing flash irrelevant)… but in real life the devices are far from supporting HTML5. Support to apple and support to developers is a totally different story. Even many simple things that are HTML5 become very difficult in developing for iPhone, iPad or other iOS devices. Here's an example of many issues that result in attempting to use features that iOS claims to "support".

Embedded Link

Issues with position fixed & scrolling on iOS
With the release of iOS 5, fixed positioned layout is said to be supported in MobileSafari. The word supported needs to be taken with a pinch of salt, because there's all kinds of issues which I i…

Josh Clark responds to Jakob Nielson's Mobile Stance

Nielson recently stated that he thinks we should keep building a mobile version of a site that is trimmed down and optimized for mobile, and a full version. This contradicts the growing momentum in the industry regarding among other things Responsive Web Design. Josh Clark, another expert in Mobile and Usability, correctly dissects Nielson's stance and explains why he's seeing things backwards in this article at Net Mag.

Embedded Link

Nielsen is wrong on mobile | Opinion | .net magazine
Designer, developer and mobile maven Josh Clark tells us that rather than stripping down, we should be asking how we can do more with the mobile experience

Flash Gaming Technology – Notes from Lee Brimelow’s Adobe Presentation

Here are my notes on the presentation from Lee Brimelow of Adobe at the Atlanta Adobe Users Group Meeting: http://www.meetup.com/Adobe-User-Group-of-Atlanta/events/56200162/

What is flash for? Doing things the browser can’t! If you can use HTML5 then do it. Learn about it and learn the capabilities and know when to use what tool and when they are appropriate. It might not be easy, but it is where the industry is moving, don’t hide from it! If you want to do things that are to advanced for the current standards and browsers, then flash is most likely where you need to be. Adobe will always position Flash to be ahead of what is possible with browsers.

While you can do some gaming in browsers today, flash is now positioned to be the best solution for game development. It even can compile to native apps for ios and many successful apps have done so. Adobe has put in a site to showcase these games at: http://gaming.adobe.com

Adobe has a new partnership with unity. See example game: Angry bots.

Console sales are declining. We have so many other outlets to game: browsers, social, mobile devices… Soon professional games will be via Facebook and browsers.

Facebook angry birds game built in flash using stage 3D.

New gaming features:
Mouse lock.
Right and middle click events.
Concurrency, multi threading for player. Yo will not lock up with intense calculations.
Native extension Burls and extensions.

Sprite sheet exporter!
Create js exporter, via Grant Skinner
Html 5 export to canvas a vector art.


11.3 – latest flash player
full screen keyboard input.
Background auto updates.
Audio streaming via net stream.
Improvements for low latency audio.
Stage 3D progressive texture streaming.
Lzma compression sort door byte array.
Native bitmap encoding to png and jpg.
Bitmap data draw with quality
Frame labels.

Air specific
USB debugging for ios
Native ios simulator support
Enhanced background support for ios
Android 4 stylus support
Mac app store support

Dolores, upcoming updates
As workers
Advanced profiling
Better sort for hardware accelerated video cards

Refactorizing code base
Work on as virtual machine
Many action script language updates: stringent static typing as default, hardware oriented numeric types, type inference…