We build amazing iPhone and iPad apps. We recently build ABC Play School Play Time and Art Maker for iPad, and recently wrote Learning Cocoa with Objective-C Fourth Edition and the iOS Game Development Cookbook for O'Reilly. This is our blog.

Reasons Why Hearthstone is Good, From A Game Design Perspective


Lately, we've been playing a lot of Hearthstone. Hearthstone's a digital collectible card game from Blizzard, in which you assemble decks of cards and battle other players. It's a game that clearly draws a lot of inspiration from games like Magic: The Gathering, but it's significantly simpler.

We've been playing Hearthstone since it soft-launched in Australia a couple of weeks ago. Today, it launched worldwide on iPad, and people who weren't already raving about it are starting to take notice. While playing the game, we've ourselves really getting into it, which surprised us - Hearthstone is a free-to-play game from a triple-A studio, and we usually get really into games like Dear Esther, Gone Home, and Kerbal Space Program. The level of enjoyment we've been getting out of this game was a little startling, and we had to spend a bit of time working out why we liked it so much.

Here's what we worked out.

1. The experience starts right away.

When you start the game, you immediately enter a game and begin learning to play. You're given a deck, you're given specific instructions on what to do next, and you play through five games that progressively teach more advanced mechanics.

At the end of the tutorial, you're then asked to sign up for an account. This is absolutely genius - all of the non-fun (or, to be more accurate, non-core-gameplay) components of the game, such as signing up for an account, managing your deck, and even being asked for money, are deferred for as long as possible.

2. The monetisation model is subtle.

Hearthstone is a free-to-play game. The developers make their money from in-app purchases, and the more purchases you make, the happier the developers will be. While many games put pay-gates on progression, Hearthstone's pay-gates are on flexibility. When you play games, you unlock cards; if you pay money, you unlock more cards.

Collectible items as a free-to-play strategy are an increasingly popular area, and we're going to see a lot more of these. They're a model of monetisation that actually respects the player's time, and doesn't club them over the head with a publisher's demands for return on investment. When you buy cards in Hearthstone, you're not paying a toll for playing, you're permanently enhancing your experience of the game. This enhancement happens in very small increments, but it's enough.

As an aside: we're increasingly convinced that 'consumable' in-app purchases are the worst possible thing to base your game's design around. There's been a huge amount already written about the drawbacks of this approach to making money from games, and we've always suspected that those who are defending the approach (and who aren't taking a 'I freakin' love taking baths in dollar bills' attitude) are doing so from the perspective that, well, you don't have to pay, but it makes the game a little nicer if you want to. The problem with this approach is that 'making the game nicer' often translates to 'making the game less abusive'. Making a game that starts out great and gets better with in-app purchases, instead of less bad, is a very desirable goal indeed, and we think Hearthstone (and games that use a similar accumulative-item model) have cracked it.

In addition to paid rewards, almost every game provides some measure of reward for the player. When playing in Practice mode, the player levels-up their characters and unlocks new cards. When playing in Play mode, the player earns progress towards achievements, which give the player items that would ordinarily require paying real-world money. If their game is Ranked, they don't earn items, but they have a chance to increase their rank.

This reward loop serves to keep players in the game for longer, which increases the potential for them to drop money on the game without ceaselessly hammering at them to cough up cash. This also has the benefit of keeping the player population high.

3. The game's design is fast.

Hearthstone games last 20 minutes or less. There is no interaction between players during a turn: players may not interrupt another's turn, and combat has no interaction either. When it's your turn, you have uninterrupted control over what happens until you hit the end turn button.

Turns have a time limit, which is useful; interestingly, the game punishes players who take too long, in that if their turn timer expires, they receive less time to do their next turn. (If they complete that next turn without the timer running out, their amount of time per turn is restored to normal.)

4. The game is welcoming.

Hearthstone intro movie

The intro movie begins as a traditional Blizzard cinematic: giant, intimidating heroes doing battle and magic, while saying cheesy lines about glory, victory and honour - until the switch at the end, where it's revealed that everyone's just sitting in an inn, playing a board game, having fun.

The game feels incredibly happy and supportive, while at the same time sacrificing none of the feeling of risk and excitement that Warcraft's universe traditionally evokes. Even the voice that the player hears when the game starts up is welcoming: "Ahh, it's good t' see ya again!"

