http://www.gifterapp.com/index.htmlNews From The Gifter Teamensupport@gifterapp.comCopyright 2008 Gerbarg/Litwack2008-07-23T16:50:59-07:00 hourly 1 2000-01-01T12:00+00:00 Wed, 23 Jul 2008 17:19:18 -0700support@gifterapp.comBlog2008-07-23T16:50:59-07:00http://www.gifterapp.com/blog/files/the-napkin-sketches.html#unique-entry-id-4http://www.gifterapp.com/blog/files/the-napkin-sketches.html#unique-entry-id-4Posted by Geoff

For this post I thought it might be fun to show the first sketches I made for Gifter’s interface. They’re incredibly crude, but that’s the point - I wanted to get the basic idea down and wing it to Louis as fast as possible. Needless to say, it’s Louis who actually, you know, implemented everything.

First sketch. What’s with the rounded bottom? Looks like an OpenMoko. (Gifter: probably not coming to OpenMoko.) So this


became this, the address book sorted by birthday:


This is the first cut of our category screen.


Here’s what it looks like as of 1.0:


Icons. I just gave our artist descriptions of what we wanted instead of inflicting this hideousness on her.


If you’re interested in interface design, why not check out Designing Interactions by IDEO’s Bill Moggridge? It’s backwards-looking, but there’s a lot to be gleaned from the past and I thought the interviews on the DVD were fascinating.]]>support@gifterapp.comBlog2008-07-16T12:28:21-07:00http://www.gifterapp.com/blog/files/make-go-fast-now.html#unique-entry-id-3http://www.gifterapp.com/blog/files/make-go-fast-now.html#unique-entry-id-3Posted by Louis

Launching Gifter was really hectic for us. We had a lot of last minute issues with our providers, and some of our data pushes were not happening properly when the app launched. Because of that I spent most of the first weekend it was out in emergency mode. Now I am back to work on 1.1. It has a few bug fixes, quite a bit of performance work, a bit more UI polish, and one or two features we dropped from 1.0 at the last minute in order to make the App Store launch day submission deadline. I am really excited about our next release, but more on that another time.

I figured I would actually make a post about writing a good iPhone app. Now the dev tools are still NDA, so I am not going to talk about anything intrinsic to the iPhone yet, but there are a number of topics that are important to the iPhone while not being specific to it.

One of the most important things is for apps to be responsive. They need to scroll fast, they need to get data in front of the user quickly. The more often they stall, the more often the user notices the app getting in their way. That is especially true with the iPhone, where the user is not multitasking, they tend to be using the app in a quick focused way. I think Gifter does well at these things, and we are going to do better in the future.

Let's look at a typical task. In Gifter, when you select a category it queries a server for an XML data file, parses the file, then displays a list of items. That is a pretty common model for iPhone apps. Now consider what happens when you do that. For this example lets assume we are using a 2G iPhone somewhere that gets around 40k/s (some places get better, some get worse). One of our typical data files is around 60K. Now according to my math 60K -> 480k -> 12 seconds. It takes 12 seconds to download a category, plus an additional 2-3 seconds to start up the download between host lookup, network latency, et cetera. That is a lot of time for a user to be staring at a blank screen. And in early betas that is what Gifter did, but we put some work into things, and we think we made it a lot better. Nothing we did was iPhone specific, all of this is equally valid on Mac OS X. In fact the controller and model for Gifter compile and build for Mac OS X (we use the code in some of category management tools). Here is what we did:

1) Trim out all extraneous data
Our data files included a lot of stuff we did not strictly need, or could recalculate on the phone. Part of the reason for that is that Gifter is capable of pulling data directly from vendors in some cases,
and we do not control what they send us. While having that ability is a big win in some cases, we found that by fetching the data on our server we were able to cache, filter, and in some cases compress the data. For instance, we rewrite a lot of URLs to be shorter by using mod_rewrite on our server. (This also allows us to work around some bugs in the iPhone.)

