Dec 12

I have commented about developers who do not take the time to display a proper name under the app icon before on this blog.

Recently I experienced a variation on this issue. An app that I was working on was a universal app (both iPhone and iPad). The name of the app fit perfectly under the app icon on the iPad, but on the iPhone (where the icon is smaller) the name got truncated with the ugly … in the middle of the name.

As you may recall, the best way to control the name that is displayed under the app icon is to create an entry in the InfoPlist.strings file like this:

"CFBundleDisplayName" = "YourAppName";

Instead of resorting to abbreviating the name on the iPad just so that it would fit on the iPhone, I wondered if there was a way to have different strings for each platform. After some experimentation it turns out that there is. And it’s quite logical too. Just add the usual ~iphone and ~ipad suffixes after the key, and it just works.

"CFBundleDisplayName~iphone" = "iPhoneName";
"CFBundleDisplayName~ipad" = "iPadNameLong";

written by Nick \\ tags:

Apr 02

The Dilbert widget for embedding the comic strip uses Flash, so you’ll have to tap on the link the old fashioned way to see today’s comic:

http://dilbert.com/strips/comic/2012-04-02/

written by Nick \\ tags:

Apr 01

Consumer Reports have been known in the United States as the premier, independent testing lab for consumer products. To iPhone owners they are probably best known for their role in stoking the flames of reported issues with the antenna design of the then newly launched iPhone 4.

Last week it was time for another attack on Apple’s latest product: The new iPad gets up to 13 degrees hotter than the iPad 2 when playing a game

This report had many experts scratching their heads, and it even prompted an official response from Apple.

Now it seems it may just be part of an elaborate launch promotion for their latest app: iGRill.

Inspired by earlier apps that exercised the iPhone CPU to the point where it could be used as a hand warmer, and this video showing how the iPad can be used as a great kitchen appliance, it was obvious that the latest advances in thermal engineering of the new iPad called for an app like iGRill.

Here’s how it works: Place your new iPad on a flat surface in your kitchen. Make sure that the surface is not flammable and that it can withstand prolonged exposure to the immense temperature of 116 degrees Fahrenheit. Now launch the iGRill app and turn up the dials to maximum heat. Wait a few minutes until the awesome heat animation indicates that the surface of the iPad is now exactly “13 degrees hotter”.

Bring out your raw meat, raw chicken and other foods that are dangerous to consume if they’re not thoroughly cooked. Place the food on the screen of the iPad in the indicated areas. Be careful not to layer the food items. Note that there is no need to add any cooking oil, since the oil from your fingers stored in the oleophobic coating of the screen is sufficient.

If your new iPad and your iPhone are both on the same iCloud account, then you will receive an iMessage as soon as the food is done. This way you don’t have to hang out in the kitchen for months while the food slowly turns into charqui.

Another exciting feature, which can be unlocked with a modest in-app purchase, makes use of the front facing camera. The camera will capture an image of each food item as it’s placed on the screen. The app then matches the captured image with GR’s extensive food database and provides you with instant nutritional information.

The iGRill app is not yet available in the App Store, but we understand there have been heated discussions between the developers and Apple. So look for it to appear in the What’s Hot section soon.

written by Nick \\ tags:

Jan 23

The New York Times had a great article yesterday about the outsourcing to China of all consumer electronics manufacturing in general and the specifically manufacturing of iPhones.

Woven into the article is the fascinating story of how the plastic screen of the first iPhone was replaced with the Gorilla Glass that we know and love, in just six weeks before the iPhone went on sale. No other company besides Apple would even consider pulling off such a feat. And there’s no other place in the world besides Shenzhen China where it would be possible.

written by Nick

Jan 20

Yesterday Apple introduced iBooks Author at an education event in New York City. Almost immediately people were up in arms: How dare Apple introduce an application for free that does not meet all of their own personal needs? And the audacity of insisting on a EULA that favors Apple’s own devices and markets. Not to mention the fact that iBooks Author only runs on Macs. Of course I would also prefer a tool that solves more of my issues related to publishing, along with unicorns and free beer. But, since I’m not footing the bill for the development of iBooks Author, my opinions on this don’t carry much weight. So let’s move on and look at what iBooks Author really is.

iBooks Author is intended to solve a very narrowly defined problem: How to easily create and publish great looking interactive eBooks for the iBookstore to be read on iPads. From what I’ve seen, it solves this problem very well.

iBooks Author is not intended to be a general purpose ePub authoring tool. This is of course disappointing. Most people don’t know that Apple already has one of the very few commercial, easy to use tools for creating ePub files in the iWork Pages application for the Mac. It’s not all that great, but Pages solves the problem of writing a book containing mostly text, adding some images and saving it as an ePub. A disappointing consequence of the introduction of iBooks Author is probably that Pages will not see many future improvements to it’s ePub capabilities.

