int 0×30:

I recently released Percolater, an iPad app for viewing news stories, links from Twitter contacts, and RSS feed entries as rendered pages. Basically, it’s all of the ideas and inspiration that fueled Feedabot, in a more simplified, accessible, and consumer-friendly form.

Read more about it over at BuzaMoto.

Or, if you’ve got an iPad and want to download it now, here’s the iTunes store link.

I spent some of my time over the course of the past few months sharpening my iPad development skills. Shown above are a few of the prototypes I made that I don’t plan to continue.

Every day, the collection of pages rendered by feedabot grows larger. In fact, there are approximately 250,000 pages in the feedabot archive as of a few days ago. Using the current web-based interface to navigate through this collection (one click shows you six new images), it would take approximately 35 hours of nonstop clicking to view all of those pages. How might one go about building a better system for navigating large collections of web pages?

Head on over to the BuzaMoto blog to find out.

Not long ago, Tak finished up a little photo viewer application taking advantage of some of the more modern CSS features. It took me a few days before I realized that combining this new layout with the data I’ve collected from Feedabot would be an excellent idea. I spent the afternoon connecting the two, and I have to admit, it looks and feels pretty amazing. It turns out that this presentation technique works particularly well for curated collections of pages rendered by Feedabot (like the collection of tagged items in the example above).

As I start spending more time on HTML5 sites and those using more modern CSS techniques, I’ve started to wonder at what point the web design we’re used to today will start looking like the pages from the 90s like this one.

I’ve been talking to Mahir a bit recently about Feedabot and fixing some of the current UI issues. As a result, I starting spending some time thinking about different ways to present the data contained within the site. I only recently made the observation that simply generating RSS from the Feedabot data provides a simple way to redirect it to sites whose sole purpose is RSS presentation.

Even though I’m not really much of a Tumblr user, it seemed like a good place to put some of this data and explore some different presentation interfaces without much effort. After spending some time trying to figure out how to get Tumblr to import the entire contents of an RSS feed (not just recent entries), I found a nice solution using the Tumblr API and php. I then created a few separate Tumblr accounts for some page sets I’ve tagged while using Feedabot over the course of the last six months or so:

http://buza-inspiration.tumblr.com/

http://buza-people.tumblr.com/

http://buza-visualization.tumblr.com/

http://buza-visual.tumblr.com/

Cavalcade, the first theme I stumbled across, works slightly better than most others for Feedabot data due to its two column presentation style. It’s clearly not perfect for this type of data, but it’s nice to explore different presentation mechanisms with the click of a button.

I’d really like to see some of these sets in the Tumblr Mosaic Viewer at some point, but at the moment it doesn’t seem to be able to load more than one of the images from each of the above Tumblr pages.

Last week, I was up in Alberta visiting the Banff New Media Institute, where I’m currently an artist-in-residence for the Liminal Screen co-production residency. The residency technically runs for six weeks, but prior engagements prevented me from spending the duration at the centre. For it, I’ve been working remotely with Futurelab colleague Travis on a multitouch text layout installation that will be on display at the centre this evening, and at other locations around the world in a few weeks.

Overall, it was a great week of skiing, programming, and talking about future projects.

Feedabot is a project I’ve been working on over the course of the past few months to help me manage the links that pass through my Twitter feed and a few other RSS feeds. Basically, it monitors various feeds and renders the pages of the links it finds within those feeds. The automated generation of these images allows me to scan through the things people post visually as opposed to having to guess if following any given link is worth my time. It’s been up and running for almost six months now, and has become an invaluable element of my daily internet habits.

The web page previews generated by Feedabot are great for getting an overview of things posted without having to slog through each link one at a time. The ability to tag these images makes it possible to create sets of related pages that can be scanned through visually as well, which feels really nice. Up to this point, the infrastructure I built supported only the rendering of the individual pages. Through discussions with a few of the individuals using the site, it became apparent that digging a bit deeper into the page itself to isolate specific page resources would be a valuable next step. As a result, I’ve spent the past week or so thinking about how to isolate and extract interesting data from each page and presenting it to the user directly, without requiring them to visit the page itself to watch a video or view an image. My last blog post was related to these efforts as I was trying to programmatically extract regions of high text density on a given page and present these subregions to the user. While this approach appears to work reasonably well, it still needs some work, and I’ve chosen to leave this ‘text region clipping’ for future Feedabot update should I be able to address the current challenges it presents. Currently, the Feedabot engine is only extracting images and embedded videos, which are displayed as a Javascript-based popup when clicked.

The end result is that image and video resources found within a page can be previewed with a click of the mouse in a manner reminiscent of Apple’s Quick Look. Play video and see quick previews of images from rendered pages without leaving Feedabot. I’m pleased.

For now, I’m making this feature accessible only to registered Feedabot users, so if you’d like an account, you’ll have to email me to request one.

Someone was recently criticizing me for not having posted anything here since September of last year, so here’s a post about something I did the other day. I hope it makes him happy.

One of my recent projects had me trying to figure out how to isolate the parts of a web page that contain the most text. Basically, I needed to find the places on a page that had the highest text density (i.e. the amount of text in a given region). So, I wrote some Python to do these calculations and soon realized that the best way to see if my results were correct was to create little heat maps from the data. Of course the first few sets were wrong for different reasons, and the results shown here aren’t perfect, but they’re good enough for what I need to do. I figure that if I can explain everything that doesn’t look quite right, and if those results aren’t important, it’s okay.