2) Use SAX based parsers
I am a huge fan of using DOM and XPath. It really is much easier to maintain, and it allows me to write code faster. But for DOM to work you need to have the whole document loaded. That means waiting for the download to finish before you start displaying anything. The larger your data is, the worse of a problem this, but it can be pretty bad even for small amounts of data when you are on EDGE. So I grudgingly used SAX* because it is a better experience for the user.

* To be precise, I wrote a tool that builds SAX parsers from XPath triggers. That way I am using SAX parsers, but I do not need to actually write or maintain them.

3) Have your SAX parser incrementally feed your display code
So now you have written your SAX based parser. That does not buy you much  if you hold on to the data until it is done loading before you display it. Make sure to set up your code so that the SAX parser can hand your apps controller one object at a time, which it can insert into the model and view as appropriate.

Okay, so we did all of that, and the app should load faster, and when we test it we see that it does load a little faster. But all of the speed up we have seen is from step 1. It turns out the NSXMLParser requires that it has the whole document loaded before it starts sending events, which basically negates the value of steps 2 and 3. But we can fix that with:

4) Replace NSXMLParser
What I did was roll a mostly call compatible replacement for NSXMLParser, LGXMLParser. The big difference is that you can hand LGXMLParser data as you get it and it will pump the events. I am
opensourcing LGXMLParser today under an MIT style license, you can download it here. Just drop two files into your project, and wherever you use NSXMLParser, then modify your NSURLConnection code to feed it data as it receives. No need to change any of your SAX code. For now this is just a sort of throw over the wall release, but feel free to send comments and feedback. If you use it in your app I would love to know, and if you make improvements to it please consider sending me patches.

Conclusion
It used to take us 14-15 seconds to load the data. Step 1 reduced our average file sizes by ~33%, so that got it down to 10-11. Step 2 made it so that we can start displaying data as soon as we have received enough to display anything, which means that while our total download time is still 10-11 seconds, we have the first few items loaded in 2-3 seconds. Once the user has loaded the first screen of stuff we have effectively hidden the other 8 seconds of load time. So while it still
takes ~10 seconds, it feels like ~3. That is a pretty big improvement from the 15 second pause we started with.

Now I just described a lot of things, which are a lot of work. Even moreso for all of the developers new to the iPhone/Mac OS X development. While some of it is clearly code that is intrinsic to
Gifter, some bits of it is fairly generic. Because I want the apps that I use (not just the ones I write) to responsive, I am open-sourcing LGXMLParser. It is not a complete replacement for
NSXMLParser, I have added functionality to it as I have needed it, so if I did not need it, it is not implemented. I imagine I will add more as I go, but patches are always welcome. As I write these stories I may identify other bits of code to release, and build a library around them, but for now I am just releasing the two files. If you want to use them just drop them into your app!]]>support@gifterapp.comBlog2008-07-12T12:54:34-07:00http://www.gifterapp.com/blog/files/bedd9a6a1425818f49ef0645cc71044c-1.html#unique-entry-id-1http://www.gifterapp.com/blog/files/bedd9a6a1425818f49ef0645cc71044c-1.html#unique-entry-id-1Posted by Geoff

So last year I read Guy Kawasaki’s The Art of the Start, inspiring, then I started reading his blog, and then he published “By the Numbers: How I built a Web 2.0, User-Generated Content, Citizen Journalism, Long-Tail, Social Media Site for $12,107.09” and I was like whoa, that is useful information.

But it turns out that if you do your own development work, you can launch an iPhone app for even less. Here’s what we spent:

Development costs

• $99/year - The Apple iPhone Developer Program fee. I believe this is referred to as a “bozo filter.”
• $297.98 - Emergency RAM. For a while we had to parse a 12gb XML file. Every day. Louis got 8 more gigs for his Mac Pro overnighted out.
• $3000 (approximate) - Apple World Wide Developer Conference and travel: This is a biggie. It included airfare for Louis from the east coast to San Francisco and then from SF to LA, where I live - we took the opportunity to hang out for a week and work on the app hardcore.

