Hej. Hello. Hola. Bonjour. 喂. مرحبا
I’m Rasmus Andersson, a twenty-something guy living in Stockholm, Sweden. Lead designer at Spotify, owner of Notion and a passionate technologist with a soft side for emotional values, coffee and chocolates. Read more…
Came by a set of beautifully designed chocolate bars today at Betsy Sandberg while strolling through Östermalmshallen in Stockholm. These delicious creations are made by ChocoLate Orgániko in Madrid, Spain.
The title probably gives you goose bumps. No? It doesn’t? Maybe it should.
Imagine you have a lot of work to do, a lot of image processing work, like rescaling and cropping large amounts of pictures. Now think about the web as we know it, with web sites where people hang around for a few seconds now and then. Imagine each visitor would be given a task to complete while reading your web site. Like for instance download, rescale and crop a picture from somewhere on the web. It’s possible my friend.
For the upcoming new version of Dropular we are going to make good use of this technology.
The basic concept of Dropular can be explained with this use-case:
A user called kate drops a picture she just found somewhere on the web (sending its URL to the Dropular service).
kates dropped image appears on the Dropular front page, or in the global stream of pictures as well as appears in other places throughout dropular.net.
Another user — let’s call him john — visits Dropular and sees the picture dropped by kate.
At step 3 we display a smaller version of the original image along with some metadata like a title, link to the original source, and so on. The smaller version of the image will be created by our imaginary user johns web browser. It only takes a split second and john will probably not notice anything.
When it comes to image processing on the web at large, there are basically two (or three) types of methods one can employ:
The host-based processing method has the upside of being performed in a controlled environment, thus we can assure a certain level of quality and there are few — if any — trust issues. On the other hand, processing imagery can be a very resource-intensive task requiring loads of hardware and/or time + in most cases bandwidth (sending and receiving the source and output images).
Client-based processing methods are employed by most desktop applications, but until today no web applications, basically because the technology is not yet mature enough or even available.
Moreover desktop applications in general does only perform processing on trusted data, data available in your local computer, and only uses the output of the processing itself. My Photoshop program does not email you my cropped version of crazy-cat.png — if you want to crop that picture you do it yourself.
What we are trying to do is to marry the two methods, effectively performing processing only when needed and sharing the results among visitors.
So you’ve figured: the real problem with this shared distributed method is trust. What happens if a rogue user submits a bad picture? How can we trust the submitted outcome?
Ways to “work around” the trust problem:
Method 1 requires the submitting client to be verified (e.g. by means of username and password). The downside being a less powerful “grid” of clients performing passive processing.
A product with the majority of users being logged in, or where the logged in users are probable to activate task requests of most images, would probably benefit most from this solution.
Method 1 is probably the solution we will employ for Dropular.
Many clients are given the same task and the Nth submission is picked. “Nth” might refer to a fixed, pre-defined number like “first response received” or “4th response received”, or it might be a random arbitrary number which changes between task contexts.
Using this method it would require a great effort from a rogue users perspective, drastically lowering the probability of success (of messing up things). However, it comes with the cost of increased latency (N number of submissions must be sent in before we can start utilising the results, i.e. a pre-processed image). It also requires more complex and foremost stateful backend (host) software.
This method works similar to Method 2 in that we need to keep some kind of state in the host software. We request multiple submissions and compare the “outcomes” using some sort of similarity algorithm1 and identify the biggest cluster of commonality, pick one of the “outcomes” in that cluster and forget all other “outcomes”.
Here, we require a even more complex software running at the host. The upside being that rogue submissions will have a hard time making it (assuming only one submission per internet origin is allowed to participate in each session, and that the comparison algorithm is sufficient).
As of last week, my Hunch stuff — aka “box of interesting stuff” — uses this technique of distributed image processing. It currently works by using a canvas element to perform the actual processing with, then sending the resulting image data using a temporary hidden form. This currently works in Safari, Chrome and Firefox (possibly also Opera, but untested) — for sad people with Internet Explorer (or other browsers), no processing or submission will be attempted.
What more than image processing will we be able to distribute in the future? Already today we could hand out simple number-crunching tasks to clients in the same way, but what’s more alluring is the potential of distributing otherwise very expensive — or sometimes impossible — working sets. Data mining vast quantities of resources on the internet, anyone?
In the case of image processing, each outcome might have totally different data (bits) since most image compression algorithms (e.g. JPEG and PNG) introduce some level of randomness, thus we can not use basic data comparison like checksums. ↩
At Spotify, we recently put up two large TV screens on the walls of our Stockholm office (most R&D is done there). The idea is to visualize & communicate that “stuff is happening” without actually revealing any critical data (since a lot of external people are visiting the office).
Today me, Andreas Öman and Emil Hesslow — fellow Spotifiers — kicked off a cozy little Hack Night at the office, trying to create something simple yet impressive to have running on one of the TV screens.
We ended up writing a real-time search query visualization in just about a few hours. It looks like this and is smoothly animated:
Try a demo version here… (Tested in Safari, iPhone, Firefox and Chrome).
How did we manage to build a real-time scalable system and high-performance viz in such an awfully short time?!
Well, for starters we used WebKit through Cocui which instantly gave us full screen high-performance hardware-accelerated drawing (yes, it’s a long sentence with cool words but those things shouldn’t be taken for granted).
But… where does the data come from? From the internets? — Not really, but it sure travels in internets-style. We use a dumb pub/sub message queue. In one end a client (the WebKit/Cocui app in HTML/JavaScript) is listening (subscribing). In the other end one of our search servers are pushing messages into the queue in batches.
[batch of search queries during last minute]
||
||
\/
[message queue]
|| ||
|| ||
\/ \/
[client] [client]
The client simply enqueues these search queries when they are delivered while at the same time dequeueing search queries. We do it this way (batches and a queue) because we simply have too high rate of searches. It would be almost impossible to read anything if we actually sent every single message. To give the feeling of real time we use a random delay when dequeueing queries.
When a query is dequeued it’s formatted into a chunk of HTML (a div and an a tag) and then prepended to the body using jQuery with animated effects.
Don’t forget to try the demo version (Does not work in Internet Explorer) which is simply the client without any real-time data. Note that this demo uses static data for demonstration purposes, not an actual real-time stream. The real-time data stream is only available within our office and thus not available for public use.
Update: Successfully tested with iPhone, Firefox and Chrome — thank you readers!
Here’s the full Cocui demo application: sptv1-demo-cocui-app.zip (for Mac OS X 10.5 and newer).
Comic Sans is becoming popular & hip.
I’m a big fan of integrated non-intrusive, productivity-enhanching applications. One category which is especially useful for me is the automatic publishing of screenshots, making conversations about looks and state so much easier.
Mr Bulgur: The label of the “More” button looks totally skewed.
Jean-Claude Which button?! You mean the home one? Looks good for me on Windows.
Mr Bulgur See, it looks like the v-centering algo is broken on OS X: http://hunch.se/s/8y/9sd0h2fcow8gs.png
Jean-Claude Ah! Yes, I’ll fix it in a blink of an eye.
I once purchased a license for Grab Up but the team bailed on us when the software broke. Moved on to TinyGrab but it’s too slow and often not working.
Since this functionality is rather trivial I looked around if someone had written an open source version, which I could simply adjust to my needs. None found. So I wrote one myself — Scrup.
Scrup is a simple little OS X application, or system plug-in, which sits in your menu bar:
When you take a screenshot, Scrup sends it to a web server of your choice. The web server then do something with the image (saves it, doh!) and returns a URL to the new image. That URL is then placed in your pasteboard, ready to be pasted somewhere. Scrup also keeps a list of the most recent scrups in it’s menu, for easy access at a later date.
A fun and inspiring advertising/art project I’ve been involved in (wrote the server and client software) is currently running (Mon 26 – Tue 27, 2009) at Stockholm Central station.
You push a button, the huge Satio phone replica snaps a photo and publishes it instantly on the web, also displaying it on a huge screen in the main hall.
The server is based on the Nginx HTTP push module and the client (the huge phone) is comprised of a Mac Mini, a standard USB camera, some wiring done by my brother and a simple Cocoa application I wrote which simply takes a photo from the camera, compresses it and publishes it to the server. Niclas Bergström wrote the front-end (HTML & Javascript).
A The Viral Company production.
Our/Spotify’s first ever commercial television advert premieres today on Kanal 5 in Sweden.
Production by the amazing guys at Identity Works (including Carl & Kaj formerly known as Superstrikers).
Here you also get a sneak peek of our upcoming new typeface Spotify Akkurat ;)
At the time of writing this, we distribute Spotify for Mac OS X as a regular DMG (disk image). The user experience is not really what I would call smooth:
Now, for a unexperienced user double clicking the app icon inside the DMG feels like a natural action. It’s there, I’ll just open it then. Later, she restarts her computer, the DMG gets unmounted and “Hey, where’s Spotify?”.
Our solution is to use an internet-enabled disk image which automatically unpacks Spotify upon download. We then use some magic in the app to check if it was launched from another place than the Applications folder.
The latest version of Gitblog got a new posts manager, which has been inspired by the inbox of Google Mail.
As a post can be in several states (and versions) at the same time, I had to use multiple dimensions of visual cues — row colors, labels (”Draft”, the “scheduled” clock) and hierarchical rows in the case when there is a work version alongside a cached version.
To get this feature, simply perform a git pull in your gitblog directory:
cd path/to/my/blog/gitblog git pull
Today (Oct 7th, 2009) was the 1 year anniversary of the Spotify desktop client. We celebrated with cake, of course.
One year ago we pushed the button, releasing www.spotify.com and the first public, official desktop client application.
It was a big day for all of us at Spotify — after two years of hard work and a lot of coffee we could finally offer our creation to the world.
This is what the first version looked like:
