Playing with Arduino

Finally I found some time to do a little hardware hacking on the Arduino platform. As a quick first project and a first step towards much larger things we are planning at Maschinenring I came up with something that a) makes sense and b) can be done with a minimum of money (€10 if you already have an Arduino) and a main focus on programming: A two-joint articulated plotting robot.

Unfortunately, this picture is a fake :)) but I could not resist using this Escher quote (actually i guess the hand should carry a screwdriver to make it symmetrical but I didn't want to spend too much time in Photoshop for now). The real plotting results are much more disappointing because of mechanical errors which are not really controllable in software (and no, it's not the fault of the cardboard used for building the robot arms) and accumulate to an error of approximately +/- 0.5cm in the output.

Nevertheless, it was a fun project and great for getting back into some hardware-oriented programming and thinking about things like optimizing calculations for integer math. More details (including a video of the robot in action and the Arduino source code) can be found at the Maschinenraum blog.

Heres a picture of the actual output: this should be an orthogonal spiral with a winding width of 1cm. (Sorry for the crappy quality, I only have a webcam for taking pictures right now.)

Because of the low precision I didn't bother to program a way to upload more complex graphics to the robot yet, so output geometry is limited to things one can easily implement procedurally. Send me code if you want something drawn, and I send you an arm-signed drawing from the artist ;).

Empty Inbox!

Usually I sort incoming mails into folders immediately, besides the ones that require some kind of action or a reply, which I leave in my inbox (I sometimes even pull automatically sorted emails back into the inbox if I want to remind myself to act upon them). This means there are always some messages in my inbox, usually between 10 and 30, depending on my workload and other factors. Some of these emails can get very old in there, years in some cases where I just don't find the right mindset for a reply.

I am leaving for holiday tomorrow and wanted to answer some of these long waiting emails before that. The basis was laid already a few months ago when I decided to declare as abandoned some private email threads that have been waiting for multiple years, but now the impossible has happened:


Empty Inbox! I can't remember if this has ever happened before since I started using email in ... 1995 I guess.

How do you handle your inbox?

Jetzt geht's los!

[This is a German post – if you want to receive only English posts, you may subscribe to the english feed]

Proletarier bekriegen sich gegenseitig und fordern, den Ölmultis Steuergeld in die Tasche zu schaufeln:

Telepolis: Massive Streiks in Spanien und Portugal

Manchmal wünsche ich mir schon, dass ein BWL-Gundkurs zur Allgemeinbildung gehört: Wenn der Produzent entdeckt, dass die Preiselastizität für ein Produkt gegen Null geht, wird er den Preis endlos steigern und sich dabei eins lachen. Einziger Ausweg: weniger zu verbrauchen!

syn:wall at ITNOA exhibition

I just finished my first Flex project, an interactive projection wall for the exhibition ITNOA - In The Name Of Architecture. The exhibition brings together projects of students of the three universities in Vienna teaching architecture (TU Wien, Akademie der Bildenden Künste, Die Angewandte) in a self-curated setting. While the projects coming from different universities are presented in different areas of the printed-out part of the exhibition, syn:wall brings all projects together on one surface and creates neighborhood relationships between similar projects using quantitative attributes and tags.


The result of such an exploration can be printed out on a color laser printer and taken home by the visitor as an individual page of a distributed, virtual exhibition catalog.

One thing I learned (again) in this project is how inferior projectors are as an output medium. In a single grid cell of the exhibition, measuring 120 x 45 cm, a whole architecture project can be communicated in printed form, including texts, diagrams, plans and renderings. In the same area of the projected image there are 240 * 100 pixels, which can hold a lousy, pixelated thumbnail of the same project. Therefore I really like the idea of on-demand printing, and I would like to investigate this further in future projects, including producing larger prints with a plotter (something we originally planned to do but could not realize within the given budget and time).

ITNOA will be on until the end of the week, with a closing down party on Friday, the 25th of April (unfortunately I cannot be there on Friday because of two other appointments). It is located in the "Albertinapassage", the underpass under the Ring on the Albertina side of the Opera. ITNOA is also probably the last chance to have a drink at the infamous "Gaudí Bar" there, since the underpass will be closed down shortly after the exhibition. This place somehow always inspires me to get totally wasted every time I am there...

