Blog

Webmaker at Brothers For All

Naga IT Services
Filed under: Projects

This Saturday past, 28th June, myself and a bunch of volunteers headed out to Brothers For All in Langa to run another Webmaker event. Thank you Gavin, Andrew, De Wet, Jeremy, Simon, Trevor, and Nathan for all your hard work, and a huge thank you to Sihle (@sihletshaba on Twitter) of Brothers For All @brothersforall on Twitter for hosting us.

The event

We ran this event with a very similar agenda to our previous one.

The internet at Brothers For All is blazing fast, which helped a lot. On top of that, our students were really great. They blazed through the course and helped each other out a lot: they hardly needed us teachers!

At the end of the course, Sihle treated us all to some proper Langa braai meat from a place around the corner. It was delicious; thank you, Sihle!

The activities between the computer stuff

We used very similar activities to our previous webmaker event, again using some of the great ideas from Sharon Bowman’s Training From The Back Of The Room.

We started with “What makes a good web page?” Students placed stickies on the wall answering the question.

After lunch we tried to have a few more move-around-do-stuff activities to get the blood rushing again after lunch.

We started with “Take a stand.” We marked one side of the classroom as “Not so confident” and the other side as “Very confident,” and asked students to stand somewhere on the line that represented how they felt about the morning session. Then, we paired up students at the opposite ends of the scale, and gave them a few minutes to discuss what was good about the morning, and what was bad about it.

Then, we did a “beat the clock” activity: students had one minute to write down as many sticky notes as they could about HTML and CSS, based on the things they had learnt in the morning session.

We closed the day with a reflection exercise. Students got one index card each, and were asked to write down what the most valuable thing they learned was. Then, they were asked to form groups of four or more and discuss their cards.

And now?

The two weeks between the our two Webmaker event flew by, so we didn’t have time to make as many changes as we wanted to, or to have our teacher meeting to discuss the ups and downs of the previous one. At the moment, the next Webmaker event we have lined up is in September, so that gives us plenty of time to make some changes.

The CSS bits of Progressive Enhancement

Naga IT Services
Filed under: Industry, Process

At work the other day we were talking about Progressive Enhancement and feature phones, particularly in terms of CSS. The feature phones part of the chat led me to write up a short Dos and Don’ts of Feature phone design (written for designers more than developers). The PE part of the chat made me scribble up the following pictures.

Every web page looks like this. A base of HTML, with CSS layered on top, and JS layered on top of that. It’s a triangle because the balance should mostly be like that: lots of HTML, quite a lot of CSS, and as little JavaScript as possible.

Practically speaking, we chop things up a bit more than this, though.

First we load in a small file of simple CSS. Then we do some PE fancy magic testing stuff and load in Fancy CSS for fancy browsers.

Actually, though, even the fancy CSS file is splitty too. Inside the fancy CSS file we do more little tests and give fancier browsers fancier styles.

Technical details

The initial split between basic and fancy CSS files is done using a media query on a link element.

The basic CSS is loaded like this:

<link rel="stylesheet" href="/css/style.css">

All browsers get this stylesheet (and it contains simple CSS rules that all browsers will understand). The fancy CSS should be loaded like this:

<link rel="stylesheet" media="screen and (min-width: 20em)" href="/css/enhanced.css">

Since it’s qualified with a media query, it should be the case that only browsers that understand that media query (goodbye old Internet Explorer, and many older phones) load that stylesheet. However, Scott Jehl’s tests have shown that this isn’t the case: browsers are greedy and download all the stylesheets, even ones they will never use!

That’s not so great. Ideally we’d like to improve Front-end performance by using Filament Group’s loadCSS to asynchronously load our enhanced stylesheet (so that it doesn’t block page render), but that would mean everyone downloads every stylesheet. Instead we use Scott Jehl’s eCSSential. This lets us load the CSS file asynchronously (yay, performance!), and use matchMedia to test for (min-width: 20em) with JavaScript. Testing with matchMedia in JavaScript rather than than a media query on a link element works: browsers only download the stylesheets they need. (Of course, we also provide a no JavaScript fallback in a <noscript> tag, in case something goes wrong somewhere.)