This is reinforced by the fact that games don't take very long: the player feels able to drop by the game, play a short round, and at the end of the game, they've received some kind of reward.

We're going to keep playing Hearthstone for a while longer, and see what else we like about it. If nothing else, it's given the mobile game space a lot to think about!

Winners at the 20th AIMIA Awards

As we posted about a few months ago, we were really excited to learn that an app we build was nominated for two AIMIA Awards. We're now thrilled to report that the app, Play School Play Time for iPad, built for the ABC, was the winner of the 20th AIMIA Award "Best of Tablet – Entertainment" category, as well as the overall "Best of Tablet"! You can watch the winners videos on the AIMIA website.

We couldn't be more thrilled! We're incredibly proud of the Play School apps, and enjoyed working with the ABC team. The ABC team included: David Glen, James Welbourn (pictured), Priscilla Davies, Tali Gal-on, Peter Marks, Jake MacMullin, Sam Gain-Emery (Sonar Sound), Luke Mynott (Sonar Sound), and Kate Highfield (Education Advisor). Thank you all!

If you haven't already checked out Play School Play Time for iPad, check it out and let us know what you think!

SnapTas: winner of the Go South Awards 2014

Screen Shot 2014-03-31 at 12.02.14 pm.png

SnapTas is a fun little app that we made earlier this month as part of the Go South Awards  competition, which is an app development competition down here that's run by the Tasmanian Government. We're pleased to announce that SnapTas won the business category of the competition! Congratulations also to Bappy Golder, who won the individual category in the competition!

If you were a VC we were pitching to, here's how we'd describe it: "Instagram, but for Tasmania, with retro travel post cards."

We made SnapTas because it's harder than it should be to find great examples of people sharing photos and content that shows off what makes Tasmania such a great place to live. Tasmania is world famous for its scenic environment and its high quality of life, and has hundreds of thousands of interstate and international visitors every year. Right now, though, the best way to find pictures that people have shared is to try searching for hashtags on Facebook, Twitter and Instagram.

Every visitor has a different perspective on our beautiful island, and they enjoy sharing them with the world. SnapTas makes it easy to share and discover photos of Tasmania by creating a dedicated social network for both tourists and locals: when you're in Tasmania, take a photo or pick one from your camera roll, and SnapTas makes it look like a delightfully retro 1950's postcard. It's then shared with your Facebook friends, and you can also choose to make your photo available to everyone via the web.

For tourists, SnapTas is a way to share your trip to Tasmania. For locals, it’s a way to share your unique perspective on your home. SnapTas serves as a showcase of the best of Tasmania, and a single point to show potential visitors, or those want to move to our lovely island.

SnapTas also helps you share photos to Twitter and Facebook. The more people seeing Tasmania, the more people coming to visit and sharing their experience on SnapTas!

We used Parse for the backend of SnapTas, which handles user sign-up, data storage, push notifications, and all of the sharing, commenting and liking features. All of the images get rendered on the iPhone before being uploaded. 

SnapTas will be available to the public soon.

Storyboards and NIBs: A Rebuttal

Beneath the relatively placid surface, a battle is raging among iOS developers.

On one side, we have developers who use the built-in visual interface development tools for constructing their screens. On the other, we have the code purists, who insist on entirely generating their interfaces from code.

Storyboards have a number of important advantages:

  • Seeing your design means thinking visually
  • Storyboards let you see how apps flow together
  • Storyboards are the only way to use segues, which are a marvellous way to handle the transitions from screen to screen.
Screen Shot 2014-02-10 at 1.40.28 pm.png

Apple vigorously promotes the Interface Builder and the use of Storyboards, but there's a surprisingly large number of developers who insist on not using them. One famous example is Google, who, as of 2012, apparently forbade the use of storyboards and XIB files, as well as checking in .pbxproj files (that is, the actual project files used by Xcode to organise where files go.) The reasoning provided is that merging these files is too much of a challenge.

Google aren't the only ones insisting that storyboards aren't a good idea. There are dozens of examples of developers promoting this viewpoint, and here are the most common arguments we see.

"Programmers should code, and not do visual design. You should know how views work from the ground-up, and being able to code your interface is more extensible."