The only interesting catch that I didn’t originally anticipate was related to Javascript. In the beginning, there were a few sites that would reveal some image regions to be very dense with text. This, of course, was due to certain Javascript handlers attached to the images, whose source was contained within the associated text element children of the image nodes. So, all that I needed to do was to determine if a given text node contained a readable string or a chunk of Javascript. Easy, right?

Well, it turns out that it is easy. My first attempt at a solution was to just take the string and see if a Javascript parser would successfully parse it. Fortunately, I found the Python-based pynarcissus Javascript parser, which solved the problem. I love projects like this that work exactly as I had hoped it might without significant modification. Pass the text found in each text node through this parser, and ignore it if it parses successfully. There are clearly edge cases where this might get confused, but it’s good enough.

Also apparent in the examples above is that text displayed in larger fonts don’t show up in the heat map. This is because the font size produces larger DOM elements, reducing the overall density. Fortunately, I’m not interested in titles and headers, so that’s not a bug I plan to fix for the time being.

There you have it. I don’t know if this was interesting in and of itself, but what I’m going to use this for is much more interesting.

One of the nice perks of working at the Futurelab is having access to some of the great Ars Electronica resources, like running programs on the programmable facade of the new Ars Electronica Center. A few days ago, before the Ars Electronica 2009 festival kickoff, a number of Futurelab employees were putting together and testing various facade-related projects, from games to time-based pieces.

Curious about what an Atari 2600 might look like running on the side of a building, I spent a few hours beating the Stella Atari 2600 emulator into submission so that I could send the screens to the building while playing on my laptop. The most important question that I needed to address was that because each building side is approximately 10 x 18 pixels in size, what would an Atari 2600 screen look like when scaled to such a low resolution? I ran a few tests, producing the following screen captures (from left to right: Yar’s Revenge, Rampage, Breakout, and Q-Bert):

Excited about these results, I gave it a try on the building a few nights ago, producing the image above during a game of Yar’s Revenge. Unfortunately, it didn’t come out as well as I had hoped it might. The transparency of the building windows and the general darkness of the game screen pixels ended up causing problems. Close, but no cigar. With a little more time and controlled lighting conditions, I suspect a solid game of Breakout could be played without significant issue.

Special thanks to flatmate and colleague Dan Wilcox for lending me a few of his Facade-related classes, saving me a substantial amount of development time.

A number of months back, Luis and I wrote up a few proposals for the Rhizome Commissions Program, the goal of which is (in their own words):

“… to support emerging artists by providing grants for the creation of significant works of new media art. By new media art, we mean projects that creatively engage new and networked technologies to works that reflect on the impact of these tools and media in a variety of forms.”

One of our submissions was the whimsically titled Compactamator, a simple online community surrounding the creation of hyper compact code segments. In it, we sought to explore the collection of minimalist code fragments through the removal of verbosity. In other words, leverage (or design) a simple language for the drawing of shapes, with an API consisting of only single characters. As the code would be interpreted by a bit of client side javascript, Compactamator would support in-browser development producing both static and dynamic images. Shown above is the admittedly oversimplified and comical mock up we threw together for our submission.

Compactamator wasn’t awarded a commission, but a few months after the awards were given, Rhizome announced it’s own internal project called Tiny Sketch:

The name itself immediately brings to mind two projects from a few years ago, namely Brent’s TinyCode Sketch from 2006, and Tiny, which was mentioned as part of Luis’ portfolio for the Rhizome proposal.

Using limitation as a driving force for creative exploration isn’t new, of course. It was limitation that drove the evolution of the modern day demoscene, and excellent 1-bit audio experiments from (Rhizome commission recipient) Tristan Perich and my old colleague Noah Vawter. The recent popularization of Twitter, and subsequently all things small has caused a veritable eruption of “tweet programming” competitions and exercises in recent months as well. Numerous examples abound, from the wonderfully minimalist Mona Tweeta by Mario Klingemann, Andy Best’s Processing Sketches in a Tweet, Tweetcoding, the 25-Line ActionScript Contest, 140 Characters of AS3, all the way to competitions involving POVRay snippets.

One of my personal research interests back when I was a student was to consider the browser as the development environment for writing code. In particular, for writing the types of visuals created by users of Processing and Flash. As the powers that be make sizable efforts to entice us to start doing absolutely everything on the web, it’s really only a matter of time before these types of things happen. In 2006, my first attempt was OpenCode with then group mate and now business partner Takashi Okamoto. In it, both Actionscript and Processing code could be written, compiled, and executed entirely from within the browser. By placing this experimentation environment on the web, it had become relatively easy to allow people to share, explore, and experiment with code. Nothing needed to be downloaded, you just visit the site, click to load an example, and click to run. At the time, we jokingly referred to it as two-click programming.

What made OpenCode challenging was circumventing the security issues imposed by the browser. We were forced to create special mechanisms for storing resources within a user’s profile, along with custom web services to perform otherwise restricted behavior on behalf of the user. As these challenges increased, we ended up moving on to other projects. We reached the temporary conclusion that certain types of things can be done easily and elegantly in the context of the browser, and others can’t. Really, it’s these kinds of limitation-motivated projects mentioned previously that are perfect for the browser, as anything more complex will likely break some sort of security abstraction.

This gets me back to one of the reasons why the design strategy embodied by Compactamator is important: It was to use an API designed from the ground up, with minimalism in mind. This prevents the community of users from carrying existing presumptions with them about what types of things can be made with it. Compactamator created a clean slate development environment in order to fully explore limitation as an element driving creativity.