Month: October 2016

How the Web’s interface is broken

screen-shot-2016-10-10-at-1-05-48-pmHow often has this happened: you click on something you didn’t actually want to see (maybe because you were trying to scroll with your finger), causing an image to fill the screen obscuring whatever you were actually trying to read. Instinctively you hit the ‘back’ button to get back to whatever you were trying to look at.

And…you’ve lost everything. You’re somewhere else completely. You go back to the page you were on before Facebook. Annoyed, you try to go forward again, but you’re looking at an entirely different post. You scroll down, but the post you were reading is nowhere to be seen. What happened?

Let’s go back a few years, like maybe 15. I was making websites back in the days when dinosaurs roamed the web. Modern developers, in the middle of fighting over whether to use React or Angular2, might entertain themselves looking at this list of old 15-20 year websites moldering on servers that nobody ever bothered to update or shut down. They laid things out with tables. Tables!

If that doesn’t mean anything to you, let me explain. Back in the day, when you got a Photoshop mockup from a designer, the first thing you’d do is chop it up into little boxes, export them from Photoshop as jpegs or gifs (no pngs or svgs in those days). Then you’d use the HTML <table> feature to plan the page out in rows and columns. This was a hack; the tables tag was made to create, well, tables, like rows and columns with headers. But before browsers had consistent and reliable stylesheets, it was the only certain way to always get the layout you were looking for.

Dole/Kemp '96!
No, we can’t have those Republicans back.

But in the middle of laughing at the silly old animated gif backgrounds, you might notice something, as for example on this page for Dole Kemp ’96: before the page even finishes loading everything is in exactly the right place, even before any of the images loaded. And after it loads everything stays exactly where it’s supposed to.

There’s a reason for that. Back then, instead of using styles, every image had a HEIGHT and WIDTH attribute (yeah, back then some people capitalized their HTML too). In the days of 56k dial-up modems, every kilobyte that went over the was precious, so you exported the images at the precise right size and then set that through the attributes in a table.

Compare that to many framework-driven applications today, especially when you’re loading them on a phone. You’ll be in the middle of reading a paragraph, and it will jump 300-400 pixels above and below you. The Talking Points Memo site for example (whose content I love, by the way), is terrible at this; when I read it on my phone I feel I’m chasing the content all over the page.

Nobody uses tables to build pages anymore (except Visual Studio’s .NET templates, because Microsoft). Now people declare the size of their images using stylesheets, if they even bother. When they do it’s probably done dynamically, sometimes by resizing on the fly using Javascript.

Now let’s get back to the lost Facebook post you meant to read, and lost when you hit ‘back.’

Back in the primitive days of the Web, the back button was a reliable thing. It took you back to whatever you were looking at last. Sure sleazy advertisers could try to override it with Javascript, but you learned to avoid those sites.

But the back button won’t get you back to what you were looking at now. Why didn’t it just close the image and go back to the post you were reading? Because the image you were looking at is actually the same url that you were reading before (because Facebook is what developers today call a ‘single page application’). There was actually some little ‘x’ in the upper right hand corner of the screen that would have closed the image and allowed you to read what you were reading, but you didn’t see it.

Good old back button
Old reliable

Now it’s too late, because you went off Facebook. When you tried to go back, in the continuously loading application the particular post you were reading is far down the feed. Facebook has loaded twenty or forty new posts in the time you were away; there’s no way to know how far you’ll have to scroll to get back to where you were. And because of Facebook’s constantly shifting algorithm weighing what should and shouldn’t be shown, it might be gone altogether. You may never even get a chance to like your friend’s cat pictures or make an angry face in sympathy to her political rant.

But it has to be that way, say the developers as they look up from their scrambling efforts to learn whatever Javascript framework displaced the one they were using last year. It’s Web 2.0! Anyways, why don’t you just get the app?