A good programmer knows more than just than their specialty. The argument that programmers should only focus on the written component of their apps implies a separation of skills that simply isn't workable in mobile apps: if you're making an application that relies on the user holding a screen in their hand, deliberately not thinking visually means that you'll be more likely to not catch small visual problems in your app's design.

There's a lot to be said for understanding views and view controllers from the ground up, for the same reasons as understanding any other topic in programming: knowing as much as possible about what's going on behind the scenes makes it easier for developers to make more advanced use of the technology. However, this isn't an argument for avoiding the Interface Builder - understanding how views work doesn't require that you manually create them in your code.

"Creating re-usable views is harder. Also, custom views are hard to see in IB, they're just white boxes."

Another common argument against using storyboards is that using custom views is harder. For example, if you've got a view controller that needs to use a custom selector view of some kind, embedding a view that you've designed in a XIB can be a pain.


  • Using the Interface Builder doesn't mean that you have to use the Interface Builder for everything. You're still free to embed a custom view, set its class, and then provide a loadView method for that class to manually create the view hierarchy for that class.
  • Embedding view controllers using container objects is straightforward. If you need to embed a collection of views elsewhere, or if you want to break out the logic of a screen into multiple sub-units, use the Container View object to break out a collection of views into a separate view controller.

A related argument that we see is that custom views just look like empty white boxes in your view controller's designs. Technically, that's true - if you drag in a generic UIView, and set the view's class to your own, it'll still appear as a generic white box. However, this argument against storyboards ignores some important facts:

  • Unless you care about the contents of your custom view, seeing a preview of your view isn't a requirement for constructing the rest of the screen. Positioning and sizing the view on the screen is the most useful feature, and that's what you get.
  • A number of important, Apple-provided views also appear as empty boxes. The point isn't that you get to see the content, but rather that positioning and arranging the view in the screen is significantly more straightforward.

"Auto-Layout sucks, and doing the layout yourself is easier to understand."

Auto-Layout has received a significant amount of criticism since it was introduced, and many developers argue that the older method of struts and springs (as well as defining frame rectangles for each view) is easier to understand.

This was a fair criticism - in Xcode 4, constraints were a huge mess, and it was very difficult to understand how re-repositioning a view in the Interface Builder would affect the constraints.

However, Xcode 5 and iOS 7 has simplified this considerably. You no longer receive a soup of vertical and horizontal blue lines, and controlling the position and size of views using constraints that you design in the Interface Builder is simple and straightforward.

"Using storyboards means designing your interfaces in Xcode, which is slow and crashy."

Xcode doesn't have a great reputation for stability, it's true. However, the time lost to re-launching Xcode after a crash is miniscule compared to the amount of additional time you'll take designing, testing and debugging your layout code.

