interviews

A Web for Everyone: Interviews with Web Practitioners — Fyrd

In recent posts, we’ve explained why it’s important to make the web work for everyone. We’ve spoken with several top web developers about how they do that. And in between, we’ve shown how browser makers can advance compatibility by adopting living standards. Today we’ll show how a single individual can dramatically improve the tooling space, helping to make the web work for everyone.

In 2015, we asked MDN visitors which tools they use most when working on cross-browser compatibility issues. Three quarters of respondents mentioned good reference materials. 65% of respondents said they use MDN as a cross-browser compatibility reference, and 64% said they use caniuse.com. No other reference sites came close.

Like MDN, caniuse.com is an open-source project with hundreds of contributors. Anyone can fork and PR the caniuse data or adapt it for use in a brand new tool (examples). Building new tools in this space is important and valuable: More than 25% of developers said they want to make their sites more compatible, but they don’t because they need better tools — for example, automation and linting.

Helping web developers is what motivates Alexis Deveria (a.k.a. @Fyrd), the developer behind caniuse.com. Alexis is a web developer at Adobe by day and a champion of cross-browser compatibility by night. He took a break from reading up on the latest browser esoterica to talk with us about compatibility.


Fyrd

What inspired you to build a website devoted to browser compatibility? Was there a specific experience that got it started? What motivates you to keep it going?

I started the site in 2008 because around that time various web browsers started implementing a number of interesting new technologies, especially around HTML5 and CSS3. However, support was sporadic across browsers and there didn’t seem to be a central location to find cross-browser support. So I created a page that listed about 10-15 of such features. As the page slowly became more popular I started adding to it and making it more interactive until little by little it became the full-fledged browser compatibility site you see today.

My motivation to keep it going revolves around a few things, firstly its popularity: so many people visit and rely on it today that it would feel irresponsible to give up on it. It’s also my most successful and longest-running project, something I’m very proud of. Then there’s the fact that it forces me to stay up to date with web tech developments which helps with my day job and finally there’s some ad revenue which always helps.

Caniuse includes Statcounter or Google Analytics stats to help users determine how much of their potential market can use a particular feature. Do you think most developers are basing technical decisions on a market formula like this? What percentage of feature adoption in the market do you think developers are looking for when they decide?

Yeah, I imagine a number of developers take the usage % rate to determine whether or not they can use a feature, though I suspect it’s very much relative to the different factors involved, like what type of feature it is, how important the feature is to have, whether or not it can be polyfilled, etc. My guess would be that most developers don’t just have a specific cut-off percentage for all features, but I haven’t heard one way or the other.

Have you heard from developers that they use Caniuse to help convince their bosses or stakeholders to take a particular technical direction?

I’ve heard of a few of such cases, yes. Which is great of course, especially when they can start using features they’d otherwise be uncertain about using.

What other factors do you think developers should consider — aside from the size of a feature’s potential market — when deciding whether to use a particular feature?

Being on the lookout for partial support and buggy support is important… While in general bugs aren’t blockers, it’s always good to be aware of potential pitfalls. There are also cases where a feature may be deprecated and eventually removed from a browser, particularly for proprietary technologies and features that haven’t received much cross-browser adoption. Thankfully it’s pretty rare for that to happen, but it’s still worth looking out for.

If you could magically make one feature of the web platform 100% compatible across browsers and devices, which would it be?

Wow, just one? If we’re talking just in modern browsers I would go for CSS Grid Layout. Layout’s been one of the biggest paint points in web development and I believe having 100% cross-browser support there would be brilliant. If I could also perform magic on older browsers it would be Flexbox for the same reasons. Thankfully in modern browsers it’s looking quite good already.

Caniuse is an important part of a developer’s toolkit when building cross-browser compatible sites. What other tools or techniques do you think every web dev should consider incorporating to help them build compatible sites?

Using services like BrowserStack or Sauce Labs is incredibly helpful in easily testing on older & mobile browsers, though they require a paid subscription. I’d also recommend becoming familiar with each browser’s own development tools. They’re all good, but it takes some time to understand how to do the same kind of debugging for each browser. Also when using a new technology make sure you do your research beyond Caniuse. Cross-browser support can still come with gotchas, so read MDN, search for blog posts on the subject, etc.

Browser compatibility continues to be one of the biggest challenges in web development — it’s hard! Do you think it’s something a new tool could solve? What would the tool do?

It would be cool if there was a all-rendering-engines-in-one browser where developers could easily switch between them to test their site. In particular this would be useful if it included mobile browsers and older versions… but I can’t see that being anything more than a fantasy, so tools like BrowserStack are likely the closest we’ll get to that.

