Re: iOS app launching speed
Re: iOS app launching speed
- Subject: Re: iOS app launching speed
- From: Alex Zavatone <email@hidden>
- Date: Tue, 15 May 2012 20:15:38 +0000 (GMT)
OK. I've got one item to discuss with you, the splash/launch screen.
This is why I like it.
Right after clicking on an app's icon, the splash screen/launch screen shows that the device has indeed paid attention to you and responded in the manner you expected, namely, the application has launched and is proceeding to load.
I can not see how this is a bad idea.
Now, after this appears, there is a reasonable time delay when the user expects some more feedback. If the user has no reaction, no "when will this thing finish launching" thought, you're home free. Users more likely pay attention to when something is wrong, than when it is good or great. By eliminating all the points where a user would express a thought of "this sucks" you're left with something that meets their expectations, that is at least good enough. This gets us to good. That's what I'm trying to lay the groundwork for.
There are barely conscious thoughts that happen if you break with the user's expectations for the worse, that put a moment of displeasure in the user's experience of using the app. Identify and eliminate all of these that you can. This makes a pleasant app.
It's by identifying and removing flaws that you enhance an app's usability. Ideally, the user would have no moments of "Meh, that sucks", or "why is this taking so loooong", so the user can get their task done without undue grief or inconvenience.
Or at lease those are my thoughts on the process.
- Alex Zavatone.
On May 15, 2012, at 12:22 PM, Conrad Shultz <email@hidden> wrote:
On 5/15/12 11:18 AM, Alex Zavatone wrote:
Yes, and I've tested it and we haven't had a problem with this. I
trust your advice, yet all I can see is that if the data transmission
fails mid 4KB data transfer, it would hang. In the case where the
URL is invalid or unreachable, we have a dict to read from on the
device.
In the "real world" things never behave normally. Here are just a few
issues that can (and by Murphy's Law, will) come up but won't trigger a
validity/reachability failure:
- The network is reachable but DNS is slow or unavailable.
- A caching DNS server has a stale record, directing traffic to a wrong
machine whose firewall silently drops packets on the floor (i.e. no
reject message sent).
- The client is running inside a captive network that is not detected by
iOS. (This happens surprisingly often, as far as I can tell in cases
where the captive network passes ICMP traffic but not TCP/UDP.)
- As you indicated, data transmission fails mid-transfer. This could
happen for a reason as simple as walking into a basement or tunnel. (I
recall once standing at a construction site, watching in horror as a
backhoe drove right through a fiber bundle, instantly killing all my
connections.) Of course, until a TCP timeout is reached, this is
indistinguishable from a slow connection. (Cf. the Two Generals' Problem.)
You really can't assume that a network connection will ever complete in
any finite period. In fact, you have to assume that any given
connection will take an indeterminate (worst-case: infinite) amount of time.
Well, the Apple HUI guidelines have been taking some strange
directions recently on the Mac end of things. I'm sticking with what
I know will provide a tried and true expected (good) user experience.
I disagree that splash screens are a good user experience.
I'm doing it because it's simply lame to display an empty TVC and
then have it fill in as content appears like an HTML page.
I don't know what you mean by "lame." That guidance is because it
*appears* to the user to be faster when you display the empty TVC.
There is an even more important reason not to just throw in a splash
screen as Default.png, though. As the devices get faster (and your code
more efficient), Default.png will be on the screen for a shorter period
of time. Eventually you will get the jarring experience of a splash
screen flashing for a moment before the UI draws. This is a terrible,
strobe-like user experience.
The options then are two-fold:
1) Present a UIImageView of Default.png in
-applicationDidFinishLaunchingWithOptions:. This allows you to
subsequently do a controlled presentation of the UI without a strobe
effect, but irritates users because you are now actively impeding their
ability to actually use the app.
2) Drop the splash screen and replace it with an "empty" (non-localized)
UI image.
I think of this as analogous to watching movies. One reason that
watching movies on iTunes is more pleasant than DVD or Blu-ray is that I
don't have to suffer through Hollywood's version of a splash screen:
Copyright notices.
I'm missing your point. Are you saying don't use a graphic
(Default.png) when the app launches or the approach I used back last
century with Director?
I'm not familiar with Director.
I'm saying: grab a screenshot of the initial screen and edit out any
elements that will vary by locale (e.g. text, dynamically sized
controls, etc.) and use that. Alternatively, create a xib that matches
your UI but without any such localized elements, and use a screenshot of
that xib.
The latter requires maintaining two xibs, though, so I usually just go
the Acorn (or Photoshop, or Pixelmator, pick your poison) route.
--
Conrad Shultz
Synthetiq Solutions
www.synthetiqsolutions.com
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden