Clocks With Hands and Elements Appended to Divs
Looking at the digital representation of a clock on the right hand corner of my laptop, thinking random thoughts about old Mexican songs. Tonight I need to write about process, it seems, and the time is running out. But it is not quite running, is it? A 52 suddenly changes to 53 and that’s it: no real suspense, no magic, no romance.
A bolero starts playing in the old jukebox inside my head, Roberto Cantoral’s El Reloj. Wallowing in pain in the midst of the vibrant guitars of a trio, he asks a clock not to mark the hours. He begs the clock to stop time in its hands. So cool: clock used to have hands and held the inexorable passage of time in them, our date with fate could be suffered through a series of audible tic tocs and…
The digital clock turns to 57. No magic, true, but same result: I need to hurry, get the assignment done, perhaps get some rest.
The task at hand: try and write a blog about process as I begin the journey of learning how to code in JavaScript from scratch. It’s been a little less than two weeks since I saw my first line of JavaScript code ever, so you can imagine how little I know. But still, writing about the process of learning sometimes does help the process of learning. We’ll see.
One of the many challenges I’ve faced in coding bootcamp is how to try and carve the time to practice coding on my own, how to come up with small projects that make the process more engaging and relatable than the myriad labs we are assigned and that are designed to challenge us and push us. There’s no time to do all the work, all the reading, all the blogs — and yet, it is only by practicing code outside the framework of the program that everything comes together. In the end, I feel it all comes down to time: there is only a set amount of it, digital clocks be damned. So we must make choices.
I chose to spend the time I had carved to research a mandatory blog post to practice by coding a very simple, very small JavaScript on my own. Time permitting, ahem, I may even get to write about my experience doing this. So here we are and here we go. What did I do?
First, I gave myself parameters. I would not work more than five hours on this: in fact, when the five hours were done I would stop wherever I was at that time. The next ‘rule’ was that I would try to do things I hadn’t done in labs and exercises yet. Not that these had to be complicated deliverables, but I wanted to learn how to do new things, whether they ended up being simple or not. Most important of all, I wanted to see if we could tell some kind of story. Lost in the woods of reduces and event delegations, I momentarily lost sight of the power and possibilities that this language provides the developer.
Could we create some kind of interactive narrative in less than five hours, with less than two weeks of JavaScript and no idea for a story? That would be the challenge.
After setting up the ground rules, the next step in my process was to come up with a rudimentary design. In this case, I focused on the few actions we have already learned JavaScript to be adept at: ‘listening’ to events from the user via the mouse and keyboard, providing information about where elements are on a screen in relation to those events and gathering information from outside sources via URLs.
Because of the time constraint, I knew that the look had to be bare: not a lot of time for styling, interface design and coding logic here. So I decided to create an app with no real instructions that waits and reacts for the user. The idea would be a blank screen (I did change the color to a dark green) waiting for the user to interact with it. If the user hit any key, the app would provide hints guiding the user to communicate with the mouse.
After adding the keypress event and asking the browser to ‘listen’ and react whenever a key was pressed, I was not satisfied. Yes, it was clearly the start of some kind of utterly simple interactive experience. But beyond that, whenever we showed the text (or appended the HTML element to the div, if you’re in the mood for that sort of language) it just popped up on the screen. Well, that’s kind of rude, I thought. Wouldn’t it be much nicer if we could fade in and fade out the text from the screen? How would we do that?
Calling Google and Stack Overflow, phoning my friends!
And of course there is a way. There are many ways. First I looked at how to do this using vanilla JS with help from an unknown friend Codepen who goes by the name of istref:

Well that’s cool. But it seemed like a lot of work for something we’d be using all the time. So I kept looking and bumped into the jQuery library and its animation effects. After reading through the documentation, I went ahead and installed jQuery for this project and voila, with a simple fadeIn() I had what I needed.
Actually, though I wrote that short paragraph in about fifteen seconds, it took me a good half hour to research the different ways of fading in and out elements in JavaScript and then reading up on jQuery, installing it and getting the fadeIn() and fadeOut() to work properly in the context of my small app. But it was well worth it!
Good: we have the app telling the user what not to do and not being visually rude about it. But what happens when the user does click the mouse button? Does it have to be in a specific div, in a button, in a span? We started an interactive narrative by introducing a trial and error dialogue, but then what? I did not want to use buttons like we had before, I thought it would be cool to experiment with expectations a little bit. If a used clicked on the screen, anywhere on the screen, nothing should appear, I thought.
Perhaps it could rain.
I had read somewhere that there were various APIs for sound libraries, music and audio effects. And of course JavaScript must have ways of handling audio. So I went back to Google…and Google came back to me. After reading a host of different ways of handling audio, I landed on Google’s Sound Library inside the ‘Actions on Google.’ Using the HTML Audio element in your code, you can then access this API of sounds via URLs that lead to specific sound effects. I found a nice rain effect, got the URL and then created a new Audio element in my program, assigning it to a variable. Once we had that, we only need to .play() and .pause() to activate the sound or song. Pretty great.
Part of the process of learning how to code by doing is spending (investing? wasting?) a ton of time looking for the wrong answers in the right places or for the right answers in the wrong places. This happened to me many times and particularly in this case. After having figured out how to include the rain sound effects in the app, I wanted the sound to — yes — fade in and fade out. I found out that it was not that simple(at least for me). After looking into various different solutions for this and breaking the code in many ways, I gave up. Part of the process, I guess.
Just like the previous two examples, I continued to explore new ways of doing things with the next few elements in my app: showing elements wherever the mouse was clicked, making a specific part of a created element ‘clickable,’ disabling functions during timeOuts. Some of them worked, some of them did not. But those that did not taught me even more than those that did.
As you may sense, the time has come for me to stop writing and start coding again — yet here I am, looking for an ending. The rhythm fails me and closure teases me from a distance. The hands of that old clock ain’t stopping for me, for this blog post or for anything else. Oh my. One day I may be able to sit down and write a proper technical blog, perhaps.