Design assets

• $130 - The app icon: we knew we’d need a 57x57 pixel icon for the iPhone, but we also wanted a vector version as a general art asset. We posted a $65 assignment to Pixish and ended up with five icons to choose from, one of which was a clear winner. We paid $65 again for refinements to the icon.
• $600 - Category icons: We needed 28 custom icons to represent store categories. We looked at royalty-free ecommerce icon sets from Stockicons.com and others - the problem was, many of our shopping categories weren’t represented, so custom was the way to go.

Deployment costs

• $340/year - Joyent Connector: We prepaid for a year of service. Our server is extremely important to the app and Joyent is solid.
• $120/year - DreamHost: We use DreamHost for a bunch of miscellaneous services, and this also included our domain name.

This website

• $59 - RapidWeaver 4: Because I’m not a web designer I was looking for a tool with great theme support, and RapidWeaver is it. Awesome web design is expensive (or, as they say, priceless), mediocre web design is cheap, but because I knew we’d be updating the site on a regular basis I didn’t want to be going back to a freelancer every five minutes with little changes, so I decided to handle it myself.
• $19.95 - Silk theme: Silk is a beautiful theme for RapidWeaver, now nobody else use it! Seriously, with the tons of color controls, it was easy to make it look custom.

• $99.99 - ScreenFlow: Our screencast isn’t actually done yet, but I’ll be using ScreenFlow to make it. A great tool for a small niche.
• $108 - Blue Snowball mic: This was one of the times when the real world is awesome: I called up my local Guitar Center, they had a Snowball in stock, and I drove over there and picked it up. Seems like a great mic for the price - you can pay more, but why?

Grand total: $4873.92!

Things we didn’t spend money on

• Publicity: It seems like iPhone apps are getting noticed by virtue of eager users having fun with the App Store. We may actually do some advertising to get the word out in the near future, but not quite yet.
• Offices: Louis lives on the east coast and I’m on the west; we weren’t sure if that was going to work, but it totally does. There are some costs for travel, but on the upside we both work from home and don’t have to pay for office space, so it all balances out.

The main hidden cost
...was of course our time. We’ve been working on this for four months solid, which is a lot of hours. If those hours were billable, it would add up to a metric, uh, fun ton.

A final detail
We didn’t spend frivolously, but we didn’t not buy anything we needed, either. $4873.92 is a shoestring, but it’s not like there was a better string out there for more money, you know?

---

A word on our commenting system - we had just put up comments via JS-Kit, and shortly thereafter their site crashed - we lost some of the comments that had already been posted. I’m cutting and pasting the comments that got through below and I apologize profusely if you posted and your comment was lost - we’re dying to hear what you have to say!
]]>support@gifterapp.comBlog2008-06-27T14:14:44-07:00http://www.gifterapp.com/blog/files/3d7eac6f9092a23a868ea394b4147bcb-0.html#unique-entry-id-0http://www.gifterapp.com/blog/files/3d7eac6f9092a23a868ea394b4147bcb-0.html#unique-entry-id-0Posted by Geoff

Welcome to the first release of Gifter! If you haven’t downloaded it and bought delightful gifts for all of your loved ones, I suggest you click the link over there to your right and make it happen. It’s free. Free. Click. Click. Do it now. Did you click? I’m going to check our server logs later. Just kidding. Probably.

ANYWAY, I’m Geoff, the communications/web/treasurer/pirate guy; my partner, Louis, is the code/server/ninja guy, and you’ll be hearing from both of us. Our plan with this blog is to skip the marketing and talk about real topics of interest to the iPhone community - how we got our little company off the ground, how we solved programming issues, the tools we use, our plans for future releases, our business model, things like that. We’re small but ferocious. Not unlike our mascot Sir Jude the War Squirrel.

]]>