Forecast - Yet Another Weather App

What is Forecast?

Forecast is an application that shows you the weather in a beautiful way. Everything is in one place and with a simple swipe you can get details about the current day or the week. 

Features:

* Current weather conditions
* Weekly forecast
* Daily temperature graphs
* Daily precipitation graphs
* C° and F°
* 4 colour themes

Future development:

* Multiple locations
* Wind direction and speed
* Support for more languages

Why another weather app?

Why not? The design is beautiful and it's definitely something that me and Dennys love using. You can see all the important things without any effort. If you want more information just swipe right and you can see more details about the day. Swipe left and you get more information about the week. 

But it all comes down to one thing... we built it for ourselves. Now, if more people like it and want to use it, that's great! We will keep getting feedback and we will improve the app. And if you are looking for a unique selling point... there isn't one. 

The story behind Forecast

One day in October I was browsing Dennys' Dribbble Portfolio (friend and ex-colleague from our Fantasy Interactive days) and I noticed a beautiful weather app concept that he has designed.

So I reached out to him and asked him if he was interested in building it for real. He agreed and that's how it all started.

Dennys lives in Hong Kong and I live in Stockholm. Because of the distance and time difference we needed to find some tools that would make our collaboration easier. 

We used Slack, Skype and Twitter as our main communication tools. We also used InVision for sharing design assets and for building the first prototype so that we could see how the app would feel before writing any code. For managing the work we used Asana and for out beta testing we've been releasing the app to a small set of friends via Twitter's Fabric.io. Finally, for our user testing sessions that where handled by Vicky Karponi we used Loopback. We also conducted interviews and observations of users.

Why is it not free?

Good question. The Forecast.io API, where we get the data from, is not free. The server for the microsite and the domain name also cost some money. And we hate ads. The moment an ad is shown into an app, it is my opinion that the app feels cheap.

Is there an Android version?

No there is not. Is there going to be one? I don't know. I have nothing against Android (I actually prefer it) but right now I don't have the time to build and maintain the app in two different platforms. 

Duotone on iOS

Spotify's new brand identity is full of bright colours. Here is the same effect but for iOS.

Code: https://github.com/72lions/Duotone-iOS

One of the ways to achieve this result is the well known duotone process where you pick two colours (one for the highlights and another for the shadows) and you replace all colours in the picture with these two.

Sounds simple, right? Well it is. You can read more about the process in a previous post where I describe the effect in JavaScript.

Duotone in JavaScript

Spotify's new brand identity is full of bright colours. Here is the same effect but in js.

Demo & Code: http://codepen.io/72lions/pen/jPzLJX

One of the ways to achieve this result is the well known duotone process where you pick two colours (one for the highlights and another for the shadows) and you replace all colours in the picture with these two.

Sounds simple, right? Well it actually is. This is what you need to do:

Convert the image to grayscale

This is very simple. The way you do it is by calculating the weighted average of the R, G, B channels.  Then you apply that value into every channel. For example: let's imagine that at a specific pixel has a colour with the following RGB values: 100, 200, 84. The average would be (100 + 200 +84) / 3 = 128. Then you replace the values of each channel with the new number, 128 in our case. You do that for all the pixels in your image.

for (var i = 0, offset, r, g, b, a, avg; i < pixelCount; i++) {
  offset = i * 4;
  // Gets every color and the alpha channel (r, g, b, a)
  r = pixels[offset + 0];
  g = pixels[offset + 1];
  b = pixels[offset + 2];
  a = pixels[offset + 3];

  // Gets the avg
  avg = Math.floor(0.299 * r + 0.587 * g + 0.114 * b);
  r = avg;
  g = avg;
  b = avg;
}

Create a gradient between the colours

