2014-12-12

Web designers: consider using a bad monitor

This post originally appeared on the Storm ID blog.

That's an odd thing to suggest, isn't it? We digital designers love us some shiny tech. From Retina MacBook pros or the new 5K iMacs to the latest hi-res displays from Samsung or Dell, what we view our work on is important to us, for better or worse.

There's only one problem: most people don't have fancy monitors like ours. The majority of our users have average-to-bad screens to view our beautiful designs on. That subtle grey you've used is lovely, but on that 5 year old, burned out, 19" Dell monitor that John in Accounts has, the grey looks white like the background, and your carefully planned visual hierarchy can fall apart and become confusing.

My nice screen and my bad screen, together forever

A few years ago I acquired an old 16" monitor from a cupboard, to be a second monitor for my 27" iMac. I tell people it was a place to put my email client and browser's web inspector while I worked on my main screen, but I think I actually wanted to stream the Ryder Cup while I worked one Friday. It is a handy place to put my email, web inspector, Twitter, Spotify and all that other stuff that helps me work but isn't actually work.

More than that though, I very quickly learned it was a great way to test designs. This monitor is small, low resolution by today's standards, has never been colour corrected, isn't nearly as bright as it once was, and has a couple of dead pixels. It's crap. But if I can put designs (created on my lovely iMac screen) onto that crap screen and they still work, then maybe they have a good chance of working for a lot of the users, too.

So if you have one or two big lovely screens to design on, consider running another bad screen too. You can probably find one at the back of an office cupboard somewhere, or pick one up on Gumtree for almost nothing. I guarantee it will improve the experience for your users in the long run.

P.S. This also goes for mobile screens. Add a small, low-res Android device to your test devices, or use a Device Lab. Most of your users don't have an iPhone 6+ or a Nexus 5.

2012-02-23

Responsive wireframing

This post originally appeared on the Storm ID blog.

There has been a lot of talk recently on the web about the best responsive design workflow, and part of that is the best way to wireframe for a responsive design. We've been wrestling with these topics at Storm ID too, and I wanted to share a little of how we're working on it at the moment.

What I describe below won't work for everyone. It may not work for us 6 months from now, but it's working well for us just now.

Sketching is a great way to get ideas flowing, to quickly illustrate those ideas to colleagues and to get things straight in your own head. I still start with paper and a pen, roughly sketching things out. I probably always will.

It’s useful to remember that we can use traditional tools (if necessary) to generate ideas internally, and then use ‘new’ methods of presenting ideas to clients. Not everything has to be a deliverable; we just have to present deliverables in the right way. Use whatever you want to get the ideas going: paper, Visio, Axure, Balsamiq, Photoshop. It really doesn't matter. Just remember that it's okay to throw it away afterwards.

So after I've got things a bit clearer in my head by sketching, I move on to HTML/CSS wireframes.

You would be hard pushed to find many web designers today who would argue against HTML/CSS being the best way to present wireframes to the client, but many feel it's too time consuming. I disagree.

It can be done quite quickly with a system in place

I've been developing a system while working on a couple of responsive sites that makes it much faster to create HTML/CSS wireframes, almost like static prototypes. I start with a basic HTML file which we have developed, a bit like HTML5 Boilerplate but tailored to our own needs, including a reference to wireframes.css, a stylesheet I wrote.

View our current starting template and view source
View wireframes.css

This stylesheet contains a few basic styles for header margins, link colour (just adjusted the shade of blue) and the main thing: styles for [data-wf="block"] and [data-wf="nugget"]. This allows me to add data-wf="block" or data-wf="nugget" to any element and have it display as a traditional-looking wireframe grey box or white box with grey border. After the wireframing stage I can easily remove the stylesheet and the data- attributes and all the grey styling is gone but the structure remains, ready for the visual design phase. I've used data- attributes instead of classes as I found them easier to find and remove.

