Posts tagged ‘computational media’
Here’s another take on the “Computing for Everyone” theme that is near and dear to me. I’ve been exploring this idea in my talks and papers, here in the blog, and all starting from our Media Computation work. This theme starts from a different question than CS: Principles, which is asking what should everyone learn about computing. The Mozilla-as-teacher post is suggesting why everyone should learn “coding” (here, including HTML coding, vs. programming): to make the Web better.
It’s a reasonable answer, in the sense that universal literacy makes the world of letters better. But how does it make it better? For me, I’m still attracted to the innovation argument: we use code as a medium to say, share, and test ideas that we can’t in other media. That communication, sharing, and debugging of ideas leads to more and better ideas, which results in innovation — new ideas, new extensions of those ideas, new implementations of those ideas. That’s why it’s important to strive towards near-universal computing literacy, at least with respect to knowledge workers, which is why it’s important to require computing in college.
There are other arguments, too. Another powerful reason for universal computing literacy is that it’s about knowing the world we live in. Why do we teach students the periodic table and the difference between meiosis and mitosis? It’s mostly not because of job skills. It’s because people live in a world where chemistry and biology matter. Today, we all live in a world where computing matters. Knowing about the inherent limitations of digital representations is more important to most people’s daily lives than knowing about meiosis and mitosis.
Now, if you buy all that: How do we get there?
This has been the premise behind much of what we have done with Mozilla Drumbeat: people who make stuff on the internet are better creators and better online citizens if they know at least a little bit about the web’s basic building blocks. Even if they only learn a little HTML, the web gets better.
I am now the Director of our Computational Media undergraduate program. (I had the gig three years ago, and it’s circled back around on me.) One of my jobs is to help answer the questions from the industrial recruiters, “What do your students know?” Below are the questions that I just got from one of bigger, more well-known companies in this space. Reminds me alot of the situative issues raised earlier in this blog. They’re not asking what subjects or concepts, but what tools and in what contexts (e.g., Java for client vs. Java for server).
What experience will the students have with:
• Engineering? C, C++…
• Mobile? Objective C, iOS, Android…
• Server? Java, JBOSS, Jetty, Tomcat…
• Networking? MySQL/SQL/Database, TCP/IP, Unix, Linux, etc…
• Tools? C#…
• Scripting? Python, Ruby, Bash, Perl, etc…
Do come to C5! You can skip my talk, since readers of this blog already know pretty much everything I’d have to say. I’m looking forward to the conference!
The 10th International Conference on Creating,
Connecting and Collaborating through Computing (C5 2012)
18-20 January 2012
Playa Vista, CA USA
Hosted by the USC Institute for Creative Technologies
Computers, networks, and other forms of technology are pervasive in our
information-based society. Unfortunately, most users of this technology use
it for passive consumption of information and entertainment. To evolve into a
true knowledge society it is critical that we transform computer-based human
activities to engage users in the active process of creating, connecting, and
The C5 conference is for anyone interested in the use of computers as tools to
develop and enable user-oriented creation, connection, and collaboration
processes. Researchers, developers, educators and users come together at C5
to present new and ongoing work and to discuss future directions for creative
computing and multimedia environments. We welcome the submission of
theoretical and technical papers, practitioner/experience reports, and papers
that bridge the gap between theory and practice or that encourage inter- and
=== Keynote Speakers ===
“Helping Everyone Create with Computing”
Dr. Mark Guzdial
Georgia Institute of Technology
“C2P3: Creating and Controlling Personalisation
and Privacy in Pervasive Digital Ecosystems”
Dr. Judy Kay
University of Sydney
=== Topics ===
C5 invites submissions of full papers in (but not limited to) the following
- Technology-enhanced human-computer and human-human interaction
– Virtual worlds and immersive environments
– Educational environments for classroom, field work and online/distance
– New technologies for literature, music and the visual arts
– Technologies for collaborative and self-empowered learning
– Multimedia authoring environments
– Gaming/entertainment platforms, virtual characters, and software
– Social networks and social networking
– Novel programming paradigms and languages for implementors
– Scripting or visual paradigms and languages for end-users
– Creating and maintaining online communities
– Tools for creating/managing online services/environments
– Distributed and collaborative working
– Social and cultural implications of new technologies
Papers should be submitted electronically in PDF format via EasyChair at:
Submissions must be written in English (the official language of the
conference) and must not exceed eight (8) pages. They should use the IEEE
10-point two-column format, templates for which are available at:
=== Proceedings ===
A preliminary version of the proceedings will be distributed during the
conference. The formal version of the proceedings will be published by the
Conference Publishing Services (CPS) and sent to authors after the conference.
For each accepted paper, at least one of the authors needs to attend the
conference and deliver the presentation; otherwise the paper will not be
included in the formal proceedings.
=== Dates ===
Submission of papers: October 7, 2011
Author notification: November 18, 2011
Camera-ready copy: December 16, 2011
Conference: January 18-20, 2012
Still trying to dig out from under the grading pile — it’s finals week here at Georgia Tech, and grades are due Monday at noon. My TA for Media Computation data structures had to leave the semester a couple weeks early, so I just finished catching up on all the grading (programming homework, quizzes, and final exam) for that class yesterday. I also have 40 students in a Senior Design class, so I’m deep into reviewing project documentation, design diagrams, and personal reflections on their process.
I’ve had a theme arise from both classes in the last couple days that is worth mentioning here.
Theme: I got a lovely note from one of my MediaComp DS students reflecting on his time in the class. (As a teacher, it’s an enormous boost to get one of these — even when critical, it affirms your job as a teacher: “Someone was listening!”) Against the recommendations of his advisors, he took my class and the follow-up intro to Java course concurrently, which means that he only gets elective credit for my course. But it gave him the opportunity to compare the two courses, which is pretty interesting for me. Besides these two CS courses, he was taking a course in combinatorics. He saw my course as the “glue” which combined the ideas of the three courses.
The concepts you introduced formed essential links with material from my other classes to illustrate the harmony of what I considered three more or less independent studies (for a long time I considered <MediaComp DS class> and <intro-to-Java> very different other than their shared use of Java, with one being the “general programming class” and the other being the “media and simulation programming class”).
What I found most intriguing was that he saw the MediaComp DS course as being the more “theoretical” course. Of course, any data structures course deals with theory issues more than a simple introduction to programming. But because this course included simulation, we also dug into probability distributions and continuous/discrete-event issues which connected to combinatorics and statistics in interesting ways. In a real sense, that made the MediaComp DS course harder than the introduction to Java course.
Recapitulation: One of my Senior Design teams refactored some code for our Physics department. Physics at Georgia Tech uses VPython in several labs. The physicists found that some of the code that the students had to write (to simulate a falling object, to graph data, etc.) was clumsy and had students struggling with parameterization issues.
My Senior Computational Media students, well-versed in HCI as they are, wanted to create a GUI for a Physics simulation. The Physics teachers (to their credit, in my opinion!) insisted on having their students write code. They explicitly wanted their Physics students to deal with “computational thinking” (their term, which may mean something different than others). So, the team created a nice set of objects, rather than the umpteen functions that students had to use previously. The Physics teachers are thrilled — the team did a very good job. But in their reflections, my Seniors are still complaining that they’d prefer to have built GUIs. “It would have been easier on the Physics students.”
I agree, a GUI-based simulation would have been easier on the Physics students. The students also would have learned less. They would have had less flexibility. The Physics teachers wanted the interface to VPython to be usable — to be understandable and to focus on the Physics and on the representational issues (e.g., how do you want to represent a vector to be useful?). While harder than a GUI, the Physics teachers felt that the code helped achieve their learning goals better. It’s not always about make things easier.
The cited blog post is critiquing Apple for having wonderfully creative technology but not well supporting software creation — and what does that mean for the future of computing, as Apple becomes the copied model. Apple’s tools are used often by professionals in the creativity profession, but too often, those professionals aren’t also involved in creating new technology, even if just for themselves, and Apple isn’t really helping them make that move. We saw a form of that in Brian Dorn’s dissertation work, where graphics artists had wonderful tools for creating digital media, but fended for themselves in learning to create software.
The concern voiced in this blog is that so-goes-Apple then so-goes-the-industry. This does seem to be a problem in our industry (is it true for all industries?) that ,when one company pulls ahead into a virtual monopoloy, everyone else adopts the approaches and strengths of the front-runner. How many “next Microsofts” or “next Googles” or “next Facebooks” have you heard about? The strengths and weaknesses of that company’s approach becomes the model that everyone copies.
Apple’s abysmally, disastrously worst ideas will be mindlessly copied along with their best. To some extent this is already happening. And if current trends continue, there will come a time when nothing resembling a programmable personal computer will be within the financial (or perhaps even legal!) reach of ordinary people.
The user-programmer dichotomy will be permanently cemented in place – even now, most computer owners don’t think of the expensive space heater on their desks as something programmable. But in the future it won’t even occur to a curious child that the behavior of his, let’s say, schoolpad can be altered in ways unforeseen by its makers – the essence of the creative act we call programming. We will be stuck with computers – machines which, within certain limits, are capable of literally anything – which have been deliberately – artfully! – crippled into being far less meaningfully-modifiable than our cars and houses.
This is an interesting argument that I hadn’t met previously: Pagination is better for long digital texts because it’s easier for sustained reading. What are the implications for reading source code? Is pagination (and perhaps formatting via something like Knuth’s WEB) better than a scroll bar?
Let’s put it under the umbrella term ‘scrollable’. Scrollable content works very well for two or three screenfuls of content, because it lets you adjust, pixel by pixel or line by line, to your changing context. You can say “I want this thing on the screen, and this nearby thing on the screen at the same time”, which is often useful — particularly if the content has varied elements like buttons and links and images as well as text. That is to say, scrollable content generally works very well for web pages.
But for anything of real length, it is seriously hard work. It’s important to realise what you’re doing when you’re scrolling. You’re gazing at the line you were reading as you draw it up the screen, to near the top. When it gets to the top, you can continue reading. You do this very quickly, so it doesn’t really register as hard work. Except that it changes your behaviour — because a misfire sucks. A misfire occurs when you scroll too far too rapidly, and the line you were reading disappears off the top of the screen. In this case, you have to scroll in the other direction and try to recognise your line — but how well do you remember it? Not necessarily by sight, so immediately you have to start reading again, just to find where you were.
Beyond this, even if you have startling accuracy, still you are doing a lot of work, because your eyes must track your current line as it animates across the screen. For sustained reading, this quickly gets physically tiring.
Pagination works for long text, not because it has a real-world analogy to printed books or whatever, but because it maximises your interface: you read the entire screenful of text, then with a single command, you request an entirely new screenful of text. There’s very little wastage of attention or effort. You can safely blink as you turn.
The fate of Scalar, which has not yet been released to the public, also remains to be seen. Mellon had backed an earlier attempt to build multimedia-authoring software, called Sophie. The first version failed, says Bob Stein, a director of the Institute for the Future of the Book, who left the Sophie project after blowing through more than $2.5-million working on it. A second version is not usable now but may end up being the “holy grail,” he says.
“The easier you try to make an authoring environment, the harder it is to build it,” says Mr. Stein. “It’s easy to build an authoring environment that requires experts to use. It’s very hard to build an authoring environment that somebody can use after reading two pages of instructions.”