More ideally, and perhaps more realistically, it would be nice if browser makers would spend more time cooperating on writing tests and ensuring reliable support for technologies so certain types of cross-browser issues wouldn’t occur in the first place.

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

It can get ugly, messy and complicated. Don’t make any assumptions about what will work cross-browser until you’re familiar with it. The good news is that for many basic things cross-browser compatibility is so much better than it used to be. Together with the state of developer tools these days, there’s a lot to be thankful for.


Tips from Alexis’s interview

  • If you see a gap in tooling, you’re probably not the only one. Consider building or contributing to tools that help advance the practice of web development and make the web better for everyone.
  • Don’t assume new features work cross browser. Read about them and experiment with them before committing to use one on a public site.
  • When trying to understand a new web feature, cast a wide net: Look things up on caniuse.com and MDN, and pay attention to other sources (e.g. blogs) too.

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)

A Web for Everyone: Interviews with Web Practitioners — David Walsh

We’ve heard now from Rachel Andrew, Chris Coyier, and Belén Albeza. Each of these great web developers offered ideas for accomplishing cross-browser compatibility. The fourth interviewee in our web-compatibility interview series brings some new tools to the table.

David Walsh (@davidwalshblog) taught himself HTML, CSS and JavaScript at a young age, and soon turned those skills into a vocation. He started blogging about front-end development after landing his first job in the field. Now, a decade later, David’s blog is daily reading for tens of thousands of web developers who go there for tips, tutorials, and reflections about the life of a developer. David has spoken at JavaScript conferences around the world including LondonAJAX and BrazilJS. He works as a front-end developer and evangelist at Mozilla.


David Walsh

David, what does cross-browser compatibility mean to you?

Cross-browser compatibility means functionality and design working across not only different desktop browsers but also browser apps on different mobile devices, sometimes extending to gaming machines like the Xbox One.

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?

Working with some bleeding edge APIs at Mozilla, including Service Workers, WebVR, and A-Frame, cross-browser compatibility is something I have to think of often.

Cross-browser compatibility changes meaning but has always been present.

Earlier in my career I would also think of cross-browser compatibility but it was a different environment: IE6 had stalled, user-agent checking was commonplace, and both WebKit/Safari and Firefox were implementing features with their own prefixes, making using new features difficult.

Cross-browser compatibility changes meaning but has always been present.

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

Mozilla properties are visited by millions of users on different browsers, devices, and variant versions of each, meaning that cross-browser compatibility is a must. Also the idea that everyone deserves the same experience if possible.

Everyone deserves the same experience if possible.

Could anything convince you not to make that effort? What?

I suspect that some developers and/or organizations may see cross-browser compatibility as a bloat in time and cost. Luckily, the browsers have come together on the importance of standards and are roughly on the same timeline with features, so unless you’re using bleeding edge capabilities, cross-browser compatibility isn’t as difficult as it used to be.

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

Absolutely, especially in the days that I worked at a small agency.  Cross-browser compatibility was seen as a time-consuming task, one that the analytics didn’t justify. I made the case that cross-browser compatibility would “future-proof” sites in case new browsers came along, and I was right: Chrome debuted with a WebKit engine, quickly took hold. Mac users (Safari) were no longer the only users of the WebKit engine and set of style/feature differences.

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

Yes — the growth of Chrome! Chrome not only used WebKit but then moved to its own engine and started implementing features on its own timeline.  This all seemed to happen fairly quickly and it was very eye-opening to me to see!

You’ve blogged a lot about tools — for example, just this summer you talked about Slimer.js, Phantom.js, and Wraith, among many others. Which tools (or techniques) would be at the top of your list for coding compatible sites or testing for compatibility?

Selenium testing is a great place to start, regardless of which abstraction you use on top of it.  I really liked Slimer.js, Phantom.js, and Wraith, as you’ve mentioned. The truth is new tools are popping up all the time!

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

I would tell them they’re incredibly lucky to have missed the early days of browsers doing their own thing!  They should start with the mindset that cross-browser compatibility (outside of bleeding edge features) is a must, and that if they start with that attitude, they’d always have it.


Tips from David’s interview

  • Don’t overestimate the difficulty of making a site compatible across browsers. Cross-browser compatibility isn’t as hard as it used to be.
  • Try automating parts of your browser testing using command-line tools like Slimer.js, Phantom.js, and Wraith.
  • Functional testing with Selenium — using multiple browsers, of course — can make it easier to discover browser-breaking bugs in new code.

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)

A Web for Everyone: Interviews with Web Practitioners — Belén Albeza

