PIMMS is a software stack designed to support the development and collection of metadata. Initially, it was developed to “document the provenance of computer simulations of real world earth system processes”[*], but as is traditional for almost any infrastructure designed to support different types of experiment, the thought has occurred that the approach may be more broadly generalisable. It’s designed to allow for direct user (=scientist) involvement and the platform consists of, essentially, a sequence of stages of form-filling and design  processes, each of which fulfil a purpose:

• ‘experiment’-level description documents (at a high level, describing an overall scientific investigation in an area) – these include information such as description, author, rationale and so on and are encoded into CIM documents
• ensemble-level descriptions (datasets, versus individual data files, although as is so often true with collection-level metadata, opinions may vary on how this works in any given context).
• run-level descriptions: detailed component – based descriptions of individual experimental runs or even sessions.

Unusually and rather charmingly, PIMMS uses mindmapping as a design tool, viewing it as accessible to users. Whilst PIMMS clearly contains elements of the thinking that underlies UML-based design and uses UML vocabulary and tools in places, UML is ‘useful within a development team’, says Charlotte Pascoe, the PIMMS project manager, but it is not meant for end-users.

PIMMS counts among its potential benefits an increase in sheer quantity, quality and consistency of metadata provided. The underlying methods and processes can, in theory at least, also be generalised. A mindmap could be built for any domain, parsed into a formal data structure, automagically built or compiled into a web form and applied on your metadata. The process for building a PIMMS form goes more or less as follows.

1. Get someone to install a copy of the PIMMS infrastructure (software stack) for you, or indeed do it yourself.
2. Work out what you are trying to achieve. Write an introductory explanation, and export it to XML.
3. Identify and invite along stakeholders.
4. Invite them to build a visual representation (a mindmap) of a domain with you.
5. Press ‘Go’ and generate a web form suitable for input of metadata.

If this sounds somewhat familiar, folks, it is because the concepts underlying PIMMS have a long and honourable background in software engineering. Check out the Web Semantics Design Method (De Troyer et al, 2008), which specifies the following process for engineering a web application – my own comments in parentheses to the right:

1. Mission statement (what, when you get down to it, are you trying to achieve?)
2. Audience modeling (for whom?)
3. Conceptual design (with what? about what? doing what?)
4. Implementation design (using what?)
5. Implementation (Well, what are you waiting for? Go on, do it.)

WSDM, as described here, owes much to the waterfall model of software engineering (although, one would assume, there is nothing stopping subsequent iteration through phases) – see for example Ochoa et al (2006). To my eyes, the PIMMS metadata development process would appear to implement about half of WSDM in a less analytical and more user-centric model, encouraging direct input from the scientists likely to use the data.

The distinction, primarily, is in the implementation design and implementation phase; the PIMMS infrastructure compiles your conceptual design/structure, as represented in the mind map you have developed, into an XML structure from which PIMMS can build user-facing forms. After that compilation phase, further implementation work is essentially cosmetic, presentational work such as skinning the form. PIMMS removes the majority of implementation decisions from the user by making them in advance. Much as SurveyMonkey consciously limits the user’s design vocabulary to elements that may be useful for your average survey, PIMMS essentially offers a constrained vocabulary of information types and widgets.

I don’t make the comparison between PIMMS and SurveyMonkey lightly. The PIMMS project itself uses the terminology of ‘questionnaires’. PIMMS-based forms have a lot in common with SurveyMonkey, too;  incrementally developing the form whilst still retaining your previously collected data is not a straightforward operation. That may be a good thing – that way, you know which version of the input questionnaire your data came from – but on the other hand, incremental tinkering can sometimes be a useful design approach too…

The day continues. The sun subsides and the room is cooling fast. The geographers in the room, climate modellers of anything from the Jurassic to the Quaternary, go through a worked example of developing a PIMMS questionnaire. They discover a minor problem: the dates in the PIMMS forms don’t represent the usage of dates in palaeoclimate research, which are measured in ‘ka’ – thousands of years. This is a problem inherited from the UM, the Met. Office Unified Model [numerical modelling system].

