To reach the ultimate goal of this project took an awful lot of ‘soul searching’ would be the best estimate I could give. I approached the assignment by creating lists of things that interested me; these included things such as building physical object, anything BIG, and lots of coding involved. Combined these are aspects that would end up creating a project that I would enjoy working on and would hopefully be revolutionary. This eventually led to me asking if there was a tangible way to teach the aspects of the DOM (document object model). As of this time, there are no projects that have addressed this question. While there are hundreds of websites out there that will teach you how to code for the web, they all live on the web. A person could pick up a book from a decade ago to learn, but it still remains that the world of web coding lives entirely digital. My project aims to take the traditional methods of teaching programming for the web and translate it into a tangible domain to see what insights could be gained from combining the digital and physical spaces.
Because this project is entering new ground, there is no definitive research on the topic specifically, However there is a wealth of knowledge that is inspiring me on the 2 fronts, teaching coding, and tangible interfaces.
Teaching The DOM
Researchers often compare learning HTML to learning a second language. This isn’t entirely false, but it also is not entirely true. HTML stands for hypertext markup language. it names itself a new language, but unlike other programming languages, HTML lacks a syntax that can be read like english. In Java, you read code like english; there’s a subject and verb more or less. HTML however, describes how a page is laid out. Nicholas Mauriello has compared it to 5th grade english class. In early english classes, students are taught the 5 paragraph essay and its structure. There is a formula for how it should be set up. HTML is a tool that can be used to help define that structure.
That ideology does bring up one major problem though: HTML is code, and all code must be hard, or you have to be smart to code. Ignoring the debate of whether or not HTML is code, it has the stigma that comes with traditional coding: its hard. To look at how people do teach coding we have to look at the source of teaching. In my experience, there are 2 ways of learning, having a teacher walk you though it step by step, like we do in IML 300, or learn on your own online from sites like code academy. This project is supposed to be independent so I’m looking at the methods of online sites. Code academy does a good job of teaching the beginning process of developing a website, however it has one major flaw, CSS. People want to make the next beautiful website tomorrow, they don’t have time to learn every step of the process. This means that on code academy, they are constantly making their examples look pretty to keep their customers on the tutorials as no one wants to look at a web page straight outta 1990. With all of the techniques used to make it pretty, users of overwhelmed easily when they should be focusing on the basic concepts.
The closest project to what I’m proposing is being developed at Carnegie Mellon University. Named Click, this project takes the techniques used in teaching Java/C++ and makes it tangible. They are taking the idea of breaking code into blocks and then connecting blocks to create a program. Still in its design phase, the project will offer me a lot of inspiration as I continue to refine the techniques I will use to make my own project.
15 years ago at Cal, researchers studied the process though with designers and developers created a website. They found that the overwhelming amount of times, sticky-notes on walls, and white board markers were used to develop initial ideas. They then created a tangible interface that would read their physical work and transition it into a digital work. They were not interested in compiling an actual HTMl page out of the tangible work, but rather a design study. My work will take their project one step further to have an end at the HTMl file.
I’m proposing building a large table that will be split in half. On the left half will be the ‘playground’ and the right will be a screen showing a live render of the left. To go in-depth, the left will be where user will assemble blocks of code to create a physical representation of the DOM. for their use i will 3d print several ‘lego’ looking blocks that will feature the standard HTML brackets along with pre-made content to populate the blocks. From there, users will be able to draw blocks out of a large supply to build their own web page from scratch. The left side will be used to teach the development of pages. On the right will be a touch screen displaying a live render of the web page. As the page is populated with content, users will be able to select the content on the touch screen to bring up a menu and change its CSS. This part of the project will be used to teach the basics of design of a page. The specifics of how this technology will come together are still unclear. The reading of tangible parts will likely be the most challenging part of think of initially. The process of taking the live data and creating a render will be based off of Adobe’s Bracket. This is a web IDE that has that exact capabilities built in and I will likely either use their technology or base my own on theirs.
As stated in the introduction, this project is the outcome of putting a lot of my interests into a blender and seeing what came out. With the idea slightly fleshed out, I have been able to research projects that slightly follow its trajectory. One project that highly inspired me was made by artists out of Spain, called ReacTable. This was a tangible table that was use to create music. The artist used blocks that when ‘linked’ together would create a beat along with harmonies and melodies. This was one if the first tangible work-stations that was made with the intention of going straight to installation outside of an art gallery, and later into commercial uses.
At Tangible Media Lab at MIT was also very inspiring. Their work is part of the forefront of tangible research. While no one project of theirs stood out to me, all we helpful in crafting this idea.
On day one we were asked what are 3 values were; mine were intelligence, humor, and fun. This project is an embodiment of intelligence and fun, with a good chance for humor to slip its way into the fold. These aspects will be experienced not only by myself building the form, but by users play-testing it.
The midyear showcase taught me a lot about my project, some good and a lot more bad.
To start, I’ll begin with how the presented material worked out. The very first thing i saw within minutes of people trying out my project was that color was a HORRIBLE idea. What was worse was having red dots on some cards as well as on the ‘playground’ to mark where the dots should be lined up. This led to users to immediately reach for the red cards and match the red to red. This was an oversight that that occurred during the the final set up of the project. Midway though the showcase I took the red cards off the table and left the rest of the users with the rest of the set for the remainder of the show. The goal of the project was for users to mix and match cards to create their own narrative however their primary objective was to match color schemes (even after red was taken out). Only professors were concerned with what was written on the cards rather than what was on screen.
All of the problems above were partly predictable. I made the decision to not go fully ambitious with the tech for the midyear show and in doing so, though color would be the easiest way to make it work. In the end it made it more complicated and breakable - due to the ever changing light on the stage.
The other part of the showcase that I was majorly testing was the ‘how to teach html’ part of the project. This aspect went over slightly well but had its downsides too. Because I took the tech down, it also meant that I could not incorporate all the aspects of html elements that i wanted. Additionally because I used color, valuable space on the playground required was needed for the color dots that I would rather be used for the content and html. After observing multiple users, both faculty and students, try it out, I think that I have laid the ground works for a project that will work out which i will explain in a bit.
The critique from faculty was helpful, but at the same time, not at all. The faculty pointed out the above, and offered suggestions on how to fix that ranged from doable to go start your own million dollar labs and challenge google for innovativeness. The best advice was how to read and compute all the blocks. As of now the leading the solution is RFID chips. Each block would have a chip and the playground would be filled with sensors underneath. This eliminates all need of an overhead camera, save for documentation. The chips are small and indiscreet and will leave all the room on the blocks for content. The second best advice was something that was already on the project block - build a virtual IDE into the application. This is the real step in the right direction for teaching html. I plan on having the playground offer realtime feedback on the structure of html, meaning that for every opening block <> it will need a closing block </> to properly render. This is the real hurdle that will help users understand the proper structure of block.
My final comments regard the presentation of the installation. Before I had a large poster featuring way to much content on it that was never read. Instead i plan on making small educational pamphlets that will give brief but better info and also break down each html tag and list its purposes.
The over all process from last semester was honestly what i predicted. I spent the first month just coming up with my idea, the second month doing research and the third programming. That third month was really more like 3 weeks of cramming for other classes and programming the entire project in the last week. At the outcome, the thing that failed the most was the graphic design of the project but that was only brought up at show time. this semester will be similar but different. I plan on spending the first month doing research on the technology, asking professors what direction would be best and what sensors to use. Then the rest of the time will be spent programming as that will be the bulk of the project.
My documentation probably sucked, I don’t actually know, but it is because documentation was not on my mind for most of the semester. I took notes each week during research but they were simple and not deep. When it came time to write up on the blog it ended with mostly just turning notes into sentences. When i did get to programming time i tried to record my screen for the process but the screen cap software made the computer too slow to work with any efficiency. This is something i will plan ahead for this semester. Additionally documentation will be better written and include more than just small notes.