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 <con...@synthetiqsolutions.com> 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 (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