To add height to blocks without full content yet I just add <br /> tags (don’t panic, these won't make it to production remember).

Then I start adding layout structure CSS to my other stylesheets. This structural CSS can form the basis for visual design in the browser later. You can use something like Bootstrap if it helps keep things speedy, or you can roll your own grid, as I prefer to do.

At this stage (and most of the way through development) I reference a stylesheet for each media query, instead of combining them. I find it much easier to work with a few files open in tabs than to endlessly scroll up and down one huge stylesheet.

I don't find that all this takes me much longer than figuring out how to use Axure or Visio or something similar.

The extra time spent is worth it

Yes, it can take a little longer to wireframe in HTML/CSS. But what you lose here, you make up for later by having a solid foundation already in place to start the visual design phase. Some of your output is already done. Some of it you might need to strip out. It also gives our developers something to work with when developing the site while I work on visual design.

Building out your wireframes like a prototype allows you to work out exactly how the layout changes according to different devices. It lets you see if your thinking on paper was correct. It lets you quickly adapt when you find out you're wrong.

It's going to give the client the clearest possible picture of what you are proposing. They can view and test a usable web page, with links, javascript and/or CSS3 based interactions, and test the flows through the site. They can test this on any number of different types of devices they can lay their hands on. There is no guesswork needed. This is incredibly important as we support clients who are new to creating for the web, let alone experienced with responsive designs. Often, the best way to explain something is to demonstrate it. You can even set up analytics on these wireframes and get feedback that way.

It's not supposed to be easy

I'm a designer who codes, but if you're not, why not get friendly with someone who is. Sketch out your ideas, chat through them with a frontend developer, and have them produce responsive wireframes you can present and share with your client.

No one is saying this is simple. It's not. It takes a huge change from 'traditional' processes and to start with it will take some extra work. However, the benefits for you, your clients and the final work far outweigh the initial pain.

Always evolving

This is what works for us just now. We're always trying to look at better ways of doing things, for our clients and the agency. I'd love to hear what you think is the best way to work with responsive design throughout the process, and especially any good or bad experiences you've had.

2012-02-03

Responsive Design on Sharepoint 2010

This post originally appeared on the Storm ID blog.

When it came to rebuilding the [client] – that wonderful arts icon located in southside Glasgow - we felt that this type of content-rich site would benefit from a content first, responsive approach.

However, we weren't sure how responsive design would fly with SharePoint.

For legacy reasons, the rebuild had to be done on SharePoint 2010 ([client] being part of the [client] web family, all of which is built on SP), and we know that SharePoint can be notoriously hard to bend to your design will with so much extra code and use of <table>s.

Fortunately our SharePoint Team Leader, Tom Travers, is both a patient man and has spent years of his life rewriting SP controls to use markup that the Storm design team can actually work with. Because Storm are generally up for a challenge with SharePoint we were keen to see how a responsive design could work with that product.

First, the caveats…

First, we should say that we wouldn't recommend trying a responsive design approach with a standard out-of-the-box Sharepoint install.

Responsive design is not easy at the best of times:

  • First you have to break the design habits you have developed over the years.
  • Then you have to educate your client about what responsive design is and the benefits for the project.
  • Then you have to create a responsive design that flexes to any size of screen but is still compelling.
  • Last - and this is the really hard part when working with SharePoint - you have to integrate your designs with your chosen CMS.

An introduction to responsive design

Basically the web is going device independent.

We are currently experiencing a period in which there has been a dramatic increase in the number of devices that websites are viewed on. Smartphone penetration continues to increase with more people predicted to access the internet via this method than PCs by 2013. At the same time we’ve witnessed huge growth in tablets, like the iPad and Kindle, presenting yet another range of screen sizes and capabilities for websites to deal with.

The spectrum of screen sizes and resolutions is changing every day, so much so that creating a different version of a website is increasingly deemed to be impractical and unnecessary.

The emerging solution on the web is to adopt a responsive approach. The approach makes use of flexible grids, flexible media and media queries to serve the most appropriate experience possible to whatever device you view the site with.

Yes – it’s the right time for [client]…

We thought that a responsive design would help ensure that [client].org was accessible and well presented to the widest audience, regardless of where and on what device they were accessing it from. Moreover, as new and, as yet, unforeseen devices continue to enter the market, responsive design should help to ensure that [client] is future friendly.

Our approach to responsive design on Sharepoint

Our design approach for many projects in the past has been Research > Wireframes > Mockups > Output > Integration. However, this approach does not, in our experience, bring the best out of a responsive design:

  • Working with static mockups can never convey to the client how a design feels when it is interacted with, and it certainly can't show how the layout will work at a variety of sizes.
  • Likewise, static wireframes can show layouts and elements as viewed at a certain size and resolution, but we can't make endless wireframes of each view for different device sizes.

Also, if we mock up designs for some ‘standard' sizes, we will miss all the devices, niche or otherwise, that fall between these.

Responsive design is as much about those in between sizes as the 'standards' of today.

Wireframing

We now move on to quickly built HTML/CSS wireframes. (Actually, we do plenty of sketching first, but the client is seldom presented with these sketches.)

The wireframes are built using templates and snippets we have built up, including a wireframes.css file, which allows us to quickly add classes to elements to style them in the familiar grey, black and white boxy style for traditional wireframes.

The difference is that these wireframes can already convey to a client (and ourselves, this is as much exploratory as explanatory) how the layouts look at different sizes on different devices, and in different contexts.

They can view these wireframes in the office, on the train, in the street, and each template can be linked up to give a feel for the user journeys.

Yes, this can take a little longer than creating static wireframes.

But the more we use this process and the more snippets and templates we build up our library - yes, a “patterns library” for responsive design, nice - I hear you say - the quicker we are getting at this. Also, the extra time spent at this stage is compensated for in the next stage: visual design.

Visuals

Once the wireframes have been agreed, we move on to visual design, also in HTML/CSS.

We may work up some ideas in Photoshop (but again, the client won't generally see these). We work in HTML/CSS/JS, working with the existing layouts from the wireframes, building up the richness of the designs. This progressive enhancement approach allows us to give basic devices a basic experience without losing any functionality, and giving more advanced devices a richer experience as appropriate.

This also allows the client to see how the visual design will look in situ, in terms of layouts, contrast, typography, etc.

Having already worked out a lot of the problems with the responsive parts of the templates, this phase is much quicker than the traditional build phase from static mockups.

*!**!** SharePoint!

As mentioned above, normally our designers might spend time integrating templates into target CMS for the project. For Tramway, however, the static HTML/CSS/JS templates were handed over to Tom to integrate into SharePoint.

These templates were built initially without any allowances for SharePoint's usual eccentricities.
We wanted to create the best possible product first, and then see if we could integrate it and solve the problems needed to so. There's no point in starting from a position of weakness, as we knew we would have to make compromises later on.

How was it done?

First, we built a solid masterpage that works for anonymous, publishing web-site.

This goes some steps beyond the available minimal masterpage out the box. Not only did this mean ripping out anything that could come out, but quite a lot of ‘poking the angry animal’ to see if it would bite back. This means things like messing with the <html> element, the <DOCTYPE> declaration and the basic s4-* based structures.

Then it was just a case of pouring in the creative output…and a lot less debugging than anticipated. This was all combined with the site content, which has some rich content types, including calendar event links, video and audio, and other conditional display constructs. Oh, and a few calendar based searches.

The final challenge was to support the page authoring model, ribbon and all… Admittedly this does get a bit messy with conditional display controls being used for the page display to authenticated users and further conditionals when in page edit mode.

Methinks some further challenges lie in this area…

So here’s an open challenge for the Microsoft SharePoint 2013 team … how building in responsive support and a responsive SharePoint page editing environment?

A message in a bottle…

The bottom line, we’re pleased to say, is not only that a responsive design in SharePoint 2010 can be done, but that it can be done very successfully.

Go take a look at [client] and see for yourself…

Andy Lobban

Edinburgh, Scotland