So, if you have anything to do with tech / music. You will be aware that earlier today, spotify launched their new play button.
Their play button allows any website owner to embed a simple play button for any spotify song onto their site.
This is great news… for spotify users. Unfortunately spotify is yet to be worldwide and due to various licensing issues, not everyone everywhere has access to the same tracks on spotify.
You may be aware of Tomahawk. Tomahawk is an awesome music player that basically plays tracks from anywhere that it can find them. Whether the track is on spotify, local, sound cloud, official.fm, or various others.
Today, we bring you the Tomahawk embeddable play button. Any website owner can embed a play button onto their site for any song. They don’t even need to worry where the song is hosted, as long as it is *somewhere*. Tomahawk does the rest of the work for you.
To add a tomahawk play button to your site. Simply visit Toma.hk find the song you want, and copy and paste the embed code… Simples.
Last weekend I was invited out to the beautiful french riviera by the guys at Reed MIDEM for their new conference, MIP Cube ”Explore The Future Of TV”, for a hack day organised by the Rewired State. I was a very lucky sod. I spent 36 hours on a luxury yacht hacking about trying to make something interesting.
After discussing project ideas with my girlfriend, I went to Cannes with the aim to build a simple reminder service. Something that sent me a message 5 minutes before a tv show I wanted to watch aired.
It would be a simple service, simply viewing listings data, picking a show, and then the system would send a message. Nothing complex. I was amazed it hadn’t been done before.
I have to admit I am not au fait with available tv / film data. But after googling a few times, and speaking to a few more experienced tv / film data hackers. It seemed that the best ‘official’ listings service to use would be Atlas by Metabroadcast. In theory it seemed it would do what we wanted. Atlas obtains data straight from the BBC. It’s basically as close to an ‘official’ source as we could find.
After a few hours we had the system all working, and it was time to test with ‘real’ data.
As you can see from the screenshot above. The data was ‘patchy’ to say the least. Show titles such as “Episode 7” doesn’t really help..
After doing some more digging into data, it seems that some broadcasters charge for their listings. I find this extremely odd in current times. Sure, I can understand when businesses are literally running from this data, TV Guide, RadioTimes etc. But, my point is that if you get your listings data out to more people. More people know what shows you are showing, have more chance to see a show they want to watch. Which in turn provides the broadcasters with more viewers of live TV. Especially with many broadcasters being concerned about the coming death of linear TV.
Sure, we could have screen scraped a bunch of sites to obtained the tv listings, but at this hack day I was more interested in creating something that lasted, which would require ‘legitimate’ data.
The challenge I set was simple. The hack was simple. What was the problem? The data, or quality of.
Now I see why there isn’t a reminder service already… all I wanted to do was get the broadcasters more ‘live’ viewers, is that such an issue?
Most radio stations now have a simple data call to find out the current song being played… Yes the current song. TV? I can’t even find what’s going to be aired, let alone what is currently being aired.
Yeah sure, there are a few third party ‘unofficial’ data providers. Zeebox is soon to be releasing their API. But why is a third party needed?
With this all being said, I would like to massively thank Reed MIDEM & Rewired State for inviting me out, I had an epic time, and was great to meet / work with some amazing people.
“It was mega lols, now I need mad coin to buy a boat”
@moustaki points out that the bbc do have hidden apis for listings. Which is a great start… Now hopefully the other broadcasters will start doing the dame.
So, I spent a few moments the other day looking back at the last year. I have had an EPIC last year.
I started the year working at Marmalade on Toast where I was working on various cool projects for the likes of Budvar & Harrods. Working on exciting projects.
In April, A friend came up with an idea for Instagram. He sent me a Direct Message on Twitter. “Dude, Instagram + cats. Epic win!”. 24 hours later we had http://instac.at. On the first day alone there 10,000 more people joined my christmas card list. This I feel was the start of it all.
4 weeks later I left Marmalade to try the big world alone. I started working with some awesome clients, each of you were / are awesome. And have helped me to have an awesome time. I can’t list you all here, but you know who you are.
I started working on my own projects with various new ‘business’ / project partners each of which I would like to thank.
All the journalists and bloggers who have written about projects i have been involved in. This has been the first year I have ever had something I have been heavily involved in mentioned in the media. Especially the ones of you who called me a “UK based web guru” or a “modern day superhero”, even you commenters who called me a “fucking facist”.
All the people who have invited me to talk at their events. All the people who have taken their time to listen to my rantings.
My family & my friends for putting up with me being useless and uncontactable.
Especially Sophie, my girlfriend, for putting up with me being the worst boyfriend ever and for not feeling ignored when i get my head down in code all the fucking time ;).
All the people who have basically interacted with my life in anyway. Including you, the person who is reading this for putting up with me wasting their last 5 minutes by reading this christmas card.
I have seriously had an epic year.
I hope all of you guys have an epic 2012. 2012 for me is looking like it will be awesome thanks to all of you!
And for a bit of shameless self promotion. The projects I would like you to currently check out or keep an eye put for are: (let me know what you think, would love feedback)
I was having a chat with a friend about app marketing, and the app store. The reason why they are starting off with a native iPhone app is due to the massive call to action presented with the “Available on the app store” image.
Search for “ArtSpotter”
This image provides the user with a MASSIVE call to action. “Oh right, that is where I can find it”
That got me thinking. Personally the process of finding a website online is far easier, especially if I know the domain name. So that got me thinking, for purely marketing of web apps do we need to start using something like this:
Visit artspotter.com
Now although the fact that it says artspotter.com is pretty easy to me perhaps users actually need to search for something.
Search for “ArtSpotter”
Obviously I would rather the Available online would work better but I have a worrying feeling that “Google it” might work better.
Maybe this is the reason why HTML5 has a logo?
Mozilla are soon to be releasing their own app store. For the general mainstream, the ones who type into google “facebook”. These are the people we need to help get our warez into the hands of to go mainstream.
I think the web community needs a cause to get behind for the good of the web. Who’s with me?
This past weekend saw developers from all over the world flock to London for the third London Music Hack Day. Music Hack Day is an event organised by the guys at Six Two Productions for developers to get together for 24 hours and make something awesome…
Picture this: You’re in a new city and forgot to research its art scene before arriving. Does your iPhone have a solution to this first world problem? Thanks to the new app, ArtSpotter, it just might.
ArtSpotter was created by UK-based Raphaëlle Heaf, who has worked in the contemporary art world for more than 10 years. This ambitious new app marries her love of mapping, architecture, tech and art. Thus far, ArtSpotter has picked up funding from Ignite100, the largest accelerator program in Europe, one angel investor and two founding galleries.
ArtSpotter just launched in the Apple App Store on December 1, so it’s still new and growing. For now, the top ArtSpotter cities are London, Berlin, Paris, Munich and New York because these are cities that Heaf herself knows best. ArtSpotter is also working with events in the UK (the London Art Fair is one of them), and also speaking with others in Europe and the U.S. If ArtSpotter can aggregate data and content from the right places, this app has a chance at reaching its goal.
Take yourself back to 2007. The first iPhone was released… The media, love to claim that this device changed everything. One thing everyone seems to forget is that at first, we, as developers, could not make applications for the iPhone. There was no app store. There were no apps.
What was Apple doing? They were pushing for the web. They said, “Just make a web app”. They had their ‘add to home screen’ functionality (which is yet to be duplicated by other manufacturers, but it REALLY needs to be).
The problem with this solution was that developers wanted access to cool stuff. We wanted to play with the camera, the location services, the address book etc.
Now imagine this scenario. Apple improve mobile safari at this point to include access to all the native functionality and features. This would be what Mozilla are trying to do with their WebAPIs. Or perhaps what W3C are trying to do with the web applications API. They also add hardware acceleration and key performance improvements at this point. They make web apps, look and behave like native apps.
Now what would other manufacturers have on their devices? A decent brower that enabled developers to have access to the native functionality of the device. Now remeber, the beauty of the web is that any device anywhere can access it. There are only two requirements, a browser & an internet connection.
But what did Apple do? They released a native SDK in their very own language of choice Objective-C. Developers then started making native iOS apps. Only iOS devices have access to these tools and services. Native apps aren’t new, in fact they are old. So what was the big deal? The App Store, that is what changed everything.
Don’t get me wrong, obviously there are still the type of tools, that can’t work well using high level languages. Native apps will always be with us for heavy duty software. But for angry birds? For the type of app your mum has downloaded and installed. Do these really need to be native? No.
What we need now is device manufacturers to develop decent browsers with native funcionality APIs and the “Add to home screen” functionality.
GPU memory management with hardware accelerated CSS transitions.
See that? That’s the difference that GPU hardware acceleration of CSS transitions can make on an iOS device. If you don’t know what CSS transitions are, you might want to stop reading now.
For those that are left, I won’t bore you with how CSS transitions can provide basic animations, or how they can be GPU hardware accelerated on iOS devices, which can make an incredibly low-powered platform like an iPad offer smoother animation than big desktops running javascript.
Instead I’ll run through how Bardot currently does the “next page” trick, and how I’m trying to improve it.
As a caveat, I’m just imparting what I’ve learnt through trial, error and Google - I wouldn’t count myself as an expert on this.
Bardot is built in “pages” and “spreads”. Pages are… er, pretty self explanatory, and spreads are the equivalent of opening a magazine spread (ie two or more pages facing each other). Bardot actually has three piles of spreads *, at any one time you see only one spread on-screen - in the “viewport”. Either side of the viewport are two other piles, and when you hit the “next page” button, the piles all shuffle along one direction or the other.
The mechanism for doing this on most modern browsers is simplicity itself. Spreads in each pile have a particular class (“.read”, “.active”, “.unread”) and to move them around means changing their class via javascript, CSS transitions and transforms do the rest for you. As an aside, that makes quick changes to the animation a doddle (Make it quicker? Tweak the CSS style. Add a 3D flip out movement? Tweak the CSS style).
That all looks fine on desktop browsers, but iOS devices need a bit more help. They’ve got pretty limited processing power, and extremely limited memory, which often ends up with low frame-rates, sudden disappearances, or giving the “tiling” effect you see in the video above. This is especially true when you’re creating something off-screen, then moving it into view (like we are here), because mobile devices are optimised to only deal with on-screen pixels to keep them lean and mean.
To get around that, we can hand off the “compositing” of certain elements to the 3D GPU chip in the iPad or iPhone, which is way more adept at flinging tiles around a screen. You can move an element to the GPU by adding a 3D CSS style to an object (some use “-webkit-transform:translateZ(0)”, others use “-webkit-transform:scale3d(1)”)
In the case of Bardot, I created a style class called “.zippy” with a transform of “translateZ(0)”. When a page-forward event occurs, the top of the “.unread” pile is changed to a class of “.active.zippy”, and the retreating spread is given a class of “.read.zippy”. So “.read” and “.active” are the classes that determine where the spreads move to, and “.zippy” is the class that adds a sprinkling of acceleration.
The question begs: “So why don’t we hand everything off to the GPU with 3D CSS?”. Well, the GPU is also really limited in the amount of memory it can handle, and the more you stuff into it, the more it stutters and you’re back to where you started. In Bardot, one of those spreads could be thousands of pixels in size, it doesn’t take many of those to really bung up a GPU.
The trick is memory management. In Bardot, only the “.zippy” spreads are hardware accelerated, and once a spread is moved off-page, the “.zippy” class is removed to reduce the load on the GPU.
The result is buttery smooth animations in both directions. Simples.
* Note: I’ve tried building systems with a long continuous “conveyor belt” of pages in the past, and although the theory behind that is cleaner (moving a huge track of pages past the viewport), I find working in three piles is easier to manage, especially when you get into dealing with layouts that are many spreads long. A track would becomes tens thousands of pixels wide and you have to deal with big margin offset numbers. Not pretty.
Currently (at time of writing) there are 4 main desktop platforms (Windows, Mac, Linux, Chrome OS) and 6 main mobile platforms (iOS, Android, Blackberry, Windows Phone 7, Symbian, WebOS). In the future there is going to be even more platforms. Smart TVs will become mainstream, even the long awaited smart fridges.
Each of these platforms support applications of one type or another.
The current feeling, by many, certainly not all, and not sure if even most. Is that there has recently been a flocking to the native applications.
Why is this?
“You get a better experience with native applications”
I think I might be alone in this, but I hate this kind of argument. A ‘better’ experience depends on what you are actually wanting to experience. If you want something that you can access from any device anywhere in the world. Then the web provides an infinitely better experience.
You can put in extra functionality in a native application
Camera, Address Book, App purchases etc. These are either not possible via the browser or just not ‘easy’ to implement.
Now let’s take it back a few years ago. We had various desktop platforms. Mobile platforms weren’t really mainstream. The web was a wonderful place. Us makers, developers, software craftsman could make something that everyone with an internet browser could use. That was all you needed. That one application, the browser. It didn’t matter what desktop platform you were using. The web was our new platform.
So why have we gone back to the past?
My answer is simple. Mobile browser vendors.
They have only recently implemented hardware acceleration into the browsers. That isn’t necessarily their fault. Let’s remember that the standards have only recently been formalised.
But more importantly, they don’t currently implement any of the useful native features.
Many of you will have heard of PhoneGap. PhoneGap is basically a browser wrapper adding these extra bits of native functionality into applications built using web technologies.
PhoneGap in my opinion is an excellent interim solution, but it won’t be long until browser vendors start implementing native functionality. The problem we have is again the standards issue.
Search for “ArtSpotter”
Visit artspotter.com
Picture this: You’re in a new city and forgot to research its art scene before arriving. Does your iPhone have a solution to this 
