Disqus - Latest Comments for AlanQuatermain

Re: iBooks Author vs. ePub Author

AlanQuatermain — Wed, 25 Jan 2012 19:13:00 -0000

Definitely, and I know that the folks at Kobo would appreciate any samples you could send to us, to ensure our client properly supports everything as early as possible on as many platforms as possible.

But be warned: not all platforms will be able to support all features of the ePub3 standard properly. Devices with e-Ink screens, for example, are unlikely to handle animation very well. Be sure to look at using the epub:switch element as a possible means of providing a static-layout alternative in your book; that way the same ePub file will work on devices with different feature sets, degrading gracefully as required.

Re: iBooks Author vs. ePub Author

AlanQuatermain — Wed, 25 Jan 2012 19:07:59 -0000

Well, 'better' is a rather subjective term. ePub is an open standard though, and is supported by most of the eReader devices and software on the market. Therefore if you adopt ePub as your publication format you'll be able to provide that content to the largest number of readers possible.

If that sounds like a good thing, then yes, I guess ePub is better ;o)

Re: iBooks Author vs. ePub Author

AlanQuatermain — Wed, 25 Jan 2012 19:03:35 -0000

I'm not familiar with the landscape for desktop ePub readers, but Kobo usually keeps its desktop application's feature set in sync with that of its eReaders, so when ePub3 is implemented in one it'll be available in the other.

We were all expecting Apple to announce ePub3 support last week, so were quite surprised when they didn't.

Overall, all the major eReader software/hardware vendors were represented in the group developing the ePub3 standard. The idea is that, following the standard's ratification late last year, all ePub-based readers will move to support ePub3 at some point this year. Certainly the publishers (in North America at least) are looking seriously at using ePub3 for their new publications.

Re: iBooks Author vs. ePub Author

AlanQuatermain — Wed, 25 Jan 2012 18:58:11 -0000

Would be great to have you on board. Watch This Space.

Re: http://quatermain.tumblr.com/post/1611382556

AlanQuatermain — Wed, 10 Aug 2011 19:51:04 -0000

The code implementation was shot down, but the results of the decompilation and some sample files are still on github here: http://github.com/AlanQuate...

Re: Have a Mac or iPhone development question?

AlanQuatermain — Wed, 10 Aug 2011 16:10:35 -0000

It's mimicking the behaviour of UITableView here. The correct way to handle it to appear to not remain selected after tapping, you'd implement -didSelectCell to call [self.gridView deselectItemAtIndex: self.gridView.selectedItemIndex].

Re: My Review of the Kobo App

AlanQuatermain — Wed, 27 Jul 2011 08:42:35 -0000

Sure— we did that. We even had Apple pre-approve the changes we were making so that we could avoid seven days in the review queue only to find we missed something.

The problem is that they then rejected the app based on new rules which weren't in the quoted section. Namely, they decided that we could allow users to sign in, but we couldn't allow them to create an account. We could tell them how to create an account though— we checked with them before making the change.

After submitting that, they rejected us for telling users how to create an account ("you can sign up on our website") citing the very same rule. Despite having told us 24 hours earlier that our proposed changes were fine.

The same thing happened with all the references to 'our website', and purchasing content. We weren't allowed to link out, we were told. We were allowed to tell people they could visit our website for more information. Except we were then rejected for doing just that.

Oh, and in the midst of it all, our partner apps, built from the same source code, with slightly differing colour schemes and with 'Kobo' replaced by the partners' name, were all approved, despite having the same features which got the Kobo app rejected. Those apps literally only needed to pull the active links and the 'buy' buttons, just like the guidelines said.

Re: My Review of the Kobo App

AlanQuatermain — Wed, 27 Jul 2011 08:36:06 -0000

They claim to yes. My personal experience says otherwise. I build a bunch of apps from the same source code, and when that app is submitted from Kobo it gets five rejections and lots of change requests, but when submitted from Borders it gets approved with no changes.

The point being that they're wielding these rules as a tool to make iBooks' competitors remove existing features to try to drive them towards iBooks.

Re: My Review of the Kobo App

AlanQuatermain — Wed, 27 Jul 2011 08:32:41 -0000

From the iBooks FAQ on Apple's support site: (http://support.apple.com/kb..., 'Managing your books and iBookstore content' -> 'How can I determine which books are copy-protected (DRM) versus those that are DRM-free?')

"iTunes can show you the kind of book you have by selecting the book and then choosing File > Get Info. If the Kind is marked as Book, this is a book you downloaded from the Internet. If it is listed as Purchased Book, it is a DRM-free book downloaded from the iBookstore. If it is listed as Protected Book, it is a copy-protected book from the iBookstore."

Of course, any ePub files that *aren't* encrypted will work just fine in Kobo, Kindle, Nook, Bluefire and any other ePub reader applications.

Re: My Review of the Kobo App

AlanQuatermain — Tue, 26 Jul 2011 18:28:33 -0000

Oh also: we were rejected for the following snippets of text:

"Due to changes in Apple's iOS application policies we have removed the store."

"We have removed the store to comply with Apple guidelines."

"You can continue to purchase books at Kobo.com and they will automatically download to this device."

"Any books you purchase from Kobo will still be available"

"Don't forget you can still visit our website"

Re: My Review of the Kobo App

AlanQuatermain — Tue, 26 Jul 2011 18:25:22 -0000

Actually we'd been trying to find out from Apple what the new rules were since the rumours started in February. They actually consented to reply to us half-way through WWDC early last month. Since that point we've been working very closely with them to ensure the least amount of disruption to our users. This includes sending mock designs and wireframes to Apple prior to implementing them, so they could give us feedback before we worked on it.

Unfortunately, after approving the wires, they then rejected the app for implementing those same wires. In the past two weeks we submitted our English app four times, our multi-language app five times, and our partner-branded apps three times each. All were based on pre-approved designs, and all were rejected.

We also attempted to have a conversation with Apple about how we'd love to use StoreKit to implement in-app purchase, but that we had various concerns:

- The 30% rate meant that we would be paying Apple 100-200% of whatever we would otherwise make on each sale, while still paying for all bandwidth and storage costs related to the purchase. We asked if we could negotiate a different rate, and made some offers.
- The 3500-item limit on in-app-purchase SKUs falls short of our catalog size by about 2'650'000 items, and since there's no way to bulk-upload SKUs some poor sod would have to manually load and QA every single one of these items through the app, one by one by one. We asked if we could pay something to get a larger catalog size.
- The 'SKU per price point' has a pitfall: the confirmation dialog IAP puts up gives the name associated with the SKU in inverted commas, which means you'll see "…purchase '999 price-point item' for $9.99" or "…purchase 'this item' for $9.99". We asked whether the text on the dialog could be changed.

We were immediately told that they knew about all those problems already, but that word from above was that none of that would be changing.

We've done our level best to work with Apple as much as we can. However, when our app gets treated very differently based on whether it's submitted by 'Kobo Inc' or 'Borders Inc' (or any of our other partners in fact) it leads me personally to look at Apple's responses quite cynically. Especially when they quote rules such as 'an app cannot provide the facility to sign up for an account with a non-Apple system' from section 11.13, while section 11.13 doesn't actually mention that rule…

Re: My Review of the Kobo App

AlanQuatermain — Tue, 26 Jul 2011 18:14:16 -0000

I'm not sure what form of encryption Google Books uses, but Amazon and Apple both use their own proprietary encryption schemes which they don't license to others. So while we'd love to let you read that content, we can't implement that functionality until they release the necessary details.

On the other hand, we do support any form of Adobe DRM on both ePub files and PDFs on many of our devices, and are working on support within the iOS app for this too. Additionally, any book you purchase through Kobo is available using Adobe DRM, which means you can load them onto any device (or into any app) which supports that.

Re: http://quatermain.tumblr.com/post/7492106658

AlanQuatermain — Mon, 11 Jul 2011 10:11:24 -0000

I've been absolutely in love with the place since 2001. At the risk of sounding overly poetic, it feels more like home than anywhere else I've ever been. Feels like the place fits me like a glove 😊

Re: http://quatermain.tumblr.com/post/7191121002

AlanQuatermain — Sun, 03 Jul 2011 12:59:00 -0000

You'll excuse me if I take the more cynical view that this is purely in place to shore up iBooks' lacklustre sales by preventing competing businesses from informing users of any means to obtain content.

…because that's exactly what it is, if Netflix and others are permitted to provide information on their websites and what users can do there. iBooks' competitors are most certainly prohibited from making any such references— the location of their websites and information about what a user can do there are grounds for rejection.

Re: http://quatermain.tumblr.com/post/6494453635

AlanQuatermain — Thu, 16 Jun 2011 13:30:25 -0000

First of all: OMG Amanda Wixted reads my blog *squee!*

*ahem*
`Re-initializing self-composure……done.`

My answer to that would be that, currently, there are few cases where a skilled man applying for a tech job has to deal with the preconception that he isn't going to be any good at it because of his gender. Sadly that's often not the case for women, which makes it important not to be so over-zealous in using positive discrimination that we end up giving the bigots fuel for their own flawed preconceptions.

Re: http://quatermain.tumblr.com/post/635175297

AlanQuatermain — Wed, 15 Jun 2011 21:04:48 -0000

First thing: look at the AQGridViewDelegate function `-gridView:adjustCellFrame:withinGridCellFrame:`. The second parameter is what the grid view is going to use as the frame for a cell. The third parameter is the bounding area of the grid slot in which this cell is being positioned. The default is to centre the cell in the grid slot, but you can modify the `cellFrame` and return a new version to make it use that instead. This would allow you to compensate for things like drop shadows which would extend to the right of a cell's real contents, such that the contents are centred within the grid cell.

