Journal - Nerdery

Sleeves Received Twitter

The Wire run a Tumblr blog called Sleeves Received which features some of the lovely, weird and wonderful packaging from releases they’re sent. As a label owner, record nerd, and designer, this is pretty much the best Tumblr for me. Since I’ve given up RSS and moved to following sites on Twitter if I absolutely need to follow, Sleeves Received has been missing from my life. So I used IFTTT to pipe the RSS feed from the site to a Twitter account, so it tweets new posts. Follow if you’re interested.

Disclaimer: This is totally unofficial.

The Wire’s Sleeves Received on Twitter

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.

On Adaptive Design

This post originally appeared on the Storm ID blog.

There’s some confusion from some of our clients about what adaptive design really is and if, when and how it should be used. Responsive design is all but the industry standard at this point, but what about adaptive?

Originally the term adaptive design was used to describe layouts which were very similar to responsive layouts, but with fixed widths instead of fluid widths. Some designers really liked that as it meant you could control line lengths and image sizes and that was handy when the industry was starting to get to grips with how all this new stuff worked. The main downside was that if you viewed these layouts in a browser window which was in between these breakpoints, you could have a lot of ‘wasted’ screen space. The experience didn’t feel native to the device you were holding, which is the whole point of responsive design. For example we saw some tablets that were less wide than an iPad and the designer had only added breakpoints for iPhone size and iPad size screens, so you saw the ‘mobile’ sized site with lots of space either side. This method didn’t lend itself well to the fluidity of the web and the mass of different device sizes. You had to use breakpoints that made sense for your current traffic which may not make sense in a few months when Apple or Samsung or Amazon bring out their new device with a different screen size.

The adaptive design that is talked about in many articles at the moment largely relies on Javascript (JS) to add in components to the document based on what it thinks it knows about your device. This can work, but has a couple of possible problems that are showstoppers for me.

Some articles advocate using JS to find your screen size. This is generally fine technically, but there can be problems with that. Screen size ≠ browser window sizecontext ≠ device type.

Some advocate browser sniffing, where JS detects parts of the user agent string of your browser. This can cause huge problems. For various reasons, browsers often lie about what they are. This method doesn’t allow for new classes of device either, without development updates.

OkCupid have a different use for browser sniffing.

Another big problem with many of these articles is that these techniques absolutely require JS. That’s not too bad if it’s server side (run on the website’s server before sending the page to the browser), but if it’s client side (run by the end user’s browser as the page is delivered) then this can and will cause problems. Web browsers operate in a fundamentally hostile environment. If the end user’s browser has JS turned on, and if JS runs successfully and in a timely fashion, then they may be delivered a relevant page, with the caveats above. If JS is turned off (unlikely but possible) or JS fails to run (device is struggling, internet connection is slow or fails) then, in many cases the user will be left with a sub-standard experience, or no experience at all in some cases. And slow connections are not just for mobiles. Think cafes with 50 customers and a weak router, or small internet cafes, or some rural areas, or people who have to deal with ISP problems all the time. Our company build large scale, award winning digital products, but we can’t get decent wifi in one of our meeting rooms, and we spent the first week in our new office with a connection that was only okay if no one started a YouTube video or Spotify.

This is what squarespace.com looks like if JS is turned off or fails.

Running this stuff on the server and delivering components according to what it thinks it knows can be good idea in theory, though. Capital One talk about doing this with their sites, promoting different products to different device classes and locations. If you have a strong in-house team, both in development and marketing, and can tweak that regularly and test heavily, you could have . This can also have downsides. Many people will try to tell you that on a small screen you should change content because small screen = mobile = on the go. We know from (bitter) experience that this is not necessarily true any more, as more people move to not owing a traditional computer at all. On many of the kind of sites we produce, all content is as relevant on small screens as larger screens, so messing with that seems like a bad idea. Make an element less prominent, but removing it all together will just frustrate the people who need that element and only have mobile device (at least at that moment). How many times have you sat on your sofa and looked for something online on your smartphone, only to give up because the feature you need is missing, and getting up to switch on your laptop seems like a lot of effort?

