Scribe's Annoying, Clumsy, and Completely Unnecessary Note Toolbar

[tomsem]

Making it even shorter:

For the Note editor, 2 changes should be made:

* When Closing an empty Note, just remove the Note object without a confirm dialog. No user data is at stake.

* Add a ‘Close without saving changes’ option to the Note editor menu, so the user can signal this intent directly. Without this, Close saves the changes and user has to try manually un-doing them. It was possible before with Cancel button but that’s gone.

For Place Note toolbar action:

* Tap to place a note should ignore Tap if the location has no target object (word, table, image), and cancel Place note mode. With the current behavior, tapping in a whitespace area randomly choose a target and opens Note editor, when user intent about location is ambiguous.

* Selection of target needs to be a little fuzzier. Even tapping very close to a word can result in some other target getting selected.

Feature request:

* Enable Pen annotations and placing of notes on fixed layout books (comic books, etc)

[j.p.s]

^
Is that a different toolbar than the one discussed below that can be hidden?

Originally Posted by sanch

The hand icon overlaps, but I put it on the right side and at -75 it’s an acceptable trade-off.

Originally Posted by j.p.s

What is the hand icon for, and is it possible to hide it?

Originally Posted by sanch

Good call out here— I just looked it up in the manual, and it is possible to hide it. Now I feel silly for not having looked it up earlier.
It’s the writing toolbar for annotating.

[cerem0ny]

Originally Posted by tomsem

If you have a Scribe, you will know what I'm talking about: 'What is that annoying thing in the margin up there?' (see attached).

As a former SDET (with some experience with validating UX issues), I took a deeper dive.

TL;DR
They should revert this feature ASAP!!

---

It seems they wanted to streamline the process of placing a note, by bypassing the options that come up with Long Press. How to signal user intent to Place a Note at a given location?

Long Press is 'taken', and Tap's job is to monitor the tap zones, and the highlights, Note icons or hyperlinks that might be there.

Hence the Brilliant Idea: a Toolbar!! Something to tap on! The Pen toolbars are awesome and fun! Let's do another one! Toolbars Rule!!

It's not too soon to point out that this is already not any quicker than Long Press and tapping the Note button. It also involves two touch actions on two locations which could be several inches apart, requiring quite a bit of hand-eye coordination compared to the tried and true method we've used all these years, where the two locations are less than an inch apart.

But the badness doesn't stop there.

Look how complicated the toolbar is: it Expands to show 4 Buttons: Minimize, Long Press (?), Place Note, and Menu.

It's not too soon to point out that only one Button is really needed: a toggle Button with Note icon with two states: Not Ready to Place, and Ready To Place.

But we're not done: Menu has only one option, Move To Right. Why not replace with a Move to right side icon? And when it's on the right side a Move to Left side icon. Probably doesn't even need localization.

And why do we need a Long Press button at all? We don't: Long Press always takes precedence. It's just a complicated way to cancel Place Note mode.

What if I want to do a series of Place Notes? There's no efficiency to be gained: it's always at least 2 Taps because Tap Mode doesn't stick (good reasons for that)

With Place Mode in effect you can do arbitrarily number of non-Tap touch gestures. Then maybe you casually tap the right side, expecting to turn the page. Oops! The Note dialog launches. Conversely, you go to tap on a word to place a note and miss by a little bit. Oops! the page turned.

If you prefer to keep the toolbar minimized of course it adds 2 taps every time you would otherwise use Place Note. But it is still distracting, and there's no option to hide it.

I'm confident the issues with Print Replica support will be solved soon (the under the hood devs tend to be better than the more effete UI devs), and it will be awesome indeed!

But with this? Somebody actually thought this feature addressed a usability issue, when the reverse is true. Unless they got fired, they probably have not changed their mind (if you can call it that). What's it gonna take to get this pulled, or at least add some option to hide it.

Enough badness for you? No?

Turns out the redesigned Notes dialog is another textbook UI anti pattern example. But I'll save that for another post. Lunch time!

But to put it all in perspective, I remind you that we are all going to die.

Erm, you do realise you can hide the toolbar if you so wish?

[tomsem]

Originally Posted by cerem0ny

Erm, you do realise you can hide the toolbar if you so wish?

Thanks I didn't notice it in the menu up there.

I've never bothered reading the HTML manual for any Kindle, my bad.

But at least it now won't keep me awake at night.

[tomsem]

Originally Posted by j.p.s

^
Is that a different toolbar than the one discussed below that can be hidden?

So it's the same toolbar but in context of reading a document, not marking up an imported PDF.

In the reading context it has only the ability to place a note, and it has all of the unpleasant behaviors I note. And it's not really adding anything useful in the 'reading' context.