Listen: whenever engineers tell you ‘it has to be that way,’ they are failing at their job. There is no technical impediment to making a web that works the way people expect it to. Instead of fighting over what Javascript superset to transpile from, maybe we should be talking about that. Let’s start with making pages that stay in place while people read them, and making pages where the ‘back’ button does what it’s supposed to.

Help, I’m supposed to teach tech! What should they know?

Yesterday I got a message from a teacher on Twitter. She mostly teaches science but this year she’s supposed to teach a 9-week tech class. She said she was “not a techy but willing to learn” and asked me what I thought the kids should know by the time they are done. I was flattered to be asked, and it inspired me to write an answer I was happy with, especially the six things I think kids should learn in a tech class. Here’s a slightly modified version of what I wrote:

Thanks so much for asking this; it gives me a reason to re-think what I want my own students to learn. I started out thinking about specific concrete skills (using variables or understanding files, eDebuggingtc.), but realized that those aren’t the most important things.

The things that I think kids should learn from technology education are skills that all good programmers and engineers have, but aren’t specifically tech skills. Some of the main ones are:

  • Think algorithmically: learn to plan out a sequence of steps that can solve a problem
  • Break down a problem: separate it into smaller parts that are easier to solve than the original problem
  • Debug independently: when a solution you have isn’t working, start testing smaller parts of the solution to see which part isn’t giving you the result you were expecting so you can hunt down the problem
  • Modularize solutions: look for ways you can re-use parts of earlier solutions that worked in other problems
  • Open-source your solutions: put your solution in a form that your peers can understand them and use different parts as needed.
  • Import solutions into your own: when a peer has come up with a good way to solve a problem that’s part of the problem you’re working on, don’t re-invent the wheel. Use a modified version of their idea, while giving them credit of course.

Of course these are huge goals and not easy to impart to a student even if you have whole year with them, let alone 9 weeks. You didn’t say how many classes you have a week, but I’d focus on just a couple of them, maybe the first and second or first and third.

As for what specifically to do, this is challenging even if you are given clear goals, let alone if you don’t. I’m sure you already have, but the first thing I’d do is feel out the administration more to try to get a better idea of what they expect to come out of it.

Assuming they really don’t have a particular goal in mind, my advice is to be a little bit ambitious and aim for a target you might not achieve at least the first few times around. If you’re a Google Apps school, the students will learn how to use the apps in their other classes pretty quickly on their own. If this is the main focus of your class I predict they and you will be bored very soon.

Khan Academy ProgrammingOne of the things I highly recommend for this is the Khan Academy tech classes. It’s easy for the kids to log in with their Google Drive accounts and for you to create a class where you can monitor them. The classes are very self-directed, with videos accompanying an interactive programming window, so if students have headphones they can all proceed at a pace that works for them. As a teacher I’m sure you know that with any subject some students will take to it like a fish to water and others will have a great deal of difficulty. This is doubly true for programming.

Some things you might have them learn are:

If you continue to do this class and your school is willing to spend a little money (really very little) on some hardware, I’d recommend ordering some Arduinos from Adafruit. and teach kids to make some simple electronic devices such as these ones .

 

Best first “pro” language (part 2 – Javascript)

Javascript LogoThis is part of a series on what is the best first ‘pro’ language, meaning something that’s actually used for professional applications. Last week I talked about Python, this week I’ll attempt to face the monster that Javascript has become.

I’m old enough to remember when people didn’t even really consider Javascript a programming language. They called it a “scripting” language or some other diminutive. To be fair, in those days they weren’t necessarily wrong. In the late 90s and early 2000s when I was in the Web business, Javascript was good for nothing but juggling the HTML Document Object Model. The DOM is the complex framework in the browser the controls the appearance and content of your web page. It’s what gets changed when text changes on a rollover or a menu drops down.

That is what made me think, once, that Javascript was a good first language for all its flaws. One of the challenges of any programming language is getting the students’ work in front of other people in a way they can see what the students have accomplished. Java used to be able to do this with Java Applets that ran on a browser. But Applets are dead as a doornail because Oracle could never deal with the security vulnerabilities they entailed, so browser makers stopped running them. With Javascript, if your students can make a simple rollover or dropdown, you can put it live and tell people to come see it.

