Firmware Update firmware update 5.8.5 out(improves manga reading)

[NullNix]

Originally Posted by Atunah

I don't read Manga, not really sure what that is, I assume they are comic books? So I won't notice anything on that front as I don't read comic books.

They are comic books in much the same way as bandes dessineés are comic books: i.e. a widely-read publishing phenomenon which happens to look like comic books do. (A better comparison would be to graphic novels, which were an explicit attempt to import the French/Belgian bande dessinée to English-language media.)

They sell like wildfire in Japan, to pretty much all age ranges.

[Atunah]

Originally Posted by NullNix

They are comic books in much the same way as bandes dessineés are comic books: i.e. a widely-read publishing phenomenon which happens to look like comic books do. (A better comparison would be to graphic novels, which were an explicit attempt to import the French/Belgian bande dessinée to English-language media.)

They sell like wildfire in Japan, to pretty much all age ranges.

I don't think I understood half of what you just said.

Its probably all the same to me, comics. I used to read Asterix and Obelix when I was a kid, loved those. And Donald Duck. But nothing as a adult. Not making any judgement here, just saying that I won't ever see this new feature in the update as I don't read it.

[rashkae]

This is the first firware I have been unable to crash by browsing/flipping through books in Cover (Grid), a problem I've been able to reproduce with every device and every firmware since the first paperwhite.

Also, AZW3 sideloaded books don't get the new hold for fast page turn feature, but the page turns are noticeably faster. Also, the image pinch/zoom and pan is *ridiculously* faster. I haven't tested pdf rendering yet, but overall, this update is a *big* improvement for graphic heavy books, even in the old format.

[tomsem]

Originally Posted by Axanar

The main issue here is "not" the "X". The issue is that most dialogs (let's call them window) inside the Kindle firmware are inconsistent in their visual appearance.
...

I find this highly distracting.

I understand your point; I noticed this myself and did not mention it in interest of concision. It doesn't bother me much, and even that annoyance will diminish with familiarity. Perhaps it will be so with you as well.

But I suspect these inconsistencies have existed for a long time, and are a low priority item with the development team. As you state, that may due to turnover and people moving between projects, focused only on their part of the 'elephant', and limiting testing to the specific features that are being delivered. Not to excuse them for not having more attention to detail, but it is unfortunately not a rare phenomenon in software development, as there are always trade offs.

It's a much worse situation with the Fire, IMO. It's as if everybody's moved on to Alexa platform, Fire TV etc. Even fundamental things like sync, immersion reading, collections management are broken on mine and that is more than an annoyance: it makes it nearly unusable.

[tomsem]

Originally Posted by Atunah

I don't read Manga, not really sure what that is, I assume they are comic books? So I won't notice anything on that front as I don't read comic books.

Technically, the difference is that comic books are read from front to back, and panels are read left to right, while manga (following Japanese convention) are read from what Westerners might call back to front, reading panels progress right to left. In physical form, manga pages tend to be smaller in dimension (e.g. 5 x 7.5 inches vs 6.5 x 10 inches).

Manga genres are mostly distinct from those found in comic books, having originated in Japanese culture. But of course there is cross-pollination and experimentation.

I think the Kindle format used is the same, except that document properties are set to yield comic-book like navigation (panel navigation defined by author) or manga-like behavior (left tap or swipe right to advance to next page, 'virtual panel' navigation is 'S' rather than 'Z' pattern). And the 'fast page' navigation applies only to 'manga'.

[Axanar]

Originally Posted by tomsem

But I suspect these inconsistencies have existed for a long time, and are a low priority item with the development team. As you state, that may due to turnover and people moving between projects, focused only on their part of the 'elephant', and limiting testing to the specific features that are being delivered.

The issue is getting worse by each new version of the Kindle firmware and haven't existed in such a big way as for the 4.x.x firmwares with their old'ish look.

As you rightfully said "the development team". I bet they are a bunch of programmers spending their time hacking the things together. They most likely lack quality control and they most likely lack and coding and styling guide.

As a programmer myself (starting within the 80's), I can tell that you can get an idea of the code by looking at the GUI visuals. If the GUI looks like rats arse, then most likely the code itself is being treated the same way.

I even found more inconsistences within this Kindle firmware update:

1) Some window have the buttons (say "cancel" and "ok" as an example) tied at the bottom of the window. One button left, the other right. But some window have these two options applied on the bottom right. E.g. both buttons are aligned towards the bottom right of the window.

2) Open a book and go to the "go to" option (where you can chose the table of contents and page bookmarks). The entire window for this particular part still is the very old style one.

