It really is a shame that my e-reader doesn't have an SD slot

[Shades]

Originally Posted by speakingtohe

I think kindle was around before Kobo and I doubt you could get a patent on sliders

I don't know... Apple has a patent for disappearing scroll bars.

[Rizla]

Originally Posted by twowheels

I'm one of those who made that statement.

As a software engineer for 20+ years (professionally, and 30+ as a hobby) I have a lot of experience with such things and it is my experience that whenever you have to make a decission, that's a potential bug -- every decision point is a potential point of error. Now, a lot of bugs can be avoided by good design, but it's also my experience that many (most) software developers write horribly complex code with a lot of special cases and extremely convoluted logic, which grows exponentially more complex with more options. There are very few who can see through the immediately obvious collection of flags, switches, and branches, and come up with an elegant solution that avoids special cases and can treat them all as the same -- especially when adding options to existing implementations that they didn't write indeed.

The code is already in place to 1) increase / decrease font size, and 2) the same for margins. Adding an extra in-between font size and margin setting to an existing series of cases barely complicates code because the framework is already there. Adding extra font sizes is trivial. To mess this up would take a very poor programmer indeed...

[eschwartz]

Originally Posted by Rizla

They are quite different things. One exists, the other doesn't.

Correct. Faking the appearance of loyalty doesn't exist -- because once you do that, you are in fact being loyal.

Side-loaders (like USB-card users) are a fringe minority of users. If Amazon can find a cheap alternative to charge, it will make no sense to retain the port.

1. No they aren't.
2. See DiapDealer's response the last time you said this.

Originally Posted by DiapDealer

What was nonsense (and still is), was your suggestion that sideloading is only a byproduct of the need to connect a charging cable. Also nonsensical is the idea that the elimination of a charging cable need automatically spell the end of sideloading.

[eschwartz]

Originally Posted by Rizla

The code is already in place to 1) increase / decrease font size, and 2) the same for margins. Adding an extra in-between font size and margin setting to an existing series of cases barely complicates code because the framework is already there. Adding extra font sizes is trivial.

And to add extra UI methods of accessing that code does not make use of an existing framework.

Question: Do you have 20+ years of professional programming experience, and have you unpacked the Kindle firmware to take a look at what you'd need to do to change things?

Perhaps it is even possible the current codebase already locks things into place as-is.

It seems to me as though you may be merely assuming things simply because you want them to be true...

To mess this up would take a very poor programmer indeed...

And please stop underestimating human ingenuity.

[JSWolf]

When you have a font size change, it's just a number. That's all it is. The number gets passed along to tell the system what size to make the font. It should be trivial to allow a larger selection of numbers to be passed along to the system to get a different font size.

What would be perfect is to have buttons labeled + and - that also shows the number. And also a button to go to the default number. And if you hit the number, allow you to type in the number you want. Then all that happens is this number gets passed along to the system to get the font size and done. The only difference between this and what Kindles/Sony Readers/nooks have now is it's a different interface.

Currently, the best Readers are Kobo Readers for font size changes. But it could still be better as mentioned above.

[eschwartz]

Yeah, and the interface is where the hard part comes in.

[twowheels]

Originally Posted by Rizla

The code is already in place to 1) increase / decrease font size, and 2) the same for margins. Adding an extra in-between font size and margin setting to an existing series of cases barely complicates code because the framework is already there. Adding extra font sizes is trivial. To mess this up would take a very poor programmer indeed...

That's not what I was addressing with my comments, but that said, the previous programmers could have hard-coded assumptions about the sizes all over the place, making changes very difficult indeed. It is possible, and I've seen such bad code before.

Edit:

For example... if they passed around the values as ordinals indicating which one, rather than the actual size, such as "font_size = 3, margin = 1", then adding a new value would be very hard as the code everywhere (and it could be logic that is poorly duplicated in many places) expects the value to be one of 0...9 for font and 0..2 for margin (assuming 10 font sizes and 3 margin sizes -- I don't remember exactly how many there are, I don't look at the dialog very often). Adding intermediate sizes could be very difficult.

Given how the dialog is laid out, and how the original requirements were probably specified to match the current dialog I would not be the least bit surprised if the first developer coded it exactly like that as I've seen many people do that. As a system architect and lead developer, getting developers (even some with many many years of experience) to think of the problem in generic terms that makes for easily extensible programs in the future is something that drives me to near insanity.

[twowheels]

Originally Posted by eschwartz

It seems to me as though you may be merely assuming things simply because you want them to be true...


And please stop underestimating human ingenuity.