.ibooks vs. ePub

The output from iBooks Author is like ePub but not quite. If you open up the .ibooks file (it’s a zip archive just like ePub files are) you will see the same structure as an ePub. Each page has it’s own xhtml file, and there are a couple of XML files that describe the structure of the book.

Creating an ePub reader for iOS is not terribly difficult since the individual pages or chapters are pretty standard HTML files which can be displayed in a UIWebView. I believe that iBooks v1.x in essence was built around a UIWebView. But that has changed significantly with iBooks 2.

Examining xhtml files generated by iBooks Author in more detail and you’ll find a lot of non-standard CSS: -ibooks-layout-hint:, -ibooks-list-text-indent:, -ibooks-strikethru-type:, etc. I know there are several WebKit specific CSS extensions with the prefix -webkit, but I don’t know what WebKit, and much less a UIWebView would do with these new -ibooks extensions.

But it gets worse.

When you use one of the built-in widgets you will get code like this:
<object type=”application/x-ibooks+anchored” data-anchor-ref=”danchor-gallery-0″> This code must trigger something in the iBooks 2 binary that renders the widget. It would have been nicer if iBooks Author generated standard JavaScript+CSS here instead. The native approach was probably done for performance reasons, as anyone who has tried to develop complex, interactive animations with JavaScript and CSS can attest to.

A consequence of these design decisions is that it’s no longer possible to load the xhtml files into a UIWebView and see a fully rendered page. This begs the question of how did they implement these new features in iBooks 2? I don’t see any way to just use the public APIs of a UIWebView to accomplish this. But given the debacle when iBooks was caught using a private API for adjusting the screen brightness, it seems unwise to go down that path again. Maybe they started from scratch using the WebKit open source code? They would certainly have the talent at Apple to pull that off.

So why did Apple choose proprietary extensions to ePub instead of fully conforming to the standard? We can only speculate.

  • They want to lock in publishers to the iBookstore to boost the lagging number of titles.
  • They want to ensure only iPads sales benefit from this free tool.
  • They want full control over the format themselves.
  • Time and budget constraints forced them to take the easier path.
  • The current ePub standard does not provide all the functions and features they wanted to include.

I think there is some truth in all of the above, but I would put my money on the last one. See also John Gruber’s insightful analysis.

Given that the output format is closed, it would be possible for Apple to switch to a fully ePub compliant format as soon as the standards catch up. I don’t think this is very likely. But keep in mind that this is just the first version of iBooks Author.

Lack of iPhone compatibility

Curiously iBooks Author only generates ebooks for the iPad. I don’t think there are any technical reasons for excluding the iPhone and iPod touch. It’s more likely to be a content production issue. Creating the page layouts for these enhanced ebooks for the iPad is expensive enough. Forcing publishers to do the work twice to also target the iPhone, would probably be too much to ask.

For the educational market, the iPad is probably the right target. But if you are contemplating using iBooks Author to create ebooks for a wider audience, then the lack of support for iPhone and iPod touch is definitely a factor to consider.

Newsstand

One seemingly obvious application for iBooks Author is to create magazines to be distributed via Newsstand. Jason Snell of MacWorld wishes for this. The current EULA forbids content created with iBooks Author to be distributed via Newsstand (unless you give it away for free), but that is something it shouldn’t be too difficult to get an exception from Apple for, or conceivably see Apple change the EULA to include Newsstand in addition to iBookstore.

But given the architecture of iBooks 2 and the files generated by iBooks Author, it will be a challenge for third party developers to create magazine reader apps to display content generated by iBooks Author.

So should Apple create a generic magazine reader app, e.g. iNewsstand, that has similar features as iBooks, but also handles subscriptions and delivering content using the Newsstand infrastructure? That would be a bit odd to introduce now, as it would become a newsstand within the Newsstand folder. (Apple has actively discouraged third party magazine aggregators from making their apps Newsstand enabled.)

How about a sample project that magazine publishers can download and expand for their own use? This also seems unlikely as that would diminish some of the benefits Apple is achieving (deliberately or as a side effect) from the new proprietary file format.

IBooksPageViewController

An elegant solution to the problem of giving third party developers the ability to display content generated by iBooks Author would be to provide a new view controller that can read and display .ibooks files. It would be like a UIWebView on steroids. We can debate wether it should be a view or a view controller. Given the fixed page layout nature of ebooks created in iBooks Author, I think a view controller would be more appropriate.

Imagine the cool apps that can be created by developers if the creativity unleashed by the free iBooks Author tool could be harnessed in iOS apps. If Apple’s true intention is to keep the file formats proprietary and the technologies exclusive to the iOS platform, that is still achieved and further promoted with this solution.