Be careful about SEO. Google is putting less importance on content which is not visible by default on a page, such as tabs and ‘read more’ content. This could easily be applied to content that doesn’t appear for all users. So be careful about selectively adding content that might be important.

Delivering different assets from the server depending on screen size is also a good idea in theory, as it means your browser only downloads what it needs to which cuts down on bandwidth, increases page speed and in turn engagement and sales. However, there are new HTML image specs which are usable in Chrome, iOS, Safari and Opera now, and are polyfill-able in other browsers, which basically do the same things with a bit more flexibility. They take away the need for fancy server configs too, which is especially great for prototyping.

The last, and perhaps most important point: What these articles talk about as adaptive design could fit into responsive design. The two are not mutually exclusive at all. Responsive design goes way beyond just fluid layouts that change at different screen sizes. It’s also about performance and progressive enhancement, both of which are part of what they talk about adaptive design being. But that’s another big blog post in itself.

The main thing is to use common sense and think about all kinds of users. Use progressive enhancement to first make it work, then make it work better. Don’t rely on a user having all the technology that you hope they do, and have it working fully every single time. Be inclusive.

Lytro testing

While I was in Austin, I was given a Lytro camera to try out for an evening. The Lytro site can explain much better than I can what this camera does:

The Lytro camera lets you capture and share what you see in a whole new way. It’s the first consumer camera that records the entire light field — all the rays of light traveling in every direction through a scene — instead of a flat 2D image.

This means you can refocus images and change perspective in post-processing. You can do this and export a flat image, or you can upload your photos to the Lytro site and embed them on websites, allowing viewers to focus or alter perspective they way they want.

It’s an amazing idea. It’s going to be incredibly useful technology when it’s ready. At the moment, the photos are very low resolution and the crazy focus  and perspective shifts you’ll see in the example images didn’t seem to happen for the photos I took. It’s also pretty bad in low light. Still, it’s a lot of fun, and I can’t wait to see what the next few iterations bring. Also, it’s fun watching people get really confused about the weird looking Start Trek type contraption you’re pointing at things.

View my full gallery

A few examples

I’ve embedded a few examples of mine here. Try clicking on an area to refocus. Try clicking and dragging to change perspective.

My NYT ‘word cloud portrait’ from SXSW

The only 5 minutes I spent at the SXSW Trade Show this year was getting a ‘word cloud portrait’ done at the NYT booth. They took my photo, asked which section of the NYT I liked most, and two minutes later presented me with a print of my portrait.

Andy Lobban - NYT cloud portrait

View on Instagram

Flash support on mobile devices

This post originally appeared on the Storm ID blog.

Most people who build for the web agree that trying to use Flash on anything to be used by mobile devices is a bad idea. Most people, however, don’t keep up with the state of the web as closely as we do. In the last few weeks we’ve had a couple of clients ask us about adding Flash content to a site that will be used by mobile devices as well as traditional computers’. I have collated some information on the subject which might give you a better understanding of the current situation, or help you explain it your clients.

Mobile Flash Support

Mobile device use is on the rise, which means most websites are being visited by mobile users to some extent. Using Flash content in these situations should be avoided if possible, or at least used with an appropriate fallback.

Some stats from our clients’ sites

International sport organisation’s e-commerce site, last month

  • Mobile visits with Flash installed: 2.25%
  • Mobile visits without Flash installed: 97.75%

Large UK retail chain’s e-commerce site, last month

  • Mobile visits with Flash installed: 5%
  • Mobile visits without Flash installed: 95%

 

Besides, animated GIFs are more fun anyway.

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.

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…

One for the music and letterpress nerds

Gillian Welch and David Rawlings oversee the letterpress process of their new album cover.

More Journal