For the third interview in our cross-browser compatibility series we talk with Belén Albeza (@ladybenko). Belén is an engineer and a game developer who works on developer relations at Mozilla. She is the author of several books about web development, including “Power-up Your Front-End Development with Grunt” and “XHTML + CSS ¡de una maldita vez!” She is a frequent speaker at conferences on topics such as game development, Web APIs and more. Next week she’ll speak at View Source 2016 in Berlin! She also contributes often to Mozilla Hacks.

We’ve heard from two great web developers so far about how (and why) they integrate web compatibility into their workflows. Two weeks ago, Rachel Andrew said, “I’ve always worked from the assumption that the web is for everyone.” Last week, Chris Coyier said he is motivated to make cross-browser compatible sites by a simple economic reality: “People pay for websites that work for them.”

What motivates Belén to make the web work for everyone? Read on to find out.


Belén Albeza

Belén, what does cross-browser compatibility mean to you?

It means having a website or a web app that is functional – not necessarily identical – across different browsers.

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?

You always have to think about that. It is hard, however, since it’s natural to do 90% of the development under the same system. The only shortcut to this is to use web standards, so you know that your code will have a good chance of working in other browsers and systems, but you still never know for sure until someone tries it in a real browser, on a real device.

The only shortcut is to use web standards, so you know that your code will have a good chance of working in other browsers.

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

From my point of view, cross-browser compatibility is not a nice bonus to have: it is a must. You just cannot afford to have your product not work in one of the major browsers (or OSes). So I don’t see it as “extra effort”, I see it as “mandatory effort”.

Could anything convince you not to make that effort? What?

Cross-browser compatibility is not a binary switch in which you either have it or not – it is a spectrum. I consider it mandatory to have the product work under major browsers (Chrome, Firefox, Edge, Safari, Android Browser) and in major OSes (Windows, Mac, iOS, Android). Beyond that, unless it is a client requirement – like legacy support for older systems/browsers – I think that making sure that your code complies with Web Standards is a good sanity point. Most of the time you don’t have the resources to test in every browser, on every system, on every device.

There is also the issue of needing a particular feature that is core to your product, for instance, WebRTC, Websockets, or Web Audio. In this case, you are making a conscious decision or leaving out browsers with no implementation or a partial one.

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

My experience so far has been usually the opposite: clients or product owners wanting to support as many browsers and systems as possible! I have had to convince them to ditch support for obsolete browsers so our code base could be more modern and smaller.

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

In one of my previous jobs we were developing a web app and we used both Firefox and Chrome for development. But these were the regular versions of the browsers. We built a release candidate of our app and patted ourselves on the back… just to find out the next day that the QA team had found a really nasty bug in our web app! How that could be?

Well, it turned out that the day after we submitted the release candidate for QA, a new version of a browser was released, and it fixed a bug that we had a workaround for. And this workaround – which was no longer necessary – was causing a bug! From that day on, we added the nightly builds of Chrome and Firefox to our development stack of tools, so we knew what to expect in the future!

You’re speaking this September at View Source in Berlin. Your session is called, “You might not need a CSS framework.” Do you think frameworks make cross-browser compatibility better or worse? Does any framework stand out as particularly good for compatibility?

I think that framework creators have a huge responsibility with respect to cross-browser compatibility. If a framework only supports a subset of major browsers, and somehow it manages to become extremely popular… the Web would be doomed. My recommendation, in general, is to avoid the use of third-party frameworks except in very specific circumstances (like developing a prototype).

You’ve done quite a bit of work with HTML5 games. What special compatibility challenges do HTML5 game developers face? Do you use a different set of tools for preventing/debugging compatibility issues in HTML5 games?

It is challenging in many ways: performance varies across browsers, across devices… There are also some quirks you need to be aware of: for instance, different browsers support different formats for audio files, some mobile browsers require a user interaction to be able to play sounds, etc. But you have similar issues when creating native games, because not all devices are equal, do not perform the same and have different hardware capabilities!

When working on a commercial game there is usually a QA stage where the game is tested on different devices and OSes – you would “just” need to add different browsers as well. Now that I make games on my own, I pick a game framework which is known for good cross-browser compatibility (Phaser) and test the game on the handful of devices I have at home.

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

This is not an option, it is a must. You cannot afford to lose 50%, 40% or 30% of your potential audience. You have to care! And caniuse.com works wonders 😉

You cannot afford to lose 50%, 40% or 30% of your potential audience. You have to care!


Tips from Belén’s interview

  • Cross-browser compatibility does not mean making things look identical in every browser — it just means making them usable for everyone.
  • The only shortcut for building a cross-browser compatible website is to stick to standards.
  • Remember to test your site or application on the nightly versions of browsers, which include features soon to land in release channels.

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)