But there are serious obstacles to this approach. The main problem is that first the students must learn HTML, Cascading Style Sheets and the Document Object Model. HTML is pretty easy, you can teach them enough to be able to do something useful in a month or two. But CSS and the DOM are convoluted and unpredictable, scarred with the remnants of the late 90s browser wars when the two major browsers roamed the earth with DOMs completely different from the World Wide Web Consortium’s official version, and hapless front-end developers had to kluge their Javascript to deal with all of them at the same time.

For all that it might still be worth it it Javascript was sitting still enough to be able to get students to the point they could do a simplified version of what web front end programmers do today. But real-world Javascript has been transforming itself at a terrifying pace. In a way it no longer makes sense to think of Javascript as a single programming language. It’s more like the flu; just because you could deal with last season’s version, it doesn’t necessarily help you with the next one.

Javascript ModulesEvery few months, it seems, everyone is excited about a new front-end “framework.” Frameworks are new downloadable modules of Javascript and CSS that come up with some (supposedly) better way of handling things in the DOM of various browsers. A few years ago everyone was using jQuery, which isn’t exactly a framework maybe but was an easy way to do a lot of visual things like dropdown menus and more importantly get fresh information from the server without loading a whole new page using AJAX. But Google had developed their own way to do that using a framework called Angular which is based on the Model View Controller web paradigm. At the same time Facebook developed a framework called React that wasn’t made for client-server interactions but which many people consider better than Angular for dealing with events in the user interface. Now Google has made Angular 2 which is very different from Angular.

But there are a million other different approaches and ways to use Javascript, including add-ons that do “polyfills” which trick browsers into using features they don’t have built in, completely different languages like Typescript that “transpile” into Javascript so browsers can run it, the npm module loader and Node.js, which is a version of JS that can be used on the server side where languages like Java, Ruby or Python would normally go. Javascript itself has added new features like returning functions from functions; ECMA16, the new version of JS, has a bunch of entirely new syntax even though it mostly does the same thing the old version does. This post at Hacker News gives an idea of how confusing Javascript is today even for people who used to think they knew it.

None of this is necessarily bad; it may just be Javascript growing up and becoming a mature programming language. But maybe not a safe environment for a learner to be wandering around in. Of course you don’t need to learn Angular or React or Node or whatever to learn Javascript; by itself it can still be a pretty simple language. But if you learn it all by itself you lose the advantages of being able to put your programs in front of the user, and you have to deal with all of the other weaknesses of the language.

And there are a lot.

When Javascript was new it attempted to integrate the then cutting-edge paradigm of coding, which was Object Oriented Programming. This might make you think it had a lot in common with the similarly named Java, but it was an illusion. Java, like any other OOP language, is built around classes which become objects in a program. Javascript doesn’t have classes, it has “prototypes,” which are like classes in the sense that raisins are like chocolate chips in your cookie.

People have been trying to make prototypes more mature so they work like classes (in ECMA16 you can even call them classes, though they’re not really). But along the way everyone got bored and started chasing in the new shiny object in the programming world: functional programming.

I’m just learning pure FP myself (Haskell is the gold standard in the way that Java is the gold standard of OOP), so I can’t say if JS handles FP any better than it handles OOP. But this kind of tacking on is what makes Javascript such a hard language to follow. James Nicoll said of English, “We don’t just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary.” This describes the expansion of Javascript perfectly.

Then there is the ugly way that Javascript deals with data types. Some languages, like C or Java, are very strict about declaring what kind of data a variable can hold. Other languages like Python keep that away from the user but behind the scenes still have a good idea of what the data type of a variable is. And when you say x = 10 but you want x to increment by 0.01 you can tell Python to make x a float instead of an Integer.

