In the top-left corner of every iOS device there is a space for service providers to proudly showcase their branding. Pop a sim into your iDevice and once connected, you’ll notice the name of your service provider appear between your reception bars and network type (•, 3G, LTE, wifi). Once you’ve gotten past the informative value of such branding, the novelty wears off rather quickly. It isn’t uncommon for a carrier to make a mess of their name (YES OPTUS, VodaAU), which can severely uglify your phone -forever-. A fair question to ask is: have you ever forgotten which service provider you’re subscribed to? No, neither have we.
- No jailbreak required
- CarrierEditor comes with a bunch of pre-made replacement logos, including BATMAN.
- It’s FREE (but you should send a big thanks tweet to @uhelios on twitter)
We liked this so much, that we had our Shifty Labs™ team draw up some Jelly-eyed logo replacements.
To get the Shifty Jelly carrier logo, DOWNLOAD IT FROM HERE.
In our previous post we talked about Nathan, the sole designer in our trio of iPhone monkeys. We figured that we may as well complete the picture, and release part two of this three part trilogy, this time looking at Philip Simpson.
Philip and I both work at Groundhog Software during the day, a company that develops custom applications and web sites for many different clients (be sure to check them out, they’re one of the few companies I’ve ever come across that really value quality and innovation rather than just talking about them). They are also highly supportive of our iPhone efforts, and trust us to maintain a separation between our work and personal developments, a trust I think we’ve always done the right thing by. That’s where I first came across Philip, when he started there as a Software Developer about 2 years ago. It quickly became obvious that Philip was smart, and highly motivated and also that he did a lot of development in his spare time (at the time mainly for charity). In his day job Philip mainly works with Java and large J2EE applications for our clients.
It came as no surprise then that when Ruby on Rails started gaining traction Philip fell in love with it. It was the anti-java in a lot of ways, fast, flexible, highly extendable and very light weight. While Java servers generally need at least 512MB of RAM to run, Rails runs quite happily on a tenth of that. Meaning that you could set up a ten server Rails cluster in the same space you could put one Java server. Rails is also a lot cheaper to host than Java. It was a fairly logical step then that it was the language of choice for the back end of Pocket Weather, and even more logical that Philip should be the man to do it.
The back end of Pocket Weather is what I call the ‘invisible’ side. Most of you probably don’t even know it’s there or what it does. Coded exclusively by Philip the back end polls the various FTP and HTTP sites from the BOM at various intervals during the day, and parses out all the data that Pocket Weather needs. This is no small feat, and is why we refer to Philip as our ‘Ruby Magician’ because all I see of it is a nice clean API that the iPhone App talks to. When you open Pocket Weather it contacts our server, and asks it for the weather for all the locations you have set up. This data is all sent back in one tiny chunk. This is good from a speed and data point of view on your iPhone, and also very good for the BOM, because it’s only our server talking to it, not tens of thousands of individual iPhones.
The running joke in the early days of Pocket Weather development between myself and Philip was always ‘Yes, but can it scale?’. You see Rails has an (undeserved) reputation for not being able to scale when it comes to handling large amounts of traffic. We were able to test that first hand when, in the early days of Pocket Weather, 800 new people a day were downloading our application. There were some nervous times when Philip had to keep a daily eye on things as our shared hosting groaned under the strain. Philip was always on the case though, and has been tweaking the code and architecture since day one. This has meant that Pocket Weather has experienced no downtime due to our code, though we have had some minor outages thanks to the double-edged sword that is shared hosting.
Philip is also a great friend and a very handy developer to have in our trio. I find that working solo it’s hard to get motivated and produce quality work, but when you have someone else you can draw immense motivation from each other, and you end up with a much better end product. Just like all of us, Philip is in the development for the fun, not the money, so much so that I often have to force him to accept payments and end up arguing with him because I think he needs a higher share of the profits, while he’s always pushing for a smaller one. I can think of many employers who would kill to have that problem🙂
So what is Philip currently working on at the moment? Well he’s bringing the extended forecasts we promised for version 1.4 (so you can stop emailing us residents of Cape Byron, Wollongong, etc), as well as moving all of our code to a private server, so that we will never have to suffer the indignity of the downtime and problems you get on a shared host. He’s also working on two other projects that are very close to being released, but that we are maintaining Apple(TM) levels of secrecy about.
I came across this thread on forums.mactalk.com.au (a great site by the way) today:
It got me thinking. There are people out there that love our design, and I don’t think we’ve actually ever talked about how it came about. In the early days of Pocket Weather (July of 2008) we were trying to design a weather application that we actually wanted to use. The problem that we kept running into is that we, to put it mildly, suck at design. I think it’s a very common thing for programmers to be really bad at design. There are many reasons for this, but the most plausible one is that the best programmers are analytical problem solvers that like to build, tweak and optimise things that have defined inputs and outputs. Creative people on the other hand…well you get the picture.
So I started canvassing all the people I knew who knew anything about design. They all had pretty much the same reaction “The iPhone comes with a weather app you idiot”. Luckily for me I had no lack of motivation, self determination and will to see it through (my wife would summarise that as ‘stubbornness’, but I digress). Then the designs started flowing in, but they were all universally bad. I may not know how to design, but I know what I like, and I liked none of them.
Enter Nathan Swan. I knew Nathan quite well, and had even helped him out with a small business that he runs, but had never seen any of his designs. I canvassed the idea to him, and he jumped at the concept, and got crazily excited. It was the first time in at least a month I had found someone as passionate as me about our little iPhone project. I think even Philip (our Ruby Magician) wasn’t sure why were building a weather app at the time. I had no idea what to expect, I sent him a rather crude brief of what I wanted, and he didn’t even have an iPhone.
Then on the 28th of August 2008, I received this in my inbox:
I almost fell off my chair. I showed Philip and he was just as excited. Nathan had blown me away! The design was clean, readable, simple and he had nailed the weather icons just right. To this day I haven’t seen any other application or weather service that has better weather icons than the ones he designed. It was only a few weeks later that Pocket Weather AU was finished and unleashed on the world. It went to the #1 spot in the iTunes store in only a few days, where it stayed for several weeks. Achievement wise, I count those as some of the best of my career and I’m sure that Nathan and Phil feel the same way.
I’m convinced that to a large extent we owe our success to Nathan. We could have got by without him, but it would have been half the application it is today. Some programmers make the mistake of thinking of design as an afterthought, something you tack on when you’re finished coding, but at Shifty Jelly we firmly believe that design comes first, before you touch a single line of code.
The other great thing about design is that it’s a hard thing to copy. Take for example our recent initiative to post weather updates on Twitter, only hours after we had done it our competitor here in Australia subscribed to a few of our feeds, and the very next day had his own competing service up and running. The barrier of entry was low, and ethical debates aside, it was an easy thing to emulate. Design on the other hand is a much more individual thing, and the barrier to entry is quite high.
So thanks a bunch Nathan! (@_nathanswan on Twitter)
For those of you not familiar with who does all the work at Shifty Jelly, there are three of us:
- Russell (iPhone application)
- Philip (Server set up, maintenance and development)
- Nathan (Graphical design)
While we normally try to keep these posts product specific, we thought we’d make an exception today to congratulate Philip, who is getting married this weekend! He’s marrying our Pocket Weather help video voice over girl, Amy.
In true Philip fashion he deployed another version of our Pocket Weather Server last night (at 2am no less), and so far it’s running smoother and faster than ever. Now he’s going to take a much needed break, so all the best Phil, and we love your work!
While he’s away I’ll be keeping an eye on the server, but truth be told, he’s done such a great job that there’s not much for me to do.
In Pocket Weather news we released 1.3.4 to Apple Tuesday night, and it has a few minor tweaks that should make life easier:
- Home button on the tide screen, to take you back to the weather screen without having to go through the tidal locations and states.
- New option to pre-load radar data in the background (turned off by default). For those of you that choose to turn this on, it will mean that by the time your done looking at the weather and click on the radar icon, the radar will pop-up instantly, instead of having to wait for it to load. As always be mindful of your data caps if your on an iPhone,
- Minor tweaks to memory use and radar screen.
As Apple continue to fumble the ball on releasing version 1.2 of our application to the masses (if you’re reading this Steve, how about helping a brother out, aye?), my mood was lifted slightly the other day, when upon walking outside I spied this in the night sky (taken on our crummy panasonic digital camera):
So even if Apple is not smiling down upon us, at least the universe is (or the moon, jupiter and venus to be precise).