Posted On September 18th, 2011 Author Kyle Racki
Filed Under Design, Business, Development, 1
Just recently, a big change came along in web design; Arguably the biggest revolution since modern web standards in the early 2000's.
Responsive Design has been invented. It's a term used in new age architecture to describe buildings that behave 'responsively'. That is, they adapt or respond to conditions such as the amount of people in a given room, for instance. They will automatically change heat, air and even room size (yes, the walls expand and contract!) to accommodate more or less people.
And just like Responsive Design in architecture, when it comes to the web, responsive design allows websites to no longer behave like static online brochures that scroll, but rather they adapt by expanding and contracting, resizing themselves to appropriately fit a variety of screen sizes. So for example, a website might have five columns when viewed on a 52" wide screen, but when viewed on a laptop it may scale down to three columns, two on an iPad and down to one column when viewed on a smart phone.
The best way to illustrate this is by viewing this gallery of well-designed responsive sites. You'll see four views for each site, from wide screen down to a small screen. Pretty impressive, huh?
The best part is, designing sites to be responsive does not add a lot of size, scope or complexity to a project. Sure, it adds some work for the designer and developer. But really in the grand scheme of building a website from start to finish, building it responsively is not all that time consuming once you know how.
Now, like all things in life, there's a catch. Building a website with responsive design is not a replacement for a mobile app or site. There are subtle but key differences.
Depending on your business, you may find that you actually need a mobile web application instead of just a website that scales to a variety of devices and screen sizes. The reasons are:
-
Functionality
-
Weight
-
Business Model
1) Functionality
The trick with responsive is that it's all in the layout. When a user is on a smart phone, they are looking at the exact same site as on a desktop computer, but the CSS or style sheet is scaling the site visually to look better on a mobile device. It's kind of like window dressing. The HTML page is exactly the same.
Now you may find that on a mobile device, you want to do more than simply make the website look different. You actually want to take advantage of a mobile device' hardware. You may want to let the user shake their phone to randomize a search, upload photo's through their phone camera, plot their location through GPS. These are things you'll actually have to build specifically for the mobile device - you obviously don't want this functionality for users on a desktop!
There may also be a lot of functionality on your main website that you want simplified and altered significantly on the mobile experience. If you have an iPhone, think of how different the main Facebook website is from the iPhone app version of Facebook. On the latter, the functionality is simplified significantly from how you would use it on the website (no instant messaging for example).
An added benefit of mobile websites is that you can include a link at the bottom of the site "Click here to leave the mobile version". This way, you can present your user with choice so they default to the mobile version, but can always load the desktop version on their phone if they so choose.
2) Weight
With responsive, again, the HTML page is exactly the same regardless of what device you're viewing it on. On a mobile device, every bit of information a user has to download counts - because users often have slower internet connections and their phones have less memory than a desktop computer.
So if your main website has a lot of intensive graphics, videos, and sounds that a user has to download, responsive design is not going to change that when the user is viewing it on a smart phone. A mobile web app on the other hand is a completely different site, made specifically for phones, and there are a lot of techniques developers can employ to make the page as fast and lightweight as possible.
I won't get too much into the technical stuff here, but it would include using HTML5 local storage techniques, limiting the amount of http requests, keeping Javascript libraries as compressed and minimal as possible, loading smaller images and a whole lot more.
3) Business Model
If you have a blog, chances are your website will be used the same way regardless of what device you're user is accessing it with. Blog's are always for finding and reading content, and sometimes commenting on a post. In that case, responsive design is probably a perfect solution, since it allows the content to be optimally viewed on a phone.
Now on the other hand, if your website involves a lot of user functionality, like the aforementioned Facebook, which includes adding photos, tagging pictures, posting content, finding friends and more, it's much better to design a specific mobile experience that varies greatly from the desktop experience.
And you don't have to be as big as Facebook either. There are a lot of companies whose desktop websites wouldn't translate well as merely a shrunken down mobile version, but would benefit from a true mobile app. Some examples may be banks, movie theatres, restaurants, concert venues, e-commerce stores, social sites... the list goes on.
The other factor to consider too is whether or not you want to sell your app and/or make it available on the iTunes Store or Android Marketplace. If you do, responsive is not going to work. On the other hand, you could make a native iPhone/iPad/Android app, OR build a mobile web app using open standards and using the insanely clever PhoneGap, you can package your web app as if it is a native app. This will enable you to use the phone hardware like contact lists, voice and camera, and will also allow you to sell it on app stores.
Closing thoughts
As a general rule, I like to think of it like this: If your website is meant to be viewed, Responsive Design is an amazingly simple technique to please visitors on your site (in fact, I think that building in Responsive is the first place every company should start when they want to dip their toes in the mobile landscape).
On the other hand, if your website is primarily meant for users to interact with (games, accounts, videos, social, e-commerce etc.) then a mobile web app is an important investment worth making.
Posted On August 23rd, 2011 Author Amy Wheaton
Filed Under Headspace News, Design, 3
Over the spring and summer we’ve been busy working on a new Headspace site, which we’re pleased to unveil today. One of the biggest changes is that our new site utilizes responsive design – it’s accessible from smartphones, tablets, computers, wherever users happen to be. We also placed more emphasis on showcasing our work, our team, our process and our tools of choice.
The old saying when it comes to agency and studio websites is “the cobbler’s children have no shoes” – typically, paying client work comes first (and it should!) Our new site has been a work in progress for some time, and everyone on the team has played a role in getting it ready for launch, from design and programming to copywriting and testing. The site was built in ExpressionEngine 2.0. It also makes use of HTML5 elements, CSS3 (that's where most of those fancy shadows, transitions, rounded corners and gradients are coming from) and JQuery for sliders and modal dialogue windows.
Some of the design elements will look familiar from the old headspacedesign.ca, but we’ve implemented a fresh take on our branding and it figures prominently on the new site. Big thanks to Laura Cosham of Cosham Illustration for her help making us look good and to Kyle, Ricky, and Amy for their work getting everything ready for launch.
We have more features planned to roll out over the next couple of months, so check back often for updates!
Posted On March 15th, 2011 Author Kyle Racki
Filed Under Design, Business, 0
Over the years, we at Headspace have developed a pretty tight process for creating websites. However, I find in some cases, clients have a very fuzzy idea of what they want out of their website in the beginning. Even after our in-depth planning stage, clients will make fundamental change requests to their website very late in the game, and often at a time it will impact the budget and timeline of a project.
So how do we avoid this? First of all, let’s examine our planning process (which is probably more-or-less similar to many web design company’s processes):
After a proposal is accepted and our client is ready to move ahead with us, we schedule a kick-off meeting. The goal of this meeting is to:
- acquaint the client to the project manager and lead designer
- review the needs of the project and what came out of the RFP/Proposal process
- discuss really specific details that will help form the website strategy.
After this meeting, we internally compile each others’ notes from the meeting (as soon after the meeting as we can, actually). We then deliver 3 important pieces of documentation to our client:
- A Statement of Work, which in high-level detail, indicates what we will perform, what the agreed upon fees are, and some other legal mumbo-jumbo which serves as a contract between the two parties.
- A Strategy Brief, which outlines in more detail what we want to achieve with the website and how we plan to achieve it. It includes parts of the kick-off conversation, such as target-audience, competition, conversion goals etc.
- A Function Spec, which includes a site-map (showing all of the pages views on the site), a wireframe for each main view (which shows where we will allocate each content block visually on the site without getting into the look and feel just yet), and a written, technical document that verbally describes what happens on the site.
The function spec is particularly important because it serves as a technical reference between the client and developer, and sums up the “scope” of the project. In other words, if the agreed-upon spec defines a part of the website functionality in a drastically different way than what the developer delivered - the developer would be responsible to correct it. On the other hand, if the client asks for something that wasn’t defined in the spec, it will probably be considered “out-of-scope” meaning it would require more time and budget to include. This protects both parties by making sure that both agree upfront how the site will work and honour their commitments.
Rushing along
At this point, when the 3 documents are delivered, we expect a LOT of feedback from our client. After all, like the blueprints on a house, these documents are essentially paper-versions of their website. This is the part of a project where you can really let loose with ideas, but it’s also where the project should get very real. All the ideas are now on the table, and we are planning in precise detail exactly what the website is and how it works.
I find that often clients will hurry this process along and agree to virtually everything assuming that this is the boring part so saying yes to everything will make it finish faster. In reality, this is the part of the project where the client has the most control and room for input.
A cold, hard shock
And I’m sure you know how the rest goes; Client reviews the design, makes changes until they approve it, we build the site, load the content and show them the close-to-finished website… and then… suddenly…out of nowhere there is a massive list of changes back from the client! These changes may include a massive overhaul of the site-map and wireframe, along with a completely re-thought-out list of fundamental changes to how the site actually works. And naturally, they aren’t happy to be told that now it will cost more money and it will delay the launch.
Why it costs more
This might seem unfair to some people, so it often helps to compare the building of a website to the building of a house. If you hire a contractor to build your house, and you sign off on the blue-prints and give them the green light to build, but then after the house has been constructed, you decide you don’t want the bathroom on the main level, you want it moved upstairs—do you think that’s going to be a problem? Of course! Now walls need to be knocked down, plumbing needs to be completely re-worked - this is going to cost more money and you’re going to have to wait longer to move in.
Or how about if you told an interior designer you wanted marble counter-tops, waited until she installed them, and then decided you want granite. Obviously, it’s going to cost more to change now. So in a similar way, decisions you make early on when planning your website are going to affect the final outcome of what gets produced.
But what can help you if you need to commission a company or freelancer to build your site?
Know what you want
First, know what you want before you even pick up the phone. Now that’s not to say that you need to design the site yourself - the last thing a web designer wants is to be handed a design from a client and be told to make it look exactly like that. Definitely remember that you’ve hired professionals, so be prepared to accept their advice. But at the same time, remember that this will be your site for years to come and as the website owner, you need to be the champion of it, so it’s your job to know what you want and the web teams job to help you get there in the most practical way.
So come to the kick-off meeting armed with information; Why you need the site, who it’s for and why they need it, how you plan to fulfill users expectations, when you need it launched (which is usually different than when you want it launched), how much you have allocated for spending, where it will live and so on.
The wonders of napkins
Better yet, come to the kick-off meeting with doodles. The wonderful thing about paper is that it can change. On paper, you can change a search bar to a list of check-boxes instantly, or you can remove an entire section by simply scratching it out. If you have sketches of what you want, no matter how crude they may be, they will help not only your hired web experts know what you want, they will help you know what you want because you’ll get an instant idea of what works and what doesn’t. If it doesn’t work on paper, rest assured, it won’t work in code - and all it cost you was a napkin to find out.
Once your web team understands all of this, they will be able to tell you in realistic terms what is feasible, and if necessary, propose alternate solutions.
We launched a website recently for Tattoo Tree, an online resource for tattoo artists. Our client approached us for a proposal with complete hand-drawn sketches of the entire website, and a document outlining how she wanted it to work. We didn’t always see eye-to-eye on how things should work, and there was some compromise on both sides, but the point is, our client knew what she wanted, had a vision, but was willing to accept our advice - and you know what? It was one of the most smooth projects we worked on, and we launched a fairly complex website in less time than we would have launched a simpler site whose owner couldn’t make a decision.
Look at examples
9 times out of 10, if something hasn’t been done already on the web, it’s because it’s impractical. So to get a good sense of how your website can/will work, look at examples of good websites and see how they allow users to accomplish certain tasks. Show them to your team, and let them bring other examples to the table. You can find beautiful websites on sites like Site Inspire and Drawar.
Write your content now!
Too often, clients wait until the site is built using dummy copy before they even think about what content is going to actually end up on the site for launch (having no copy ready in time is also the #1 reason why projects don’t launch on time).
If you have hired a web copywriter, make him or her part of the development team early on. The writer is as important to the success of your site as the designer and programmer. Think of the content as what the designer will design the site around. It’s why users are actually coming to the site in the first place.
For some reason, clients seems to understand this concept when getting a print piece designed, they provide copy to the designer up-front whereas websites often get misinterpreted as being blank templates that will work with any type of content. In some ways that’s true, but the sooner you produce actual copy/images/video, even if you plan on changing it or adding to it later, you will assist the designers and you will get a better grasp on what the final product will contain.
Content takes way longer than most people think it will, so starting immediately once a project begins will ensure you give yourself a good head-start and actually get the copy done in time for the designer.
Obsess over the spec
Finally, when your web team shows you a function-spec, pore over it. Read it like you would read the blue-prints to a house you are building. Visualize it. If you don’t understand parts of it, ask questions. Sketch it yourself as you read it. If it doesn’t make sense, ask the site planner to explain it further over the phone or in person and if necessary, provide follow up wireframes or examples on other websites.
Don’t make any assumptions at this stage thinking “Of course the developer will remember to include feature A, because every website I visit has this feature!”. If it’s not expressly written down, ask for it. If the spec doesn’t mention anything about RSS feeds, don’t assume there will be one. If it’s to be included in the scope, ask for it now. If the spec mentions a list of search results, don’t assume they can be sorted alphabetically by the user. Think long and hard about what is outlined.
Also don’t think that because you mentioned something about a social widget in the kick-off meeting that it’s automatically within scope. Things get missed in conversation which is why the notes are presented back to you. The spec is a summary of what conversation took place, so if you feel something is missing, now is the time to voice it.
These are just some suggestions to make your new website the best it can be, and at the same time, keep it on-budget and on-time. As the saying goes, measure twice, cut once. Your web developer’s will thank you for it.
Posted On March 3rd, 2010 Author Kyle Racki
Filed Under Design, 2
If you are a web designer or work with web designers, you know that content is a real challenge when it comes to producing a quality website. Mainly because content is of critical importance, after all, that is why users are there in the first place. However, many web teams ignore content until the very end of a web project. Why?
In my experience with print design, I often had finished, client-approved copy before I was even briefed on the design. When it came time for layout, everything I was using for content was real, and I would get annoyed if any last minute copy changes came in after I spent hours kerning and massaging my lovely blocks of text.
With the web however, most of us have gotten used to the lack of finality with our designs. A website is never truly finished, unlike print, where the piece, sooner or later get’s printed—and then it’s done and I’m on to a new project. I think because of this inherent flexibility in the medium of the web, it has caused website owners to neglect copy, because they know it can always be done and added later, usually in a content management system.
In a perfect world, content should be available to a designer before he ever begins designing, just like the good old days of print. Would you agree?
But let’s get real
I have to say, while I generally would prefer this, I know that 99% of the time, it’s never going to happen. Time is money, and as long as I am waiting around for a client to write content, or even have a professional writer get copy written and approved by the client, I am wasting precious time that could be spent developing a look and feel for the website, or constructing the back-end.
Also, there are times where it actually doesn’t make sense to have all the copy written. Sure, things like calls-to-action, headlines and home page copy is great to have well in advance, but often it can be easier and more freeing to design content once it’s in place and on the page. Especially user-generated content cannot possibly be written in advance of the website design, so lorum ipsum will do just fine. And of course, in many other situations, content is not made up of words at all; It may be in the form of video or images, in which case, placeholders will have to make do.
Impossible to design without?
There have been strong comments made by very established web professionals who decry that good design can only be created with content already developed. That content is king and design is what the king is dressed in. And while I wholeheartedly agree, I also believe the being able to design a quality website can be done before every piece of copy is written. If you know the business (or non-business) goals of the website, who it’s target is, the site-map and information architecture already established, and you know what kind of copy will eventually be in place, then who is to say an effective solution can’t be designed?
Do you agree with me, or think I’m out to lunch? Let me know in the comments below.
Next Page