Number data types in C and JavascriptIf you say x = 10 in Javascript then x’s datatype is…number. As far as JS is concerned x could become 87 billion or 0.0003. But as far as JS is concerned x could become the lyrics of the national anthem or a graphical DOM element. This is very, very far from the way a computer’s memory works, so when a student moves to a language that’s even implicitly typed like Python, let along statically typed like Java, they are going to be in for a terrible shock.

What’s worse is the casual way that JS “converts” one type into another, especially when you compare them, so for example 0 is “equal” to false is “equal” to an empty string is “equal” to undefined. I put “equal” in quotes because they’re not really equal, Javascript just acts like they are. This leads to Javascript’s ridiculous “triple-equals” comparison convention. As you probably know if you’ve done any programming, a double equals (==) is what you use when you want to know if two things are equal, so for example if(a==b){ //some code } means do whatever’s in the curly brackets if a is equal to b. (This is as opposed to “a = b” which assigns a to be whatever b is.) Double equals work in Javascript too, but because of JS’s ridiculous laziness with type conversion, if you want to make sure they are really equal (same value and same type) you have to say if(a===b) . In other words in Javascript (and only Javascript) you have to say “do this if a is equal to b, but I mean really equal!”

I’m not saying (here at least) that Javascript is a terrible language, but I am saying that Javascript is a terrible first language, with a few exceptions. Khan Academy’s Intro to JS is a good way to get kids’ feet wet with a programming language where they actually have to type the commands. In fact what they will be learning is Processing, a useful beginner programming language, but since this is another example of “do things in the little window by the code,” it does not count as a ‘pro’ language in the sense I’m using it here.

The other reason you might want to teach students JS is if you actually want them to build interactive web pages. In this case first teach students HTML and CSS together (start with CSS right away; in 2016 there is no use at all in teaching simple HTML with no styles). This should go on for about six months or so. At that point they’ll be ready to start manipulating the DOM in simple ways with JS.

Otherwise, let them learn JS when they have learned another language first.

When kids do something stupid on the computer

I am old enough to remember when stores like Radio Shack in the mall had computers sitting on display with nothing but a cursor blinking on a command line. There was no program running, no user interface to interact with. Inevitably the screen would look something like this (edited slightly to keep this blog PG):

trs80HELLO
SYNTAX ERROR: ‘HELLO’ IS NOT A COMMAND
WHAT IS A COMMAND
SYNTAX ERROR: ‘WHAT’ IS NOT A COMMAND
*&!# YOU
SYNTAX ERROR: ‘*&!#’ IS NOT A COMMAND

It’s hard to know what people who put the computers expected to happen. But what looks like vandalism isn’t, really. What probably happened here is that a kid who didn’t know how to work with a computer tried, assuming the computer would be designed to be cooperative. When they found it wasn’t, they had a normal angry reaction.

Recently I was co-teaching a class where the other teacher was teaching kids Blender. I knew Blender less than some of the kids, so I was more a fellow student than a co-teacher. But I’m also a grown-upSuzanne, so I studiously mimicked my co-teacher’s lessons, and soon learned a lot.

Some of the other kids did that too. But others, when it came to selecting the starting shape, picked not a sphere or a column but Suzanne, Blender’s built-in monkey head shape. Then they randomly selected various panels and stretched them in random directions until Suzanne looked like a jigsaw puzzle with a coupla pieces gone.

My co-teacher was incredibly patient, but I could feel his frustration. “Okay, that’s nice,” he said, on seeing the twisted parody of a monkey. “Now start again and follow the instructions please.”

If you’ve taught kids on computers you are familiar with this problem. I encounter the same thing when my kids, instead of naming their objects MySprite call them something like IAMLAZARRRRRR (and then can’t spell it when they try to refer back), or make a video game where all the sprites, the background and the obstacles are Nicholas Cage’s head or Honey Boo-Boo’s mom so you can’t see what’s going on.

To a child psychologist, what is happening is clear and predictable. When introduced to a new environment, kids start testing the extremities and boundaries. They want to see what can happen, what they can get away with. Play is the work of a child, as it’s said, and play is a step in learning.

From a teacher’s point of view, though, the problem is clear. In a specialized field like programming or using an advanced program there are narrow paths to success through wide fields of failure. The keys of a piano can be struck in an infinite number of ways, but only an insignificant portion of those will make a song. There is a tiny chance a kid will discover something useful this way, but the more advanced the system they’re working in the less likely they will.

Also, you have a lesson plan, and they are missing out on it as they screw around! You have got to get them on track NOW or they will be forever behind!

A hint to working with children: when you find yourself saying “I have to fix this NOW,” you’re courting failure (except, obviously, for situations where the children are literally in danger).

Firmly discouraging a child’s play is likely to lead to disinterest and alienation. So what do you do instead?

Here’s what I do:

“That’s a weird result! How did you get that?”

(Yes, I usually know, but I’ll let them tell me.)

“Wow, that’s cool, I’m going to try that later myself! Hey, I want to give you time to experiment later, but can you do the lesson right now, because I don’t want you to get behind.” (Yes, you really do have to give them time to experiment later.)

Of course this always gets them back on task 100% of the time. Haha, just kidding. They will probably continue to screw around and do inappropriate things sometimes. But at least you haven’t discouraged their natural curiosity, and in the future you can start to try to direct it.

As you go along, give them places where exploratory actions can get them useful results. Start to define boundaries for play that will get them somewhere. When they see this happening, they will become eager and want to follow it further. Now they’re on the hook, and you can start to reel them in!

Can coding be taught in an Agile way?

The traditional method of programming lessons continues to be giving a whole class a distinct assignment testing their ability to use whatever programming skill they were supposed to be learning that week: make a loop, get input, etc. The students, if they do the work, are left with a folder full of little programs that do nothing particularly useful. In the best case scenario they may refer back to them in the future as examples.

This is based on a sequential method of teaching programming. Hopefully at the end the students will be required to combine those skills into a more significant program, but I suspect that rarely happens. Even at the college level this method often continues, with the focus on learning the syntax of this or that particular language. It’s only the most advanced students that confront real problems with their programming.

There is a reason for that: a program that addresses a real problem will of necessity be long and involve a bunch of different keywords, concepts and procedures that must be learned in advance. It’s not reasonable for a single student to do it. And students who work together won’t have the skills to make their individual parts combine.

What if we, as software teachers, take the leadership role in making the parts of their program together?

As I’m imagining it, each small group of 2-3 students would be assigned a small part of a big program that is meant to address a real-world problem, such as acquiring real-world data and displaying it in an interesting way. They would only need to learn two or three distinct skills to do that. They’d have to practice this skill a few times first, then they’d be given a unit tester program and told the expected outcome.

Unit testers are already used in college classes, but every student gets the same unit test to solve. In this system I’d imagine each group would have to solve a different unit test. The tests would be designed so that each module that could solve it would fit together to make a working program.

Except of course it probably wouldn’t work together at first. Then they’d have to look at what the others did and see where the problem was. If this was done correctly the students would be having regular meetings every few weeks where they shared their progress and what they got working. In the process of collaborating they’d come to understand what the other units were doing.

But then they wouldn’t learn all the skills! you say. No, not at first. They’d learn one skill, and they’d really learn it. They’d have a bit of understanding of what everyone else did. And they’d have a program that really mattered.

I certainly don’t want to add on to the people abusing the word Agile in programming. Maybe I should use another term. But I think this works towards the sense that Dave Thomas intended. The students’ solutions would, at first, only solve the problems in the most trivial way. Then they’d work through harder and harder unit test cases. It would be up to the students at every point to see what’s missing. By sharing their work with other groups and seeing what they are doing they’d have a sense of collaboration. Ideally they themselves would come up with the distinct problems to be solved which would then be divided between groups.

I’ll be honest, I haven’t done this yet. Maybe it won’t work. But this year I am going to try it. I’ll list the outcome on the blog.