Armory will open immediately and operate like offline mode while the blockchain data is loading. Then switch to online mode when it's done. I already have a proof-of-concept for this, I just need to redesign some of the interface to accommodate mixed-online-offline mode.
This is perfect! Splash screens are a strange concept, I think. It definitely adds to the user experience to see the user interface as soon as possible.
One thing you could do when the app shows up immediately, but hasn't loaded the block chain, is disable (grey out) all the items in the GUI that show information that hasn't been loaded yet, and then superimpose some sort of animation on top of it. I like this type of animation (but maybe that's just because I'm used to Linux):
...
Animations, in my opinion, lets the user know that something is going on, and, coupled with a time estimate, it will provide a greater user experience. I already think your client has the best GUI of all clients, and this would really add to it.
On a different note: how is it going with making Armory independant of the Satoshi client? I remember you mentioned something about it being a lot of work. I guess the better solution would be for the Satoshi client-developers to separate out the protocol-specific functionality into a library, so other clients can use it. Developing your own implementation seems like a waste of time, if you ask me (although it might be an interesting/fun experience).
Do you know if the developers have any plans on doing this? Separating out the protocol implementation from the GUI of the Satoshi client? I think this would really spur development of alternative clients, including yours.
I'll look into doing some kind of animation. I was actually thinking I'd have a progress bar, based on MB of blockchain read so far, but the C++ code would need some modification to make that work (currently a C++ black box that python has no internal access to).
I just talked to gmaxwell today about this very topic (networking&validation engine). I really don't want to reimplement that part of the protocol and was hoping that I could cannibalize pieces of the bitcoind library. gmaxwell suggested that they are considering doing something similar with bitcoin-qt: abstract out the wallet from everything else, and have a lite-weight daemon running in the background for any wallet application to use (via sockets and RPC). I have a tough time believing they'll be able to get the non-wallet pieces of it to be "light-weight" enough that people won't complain... but if it is that could great for all developers. I'm envisioning it would be like like the .NET libraries: it's a prerequisite that needs to be installed for other Bitcoin apps to functions -- users will grumble about it, but they'll do it and then forget about it once everything is working.
For now, I'm going to work on a better loading experience, OSX support, and update wallets to support multi-sig, compressed keys, branched wallets, etc. I think that will add more value right now than independent networking -- and maybe this landscape will look a little easier by that time
