GenyMotion Quick Fix

I have been setting up Geny Motion today to run with Android Studio, and was having difficulty setting up. Followed the instructions and installed Virtual Box v5.0, yet was still getting the error “Unable to load VirtualBox engine’.

For once Stack Overflow wasn’t very useful (omg), so got this fix off a colleague ( so thought it would be good to share further. And yes, you do have to sudo. Quick and simple:

sudo cp /usr/local/bin/VBoxManage /usr/bin/VBoxManage

Asset Generation for Web & iOS: Updated 21/07/15

When generating assets, every designer/developer will have their own workflow and preferences on top of the standard ways of doing things. I wanted to share some tips on how I generate assets for applications and websites. Being a designer and developer, I may do it slightly different to someone who, say, needs to pass their assets over to a developer. However I still generate my assets in a way that if I was absent, another member of the team would know what these are for and how to use them.


Screen size

As I do when designing, starting with the smallest and biggest screen size first (if the application was for multiple devices) is the best way to go. If your design is literally just for one screen size on one specific device, then you are wrong – apps need to be responsive and adaptive to different devices, especially with how rapidly technology is changing.

Creating assets in a workspace (I usually use Adobe Illustrator) and exporting as the largest screen size can save a lot of time later. This can also solve resolution issues when needing this image at ‘x’ size later on, as the images (for web) will only be getting smaller if you start with your largest screen size. But what screen size do we use for desktop? The most common size is currently 1024×768 so this is a good starting point, but you need to ensure that the site looks good on extended sized (1600 x 1000) and smaller sized (800 x 600) browsers. On Chrome, a good extension to download is the window resizer, which allows you to resize your browser window to several sizes.


For iOS devices, each device has a set size and is either @1x, @2x or @3x. 1x is regular, 2x is retina and 3x is retina plus. Depending on the device you are providing assets for, you will probably need 1x and 2x assets (3x is only used for the iPhone 6+ currently). These types are used for the following devices:

Screen Shot 2015-05-01 at 11.40.24

This source comes from the brilliant site – a must for iOS design. You can also use the iOS Human Interface Guidelines on the official Apple site, but this one gives you all the relevant parts straight away.

When exporting assets, I like to ensure that everything has an even number with no decimal places. No major reason, but it helps when you may need to create extra assets of different sizes later on, as it ensures that they are all of a nice rounded off number.

For app icons, the following icons are needed (for Xcode 6):

Google Chrome - -  - Screen Shot 21 July 2015 09:23

You may also want to include app icons for the Apple Watch if your app is to be available on this too. Apple will make the icons rounded for you, so there is no need to export as rounded icons. Then at least if the conventions change, you won’t have some dodgy looking icons that you will then have to change again. A good tool to use for exporting app icons is: by Pixel Resort. This is a brilliant template – just open in Photoshop, place your icon within it and use the in-built actions to export all the sizes. It comes with a lovely preview screen, gridlines and masks, all to help you get the best out of your app icon. The only app icons that are exported with this template that I do not use are the ‘Icon-60’ and ‘iTunesArtwork@2x ‘ icons.

Adobe Photoshop CC 2015 -  - Screen Shot 21 July 2015 09:37

We have created multiple app icons for the same project and attached them to different schemas in Xcode, so that we can tell the difference between our develop, staging and production builds.


As for naming your assets, the general format that I use is ImageName_btn-736h@2x. Capital letters used for readability, an _btn if it is needed for defining an element, the -736h for the height (again only if needed to distinguish) and the @2x/@3x (for 1x there is no need to put an @1x at the end). Not only do I export assets, but I also export my UI screen designs to help the developers with their layout. The format for this is 01_HomeScreen, using a number extension at the beginning of the file name to clarify the screen order. However a user flow diagram with the screen names and small images is also good for this.

Naming for appicons, I use the Pixel Resort template as mentioned above, but this doesn’t name them appropriately for my needs. I have all the icons exported in a folder called AppIcon.appiconset (ready for putting into your Xcode project), but you may want to vary this name slightly if you are using different app icon sets (such as DevelopAppicon.iconset, for example). As for naming the icons themselves, I use the general format of AppIcon29x29 with the appropriate @2x/@3x extension where needed. See my icons below:

Finder - -  - Screen Shot 21 July 2015 09:31

Folder Organisation

The most important thing is to keep your folders organised when passing assets/designs over. Having an organised folder structure with designs > journey 1/journey 2 etc. and assets > screen 1/screen 2 etc. is crucial for developers being able to find what they need to implement your work. It’s very easy for things to get messy, especially when designs get changed frequently, but it’s worth being a tad OCD about this kind of thing.


My main programs for exporting assets are Illustrator and Photoshop. In Illustrator, it is as simple as creating your asset, resizing appropriately (as it is vector based) and pressing ‘export’. But be careful, as Illustrator does not always export the files 100% to their size in AI – sometimes there are a few pixels added on. In Photoshop, there is a brilliant tool called asset generation. You can simply put your assets on separate layers, adding the extension ‘.png’ or whatever extension you want it and of course checking that your files are named correctly (ImageName@2x.jpg). From there, you press File > Generate > Image Assets and all of your layers will be exported in the specified file formats into a folder. You can even create the folder structure for this too. Excellent for real time updates, especially when you’re sharing your assets and need to make a lot of changes. It saves needing to press the export button over and over too.


Another thing I find myself exporting a lot is buttons. If possible, check if these can be created by developers using code to save on loading time. Also, if you’re creating a button with text included, remove the text before exporting. This way, the text can be added on and styled with code, and can be changed so much easier than if the text was stored in the image.


One last thing to think about is if you are designing for animation. For example, if you were exporting a vector image of a person to put into Flash, you may want to export all of the joints and specific areas of the body that will be moving separate, to save problems later on. So ensure that all your different parts are grouped rather than joined together, as even if you don’t want to animate now, the need may appear later on.

That’s most of what I have to say for now. My main focus is currently iOS at the moment, hence the slight bias towards that in this post. This post will be added to as I do more stuff and find more tips and tricks along the way, but this is the way that I do things and the parts that I wanted to share. I will be starting to use Sketch soon, replacing AI and PS for a while to see how it goes, so will update at the end of my trial for this.

Handy Color Code for Custom Values in Swift

So that RGB values can be entered in XCode in Swift (for example changing the background colour of a table view), place this UIColorExtensions file in your code:

import Foundation
import UIKit
func UIColorFromRGB(rgbValue: UInt) -> UIColor {
    return UIColor(
        red: CGFloat((rgbValue & 0xFF0000) >> 16) / 255.0,
        green: CGFloat((rgbValue & 0x00FF00) >> 8) / 255.0,
        blue: CGFloat(rgbValue & 0x0000FF) / 255.0,
        alpha: CGFloat(1.0)

Then call it in your viewDidLoad() or wherever you want using:

        view.backgroundColor = UIColorFromRGB(0x209624)

Very useful for custom colors in Swift.

Rejecting the ‘9-5’ and Embracing Remote Working

Companies nowadays are trying to adapt to new ways of working. For many big corporations, this is an un-traditional approach, but one that needs to be acknowledged in order to obtain and keep the best people. This is a topic of interest to me, so I thought it would be an interesting one to discuss.

I work for a large corporation in London, but I live in Essex, with an average journey time of 2 hours each way (on a good day) which comprises of a drive, a walk, overground train, underground train and another walk. This can get pretty stressful and tiresome, and quite frankly can ruin my attitude towards work for a day if all goes badly. To combat this, I arrive at work between 7.30 and 8.00, leaving between 16.00 and 17.30 on an average day. Thankfully, my company are great with ‘flexi-time’ and are embracing this new culture of allowing remote working too, which is a complete god send: not only do I feel relaxed and well rested, but I usually end up working more productively and for longer because of this.

I have recently been discussing with several other ‘long distance’ employees at work (who are all earlybirds like me) and general attitudes towards this. The general attitude at my place of employment is just to go ahead with remote working until told otherwise. This makes a lot of sense – as long as we get our work done to the best of our ability and communicate with our team, being in the office when needed, what does it matter? My team have recently embraced ‘Remote Wednesdays’, where we will work either as a team or individually in a location of our choice, whether it be a coffee shop or at home, which has been working very well. Thanks to tools such as Slack, Github and Dropbox, we all have a continuous workflow with each other and ways to communicate – we all love it so far. Hopefully the higher ups in the business won’t disagree with us and take it away.

The main reason I wanted to write this post was to give some genuine insight into how customising your own work regime is working at my workplace, in case other people would like to embrace it also. So here are some bullet points into why working this way is great:

1. A different work routine isn’t an incorrect work routine

Just because someone isn’t at their desk 9-5 doesn’t mean they are not working. The most creative people almost never work from 9-5 – early hours seem to be a common theme. A lot of developers seem to prefer the night, starting late in the day and then working on/off throughout the night. Github is an interesting way to see how people work differently in teams.


2. Becoming a robot is not a good way to get rewarded

If you become that person who seems to live in the office, you will burn out. Working more hours is great if you really enjoy what you are doing, but everyone needs to know their limits and when to take a break. You may end up falling out of love with what you’re doing, or just become so exhausted that you cannot function. Either way, the best creatives and the most happy ones have a good balance. Getting in ‘the zone’ is much easier, and time will pass quickly by itself.


3. People need to be engaged

If you’re not engaged with what you are doing, you will get bored and lose your enthusiasm. Remote working gives us a good way to get out of ‘those’ meetings that dull your mind for the rest of the day. It is a known fact that the most creative people get bored and distracted easily if they are not stimulated, as their minds are always looking for something to occupy them. Giving them the freedom to choose their own working environment gets more out of the person and, therefore, gives more back to their company. A fun office environment is a plus too!


4. Risk taking is a part of life

We embrace the Agile methodology: fail fast. Try this way of working, and if it doesn’t work for you, it’s not the end of the world. You will learn from your mistakes, which is the most important thing. You need to accept failure in order to reach success and understand why the failure happened in the first place. It’s hard at first, especially if you work in a subjective area such as design, but you need to not take failure personally. Step up to the challenge and make it work.


5. Daydreaming is important

It’s hard to daydream in an office with phones ringing and people rushing by. Headphones work to an extent, but it is extremely important to have the space and time to think. Daydreaming allows your imagination to expand and gives your brain some downtime. Thinking is so crucial, especially in the early stages of a new project, as it allows you to consider all possibilities, and the 5 minutes a day that you get some good quality daydreaming done may produce a big idea or approach that you never would have considered otherwise.


So the rest is up to you. If there are any other personal reasons you feel for working your own way, let your employer know. They train you, they should be willing to make you happy enough to keep you. It is still a touchy topic at times, but we’re all human at the end of the day – no-one wants to see someone else crash and burn out. I write this while working remotely from my home, and it’s a brilliant thing to be able to do, and the creative juices have certainly been flowing today!

Note: All images are copyright to me – no usage without permission.

Setting up Homebrew, Node, Bower, Grunt & more

We use a variety of Homebrew, Node, NPM, Bower, Grunt and Compass in the majority of our web-apps to aid us with managing our packages and dependencies. From having messed this process up on my machine numerous times now, I am going to document this process so that it may help others in the future, as the Internet was not the most useful of places when I was trying to sort this out by myself. Luckily a colleague has saved the day for me numerous times, so to avoid annoying him further, here is our process 🙂

Note: This process is just to set up a clean install on our machines – I will explain further in another post how to get all of this working within a specific project.


Step 1 – Install Homebrew

$ ruby -e “$(curl -fsSL”

Homebrew installs packages and then links their files for you. It is very important that you do this step before anything else so that you can then install packages through Brew, to save having symlink problems later on due to duplicate versions being installed. Install Brew wherever you like.

Step 2 – Install node

$ brew install node

Node.js is a platform built on Javascript’s runtime, great for building real-time applications. When you install node, it comes with npm, its package manager. Npm is great – through this we can install bower, grunt as well as many others that may be needed for future applications.

$ node -v

$ npm -v

Run these commands just to check that your current versions are up to date.

Step 3 – Install Bower

$ npm install -g bower

Bower is another package manager that manages your libraries, frameworks etc. This command will install Bower into your node_modules. Use  a bower.json file to list your packages and the versions that you want – Bower will take care of the rest.

Step 4 – Install Grunt

$ npm install -g grunt-cli

Grunt is a js task runner. Configure a gruntfile.js to automate your tasks using the many plugins available. This makes unit testing, real-time changes and minification so much easier. This task also installs the grunt command line interface.

Step 5 – Install rvm

RVM manages your rubies and shows which ruby your current shell points to. This step may vary for different people. You may need to install gpg (this verifies signatures and publishers) as Mac OSX doesn’t do this for you. If this is the case install it through brew:

$ brew install gnupg gnupg2

Once you have this verification step set up, you need to install this public key necessary for rvm:

$ gpg –keyserver hkp:// –recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3

Then you can run the command for installing rvm. If the above steps are already configures, you can skip straight to this:

$ \curl -sSL | bash

To start using rvm, when the last command has finished running, you should see something like “* To start using RVM you need to run `source /Users/UserName/.rvm/scripts/rvm` in all your open shell windows, in rare cases you need to reopen all shell windows.” so run:

$ source /Users/UserName/.rvm/scripts/rvm

Now we need to install some rubies, as we currently will only have the OSX ruby, which requires sudo (NEVER do a sudo – if you need to sudo, something is wrong with your setup). To see available rubies:

$ rvm list

And no rubies should be installed yet.

$ rvm install ruby

To install your rubies.

$ which ruby

Shows your installed rubies – should show rubies in your user path. Now that there is an rvm ruby installed, you own it and can ‘gem-‘ install things without needing to sudo. If these steps hadn’t been done, you would have got an error saying you didn’t have access when trying to gem- install things.

Step 6 – Install compass

$ gem install compass

Installs a gem for compass.

$ npm install compass

Installs compass using npm into your node_modules.

Step 7 – Install selenium

$ brew install selenium-server-standalone

Selenium is needed for automating your web browsers for when you run your tests. If you don’t have tests or think you don’t need this, then wrong – write some tests for your code!

Step 8 – Install chromedriver

$ npm install chromedriver

A wrapper for selenium – also needed for running your tests.

Step 9 – Install Protractor

$ npm install -g protractor

We use Angular, so this is needed for running our end to end tests in the browser. If you don’t user Angular, you won’t need this. Highly recommend using Angular though – it’s awesome. This will install cl protractor and webdriver-manager.

$ webdriver-manager update

Download the binaries to get selenium running.

$ webdriver-manager start

Start up a selenium web server. You may get a pop-up requesting that you download a Java JDK to use the cli. Do this if you haven’t already done so.

Will update some more later to show how to link all this up to your projects to get them running, if you can’t figure it out yourselves 🙂

Merge Conflicts From Branch To Branch On Github

Occasionally, there will be a time when you are merging one branch into another on Github (in our case, develop into staging, as our branch hierarchy goes newBranch(es) -> develop -> staging -> master *) and although it may seem scary when that grey box appears, it isn’t difficult to fix. In the example below, we are pushing to develop from staging:

git checkout develop
git pull origin develop
git checkout staging
git status (all should be up to date).
git merge develop
git mergetool (then press 'enter', fix the conflict using the mergetool, save and close, then type 'y' when prompted).
git status (should show you the changed file ready for committing. There may be a '.orig' file duplicated of the file with the conflict - this can be deleted).
git commit -m "Fixed merge conflicts"
git push origin head

This should solve any problems, unless you’ve got a complicated merge on your hands.

* our branch structure is this way not only to avoid merge conflicts and issues, but to fit in with stakeholders’ features. Each branch has to be merged into develop then deleted. Each contributor will be pulling from develop just in case there are any changes. After develop is ready to be shown to stakeholders and test users, with stakeholder warning and approval, develop is pushed into staging. Only after the stakeholder has approved of the changes in staging can staging go into production (master). The main thing we have to be careful of with this is possible problems when the stakeholder doesn’t like a feature in staging, when someone has already pushed another new feature into develop. To avoid this, all contributors have their own branches to work on, and only push to develop when a staging feature has been approved and is being pushed to develop. All the while that they are working on their features, they are pulling from develop to stay up to date.