Kindle Touch 3G Review

I purchased a Kindle Touch 3G, and I'm very happy with it.

Pros:

1. The touch screen is good, but not great. The instructions that came with the Kindle say to turn a page by touching the screen on the right hand side, but I found this unreliable. Often a touch doesn't register, and I'd need to touch several times in order to get a page turn. Swiping also turns the page, and I found this much more reliable. Once I started swiping to turn the page instead of touching, I found the Kindle much more enjoyable to use.
2. The E-Ink screen is very nice to read text on. It feels nice on the eyes, has good resolution, and being able to resize the text using a pinch action is very handy.
3. You don't need two hands to read like you do with a traditional book. You can easily, for example, sit and eat breakfast while turning the page occasionally by simply touching the screen.
4. Books are cheap compared to their physical instantiations, particularly since I live in New Zealand and books are expensive here in general.
5. You don't need to carry a large number of books around.
6. I don't mind having the "Special Offers", I don't find them intrusive, and it makes the Kindle cheaper.
7. I battery life is good, even when using the lighted cover, which draws power from the Kindle's battery. Usually I only need to charge my Kindle about once a month.
8. 3G is worth it, for me at least. I do a lot of traveling, so having 3G is really handy if I want to buy books while in a hotel. It means I don't need to try to get the WiFi to work. I have found it patchy though. For example I took my Kindle on my recent trip to Canada, and 3G connectivity didn't work in Vancouver Airport, but it did work in my hotel room in Toronto.
9. Amazon's "Get a book in under 60 seconds" is true; books download fast, even over 3G.

Cons:

1. Entering text on the touch screen isn't a great experience, and for shopping should really be considered a last resort when you don't have a computer with Internet available. Entering a passcode to unlock the Kindle is annoying too, you need to wait for the keypress to display before continuing, which makes using it laggy. Text input would be better on a Kindle with keyboard (I imagine, I don't own a Kindle with keyboard), but I think that since having a keyboard increases the Kindle's size significantly, I'm glad I purchased the Touch over the keyboarded Kindle. The Kindle Touch is smaller than the Kindle with keyboard, but has exactly the same size screen, and I don't use text input on my Kindle that often. I don't know what text input is like (or if it's even possible) on the entry level Kindle, but I imagine if you only want to buy books on your computer, then you could get by with the standard entry level Kindle.
2. Technical books don't layout very well, particularly the tables in them, and it seems some of the formatting information can be lost in the process of converting a book to Kindle format.
3. The range of available books is good, but not all books are available. The most popular books are usually available, but often some older or less common books aren't available. I expect this will improve over time.
4. It's heavier than most real books. I need two hands to hold it comfortably when reading.
5. I'm spending more money on books now...
6. Amazon recommends books that I might like to read. I've found a few books that I've enjoyed this way, but it makes me feel like I'm a consumer.
7. Region/Zone/country restrictions on content suck. Really.
8. I'm not interested in audio books, but they keep showing up in the search results. In particular they don't seem to be as region-restricted as text books. I understand that publishers make much more money with audible books, but I'm just not interested in buying them at this stage, and I wish they didn't show up.

I also bought a Kindle Touch Lighted Leather Cover. I'm satisfied with this too, though it was expensive. It does add a bit of bulk to the Kindle however, and it makes it slightly less comfortable to hold. However it feels sturdy, does a good job of protecting my Kindle, and looks stylish.  The light is quite good, and is more than adequate for reading with. The light draws power from the Kindle's battery, and it's a breeze to install your Kindle into the cover. I can't figure out how to get my Kindle out of the cover though!

I'm glad I bought the cover, it makes reading at night and on planes much better, it protects my Kindle, and it doesn't make holding the Kindle too uncomfortable.

In terms of deciding between buying the Kindle Touch, standard Kindle and Kindle with keyboard, it depends... I'm glad that I have the touch screen as a backup keyboard rather than having a physical keyboard which increases the size of my device. However I think you're not worried about the ease of purchasing content directly from your Kindle (i.e. you plan to mostly buy books using your computer via the Amazon.com website) then a standard Kindle would probably be adequate for you.

Overall, I'm happy with my purchase of the Kindle Touch 3G and the Lighted Leather Cover, and I recommend them.

Replacing Lenovo optical drive with second hard drive: The Lenovo adapter is disappointing

I recently ordered a Lenovo Serial ATA Hard Drive Bay Adapter III for my Lenovo T510 laptop. This can hold a hard drive, and replaces the DVD/CD-ROM drive in your laptop. This enables your laptop to run a second hard drive.

