Andrew

A Web for Everyone: Interviews with Web Practitioners — Rachel Andrew

A recent article on Mozilla Hacks, “Make the Web Work for Everyone,” explored challenges and opportunities in browser compatibility. In that post we urged developers to build cross-browser compatible web experiences in order to maximize exposure and market size; prevent interface bugs that drive users away forever; and demonstrate professional mastery.

Today we’re kicking off a series of interviews with web developers who have earned widespread admiration for their work on the web. Do these professionals at the top of their field take web compatibility as seriously as we do? Why or why not? And how do they go about achieving it?

We’ll start by talking with Rachel Andrew (@rachelandrew).

Rachel Andrew

Rachel is a founder and managing director of edgeofmyseat.com, the company that builds Perch CMS. She has worked on the web since 1996; in that time she’s authored numerous books about CSS and HTML5. She is a frequent speaker at web development conferences (you can see her talking about CSS layouts at View Source 2016 in Berlin, September 12-14). She blogs at rachelandrew.co.uk.


So Rachel, what does cross-browser compatibility mean to you?

Doing my job properly! That’s it really.

How often do you have to think about cross-browser compatibility? Have you found ways to work that allow you to reduce the amount of time you think about it compared to when you were less experienced?

I think about it a lot less now than I used to. The main core things we want to do work cross-browser in a consistent way. We don’t have wildly buggy behaviour as we had in the past. New developers should go look at positioniseverything.net/explorer.html to see the stuff we used to have to deal with!

Where I do need to think about it is when I am using a new specification, something that isn’t fully implemented perhaps. Or something that hasn’t yet been implemented in all browsers, in that case I need to be sure that my usage of that technique for supporting browsers does not cause a problem for people in a browser that hasn’t got that feature yet.

What motivates you to make the extra effort to build a cross-browser compatible site or product?

I’ve always worked from the assumption that the web is for everyone. I’m also old enough to understand how fast this stuff changes. As far as I can see the absolute best way to ensure that things work well for people now and a year down the line is to get them working in the biggest possible number of browsers and devices today.

Could anything convince you not to make that effort?

Not really, because it is so ingrained into how I work. I also know from experience that when someone says the site only needs to work in a certain browser, look a year down the line and that might change.

Also, in a world of evergreen browsers, working cross-browser can actually mean improving the future experience for the people using the browser with the biggest market share. Here’s an example: position: sticky, enabling sticky headers on tables and navigation has been in Firefox for a good while. It is currently behind a flag in Chrome. Over 50% of my users are in Chrome, however the sticky headers on a table are a nice enhancement so I might use position: sticky to add that little touch for Firefox users who have support.

When Chrome ship their support, suddenly all those users will get that nice enhancement. The site will get better for them without me having to ship any code. So being aware of what is shipping in different browsers means you can take advantage of new stuff and leave these enhancements in your site for other browsers to grow into.

We think of cross-browser being dull grunt work, battling with old browsers and weird bugs. However it can also be pretty fun and liberating, especially right now. There is new stuff shipping all of the time, you miss out if you don’t take a look at who is shipping what.

Can you think of a particularly vexing or interesting compatibility bug you’ve encountered?

Not really, of course I’ve had them. No matter how much testing you do you can be sure that something subtle or not so subtle will happen at some point. What you find is that the more time you have invested into understanding why things work as they do, the more these issues just become a bit annoying rather than giant showstoppers. Actually practicing working cross-browser in non-stressful situations means that when something baffling does occur you have the ability to take a step back and debug it, figure out how that user could possibly be seeing what they are seeing and get it fixed.

Have you ever had to convince a client or boss that building a cross-browser compatible site was important? How’d you do it?

Even back in the days of the browser wars I never mentioned it, I just did it. It’s how we work.

Did you ever have a specific experience that caused you to take cross-browser compatibility more seriously with your next project?

Not really, I’ve been doing this for a long time! However I used to do a lot of troubleshooting of work done by other people. Rather than starting from a baseline of solid experience and enhancing from there, they would have all started with something that only worked in one browser and then tried to retrofit compatibility for the others. Fixing the mess often meant going right back to basics, figuring out the core experience that was needed and then building back up the desired result in those browsers that supported the full experience.

In your post, “Unfashionably Profitable,” you say, “Everything should be possible without JavaScript.” Do you think over-reliance on JavaScript has made the web less cross-browser compatible?

I think that people will often reach for JavaScript earlier in the process than they need to. Even if they are not building the whole thing as a JavaScript application there is a tendency to assume JavaScript is required for all sorts of things that can be achieved without it, or where a baseline experience can be developed without JavaScript to be enhanced later.

