MudLog

My two year vacation is over. This blog is now closed. See you in another life.

It’s been almost two months since my last post. E15 development was in full swing as well as thesis writing. We’re thinking about distributing the binary soon, and we’ll definitely have to rework the website. The best way is to probably make E15:Web as the E15 site. Anyway, this blog is going to close soon. Graduation is on June 6. My thesis was submitted today…so I’m done!

I know I haven’t updated with a new entry in a while. I’ve been working on this post for the last three months or so, but every time I try to write about something, I find it difficult to finish. But here it goes, another attempt at writing.

I said last year that I will work on a web application every month. I failed. Not because it was particularly difficult to implement, but because I thought it was a waste of time. I also don’t particularly enjoy making web applications or designing web pages. I’ve been doing it for a while, and the technical challenge isn’t so exciting; and it seems like everybody these days claims to be a web designer, and it’s true, being a web designer isn’t difficult (of course whether they are good is another question). With frameworks like rails and relatively compliant web browsers, it’s becoming simple to deploy web applications. Of course it is a nice change from the days of writing endless lines of redundant php code, but at this stage, it’s really about the idea and not about technological challenges. Ideas are hard, therefore I failed.

As a designer I feel the limitations of web browsers growing every day. Of course limitations can be due to security restrictions, and I feel like spending time to circumvent restrictions is a waste of time. Also, we have powerful computers, yet none of the graphics capabilities on the browser takes advantage of powerful graphics cards. This is why I don’t really spend much time working on web applications anymore. In a research context, when I think about what the “next thing” is for the web, I think it’s about the web as an environment we interact with, without a web browser; and give web designers a whole new set of graphical and interaction possibilities.

I’m focused on working on E15, and it’s been great. Implementing a desktop application comes with more complexity, but rewards with more flexibility. For the first time in a while, I feel like I can finally build things that I think, without discovering later that it is impossible. I’ve been knee deep in Cocoa, and I think I’ll probably focus more on writing about problems and solutions I’ve come across in future posts…if I ever decide to write onto this neglected blog of mine…

Just a note that OpenCode is now OpenID enabled. You can either use the Login/pass or use your OpenID url to authenticate.

Finally, at the end of term comes the pre-alpha, public release of OpenCode. What does it mean when we say pre-alpha? It means it’s not done, but we wanted to get people playing with it rather than letting it sit on my computer collecting dust. When we say public, it means anyone can sign up and start using it. So…try it out. Let me or Kyle know what you think.

PLW Locker is almost done, I’ll have it ready to go by the end of the year. OpenCode will be the first site to support logging in from the Locker. Everybody, go get yourself a PowerMate and get ready.

I spent the Thanksgiving break being sick. I got sick a couple days earlier, not because the Lions got their ass kicked by none other than Joey Harrington, the Quarterback (who was drafted as a first round pick) they traded to the Dolphins for a future sixth-round pick. I love the Lions, but every year they manage to fuck up worse than the year before. Last week Michigan lost to Ohio State, which was a real heartbreak, but Yale killed Harvard, so in a way that made the loss less painful (especially with the MIT streakers and all. No it wasn’t me.) But enough with the football…

The past few mornings, I’ve been coughing up some funky stuff. It’s disgusting. No need to describe it except to say it’s amazing how something so unnatural can be produced by my own body. I say it’s unnatural because its color is highlighter green. I haven’t taken biology since high school, but how can some natural process create such artificial color? Maybe this is because my body no longer consists of natural things. Everything I eat is artificial. I don’t really know what is in the stuff I eat. I eat student food, under a student budget. This means I eat things I wouldn’t normally, just because it’s fast and cheap. This is the only place where the don’t ask, don’t tell policy works. Mmm…don’t you just love the burrito of mystery?

Where am I going with this? I wanted to tell this story, because I thought it would be a clever way to come up with another reason for why computers and digital work is important to art and design, but I don’t think I’ll be doing a good job. Remember I’m still sick. Thinking makes my head spin.

Over the years, I’ve met many artists and designers who resist the use of computers and technology to influence work. They bitch and moan every time they have to use a computer. Normally, I would ignore them and not waste my time, but the problem is, most of these people are stubborn professors who are in the position to influence students excited about computers and technology. I don’t understand why they are so critical. I can only assume it’s because they fear the unknown, and this thing called the computer and the internet confuses them to no end. This is why I think future artists and designers need to skip art school and come to MIT instead.