This issue is going through the entire Kindle firmware and gets worse by every new release of the firmware. In these times with high competition (e.g. Apple or Kobo), customers do look at these things. That's what you pay for at the end. Looking at the more expensive Kindle models - you - as customer have to make a decision whether the higher prices are justified if you get such a visual fragmented mess of GUI visuals back.

Now the good things:

1) The new Kindle firmware *is* indeed snappier and noticable faster!

2) The GUI revamp has benefits. For the "it looks cleaner" part of it or for the "it's fresher" part of it, this is true. Sadly their development team doesn't do it carefully enough and leave a lot of fragmentation withing the Kindle firmware (Fragmentation = different visuals of window. The password box looks like a clusterfuck now).

[jhowell]

The 5.8.5 kindle firmware has a change that affects cover thumbnails for personal documents. A book downloaded from Amazon or sideloaded that is marked as a personal document (cdetype=PDOC) will no longer accept a sideloaded cover thumbnail image and will only show a generic cover thumbnail with the book's title and author.

Books marked with cdetype=EBOK still support cover thumbnails. Also, personal documents that were transferred to the kindle prior to installation of this firmware version are unaffected.

I have been sending books acquired outside of Amazon to my Amazon account as personal documents. This allows the reading position to be synchronized when I switch between devices. Unfortunately my kindle shows only a generic cover thumbnail for these books. In the past I have been able to correct this using the ExtractCoverThumbs program, which creates and sideloads a real cover image thumbnail to the kindle. This will no longer be possible going forward since the sideloaded image is ignored by the 5.8.5 firmware for personal documents.

The same will be true for books sideloaded using calibre if they were marked as a personal documents during conversion. In that case the cover thumbnail that calibre transfers along with the book will be ignored.

ETA: Upon further checking I see that there is an exception that personal documents delivered in the old MOBI/AZW format (not KF8/AZW3) still have their cover thumbnails extracted from the book by the kindle firmware and so bypass the firmware change that I documented.

[Josieb1]

Originally Posted by jhowell

The 5.8.5 kindle firmware has a change that affects cover thumbnails for personal documents. A book downloaded from Amazon or sideloaded that is marked as a personal document (cdetype=PDOC) will no longer accept a sideloaded cover thumbnail image and will only show a generic cover thumbnail with the book's title and author.

Books marked with cdetype=EBOK still support cover thumbnails. Also, personal documents that were transferred to the kindle prior to installation of this firmware version are unaffected.

I have been sending books acquired outside of Amazon to my Amazon account as personal documents. This allows the reading position to be synchronized when I switch between devices. Unfortunately my kindle shows only a generic cover thumbnail for these books. In the past I have been able to correct this using the ExtractCoverThumbs program, which creates and sideloads a real cover image thumbnail to the kindle. This will no longer be possible going forward since the sideloaded image is ignored by the 5.8.5 firmware for personal documents.

The same will be true for books sideloaded using calibre if they were marked as a personal documents during conversion. In that case the cover thumbnail that calibre transfers along with the book will be ignored.

I am on 5.8.5 and my personal docs sent via Send To Kindle (originally mobi files) show the cover, exactly the same as it did before I upgraded.

