Adjust Multiple Column Sizes Simultaneously
Within the Finder, Column View enables you to see folder hierarchies, with each subsequent level getting its own column. Dragging on the double lines at the base of a column divider changes the preceding column's width. But Option-drag on any divider, and all the columns in the window change to the same width.
Visit MacTipster blog
Submitted by
Sharon Zardetto
Recent TidBITS Talk Discussions
- Alternatives to MobileMe for syncing calendars between iPad/Mac (1 message)
- Free anti-virus for the Mac (20 messages)
- iTunes 10 syncing iPod Touch 4.1 (2 messages)
- Thoughts about Ping (16 messages)
Related Articles
- Take Control Sale: 50% Off to Celebrate Account Management (26 Jul 10)
- Apps and Docs in iOS (15 Jul 10)
- What is Fast App Switching? (23 Jun 10)
Published in TidBITS 1037.
Subscribe to our weekly email edition.
- Take Control Sale: 50% Off to Celebrate Account Management
- Skype 2.0.1 Brings Background Calls to iOS
- iBooks 1.1.2 Adds Image Zooming, Fixes PDF Link Bug
- DealBITS Discount: Save 20% on PDF Shrink 4.5
- Apple Donates MacPaint and QuickDraw Source Code to Museum
- Beware Bluetooth Keyboards with iOS Devices
- Apple Reports $3.25 Billion Profit for Q3 2010
- Apps and Docs in iOS
- TidBITS Watchlist: Notable Software Updates for 26 July 2010
- ExtraBITS for 26 July 2010
Take Control's Problems with Apps and Docs in iOS
Until the iPad came out, we didn't receive many requests to read our Take Control ebooks on the iPhone and iPod touch. But once the iPad appeared, the email from readers requesting this capability started to pour in.
What We Want, and Why We Can't Have It -- If you're shopping for an ebook, it should be easy for you to browse a Web-based catalog, pay via an online cart, and download your new ebook to your device, whether that device is a laptop or desktop computer, a new iPhone 4, an iPad, an older iPhone or iPod touch, or maybe an Android phone or other device.
And, in the Take Control Web site and cart, all of that is possible... except downloading of the files. We haven't yet seriously looked into the Android and other handhelds, but we have recently spent quite a lot of time learning how we can make it possible to download to an iOS device and investigating how iOS makes the connections between apps and documents. This investigation prompted Matt Neuburg's article, "Apps and Docs in iOS" (15 July 2010). If you haven't done so already, go read Matt's article - what I say next may not make sense without that background.
Now think about what Matt says in relation to a publisher offering an Internet service that provides downloadable content to iOS device users, such as a purchased ebook or a software manual. The Take Control series, as an example, faces several hurdles:
iOS offers no centralized file storage area, so any downloaded file would live in only one app, or, if that app could share with others, multiple copies could be spread among multiple apps. That could be confusing for users, who would likely then turn to us for help.
iOS needs to support Zip files. We distribute our ebooks as zipped PDF files, not just to reduce file size, but also because it ensures that when you download the file, you really download it, as opposed to displaying the PDF in your Web browser. Otherwise, someone could become confused by closing a PDF-displaying browser window and "losing" the ebook. Although some iOS apps can handle Zip files, none of Apple's own apps can. Plus, there's no programmatic way - either on the iOS device itself or on a Web page - to know before a link is clicked if a user has an app like GoodReader that can handle Zip files, so we can't even sniff the presence of a Zip-handling app and change the download page accordingly.
Although our cart doesn't have a feature for presenting iOS-using customers with straight PDFs at the end of the shopping process, such a feature would be fraught with problems. A straight PDF download might work in iOS 4, under which Safari presents a normal Open In dialog, but in iOS 3.2 on the iPad, Safari displays the PDF but doesn't let you open it in any other app to save it. Navigate away from that page, and the PDF disappears. And since the download URLs in our cart are good for only a limited time, you wouldn't be able to get that PDF again. That's not a good user experience.
Luckily, as we were trying to figure out a better alternative for iOS users, we were also building our Take Control account management system. At some point we had a brainstorm - iOS users could download their books when they were logged in to our Web site. We have PDF versions of all our ebooks, and EPUB and Mobipocket versions of many of them. You could log in to your account and then view the PDF version of one of our ebooks in Safari or download into GoodReader, which offers better ebook-reading features. And with PDF, that's easy and is working now.
But what about EPUB? Apple's iBooks app can display EPUB files copied into the Books category in iTunes, but it turns out that iBooks does not register itself as being able to open files with the EPUB UTI. Tap a link to a .epub file on a Web page loaded in Safari and another app might offer to open it, but iBooks won't. Worse, if the user doesn't have any app that can open an EPUB file, Safari merely reports "Download Failed: Safari cannot download this file." Also not a good user experience.
Why Not Use the iBookstore? An answer to this problem is to upload our ebooks to the iBookstore, and in fact, we've done that with a number of our titles (search for "Take Control" from within iBooks). However, we don't consider the iBookstore a complete solution, for a number of reasons:
We want the autonomy of running our own site so we control the shopping experience, including offering bundle discounts and sales like this week's 50-percent-off sale (see "Take Control Sale: 50% Off to Celebrate Account Management," 26 July 2010).
Working with the iBookstore is slow. It takes roughly two weeks for a book to be approved for sale, and even once it has been approved, changes take anywhere from a few days to a week.
All books in the iBookstore must be in EPUB format, even though iBooks now supports PDF. Although we have converted many of our PDF-based ebooks to EPUB, the PDF versions look and work a lot better on the iPad (EPUB is better for the small screen iPhone and iPod touch).
The iBookstore is a black box, accessible only via iBooks. There's no way to link to a book in the iBookstore from the Web, as is possible with the iTunes Store and the App Store.
Apple takes a 30 percent cut of sales from the iBookstore, and while we don't begrudge them that, we'd prefer to sell directly from our site, where our transaction costs are lower.
If you purchase one of our ebooks through the iBookstore, you must create your Take Control account manually, or, if it's already created, add your book to it manually. Account creation and population is handled automatically for orders through our cart. We give free and generously discounted updates to many of our ebooks; some of that won't be possible for iBookstore customers.
The iBookstore has a nice layout, but it's not ideally suited to the needs of our ebooks and customers.
Further, other organizations or individuals may wish to make a few documents available for download to an iOS device in an informal manner, but not so informal that they toss their documents to the winds of the current iOS approach. Brochures, posters, course catalogs, newsletters, and so forth, for instance, don't belong in the iBookstore.
Documents in the Dark -- So, assuming Internet-based file serving of ebooks is something we want to roll ourselves, what would be a good user experience, since nobody can predict in advance what file types a particular iOS device can open in which apps? To explore this question, I created a simple Web page that linked to a PDF, an EPUB, a Mobipocket file, and a Zip file, and we tested what happened when we tapped each of those links in Safari on different devices. Then, to see if the results were different outside of Safari, Matt wrote a tiny app that contains sample documents in each of these formats and displays the Open In dialog when the user taps an associated button.
Alas, our results were all over the map. The iOS 3.2-based iPad reacted somewhat differently than the iOS 4-based iPhones, and each device offered different options for opening any given file type based on which apps were installed on it. This is, in fact, how we learned that iBooks cannot open an EPUB via the Open In dialog, and that Safari in the iPad's iOS 3.2 doesn't offer an Open In dialog for PDF, while Safari in iOS 4 does. So, while Safari can open linked files of various types and potentially hand them off to other apps, one of three things will occur:
If no app on the iOS device can handle the file type, Safari displays a Download Failed dialog.
If the file in question is a PDF, Safari loads it and displays it, and, if you're in iOS 4, it also shows native Open In buttons (below left). If there is only one app that can handle a PDF, such as iBooks, you'll see a single Open In iBooks button. If you have multiple apps that can handle PDFs, one will be the default (I'm guessing now that it's the most recently updated), and the full set (below right) will be displayed if you tap the Open In... button.
If the file isn't a PDF, but there's an app that can handle it, Safari downloads it and displays an unusual Web page-based "dialog" that shows either a specific Open In AppName button, or both that and an Open In button (below left) that, when tapped, shows the list of available apps for that file type (below right).
The user experience here isn't good either. This "dialog" isn't a real Web page, in that you can't scroll it vertically on an iPhone or iPod touch screen, and its buttons are below the bottom of the page and out of tapping range. Plus, if you have zoomed the Web page containing the source link, the resulting page for the "dialog" is also zoomed, with the effect that the dialog is sometimes completely out of sight. If multiple apps can handle a file type, the icons that Safari shows are almost always mixed up between the apps. Finally, I've had to terminate Safari manually in at least one case - dealing with that dialog froze the app.
On the iPad, we learned that EPUB files can be opened in Stanza, GoodReader, BookShelf, and CloudReaders, though only Stanza can actually display the EPUB file. We also learned that Bookshelf can open and display a Mobipocket file. BookShelf, CloudReaders, and GoodReader all claim to be able to open a Zip file, but only GoodReader can. Lots of apps can open PDFs, including iBooks and GoodReader. (In our initial tests on an iPhone and iPod touch, GoodReader wasn't showing up in the Open In dialog at all, since it hadn't at that point been updated for iOS 4. This is yet another area where apps must be rewritten and recompiled to deal with the ever-evolving iPhone system - see "What is Fast App Switching?," 23 June 2010.)
For people like us, who try to give reliable, concrete directions, this situation is maddening. At Take Control, we want to provide a service to our readers, supplying an ebook via the Internet and helping the user open it in some appropriate app. But we're having trouble doing that because there's no way of predicting what will happen on any given user's device.
It would be great if we could write an iOS app or code a Web page that checks what a user's options are and says, "You have an app that can open an EPUB, so shall we download the book as an EPUB?" But we don't see any way to learn what the user's options are. We can't find out what apps the user has that can open a certain type of document, and there's no central registry telling us even what apps exist that can open a certain type of document. If, on the other hand, we just provide a URL to the ebook and let the user open it in Safari, we've ceded control to Safari, which might tell the user that there's no app that can open this document. Now the user is confused, stymied, and probably mad at us.
Interim Solutions -- What have we done? Two things. First, we've added a blue-colored note to the first screen of our cart when it's loaded from an iOS device, giving customers advice on how to proceed once they finish ordering.
![](/file/11593/db.tidbits.com.tar/db.tidbits.com/tbthumbs/tn_iOS-download-warning.jpg)
Second, when you visit your Take Control Account page from an iOS device, we focus the available links on downloading the PDF file for each purchased ebook. One link downloads the file in Safari; the other downloads in GoodReader, by using the ghttp: scheme that GoodReader alone understands. We recommend the latter, since it's a better experience. (In fact, it downloads the zipped PDF, which GoodReader can expand, resulting in the full book title being displayed in GoodReader, rather than the filename of the PDF.)
We'll be evaluating these decisions (and the specific interfaces we use) regularly, and if we come up with something better, we'll implement it. We're definitely feeling our way at this point, and are open to suggestions.
Right now, we don't let readers download the EPUB and Mobipocket versions of our ebooks directly. They're accessible only as zipped archives from your Take Control account, and only from a desktop or laptop computer. That's because, as noted above, iBooks can't open EPUB files from a link yet, leaving only Stanza (EPUB) and Bookshelf (Mobipocket) as the apps that could handle those links. However, we plan to make it possible to download those files within iOS in the future, once the apps (iBooks in particular) catch up.
(In case you were wondering, we don't sell a bundle of the PDF, EPUB, and Mobipocket files because we don't want to delay publication until EPUB and Mobipocket conversion is done, and we don't want users to get different things depending on when they download.)
Overall, the moral of the story is that until Apple makes the whole business of apps and documents more rational and open in iOS, every document type will have to be dealt with individually, on a case-by-case basis, with a lot of head-scratching and frustration for anyone who wants to offer documents for download from the Internet. Document types are a good idea, obviously, but Apple needs to loosen the wraps and make this a better experience for users and developers alike. Otherwise, while we don't want to say that what Apple has provided is worse than nothing, it's darned close.
![](/file/11593/db.tidbits.com.tar/db.tidbits.com/images/badges/mark-space.gif)
address book, music, photos and much more between your phone
and Mac. Supports ANDROID, BLACKBERRY, PALM PRE and many
other phones. <http://www.markspace.com/bits>
However if you really must swim against the tide, then you could consider following the path of magazines/newspapers and writing your own iOS App and using Apple's in-App purchasing. This should give you more control over formatting and speed of issuing content, but would not avoid Apple's commission. However you should also consider the savings of not having to pay credit-card fees, or hosting and support of a web-store.
The iBookstore is just another retailer to us, like any single bookstore or chain is to a paper publisher. We're happy to support it, but we would never consider it our only outlet, even for a particular device. (And of course, the iBookstore isn't at all accessible to any other type of device.)
As far as an app with In-App Purchasing goes, it's a possibility, but it suffers from three major liabilities:
* We have pay to develop and maintain it, which isn't cheap.
* People have to get it before they can order books using it, which is a major obstacle.
* Apple still takes 30% of the proceeds which is vastly more than our normal transaction fees for our eSellerate cart.
Apple will eventually 'fix' more things giving more options but I sure hope that it isn't a finder system and that they keep it simple.
Afraid that your wish list will stay that for a while.
Note that I have no problems with downloading a file and dumping it into iTunes or the GoodReader download options. Not a big deal to myself or to others that I show it to.
The simple fact of the matter is that documents are utterly commonplace on the Web, and if Apple wants iOS to be a fully Web-savvy operating system, it's going to have to deal with documents more cleanly.
However, in our recent EPUBs, there's an Updates section in the front matter with a link that should work to get to the Ebook Extras page. Because Apple gives some number of free pages as a sample in the iBookstore, including that section, we had to move it to the back of the book for the iBookstore EPUBs (truly annoying makework, but no way around it).
But this is yet another reason we created the Take Control account management system - so you wouldn't have to go to each book and click its Check for Updates button or equivalent link to see what was new and get it. Your Take Control Account page just shows all that now, and lets you download whatever you have, in whatever format you want.
As for the Take Control situation, for any ebook that lacks a Check for Updates button on the cover (it could be an EPUB or an app), look in the Read Me First section.
We aren't entirely sure how "automagic" updates will be in the iBookstore ourselves, but we'll find out soon enough.
I've actually found that PDF's of books are actually worse to read on the ipad. I may just be reading the wrong ones, though.
Either way, I'm really looking forward to what Apple does w/ these. I do think that things will get better over time, and they've already done so. iBooks sync state of books that weren't bought through the bookstore. Open a book the ipad, then on the iphone, and you're at the same place. That's partly why I just bought a new ipad, w/ 3G. (The other being that I was able to find a buyer for my wifi, and we don't have wifi at the new office.)