Viewing entries in



Today's christmas festivities were celebrated in the form of a bit of hacktastic skullduggery, in the form of an overdue get together of Bournemouth's finest coders, hosted by our friends at RedWeb.

I decided, given the festive season, to take some time to get acquainted with SpriteKit and build out the game idea that I had been conceptualising with my little 3 year old son Rudi.

The game, a Disney Cars inspired shoot em up, where Rudi, the games main protagonist, gets to fire his warchest of cars toys at the oncoming Tyger (Rudi's one year old brother). The premise of the game, to provide a virtualised outlet for Rudi to satisfy his insatiable urge to throw things, whilst teaching him the appropriateness of his actions in real world and virtual settings.

I set the game scene up quickly, based on a fairly generic xcode SpriteKit game template and the very entry level tutorial from Ray Wenderlich.

The main customisations I made, aside from the graphical components, were features driven by requests from my son.

1. "Daddy, can I throw different Cars?" 

The initial game setup just had a single projectile type, the obvious Lightning McQueen. So one of the first orders of business, was to create a full armoury of projectiles, of our favourite Cars characters.  First request was for Professor Z, and not content for long, I added 9 different options. 

I setup a UIVIew container, and placed the UIButton outlets inside it. I created a UIButton *menuButton which would have a background image that reflected the currently selected image. When the menuButton is pressed the weapon drawer will toggle open and closed.

2. Unlocking Weapons

It would be all too boring to just put all the projectile types in the tray from the start. Instead, I setup a simple game mechanic that involved unlocking the projectile types when a certain number of hits had been achieved. Whenever 

projectile:(SKSpriteNode *)projectile didCollideWithMonster:(SKSpriteNode *)monster

is called, the int pointsCounter is incremented and the score label text updated. We also save the score to the NSUserDefaults.

- (void)projectile:(SKSpriteNode *)projectile didCollideWithMonster:(SKSpriteNode *)monster {

[projectile removeFromParent];
[monster removeFromParent];
if (updateLabel == NO) {
updateLabel = YES;
[self updateUserDefaults];
[self loadProjectiles];

3. "Daddy, can I move myself?"

I enabled Core Motion, to access the accelerometer to enable using the tilt of the device to move the Rudi character up and down, whilst firing at the on coming baddies.

I found this tutorial to be quite helpful here:

What next?

There's still much to do before the game will be accepted by its harshest critic. Some of the next things will be:

  • Fix some bugs with current physicsBody affecting the Player node.
  • Use SKParticleEmitter to create collision explosions, projectile trails, and smoke.
  • Create levels
  • Give projectiles different properties and behaviours.
  • Parallax for background scene to provide some depth

Thanks to the internet for providing the images and other such assets.

How to format ISO 8601 Date Format in iOS

So, it turns out NSDateFormatter, a formidable class for converting and manipulating date formats in iOS development, met its match with the ISO8601 date format that I was getting from a rails based API. Or at least, that's what I found. So here's how I coped with it:

The json:

"start_date": " "2014-10-26T21:00:00.000+00:00"

Turns out, NSDateFormatter can't parse this.

I did quite a bit of digging around and in the end, my friend and mentor @HunterBridges pointed me in the direction of this nifty little library on GitHub

It even has a nice little xkcd comic in the README, so definitely work checking out, just for that.

I downloaded and extracted just the header and implementation files "ISO8601DateFormatter" and included them in my model class. 

#import "ISO8601DateFormatter.h"

Then, in the implementation where I was initialising my model instance from the API response dictionary:


NSString *datestr = [result objectForKeyNotNull:@"start_at"];
NSLog(@"Date String: %@", datestr);
ISO8601DateFormatter *dateFormat = [[ISO8601DateFormatter alloc] init];
NSDate *date = [dateFormat dateFromString:datestr];
NSLog(@"Formatted Date String: %@", [dateFormat stringFromDate:date]);


Note "objectForKeyNotNull:" method is a convenience method for making sure the result doesn't contain a null value.

So, I grab the original date format from the web service response and save it as an NSString.

I then alloc and init the new ISO8601 class as dateFormat variable. Then I create a new NSDate object and call dateFromString on my dateFormat variable, passing it the original dateStr variable as a parameter.

And that's it. Later on, I create a normal NSDateFormatter to parse the new date object and get just the time in HH-mm format, which is what I actually wanted for the app feature I was building.





If Snapchat and Tinder weren't evil || Lumpy - iOS App (part 2)

Then they'd probably do something like this....

A while ago, I wrote a post about a particular product hypothesis I had. I won't regurgitate the underlying rationale and background research, but needless to say, I think it's compelling enough. Since that time I've been pretty full-on building my startup Nuwe & consulting at Nourishcare.

But, a couple of incidents recently brought back to my attention this concept and I've decided to flesh it out a bit more. Today peoples, we're fighting cancer. And broken bones. And probably other things, but let's stay humble for the time being.

A few weeks ago, we were on a family holiday to Center Parcs. Near the end of the holiday, my 3 year old son, Rudi, fell off a coffee table and hurt his arm. It was clearly painful, and despite continuing to cycle and swim, he was also clearly carrying his arm in a way as to relieve the pain. When we got home, we took him to the doctor, who assessed and prodded and poked and, reticent to x-ray a 3 year old, advised us to monitor the situation. My wife and I asked each other 10's of times, whether we should take him for an x-ray, it clearly wasn't right. We asked each other, we asked other members of the family. We asked and asked and asked.

A few days later, we decided to take Rudi to A&E, and it turned out, he had a broken collar bone!

A week later, my wife went on a spa day with her girlfirends. Much to my amusement, she came hobbling home, having slipped getting into the jacuzzi and couldn't walk. A few days later and her ankle was purple. Again, the questions started - should I get it checked out? is it broken? 

How often must this happen? How often must this be needed but the person doesn't have anyone to ask? These are questions that tickle my interest.

What have Snapchat & Tinder Got To Do With This?

Does a day go by without seeing some rip-off of a snapchat or tinder type feature, UI approach or app clone? Well, don't expect anything different from me. Let's get all popular culture and ask ourselves "WHAT IF"?

What if, Tinder's amazingly engaging and simple gesture based UI could be put to use for more promising purposes?

What if, Snapchat's ephemeral messaging system that is popularly used for kids sharing naked photos of each other could be used to encourage sharing of sensitive visual information - such as photos of suspect moles, skin blemishes, lumps, bruises, potential broken bones - things we want to share, should share, but can't?

How does it work?

1. User takes a photo of a suspect skin blemish, mole, bruise, lump - something that's concerning them and they just want to invite feedback from family, friends, or the general public.

2. User selects the people they want to receive a very simple binary response - yes/no -which aims to answer the question "should I get it checked out?"

3. The responder receives the message into the person inbox, and is notified via push notification and if not responded after an amount of time, receives an email to their inbox.

4. The responder selects the message, which loads the message details. This contains the image "card" ala Tinder. The message will be visible for 15 seconds, encouraging the recipient to respond with their "gut" reaction and not to dwell / risk dropout and non-response.

5. The message will self-destruct after the timer runs out, and the message will no longer be visible to the recipient. Attempts to take screenshots using the camera will trigger the view to close before screenshot is taken.

6. The user can then embellish their response with additional notes and comments - personal experiences, words of encouragement, advice etc.

7. The user is notified when responses are received, and can view a summary of the responses on the message detail view, helping them to decide what action to take next.

8. Users can configure their settings to ensure their images are also deleted from the server, or retained on the server for their own personal future use and also for the benefits of research and visual recognition and machine learning for predictive diagnosis of skin conditions and injuries.

Take a photo or video

Select the recipients

Recipients received requests to their inbox

Time to Vote - who does it look?

See the results

Next Steps...

Next we have to validate this concept with our target audience, and for that we need to start to hypothesis who that will be, how to reach them, what they might pay (if they will) for the service, how much they'll cost to reach and a billion other questions...

10 Tips for Building Wireframes

10 Tips for Building Wireframes

I have been learning to create low and high fidelity wireframes for both mobile and web devices. There are a variety of different tools you can use to create these wireframes like Illustrator, Photoshop and Sketch ( only available on Mac ). I have been using Sketch 3 to wireframe as its a simple combination of both illustrator and photoshop. 

More and more designers are using vectors for wire framing. The following tips will help you make the most of your wire framing experience. 

Wire framing is about working rapidly and iterating quickly. The aim is not to create attractive interfaces; your number one priority is to design information and experience. 

Below are 10 tips that i believe to be important when designing wire frames. 

1.  Start Sketching

Sketch them first with pencil and paper for a quick sanity check. This should take about 30 seconds and opens up the possibility of getting early feedback. This can save a lot of time and money. The feedback gained through peer review or, best of all, from some early and informal user testing (you may need to spend a little more than 30 seconds on sketches if they're for user tests). 

2. Go Monochrome

Wireframes make clear the hierarchy on a web page; they visually demonstrate the order in which users should process the available information. If you want users to process the headline before hitting the "buy now" button, the headline needs to "trump" the button by demanding more attention.

This visual hierarchy can be defined in a number of ways. We could use size to make the headline more impactful, we could use positioning (by placing it before the button). We could use colour, contrast and a range of other things, but doing so in a wireframe only makes things more confusing.

By removing colour from the equation, the visual relationship defined by position, size and (if you want to go the extra step) contrast, is much cleaner.

We're not building pretty, pixel perfect UI kits here. Stick to a limited range of greys, then use color just for labels and notes. 

3. Don't forget the goals of the page 

Keep the goals of the page in mind when designing a wireframe. Focus on driving action. Organise the information into hierarchy that serves the goal of the page. 

4. Pick Your End Point

Prior to commencement, work out who will be consuming the wireframes, how they'll consume and what what level of fidelity is required. Remember that theres a relationship between the level of fidelity and type of feedback. Will quick paper sketches suffice or will they need to be fully interactive with accurate dimensions? Keep in mind: the less precise the wireframes are, the more liberty and creativity a designer is going to take with them. On the other hand, if you think they look perfect designers may feel inhibited and merely "colour in" the wireframes, preventing the design process from really getting going. 

5. Keep the rest of the team informed

Wire frames are not just for the client. All members of the web team should provide feedback on them, buying into the process at an early stage.


6. Use common elements

When designing a set of pages, use tools that allow you to make multiple changes to all common page elements at once. Moreover, as you're creating the wireframes, look out for design patterns that repeat. Leveraging these is key to gaining efficiency and consistency. 

7. Consider the content

If your wireframe aren't sketches then be realistic about the amount of content that will be added to the page. This holds true also for number (and length) of links and navigation. If practical use accurate sized fonts, images and consider what will happen when more text then ideal is added. Nothing on the web should be etched in stone, so ask if the design will flow as required. 

8. Draw on your experience

You do not need skills in design or development. All anyone needs is experience in using web apps or websites. Of course the more experience the better but you don’t need to understand relational databases to wireframe.

9. Keep it clean

If a particular page requires two text boxes and a button then it should have just that, no more, no less.

10. Get feedback 

I have learnt not to be afraid to test your wireframes with a couple of informal user tests. Grab people from around the office and ask them to find various bits of information or explain what they think the function of the certain elements is. 














10 Best Practice Tips for User Onboarding to a Mobile Application.

10 Best Practice Tips for User Onboarding to a Mobile Application.

1.The Goal.

The main goal is to accommodate your user and to get them using your product, ASAP. It’s highly important to make a fantastic first impression and to then carefully familiarize your users with the product so that they come back.


2. Communication is key.

You don’t want to talk their ear off but you want to be as charming as possible. Simply: Tell the user what they need to know. In as few words as possible, make them like you, being as witty or delightful as you can while doing it. It is also important to make sure you type in the correct formality for your members.


3. Welcome them properly.

It doesn't feel great spending so much time filling out registration and membership forms to then only walk in through the door with every single staff member acting as if you don’t exist.


A major part of the on boarding process is making a new member feel welcome. You want to be able to thank them for taking the time to join your product instead of just sending the invite to the junk box. If you haven’t set up a welcome email, then make one. It doesn't need to be long.


4. Making it easy.

This is where you will lose sign ups. Life is complicated enough as it is and if you do not make your sign up simple, you will be losing customers. Take some time to figure out what you actually want to know from your customers- the bare basics.


5.  Save them time.

Nobody, including ourselves, like being asked to fill out questionnaires or registration forms by people in the streets. You’re in a rush, you have to go to the doctor with your headphones in.  I’ve used all the excuses in the world not to stop to be asked to fill out a questionnaire. We don’t have a lot of spare time. We value our information and don’t necessarily feel comfortable sharing a lot of information right from the start.



Social log-in is a great time saver that is appreciated by a vast majority of consumers. You’re going to have some people who do not want to use this option, but you can offer a different mode for them. Pinterest is a great example of this. They have an option for a social log-in, or you can create a direct account. Do the same thing for your visitors.

The on boarding process should be warm in tone, fun and offer additional guidance if necessary. For example, if you've got a video available on how to make the most of their experience, this information should be included both in the email you send out and in their welcome  page.

6.  Creating a compelling CTA.

No matter what market you’re in, chances are you are facing some stiff competition out there. What can you do to make signing up for your customer a “must”? Take a step back and distil what it is that makes you unique into no more than 2 sentences. Your tagline should be placed in a prominent spot on your landing page.

7. Making Referrals.


The best way to make an influential person shout about your company? Start including friend referencing on your boarding process.  A fantastic example of this is Facebook. When you sign up and are getting your profile ready, you have the option of inviting friends/existing contacts.

There is nothing more influential than a customer who is totally excited about what you have to offer and wants to be the first person to share it with friends.

The added benefit of a referral goes back to your growth funnel. It takes a lot of people pouring into the funnel to keep it full so why not let your customers help you keep it full.

8. Don’t break the flow.

Designers usually strive to get the users into a state of “flow” in which a person performing an activity is fully immersed in a feeling of focus, full involvement in the process of the activity. There are many tools to help designers make this happen that can also be implemented into the design of your on boarding process.


One of the main requirements is to be as unobtrusive as possible. For example, don’t surprise your users with unexpected pop ups and messages. The best way to prepare the user is show them what steps are coming up and what they have left. For a fluid experience, context is important.



9. On boarding is a relationship and is ongoing.

Relationships are built on trust so don’t mislead your users and make it easy for them to trust you. Your users are new and are figuring out there way around your product. You need to nurture the relationship between yourself and them to keep the relationship going. Engage your users in a natural yet friendly way. You should spend time very early on in the on boarding process getting to know your users and what their needs are. This could be sending me them a personalized note to each individual right after the moment of email verification.10. Ease them in gently. People, including myself hate it when you visit a page or an application where it’s so busy and over complex, it makes me want to stay away. This isn't to say that you should not do something personal and fascinating.  What you don’t want to do is overwhelm the new users on their first visits to your application.There some examples of pages and apps where all the white space is full of content. Colours, images and words. It can all be a bit too much for a new user to handle. With some effort, the experience can be elegant and informative without over stimulating the user. Short tips and pop up notifications are a good way to guide new users through the appropriate steps. Be sure to show them one at a time. Tell them directly what they need to know and when they need to know it. Don’t make them remember too much as they will forget it. Instead, use reminders.Overall, on boarding new users should be a fun and creative experience to help develop your product. There are hundreds of tools out there to help you optimize your product. Experiment with different tools and features to your advantage.



Sources and Further Reading



iOS8 - What's got me excited? Notifications.

Push and local notifications came on leaps and bounds in iOS7, to the extent that they're no longer really annoying* and in fact, have been verging on being quite useful when used intelligently within the overall experience of a mobile app.

Notifications displayed on my lock screen are, by some stretch, the most frequently visible real time notifications that I receive in the course of my day. So, when Apple officially declared iOS8 and it's myriad of updates yesterday, it was the evolution of the notifications, part of the iOS UIKit library, that caught my attention.

At both NuWe and Nourish Care, we've been looking closely at the opportunities for using notifications to improve the overall user experience, simplify the ways that users interact with our apps starting even before they've gone through the rigmarole of actually unlocking the screen, finding the icon, opening the app and logging in before they get to do what it was they wanted to do in the first place.

Some technologies offer considerable promise, such as the iBeacon protocol for adding real world context to user actions.

But notifications were really missing some additional, albeit simple, but important features to make them really useful without the need for things like iBeacon. And yesterday, goddamit, I think they got it.

Apple talked about 2 primary enhancements to provide Interactive Notifications:

  • Inline Comments - for example, responding to a text message inline within the notification.
  • Inline Actions - for example, offering user some inline buttons which, when tapped, will open the app and provide some context with which to customise the experience.

Let's have a look at them a little more closely:

Image from Yahoo Tech

Image from Yahoo Tech

I can't currently see within the apple documentation where this specific type of interaction resides, and if indeed it is available outside of the message app for use with 3rd party apps - I really hope it is. I can think of a number of great use cases for taking the input and parsing the string to create a very streamlined user experience for manual tracking activities. Even better, the option to use the voice control as well.

I presume it must reside somewhere within the UIKit library, if you spot it, let me know :)


Image from Techcrunch

Image from Techcrunch

Actionable Notifications, found in the UIUserNotificationAction class reference give us additional options to setup buttons that the user can tap straight from the notification.

We can set an action, optionally require user authentication, and we can use different UI patterns based on whether the action is likely to be destructive (such as deleting some data) as a result of the interaction. The default is non-destructive, set it in the property.

@property(nonatomic, assign, getter=isDestructive) BOOL destructive

You can also configure whether the action will load the app to the foreground, or simply process the action in the background, using these constants:

typedef enum UIUserNotificationActivationMode : NSUInteger {
} UIUserNotificationActivationMode;

Oh my frickin' God, this is awesome!

*some developers still abuse them and make them annoying, I can think of a few examples...