Last week I was supposed to be giving this talk at iOSDevUK, but unfortunately I had to cancel it because I was sick. So I thought I’d post my notes here for you guys to read and go through. This talk is slightly different from the version I used at previous conferences, as I decided to update and revise it. The last few slides are missing notes, but I think there’s still some choice nuggets to be had!
(slide1)
Hello, my name is Amber Weinberg and I’m a recovering developer. 🙂
I specialize in WordPress development, but have recently been working extensively in mobile development. I’ve found that there’s not one perfect way to go about mobile, and today I’d like to talk about the three different ways you can approach your site in mobile.
(slide2)
When first starting out in mobil development, it might seem like you’re simply working with a smaller screen size, and in some cases – that’s really all that’s to it. However, unlike developing for desktop, where you normally only have to pay attention to one set “size” (for example, a 960px wide site) and a few browsers, you have to now pay attention to endless browser sizes, devices and orientations of the device itself. It’s less about the browser it’s running (most run webkit anyways) and more about the experience and ease of use.
(slide3)
With that said, mobile development has been made a lot easier thanks to the advanced adoption of HTML5 and CSS3. Animations, transitions, advanced selectors and offline storage work fantastically on mobile, as it was mobile that really spawned off the need for the new spec. Yep, HTML5 and CSS3 were actually created to give the web a more “app” like experience.
(slide4)
Unfortunately, there’s always one bad apple to spoil the bunch, and that apple is what we call “a Blackberry”.
A lot of Blackberries are owned by professional businessmen, or loaned to them by their jobs. For example Fedex, where my own dad works, gives these out widely to all of the upper office positions. So there’s a lot of these devices floating around.
Now, the newer Blackberries aren’t really an issue, and run the web quite well. They even have larger screens. However, many of the ones given out at jobs are the older or more pared down models, and those models don’t completely “agree” with CSS3.
I’ve run into issues before with simple styles like opacity not working at all, and even some advanced selectors.
Just be warned – Blackberry is the IE of the mobile world.
(slide5)
When working in mobile, you have a lot of the same issues as you normally do when working on a regular desktop site. Some of them are a bit more magnified though.
For example, while we’re concerned with how fast our sites load on normal computers, we often don’t have to pay too close attention thanks to the wide adoption of high speed internet. However, when dealing with mobile – we can never be super sure that the user will have fast internet – and even “fast internet” isn’t very fast on mobile. Remember, your iPhone’s hardware isn’t going to compare with your 27” iMac, so the same internet is obviously going to run quite a bit slower on the smaller device.
Therefor, we need to make sure that whatever route we take in mobile, that it’s optimized as much as possible for speed. We don’t want users downloading huge images or lots of Javascript.
Which brings me to the next magnified issue – Javascript and graceful degradation. Some devices, like Androids, can actually turn off Javascript. While I’ve always personally felt like this isn’t a big issue – the only people who are going to turn off JS are probably us web nerds – I believe it’s still important to make the site work as much as possible without JS – if a user is running a slower internet, your JS might not even have time to load before they get off the page.
(slide6)
Of course, there are plenty of unique issues when dealing with mobile development.
Space is obviously a huge issue – you’re not going to be able to display the same amount of content in the same exact way on a Blackberry as you would on a 24” monitor. It therefor becomes even more important to make sure to get what the user needs front and center.
Retina displays are now becoming not only a mobile issue, but thanks to the new MacBook Pros, a desktop issue as well. Retina displays are devices that display double the pixel density – so that the screen size, while exactly the same as it’s non-retina counterpart, gives a much sharper display. The downside to this is that most of the web looks like crap on one. While this isn’t too noticeable on the iPhone, I’ve hard this is so noticeable on the MacBook Pros, that people have actually returned them for a normal display. Retina displays become a huge issue for mobile, because in order to avoid your images from looking pixeallated, you have to use much larger images, which results in slower download speeds.
Another major issue in mobile, which relates to space, is the browser. While you’re safe in assuming that all desktops will be able to see a 960px layout just fine, you’re not safe in assuming any size for mobile. A user can be on a 320px wide iPhone, a 768px iPad, or a 240px Blackberry Pearl. You don’t want to serve an iPad size site to the Blackberry, nor a Blackberry sized site to a tablet.
(slide7)
So let’s take a look at the different ways we can approach mobile development.
You might have heard from someone that you should always use responsive development. Or never use a separate web site. Or native apps or dying. What do I say?
Bollocks. There’s an appropriate use for all three of these solutions. Not every site even needs one of them. The route you need to take when approaching mobile depends on the users and how the use the site.
Let’s take a look at all three mobile solutions and their pros and cons.
(slide8)
Mobile sites are regular websites, written in HTML/CSS that are separate from the regular, or desktop, version. For example, when you’re navigating to a site and it says something like mobile.website.com or m.website.com, you’re most likely running a mobile website. This differs from responsive development, which I’ll explain next, because you’re essentially maintaining two completely different sites. When visiting a website, the website sees that you’re coming from a mobile devices and instead of taking you to the normal site, redirects you to the mobile site.
Mobile sites are fantastic when dealing with larger, more complicated sites, like eCommerce or sites that work more like apps. Using a mobile site allows the experience to be customized and easier to use for visitors.
However, mobile sites are a sustainability nightmare. If you want to make a global change, you have to do it in two places – once on the regular desktop site, and again on the mobile version. This means that development costs are a lot higher for the business owner as well.
(slide9)
Responsive design is currently the flavor of the week – and is what most developers gravitate towards when approaching mobile.
Responsive design is a site that changes appearance based on the size of the viewport, not necessarily the type of device it’s on, like mobile websites. If you take your browser and resize the window and the site scales down or changes layout, you’re looking at a responsive design.
You can see Pixelworker’s website here, which is a site to find fantastically nerdy t-shirts. On the right is a view of their site on regular sized screens, and as the website get loaded on smaller and smaller devices, you can the layout starts to change. First it just shrinks down to fit the screen, but once you get to the smallest version, on the left, you can see that the layout drastically changes. The navigation becomes four small icons and moves to the top right., the large hero image disappears, and the images of the products become one column with larger images.
Responsive design is a fantastic solution. It works simply by using percentage based widths instead of pixels and uses CSS3’s media queries to fine tune the layout based on the size of the viewport. This means that it works with every new device with no further updates require. If someone comes out with something new that’s in between a tablet and a mobile phone – you can rest assured knowing your responsive site already works on it. Also, because you’re only maintaining one codebase and coding it once – it’s the least expensive option of the three.
There’s also a simpler type of responsive design, called adaptive design. This is a dying technique, so I won’t go into too much detail, except to say that it’s just like responsive design, except instead of using percentages for the layout, it uses pixels and just swaps layouts as the viewport goes down. This has the obvious disadvantage of not catering entirely to every width.
Of course, responsive design is not without it’s drawbacks. You can only edit the CSS for viewports, not the HTML – unless your resort to using JS – which is not good practice at all! Responsive design can also lead to image bloat if you’re not careful, because the images you use for the full-width version is the same image used for mobile.
(slide10)
Native apps are fantastic solutions for sites that work well as, well apps. You can use the device’s native hardware, like the camera, phone settings and it’s written in the phone’s native language, which means it runs faster and smoother. You also get the advantage of being advertised in the phone’s app store, so you don’t have to rely on users coming to your site.
As lovely as native apps are, they do come with some serious drawbacks. They’re much more expensive because they requite special developers who can work in Java, Objective-C or whichever language the device uses. This means you’ll often have to find a different developer for every platform, or risk leaving out those users.
If you’re building a device for iOS, you’ll have to go through Apple’s app store and have the app approved. Making simple updates or text changes to the app again requires the use of a special developer and it takes time to push the update through the app store.
Native apps also aren’t future proof at all – if a new platform comes out, or even if the current platform gets a major upgrade, you’re forced to choose between creating a new app or leaving out those users.
(slide11)
This chart was taken from Statcounter’s website and shows the rate of desktop and mobile usage over the past year from June 2011 to 2012. As you can see, while desktop is still king of the web, it’s had a steady decline while mobile usage has been increasing.
I believe this is due to more affordable devices, faster mobile networks and wider coverage of public WIFI. I think we’ll continue to see a steady decline of desktop devices, as people no longer need to go to their desk to check their email, update their social networks or browser the internet. This makes having mobile optimized sites even more important, as you can start to lose a lot of visitors if it’s impossible to use on these devices.
(slide 12)
I’d like to now show a couple of mobile sites I’ve done, the issues I’ve faced doing them, as well as some techniques and tricks to making mobile easier to work with.
The first mobile site I did was for Audible. Audible is an Amazon company that offers a subscription service for buying audiobooks. They wanted a mobile presence, and because of both the complexity of the app, and the fact they already had a working desktop site, they decided to go with a separate app.
This project spanned over 100 mockups and several months. I had to support iOS (including the iPad), Android and Blackberry devices.
(slide 13)
If you take a look at the site on all three devices together, you can already see that there’s a big difference between each device. Especially, the Blackberry – which we can hardly see any content at all on it’s teeny tiny screen. For this reason, we made sure to put the search box and the sign in link at the very top – the two most widely used areas of the site.
(slide 14)
Most of the problems you’ll encounter in mobile development stem from the difference size issues of each device. You’ll still doing a bit of responsive design on mobile sites, you’re just doing it for mobile devices only – and being unused to working with percentages, it was quite a challenge.
I had issues with making sure my buttons were long enough to fit from the iPhone to the iPad, and when using percentages with margins – they would often become unaligned on bigger devices or when turning the device over.
This module right here is supposed to be two rows of books edge to edge on the device – but when in landscape mode, the books no longer fit the screen and fall down, leaving some big gaps.
All of these are, thankfully, fixed using media queries today. This site would’ve been a lot easier to code had I done it recently!
(slide 15)
Media queries are fantastic functions new to CSS3 that allow us to fine tune a site based on the view port size of the browser. This is helpful because we no longer have to worry about percentages messing up our margins and layout.
You specify media queries using a min or max width of the browser. For example, if we wanted to target iPhone sized devices only, we’d use a media query with a max width of 320px.
You’ll most often use a media query when you come to a break point in your design. A break point is when the layout starts to “break” as you resize the browser. For example, in the previous slide with the two rows of books, the width of the browser, when those books were pushed down and that big margin opened up, would be a breakpoint and where I would need to insert a new media query.
(slide 16)
A common argument right now is whether one should go desktop first or mobile first – and the popular view is to go mobile first. Mobile first means starting from the smallest screen and adding on styles as you increase the size of the viewport. This is often thought to be better for browsers as you load in less resources when you’re on mobile, which often means the user has slower internet.
However I really disagree with this approach. Firstly, it puts the developer at an almost impossible disadvantage when they’re handed designs for a full width site and told to make it responsive. A developer has no basis to start from – so it’s a lot easier to code the desktop version first and then adjust the design as you decrease the browser size.
It can result in some code bloat if you’re not careful, however I believe that use a mix of both min and max queries can help avoid this. Load large graphics as background images so you can remove it with a media query in mobile.
(slide 17)
Another issue I had is with Javascript, particular the sliders. Because Javascript isn’t reloaded just because you change the orientation of the device and most sliders require a set width to work correctly, when the user changed the device to landscape, the arrows and the slider didn’t move properly. This even happened if I set the slider to 100%, since the width of the slider was calculated on load.
To combat this, I had to write a tricky script, but thankfully today there’s an easier solution.
(slide 18)
Thanks to Flexslider, we can now have fantastic responsive sliders, that work as the viewport’s width is changed, not just on loading.
Version 2 of flexslider even has touch and multi-slider per view support, so it’s finally the only carousel one developer should need. Which is nice. Because I used to use about 10 different ones.
(slide19)
My next case study, Hired.IM, is my newest responsive website and a project near to my heart. It’s a project I’ve started with a great designer friend of mine, Paul Maloney. It’s a job board for designers and developers, but what makes us different is that we plan to donate 50% of the proceeds to support CodeClub, which is a fantastic charity that aims to get after school classes for kids and teach them how to code.
(slide20)
Because the site’s design was pretty simple it gave me a chance to spend a bit more time tweaking the mobile experience. I was able to get the search and widgets area in three separate layouts to take advantage of the viewport size.
Amber Weinberg
Amber is a freelance front-end developer specializing in semantic and accessible custom WordPress themes. She works with agencies and other freelancers to bring their designs to life using custom ACF flexible layout builds - making them more performant and less buggy while allowing the client easy customization without breaking the design system.