MobileRead Forums - View Single Post

dgatwood · 02-26-2013, 11:19 PM

I'm assuming that you already have the magic file in there that tells iBooks to use the publisher-specified fonts, right? I would expect any "We'll fix your broken books" behavior to be keyed off of the presence or absence of that file; if somebody has take the time to update their content to work in iBooks, then there's no need to assume that the content is broken, and if they haven't, then it probably is broken.

Either way, I want to strongly disagree with JSWolf's advice. Please do file bugs every time you find something that doesn't behave the way you expect it to behave. This does three things:

1. It ensures that the development team knows that a particular behavior is dubious.
2. It ensures that they have an accurate picture of how many people that behavior is causing problems for.
3. If it really is an expected behavior and they have already come up with a better way of doing what you're trying to do, they'll tell you and save you a lot of wasted time.

I can't tell you how many times I've filed a bug and been told, "You're the first one to complain about it" even though people have been whining and kvetching about it on forums for years. You can safely assume that nobody will ever fix problems that they haven't been told about, and that the priority of bug fixes is proportional to the number of people it affects.

You should never assume that developers of any application, whether they work at Apple or Adobe or Kobo or B&N or Amazon or whatever, have any idea that they've broken something, because 99 times out of 100, they don't. They're not producing content that has to work with the devices; they're producing devices that have to work with the content. You folks—the people who are in the trenches producing content—are the ones who know what problems you're hitting in the real world.

More to the point, you're the ones who notice and hear about it when your content breaks. When your content breaks, it is quite frequently caused by a poorly designed fix to work around something wrong with somebody else's content. But if your content is right, it should take priority over somebody else whose content is wrong. By screaming early and often, you ensure that poorly engineered fixes don't become so engrained in the behavior of an app that they can't be changed, and you greatly increase the chances of the engineering team going back to fix the problem the right way. The earlier you notice a bug, the easier it is to fix, and all that.

So please do file bugs. Please.

02-26-2013, 11:19 PM	#16
dgatwood Curmudgeon Posts: 629 Karma: 1623086 Join Date: Jan 2012 Device: iPad, iPhone, Nook Simple Touch	I'm assuming that you already have the magic file in there that tells iBooks to use the publisher-specified fonts, right? I would expect any "We'll fix your broken books" behavior to be keyed off of the presence or absence of that file; if somebody has take the time to update their content to work in iBooks, then there's no need to assume that the content is broken, and if they haven't, then it probably is broken. Either way, I want to strongly disagree with JSWolf's advice. Please do file bugs every time you find something that doesn't behave the way you expect it to behave. This does three things: 1. It ensures that the development team knows that a particular behavior is dubious. 2. It ensures that they have an accurate picture of how many people that behavior is causing problems for. 3. If it really is an expected behavior and they have already come up with a better way of doing what you're trying to do, they'll tell you and save you a lot of wasted time. I can't tell you how many times I've filed a bug and been told, "You're the first one to complain about it" even though people have been whining and kvetching about it on forums for years. You can safely assume that nobody will ever fix problems that they haven't been told about, and that the priority of bug fixes is proportional to the number of people it affects. You should never assume that developers of any application, whether they work at Apple or Adobe or Kobo or B&N or Amazon or whatever, have any idea that they've broken something, because 99 times out of 100, they don't. They're not producing content that has to work with the devices; they're producing devices that have to work with the content. You folks—the people who are in the trenches producing content—are the ones who know what problems you're hitting in the real world. More to the point, you're the ones who notice and hear about it when your content breaks. When your content breaks, it is quite frequently caused by a poorly designed fix to work around something wrong with somebody else's content. But if your content is right, it should take priority over somebody else whose content is wrong. By screaming early and often, you ensure that poorly engineered fixes don't become so engrained in the behavior of an app that they can't be changed, and you greatly increase the chances of the engineering team going back to fix the problem the right way. The earlier you notice a bug, the easier it is to fix, and all that. So please do file bugs. Please.