I like this idea. I think I’ll go right now and submit a Radar for it.

written by Nick \\ tags: , ,

Dec 16

This post is on a very narrow issue, but one that I spent several hours tracking down and finding a fix for. Hopefully this will save some grey hairs for a few of my loyal readers and Google searchers.

An app that we’re working on connects to an IIS server and authenticates using NTLM. For security reasons (for this particular app) NTLM is the only acceptable authentication mechanism.

Therefore, in the didReceiveAuthenticationChallenge callback method we specifically check to ensure that the authentication method is the one we’re accepting.

- (void)connection:(NSURLConnection*)connection
didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge*)challenge {

  if (([[[challenge protectionSpace] authenticationMethod] isEqual:authenticationMethod]) &&
    ([challenge previousFailureCount] <= kAllowedLoginFailures)) {

    [[challenge sender]  useCredential:[NSURLCredential
                    credentialWithUser:user.username
                              password:user.password
                           persistence:NSURLCredentialPersistenceNone]
            forAuthenticationChallenge:challenge];
  } else {
    [[challenge sender] cancelAuthenticationChallenge:challenge];
  }
}

This worked great until the app connected to a server over SSL. Then we experience a very strange behavior. Communication with the server worked fine the first time the app was launched. But after quitting the app and launching it a second time, all server communications failed.

After a bit of debugging and a liberal sprinkling of log statements we discovered that the server sometimes sent the authentication method NSURLAuthenticationMethodServerTrust instead of the expected NSURLAuthenticationMethodNTLM.

We spent some time digging deep into the settings for IIS. The idea of forcing IIS to only use NTLM authentication seemed promising. But in the end we were unable to find the right switch in IIS to get the behavior we desired.

So back to Xcode for a closer look at how authentication is handled. We soon came to the canAuthenticateAgainstProtectionSpace callback method. Which had this naïve implementation:

- (BOOL)connection:(NSURLConnection*)conn
canAuthenticateAgainstProtectionSpace:(NSURLProtectionSpace*)protectionSpace {
  return YES;
}

After fixing this and rejecting authentication methods we can't or don't want to handle, the method now looks like this:

- (BOOL)connection:(NSURLConnection*)conn
canAuthenticateAgainstProtectionSpace:(NSURLProtectionSpace*)protectionSpace {
  DLog(@"protectionSpace: %@", [protectionSpace authenticationMethod]);

  // We only know how to handle NTLM authentication.
  if([[protectionSpace authenticationMethod] isEqualToString:NSURLAuthenticationMethodNTLM])
    return YES;

  // Explicitly reject ServerTrust. This is occasionally sent by IIS.
  if([[protectionSpace authenticationMethod] isEqualToString:NSURLAuthenticationMethodServerTrust])
    return NO;

  return NO;
}

The IIS server still sends NSURLAuthenticationMethodServerTrust occasionally but when the iOS app rejects it, IIS immediately follows with a request for NSURLAuthenticationMethodNTLM. The didReceiveAuthenticationChallenge method is then called with an authentication method that it can handle. All is well again.

written by Nick \\ tags: , , ,

Dec 10

I read an interesting article at NYTimes Blogs about Apple’s Spot-the-Shopper Technology

The article claims that Apple’s system “has had the ability to show the in-store location of a shopper who has come to pick up a purchase”.

How does this work?

I don’t have any insider knowledge of how this system works, so this post is just my speculations. I know that I have very smart readers, so I’m curious to know what you think.

First let’s tackle the easier problem of knowing when a customer arrives at the store. Here are some ideas of this could work.

The Apple Store app could use a mechanism that is similar to the location reindeers in the Reminders app. As soon as the app realizes that the phone is in the vicinity of the Apple Store it sends a message to Apple. GPS is usually not very accurate indoors, but combined with Apple’s database of WiFi hotspots (I’m sure the Apple Store WiFi locations are in their database) it should be accurate enough to provide an alert.
The Apple Store app sends the MAC address of the WiFi network interface in the customer’s device to Apple. As soon as the device tries to connect to the Apple Store network, the MAC address is detected and the system is alerted that the customer has arrived.

Neither mechanism is foolproof. If the customer’s device is in airplane mode, for example, then I can’t think of any mechanism that would work. Since Apple is not advertising this functionality, it doesn’t have to work every time. But each time it does and a customer is delighted by the experience, it’s a win.

Now to the more difficult problem (I think) of locating a customer in the store.

The article shows an iPod touch with a map of the store and locations of people who have requested help highlighted in red.

For iPads with “help buttons” that are part of the store’s fixed display, it’s of course easy to place them on a map and highlight the location when someone asks for help.

