reading » Always Where

Ebooks: Soon, very soon!

Another ebook linkfest:

TeleRead, which I’ve just subscribed to, has a bunch of interesting content surrounding the topic of ebooks.
A first look at the Irex Iliad
Answers to readers’ questions about the Iliad

Contrary to some rumourmilling sites, it looks like the powerhog on the Iliad is the WiFi; when it isn’t used, it has something approaching a 10,000 page-turn battery life. At somewhere between 400 and 650 Euros (rumourmill prices) it won’t be cheap; however, I downloaded 50 articles about architectures and languages for robotic control. It would be amazing to be able to sync those to an ebook reader and start reading, instead of printing, annotating, and then transcribing notes elsewhere.

Unrelated were some pointers to a $150 Linux-based PC produced by YellowSheepRiver. Cute.

The Iliad

What a wonderful name! Sony just never seems to get things right with marketing and branding. Between the death of the minidisc as a viable digital format for music, and it’s complete failure to capture the MP3 market, they stand to miss out on the ebook market as well, just for lack of features and poor naming. (“Reader”? How generic can you get?)

A friend in Germany pointed me at the iRex Iliad. In terms of features, it seems to have several key advantages over the Sony Reader:

Feature	Sony Reader	iRex Iliad
Read PDFs	Yes	Yes
Play MP3s	Yes	Yes
Memory	Memory Stick, SD	Internal¹, CF, SD, USB keydisk²
Network		10/100Mb Ethernet, 802.11b WiFi
Battery Life (reading)	7,500 page turns	20-30 hours
Dimensions	176 x 124 x 14 mm, 250g	155x216x16 mm, 350g
Resolution	6 inch (diagonal), 800×600 pixels, 4 gray levels,	8.1 inch (diagonal), 1024×768 pixels, 16 gray levels
Input	None	Touch (Stylus)

Notes

¹ There are approximately 200MB of unused, on-board memory, but that’s used for font installation as well.
² The USB keydisk is an amazing feature; it apparently can act as a USB host, so I can plug any keydisk in, and read files off of it. If I was able to transfer files from the USB keydrive onto a CF/SD card as well, that would be cool. But either way… just being able to plug in a USB keydrive as external storage is some smart thinking.

Comments

All told, the Iliad looks like a much nicer product.

[Size] It is significantly larger than the Sony; it is just about the size of a printed page. For a device that you read on, that matters a lot.
[Input] The Sony has no input on the device; it looks like I can scribble on PDFs using the Iliad. This is critical as well; although I am not terribly concerned with being able to “write”, per se, I do want the ability to underline and otherwise mark critical sections of text. If the handwriting recognition is good enough (or I can “zoom in” to create hi-res handwriting), then this would be an amazing tool for grading documents of all kinds.
[Battery] I can’t tell, but it looks like the battery on the Iliad isn’t as good as the Sony. This is probably due to the runtime on the device remaining active for handling input, etc. Ideally, they ship the device with the ability to lock it into a low-power mode, where all I do is read and turn pages. That way, I can either run in an “interactive” mode, or I can just read text.

Those are the features, in order, that matter most to me. For that reason, I’m eager to hear more about the Iliad, and hope that its April release isn’t a vaporware target. Waiting a bit (but not forever) for a device that’s almost the size of a printed page (vs. the size of a paperback) is absolutely worth it—since the display technology on both is practically identical (both use eInk technology).

Must… wait…

Why eBooks will be more amazing than iPods

The killer app is content.

We’ve known this for some time; people don’t buy devices, they buy devices that allow them to access content. In the case of the iPod, it is music. In the case of the computer, it is applications. Phones? The words of others—live, realtime, anywhere. The Internet itself is also a massive source of content, and many devices have been repurposed to allow access to that content; PDAs and phones finally have processors and displays that allow for (reasonably) effective access to the ‘net.

The iPod is probably the most powerful of these devices because of its simplicity. Music—rhythm and pitch—have been fundamental to human culture since the beginning of time. Giving people the ability to carry thousands upon thousands of songs with them anywhere is an incredibly powerful thing. eBooks will be no different.

The iPod of eBooks is coming. Sony will, no doubt, screw it up, but we’ll get there, in time. A year ago, they released the Libre, an e-ink based eBook. What is e-ink? It’s a display technology that doesn’t require power to hold state. So, the Libre’s battery life is measured in page turns—or, screen refreshes, if you prefer. Now, the first version of the Libre was broken: it couldn’t handle content in PDF (or any other ubiquitous format, like plain text), and it came encumbered with DRM. As if I want to buy books that will expire.

If Sony actually releases a new version of the Libre unto the world, and if they think for just a moment, they could take the world by storm. If the device can display unencumbered (DRM-free) PDFs and plain text, if it has an integrated MP3 player, and it is priced right, the Sony Libre will become not the must-have gadget, or must-have toy, but must-have tool for a literate society.

Consider what will happen. First of all, I can begin collecting all my favorite books in PDF (if the publishers ever get their heads out of their asses and sell them to me, DRM-free, as PDF downloads); now, I can pick up any book I’ve ever purchased, any time, and read it. I can start collecting papers pertinent to my work, and keep them with me, all the time. I already have thousands of papers related to my dissertation work on my laptop, but that’s a horrible place to try and read a paper—primarily because my laptop wasn’t designed for reading. This, though, is just the start.

Weblogs will render eBook friendly streams, into either plain text or directly into prettily typeset PDF. I’ll download eBook content from weblogs as readily as I download podcasts for my iPod… but moreso. Why? Partially because I ran my iPod Shuffle through the wash, but more importantly because I can read far faster than I can listen. eBook content takes up so little space—it costs me nothing to keep it, accessible anywhere, anytime, on my Libre. Micropayment infrastructures like BitPass will matter all the more, because now I’ll be able to subscribe to the Plain Dealer, in England, for cheap—and download it to my Libre for reading on the Tube.

Well, maybe I won’t read the Plain Dealer. But you catch my drift.

The Libre doesn’t need an interface to include an MP3 player; the iPod Shuffle demonstrated that. So, with an eBook and integrated MP3 player, I can sit and read the newspaper while listening to the Bach cello suites that I downloaded from Magnatune.com. Or I can call up the complete Hitchhiker’s Guide to the Galaxy—a wholly remarkable book. The Libre could, even, replace textbooks the world over. And, someday, eBooks will. $100 laptops matter, too… but eBooks will be every bit, if not more, important.

The iPod is amazing; 50 years ago, you could only listen to music in one place, using a large reel-to-reel player or vinyl. Today, I can take thousands upon thousands of hours of audio with me in my pocket. I still cannot, however, transport thousands of pages of text with me everywhere, all the time.

So do it right, Sony. Give me an eBook that lets me load thousands of PDFs and ASCII files onto a (more than one) memory stick, hundreds of MP3s onto another (with two separate, replaceable batteries, please), and don’t screw it up by locking it down. You’ll change the world.

And I’ll buy one.

End of the SPAM!

I wanted to generate a quickly searchable database of snippets of text regarding technology surrounding editors, environments, and languages used for teaching CS over the last 50 years. It isn’t complete or comprehensive, but I’ve refreshed myself on key points from a large number of papers in my bibliography, which was the desired outcome.

In the next day or two, I’ll put together a summary post that links to all of these for quick-and-easy navigation. Also, I have a number of things that are conspicuously (and knowingly) missing at the moment:

Papers on BlueJ and DrScheme
Papers on LOGO and microworlds (eg. StarLogo).

I’ll end up handling these separately; it’s too bad they’re not in the list (for completeness), but for the sake of time, I’ve omitted this literature, as I’m more familiar with it anyway.

2005: Myers and Ko

Different methods, potentially we may have different ways of coming to similar conclusions? Interesting.

Eliciting design requirements for maintenance-oriented IDEs: a detailed study of corrective and perfective maintenance tasks

Design requirements for more flexible structured editors from a study of programmers’ text editing

Yep. Highly relevant.

2003: Helium, for learning Haskell.

Relevant, but not terribly interesting in the face of research.

http://doi.acm.org/10.1145/871895.871902

2003: Identifying and correcting Java programming errors

Syntax errors identified that their software attempts to catch before the compiler does:

= vs ==

== vs .equals

mismatching, miscounting and/or misuse of {}. [], ()

&& vs & and || vs |

incorrect semi-colon after an if selection structure before the if statement or after the for or while repetition structure before the respective for or while loop

wrong separators in for loops (using commas instead of semi-colons)

an if followed by a bracket instead of by a parenthesis

using keywords as method names or variable names

invoking methods with wrong arguments

forgetting parentheses after method call

incorrect semicolon at the end of a method header

leaving space after a period when calling a specific method

>- an =<

http://doi.acm.org/10.1145/611892.611956

2000: Displaying and editing source code in SE environments

At the far right of the diagram are “structure editors,” so called because of internal representations closely related to the tree and graph structures used by compilers and other tools. This greatly simplifies some kinds of language-oriented services, but it requires that programmers edit via structural rather than textual commands. Behind this approach is a conjecture, articulated by Teitelbaum and Reps, that programs are intrinsically tree structured, and that programmers understand and should manipulate them that way. Unfortunately, years of failed attempts, combined with research on program editing and on how programmers really think about programs have refuted that conjecture. From a tool integration perspective, the advantages of complete linguistic analysis are offset by its fragility (in the presence of user editing) and context-dependency (the meaning of code in many languages depends potentially on all the other code with which it will run). Few structure editors are in use today.

At the far left are simple text editors with no linguistic support. Editing is simple and familiar, but there is no real specialization for source code. Integrating a simple text editor with software engineering tools requires complex mappings between structure and text, but these typically result in restrictive and confusing functionality, fragile representations (for example, where the identify of structural elements is not preserved during editing operations), or both.

http://www.cs.berkeley.edu/~maratb/pubs/editor.pdf

1996: Usability issues in the design of novice programming systems

Too much to quote.

Over the past twenty years many research studies have discovered useful information about novice programmers, and identified good and bad aspects of today’s programming systems, both visual and textual. However, this body of research is widely distributed throughout the literature and is not well organized, making it difficult to use in guiding the design of new systems. The result is that these research results generally have not been systematically fed back into the design of new programming systems. Instead, the design of new languages and environments has most often been driven by technical objectives, such as ease of parsing, ease of generating fast code, closeness to the machine, ease of proving correctness, etc. Even systems that were designed for novice users or for teaching have not attempted to broadly survey this body of research before making critical decisions about the metaphor or model that the language is based on, the notation that is used in the language, and the environment.

http://www-2.cs.cmu.edu/~pane/cmu-cs-96-132.html

1996: Thetis

Shortcomings of existing compilers

The idea that weaknesses in the programming environment complicate the learning process for beginning students is not a new one; such shortcomings have been recognized in earlier papers [Ruckert93, Schorsch95]. The underlying problem is that most commercial compilers—particularly for languages like C that cater to a large audience of programmers—are designed for experts rather than novices. As a result, most of these compilers are poorly suited to student use.

In our experience, commercial compilers suffer from the following problems when used in an introductory course:

The error messages generated by commercial compilers are often uninformative and sometimes misleading. New programmers tend to make certain mistakes more often than others. For example, omitting a required semicolon or right curly brace is a very common error in C programs. Unfortunately, compilers sometimes respond to this error by reporting a seemingly unrelated syntax error several lines below the actual mistake, presumably because the parser does not detect the problem until that point in the source file. Expert programmers understand the problem and know where to look; novices are completely baffled.

Interactive debuggers typically require students to understand advanced concepts before they are ready to assimilate them. …

Commercial compilers offer a bewildering set of options and special features that are useless to the novice and occasionally cause consistency problems. …

http://doi.acm.org/10.1145/236452.236560