I've used my optical drive two, maybe three times since getting the laptop, so swapping it for another hard drive seems like a good trade for me.

The Lenovo drive bay itself works fine, but I'm still disappointed in Lenovo's product.

When installed, the drive bay looks like this:

Lenovo Serial ATA Hard Drive Bay Adapter installed in a Lenovo T510

The problem here is that there's a gap of approximately 3mm (~0.12 inches) between the top of the drive bay and the ceiling of the optical disk cavity. This means the drive bay can wobble vertically, so much so that I feel the need to tape it in place to stop it flopping around. This looks ridiculous.

Secondly, in order to install your hard drive inside the Lenovo drive bay, you need a hard drive cover. This is the metal cover that encases the hard drives shipping in Lenovo laptops. The covers normally have rubber bumpers/rails to stop the drive moving around. You need to take the bumpers off to install your drive into the hard drive bay.

The hard drive covers looks like this:

Lenovo hard drive cover

And with a hard drive in it, the hard drive cover looks like this:

Lenovo hard drive cover encasing a hard drive.

Note the screws. The drive bay has notches which the screws snap into, holding the drive securely inside the drive bay. Possibly the screws are the only important bit here; you probably don't actually need the drive cover to install the drive into the bay, just the screws since they're what hold the drive in place inside the drive bay.

The frustrating thing is that nothing on the Lenovo web site tells you that you need a drive cover to install a drive into the drive bay. My drive bay arrived and I had to loot my old laptop's drive cover in order to install a new drive into my current laptop.

And I also couldn't find the drive covers listed on Lenovo's web site. Presumably if you buy a laptop hard drive from Lenovo they come with this cover, and presumably Lenovo use this as a way to force you to buy all your laptop hard drives directly from Lenovo.

That's the sort of behaviour I'd expect from Apple, not Lenovo.

Thankfully Ann at IT was able to figure out how to order the drive covers separately. Thanks Ann!

Overall, the product was easy to install (once I had a drive cover) and works fine (apart from the wobble) but I'm still disappointed. Next time, I'll try one of newmodeus' Lenovo drive caddies:

Update 22 March 2015: This blog post now has a Russian translation;
Пост доступен на сайте softdroid.net: Замена оптического дисковода вторым жестким диском на Lenovo.

Improved key input in fullscreen mode plus pointer lock changes

I've landed bug 716107 which removes the "Press ESC to exit fullscreen" warning upon alphanumeric key input in fullscreen mode.

This will mean fullscreen web apps can use the full range of keys without having the annoying warning message pop up every time the user presses an alphanumeric key, i.e. the WASD keys!

In order to make change safe, we altered the security model a bit: now when entering fullscreen we explicitly ask the user to approve/deny entering fullscreen using a modal prompt, something like this:

Fullscreen approval prompt.

The prompt has a "remember decision for $domain.com" checkbox, so if the user trusts the domain they can avoid having to approve fullscreen every time. If the user opts to "remember" an allow fullscreen decision, we'll still show a "$domain.com entered fullscreen, press ESC to exit" warning when entering fullscreen, but it goes away after a few seconds.

Once the user has approved entering fullscreen, we won't show a warning upon alphanumeric key input.

I also landed bug 746885 which makes pointer lock wait until fullscreen has been approved using the new approval UI before granting the pointer lock request. It may take the user several seconds to approve fullscreen, so authors need to be aware that the "mozpointerlockchange" event may come in several seconds after the "mozfullscreenchange" event. Authors shouldn't assume the pointer is locked until after they've received a "mozpointerlockchange" event!

We also changed our spelling to use "fullscreen" rather than "full-screen", since everybody (including the fullscreen draft spec) was spelling it "fullscreen" anyway.

These changes are in Firefox Nightly builds from 9 May 2012 onwards, and will ship in Firefox 15, which is scheduled for release on 28 August 2012.

These changes should greatly improve the experience for HTML5 games using fullscreen and pointer lock!

When you encounter a bug, always file a bug

If you find a bug in Firefox, or any other software for that matter, please please please file a bug! It's completely possible that the developers simply aren't aware of the bug.

The developers may not be aware of the bug because they don't run on the same hardware, operating system, or environment as you, or they may not use the browser the same way as you do.

Even if we already have the bug on file and we mark your bug as a duplicate, at the very least this is allows us to get a coarse feel for how often the bug is encountered in the wild.