Thanks to Rüdiger Suppin for working on the concept with me and to all ITNOA people who helped entering the project information and crop all the images.

A weekend with the iPod touch

Last week I got myself an iPod touch, because I had to spend money from a grant on hardware quickly and there is currently nothing else that I need. I got it primarily for testing web apps on its mobile Safari browser and to optimize them for its screen dimensions and touch interface. The iPod touch shares the same interface, operating system and applications with the iPhone (which becomes available in Austria tomorrow), but lacks three of its features: cellphone capabilities, camera and Bluetooth - I actually own a cellphone which does all this, so I am quite happy feature-wise, but naturally cannot comment on these aspects of the iPhone.

After a week of use I now want to share some of my experiences and observations with you. The first thing that stunned me is that they ship this thing a-maz-ing-ly fast! I ordered it on Monday afternoon, and on Tuesday early afternoon it was delivered to my door! Next: over at Apple, they know how to package their stuff - the packaging is so nicely done it is really a fetish on its own.

The touch interface is really good for a "wow" from everyone, especially with the nicely done details I admire Apple for: Lists don't just stop scrolling at the end, but you can scroll a bit further and they will elastically go back after you release your finger. Applications zoom into view when you start them, and the thing emits this perfectly designed click sound on every action. Multi-touch is overrated IMHO, since I very rarely use it and would find it more convenient to have a single-finger gesture for zooming (multi-touch always also means multi-hand, which is annoying - you cannot hold the thing and perform a multi-touch gesture with the same hand). The complete absence of haptic feedback also quickly turned out to be a caveat: simply no way of reliably controlling the audio player (volume, next song) while it is inside your pocket - you have to take it out, unlock, look at it, every time you want to change the volume. Also I found especially the volume slider would recognize gestures with my thumb unreliably, which is most annoying when the music is too loud and you have to fiddle around for seconds to be able to turn the volume down. Generally, a few (freely assignable?) physical buttons on the side of the thing would probably spoil the super-minimalistic design but would improve usability a lot for me.

Speaking of design: Maybe my hands are just too sweaty, but after a short time of usage the thing looks really ugly, on both sides. Finger taps and grease all over the screen and the shiny back makes you want to clean it all the time, which really is a Sisyphus thing. So its not exactly the kind of device you want to give out of your hand for business presentations, as everyone will go 'yuck, I'd better wash my hands...'

Interestingly I already had several occasions where the much-appraised tilt sensor turned out to be annoying. Obviously, if gravity doesn't point in the direction of your own 'down' vector, you are in trouble, which happened to me in bed several times. I wanted to browse some pictures before going to sleep, and they all would turn to their sides. The other day, Patrizia wanted to turn a photo to look at some detail, but the photo would just turn together with the device and there was no way of stopping it from doing so. So there are situations where it would be nice to be able to deactivate or override that tilt sensor thingy.

What surprised me is how little you can actually do with that thing, in terms of producing or editing content. You cannot edit song information. You cannot reorder the pictures in a folder. You basically cannot delete anything that's on there while on the go. Speaking of limitations, this brings me to the iTunes software you are forced to use. But I do not want to go into the details here, in short: iTunes on Windows is utter crap! I just hate it, and I will never understand how iTunes got the reputation it has... bleh! I hate it, hate it, hate it, and it will probably be the reason why my iPod will soon sit somewhere collecting dust, because actually they force you to use iTunes with the iPod touch - it is not possible to activate "disk mode" on this device which would allow you to use alternative programs. I guess this also means no chance for Linux users to ever sync their stuff with an iPod touch.

The full meanness of the Apple corporation is revealed when you look at the syncing options for calendars and address books on Windows: Outlook and Windows Address Book are the only supported options. Importing bookmarks only from Internet Explorer! No Mozilla, no iCal, no standards support. They have their deals with Microsoft, and they don't give a dime about standards or open products. But it all comes in a nice package, and hey the user interface is nicely animated, so the geeks are flying for Apple. Pfui!