Now the analogy. Computers and technologies are much like the artificial products we eat. Whether you like it or not, it is already within us. It’s okay if you don’t like it, but resisting and rejecting computers and technologies is like being an organic preaching hippie. But these days organic food isn’t even organic. It’s what hipster Williamsburg girls eat at Whole Foods at Union Square.

Interesting thread on Slashdot about Working Economy Without DRM.

This is Kyle’s trip report, published here since he doesn’t have a blog.

Having never heard of Edward Tufte (ET) prior to my visit, I hadn’t any idea what to expect.

After obtaining ET’s 4-book collection and a folded sheet of orange 11″x 17″ paper, I entered the conference hall. I immediately realized the attendees were neither engineers nor designers. The average attendee age must have been around 35.

ET began the first half of his presentation promptly at 10, asking attendees to open to various points of his books. He briefly explained a few key ideas, and began a long iteration through his “Fundamental Principles of Analytical Design”. These principles were often mentioned immediately following references to rather high-level scientific inquiries: A chart representing SARS outbreaks, Galilean planetary observations, Minard’s map of Napoleon’s invasion of Russia in 1812, and a 1930’s epidemiological study of a London-based Cholera epidemic.

As time goes on, ET professes, the ability of scientists to make use of his design principles will become increasingly important. The resolution at which scientific inquiry operates increases, and as this happens, a much greater degree of clarity must be made when making scientific assertions. It became clear through the course of the first half of the lecture that ET is not a scientist, and didn’t seem to have a solid grasp of those scientific concepts he asserts require his principles to be appropriately represented.

Following lunch, the presentation took a rather dramatic turn. ET abruptly stopped talking about the fundamentals of analytical design, and became more of a snake-handling preacher condemning the over-simplification of scientific content of Microsoft and its PowerPoint presentation software. He spent two hours discussing how software designed for simplification and abstraction (PowerPoint) was responsible for the 2003 Columbia disaster. Attendees nodded in unison.

Following this, ET proceeded to give attendees insight into how to give effective presentations. This was more or less a self-congratulatory pat on the back for ET, as each of his suggestions were each an integral component of the presentation he had just presented, including the supreme importance the folded orange 11″ x 17″ piece of paper, which most people used only to determine the time of the lunch break.

In the first half of the talk, attendees were expected to formulate an appreciation for the necessity of effective information representation and visualization. ET stressed the importance of the principles of scientific inquiry through clarity, detail, and comparison. In the second, he abandoned these assertions. Rather than discuss all of the issues involved with a highly visible NASA decision involving the lives of many people, he picked just one (the presentation format of a single report), asserted its lack of detail, and hastily sketched a line of causality between simplification and death. To give ET some credit, however, “show causality” is Analytical Design Principle #2.

I remain skeptical that ET’s ideas can be applied to pure scientific research. There are reasons why his examples are either outdated or the product of high-level socially-oriented organizations such as the Harvard School of Public Health. There are simply too many variables, and too many assumptions embedded within the frameworks of most scientific research to be represented as he suggests. Perhaps he should spend more time reading Thomas Kuhn and less time analyzing PowerPoint presentations.

Fortunately, our work at the Media Lab sits at an unusual position between pure research and corporate interest. The work we do is not extremely fine-grained and thus lends itself better to ET’s principles than pure research. ET’s books have been useful to me while learning more about the fundamentals of design through the avoidance of unintentional optical clutter and the how contrast between data and background reduces optical noise.

Criticism aside, I was pleased to have attended ET’s presentation.

Documentation is always a painful task: especially with software, since programming is hard enough. I tend to slack off on commenting code, and I rarely document anything I do. As long as I wrote it, no matter how old, I can usually figure out how everything works. If I give out code, I usually let other people figure out everything, but who does that really help? I guess people that are competent programmers that are just too lazy to write their own.

This article about community documentation was interesting. I think documentation would improve greatly if users write their documentation. The user comments on PHP.net and the Ruby on Rails wiki are good examples. Active users become more knowledgable than developers a lot of times, and developers don’t necessarily see things from the users perspective. Just look at the horrible UIs employed by some of the biggest software. I don’t know any one that has ever said they love Flash’s UI.
But, back to getting users to write documentation. How do you get them to do it? Do you ask them nicely? I don’t know…I think that’s a challenge all on it’s own. But people like free things, like free software. Why not come up with a new license where you would give out free licenses for contributing documentation while you can choose to opt-out if you just want to buy it and save the trouble of writing.

Good thing bp stands for “beyond petroleum.”