A Web for Everyone: Interviews with Web Practitioners — Chris Coyier

This is the second in a series of interviews about web compatibility with web practitioners. This week we caught up with Chris Coyier (@chriscoyier), prolific web developer and writer behind CSS-Tricks, Digging Into WordPress, and the ShopTalk Show. Chris is one of the founders of the code-snippet demo site CodePen. He recently published a book about SVG. And now he’s here to talk about web compatibility.

These interviews follow up on our recent article, “Make the Web Work for Everyone,” urging 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.

In our first interview, Rachel Andrew said making a website work across browsers is part of doing her job well; she said it can even be “fun and liberating” to use new browser features without breaking the web. Let’s see if Chris Coyier agrees.


 

Chris Coyier

What does cross-browser compatibility mean to you, Chris?

I think the term itself is pretty clear: Make stuff work in many different browsers. What those browsers are is certainly different from team to team. Even people whose goal is extreme cross-browser compatibility have limits. Not a lot of people worrying about Netscape Navigator these days.

How often do you have to think about cross-browser compatibility?

I think about it less and less over time I think, but that’s not due to my skill in fixing cross browser issues increasing, its more that browsers are more and more consistent all the time. It’s still pretty easy to waggle fingers at certain inconsistencies, but it would be hard to argue we’re worse off now than we were a few years ago.

Still, I’d say in my life of “actually building stuff” it’s at least a weekly occurrence that some cross-browser consideration needs to happen. And because of working on the content on CSS-Tricks, it’s almost a daily consideration. On a reference site, it’s poor form to talk about browser features without mentioning support.

Last summer, Geoff Graham wrote on CSS Tricks that, “It’s rather expected of us that we know how to build websites that can work cross-browser.” Do you think employers and the market really demand this knowledge from developers? Do they expect it of junior devs, or is it more of a senior-level skill?

Front-end web development is a job. Knowing about, testing for, and fixing cross browser issues is part of that job. I’m not sure I would expect a junior dev to be super skillful at dealing with cross-browser issues out of the gate, but I would expect them to be open to learning about and dealing with those issues. And at levels beyond junior, it would be a pretty big red flag if a front-end dev could or didn’t want to deal with cross-browser issues.

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

Money. People pay for websites that work for them. Here’s a little example: Just last week we were working on some drag-and-drop functionality in a new part of CodePen. Worked great in Chrome, didn’t work in either Firefox or Safari. Tim Holman, one of our front-end devs, had to spend a good part of a day implementing different fixes for both. Good thing we did that before launch, otherwise we surely would have turned some potential customers off.

I don’t feel compelled to fix cross-browser issues because of some holy decree that all experiences be created equal. It comes down to money and customer satisfaction.

Could anything convince you not to make that effort? What?

If the cost-benefit guess is way off. If I guess that fixing a cross-browser issue will take a month of development and help 0.1% of customers, I can do some scratchpad math and probably come up with a decision not to do it. Thankfully most issues aren’t that far off.

Even though I do believe “it’s part of the job,” I would also say that it’s a rare developer that really loves doing that kind of work. I can say for myself, I enjoy the moment of solving the problem and closing the ticket, but the journey there can be demoralizing. I’d be cautious about doling out too much of that work to any one dev.

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

It’s usually the other way around. It’s been me making a site only to send it to a client and have it not work the way I thought it would for them. So it’s them schooling me on cross-browser compatibility.

If I had to be part of a “convincing” session, I’d probably approach it as pragmatically as I could. Let’s look at some data and pick a reasonable spread of browsers to support and hit those targets.

Can you think of a particularly vexing or interesting compatibility bug you’ve encountered? On what site/product? Did it go live, or did you catch it before it went live?

One came up for me a few weeks ago. A person wrote in to me telling me that CSS-Tricks was very hard to scroll. I’ve never experienced it before and I was having trouble replicating it. I’m aware that I only have one dev machine and it’s a pretty souped up MacBook Pro, so I wasn’t doubting anything, I just couldn’t replicate it or dig into fixing it.

She sent me videos of the issue, which made it very clear. Chrome was fine. Firefox was fine. It was a special browser she was using called Pale Moon. It’s only for Windows and it’s not available through my normal “test stuff on Windows” tool.

In reading about the browser a little, it talks about how one of its features is optimizing resource usage. I’m sure that’s a great thing in most cases, but it made me think that if somehow CSS-Tricks was asking for more memory than Pale Moon was willing to give it, that might cause the issue. What is painted up and down the entire page? The background! The background on CSS-Tricks is a combination of CSS gradient and SVG. Not particularly memory-light unfortunately. To test, I had her set a user stylesheet to remove the SVG, and it worked great.