The reason it is there, I assume is for 'consistency' between the various contexts (reading, annotating imported PDF, drawing stuff in Notebook). But I haven't spent any time there since I got this a few days ago.

[Pjama]

It’s annoying having to hide the writing toolbar whenever I read a book. I think it should default to hidden when reading a book. Considering when you go to make a note in a book it asks you to select either typing or writing, what's the point in having the toolbar there in any case? It is a blot on the landscape, like having a large squashed fly in the margin of your book. Impossible to ignore.

It's not a big deal to hide it, but how many average users are even going to work out how to hide it and just put up with it?

And, a general point about ‘Accessibility' on any device, for the elderly (disclaimer, I’m talking about non-tech savvy elderly people, such as my mother, mother-in-law etc.), they do not see or understand three tiny dots as being a menu to press. I can’t imagine how the visually impaired cope with this type of menu system either. The very opposite of accessible.

I actually think the menus on a kindle should be much more text-driven, and much less like a mobile phone, for this reason.

[j.p.s]

In my opinion the kindle UI has been getting increasingly clumsy and annoying for years.

[tomsem]

In my OP, I mentioned issues with Note dialog. This is what I was referring to:

In the interest of making a nice, rectangular space for Pen annotations (it's already much larger than the Note dialog on other Kindles), the Delete|Cancel|Save buttons are no longer there. It does look nice, but it's caused some issues.

Delete has been moved to a menu (which makes it harder to access), and the only way to exit the dialog is X.

If you open Note dialog and change decide you don't want to add anything, there's no way to signal intent to Cancel. When you Tap X, then you get nagged about 'hey you can't create an empty note' and have to choose Delete or Cancel (to go back to the Dialog). Awkward and annoying since the UI geniuses didn't let me Cancel explicitly.

And better than nagging would be to just remove the Note that cannot exist without any comment. I don't think anyone intends to save an empty note (what would be the use case), you can assume this is a Cancel.

Similarly if you start to enter a Note and want to Cancel, you're in a bad place: X saves what you would prefer to not Save, forcing you to Delete the note (and often a highlight) to clean its up. The only way to Delete is to open Note dialog, tap the menu icon and select Delete. Again because no explicit Cancel is available. Or you can delete the note or scribble you created and suffer the 'you can't save empty Note' nonsense. It's probably the least pain route but it's not good to punish user because they can't tell you what they want to do.

There is an asterisk next to Handwritten Note and Text Note labels, so you have at least some feedback that something has changed.

All because they have violated a very fundamental UI best practice: don't have a button that does more than one thing.

If they fix the nag on empty content (a no brainer really), then they could preserve the look and feel by adding an additional menu item for 'Cancel changes and exit'. And then X would do the expected every time (Save changes, or Close when no changes are made).

[tomsem]

While reading mode doesn't need the Writing toolbar in reading mode, clearly they decided it's more important to have Consistency. So it's visible by default. Maybe the first time you open a book, they could have a little info box that tells you that you can hide it, and where to find this option.

And I've noticed another difference between adding Note with Tap vs using Long press: Long press doesn't do anything unless there's some object to tap on (a word or image or table). But Tap just randomly chooses a nearby target instead of doing nothing. It would probably be better if it also did nothing, and cancelled Place note mode, since the user has failed to identify a target for the Note. And with reflowable content, it won't do to allow Notes in white space, since it's not clear how you'd create a reference that would preserve that location (reflow the doc and it could wind up on the other side of the page etc.

Currently the imported, converted PDF documents don't have any targets (i.e. words) to attach Note to because of Scribe's failure to read in the text layer (when it has one). So you can place a Note anywhere. Presumably when that's fixed, you'll again be able to Long press to select a word as target, and it'll figure out when initiating Note from the toolbar, Tap handler will figure out whether you tapped a word and snap the icon to the appropriate place, or if not assume you want to anchor it to the coordinate you tapped (on top of an image or in white space).

[Pjama]

It would truly be awesome if Amazon were to use developers that have actually used a Kindle before, or even who like to read! So annoying when the most basic things have been messed up.

I do love my Scribe, though, it is wonderful to read on, and to do puzzles on, and these are minor niggles (for me). I was surprised and quite sad to see a long-term poster on a different thread call Scribe buyers stupid. I don't feel we are stupid for buying this device.

[tomsem]

Originally Posted by Pjama

It would truly be awesome if Amazon were to use developers that have actually used a Kindle before, or even who like to read! So annoying when the most basic things have been messed up.

I do love my Scribe, though, it is wonderful to read on, and to do puzzles on, and these are minor niggles (for me). I was surprised and quite sad to see a long-term poster on a different thread call Scribe buyers stupid. I don't feel we are stupid for buying this device.

One of Amazon's credos is supposed to be to eat their own dog food, but in this case I would infer it was a very small circle of people doing that (if for no other reason than the devices aren't being produced at high volume and are costly), and that risks group think.

The remedy is to recruit Amazon people outside their own team to help out, and have other perspectives. As long as those people are sworn to secrecy and don't open carry pre-release devices around the campus or in public, it would be valuable.

With pre-release updates, they could probably open it up to any Amazon employee with a Kindle. Just make them sign something and reward them somehow for finding bugs.

Of course maybe they are doing all of these things and are just 'stupid'.

[jhowell]

I suspect that corporate interest is low, budgets have been slashed, and this was the best they could do with the resources at hand.

[tomsem]

Originally Posted by jhowell

I suspect that corporate interest is low, budgets have been slashed, and this was the best they could do with the resources at hand.

This was a far more ambitious release than normal. It's a massive update to personal documents service, with completely new use cases (annotation workflow and notebook), on top of new hardware. New platforms, essentially. It wasn't that long ago that it seemed Kindle was on life support.

Now I'm wondering: what got into them?

They surely had more budget but it's a lot more work than just another new Kindle, it's building out these new platforms and exploring new use cases. Scribe is just the first step.

So it is part of the plan to get this in people's hands and get feedback, rather than build out features nobody will use.

Internally it seems they review Word documents and Microsoft is across the street more or less, so that's why that is a focus. But they can't ignore PDF as that's widely used elsewhere. So that will develop more slowly I think.

Ultimately I think the goal is to export a PDF that looks like the one that came in, with the annotations appropriately PDF standard. Probably they're working with a partner on that (FoxIt or Adobe) since it's not a competency they really need in-house any more than they need Word developers.

And Print Replica is completely adequate as a lightweight proxy for PDF. And they'll be full citizens as personal documents (reading position and markup synced), similar feature set on iOS and Android eventually.

It's unfinished but I like where it is headed.

I could be dreaming though.

[talaivan]

Originally Posted by tomsem

Currently the imported, converted PDF documents don't have any targets (i.e. words) to attach Note to because of Scribe's failure to read in the text layer (when it has one)..

I guess that's why the text of imported pdf's is fuzzy. Much better on the Sage. Amazon, please get rid of your software developers and hire a competent start-up to start all over building your software. You can use what you have until they come up with something better, which shouldn't take too long. Really, the software on the Scribe, which is a machine with enormous potential, is atrocious -- no excuse for it.

[tomsem]

Originally Posted by talaivan

I guess that's why the text of imported pdf's is fuzzy. Much better on the Sage. Amazon, please get rid of your software developers and hire a competent start-up to start all over building your software. You can use what you have until they come up with something better, which shouldn't take too long. Really, the software on the Scribe, which is a machine with enormous potential, is atrocious -- no excuse for it.

It actually looks fine. If the PDF is generated on a computer (as opposed to scanned in with some fixed resolution), it imports in at a resolution that remains sharp at the highest zoom Scribe allows (which seems about 4x).

It's using the same format ('Print Replica') used for many textbooks sold in Kindle Store. The iOS app lets you zoom in even further, and it remains sharp to that zoom level.

If the text isn't sharp it is because the source PDF wasn't sharp (most likely scanned at a resolution that doesn't look good when zoomed in on the Scribe).

Amazon takes the incoming PDF and creates a raster images for each page, at an appropriate resolution for the target device. This raster image is the only thing that gets rendered for display. The text is never rendered, it's just string variables in memory that are associated with a rectangle on the display.

Where we have talked here about 'text layer is not getting read in', it's a metaphor for 'the area of memory which maps text to display coordinates isn't getting populated properly when file is read in'. Or it could be an issue with retrieving data from that area. But when it is fixed it won't look any different.

PDFs are more complex, and require more computation to render them. It requires an entirely separate rendering engine. Some PDFs will even be impossible to render with an eReader and its intentionally limited resources. It's never been a great fit for eReaders. One advantage is that fonts and vector graphics scale up smoothly, but that doesn't confer any advantages on an eReader. It's so you can print large signs and posters without pixelation.

Kobo is stuck with PDF because they do not have the engineering resources to do more than build on top of a third party engine (Adobe). The engine is as optimized as it can be, but it's going to have limits. If all you are doing is markup of small documents, it is probably fine, and well suited for that use case.

But Print Replica is far more lightweight, and won't have non-linear performance issues. It's a good approach for fixed layout content, particularly for Scribe, where there's priority on reducing system resource usage as much as possible.

And my current belief is that Amazon wants Scribe to do more than mark up converted PDF files: they want to give Scribe access to content available in Print Replica format in the Kindle Store (textbooks etc), which should find a market for Scribe with students at all levels, especially with the Notebook features built in.