So, by now you should have a grayscale image. Next step would be to create a gradient between the two colours. That process is also quite simple. You decided how many steps the gradient will have. I believe that 255 steps are enough.

  // Creates a gradient of 255 colors between color1 and color2
  for (var d = 0; d < 255; d += 1) {
    var ratio = d / 255;
    var l = ratio;
    var rA = Math.floor(color1[0] * l + color2[0] * (1 - l));
    var gA = Math.floor(color1[1] * l + color2[1] * (1 - l));
    var bA = Math.floor(color1[2] * l + color2[2] * (1 - l));
    gradientArray.push([rA, gA, bA]);
  }

Swap the colours

For applying the new colours we first need to know the Luminance of each pixel. We can find it quite easily by using an rgbToHSL(r, g, b) algorithm. The last value is the luminance value. Now that we have the luminance value for any given pixel, we can use that value (0 - 254) to pick a colour from the initial gradient and replace the already existing value.

We then put the data into the canvas and call dataURL() which will return a base64 encoded image. 

Word of advice

If you want to use this in production, you should know that this is a heavy operation. It might block the main thread for quite some time and you might miss 60fps. That's why I recommend that you put as much code as you can into a Web Worker.

That's it. If you have any questions don't hesitate to contact me.

PassThrough Shader with Cinder

Playing with Shaders in Cinder and using my girlfriend as guinea pig. It is a simple Pass Through OpenGL Shader applied realtime on the camera data.

Collection view with spring physics

A collection view with spring physics while scrolling. Similar to what the iOS 7.0+ Messages app does and supports both vertical and horizontal scrolling. This small experiment is heavily inspired by Ash Furrow's guide on UICollectionView + UIKit Dynamics.

Get the code from Github.

Playing a chunked MP3 with Media Source Extensions

In this proof of concept (currently only tested and working in Chrome 35+) I've split the mp3 in 25 parts by using the unix split command. The moment the first part is loaded then the playback starts immediately and it loads the second. When the second part is loaded then it is appended to the SourceBuffer by using the Media Source Extensions API.

You can check the source code on Github or check the demo.

A lot of thanks to Theo for letting me use his awesome track Breathe In.

There is another implementation that I created a year ago which uses only the Web Audio API. You can find it here.

Multi-user collaborative step sequencer with NodeJS

Last February at the Spotify office in Stockholm we held the Music Hack Day hackathon.

Music Hack Day is an international 24-hour event where programmers, designers and artists come together to conceptualize, build and demo the future of music. Software, hardware, mobile, web, instruments, art - anything goes as long as it’s music related.

Our team which consisted of David Lindkvist (@14islands) and the awesome guys from Plan8 (@Plan8_Music) created a multi-user collaborative step sequencer with NodeJS. So that means that several users can connect with their mobile devices or desktops and play a step sequencer together hosted on one of the devices connected. One device will be able to act as the main controller for all sound controlling filter and pitch.

Try out the demo or checkout the project on Github. 

Playing a chunked MP3 with the Web Audio API

In this proof of concept (currently only tested and working in Chrome 24+) I've split the mp3 in 25 parts by using the unix split command. The moment the first part is loaded then the playback starts immediately and it loads the second part. When the second part is loaded then then I create a new AudioBuffer by combining the old and the new, and I change the buffer of the AudioSourceNode with the new one. At that point I start playing again from the new AudioBuffer.

A lot of thanks to Paul (@aerotwist) for his suggestions and to Theo for letting me use his awesome track Breathe In.

You can check the source code on Github or check the demo.

Google Ramayana wins FWA People's Choice Award 2012

I'm very happy to announce that Google Ramayana was awarded by FWA with a People's Choice Award for 2012. 

It was an absolute pleasure to be part of the team and to work next to some of the most talented designers and developers out there. It was a lot of fun and I learned a lot next to these people: Justin Windle (@soulwire), Paul Lewis (@aerotwist), Claudio Guglieri (@claudioguglieri).

Google Ramayana is a traditional Sanskrit narrative cherished by Indian culture now made Interactive with Google Chrome. 

You can experience it yourself here: http://ramaya.na 

HTML5 vs Flash

Disclaimer: I support the Open Web. I love HTML5. But I also love Flash.