For the second part, I'm not sure. It won't scroll just because it's full— it would need to have something below the visible area to which it should scroll. If that's the case, I'd check out the value you're returning from `-numberOfItemsInGridView:`, and then maybe trace from that back to the calls into AQGridViewData's `-rectForEntireGrid` and `-sizeForEntireGrid` methods, making sure that the correct number of items has been set on the AQGridViewData instance.

Re: http://quatermain.tumblr.com/post/528737778

AlanQuatermain — Wed, 25 May 2011 10:10:00 -0000

Just copy the contents of the Classes folder in the main project into your own project— that's all I do.

Re: http://quatermain.tumblr.com/post/528737778

AlanQuatermain — Mon, 18 Apr 2011 09:39:59 -0000

The list-view mode uses a single image per cell, but the shelves actually use transparent cells, and I set the gridView's backgroundView property to a UIView with a pattern backgroundColor. The example above uses an image which has everything from the top of the view to the bottom of the first shelf, and is maybe 100 or so pixels wide to contain the wood grain. Other shelf images (such as the default white one) are only one pixel wide. I then create a color from that image using [UIColor colorWithPatternImage:] and set that as the view's -backgroundColor property.

Re: Preemptively remove running apps from the Dock

AlanQuatermain — Tue, 12 Apr 2011 13:57:50 -0000

I'm pretty sure that was in the original Cheetah Dock as well.

Re: http://quatermain.tumblr.com/post/3892342867

AlanQuatermain — Wed, 16 Mar 2011 12:18:00 -0000

What I have planned will go way beyond AppZapper, and is in my mind the way Apple would likely do it. Simple for users and developers, yet at least as powerful and configurable as the OS X installer is currently. Certainly the primary user interaction method I have in mind would be really quite awesome. Please forgive me if I don't go into too much detail before I've got a prototype up & running though ;-)

Re: http://quatermain.tumblr.com/post/3885536622

AlanQuatermain — Tue, 15 Mar 2011 18:55:09 -0000

Same thing happened at the original iPad launch. So everyone outside the US got delayed by another month. Really seriously annoyed a number of non-US developers whose US-based competitors got a clear two months headway on them as a result.

Re: http://quatermain.tumblr.com/post/3631064659

AlanQuatermain — Mon, 07 Mar 2011 23:33:11 -0000

2 things:

Sometimes it's the margin that people object to. People say it's bad for Amazon to keep 70% or 40% or whatever it is, and that they won't buy from them. People see hand-made baskets on sale at WholeFoods for $50 apiece, and then see the same things in a smaller store for $25. Realising that WholeFoods is using a higher markup, people feel that they shouldn't buy these things from WholeFoods.

It's no uncommon, and it's something that businesses need to work with in one way or another. Historically a 10% markup should be plenty, and after a few years, the company's costs go down, their workforce becomes more streamlined & able to produce more at less cost, and the profit from each $ of revenue increases. That's the way things work, and it's up to the businesses themselves to work with that.

As for horse-drawn carriages vs. cars, that's a strawman. Apple and Amazon/B&N/Kobo are selling essentially the same products, each with their own value-add. Apple's offering isn't like cars vs. carriages, it's like cars vs. other cars. It's like Ford trying to say that their competitors have to give up 30% of revenue paid by anyone who currently drives a Ford.

We'd love to compete with Apple, but they're doing their damndest to ensure that we don't get the chance, by playing fast & loose with the app store rules. Right from the start we've been prohibited from doing any of the clever stuff iBooks does with WebKit— only Apple can do that. Now they're saying we can't do *anything* without enriching them.

Remember: unless I take a 60% cut of every sale, then every sale that comes as a result of my expensive marketing and product development outlay enriches my competitor more than it enriches me, putting me at a greater and greater disadvantage in the market as time goes by.

Re: http://quatermain.tumblr.com/post/3549072134

AlanQuatermain — Fri, 04 Mar 2011 14:40:57 -0000

If so, that would be the first time I've seen such a thing. Normally private APIs become public along with everything else, and developers get beta access to them. That is, after all, the entire point of these developer seed releases.

I think that it's just been decreed 'not ready for prime time' internally. It will likely become public in 10.8 or possibly during a point release of 10.7. That doesn't happen often, but WebKit is the exception to that rule, historically speaking. It gained some significant features during 10.2 point releases IIRC.

Re: http://quatermain.tumblr.com/post/3631064659

AlanQuatermain — Fri, 04 Mar 2011 01:04:45 -0000

You're right that it doesn't make much sense, but that's only the case if you're also assuming that Apple intends to be reasonable. They're not. They want to own the eBook space on iOS, so are pushing the rest of us out in the least-obviously-uncompetitive way they can. Amazon's site is their store, so any links to it (and, based on Readability's rejection, any *mention* of their URL, linked or not) will be cause for rejection.

Re: http://quatermain.tumblr.com/post/3631064659

AlanQuatermain — Fri, 04 Mar 2011 00:23:00 -0000

Incorrect. The rules state that if you sell content which your iOS app can consume, then you must make it available via IAP. Current providers using out-of-app purchase paths have until June 31st before their apps get rejected.