+3  A: 

I'd go for the smaller download, I think.

I would suggest having a "splash instruction manual". Explain on the first page that you're installing the application, and then start providing simple instructions. Importantly, allow the user to go back and forward on the instructions - don't make it like the installers which give you one splash page after another, without any control over what's going on.

During the installation, have a bar at the bottom (or something similar) indicating progress... and when the installation is complete, turn this into a "launch" button so that the user can finish reading the instructions before launching, if they want to.

I'm not an HCI expert by any means, but I think that's what I'd want.

Jon Skeet
I agree with providing feedback - I like having the first page be an installation instructions they can read. I just have to remove that from subsequent starts.
mr-sk
+1  A: 

I myself would rather have a 30mb file which needs to be unpacked than a 80mb file which is almost 3 times bigger.

The copying/downloading might be faster so the 25 seconds in which you will have to unpack the app will not cause that much problem. Also 25 seconds isn't that long, if it were 25 seconds everytime the app started it would be a problem but since it is only once it doesn't matter.

As for the indicator, a process bar from 0% to 100% or a simple animation "Installing.. please wait" with a small explanation that it will only happen once will suffice.

I agree - and its only 25 seconds the first time (provided they let the DB be fully constructed and don't quit mid way).
mr-sk
+6  A: 

Since you won't get under the 10MB "you must be connected to Wi-Fi to download this" limit either way, I don't think it matters much whether it's an 80MB or 30MB download.

Additionally - by decompressing the data on launch, you've added another failure mode. What if you run out of space during the decompression? You'll have to write code that checks for that, informs the user in a way that they can do something about it, and then retry the decompression the next time they launch.

Mark Bessey
Good point - I agree with this as well. No even close to 10MB.
mr-sk
Also, having the file uncompressed on first launch means that it will be stored twice on the device consuming more space than necessary. Perhaps some in-place compression of the sqlite database would be best?
rpetrich
mr-sk
+2  A: 

Personally I don't think it matters. In both cases it sounds like a one time cost at the very beginning, so either case is reasonable.

The larger download might be a bit better to the end users as there's a single time they have to wait (when downloading the app), instead of two (first downloading, then the first time they run).

The smaller download would be better if bandwidth is limited/expensive. If you have to serve this to all your users it would be cheaper for you to serve the compressed version. However, since this will be handled by the App Store, not you, then this is probably not a big deal.

Herms
Yeah that's a great point. The big download is a one time cost, (download/install) VS a still large download/install (and 25 second startup).Its also less work for me - Maybe I'll provide a point of contact so users can provide feedback once the app is released, specifically to address this issue.
mr-sk
rodey
Yeah, since apple is hosting, I'm not worried about bandwidth cost and since its 30 or 80, you should be on wifi or tethered (and doing the install via itunes).
mr-sk
+2  A: 

What about compressing the database's field values but not the database itself, then decompressing on demand? Would that sort of approach work for your database use?

Marco
Yes - I thought about that today as well. I might try that tonight and see. That would work very well because they never access more than one field at a time in the database, so the overhead wouldn't be too awful (I think).
mr-sk
Working on this now - Got the DB at 41MB with only the essential stuff compressed. Working on some code to decompress it now ...
mr-sk
A: 

Give me the smaller download. Upon the first boot, just let me know there is going to be a 30-60 second wait while the application is "configuring" itself. Stress that this is a one time only deal.

rodey
A: 

It'd going to take more space in the end if you star compressed, because it will be 80MB + the compressed 30MB.

Anything over 10MB will require WiFi so it really does not matter.

Kendall Helmstetter Gelner
A: 

My vote: 30MB + 25 second unpacking.

Make sure to:

  • Give the user feedback on how much time left by implementing a progress bar ( or something similar )
  • Entertain the user with something visual

How to entertain the user:

  • During the progress bar, play a slide show of 3 or 4 slides demonstrating all the cool features of your app

p.s. I got this idea from Matlab's installation process. Matlab takes like 20 minutes to install... so they have a slide show with cool pictures and they tell you about new features. It keeps you entertained for like 5 minutes, but unfortunately the slideshow cycles and then you leave to go do something else. I think it would be better if they had made a longer slideshow.

Trevor Boyd Smith
A: 

Thanks for all the feedback everyone - lots of great information.

I ended up implementing Marco's suggestion - and it's working very well. Im using zlib compress when I build the DB and uncompress after I extract the data. Its about 41MB - so I'm pretty happy with that.

Thanks again everyone!

  • sk
mr-sk
A: 

I'm going to download the application once, but I'm going to run it multiple times.
I will always prefer faster operation for larger space requirements.

EDIT: What do you mean by "FIRST boot" only? Do I have to wait 25 seconds each time I turn off my phone and then turn it back on and then launch the app? Or do you mean only ONCE ever once I have the app?

If it is the former, my original answer stands, if the latter, I prefer a smaller download if I only have to wait once ever.

Nick Presta