Now that that is out of the way let me take you back 5 years, when Flash was still cool. Remember those amazing interactive websites featured on the FWA website? Running smooth on your browser? We would create an interactive experience and it would work on all browsers. The catch? You needed to install the Flash player which some browsers had it pre-installed.

I remember doing crazy shit and getting 60fps. I would have a full screen background image animating while on the foreground a video player was playing while some particles would animate according to the audio data. Again... at 60fps. I could also have 3D scenes with Papervision3D and have a great performance too.

Fast forward to now. Flash is an outcast, replaced by HTML5. If I need to do crazy stuff I would need to check:

• If I can use CSS property X and Y in all browsers.
• Which video filetype is compatible with all the browsers that I need to support.
• How to force hardware accelerated animations.
• Is canvas supported for doing my particle stuff?
• Is WebGL supported for doing my 3D stuff?
• Is there support for the Web Audio API?
• Make sure that I have a nice fallback when a browser doesn't support all the things that I need to do. 

And after I do all that, the experience would still be different in every browser.

But that's fine too. The thing that drives me crazy is that we went from smooth experiences to slower and lagging experiences and we are OK with it. We justify the slowness because it is HTML5. We dropped our expectations.

I'm not saying that it is not possible to get 60fps with HTML5, I'm just saying that we now need to understand how the browser works behind the scenes. When does it repaint? When does it forces a layout? And that is per browser. Because Chrome does things in a specific way, that doesn't mean that Firefox or IE will do it in the same way.

All of the above makes us to have to work more on a project. More work means higher cost. Now, try to explain to a client why it is better to have an HTML5 experience when:

• It will be more expensive for the client.
• It will take more time to build.
• The experience won't be the same on every browser.

I'm not blaming HTML5 for this. I'm blaming the browser vendors. Firefox, Chrome and the others alike are advocating for HTML5. Fine, I agree. But if you are going to start a war against Flash, then make sure to give us at least the same or better experience and performance.

Here are a few reasons why I think Flash is superior than HTML5:

• In Flash when we were animating stuff we didn't have to worry about the redraw regions because Flash was handling that. HTML5 gave us canvas. We now need to handle the redrawing of the regions ourselves. Or use 3rd party libraries (more code to maintain). If we don't do that then our performance will decrease.
• Flash had a great API for drawing.
• You had access to low-level stuff. E.x. you could be messing with bytes.
• AS3 is an Object Oriented programming language with Classical Inheritance.
• And much more... 

The craziness of it all

People advocate for HTML5 but they don't like the specs or JS itself and they are using programming languages like CoffeeScript, Dart and TypeScript. Some want OOP inheritance, other want strict types and they have basically created new programming languages that "fix" the things that they don't like. Nicholas Zakas nailed it. He gave an interview at the guys on Nettuts and he said:

“if people actually took a little bit of time to learn JavaScript before diving in, I’d hope there would be a greater appreciation for what a unique and dynamic language it is.”

— http://net.tutsplus.com/articles/interview-with-nicholas-zakas-of-box/

Then we get libraries like Johannes Koggdal's oCanvas that provides a nice API for drawing in Canvas. Similar to what we had in Flash.

Another argument against Flash was the whole SEO problem. And it was true. Spiders couldn't read the content inside the Flash file. So developers had to create extra architectures for making the content available for the search engines. 

But look at the Internet right now. It is full of HTML5 web apps that take advantage of the History API and the people that were bitching about Flash now shot themselves on the foot. And now these people are creating complex architectures for making their HTML5 web apps SEO friendly.

What that tells me is that we were so eager to ditch Flash but then we replaced it with something inferior that we so hard tried to improve. And we also start doing the same mistakes that we did with Flash (check the SEO argument above). 

Final thoughts

I don't want Flash to come back. That's done. It's in the past. 

I just hope that people would stop bitching about Flash and recognise how Flash pushed the boundaries and contributed on the evolution of the web.

And finally, I hope that we as developers will push Google, Firefox, Opera etc and demand better and faster browsers.