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…

Touch Specific Media Queries in CSS4

Proposals in the works for new media queries specific to touch enabled devices. Examples include pointer, which will differentiate wether the device has a fine or coarse pointer (finger vs mouse) and hover, which would say if the device supports hover states. I can see this being helpful and useful for building mobile friendly sites where you want good control over interactive elements with hover states.

Embedded Link

CSS4 media queries to tackle touch | News | .net magazine
Shift to input concepts rather than explicit lists will benefit developers