One of my biggest failures at work is assuming that something will be easy because it "should be". I have found, repeatedly, that it's better to assume that if something CAN be done in an overcomplicated way, it will be.

An example... a piece of code that I specified was for a temporary solution that did not need any future-proofing (it was to support a piece of legacy hardware that hadn't changed in 15 years and was being phased out) and that I felt (as one of the system designers) should have taken 25-50 lines of code to write, and a few hours... after 3 hours of meetings trying to explain it to the developer (with the title 'senior'), and three attempts on his part, it finally came back a week later as a 700+ line source file, with a 400+ line config file. I was in complete shock.

Another senior developer with many years of experience writing video games once "fixed" a bug in a medical device where measurements were off by 4. I later found a '+ 4' hidden in the code. He was fired the same day. This is the same guy who'd spent nearly 6 months working on a feature that was buggy as could be and after many months of testing cycles with bug after bug and many people trying to figure out his 50 boolean flags that were trying to keep track of all of the special cases and past history of what had happened to make it do the right thing next, and other developers trying to help fix the bugs by adding even more flags... I finally got permission to rewrite it myself and did it in less than a day, with ZERO flags to keep track (just one state variable and a simple state chart) and it had ONE tiny little bug that was found the next day where I went "doh!" and fixed it in less than 30 seconds. No bugs were ever found in that code after that.

[Demingy]

Originally Posted by Rizla

They are quite different things. One exists, the other doesn't.



Side-loaders (like USB-card users) are a fringe minority of users. If Amazon can find a cheap alternative to charge, it will make no sense to retain the port.

I'm not sure how minority side-loaders are, but I can say that loss of the port wouldn't make a difference to me as far as side-loading goes because I already do mine purely wirelessly.

[JSWolf]

Originally Posted by eschwartz

Yeah, and the interface is where the hard part comes in.

If Amazon wanted to add in another font size step between each of the existing font size changes, that would be very easy. It's just add in another AA button between each of the existing buttons. Passing the number to the system is already in place. No problem there.

The way I described things would be more difficult to implement. But once done, there would never be any need for such to be done again.

[jbjb]

Originally Posted by JSWolf

When you have a font size change, it's just a number. That's all it is. The number gets passed along to tell the system what size to make the font. It should be trivial to allow a larger selection of numbers to be passed along to the system to get a different font size.

Do you actually know that is the case, or are you just assuming it?

There are many feasible implementations which would make it harder to add intermediate sizes. For example, the font selection code could return an enumeration from a fixed set, where the actual numerical values of that enumeration are arbitrary - adding a new value to that set would involve adding code at every place where that enumeration was used. Or, it could return an index into an array of font descriptors, and other code may make assumptions about the size of that array. Or, any of many other ways. Even if it does return a number which maps directly to the numerical size of the font, it could be that the units of that number are such that it doesn't have the resolution to represent intermediate sizes.

I'm not saying it isn't as you describe, just that unless you have actual inside knowledge of the code, you can't assume that it is - there are many other ways of doing it.

/JB

[eschwartz]

... and like twowheels already said, two and three posts ago, JSWolf.

[Rizla]

Originally Posted by eschwartz

Yeah, and the interface is where the hard part comes in.

I see what you mean. Amazon has visually "hard-coded" the font sizes choice in the UI. It's an ugly implementation that makes expandability problematic. Amazon would have to alter the UI significantly to add a gradation, or remove one of the other ones. Ick. Poor design, that. Ick. It really is ugly from a design point of view.

[Rizla]

Originally Posted by Demingy

I'm not sure how minority side-loaders are, but I can say that loss of the port wouldn't make a difference to me as far as side-loading goes because I already do mine purely wirelessly.

As you say, personal documents can be "side-loaded" via whispersync. As such, the USB port is only necessary for charging

[Rizla]

Originally Posted by JSWolf

If Amazon wanted to add in another font size step between each of the existing font size changes, that would be very easy. It's just add in another AA button between each of the existing buttons. Passing the number to the system is already in place. No problem there.

The way I described things would be more difficult to implement. But once done, there would never be any need for such to be done again.

You're right about the code. All that is necessary is to add an extra number(s) in the existing font-change UI option. As you say, that number will be passed along to the existing font rendering process.

The problem lies in the lack of space available to insert another AA in the font-choice UI. They could fit an extra one in there, but it would be tight and ugly. Alternatively they could just put a big or small 'A' instead of both. Ick. The whole thing is horrible. They should just change it to an increment and decrement "button." It seems it's too much work for them.

Maybe Amazon is waiting to overhaul its aging and increasingly lack-luster UI. Presumably they'll introduce better font gradation at that time. For now, they appear to have other priorities.