I’m not saying “don’t use JavaScript” but the fact is that as soon as you bring JavaScript into the mix you have a whole host of new potential compatibility problems. A development practice that brings these things in one at a time and encourages testing at each stage makes the whole process much much easier.

Are there parts of your process/toolchain/etc. that make it easy for you to incorporate or test for compatibility that you would recommend every web developer incorporate into their own?

I’m pretty old-school when it comes to tools, however I am a big fan of BrowserStack, mostly because I travel a lot and can’t fill that laptop with virtual machines or drag several devices around with me.

What would you tell a brand new developer graduating from a coding bootcamp about cross-browser compatibility?

Everything gets easier if you start by figuring out what the core thing the site or application or feature you are building needs to do. Build that, make sure it works in a few browsers. Then, and only then start to add the bells and whistles. Don’t get everything working in one browser and then a day before launch think, “hmm maybe I should test this in another browser”. That is when cross-browser becomes difficult, when you try and do the retro-fitting.

Start out right and you probably won’t have to think about it too much.


Tips from Rachel’s interview

  • Experiment with upcoming or partially-implemented browser features, but use them only to enhance basic functionality, not to deliver basic functionality.
  • Add new features one at a time and test their compatibility as you go. Don’t wait to test at the end.
  • If you don’t have access to all the machines and devices you need to test on, test in one of the online browser testing tools.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

People of HTML5: Andrew Betts on building the FT.com HTML5 app

HTML5 needs spokespeople to work. There are a lot of people out there who took on this role, and here at Mozilla we thought it is a good idea to introduce some of them to you with a series of interviews and short videos. The format is simple – we send the experts 10 questions to answer and then do a quick video interview to let them introduce themselves and ask for more detail on some of their answers.

Andrew Betts Today we are featuring Andrew Betts, director of Assanka.

We came across Andrew because of his talk “We’ve Got a Website for That – The FT Web App and the Future of the Mobile Web” at the BlackBerry Devcon in Amsterdam where he did a great job allowing us to peek under the hood of the Financial Times web app. You can reach Andrew on Twitter as @triblondon.

The video interview

You can see the video on any HTML5 enabled device here (courtesy of vid.ly).

10 Questions for Andrew Betts

1) You worked on the HTML5 application for the financial times. What made you go HTML5 and not native? How many people were involved at all?

The FT has an agnostic approach when it comes to the formats and technologies we can use to display our content. The choice has to suit the content, the reader, and our business model. Before we launched the HTML5 app there was already an FT native app on iOS, and it received an Apple design award, but HTML5 offered several significant benefits, the most important of which was to allow us to maintain a direct relationship with the reader. Secondary benefits include a faster update process, an investment in future cross-platform compatibility (HTML5 is yet to fully realise the dream of write-once, run everywhere), and freedom from restrictions and rules that are (or may be in future) imposed by app store operators.

2) What would you say was the easiest part and what was the thing that you had to spend the most time on to make it work?

Interactions are the hardest thing to crack. Matching behaviour to user expectations is frighteningly complex, especially when you realise that instinctive expectations of swipe behaviour is actually quite varied and inconsistent. One example of this complexity is swiping horizontally from the bottom of a section page, which takes you to the top of the next one. If you then swipe back, do you end up where you were, or at the top? So dealing with interactions is both technically hard and architecturally challenging.

Offline behaviour is also very tough. We get a lot of “User x can’t use the app offline” style support requests, and those are very hard to debug. We log every report but the priority is to figure out the scale of the problem.

The easiest thing to deal with is probably layout. We send all legacy browsers to m.ft.com so we only have to cope with the most recent major versions, and that means that generally we get good standards support for CSS.

3) How did you deal with the differences in interfaces? A mobile has much less space than a tablet and again less than a desktop. Are you using mediaqueries to give different experiences?

We group devices into one of four sizes based on media queries, and we vary which resources we use slightly based on the reported DPI, but most of our responsive layout logic is done in JavaScript. We make a few assumptions right now to make development easier, such as that the user cannot change the size of the browser window, except by rotating the device, so we only need to change the layout on orientation change, not in response to arbitrary resizing of the window. We also currently assume the user has no mouse cursor, so there are no hover effects.

4) How does input get into it? Is it simple enough to build touch interfaces in HTML5 or did you have to use some trickery?

Quite a lot of trickery is involved, unfortunately. The browser has to tread a fine line between on the one hand offering a touch API to web developers and getting out of their way to let them use it, and on the other, dealing with the fact that almost all websites are still built for keyboard and mouse, so the browser needs to help the user deal with that. We developed a polyfill called Fastclick which makes click events fire as fast as touch events, and that certainly helps us provide an experience that is as snappy as using a native app.