Faster than you could say ‘Precambrian’, we are out of time. There has not been a chance to view the generated metadata collection form in use, which I regret slightly as it is the most common scenario in which the attendees will work with the system. Still, it was a worthwhile day. Workshop attendees  have voiced an interest in working with the software in future. As for me, after this glimpse into the future of palaeoclimate data management, I find myself thinking back to my past life in web engineering. I wonder whether, like  palaeoclimatologists, research data managers  could develop their expectations of the future by exploring the literature of times past…

De Troyer, O.,  Casteleyn, S.  and Plessers, P. (2008). WSDM: Web Semantics Design Method. In: Rossi et al (eds.), Web Engineering: Modeling and Implementing Web Applications. [see http://wise.vub.ac.be/Downloads/Courses/DesignMethods/WSDMChapter.pdf]

Sergio F. Ochoa, José A. Pino, Luis A. Guerrero, César A. Collazos (2006). SSP: A Simple Software Process for Small-Size Software Development Projects. IFIP Workshop on Advanced Software Engineering 2006: 94-107

Accelerometers are helpful for characterising device usage and detecting the mode of use. Most of these devices have an internal accelerometer, but it is convenient for our purposes to use an external device (requires less programming and does not require a jailbroken device).

Setup

In order to use this device, you must first set up the serial port with a line like the following:

stty -F /dev/ttyUSB0 raw ispeed 38400 ospeed 38400 cs8 -ignpar -cstopb -echo

Code

The code probably won’t tell you all that much, but here’s one way to make your life much easier: assuming you’re running this on Linux, set your device ID as /dev/dlptilt, then change the line ‘/dev/ttyUSB0′ to read ‘/dev/dlptilt’ in the code before compiling.

#include
#include
#include
#include
#include
#include
#include
#include 

#define BAUDRATE B38400
#define MODEMDEVICE "/dev/ttyS1"
#define _POSIX_SOURCE 1         //POSIX compliant source
#define FALSE 0
#define TRUE 1
#define DEBUG 0

volatile int STOP=FALSE;

void signal_handler_IO (int status);    //definition of signal handler
int wait_flag=TRUE;                     //TRUE while no signal received
char devicename[80];
long Baud_Rate = 38400;         // default Baud Rate (110 through 38400)
long BAUD;                      // derived baud rate from command line
long DATABITS;
long STOPBITS;
long PARITYON;
long PARITY;
int Data_Bits = 8;              // Number of data bits
int Stop_Bits = 1;              // Number of stop bits
int Parity = 0;                 // Parity as follows:
                  // 00 = NONE, 01 = Odd, 02 = Even, 03 = Mark, 04 = Space
int Format = 4;
FILE *input;
FILE *output;
int status;

main(int Parm_Count, char *Parms[])
{

   int fd, tty, c, res, i, error;
   char In1, Key;
   struct termios oldtio, newtio;
   struct termios oldkey, newkey;
   struct sigaction saio;
   char buf[255];
   char message[90];

   // set device name here
   strcpy(devicename,"/dev/ttyUSB0"); 

   newkey.c_cflag = BAUDRATE | CRTSCTS | CS8 | CLOCAL | CREAD;
   newkey.c_iflag = IGNPAR;
   newkey.c_oflag = 0;
   newkey.c_lflag = 0;
   newkey.c_cc[VMIN]=1;
   newkey.c_cc[VTIME]=0;
   BAUD=38400;
   DATABITS=CS8;
   STOPBITS=CSTOPB;
   PARITYON=0;
   PARITY=0;
   fd = open(devicename, O_RDWR | O_NOCTTY | O_NONBLOCK);
   if (fd < 0)
   {
   	perror(devicename);
   	exit(-1);
   }

   saio.sa_handler = signal_handler_IO;
   sigemptyset(&saio.sa_mask);
   saio.sa_flags = 0;
   saio.sa_restorer = NULL;
   sigaction(SIGIO,&saio,NULL);

   fcntl(fd, F_SETOWN, getpid());
   fcntl(fd, F_SETFL, FASYNC);

   tcgetattr(fd,&oldtio);
   newtio.c_cflag = BAUD | CRTSCTS | DATABITS | STOPBITS | PARITYON | PARITY | CLOCAL | CREAD;
   newtio.c_iflag = IGNPAR;
   newtio.c_oflag = 0;
   newtio.c_lflag = 0;
   newtio.c_cc[VMIN]=1;
   newtio.c_cc[VTIME]=0;
   tcflush(fd, TCIFLUSH);
   tcsetattr(fd,TCSANOW,&newtio);
   write(fd,"T",1);
   while (STOP==FALSE) {
       status=1;
       if (status==1) // so redundant...
		{
	if(DEBUG){
   		write(fd,"P",1);
		printf("Printed P\n");
	} else {
		// 7 - single a d conversion to host on current settings
		// z 3 bytes (both channels x and y of accelerometer)
		// s - 7 bytes (all 7 channels)
		// 8 - streaming a/d conversion data using current settings
   		write(fd,"z",1);
	}
	} 

         if (wait_flag==FALSE)  //if output is available
	{
		res = read(fd,buf,255);
		if (res>0)
		{

			// Print serial output
			for (i=0; i

As part of Project Sunflower, we took various approaches to interface evaluation. Alongside heuristic evaluation, walkthroughs and so forth, we also used various bits of hardware to support trials. This post describes setup and sample code for the NeuroSky MindWave, an inexpensive BCI (brain-computer interface – think ‘electroencephalogram’, or ‘brain wave monitoring’) that uses a single sensor placed on the forehead to measure eye blinks, ‘attention’ and ‘meditation’. These two latter variables shouldn’t be taken at (scuse the pun) face value; according to a report by Travis Ross, they’re based on a proprietary algorithm, with attention reported to relate to beta waves, hence linked to wakefulness/focus, and meditation linked to alpha waves – level of calm. Vague, admittedly, but then these devices are priced for and in large part targeted at the consumer market. If you’ve ever seen those Mattel Jedi force-trainer toys, those are based around the same technology.

Setup

Having installed the software prerequisites and drivers, the next thing is to run the Thinkgear Connector. This is an extremely helpful little piece of kit, which listens to the USB radio link and makes the sensor data available to applications. This reduces the connection step to a couple of lines of code. Since the Thinkgear Connector will return JSON upon request, the data packets are easy to parse.

Code

import sys
import json
import time
from telnetlib import Telnet

tn=Telnet('localhost',13854);
start=time.clock();

i=0;
# app registration step (in this instance unnecessary)
# tn.write('{"appName": "Example", "appKey": "9f54141b4b4c567c558d3a76cb8d715cbde03096"}');
tn.write('{"enableRawOutput": true, "format": "Json"}');

outfile="null";
if len(sys.argv)>1:
        outfile=sys.argv[len(sys.argv)-1];
        outfptr=open(outfile,'w');

# default values
eSenseDict={'attention':0, 'meditation':0};
waveDict={'lowGamma':0, 'highGamma':0, 'highAlpha':0, 'delta':0, 'highBeta':0, 'lowAlpha':0, 'lowBeta':0, 'theta':0};
signalLevel=0;

while i

Example output

The code as written above produces very simple CSV output, which has the benefit of being very easy to plot using something like Gnuplot:

plot "test-output.log" using 1:3 with lines, "" using 1:4 with lines, "" using 1:5 with lines

Some sensor data captured: subject was working on a language problem. Red

Sensor data captured: individual was watching TV. Red

Note: the number of blinks captured is low enough that the chances are that the MindWave is not picking up all blink events.

Assumptions used here: the task is to copy non-DRM’d ebook files onto an ebook reader.

Sony PRS-600, Hanvon n510, etc.

Like most of your basic e-Ink devices the Sony and its type are ridiculously straightforward to use, if a little slow, as long as you are familiar with copying files using a file manager. These devices function as USB mass storage devices. Plug it in, copy files, unplug it and (in the case of the Sony) wait for it to reindex pretty much the entire filesystem, including files that have been on the ebook reader for months. Don’t keep too many files on the Sony, or you’ll run out of battery life before you ever read a page – the indexing is the most power-hungry step it takes. The Hanvon doesn’t bother with exhaustive indexing, which saves time and battery life here but means that it doesn’t offer the same search functionality.

Filesystem speed stats were generated using:

rsync -auvh --progress --stats --no-o --no-g --no-p /some/files .

We ran this on Linux in each case, in order to ensure that there weren’t any confounding factors such as Spotlight indexing.

Results:  Hanvon N510: 2.34M bytes/sec

Kindle

The Mac recognises the Kindle as a USB drive, and allows you to copy items directly onto it (.pdf or .mobi – convert using Calibre if required). It’s not all plain sailing, though; the Kindle tends to place items imported in this way into a menu section entitled ‘items not yet indexed’. When this happens, it seems that you may need to reset the Kindle (hold the sleep button for 20 seconds), at which point it will reindex on startup.

File transfer rates: 1.87M bytes/sec
We found the Kindle’s file transfer rates to be unusually slow.

Xoom

The Xoom is a somewhat frustrating device. It’s using a driver called MPT (Motorola Phone Tools). Seems this is standard to Android devices, instead of SCSI-like hard drive/mass storage, so we’ll all have to get used to it… Google’s explanation for this decision may be found on this blog post: in short, MPT is seen as an improvement on USB mass storage because

‘for devices with lots of internal memory, a manufacturer no longer needs to come up with some hard partition between the USB mass storage and internal storage. Instead, they are all in one partition, with MTP providing access to the directory of media files that would normally be available through USB mass storage. This means there is no longer a need for apps on SD card for such devices, because what used to be the ‘internal SD card’ is in the same partition as where applications are stored. The storage on your device can be used for either applications or media, depending on what you want to put on it. You aren’t stuck with how much space the manufacturer decided to leave for the two areas. Also, this means that the media storage doesn’t need to be unmounted from Android when it is being access[ed] through the PC.’

On Windows, once the appropriate drivers are installed, it can be treated like a standard storage device – you can simply drag and drop files. On the Mac you’ll need to download the Android File Transfer software, which will allow you to drag and drop files in either direction, plus or minus the occasional bug.  On Linux, you can mount it through MPT using mptfs, a fusion driver for MPT drives. GNOME users will probably find that this happens automatically. The rest of us just do mptfs -o allow_other mountpoint. Android File Transfer on a Mac feels rather slow, but our test on Linux (see data below) suggests that mptfs is not unreasonably slow.

File transfer rates:
mptfs on Linux (calculated as above): 4.59M bytes/sec
Compare this to a similar test of an HP USB2 16GB USB drive: 7.66M bytes/sec

iPad

The iPad was clear winner of the ‘least cooperative’ award in this category. iDevices don’t show up in the filesystem by default. The traditional mechanism used to get files onto the device involves iTunes. This music software has been adapted after the fact for use as an ebook organiser, and its origins are still clearly visible. The results are indifferent: the right-click context menu in the ‘Books’ pane, for example, invites you to ‘download album artwork’. Using this approach, getting files onto your iPad is a multi-step process; download files, import them into iTunes, sync with iPad.

Right-click context menu for ebooks (iTunes)

iTunes is the Vegemite of the tablet user; you either love it or hate it. Unless iTunes is a big part of your ebook-reading life already, it becomes an irritant, dragging out the file copy process unnecessarily. The OPDS approach is simpler, if all you want to do is get your files onto the iPad: just download them directly onto the iPad itself.

File transfer rates:
cannot be compared directly.

In this post, we look at OPDS, otherwise known as ‘Open Publication Distribution System’, and why it’s worth a look for anybody intending to integrate ebook platforms into the student experience. For anybody who’d rather skip ahead, version 1.1 of the standard can be found right here.

OPDS is, according to the specification, designed as

a syndication format for electronic publications based on Atom and HTTP

and can

enable the aggregation, distribution, discovery, and acquisition of electronic publications

using

existing or emergent open standards and conventions, with a priority on simplicity.

Now, as we will see from reviewing the performance of typical embedded ebook search/indexing functions and interfaces, most ebook readers aren’t designed to contain huge numbers of ebooks. At 7.99 an ebook, most readers will be cautious in their acquisitions, so perhaps the perception from some manufacturers is that it is pointless to create readers that specialise in navigating across hundreds of thousands of files. Many portable media devices suffer from similar difficulties – the classic ‘clickwheel’ interface on iPods, as applied to a large number of files, became the subject of a 2009 satirical report by The Onion.

The relevance of OPDS is the following: OPDS allows you to search and browse across extensive collections of documents. They don’t need to be books; an OPDS frontend on an institutional repository is perfectly achievable, format conversion notwithstanding. The obvious use case is searching or browsing for a single file, but part of the relevance of OPDS is the fact that it also allows for batch mode: a student downloading the full reading list for the semester, for example. Wouldn’t that be convenient?

An OPDS catalogue is fairly straightforward to set up. For prototyping purposes, the well-known ebook software Calibre can be used to experiment with the concept; it can be found in the Calibre software under Preferences->Network->Sharing over the net, and is referred to as a ‘Content Server’. If you’d rather experiment with a static OPDS catalogue — providing no search function, but with browse functions that make full use of your metadata — consider trying calibre2opds, a Java application that renders your Calibre catalogue as a set of static HTML pages and, being simpler and more secure (by dint of having very few moving parts), may be considered a relatively secure way of deploying a prototype. A comparison of these alternatives may be found here.

Cross-platform compatibility: Limited.

Android and the iPad approach this on a per-application basis, and a good implementation is available for both. iBooks won’t handle the catalogue functionality, but you can manually type the address into Safari; then, when you click on an ePub file, iBooks can handle the download. Alternatively, you can use Stanza, which works well – but when iOS 5 came out, we discovered that Stanza ceased to work until we updated the iPad to the latest version, so be prepared for sudden failures around the time of iOS upgrades.

The Kindle is able to use OPDS catalogues, but requires them to run on port 80 (the usual port for a web server, admittedly, but not Calibre’s preferred choice for practical reasons). Simpler e-Ink devices mostly still do not have any mechanism for connecting to the Web, and therefore this sort of functionality is not available on the platform itself, so desktop software must be used instead.

Ease of setup: Moderate.

Getting a Calibre content-server running on a home network is relatively easy provided that the user is familiar with terms like ‘IP address’. However, practical implementation on a larger scale requires significantly more thought; not only are there security and sustainability issues around the software, but the usability of the resulting catalogue is very dependent on good metadata.

Benefits

Standard, relatively simple to set up, and extremely liberating – a convenient distribution channel, bypassing the need to centralise via a commercial vendor, what’s not to like?

Disadvantages

Support for OPDS is patchy and the standard is still relatively recent. Many popular ebook reader applications do not support it explicitly. Fortunately, it’s so near to popular standards that all you really need is a web browser and an ebook reader to get some benefit from an OPDS.

Sample screenshots

Browsing the Calibre content server by tag

Browse by author

Visibility of System Status - The user should be informed of what is going on

Match between System and Real World - The system’s language should be familiar and follow real-world conventions

User Control and Freedom - System should support undo and redo to help user leave an unwanted state

Consistency and Standards - The meaning of words and actions should stay consistent in  different situations

Error Prevention - Eliminate error-prone conditions or allow users to perform commit actions

Recognition rather than Recall - The user should be able to recognize the meaning of actions than having to recall their functions

Flexibility and Efficiency of Use - System should provide certain accelerators that help speed up interaction for expert users, however it should cater to both, novice and expert users efficiently

Aesthetic and Minimalistic Design - The design should be aesthetic, minimalistic and easy to understand

Help Users Recognize, diagnose and recover from errors - The system should assist users in recognizing, diagnosing and recovering from errors

Help and Documentation - Adequate help and documentation should be available to the user when needed

The study has been conducted based on user interaction with the eBook reading interface.

Results of the Analysis

The table shows the results obtained. It displays the areas where the devices do not agree with Neilsen’s Heuristics, and mentions the reason it does not fit the respective guideline(s).

This study further agrees with our previously done research indicating that the current eBook readers have some shortcomings that affect the user experience and there is more room for improvement that would lead to more satisfying user interaction with the device from an eBook reading perspective.

Device

The first thing noticeable about the device, or should I say not noticeable, was the power button. The power button was nowhere to be seen on the sides of the device. Users often mistook the SIM card slot for the power button. This was an issue with all users. The power button is on the back of the device, besides the camera. It isn’t easily identifiable.

The XOOM weighs 1.6 lbs, slightly more than iPad and Kindle that weigh at 1.3 lbs and 1.2 lbs respectively. This was another concern shown by users. The users pointed out that the impact of the weight was clearly evident through stress in the wrists when holding the device.

The thickness of the device is also not comparable to the iPad 2 and Kindle DX, the two other devices used for the study. The users thought a thinner device would be more convenient. The greater thickness however, did provide for slightly better grip.

The keyboard feels too broad when holding the device in landscape mode making it difficult to type.

User Interface

The users liked the eBook reading experience the app had to offer. The pages were displayed across the entire screen not wasting space at the edges and thus displaying more words per page in portrait mode. Settings provided by the app were also deemed adequate by users.

The most admired feature was ”Night mode’. This feature allows users to change the screen to white on black from black on white. This makes it more comfortable to read in low-lighting conditions and especially at night. This feature is an advantage because the backlit display can cause severe stress to the eyes when reading continuously for a long time.

The areas users generally found tricky were finding applications to read books on the device. Previous experience with the device played a significant role in this case. The users with little or no experience found it difficult to find and install apps. Most users wanted the app to be installed by default instead of requiring the user to install it.

The landscape view does not support 2-page display, causing almost 2 inches of screen space being wasted on either sides of the screen. This space could be better utilized to display more text and thus help users to see more information on the same screen.

The most severe issue was that of crashes. In case of some users, the app crashed abruptly and the user was taken back to the homescreen.

Bottomline

The Motorola XOOM is a powerful device and runs the latest Android 3.0 OS, however as far as eBook reading goes, is not a very suitable option. Especially for academic text. The device’s weight. thickness, abrupt crashes, and the ePub format’s illustrations rendering capabilities deems it unsuitable for reading academic text. Like most other tablets, the XOOM is good for leisure reading with its simple UI, various viewing modes and fast responsiveness. Academic text on the other hand requires more information displayed on a single page, the ability to flip through chunks of pages while being able to see the scrolled contents and the ability to make notes on the textbook. It will take more time till eBook readers support these features and as of now the Motorola XOOM does not seem ready for use as an academic textbook reader.

We studied the Kindle from point of view of academic text. We studied the reading experience on Kindle DX, the user interface it offers, and the device in general.

Device

The users were really happy about the fact that it was lighter than any other tablet they had held in their hands.  The fact that it is lighter than most other devices is true, however saying its weight makes it an ideal eBook reader is not. The users did have problems with the weight of the Kindle DX. Some users that had used other Kindles previously said that the bigger screen on the  DX was a great advantage, but the addition to the weight worked against that. The users were comfortable using the smaller Kindle than buy the more costly, heavier Kindle DX for a bigger screen.

The E – Ink Pearl display made a mark on all users. The users were very impressed with the fact that there was no glare from the screen, and the absence of brightness adjustments to be made to the screen to adapt to ambient light.  The screen was perfectly readable in varying lighting conditions. The screen felt good, and mimicked paper.

The problems mostly faced were with the buttons on the device. Users complained the keys on the keypad were too small, and found holding the device and typing at the same time uncomfortable as the keypad was too low on the device. The fact that there are no dedicated numeric keys added to this factor. The 5-way stick was difficult to identify for the first time, and making selections was difficult until the users realized the 5-way stick could be pressed in to make a selection. The device has navigation buttons on the right side only, which makes it mandatory for people to hold the device either in the right hand, or use another hand to flip pages when holing it in the left. The ‘Back’ button and the button to navigate through a book were misleading. Users mistook the ‘Back’ button for page navigation, however it is for navigating through and to menus and not for in-book navigation. Some users also expressed the need of a ‘Forward’ button as the slow response rate may cause repeated actions causing unwanted results. The Menu button was also misleading. as users thought they could change settings in-book using the Menu button. There is a dedicated key for settings on the keypad. This key too, is difficult to identify the first time.

User Interface

The users liked the simplicity of the UI, as all the books were displayed on the Homescreen. This made it very easy to find a required book on the device.

The Kindle offered a number of font sizes to aid the user. It also has a text-to-speech feature. That being said, the text-to-speech isn’t as advanced as one might expect. It is like any other text-to-speech software you may have tried using. The software  sounds fairly automated and loses expressions, which are key to any book or story alike.

The fact that it was not a touchscreen and did nothing but read eBooks was seen as an advantage. The lack of a touchscreen and other features caused less distractions to users and readers spent time reading instead of anything else.

The main concern shown by all users was the responsiveness of the UI. Common tasks like unlocking the device, opening a book and flipping a page took a long time due to the slow refresh rate. Talking from an academic texts viewpoint, fast refresh rate is one of the most important attributes an eBook reader should possess. When reading textbooks, most people flip through chunks of pages to retrieve relevant information. A task that seems impossible at a very slow refresh rate.

Bottomline

The Kindle is great for linear reading, but its currently not suitable to be used to read academic text. The refresh rate is too slow to allow for fast flipping to and from pages. The limited illustrations rendering capabilities and weight are also a problem. The Kindle, due to its low weight and E-Ink display may be really well suited for leisure reading, but it might take some time till one can use the Kindle DX to replace textbooks.

Device

Most users were very happy with the design of the device, and particularly liked how thin it was. That being said, the flip side is that they were not very happy with the weight of the device (despite being 15% lighter than its predecessor), and complained that their hands would hurt after a certain amount of time when using the device to read. When reading from the device for a significantly long time, one starts to feel the edges, especially when held in one hand.

The most common concern that all participants raised was that they all wanted the iBooks app installed by default instead of having to install it separately to be able to read eBooks. I admit this isn’t a lot of work, but isn’t the whole point of eBook readers allowing the user to get access to books as fast as possible? Inexperienced users did not know much about applications and their installation.

The screen feels good to read, however exposing your eyes to an LED-backlit display for a really long time isn’t a good idea. Especially in low-lighting conditions.

User Interface

The users were particularly impressed with the responsiveness of the touchscreen. They liked the way the device registered the tap exactly where they intended, and did exactly what they wanted it to do.

Users that had previous experience using iOS devices were more comfortable operating the device than others that had never used iOS devices before.

iBooks renders the book in a very graphical way to make it look not like plain text, but more like an actual book. This feature, however, costs almost an inch of space from each side. Space that could be utilized to fit more content on a single page, allowing the user to read more on a single page, saving some time from the reduced page flips.

Bottomline

From a purely objective viewpoint, I’ll go ahead and say the iPad has a supercool UI and great responsiveness, however, when it comes to eBook reading, these features don’t really count. Its backlit LED display and weight make it a ‘not so ideal’ eBook reader when it comes to academic text. The device is useful for leisure reading, but it may take some more time before we see students using the iPads as textbooks leaving their 2000 page hardback textbooks at home. One of the main uses of a textbook is to refer to a particular formula, diagram or search a particular concept as soon as possible. The ePub format’s limited Math rendering capabilities coupled with the inability to write all over the book and flip through chunks of pages at a time does not affect leisure reading, but makes it not so suitable for academic use.