If the developers aren't aware of a bug, there's no way they can fix it! Please file bugs!

Changes to DOM full-screen API in Firefox 11

We've made some changes to how the HTML full-screen API exits full-screen mode in Firefox 11, which is scheduled to ship in March 2012. Previously Document.mozCancelFullScreen() would fully-exit full-screen and return the browser to "normal" mode. Starting in Firefox 11, Document.mozCancelFullScreen() will restore full-screen state to the element that was previously full-screen. If there is no previous full-screen element in either the document or a parent document (full-screen mode isn't restored to former full-screen elements in child documents), then the browser will "fully-exit full-screen", and return the browser to normal mode.

To see how this is useful, consider the case of a PowerPoint clone or presentation web app that wants to run full-screen. One way to implement such a web app would be to have a full-screen <div> element where the slides are shown. The developer may want to be able to switch full-screen mode seamlessly between the slide deck <div> and (say) a <video>, and then return to having the slide deck <div> as the full-screen element so that the user can carry on with the presentation. Before this change, if the <video> was in a cross-origin subdocument (like a YouTube embedded player in an <iframe>) returning full-screen mode to the slide deck <div> from the <video> was a two-step process; users would have to fully-exit full-screen, and re-request full-screen mode on the slide deck element. Now developers can simply call Document.mozCancelFullScreen() and seamlessly switch back. The browser won't drop out of full-screen mode during the transition.

Note that if users press the escape key they will always fully-exit full-screen, i.e. Firefox won't restore the previous full-screen element to full-screen state on escape key press. So to seamlessly restore full-screen to the previous full-screen element, developers must explicitly call Document.mozCancelFullScreen(), they can't rely on the user pressing the escape key.

We've also added webconsole logging upon full-screen request failures to Firefox 11, to make debugging denied full-screen requests easier.

Another change coming in Firefox 11 is we'll no longer deny full-screen requests in web pages which contain windowed plugins. Now we'll exit full-screen when a windowed plugin is focused instead (on Windows and Linux, MacOSX is unaffected).

Firefox's HTML full-screen API enabled in Nightly builds

A few days ago I enabled the HTML full-screen API in Firefox nightly builds. This enables developers to make an arbitrary HTML element "full-screen", hiding the browser's UI and stretching the element to encompass the entire screen. This will be particularly useful for HTML5 video and games.

If all goes well, this feature will ship in Firefox 10 at the end of January.

The API has changed slightly since I last blogged about it. The current API is Mozilla-specific, but is similar to the W3C's Fullscreen draft specification.

To enter full-screen mode, call the following method on the HTML Element you'd like to enter full-screen:

• void mozRequestFullScreen() : posts an asynchronous request to make the HTML element the full-screen element. If the request is granted, some time later a bubbling "mozfullscreenchange" event is dispatched to the element which requested full-screen. If the request is denied, a "mozfullscreenerror" event is dispatched to the element's owning document. We only grant requests for full-screen when:
• mozRequestFullScreen() is called in a user-generated event handler, e.g. a mouse click handler, and
• the requesting element is in its document, and
• there are no windowed plugins present in any document/iframe in the current page, and
• all iframes containing the requesting element (if any) have the mozallowfullscreen attribute.

We added the following method and attributes to HTML Document:

• void mozCancelFullScreen() : exits the document from full-screen mode. This dispatches a "mozfullscreenchange" event to the document containing the (now former) full-screen element. Note that the "mozfullscreenchange" event which is dispatched when you enter full-screen is targeted at the full-screen element, so if you want to receive the "mozfullscreenchange" on both entering and exiting full-screen in the same listener you should add your listener to the document, rather than the full-screen element.
• readonly attribute boolean mozFullScreen : true when the document is in full-screen mode.
• readonly attribute Element mozFullScreenElement : reference to the current full-screen element.
• readonly attribute boolean mozFullScreenEnabled : returns true if calls to mozRequestFullScreen() would be granted in the current document. This returns false if there are any windowed plugins present in any document/iframe in the current page, or if any iframes containing this document don't have the mozallowfullscreen attribute present, or if the user has disabled the API by preference. If this returns false you may want to not show the user your enter-full-screen button in your page, since you know it won't work!

We also added the :-moz-full-screen css pseudo class, which applies to the full-screen element while in full-screen mode.

We added the mozallowfullscreen attribute to iframe elements. Without this, full-screen requests made by script in the iframe's content (i.e embedded ads, or a YouTube player in an iframe for that matter) will be denied.

While in full-screen mode, the user can press the ESC key (or F11) to exit. Alpha-numeric keyboard input while in full-screen mode causes a warning message to pop-up to guard against phishing attacks. The only key input which doesn't cause the warning message to pop up are: left, right, up, down, space, shift, control, alt, page up, page down, end, home, tab, and meta.

Navigating, changing tab, changing app (ALT+TAB) while in full-screen mode will cause full-screen mode to exit.

Here's about a simple example, which will work in current Firefox nightly builds:

(Press ESC to exit full-screen)

The code for that button's onclick handler is simply:
document.getElementById('bruce_video').mozRequestFullScreen();

How is Firefox's full-screen API different from Webkit/Chrome/Safari's full-screen API? Firefox's API adds a "width: 100%; height: 100%;" CSS rule to the element which requests full-screen, so that it's stretched to occupy the entire screen. Chrome's API does not do this, but instead it centers the full-screen element in the window and blacks-out the underlying webpage. So the full-screen element won't occupy the entire screen with Chrome's API unless you specify a "width: 100%; height: 100%;" rule yourself. Conversely if you want to vertically and horizontally center something while in full-screen with Firefox's API, you need to make the containing element of your desired centered element full-screen instead, and apply CSS rules to vertically and horizontally center the contained element.

For a cross-browser full-screen API example, see html5-demos.appspot.com's full-screen demo.

Edit: 11 Nov 2011, clarified Document.mozCancelFullScreen() and Document.mozFullScreenEnabled, fixed typos.

Mozilla full-screen API progress update

Update 10 November 2011: the full-screen API has been changed slightly and enabled in Firefox Nightly builds, see http://blog.pearce.org.nz/2011/11/firefoxs-html-full-screen-api-enabled.html for details.

I've been working on implementing Robert O'Callahan's HTML full-screen API proposal in Firefox (bug 545812). Support for the base API has landed, disabled by default, in Firefox nightly builds. To enable the full-screen API, set the pref full-screen-api.enabled to true.

We have implemented a general purpose full-screen API which can make any HTML element the full-screen element (it seems WebKit based browsers' full-screen API allow only making <video> elements full-screen).

This feature makes the following API changes to HTML Element:

1. void mozRequestFullScreen() : makes an HTML element the full-screen element. Causes browser chrome to hide, and expands the element to encompass the entire screen. Upon success, this dispatches a "mozfullscreenchange" event to the requesting full-screen element, or the element's owner document if the element is not in a document. We only grant requests for full-screen when running in user-generated event handlers, e.g. a mouse click handler.

This feature makes the following API changes to HTML Document:

1. void mozCancelFullScreen() : exits the document from full-screen mode.
2. readonly attribute mozFullScreen : true when the document is in full-screen mode.
3. readonly attribute mozFullScreenElement : reference to the current full-screen element, if it's in the current document.

This feature adds the :-moz-full-screen css pseudo class, which applies to the full-screen element while in full-screen mode.

For a request for full-screen to be granted in content inside an iframe, the containing iframe needs to have the mozallowfullscreen attribute present. This is a boolean attribute, so the attribute only needs to be present, it doesn't matter what value it's set to.

Keyboard input is restricted in full-screen mode. When alpha-numeric key input occurs in full-screen mode, full-screen mode immediately exits. This is to help protect against phishing attacks.

We also plan to deny requests for full-screen mode when windowed plugins are present (since we can't easily monitor key events to windowed plugins on non-MacOSX platforms). We will exit full-screen mode when a windowed plugin is added to a document as well. I have a patch for this, but its dependencies haven't landed yet.

Work remaining to be done before this can be enabled:

1. Adding a warning message when we enter DOM full-screen mode (on desktop Firefox, and on Fennec too).
2. Making the full-screen API work in multi-process Firefox/Fennec (bug 684620). This requires a way of getting the PBrowserParent from C++ in the chrome process to be implemented, there's not a way to do that yet unfortunately.
3. Make change/open tab cause full-screen mode to exit (bug 685402).
4. A security review must be completed, and concerns raised there must be addressed. This could involve changing the API.

We also want a clearer transition effect when entering full-screen, to somehow show the full-screen element "stretching out" to encompass the screen.

You can test out our work-in-progress full-screen implementation, by grabbing the latest Firefox nightly build, setting the pref full-screen-api.enabled to true, and pointing your browser at my not-very-exciting full-screen API demo page.