Could that be because Send to Kindle converts and sends to the Kindle as AZW files? (That's written on the sending page of Send To Kindle)

[Josieb1]

Originally Posted by Axanar

I was one of the people who complained about the difficult readability of the system text. This was caused by Amazon changing the "bold'ish" shape of the fonts. this has been adressed by 5.7.x.

The capitalization was never questioned. At least not by me. The capitalization of dialog buttons isn't necessary because the dialog buttons already had "bigger" and "bolder" fonts. But even so, this can still be accepted.


The main issue here is "not" the "X". The issue is that most dialogs (let's call them window) inside the Kindle firmware are inconsistent in their visual appearance.

In case I explained myself not good enough (I am german). Let me try a different attempt of explaining it.

Right now the Kinde firmware (as of 5.8.5) has plenty of inconsistent windows and this is most likely an issue of lack of quality control and/or wrong people working at wrong parts of that firmware.

Right now we have windows (remember: dialogs) with buttons applied at the bottom that allows you to confirm or close the window. We have windows with said "X"'es at the top right (and badly laid out too) that allows you to close these windows. We have windows without "X"'es and/or confirmation buttons at the button, where you need to tab outside to close them.

These are by now 3 different visual appearances and 3 different ways of closing the window.

Example1:
Click on the Lens at the top (search). Look at the window there. The "X" is outside of said window. In former Kindle firmware versions, this window looked similar to other windows having the "X" inside a framed window.


Example2:
Go to Settings->Device Name->(Arrow to change the name)

You get a window with two *frameless* buttons at the bottom (besides the textfield to change the name of your device). One says "ABORT" the other says "SAVE" (Capital letters: or similar wording: I have my Kindle running in german language).

Now go to Settings->Social Networks->Facebook/Twitter

You get a window with two *framed* buttons at the bottom. The buttons are *first char capitalized* saying "Abort" and "Continue" (aha? not capitalized?).

This is inconsistent, compared to the other windows.

Example3:
Go to Settings->Device options->Device info. A window pops up showing an "X" at the top right and a *frameless* button on the bottom right saying "NEWS".

Now looking at Exampe 2 again. There was no "X" at the top right, instead there was an "ABORT" button at the bottom left.

Making two similar window look "inconsistent".

If you look around in the settings, then you may get more of these inconsistencies.

Example4:
Erasing WIFI-Passwords window. It has two frameless buttons at the bottom. One says "ABORT" the other "ERASE". Here you can not tab outside the window to close it.

They are playing with "windows" (the type of objects that catches the entire kindle screen with e.g. buttons at the bottom). They deal with "modal" dialogs (the ones that doesn't allow tabing outside to close the window), they are dealing with other types of dialogs having an "X" inside etc.

Even different wording for same "effects".

I find this highly distracting.

I, at least for the next six weeks, test software for a major organisation. I worked through Examples 1-3. IF they had been spotted in testing, and that would only be if the same team or testers tested all three examples, or if the results didn't match the test scripts or documentation (not an automatic given here) then they would no doubt be marked as cosmetic and made a low priority, or even postponed to fix at a later date.

I get that it bugs you but the functionality works, it's just cosmetically they don't match.

NB: I said six weeks as I'm being made redundant. (Yes I'm happy)

[Axanar]

Originally Posted by Josieb1

I, at least for the next six weeks, test software for a major organisation. I worked through Examples 1-3. IF they had been spotted in testing, and that would only be if the same team or testers tested all three examples, or if the results didn't match the test scripts or documentation (not an automatic given here) then they would no doubt be marked as cosmetic and made a low priority, or even postponed to fix at a later date.

I get that it bugs you but the functionality works, it's just cosmetically they don't match.

NB: I said six weeks as I'm being made redundant. (Yes I'm happy)

Testing software is not the same as writing software "or" having some GUI style guides that prevents these things to happen in first place.

These are not just "cosmetical" issues as you say. They can already be a programmatically issue by using deprecated API calls or a mixture of older Toolkit libraries and new toolkit libraries or hardcoded window and GUI elements etc..

The problem starts at the beginning and not later on! If there are no GUI styleguides and no real quality assurances, then these problems inherit from version to version and will never be dealt with or get fixed.

Now you make these things "low priority"... Then the next Kindle firmware pops up and inherits new graphical glitches and issues... you mark them "low priority" again... Now you have the previous low priorities add up with the new low priorities and you end up in a graphical mess.

How many Dialogs and Windows do we have in the Kindle firmware ?

Let's pretend there are around 50 Dialogs and Windows at all.

Each Kindle firmware update isn't a full rewrite! They compile new updated libraries, use a new wayland display server, compile with compiler flags... Between Kindle firmware versions there is time enough to sort these things out. But things can only be sorted out if the problem case is being understood.

[Axanar]

Originally Posted by Josieb1

I get that it bugs you but the functionality works, it's just cosmetically they don't match.

I'd like to add a few sentences to my previous comment:

If you sell a car, then what's the first things you do ?

You wash, clean and polish the car - if necessary fix engine, scratches and bumps - to add some monetary value to it.

The basic functionality is to be expected like this:

It's a car... it drives... the customer expects it as functional feature of the car. Otherwise a normal customer wouldn't want to buy it at all. It's the polish that usually drives the "buy" or "no-buy".

But let's wait for the next Kindle firmware update. Maybe some concerns are being addressed till then. My hopes are, that the one or other Kindle developer keeps reading these pages and forward user concerns to the team.

Edit: Besides that, who says it's "low priority" ? The person who works in the quality area (or software texting area) usually works with the "quality handbooks" that usually are part of the contract with the customer who pays for the product.

We usually make an written offer to the customer. The customer either agrees on it or not. That offer usually contains the requirements (software requirements) that the customer wishes that the software should do and the quality it sould have (quality requirements). The quality requirements are not just software tests (press button A should do this and that but not this and that) but also the quality requirments for product documentation and the GUI itself.

You can even get raw sketches from the customer in how the window and GUI should look like. So saying "low priority" is just a matter of general agreement between customer and software company creating the product. Other customers may make it a "hgh priority" to have the GUI look consistent and not fragmented, to not confuse their user base.

[Josieb1]

Originally Posted by Axanar

I'd like to add a few sentences to my previous comment:

If you sell a car, then what's the first things you do ?

You wash, clean and polish the car - if necessary fix engine, scratches and bumps - to add some monetary value to it.

The basic functionality is to be expected like this:

It's a car... it drives... the customer expects it as functional feature of the car. Otherwise a normal customer wouldn't want to buy it at all. It's the polish that usually drives the "buy" or "no-buy".

But let's wait for the next Kindle firmware update. Maybe some concerns are being addressed till then. My hopes are, that the one or other Kindle developer keeps reading these pages and forward user concerns to the team.

Edit: Besides that, who says it's "low priority" ? The person who works in the quality area (or software texting area) usually works with the "quality handbooks" that usually are part of the contract with the customer who pays for the product.

We usually make an written offer to the customer. The customer either agrees on it or not. That offer usually contains the requirements (software requirements) that the customer wishes that the software should do and the quality it sould have (quality requirements). The quality requirements are not just software tests (press button A should do this and that but not this and that) but also the quality requirments for product documentation and the GUI itself.

You can even get raw sketches from the customer in how the window and GUI should look like. So saying "low priority" is just a matter of general agreement between customer and software company creating the product. Other customers may make it a "hgh priority" to have the GUI look consistent and not fragmented, to not confuse their user base.

I was just pointing out how it would be categorised in my company.

[Josieb1]

Anaxer, since you appear to be very upset by the update can I suggest you complain to Amazon.

[NullNix]

Originally Posted by Axanar

These are not just "cosmetical" issues as you say. They can already be a programmatically issue by using deprecated API calls or a mixture of older Toolkit libraries and new toolkit libraries or hardcoded window and GUI elements etc..

That is the Amazon Way. This is an e-reader with at least three complete ebook reader implementations in two languages (Java and C), with at least three GUI frameworks (in Java, JS and C)... it's a *mess*. If you want elegant, integrated software, don't go anywhere near Amazon. They've never worked that way.

Originally Posted by Axanar

Each Kindle firmware update isn't a full rewrite! They compile new updated libraries, use a new wayland display server

I'm reasonably sure the Kindle has used directfb and now X11 but never Wayland. Given their degree of dependence on a custom Awesome config that bubbles windows to different layers depending on their WM_TITLE, I'd suspect it'd be a big rewrite to move across to Wayland, too: they'd need a custom compositor at the very least.

(Also, frankly, Wayland isn't stable enough for a device that just has to work. Not yet.)

[Axanar]

Originally Posted by Josieb1

I was just pointing out how it would be categorised in my company.

Oh please don't get me wrong. I didn't want to invalidate your arguments. They are of course valid. I only wanted to add a different users perspective at it.

While we are at it. Look e.g. the Passwords entering dialog once you turn on your Kindle (or unfold the cover). It's still old compared to the new one within the settings (change or set password) dialog. The old one has still the borders around the keys (not to mention they changed the right padding without having any effect), while new one (within the settings) have a borderless numbering box at the bottom and an textfield at the top.

I mean it was Amazon who wanted to re-fresh their GUI. I wished they had done this throughly rather than the fragmented one what's given to their customers now. I as programmer (in fact: project leader and management) would have never ever given out a product in such an unfinished and unpolished way. Never ever!

Originally Posted by Josieb1

Anaxer, since you appear to be very upset by the update can I suggest you complain to Amazon.

Feel free. I for one wasn't able to pass their first-level customer support.

... and thank you.