We also deal with swiping in a few quite distinctly different ways. Swiping between sections is an endless carousel, and we implement the tracking and sliding ourselves, by maintaining hidden page containers to the left and right of the current view and applying CSS 3D transforms. But paging through an article requires different scroll mechanics – it has a fixed length, and we have to lay out the whole article in one go to know how many pages there are. Pages that scroll vertically are a different challenge again, and there we use a combination of leaving the browser to do scrolling natively, and simulating it where we need slightly different behaviour.

You’ll also notice that the pages don’t ‘bounce’ when you hit the top and bottom of the page, despite that being the normal behaviour in the iOS browser. We’ve gone to quite some lengths to ensure that the user experience mirrors an app and doesn’t feel like the device ‘coping’ with a site that hasn’t been designed to be viewed using a device with touch input.

5) You said in your talk at Blackberry Devcon that you are using localStorage to cache your JavaScript libraries and some of the images. Why not use WebSQL or IndexDB for that? Isn’t the synchronous nature of localStorage slowing things down?

No, actually localStorage is considerably faster than WebSQL (we are yet to use IndexedDB because it’s not supported on some of our target platforms). The time required for a lookup by key in localStorage is many times less than the equivalent SELECT statement on a WebSQL table. It’s true that it’s synchronous, but if the critical aspect affecting perceived performance is the time required to fetch data, which it often is, then localStorage offers a much faster response. it’s also typically reliable and relatively stable compared to the behaviour of WebSQL and particularly the HTML5 app cache.

6) You also said that localStorage uses UTF-16 instead of UTF-8. This means you can store two ASCII characters in one UTF-16 one and thus double the storage capacity, right? Can you share some code? This would be incredible to use for everybody out there.

Both localStorage and WebSQL use UTF-16 in webkit browsers, it’s one of many aspects of the implementation of these technologies that don’t make a lot of sense! We’re experimenting with some algorithms for compressing our data so we can make more efficient use of that storage, and one of those is to combine two characters into a single UTF-16 one. We’re not using that in production yet, but when we do we’re certainly hoping to open source it.

There are simpler things to be done as well. A cursory poke and prod of WebSQL tables suggest that column names are stored along with the value in every cell, so some attempts to increase efficiency are as simple as using single character column names. Clearly we ought not to have to do all this, but it’s the price you pay for dealing with bleeding edge features in browsers.

7) What would you consider the best start for someone when they want to build an HTML5 app? What are the first things to get sorted?

Decide ahead of time what you’re trying to achieve. I could be a pedant and say that making your site HTML5 is really just a matter of changing the DOCTYPE, so an ‘HTML5 app’ is really whatever you define it to be, and having a clear idea of that is a good place to begin. Are you building something just for touch, or for keyboard and mouse as well? Does it need to work offline? Will it be crawlable by search spiders? Will it work with JavaScript disabled?

There are some great resources like MDN, but we often find ourselves reading the HTML5 specs, and sometimes even the webkit source code to find out how something is actually implemented.

8) Can native and web apps be the same thing?

Technically, I guess not – strictly speaking a native app is complied code running directly on a platform, but the hybrid model seems to be getting ever more popular, and I often see apps which are thinly veiled web browsers. If you look at it from the user perspective and say, can a web app feel exactly like a native app, I don’t see why not. The challenges are greater because of the diversity of uses that web technologies are designed for, and the diversity of platforms on which they are used. And for uses such as gaming, native code is always likely to run faster and have deeper access to the OS.

But for applications like publishing, which after all was the original purpose of the web, web technologies do provide support for most of the user experience concepts that we need.

9) What about testing? How did you approach this? Do you have an array of hardware to play with?

It’s a nightmare. We had a local electrician built us a charging station where we could store all our devices and keep them charged all the time. We have around 45 individual devices in our team (that’s around 4 times more devices than we have people). We’re constantly looking at ways of improving our testing process, and we keep revisiting automated, on device testing, but we’re not using it in our build cycle as yet. Right now we have a team of very dedicated testers who poke and prod devices all day.

10) As someone who went through the process of building a big HTML5 app, what would you like to have from browser vendors to make your life easier?

A blithe answer is ‘How long do you have’, but in practice we have to accept we’re using freshly minted technologies and there might be teething troubles. The main things on our shopping list are: more frequent and aggressive browser updates (especially on Android, where the browser is the problem child of the mobile web world), a better and more reliable app cache, and hardware acceleration of CSS transforms.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)