Intro to Javascript with Observable

I am teaching a course called “Coding for Lawyers” this coming fall and I am going to use javascript and try to be practical in my approach that these law students aren’t going to be coders but that they need to be familiar with how the Internet works.

I do want them to be able to get into visualizations and working with data as soon as possible.

Does anybody have a simple Intro to Javascript Notebook?
or other just elementary notebooks?

What about a good jumping off point? - maybe promises?

Maybe I want to start with Observable for “Hello World” or maybe I want to wait until we know what a variable is etc.

I saw a query from a javaScript newbie earlier with a nice answer from Jeremy and I was wondering if anyone had posted notebooks or had thoughts on the path from “this is javaScript” to d3 visualizations in Observable

You might consider formulating at least some portion of the subject matter as, What are some tasks that lawyers routinely have to do that would be aided by use of a programming language?

I’ve worked with people (and been one of them) in this “advanced beginner” state, in my case working with scientists, and visual effects artists. They’re likely very capable of absorbing a lot of material very quickly… as long as it embeds with what they already know, and what they are trying to do. Being asked to learn about Promises, for example, without the motivation of having first experienced the problem that they address, may lead to frustration.

Many artists, who in other circumstances would have no inclination to programming of any kind, are perfectly happy picking up MEL scripting or Python, because it helps them do what they’re trying to do. It’s also readily available in the environment that they already use, at no cost, comes with no overhead, nothing to set up, no harm if they use it a little bit and then drop it.

If they’re lawyers, they’re likely looking at a lot of documents and could benefit from something like basic text extraction. If you show them that you can do that just by right-clicking and pressing “Inspect” on any document that they look at as they’re browsing (and demonstrate it in the same browser that they’re already using for any other activity), then they might be more likely to see it as something they can integrate into their current activity, rather than as a foreign thing that they might or might not open up again once the class is over.

1 Like

I have no actual knowledge on this topic, teaching programming, but my two cents are that you should get them doing something that has value (for them), and has a feedback loop, as quick as possible. People that are specifically interesting in programming will be able to put themselves through theory about variables and constrol structures etc., but most have no interest at all, and just want to play and figure it out, like you do with LEGO. Theory just boggs things down, I believe, and should be offered as-you-go, while playing around.

  • With regard to the feedback loop, javascript + Observable are a great choice.

  • With regard to value, that depends on what kind of students you have, and what kind of crazy things you can think up that have something to do with the subject matter. I really don’t have the best of ideas for you, but I’d say, try to think out of the box.

If you’re trying to get them to value the kind of things that code can do, then it may be preferable to go for some language/platform where there is interesting sensor input / interesting output. In this arena, although I love javascript, I have to say the web-platform is often a bit ‘closed world’. For a more ‘open-ended’ situation, Processing + Android phones can come in very handy, because you can get setup really quickly, and any mobile phone has a lot of sensors. You’d want to pre-program some rudimentary examples that exemplify sensor input: touchscreen and gyroscope are the easiest to get at, then maybe the camera and communication between phones (say, via wifi or bluetooth or heck, some quick web api). [You should be able to get your hands on some older smartphones without too much effort or cost. Getting them into developer mode might even be harder than acquiring them.]

Maybe an approach would be to

  1. First get to know the “tactile feel” of what it is to program (and learning, almost implicitly along the way, variables and control structures) — by using javascript + Observable. You can use simple fetch-es to get data from the web (think open geo data, other open data provided by say governments), and do some basic text extraction stuff, learn some for-loop stuff along the way, maybe some rudimentary vizualizations.
  2. Then get them started with Processing on Android phones. The feedback loop quick as enough that you can re-run your program every few minutes or so, and you can play with sensors, and have your students think up funny things to do with them.

One addition though: depending on how far your students are in their studies, you could possibly “sprinkle in” some law-specific “open IT/law-related questions” into the course. Even though it has no direct relevance/overlap with the actual coding experience, they’re in the ‘programming world’ now for a while, and hence this is the time and place to address IT/law ideas. I had a (very elementary) course on law once (in my computer science bachelor’s), and they floated some ideas like:

  • Privacy and law, obviously. On the one hand, the need for privacy. On the other hand, the absence of regulatory systems, anonymity versus community building, etc. Reddit is an interesting point in case w.r.t. community building, anonymity, etc. “Is (non-)anonymity necessary for communities and open speech to thrive?” / “Can regulatory systems work in anonymous settings?” / …
  • Maybe throw in some really specific computer stuff. For instance, voting procedures: the perfect example of when you want perfect anonymity (shielding people’s identities) + perfect knowledge of who’s voted and who not (fair voting). This may seem like the grandest of IT paradoxes, but they can be solved with some simple computer science stuff, hashes and other cryptography stuff. The main obstacle here might just be the organizational side. “What is hashing, and does it magically solve anonymity / integrity problems?”
  • Flexibility/rigidity of IT structures, whose responsibility it is when they fail, who is able to break them, etc.
  • And there’s stuxnet of course, state actors hacking each other. That’s just too badass not to mention somewhere in your course.

I remember we read some parts of the book Code by L.Lessig online link, which I found quite interesting.

FWIW, I think the sandboxed aspect of Javascript in the browser is a actually big advantage. Part of what can hold beginners back is the fear of undoable actions that their programs may commit, e.g. accidentally unleashing a file deleting program while trying something out. The worst that Javascript in the browser can do is hang the page, at which point you just refresh and blow it away. People kind of have a sense for that, since they use a browser in their daily lives, in a way that they don’t have a sense for what dark and scary things a terminal is doing when it’s spewing out line after line of incomprehensible text.

Also, the order of magnitude increase in the feedback from the “execute as you type” Javascript environments is (or at least appears to me) an underappreciated advantage, which allows for wild and free experimentation, rather than “hold your breath and hope it gives no errors” type of mentality.

As to some specific things in relation to law: I think the graph evaluation model of Observable, similar as it is to DAG construction in compositing (eg Nuke) or FX work (Houdini), could bring similar advantages to document construction. Namely, the need to propagate edits through a document (maybe using the tagged template literals) is similar to the need to pipe constantly updating assets through a node network. So, the shift is that you’re performing explicit operations on the graph rather than on the output of the graph, which is what you get when working from the static viewpoint (like in a regular document editor). Then, for example, similar text in multiple places describing different claims won’t get out of sync when changes need to be made (because they ARE of similar origin, rather than that they are identifiable as having similar origin as judged by outcomes).

I actually worked on a project which was attempting to address something similar to this issue (using Python and LaTeX). My knowledge of current law practice is kind of limited, so I don’t know if this is relevant or interesting, but at least from that experience it seemed that document construction in legal practice could benefit from this type of viewpoint.

1 Like