Fly is now Open Source

It's a known fact that ninjas like open source. There are many good reasons for releasing your source code into the open, but in the end we do it because it feels right.


The Fly app was originally hacked up over a weekend in late 2010, but has been polished a bit since then (although there are still some rough edges here and there). The Qt version has been published in Ovi Store (both for Symbian and MeeGo) and Google Play (experimental) and we've had some pretty good download numbers, for a local app.

That's not to say that it's anywhere near perfect. There are lots of improvements that can be made. If you feel like improving it, the sky is the limit! (pun intended ;) ).

It has been a long time coming, but we have finally released the Fly source code as open source. You can clone the github repository here or browse the source code here. Happy hacking!

Designing assets for app developers

The development of apps is becoming more professional. As a result of this specialists like graphic designers are more often the creators of the look of an app these days. However, it's still very much the realm of the programmer to deconstruct the design - and breath life into it. As a graphic designer, you can either help or hinder the developer in this job. It all depends on the assets you provide. Here is a list of best practices for graphic designers delivering assets to mobile developers. I assume the original designs are made with Photoshop/ Illustrator/ GiMP and that the programmer prefers them as 24bit .PNGs with an alpha channel.

1. Break up your screens into UI elements

It's a good idea to provide mock-up screens  as a reference -  but these are not the files a developer wants to work with. You need to break the design apart into its different UI elements. Any button, frame, indicator, switch, arrow, toggle that you designed needs to be provided  in a separate file. If you leave this task to the developer your design might suffer inferior Photoshop skills and you're wasting his time.

2. USE LAYERS, align them, provide all states

In each element file you need to provide all the states and color variations as separate layers. Take a custom button as an example. It comes in three colors and has two states (normal and pressed). That means you have to provide a button.psd with  six  layers: "black_normal", "black_pressed", "blue_normal" ... you get the idea. Make sure to provide complete sets here. If you leave out layers, you've left the completion of your design to the programmer.  When you have complex set of layers where it is not obvious how they interact, make it simple for people by creating Layer comps in Photoshop. Also, make sure you've aligned the content of the different layers to their correct positions. The programmer should be able to simply save each layer in a separate .PNG without any extra work.

3. Use a sensible naming convention

If you pick a sensible naming convention for your files the programmer can adopt them and carry them on into the code with their original names. This makes it easier for both parties when designs needs to be updated, changed or expanded. Sensible file names from a programmers perspective means:

  • follow a consistent naming pattern. Example: header_button.psd, header_gradient.psd, header_logo.psd or similar.
  • use safe characters: lowercase a-z, 0-9 and _

4. Align to pixels

This really shouldn't need telling, but apparently still does: Align your shapes to pixels. This means, almost without exception, any shape you add to your design must have a top-left and width-height that is in full-pixel values. This can be done easily in Illustrator, and moderately easily in Photoshop ("Snap to pixels" in the Shapes dialog). Coming back to the programmer with miss-aligned half pixels  is literally like flipping him the bird.

5. Summarize your color, font and margin choices

A lot of what the programmer ends up doing is condensing your design into reusable components and variables, hopefully without compromising its look. You can help in this by providing a list of your design guidelines. Ideally this list would contain your choices of:

  • Colors: text colors, button colors, list colors, effect colors
  • Gradients: backgrounds, effects etc.
  • Fonts: list of faces used, list of sizes used, shadow effect settings
  • Margins/Paddings: numbers for guides or grids used

6. Make your graphics scalable

It is no longer realistic to believe you are designing for one resolution or platform. More likely your design will be used for developing apps on both tablets and mobile phones across multiple platforms. Your design needs to be scaleable. You should always use vector shapes, your gradients and effects should be scaleable, you should never use pixmaps, your fonts should be readily available or embedded in the file. Basically, your image should look good rasterized to any size.

7. Tips for the elite designer

If you're already following the above guidelines you're making most  app developer happy. But if you want to go the extra mile, here are some tips to make your programmer even happier:

  • create scripts the programmer can run to render all assets to an arbitrary resolution
  • put your designs into any sort of version control system (git / svn / rcs / perforce)  - we honestly don't care. Anything is better than zip files over mail, dropbox or whatever.
  • pre-render the assets to our current target resolutions - we'd love you for it.

Icons by

Cutehacks targeting Android, Symbian and more

[tweetmeme source= "cutehacks" only_single=false]Here is a video of two apps developed by Cutehacks: and Fly running on Android 2.2 and Symbian. These native apps were originally written for Symbian but run great on Android as well:

Using Qt for Android (more specifically Necessitas and Ministro), the amount of code changes we had to do were minimal. This shows the power of Qt - it truly is cross-platform. Too see these apps running on MeeGo and Maemo as well - check out this video.

None of the apps above are available in Android Market yet. Be assured we'll tell you when/if that happens :)