Brief

Mozilla recently made an open call to designers to get involved in their project “Lizard Reader”. Lizard Reader was created by Les Orchard and is an aggregator for various new feeds from the Mozilla community. Tweets, blog posts, bug reports, wiki changes, code submits, etc get collected. The opportunity for designers is to submit concepts, sketches or prototypes of a intuitive, easy readable and fun frontend for the engine.

My concept

I couldn’t let the chance pass us by and not submitting something. So here goes my concept:

I’ve chosen the sea as a metaphore. News items get dropped into it and then float to the ground where they get arranged and archived just like sediments in the sea. The names of the authors or creators float in the air and arrange themselves just like a swarm of birds.News items basically consist of an author, date, title, body text and a link to the original ressource. Items can be viewed in a more detailed version by clicking on it.

By hovering over a name one can see the items by this author.

When a post is viewed in more detail it pulls related posts in a hierarchic view. Related posts could be by the same author, covering the same topic, edits on the same wiki page or reporting of the same bug.

To get an overview over past days the user can “dig” deeper in the ground and reveal past layers of sediments. By the density and chromaticity of the layer one can judge what happened during the day without having to view every post by itself. This creates a fingerprint and patterns for different activities in the community could emerge.

Brief

Christian Siegrist my co-worker on the Candeo project and I got contacted by Anne, Niels and Moritz three Architecture Master Students at the ETH, Zurich. After finding the documentation of our bachelor’s project Candeo they recognized the similarity of Candeo and what they had in mind for their free semester project. The plan was to build an application where the user could enter his preferences for his living situation and the app should tell him which places in Zurich would be great matches for him to live. Christian and I saw the potential of this app for flat-searchers as the main customers but also urban designers who can use the gathered data to plan next steps in the evolution of a city.

Prototype

In the initial phase we would build a prototype without the data handling in a dynamic way. We only had time and budget for 5 days to work on it thus we needed clever solutions to the big problems (mostly performance requirements) we would face. We built the map interface with the extraordinary clever ModestMaps library from Stamen. We’ve missed this one for our bachelor’s project and thought we’d give it a shot. ModestMaps allows you to easily use several map data providers like Google, Yahoo or the OpenStreet Project. ModestMaps worked like a charm beside we could’t share the libs over GITHub.com, see the getSatisfaction thread for detailed information.

Interface

The user would insert his data with ten vertical aligned sliders. These sliders are customizable in horizontal and vertical manner so the user could customize the attributes of each parameter on the same interface element. This way we were able to reduce the complexity of the UI and leave more space for the map. Each parameter had it’s representation on te map. These were semi-transparent layers rendering from red to black. Red are the most accurate regions for the user to live in and black are the regions that don’t match his preferences at all.

Conclusion

The presentation of this project to the professors at the ETH were a big succes and we’ll get support to work on this project during 2009. We’ve fixed a release date around summer ’09. There will be major changes for both the interface and the map as well, but we were able to build a solid foundation for the next steps in the process.