Why isn't our warning banner based on feature detection?

In my last post, I showed how we display a banner above Coursera to users on explicitly unsupported browsers, to warn them that the site is known not to work well on them.

After my post, Kyle Simpson, a well-known web developer and creator of the talk "Browser Versions are Dead", put together a post about why he thinks browser version detection should be avoided, and feature detection should be used instead.

He has some great points in it. Generally, the web developer community is trying to move towards using feature detection instead of user agent sniffing to warn users and degrade website functionality. We try to do that at Coursera where it makes sense for specific features (we deliver video via Flash if you don't have native HTML5, e.g.), but we determined that it's not practical to do that for our cross-site warning, for a few reasons:

• We would have to test for *a lot* of features, and those tests would take time on page load. We could cache the results of those tests in a cookie or localStorage, and so there would only be a one-time cost. But if the browser upgraded and suddenly did start supporting a feature, we would need to know to re-run the tests - and as far as I know, the only way to know about a browser upgrade is via user agent sniffing and some knowledge of how versions work.
• We couldn't just tests for features, like "does canvas work", we would also have to test for performance. We've seen some older browsers simply can't handle the amount of JavaScript that we use or simultaneous XMLHttpRequests that we send off, and they will hang. How does one test for a hanging browser yet still recover? I imagine it's possible, but I don't know if it's easy.
• I have personally been bitten by feature detection in the past and now approach it cautiously. There are some features that developers have put a lot of approach into figuring out rigorous feature testing for, like all of the tests in Modernizer.js, but there are other features that are newer and whose detection quirks are less known. For example, when I tried to use FormData for sending a form, I checked for the existence of it on window. Unfortunately, it existed in Safari, but Safari wasn't actually setting the data, and since the FormData API had no accessors, there was no way that I could feature detect it. I resorted to user agent sniffing instead, blacklisting that Safari version for that feature. That is just one example, and there have been others.
• We have limited resources. Yes, we could try to solve the problem of doing performant, comprehensive feature detection tests, of caching them and figuring out when to update our cache, doing performance tests, and determining the cross-browser feature detection technique for every single feature we use. Or, we could focus our time on our actual product, and decide that it's okay to say "Alright, we know we don't work in these older browsers, so let's just tell users what we know."

Something that I've come to appreciate in my last 8 months as engineer is that we can't always do what's perfect and ideal. Sometimes, we have to do what is practical and be cognizant that there is a better way, and when the time has come, try to move to the better way.

Warning Users on Older Browsers

As web developers with finite time and resources, we have to make a conscious decision of which browsers we will support. Every supported browser means additional bugs to fix when things don't work, and additional browsers to do both manual and automated testing in. And as you all know, some browsers are much harder to support than others (*cough* IE6 *cough*).

At Coursera, we have decided to support IE9+, Firefox 12+, Chrome (any version), and Safari 5+, and we document that decision on our help site.

Letting users know

But, our website still works in other browsers, so we do not want to block a user from using it completely, if that is their only option. We do want them to be aware that they are on an unsupported browser, though, so that they are prepared for some features to not quite work. Since 99.99% of users do not consult the help site before they use a website, we need to find a way of messaging this to them when they're on the site. Pop up a modal? Make them sign an agreement that they know they're on an older browser? Float a banner somewhere? Turn everything bright red?

Our approach: the top banner

We opted for the top banner approach, which has become a fairly common paradigm on websites for warning-style messages. We have a little JavaScript browser banner library that we can include on any of our sites. It starts by checking the user agent to see if the user is on an un-supported browser. I debated between checking if they're on a whitelisted browser versus checking if they're on a blacklisted browser, and I went for the latter approach. I figure that we can always add more to that blacklist, if we see many people on a particular old browser.

If the user is on an unsupported browser, then it animates a banner sliding down with the message "You are using an unsupported browser, so some features may not work. Please upgrade to a modern browser." We link to our help site so that users can read which browsers we support and hopefully decide to download one of them.

You can see the full code for our banner in this gist, a demo of it in this jsfiddle, and a screenshot below:

Is it enough?

We've had users ignore the banner in the past (as evidenced by oblivious forum posts) and have been iterating on it to increase its obviousness (increasing the font size, adding the push-down animation), but we will probably still have users that ignore it and get upset when something doesn't work.

In particular, we have some parts of our class sites that work much better than others in older browsers (like lecture watching vs. peer graded assignments), and we have debated whether we should have a harsher warning in some places versus others. But, we decided that our users are likely to eventually experience both features, so it is the responsible thing to warn them everywhere.

If anything, we may make the warning even more obtrusive in the feature, like a modal which forces the user to acknowledge its existence before continuing, to make sure that users do not get started on a class in a browser and think that they will be successful, only to discover later that there are some aspects of the class that they just cannot complete at all.

So, that's where we're at right now. I'd love to hear about other approaches to browser messaging. Let me know in the comments!

My Lasik Journey

I started wearing glasses when I was 8 years old. I'm pretty sure my attraction to big shiny CRT monitors and my tendency to stare directly at the sun contributed to that fact. I hated glasses, because I already felt like a dork, and when I wore them, I felt even dorkier. (See photo for evidence →)
So in late middle school, when it is of the utmost importance for a young girl to feel as least dorky as possible, I started wearing contacts. I hated actually putting in contacts - I'd come out of the bathroom with tears streaming down my face every time - but once they were in, I could keep them in for months and months, never taking them out, and my eyes would never dry up. I could even wear just one contact at a time, and I could see just fine - as I would oft demonstrate by doing a one-eyed cartwheel down the balance beam.
Fast forward 15 years, and things change. Now, my eyes notice the contacts, and I find myself noticeably affected by how dry they are. I even go to bed early just to give my eyes a rest. And I still hate glasses. As much as people tell me, "but glasses are cool!", I immediately feel like a dorky 10-year-old again when I put them on, and my confidence starts to wane.
Last week, my glasses broke, my contacts ran out, and I decided that it was time to do something I've been thinking about for a long time: Lasik surgery. I don't want my eyes (or lack thereof) to be something that I think about every day for the rest of my life, now is as good as time as any to start the rest of my life. Plus, I have health insurance again, thanks to Coursera. ☺
So, here's what I've learnt in my Lasik journey so far, and I hope that it helps you with your own decisions.

What is Lasik?

As it turns out, there are multiple types of Lasik-esque surgeries. Here's my layman's description of them, but note, I'm not a doctor!

• Lasik: In this surgery, the doctor cuts a corneal flap using a microkeratome knife, and then uses a laser to shape the cornea to fix your vision. Most doctors do not offer this anymore (at least the ones I talked to).
• IntraLasik: This one is all laser, all the time. The doctor creates the flap using a laser, and then does the shaping with a laser. It is considered safer and more precise than Lasik, and is the preferred technique.
• PRK: In this surgery, there is no flap creation at all. Instead, the doctor reshapes the cornea by modifying the top layer of the eye. The healing process is longer and more painful for PRK, so it is only recommended if your eye's surface is already misshaped.

Will insurance cover it?

This was a big question I had, because I knew Lasik was an expensive procedure ($5K-$10K seems to be the range). What will my insurance actually cover? Apparently, in the VSP network that we're in for our insurance, we always get 20% off the procedure, regardless of which one we go with. And that's it. Oh, well, it's "elective" surgery, so I'll be thankful that anything is covered. (I could argue that I could potentially die one day while wearing glasses and biking in the rain at night, but alas).

What doctor should I go to?

After money, the big concern around Lasik is safety and success. It involves putting a freaking laser in your eye, after all. So, you have to figure out: who is the best equipped person to put a laser in your eye? I did my research the usual way- emailed my colleagues, tweeted out to followers, perused Yelp reviews. In the end, I got multiple referrals for Dr. Ella Faktorovich of Pacific Vision Institute, and after having a great chat with them on the phone where they answered all my questions, I was convinced.

Am I eligible?

Not everyone is a good candidate for Lasik surgery. Or atleast, that's what Dr. Faktorovich believes, so her office puts you through a series of checks first to make sure. It's the usual stick your head in a contraption while they shine lights on you thing, and they use the results to determine if you are a candidate, and for which surgery (IntraLasik or PRK). As it turns out, my eyes are "boring" (to quote their chief engineer, who put up with my never ending array of technical questions), which means that I get to go for IntraLasik, the surgery with the fastest recovery. Woot!

How much will it cost?

The cost varies per doctor, but for Pacific Vision Institute, the final cost for me will be $6900, which includes the 20% VSP discount, the $300 discount for coming from a referral, and a $300 discount for me coming from an awesome university (I think the doctor threw that in because her daughter goes to USC and I was sporting my Trojans shirt today!).

What's next?

My pre-op visit is next Tuesday, where they'll dilate my eyes and I'll try to avoid staring at the sun, and then my actual surgery will be on Valentine's Day. (Not to jinx myself but...) Best date ever?

How'd it go??

It's been four years, and I never updated this blog post to share the rest of my Lasik journey with the world. Why? Honestly, the surgery went so well, I soon forgot that I ever had glasses, contacts, or vision problems! Dr. Faktorovich led me smoothly through the surgery, talking me through the strange process of having an operation on my eye, and after a few weeks of follow-up eye drops, my eyes were better than ever.
I no longer have to worry about losing glasses or struggling to get my contacts in, and I can use my eyes all day without feeling strain. For me, Lasik surgery was a great success, and I'm so very thankful I had the savings to fund the surgery.
(If you end up going to Pacific Vision Institute and would like me to get a referral bonus, message me to let me know.)

GirlDevelopIt SF: Help us grow in 2013!

In my last post, I talked about how we started up GirlDevelopIt SF just 8 months ago in April, and thanks to the kindness of sponsors and the enthusiasm of volunteers, we had a great 2012. We've already started planning our 2013, with multiple events a week in January and some exciting new topics planned like Salary Negotiations and Data Modeling, and it's looking to be a great year.

Want to make it even better? Here are some ways you can help:

As an individual:

• Be a TA: We strongly believe in having an interactive component to our classes, so that students get the chance to actually try out what they've learnt and the opportunity to ask questions that inevitably arise. As a TA, you can help them answer their questions and clarify their understanding, and as a bonus, you'll probably learn something yourself! Many of our students go on to TA the classes that they themselves took, as a way of testing and solidifying their knowledge. If you want to TA a particular class, just send a message to the teacher and let them know.
  
  
• Teach a class: We have a vast array of topics that we want to teach our students - web development, version control, command-line, design, user experience, mobile, gaming, etc. If you feel comfortable teaching a particular topic (maybe it's one we already have curriculum, like HTML/CSS, or maybe it's a completely new one that you'd be willing to create curriculum for), please send us a message. We find the best teachers aren't necessarily the "experts", but the ones that have practical experience in the industry with the skillset, and can impart real world learnings and industry best practices to the students.
  
  
• Run a hack night: Our students learn a lot at the workshops (we hope!) but they need to practice what they've learnt for the skills to really stick. Many of them do Codecademy or Treehouse at home, but when they get stuck, it's harder for them to find the help online. So, we like to hold casual hack nights for students to practice around others. Typically, they're at a cafe with free WiFI like Epicenter or Panera, or they can be at the office of whoever is hosting the hack night. If you'd like to host a hack night (or a "code & coffee" if it's in the morning), please send us a message.

As a company:

First, a preface: Yes, we do charge our students a small amount, but it is lower than the other similar classes in SF, and is designed to be just enough to make GDI sustainable, but not necessarily profitable. When companies sponsor us, that means that we can support more students and make sure our teachers are adequately compensated for the vast amount of time they put into teaching. We feature our sponsors on the Meetup page and also thank them in the event descriptions, and of course, at the event itself.

• Volunteer your space: We've had a lot of great spaces for our workshops, but we can always use more - we don't want to exhaust our current spaces and hosts. We look for spaces that have tables with chairs where students can sit with other students, but also with enough room for TAs to walk around. Usually, we host classes around the SOMA area in SF, but we're starting to explore classes in South Bay and Oakland. Our classes are either on weekday evenings or on weekends, and sometimes stretch over multiple days. If you have a space in your office that you'd like to volunteer for a class or two, please send us a message.
  
  
• Sponsor our snacks: Our classes require a lot of brainpower - students learning programming for the very first time! - so we like to keep our students fueled with food when we have the funds to do it. For evening workshops, that means a light dinner and for weekend workshops, it's usually lunch and snacks. If you'd like to sponsor the food for an upcoming workshop, please send us a message.
  
  
• Donate to our scholarship fund: Many of our students are learning programming because they are in a low-pay position now and trying to transition over to development, so money is tight. We encourage those students to apply for a GDI SF scholarship, where they describe what they want to learn and how it will benefit them, and then we give them a free entrance to the class. Right now, the teachers have been giving up some of their own compensation to make those scholarships possible, but we can't keep doing that forever since our teachers need to support themselves as well. So, we are starting an official scholarship fund for the GirlDevelopIt SF chapter, and we would love for companies to contribute to that fund. When you sponsor a student, we will let them know who the sponsorship came from, and we will thank you on Meetup and at the event. If you're interested in sponsoring, please fill out this form and specify 'San Francisco' as the recipient chapter.

And hey, even if you can't help in any of those ways, you can help us by spreading the word. Let your female friends and family know about GirlDevelopIt SF and encourage them to take a class or two. Who knows, they may turn out to be the next great developer!

GirlDevelopIt SF: Thanks for a great 2012!

Back in April, I had the good fortune of discovering that the GirlDevelopIt organization was looking to create a San Francisco chapter, and they were happy to let me lead that up. We started slow, with an HTML/CSS workshop, then a JavaScript workshop, and then suddenly, we were holding workshops every week, with new TAs helping out, new topics being explored, and new friendships being formed at each of them. It's been an amazing 7 months, and I want to start this post by thanking everyone who's helped.

First, thank you to the companies (and the great people from them) that lent us their space and sponsored our fuel:

• Twilio and Meghan Murphy, who has hosted us 6 times now!
• SendGrid who provides both snacks and a space at the Hatchery, thanks to Adria Richards
• Voxer and Kit Cambridge, for hosting our advanced JS workshop series.
• Yelp and Julia Nguyen for hosting advanced CSS and JS workshops.
• Storify and Bo Hee Kim for hosting our inaugural NodeJS server-side workshop.
• SauceLabs and their engineers for hosting and teaching us all about Selenium and asynchronous programming.
• Twitter SF for hosting our very first JavaScript classes.
• Disqus and Anton Kovalyov for hosting our first HTML/CSS workshop.
• Mozilla SF and Sunny Lee for hosting hack nights and a workshop - it's pretty cool to be learning HTML at the office for one of the original browsers!

Next, thank you to the teachers that made learning possible and spent hours working on curriculum:

• Liz Howard, who started off TAing, then teaching, then writing a whole NodeJS 2-day class, and now she's helping to organize workshops for other teachers as well.
• Carina Zona, who put together an incredibly informative and interactive command-line Git workshop.
• Gwen Brinsmead and Sheba Najmi, who worked together to create an all-day UI/UX workshop.
• Michell Wetzler, who started off as a student and went on to create an Analytics overview workshop, complete with real data and data analysis.

And thank you to the TAs- many of whom started off as students - like Sharon Wong, Tripta Gupta, Regina Walton, Eva Zamudio, Sarah Adams, and everyone else who spent their free time helping our students learn.

In putting together those lists, I've realized just how many people have helped us get to where we are today. Here's where we are, in numbers:

• 796 members
• 20 workshops
• 7 hack nights

But, numbers, schnumbers. What really matters is the learning and the community that's forming around learning, and that's best shown in pictures and tweets:

So, there you have it: 2012 was a great year for GDI SF, and it was a group effort. I'm looking forward to an even better 2013, and I'll be writing on my thoughts for that in my next post.

Xtreme Makeover: Legacy Codebase Edition

At Coursera, we have two codebases that power our user-facing experience - the one behind www.coursera.org, where students browse and enroll for courses, and the one behind class.coursera.org, where students actually take classes. The latter is our oldest codebase, and is based on the code that powered the first version of Coursera (before we even had a name or a company), the machine learning class. It's built on PHP/mySQL and a custom routing/templating/ORM framework.

In the beginning, it probably had very little CSS and JavaScript, so the creators understandably didn't put thought into how to write the CSS and JS in a way that would be maintainable and scalable to a large codebase and team. Well, 50 classes and countless features later, it became a hodge-podge of PHP, HTML, CSS, and JS all entangled together with no conventions in sight.

But, it worked — so we didn't want to touch it. When we touch it, we risk introducing bugs or un-introducing "features" that we were unknowingly supporting before, and when students grades and instructors happiness are on the line, we opt for doing the safe thing.

We couldn't leave it unchanged forever, though. We had many usabilty issues (meaningless icons everywhere, hard-to-navigate menus) and we also wanted to improve the university branding. So our designer proposed a redesign of the user-facing interface, and when I set about implementing that redesign in the codebase, I realized that I could not bring myself to do the user-facing improvements without making some developer-facing improvements too.

Why? Well, as a developer myself, I find it frustrating to work in an environment that doesn't use modern tools (like CSS pre-processors) and best practices (like avoiding global variables). And, as I know we will be bringing on more developers soon, I want them to be surrounded by good examples of what our codebase should look like, and not think "Oh, I guess this is just how we do things around here." I also want them to enjoy working in any of our codebases and expect that they can apply the same best practices to all of them.

So, I set about on the behind-the-scenes redesign, and thanks to help from the rest of the frontend team, we were able to make a lot of significant improvements. Here's a round up:

JS Code quality:

• We moved all of the JavaScript into separate files (much of it was in PHP templates, and some of it was even PHP-generated, ick).
• We ran JSHint over all of our JavaScript files (not third party libraries) and fixed any issues that came up. (We had to guess with situations like " == 0" vs " === 0" what it was they actually wanted - which is why developers should use JSHint from the beginning!).
• We stopped using third party JavaScript libraries that were adding unnecessary bloat and were difficult to customize - like fancybox, which we replaced with our own much smaller modal library.

JS Performance:

• We made sure all of our JavaScript executed after the document ready event.
• We moved all of the <script> tags into the bottom of the page.
• We wrote a build task to compress all of the JS files.
• We wrote a build task to create a single compressed file of all the JS libraries that are used across most of the pages.

CSS Code Quality:

• We stopped using CSS class names that were short and ambiguous, like "title", and instead moved to prefixed, explicit names, like "css-forum-thread-title". We also only use IDs when needed for accessibility reasons, and instead prefer classes everywhere.
• We ported all of our CSS to Stylus. That means we can now take advantage of variables (like the URLs for our assets, which we can now serve off CloudFront), automatic vendor prefix generation (which will improve our cross-browser support), and extending (which means I can extend Bootstrap classes and avoid directly using them in our HTML).
• We started using box-sizing:border-box, which makes our height and padding calculations easier, but did require overriding the CSS for a few third party libraries.

CSS Performance:

• We created separate Stylus files for each functional area of the site, and we have one file that imports all of them, so that we can work in small files but still only serve one big file.
• We wrote a build task that compresses the generated CSS, so it's not actually that big.

226 commits later...! Now that we have our codebase in a better state, we can enforce our conventions on any changes that developers make in the future (via code reviews), and maybe future developers won't even realize that it was ever our legacy codebase. Maybe. :-)

Getting Kids into Programming

A local father asked for advice on what laptop he should get for his 7 year old daughter, who he wants to get interested in programming. That got me thinking about getting kids interested in programming generally.

Of course, I was a kid once, so I started by thinking about what got me into it. I first got interested in programming because it helped me solve a problem (I needed a mother's day card and we lived too far away from any physical stores, so I learnt to program a digital one) and I got even more excited about it because it helped me be creative in new ways (e.g. I could create digital versions of the games I would play in real life with my friends). So, at least for me, it was less about getting interested in programming itself and more about discovering what programming would enable me to do. Programming was not the goal, it was the way to get there. Now, after many years of programming, I am interested in the meta aspects of programming itself, like what makes for a good language and clean code, but I still value the output of my program more than the program itself.

So, that's the first thing I'd advise for parents who want to get their kids into programming: don't just tell them about programming, also expose them to all the crazy things you can do with programming, and the way that your programs can be used by anyone in the world. Maybe your kid isn't into robots or 3rd printers, but when you tell them they can make a game where their favorite cartoon character is the lead, that's when it clicks for them.

But besides desire, they also need the tools and the skills. I've written before about the different ways that aspiring programmers can learn online and in SF, but I was curious to find out what the most kid-friendly resources are out there. So I turned to everyone on Twitter for their opinions. Here's what they suggested:

Programming Languages & Environments

• Alice.org
• MIT Scratch
• Waterbear
• Isla Language
• Processing
• Processing JS
• Greenfoot Java Programming
• MIT App Inventor
• RenPy: Visual novel engine
• Inform7: Interactive fiction design platform
• Mozilla Webmaker Tools

Computer Science Lessons

• CS Unplugged
• Khan Academy CS

Books & Blogs

• Hello World: Computer Programming for Kids and Other Beginners
• Python for Kids
• Invent with Python
• LaurenIpsum
• Young Programmers Blog

Robotics & Electronics

• Lego Mindstorms
• Bristlebots
• Makey Makey
• Roominate
• SnapCircuits
• Hands-on Science with Squishy Circuits

Games

Jen Myers asked her Twitter feed for advice on game programming resources for her daughter, so I gathered these links from their answers:

• MineCraft: No programming, but the building mechanics involve logic.
• Little Big Planet 2: the authoring environment includes AI programming.
• Adventure Games Studio: "Minimal programming, lots of graphicky goodness."
• GameSalad: Aimed for non-coding, but coding is possible for more advanced users.

Now, I'm not a parent myself and haven't had any first-hand experience with exposing kids to programming. If you have, or if you're young enough to remember your own first exposure, let me know in the comments!