But what about customers who have arrived to pick up a purchase? I can’t imagine that GPS is accurate enough inside a store inside a mall to pinpoint a customer.

I wonder if it’s possible for the WiFi access points inside the store to triangulate the location of a given MAC address with enough precision?

Have you experienced this system first hand? Were the Apple employees able to find you in the crowd?

Comments are open.

written by Nick \\ tags:

Nov 28

A long weekend is a good time to catch up on some reading of articles queued up in Instapaper. Here are several design related items that I found interesting.

Copycats

A well argued essay on why it’s so difficult to innovate and create great design. And why it’s so important to break through those barriers to be successful.

360iDev: Lessons from the design of Postage

Postage is a beautiful app for the iPhone. It is also very functional. I think the latter comes from Chris Parrish’s philosophy of “putting the user on rails”. Figure out what the main goal for a user of your app is, and make sure that goal can be accomplished as quickly and easily as possible. Great advice!

Apple, Kindly Remove Your OS Gestures from My App Canvas

I agree with Josh Clark that Apple blew it with these new “system” gestures in iOS 5. It would have been much better if these gestures started off the edge of the screen to give the user the clear indication that this gesture is something that is going to have an affect outside the context of the app that currently fills the screen. The gesture for showing the Notification Center does this, for example.

I think I know why Apple made this decision: to use the same gestures in Lion. In a windowed environment like OS X for the Mac, the context of the screen does not have the same meaning. So starting a gesture outside the screen does not make as much sense. And also, beginning a gesture with your fingers outside the physical area of a Magic Trackpad is awkward.

In my opinion, Apple made the wrong trade-off in this case, resulting in a worse user experience for iOS.

Exclusive: Matias Duarte on the philosophy of Android, and an in-depth look at Ice Cream Sandwich

This is a rather long article, but I’m not sure what it really says about the design philosophy of Android, if anything. My takeaway is that Matias Duarte is a very good and thoughtful designer who has strong opinions about design. I think this is good for Android. I think good design should convey and evoke opinions; an object should have a design personality.

Touchscreens have no hand

Information design legend Edward Tufte comments that touch screens are dead flat and have no texture. Maybe this is the reason for Apple’s recent fascination with skeuomorphism. (A simpler explanation is that the “more texture” decree came from the top.) In any case, I hope that Apple already has touch screens in their lab with haptic feedback so that we soon can feel real texture in our apps.

A Brief Rant on the Future of Interaction Design

Microsoft’s productivity future vision video made the rounds a while ago and was widely criticized for showing something that was not real, could never be made into a real product, and had many inconsistencies in the user interactions. While that may all be true, I think Bret Victor’s critique that is doesn’t go far enough is more spot on. His essay about our hands and how truly useful they could be in a future user interface is truly inspiring.

Dilbert November 27

Finally, I can’t help but to link to yesterday’s Dilbert strip. I think this is how we all feel about smartphone interface design at times.

written by Nick

Nov 22

With iOS 5 there’s a subtle change in behavior related to custom table view headers. Actually it’s just a more strict enforcement of the existing API. But the end result is the same: Your app may not work as you expected when running on iOS 5.

If you are implementing

- (UIView *)tableView:(UITableView *)tableView viewForHeaderInSection:(NSInteger)section

in your UITableViewDataSource then you must also implement

- (CGFloat)tableView:(UITableView *)tableView heightForHeaderInSection:(NSInteger)section

The heightForHeaderInSection method needs to return a height of 0.0 when the viewForHeaderInSection returns a nil for the case when there are no rows in that section. Otherwise you will see a lot of gray, empty header views in your table in iOS 5.

To Apple’s credit they have clearly stated this in the documentation for tableView:viewForHeaderInSection:

This method only works correctly when tableView:heightForHeaderInSection: is also implemented.

But if you missed this in the documentation and you’re wondering why your tables views suddenly don’t look so good in iOS 5, there’s your explanation. And the quick fix.

written by Nick \\ tags: , , ,

Nov 17

I saw the Steve Jobs interview movie by Robert X. Cringely today. For die-hard Apple fans it doesn’t contain any new information. But most stories about Steve Jobs are related second or third hand. This is a rare opportunity to see and hear the man himself. Very entertaining, and definitely worth watching if you get the chance.

There’s also an interesting and geeky story behind the movie. The full interview was thought to be lost for many years, until a VHS copy surfaced. With sophisticated image processing the VHS tape was used to create a movie that was watchable on the large screen of a movie theater. No small feat. It was very evident that the source material was not high definition, but it was not too distracting. Maybe that was because of the entertaining subject, or the reality distortion field coming through.

written by Nick