I probably won’t change the current design just for Pale Moon, but in a redesign, it will probably push me toward doing something simpler for the background.

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

I feel like every time I run into a cross browser issue, it pushes me toward doing less and less fancy things. I love experimenting with new stuff, then when it comes to production stuff, my typical thought is, “what’s the most basic tried-and-true way we can pull this off?”

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 dev incorporate into their own?

Modern browser developer tools have gotten pretty good at simulating different viewports, connection speeds, and emulating mobile headers, but what they support feature-wise is pretty baked in. I know I open up my iOS Simulator a lot to get a “true look” at Mobile Safari quite a bit, and the fact that I can use Safari’s developer tools to poke around in there is great.

I really dig how BrowserSync allows me to open a dev site on a local network with any other device, so I use that a good bit.

My main cross-browser testing tool though is CrossBrowserTesting.com. It’s pretty amazing.

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

If your job is front-end development, this stuff is definitely your job. If you roll your eyes at it, it might not be the job for you. There is a certain amount of empathy required in all things web, so if you can’t extend yours to understand that people use different browsers/platforms/version, this does not bode well.


 

Tips from Chris’s interview

  • When debugging a compatibility bug, the first step is to completely understand the browser environment it appears in. What OS? What device? What screen size/orientation? What browser? What version?
  • If in doubt about whether a feature will work for your audience, look for more “tried and true” ways to implement the necessary functionality.
  • Learn to use the advanced features of modern browser developer tools. They can emulate connection speed, screen size, and header differences.

 

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)

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)

A different approach to conference Q&A – Interviews

A few weeks ago was Highland Fling, a conference in Scotland organised and run by a very enthusiastic person, Alan White. I spoke twice at that event in the past and one thing I loved most about it was how it handled the Q&A of the audience.

The issues with Q&A

After-talk Q&A is always a pain to get right. There are a few issues that keep cropping up:

  • People are too afraid to ask a “probably stupid” question in front of the rest of the audience (funnily enough a lot of times this is the question a lot of others have but are as afraid to ask)
  • People asking questions use the opportunity to profile themselves or their company/product instead of asking a valid question (thus wasting everybody’s time)
  • Speakers and/or the audience can’t hear or understand the question (and speakers need to repeat it so it gets recorded/is heard by everybody thus using up even more time)
  • Speakers can’t see the audience properly (lights in their eyes) which means some half-hearted requests don’t get recognised
  • The people asking questions are asked to wait for the microphone to be comprehensible to everybody which takes up time (and not everybody knows how to handle a mic)
  • Interesting questions at the beginning of the talk get forgotten halfway through
  • Speakers get stuck answering one question or deviate rather than answering swiftly and getting more questions in

The Highland Fling way

The Fling does it differently: instead of having an open Q&A session after the talk the conference has a moderator who not only introduces the speakers but also does a 20 minute interview with them after the talk. Conference participants can tweet questions to the interviewer during the talk. This works around most of the issues mentioned earlier.

This year I was lucky enough to be the moderator/interviewer.

interviewing at highland flingOriginal photos by Drew McLellan

As you may know, I have a background in radio where I spent a lot of time interviewing people on the phone and live. It was a lot of fun going back to that and especially interesting to have a mixed group of speakers all with different specialist topics to chat about.

Judging from the Twitter feedback at the conference I must have done a good job, and it was great to see speakers be more relaxed when they sit on a sofa and know some questions will come rather than hoping there are some.

I think more conferences should adopt this idea.


View full post on Christian Heilmann’s blog – Wait till I come!

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

Sales – Scheduling Sales Interviews

AL-Mobile, lifestyle. We continue to grow and have an immediate need to fill several positions in your area. We are looking for both entry level and senior level applicants.   Benefits & Rewards –          Free renewals and free quality weekly leads –          Additional residual earnings –          Qualify for benefits like major medical health insurance from Blue Cross/Blue Shield, retirement plan pension View full post on Monster Job Search Results (mobile)

View full post on WebProJobs.org

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

Sales Interviews – Now Hiring

AL-Mobile, Begin your new career with us. We are setting up interviews this week! Enjoy record sales with American Income! Our third record year in a row, we have an immediate need to fill several local positions. Do you have motivation and the desire for a great career, but you just can’t find the one that pays well and rewards you for hard work? We need to fill several local representative positions THIS W View full post on Monster Job Search Results mobile

View full post on WebProJobs.org

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