What really surprises me is that they seem to get away with it, and the competition is screwing up so badly that Apple still, after all these years after the first iPod was released, looks like the only company that understands designing products. It's just unbelievable. Even though I hate this closed, proprietary, unhackable thing for its political implications, I wouldn't want to use any of the alternatives out there I have seen so far.

My Teeth

I guess I really am one lucky guy... After seven years of avoiding it, I went to the dentist last week for a checkup, and guess what — nothing! Not one little hole in my denture to spoil the glory:


I borrowed the X-Ray image for those of you who complain that I don't smile often enough. Thanks to padme for making a contact print and scanning it!

Note that above image is copyright by me and I explicitly disallow any form of copying, reproduction or use other than viewing it on this blog - Although I strongly believe in open source and creative commons, I am not willing to provide data about my body to anyone currently.

Towards the perfect URL scheme for web applications. Part 1: Requirements

[This is part one of a four-part article. I will add links to the other parts here as they become available.]

I am currently working on a prototype for a small, new, top-secret web application (don't worry, I will let you know as soon as there is something online to show). When I sat down to start coding, the first thing I had to decide on was what the URLs inside the application should look like and how the URL space should be structured. I always had the impression that the question of how to design URLs for web applications has been largely neglected by the web developer community as I never read anything about a structured approach towards the problem — although it is a very visible feature and often the first usability test a site has to pass. So many apps and websites out there come with unreadable, unhackable URLs and/or, even worse, do not produce meaningful filenames when you try "save as..." on a page or downloadable file. I wanted to really get this right in the first place, so I started with writing down the things that annoy me regarding how URLs are constructed elsewhere, added a few "nice to have" features and lessons learned from my own previous experiences and compiled a requirements list that my scheme⁽¹⁾ should meet.

Requirements for a perfect URL scheme

When I talk about "modern web applications" here I have a rough concept of the state of the art in mind (buzzword alert!): AJAX interface with a fallback to server-driven interactivity, REST APIs⁽²⁾, widgetizable applications and an object-oriented data model. Other websites may have different requirements, but most of what I say here will apply to a broad range of applications.

1. URLs should be human readable, rememberable and robust for voice communication (e.g. phone)

One of the most important requirements for URLs is that they should make sense to a human. Machine-generated identifiers, deep folder hierarchies, special characters, strange extensions or query parameters are examples for URL parts that humans cannot easily parse or remember. More often than you think URLs are communicated by voice communication, over the phone or in the radio, therefore they should unambiguously serialze and deserialize from spoken language (which, by the way, is also a strong case for non-case sensitive or all-lowercase URLs).

Obviously this requirement cannot be solved by a specification or scheme alone, but also lies in the application's responsibility. For example, if you have a document with the name 'qa4@@67g$O', the best scheme will not help you to provide a human readable URL.

2. URLs should be short

While this requirement is slightly related to the previous one, it is not the same. A longer URL may be much easier to remember, as you can easily try by using one of these tinyurl.com generated URLs. Still, partly for the reason of transmitting and displaying on devices with limited capabilities (think text messages), the URLs of our system should be naturally short with no superfluous namespaces, extensions or query parameters.

3. The scheme should produce meaningful filenames & extensions for every page and file served

This is one of my top annoyances on the web, as most web applications fail to fulfill this requirement. Even with document servers that are supposed to provide files for download (e.g. PDFs), I frequently encounter missing extensions, not to speak of meaningful and unambiguous filenames. Whenever we serve a non-temporary page or document for viewing
it should be possible for the user to save that page to her local machine, getting a meaningful filename with the correct filename extension.

4. The scheme should make use of established specifications and conventions — filename extensions ('.'), hierarchy ('/'), queries ('?'), fragments ('#')

Obviously I do not want to reinvent URLs, but build on top of established standards and conventions. The problem is that these standards have emerged in a time before XML, Javascript and AJAX, and so we have to find an interpretation of the concepts offered to us that match the requirements of modern web applications.

5. The scheme should use as few reserved characters as possible, leaving most of the allowed character set for the application

I want to avoid introducing reserved characters in addition to the ones mentioned above - partly because it would be a nonstandard extension to what we already have, partly because human readability would suffer by introducing additional non-letter characters.

6. URLs should be "hackable"

Closely related to human parseability requested in requirement 1, "hackability" means that parts of the URL could be removed or added by users, leading to deterministic, meaningful results. Some examples of this would be: removing everything after the last '/' should give you an overview of the content one level up a hierarchy, removing or changing extensions should change the content type served, adding parts of an URL seen elsewhere on the site should result in similar behavior on any other resource etc.. Note that a system with "hackable" URLs should also protect the user from accidentally modifying or deleting resources this way, so that users can safely play around with the URL scheme without causing damage.

7. URLs should be able to address resources AND actions to be performed on these resources

This is the major new requirement I see with modern web applications. When HTTP was designed, URLs were meant as a way to access resources, in most cases static files. The operations to be performed on these resources were pushed into the HTTP protocol in form of the GET, PUT, POST, ... methods. In modern web applications it turned out that a predefined set of methods cannot cover all the different requirements that may emerge. We therefore need a way to express actions to be performed on resources within the URL, since no other method is provided by the HTTP protocol.

8. Resources or results of an action should be presentable in different formats (HTML, XML, JSON, plain text, ...), providing correct file name extensions

As static pages play a less important role in modern web applications and standards for the exchange of various data flavours emerge, it is important to be able to present a resource (e.g. an article) in different formats (e.g. HTML, Plain Text and RSS). New standards are emerging all the time and may become relevant in the future, so the pool of formats to choose from should be expandable in the future to support yet unanticipated usage of the data.

9. The scheme should support content to be served in a format determined by the preferences of the client application

In addition to the explicit choice of format through the URL scheme discussed in the last item, the mechanism of implicit content format selection offered by HTTP through the "Accept" header⁽³⁾ should be supported. The Accept header allows the client to send a list of supported content types along with each request, allowing the server software to select a content type best suited for the task.

This way our system can send different responses to a mobile phone and a full-fledged web browser, although both are using the same URL to access the content.

10. It should be possible to mix static files and generated content

Although static files play a less important role in modern web applications, it is obvious that every web application will need to serve static files form the file system to the client. While in production environments this is often solved by a dedicated subdomain (e.g. static.foo.com), it should still be possible to serve static files and generated content from a single server.

11. A single resource should have a single (normalized) URL

Flexible URL schemes often provide multiple paths to a single resource, leading to problems in unambiguously identifying resources. Search engines, for example, may not be able to conclude that two different URLs point to the same resource, usually leading to a reduced ranking for both pages. If multiple paths to a single resource are possible, an unambiguous normalization method (often called 'URL canonicalization') should be provided.

12. Support the features of "standard" global filenames like robots.txt, sitemap.xml, favicon.ico

Due to very unfortunate historical developments, some "standards" have emerged (none of them is actually a standard accepted by any official standardization authority) that rely on the presence of static files in the URL hierarchy of a server. Since these "standards" provide convenient or important functionality for many web applications, the URL scheme must either support these filenames by ensuring that no other resource can exist with an identical URL, or we need to find ways to support the features provided by these files through other means.


This concludes the requirements for a perfect URL scheme I have discovered and found important. In the next part (coming up soon!) I will discuss the constraints we face from the URL and HTTP specifications for designing our URLs. Part 3 will present the proposed URL scheme and Part 4 will discuss implementation issues. Stay tuned!


Footnotes

1 - Let me state in advance that when I say "URL scheme" here, I do not mean to propose a new scheme outside the scope of what HTTP already supports. My intention is to find a way to structure the path component (everything that comes after the server name and port in the URL) in a way that reflects the needs of modern web applications.

2 - I have to admit here I have never quite grasped what REST really is or why everyone is talking about it. As far as I understand, it is simply the concept of having a stateless API where every call is simply a HTTP request, and I have the vague idea that the URL scheme proposed here goes well along with it. If anyone has any further insigts, please enlighten me! (And yes, I have skimmed through the dissertation)

3 - The Accept header is discussed in detail in the HTTP/1.1 specification (RFC2616), section 14.


Updates

2007-12-19: Added numbering to the individual requirements and added requirement 7 (Hackability)