You can see an example of this in action on my work in progress project, fufu (A future friendly front-end style guide that even caters for feature phones).

Gotcha: older Androids

The use of matchMedia has me a bit conflicted. Looking at matchMedia on caniuse.com, we see that this means that Android versions less than 3 and Opera Mini users won’t get the enhanced stylesheet. If we went the loadCSS route, some Android 2.* users would get the enhanced styles (which their browsers are capable on displaying), but we increase data costs for all users, because everyone loads all the stylesheets.

Opera Mini, JavaScript, and mustard

Naga IT Services
Filed under: Industry

The rather talented Alex Maughan was in our office the other day, and we got to chatting about Opera Mini and JavaScript (as FEDs in our situation are often want to do). Our chat got me thinking a bit.

Opera Mini is a strange little browser. There are Android, iOS, and Windows version, but the biggest market is the version that runs on low end feature phones. Opera claims that it “works on almost any phone” and in my experience that’s certainly true.

I call it strange because despite running on low end tech it’s quite advanced. The article Opera Mini and JavaScript by Tiffany Brown on the Opera dev blog does a great job of breaking down exactly what (and how) Opera Mini handles JavaScript. More strangeness comes in because of the way it handles things: everything requires a server round-trip. This complicates matters for things like off-canvas / side drawer menus.

Feature testing versus device detection

What Alex and I were discussing was how to solve a particular conundrum. A feature-detection test on the JavaScript required to show / hide an off-canvas menu would pass on Opera Mini, but because of the server round trip, the experience would be a bit wonky. So, do we resort to device detection, which goes against our general Progressive Enhancement principles? In her article, Ms Brown says

99% of the time, you should use feature detection to determine whether a browser supports a particular feature or API. Yet sometimes browser sniffing is the right choice.

and I’m thinking that for Opera Mini, that might indeed be the right approach. I want to take a mustard cutting approach: probably using localStorage (support for localStorage on caniuse.com) as the yardstick for “a higher end browser,” and load in the JavaScript for those only: that would exclude Opera Mini.

However, Opera Mini exposes a window.operamini object. Although this is still basically the same as device detection, it feels less horrible.

Conclusion

I’m still not sure, to be honest, but I’m going to stick with my mustard cutting for now. I quite like the combo of localStorage and querySelector: that gives me a set of fairly modern, fairly capable, browsers as a first pass.

Webmaker at the Bandwidth Barn Khayelitsha

Naga IT Services
Filed under: Projects

On Saturday 13th June, myself and a handful of intrepid volunteers (huge thank you to Steve, Deb, Brad, Ian, Gavin, and Nathan!) headed out to the Bandwidth Barn in Khayelitsha to run a Mozilla Webmaker event. It was great fun, despite a few stumbling blocks!

The agenda

The course was an introduction to HTML, CSS, and JavaScript, using a bunch of things from Mozilla’s Webmaker directory, all ready and ripe for remixing. The plan was that in the morning students would look mostly at HTML and the structure of a web page, then in the afternoon look at fancier stuff with CSS, with a smattering of JavaScript near the end for the very fast students.

The experience levels of the students varied more than we were expecting, so we strayed off the course and into a more computer literacy kind of direction for some students. I tried to put in some extra, real world, activities in to the agenda (cribbed from Training From the Back of the Room).

How the event came together

After some discussion with Baratang (Miya, Founder of GirlHype, Head of the Transformation Portfolio at Silicon Cape, and Business Development Manager at CiTi), we agreed to run a Webmaker event (rather than a Railsbridge or something similar). I spent some time reading and thinking about Mozilla’s Web Literacy guide. That led me on to Mozilla’s excellent Event Resources page, and on to their Medium Event guide (since we were aiming for 30 students).

From there, I went through the teaching kits that they have prepared on their Teaching Activities page, and started to think about making a new remix of activities just for this event. I plowed through the Webmaker directory, started a remix of the Make Your Own Teaching Kit page, and ended up with the course that we ran on Saturday.

And now?

The teachers are going to gather and knock our heads together to discuss ways to make the next one better (like we do for RailsBridge) and make our next event better for the students. The next Webmaker event is already queued up! I’ve agreed to run a workshop for Sihle at Brothers For All at the end of this month. Now to round up some teachers!