(Xcode's still the worst IDE ever built, but that makes it no different to every other IDE.)

"Dealing with lingering outlets leads to crashes."

It's a common situation: you link a view to a class using an outlet; later, you decide you don't need the outlet, so you delete it from your code. You run the app, but the view still wants to connect to the now-deleted outlet. Your code crashes. You scream with rage.

This is a reasonable criticism - Xcode should at least provide a more visible warning that the property is missing. However, it's nowhere near enough of a reason to forswear ever using it.

"Merging sucks."

This is the only valid major criticism, and is the major one that causes organisations to ban the use of storyboards and XIBs in their codebases.

However, starting with Xcode 5, the Interface Builder is getting better and better at detecting merge conflicts. When a merge results in structurally valid XML but an invalid storyboard, Xcode will attempt to repair what it can: for example, if merging two versions results in an object connecting to an outlet that was removed, Xcode will notice it, and correct it.

Part of the problem, from a human perspective, is that dealing with merging two versions of a storyboard means working with XML, which is text; normally, working with storyboards is a visual task, but when there's a problem, you have to jump down to text and interpret what the XML actually means.

The XML used by storyboards, however, is actually pretty straightforward. Each view controller is an element that contains its subviews and other components (such as gesture recognizers or segues), and references to other objects are done with short alphanumeric strings. If there's a conflict, it's generally because two developers both inserted views into the same view controller - in which case, it's about as straight to recognize and fix as it is to fix a merge conflict in code.

Parting notes

Storyboards and XIBs are one of the most powerful and flexible tools that you get as part of the iOS developer tools, and shunning them means you lose both flexibility and features. If you're avoiding storyboards for personal reasons, we strongly recommend that you give them a try. If you're avoiding storyboards in your team because of the risk of merge conflicts, get some practice in fixing merge conflicts - they're easier than you think.

If you have any comments, email us!

Go South Awards

Yesterday the Go South Awards were announced in Hobart. The Go South Awards is a competition to design and develop an amazing new app, of any kind, for Tasmania.

The competition has some really solid prize money, and looks like an excellent opportunity for app developers and students hoping to make their mark! Check out the Go South Awards website (built by our friends at Ionata and onetonne) for more information.

We're really thrilled to see an event like this pop up in Tasmania, and commend our friends in the Tasmanian Government, TasICT, and the ACS for collaborating on it. 

iOS Developer Training in Hobart


We're really excited to announce an intensive 2-day iOS developer workshop in our hometown, Hobart. The workshop is organised in conjunction with ACS Tasmania.

You can learn all about it on our training page, or over at the ACS website. There is a discount for ACS members.

The workshop is designed for existing programmers (of any sort) who want to learn iOS development, or iOS programmers who want to get up to speed with the latest techniques for building iPhone and iPad apps. It teaches the very latest public iOS developer tools and features.

Brisbane and Melbourne iOS developer training is also currently open for registration.

Secret Lab are finalists in the 20th AIMIA Awards

Secret Lab built the Play School Play Time app for the Australian Broadcasting Corporation.

Secret Lab built the Play School Play Time app for the Australian Broadcasting Corporation.

We're really excited that Play School Play Time for iPad, an app we built for the Australian Broadcasting Corporation, is a finalist in two categories of the 20th AIMIA Awards!

Play School Play Time is a finalist in "Best of Tablet – Entertainment" and "Best of Tablet – Learning and Education". 

If you haven't checked out the app, if you're in Australia you can grab it from the App Store here, for free, or here, if you're elsewhere!

We're thrilled that Secret Lab is in such good company again this year! Previously, in the 19th AIMIA Awards, Play School Art Maker for iPad, also built by Secret Lab for the ABC was a finalists in "Effectiveness", "Best Application for a Tablet", and "Best Children's", and in the 18th AIMIA Awards, Foodi for iPad was a finalist in "Best Cultural or Lifestyle", and Play School Art Maker for iPad was a finalist in "Best Application on a Tablet or Mobile".

Recently, we were also thrilled to win a Tasmanian ICT Industry Award for 2013, for our work on innovative apps for kids! 

Animation Basics: Part 2


This is the second in a series of posts about animation by Rex Smeal, animator, and friend to cephalopod and amphibia alike.

Welcome back! If you haven’t read the first part of our animation basics trilogy, you should check it out! This second article is about Timing!


So, if Spacing determines how quickly or slowly something moves, what is there left to call timing? A lot of the time (ha ha), timing is the functional time requirement of your subject. For example, when animating a boxer throwing a punch, you must make the timing quick enough to accurately convey the speed of the punch: too fast and we miss it, too slow and he looks silly. Another example would be interfaces, which need to move quickly into place in order to be practical.

This is something most people know how to do instinctively, or can easily adjust for when a mistake is obviously too slow or too fast. Where timing gets interesting is the way choices in timing can affect multiple elements moving together.

As mentioned in the Spacing article, where Spacing is the placement of instances through time, Timing is the distribution of time across defined instance points, or keyframes.


Real World Imitation

All good animators spend a great deal of time looking at real-world reference footage. Animal motion, the motion of objects under gravity: stones, balls, feathers, objects halted by a rope. Using natural timing at least as a starting point will cause objects to appear much more real. The closer the timing of an imaginary object mirrors a counterpart in reality, the more readily a viewer will accept it, irrelevant of how ridiculous the subject itself is. For example, an animated desk lamp that moves with the timing of a real, living creature can be more easily believed by an audience than a hyper-realistic figure which moves sluggishly or haltingly.

Where spacing demonstrates path of motion and slows and starts at a micro level, the wider choices about where objects move at what times is determined at a macro Timing level. These two concepts do blur quite a lot at their borders; I think of timing as requirements and spacing as the flair of a motion.

Timing Contrast

If one were listening to a drum which kept steady 4:4 time it would become very boring very fast. But with a second instrument playing a melody, or a second drum playing a different beat, interesting new combinations arise and we’re enjoying contrasts in timing. In terms of animation, this means that monotonous or homogenous motion across multiple objects is going to look bland, and a dynamic and heterogeneous cascade of objects moving at different speeds and in different styles, whilst requiring a little more effort on the part of the animator, will look much more interesting!

This isn’t always desirable, as often an audience is required to concentrate on something that isn’t moving, and in those situations a panoply of motion cues isn’t going to be advantageous.

Secondary Animation

Imagine a car driving around a corner (and our spacing is evenly distributed around the corner as we’re recklessly not slowing down), I guess you could say that this would be our Primary animation (an object appearing to move on it’s own initiative/by it’s own power). If the car has a trailer though we might call the motion of the trailer Secondary animation (an object’s motion that is separate from, but mostly determined by a primary object).

The other forces acting on the trailer might be gravity, it’s own momentum, the elasticity of the tether to the car, and if it were a lighter object, such as a flag, wind might be another factor. A flag on a stick, long hair on someone’s head, the tail of a kite, an injured arm hanging loosely from someone’s shoulder, even your clothes on your body are all examples of a secondary action linked to, caused by, but not identical to, a strong primary motion force.

This linked or tethered motion often provides a nice timing contrast, and good use of secondary animation both accentuates and deepens a motion and makes it much more interesting and attractive to a viewer. In fact, the emergent action of an object under forces is often more interesting than the primary motion. In touchscreen interface motion, the primary motion could be considered to be the gestures of the user and the interfaces move as secondary action.


Some people like to call this overlap, and the definitions get very messy when you’re talking about it in terms of secondary animation or two parts of one object, but what it really means is two parts of the same object moving in a similar (or even identical) way at different times. This helps to separate the objects, and adds a lot of interest to the motion. Inversely, regular timing can unite otherwise separate objects.

These two groups are composed of identical frame instances, just presented out of synch by one and two frames for the staggering effect.



Cycles are a really interesting technique, particularly as an economy measure. An animation cycle is where a sequence or motion may be looped and reused more than once. The difference between a ‘Cycle’ and a ‘Loop’ is that a cycle may only apply to one component, whereas a loop generally applies to everything that is displayed.

One of the most well-known uses for this technique is the “run cycle” where a character’s two steps loop seamlessly to create the illusion of an ongoing running action, when in reality the animator has obviously only been required to animate two steps.

The main difficulty in making viable cycles is preventing your audience from really seeing too much of the “seam” where the cycle repeats. In many cases there won’t be a seam: a spinning object, for example, could be said to loop from any point in it’s rotation. But more complex motions, like a character jumping, or running, often lend themselves to a logical starting point.

Keeping away from dead stops and overly regular spacing will help, obviously repeating frames will sit as a kind of afterimage in the viewer’s mind as the animation cycles. Where cycle economy becomes really powerful (infinite, really) is when there are several cycles working together, all with different lengths. Take this simple example.

Okay now brace yourself for some maths: Two cycles (with different timing) are playing in the next example, and the total length of the animation is double the longest of the two cycles. Despite doubling the on-screen time of the animation, technically we’ve only really stolen twelve frames for free here (24+36=60). But this is with two relatively compatible cycles.

If I had added another really short cycle with an uneven number of just five frames, the animation as a whole would not have truly looped until unique frame number 360, stealing us 295 frames for free and making the largest and most terrible gif ever to be displayed on the Internet.

This is great for long animations of spinning logos, but also useful for things like water ripples, cloud motion, shifting colours across an object. Extending cycle lifetime is the strongest way to avoid obvious repetition, and joining cycles like this is the cheapest way to extend overall cycle lifetime.

With the use of procedural animation, we can control these cycles just as we control loops in code: randomised frame segment orders, dynamic particle generators, and so on. Using these techniques, we can extend these cycle times dramatically, or infinitely, for no extra ‘drawings’ and close to zero extra effort. Eased rests, cycles and code-assisted animation are where an intelligent animator will be able to save the most time/money.

We hope you’ve enjoyed part two! Chat to us on Twitter and Facebook, or email us or if you have any questions!

Join us next time for the final episode in this animation basics series: Spatial Distortion!

Our business and the NBN

Secret Lab

Recently the Secret Lab was connected to the National Broadband Network (NBN). For our overseas readers, or those not following along in Australia, the NBN is an Australia-wide project to upgrade our telecommunications infrastructure. The NBN originally planned to offer fibre-to-the-premises (FTTP) to the majority of Australians, and fixed wireless and satellite connections to rural areas; when the federal government changed in September, as part of the new government policy a review into the possibility of changing from FTTP to fibre-to-the-node (FTTN) and other technologies commenced. That review is still ongoing. Either way, our office is now connected to FTTP, at the speeds of 100 Mbit/s down, and 40 Mbit/s up – a big step up from our previous ADSL2 connection, which maxed out at 23 Mbit/s down, and 0.9 Mbit/s up (we had basically the best ADSL2 connection you could get in Australia). FTTP NBN is one of the most transformative, impactful things that could have happened to us. Here's why.

We're, primarily, a game development studio, and we also teach iOS development. We build games for iPads, iPhones, Androids, Macs, and PCs. Games require lots, and lots, and lots of large asset files, sound files, music files, and the like. Most of the games we build are for clients. We also write training material, and create large instructional videos. This means, on a daily basis, we have to upload and download a lot of data around just to get anything done – often we need to upload between 3 GB and 30 GB in a day; this was impossible with ADSL2.

What did we do? We sent hard drives, or USB flash drives, through the postal service, or we left uploads running overnight in the faint hope that they'd successfully complete while we slept; worse still, and most deleterious to a small business – we resorted to expensive Telstra 4G LTE, which can upload between 5 Mbit/s and 10 Mbit/s at a cost of ~$50 AUD per 4 GB or so, so our upload went up relatively quickly but cost a fortune in doing so.

This was not sustainable. We can't run a game development studio for very long like that, as it's simply too stressful/expensive/time consuming/unproductive. Until the NBN came along, our only other options for a useful connection – primarily for uploading – were expensive HFC cables (if it was even available where our office is, which is debatable), expensive high-latency satellite options, or expensive and complicated bonded solutions (routing multiple connections together into a single connection). If we wanted to remain competitive, keep our working capital healthy, and keep our internal IT maintenance administrative requirements low (our IT requirements consist of one of us rebooting the router as needed!), then none of these options were suitable.

The NBN, via FTTP, gives us a speedy 100 Mbit/s down, and an absolutely vital 40 Mbit/s up, and it gives it to us at a price equivalent to what we'd pay for a copper-based and all-but-useless for uploading ADSL2 connection. We can upload amounts of data that would have previously taken overnight, if we could do it at all, or required us to spend ridiculous amounts of money using 4G LTE technology, instead of resorting to the postal service and hard disk drive. We can move faster than we could before, since when one of us is using Skype to talk to a client we don't have to pause all our downloads and uploads, and stop checking code into source control since – thanks to having a 100/40 connection at our disposal – Skype no longer breaks down if something else is happening on the network. We don't have to raise our prices, since our broadband connection is both usable and cost friendly to a small business, and we no longer have to pay for extras such as hard drives to post, or Telstra 4G. Best of all, we no longer have to even consider leaving Tasmania – a beautiful place to live and work – solely because we couldn't get the connectivity we would have needed to make our business more effective, sustainable, and better equipped to make new games and software.

Realistically, we don't care what technology the remaining NBN rollout is delivered by, but we don't believe that the plan currently suggested by the coalition government can deliver an NBN that will truly serve Australia, and offer the same opportunities and capabilities to Australia, the way that FTTP has changed our business in the few short weeks we've been connected. Disturbingly, the majority of the published material from the current government regarding their NBN plans does not mention upload speed at all – upload is the most transformative aspect of FTTP for us.

We don't object to communication minister Malcolm Turnbull's strategic review of NBNco, or the new government's efforts to ensure NBNco and the activities around the rollout are more transparent to the public (such as making the maps available representative of the actual state of the build) – these are all good ideas. We are concerned, however,  through sheer bloody mindedness, and to perhaps save a few dollars in the short term, or complete the rollout faster than the previous government suggested it would be done, that the current government might end up rolling out the remainder of a network with a technology that will not serve as a truly useful, future-proof, and transformative to business (and homes as well) series of tubes.

We're especially concerned that FTTN, the apparent frontrunner technology candidate for the coalition's revised rollout, is considered a stop-gap technology, is prone to be interrupted through weather, and that countries that have previously deployed FTTN (such as Germany, New Zealand, and the United Kingdom) are replacing/upgrading their networks to FTTP. If we rolled out FTTN in Australia, we'd already be behind many other countries with similar requirements and socio-economic status to us.

Feel free to email us with your thoughts, or questions.

Update on 20 November 2013: We're especially concerned given Ziggy Switkowski, the new Exectutive Chairman of NBNco, doesn't have the foresight to see why 100 MBit and faster broadband speeds could be useful to households.

Tasmanian ICT Industry Awards 2013

We're absolutely thrilled to have won a TASICT award last night at the Tasmanian ICT Industry Awards for 2013. We won the "Best Software Product" award for our work on innovative apps for kids. Thanks to TASICT, TasmaNet for sponsoring the particular award that we won, and Michael Ferguson for presenting the award to us. Congratulations to all the other amazing nominees and winners: Elan Projects, Jobric, CGI, ISW, Vodafone, Anittel, Kingborough Council, UXC Eclipse, Ionata Web Solutions, Synateq, Acrodata, Aurora Energy, and RBF. Thanks also to the event sponsors: Autech, Fuji Xerox, Insight4, Aurora Energy, HP, Hays, Anittel, and the Tasmanian Government.

Don't forget to check out Malcolm Turnbull's recorded message, regarding the NBN, on YouTube (thanks, Josh Deprez!)

Play School Play Time for iPad

ABC Play School Play Time, developed for the ABC by Secret Lab

Developed by Secret Lab for the ABC, Play School Play Time for iPad has hit the App Store this week! Let us know what you think!

This app contains some of the most interesting and complex use of Core Animation that we've ever done, and we're proud of how it's turned out. You can grab it from the App Store here, if you're in Australia, or here, if you're elsewhere!

If you haven't seen the previous app that we built for ABC Play School, also check out Play School Art Maker (Australia/other).

Update! As of 25 September 2013, the Play School Play Time app hit Number 1 in the App Store!

National Science Week 2013

National Science Week 2013 app by Secret Lab
National Science Week 2013 app by Secret Lab

We're incredibly pleased to be involved with National Science Week in Australia again this year. After building an app for the Tasmanian events last year, we were asked to create an app for the whole of Australia this year.

National Science Week 2013 app by Secret Lab
National Science Week 2013 app by Secret Lab

The app is now available on the iTunes App Store. Check it out, let us know what you think, and don't forget to take a look through the fantastic events that are being run as part of National Science Week 2013!

If you're running an event and need an app, we'd love to help.

Mobile UX Design and Development

OSCON 2013

We also ran our Android UX and development tutorial ("Level Up Your Apps: Mobile UX Design and Development") for the third year at OSCON! We had a great time presenting alongside our friend Chris Neugebauer (who devised much of the content).

Finished OSCON 2013 app from Secret Lab tutorial

Some links/information for those of you who are interested:

  • Final APK (suitable for installing) of the OSCON 2013 app we built
  • GitHub repository for the code from the tutorial
  • The tags, corresponding in order to the start and finished states for the application: talk_listing_start, talk_listing_end, schedule_start, schedule_end, day_list_start, day_list_end, navigation_start, navigation_end, data_end, tabs_end, theme_start, theme_end, navigation_refresh, talk_listing_update, themeing_finished
  • You can switch between these tags by using git reset --hard followed by git checkout and the name of the tag you want. Note that you will lose changes.

Slides are available on Speaker Deck:

Slides for OSCON 2013 Tutorial
Slides for OSCON 2013 Tutorial

If you have any questions or comments, please get in touch!

How Do I Game Design?

OSCON 2013

We ran our game design workshop at OSCON 2013 this year! Thanks to all who came - we hope you had an excellent time! Here are links to the books and papers we talked about at the end of the presentation:

If you have any questions or comments, please get in touch