LOADING

Creating Clementine

Creating Clementine

This is an ingress. I might not need it, but I just leave it here in any case.

In this chapter, the different choices made in the creation of Clementine are detailed. Even though most thought has gone into the user interaction part of the design, the choices taken when it comes to the visual representation of Clementine is also discussed.

The main focus of this part is to document choices taken and alternatives considereed when designing the user experience part of Clementine. Some technical details will be given if deemed necessary.

Clementine is a collection of interlinked static web pages, which means e that there is no database layer involved, and no server side programming logic. The interacive elements in Celementine is created with JavaScript, which is downloaded and interpreted in the browser on the client itself. All data that is entered into Clementine is also stored in the client's browser.

Clementine is designed to be as simple as possible, including only the features deemed necessary by the available literature and a preluding interview where students were asked about what a .... This is to be able to isolate the instruments implemented to design a digital book that is better than the alternatives, and be on par with (or better than) analogue texts.

The idea is to isolate and identify the reasons why people does not like to read digital texts. This to best be able to design the utopian product that is able to remedy these issues by maximizing the advantages of digital texts while also minimizing the disadvantages.

Inspirations

The main inspiration for Clementine is contemporary ebook and document readers, both software based and harware based technologies.

Ebook readers tested and used as inspiration is Amazon Kindle, both the hardware device and the applications available on the different platforms, and Calibre, an open source ebook reader used as an example of how not to create a usable reader. Amazon Kindle is available not only as as a series of tablet computers capable of rendering books, but also as a suite of applications for smartphones, tablet devices and desktop computers. During the research for the project, most versions available has been tested, including versions for the Apple iPhone, the Asus Nexus 7, Microsoft Windows 7 and for Apple Mac OSX. Apple iBooks has been tested on the Apple iPhone.

As for document readers, Adobe Acrobat Reader has been tested on Microsoft Windows and Apple Mac OSX and Apple Preview has been tested on *Apple Mac OSX.

  • Wordprocessors such as Microsoft Word and Google Docs
  • Treesaver

Ereader

Calibre

Calibre figur

Calibre lets the user do every action available with a press of a button. The result of this is a toolbar cluttered with buttons, which can be confusing to the user. Especially, when there are no less than three sets of nearly identical arrows present on the screen at all times. There is reason to believe that the amount of user testing of the application has been severly limited. The end result is an application that is confusing and borderline unusable. Additionally, Calibre is very slow to load – yet another user experience hazard.

Kindle

The commercial Kindle app on the other hand is visibly a lot more thought out, presenting the books in a clean and usable interface. , and by being available on just about every platform in existence, is rapidly becoming the de facto standard , with clear and visible buttons on the edges of the

There is a limited number of buttons visible on the screen,

The Kindle app also present the content in columns as a way to limit the number of characters on each line to improve readability.

The user interface is different on each device, adhering to the ... For instance, buttons are bigger on a touch device than they are are on the desktop version, to make it easier for the user to press the correct button with the less precise input method that is the finger touch.

Amazon also sells a hardware reader, capable of rendering the books that they sell in their store.

It is impossible to copy text out of the applications. As this is a feature that is trivial to implement, it is believed to be an intentional feature of the application, most likely because of copyright concerns.

Portable Document Format

Most static documents meant for reading and not editing is today distributed as a PDF file. The reading experience of the Adobe PDF reader available for Windows, Mac, Android and iOS has therefore been evaluated. Apple computers are delivered with an application called Preview that too is able to render PDF files, and has been evaluated.

Word processors

While word processors such as Microsoft Word, Apple Pages and LibreOffice Writer are not designed around the activity of reading, but the activity of writing, there is still a lot of text distributed in this format. The experience of using such software for reading has therefore also been evaluated for this project.

Of.. . The ability to comment and highlight text is present, and is probably the features that a reader is most likely to use when ... These features are however in all applications reviewed hidden inside a cluttered toolbar. It is very clear that word processors are not

Microsoft does provide a product called Word Viewer, an application capable of rendering Word documents to be able to read, print and copy Word documents without Word installed. In other words, Word Viewer is a lightweight document reader. A quick look at the user interface, however, reveal a user interface that is nothing more than the traditional Word interface sans the toolbar – a paginated, scrollable interface not unlike what you find in PDF documents, but lacking any kind of note taking functionalities.

http://www.microsoft.com/nb-no/download/details.aspx?id=4

Treesaver.js

Lastly, there are several JavaScript based applications on the Internet that lets designers paginate text. The libraries evaluated when designing Clementine is Treesaver, probably the most popular library in use today, and HVA HET NÅ DETTE IGJEN?, one of the newer implementations.

Treesaver.js is an open source JavaScriot library that is able to reflow text into a paginated interface, complete with controls, a table of contents and menus. While it does not work consistently across all web browsers, it is still an example of how one can implement a paginated structure with standard web technologies such as JavaScript and CSS. The business model of Treesaver, the company behind Treesaver.js, is for them to act as consultants for companies, implementing the library.

There are several other libraries, each with their own set of capabilities. Common for them all is that they are able to paginated text, they have either dedicated buttons or hotspots on the page for changeing the page, and more often than not support swiping gestures on touch enabled devices.

Summary

Common to all the aforementioned applications is that they implement a paginated reading experience, though all in a slightly different manner.

Responsive web design

Responsive web design is a modern way of designing web pages

The term responsive web design was coined by Ethan Marcotte in his article **-....

The first implementation of what is now known as responsive web design was seen shortly after the introduction of the Apple iPhone, where designers saw the need to create a version of the web page that is better suited to a touch interfacing. This was done by having the server analyze the web browser that made the page request (web browsers sends each request with a so-called header which, among other things, contains data that identifies the operating system and web browser), and then redirecting the browser to a version of the page tailored to the device.

This technique has a few issues:

  • browser sniffing might return th
  • inflexible
    • for instance, an Android device is no longer
    • does not

With the introduction of

This approach has in later years created problems for the designers, who now has to create a page that looks and handles good on a cell phone, a version that looks and handles good on a tablet, in addition to the desktop version. Keep in mind that this approach does not even take the different screen sizes, resolutions and aspect ratios of the myriad of different phones and tablet devices in use today. This is a lot of work, and can be very problematic to maintain.

The solution presented

This in contrast to the

The modern implementation has a ...

Rather than creating disconnected designs, each tailored to a particular device or browser, we should instead treat them as facets of the same experience. In other words, we can craft sites that are not only more flexible, but that can adapt to the media that renders them.

Speaking purely in terms of front-end layout, it takes three core ingredients:

  1. A flexible, grid based layout
  2. Flexible images and media, and
  3. Media queries, a module from the CSS3 specifications

(actually, the first unstyled web pages created were responsive, it is the modern way of constricting content inside fixed-width containers that is the culprit of making design non-responsive)

The main definition of a responsive web site is that is that the web page formats itself around the device that views it.

The same web page is not only accessible on all devices, but the content is more adapted to the screen size and form factor.

, you can define rules that that when a screen with a width smaller than 320px is detected, the base font size is increased and the buttons are increased (to count for )

Issues

Images

The largest issue with the implementation of responsive web design seen today, is that every client, no matter t A retina MacBook can display images with a resolution many times larger than a cheap Android phone has a need of showing. This leads to several problems: A mobile phone, often accessing the Internet through slow and expensive cell phone data plan, can have issues with the large , leads to longer download time, a larger phone bill and a page that performs sub-optimal (due to the browser having to render a huge image on a small device). There is a need for a way to discriminate between the various browser and device types based on other criterias than just screen resolution alone, and only download the data that is strictly needed.

There are proposals to further improve the standard with more so that a browser can identify the connection speed among other things, and request only the data that it really needs. For now, there are JavaScript libraries that can assist in optimizing image retrieval.

Later versions of the standard is likely to contain methods to identify the input method in use, such as a finger (imprecise, found on phones and tablets), mouse pointer (precise, found on traditional computers and some tablets), TV remote control (only arrow keys), gestures (such as Microsoft Kinect), video game controller (either arrow key based or pointer based). The ever evolving collection of devices capable of accessing the Internet, and the large variations in ways to interact with web pages rapidly growing creates a need to be able to dynamically render content in different ways.

Pixels

The approach of counting pixels are not really the preferred aproach any more, due to a pixel no longer being a pixel on today's high resolution monitors.

The Pixel

Popularized by the introduction of the Apple iPhone 4...

Pixel doubling

The operating system and browser report this 2x2 pixel matrix as a single pixel, making pixel based layouts work as in However, as both CSS and JavaScript supports sub-pixel rendering, you can in fact use pixel in 0.5 increments, and create interfaces Not that is is generatlly recommended.

Modernizr

In the creators' own words, Modernizr is a JavaScript library that detects HTML5 and CSS3 features in the user’s browser.

Through a battery of tests and heuristics, Modernizr can determine the capabilities of the device, allowing developers to adjust the user experience accordingly.

An example of this

, as the CSS standard does not (yet) support the detection of imprecise touch events, Modernizr fills this gap, and makes it easier to create a user experience based on ..... In Clementine, Modernizr is used to detect touch screen devices, and displays larger, more finger friendly, buttons as a result. Devices with a mouse pointer will have smaller buttons. Hybrid devices has large buttons.

, not only wether or not the screen supports touch events, but also wether or not the device supports multi-touch (for instandce early Android devices did not support this due to patent issues now resolved).

Other use cases of Modernizr is to be able to detect missing features in a browser, and adjust the content accordningly or even make it more possible to manually create the feature in JavaScript.

Relation to Clementine

The ideas and principles of responsive web design has been applied when creating Clementine, creating a product that is able to scale well to different devices. As mentioned above, one of the core principles behind the creation is to make a book that is as usable as an analogue book, which means that the book should be as available, if not more. By creating a book that is as useable on a handheld device, which most students own today, as it is on their laptop computers, the book will be available to read wherever the user wants to read, as regular books are. To illustrate this, a simple user story has been created, and is presented below.

Lets meet Nora, a student of informatics on NTNU. She has not been reading as much as she should have during the course of the semester, and as the exams are coming up rapidly, she needs to read as much as humanly possible in the course of time that she has left.

With Clementine, she is able to read at the table as she eats breakfast on her tablet computer. Finished, she runs to catch her bus going to campus. Here she is able to read the same book on her phone, cramming as best she can while ignoring the noise around her. Finally arriving at campus, she exits the bus and runs towards her study hall. Happy that noone had taken her favorite spot, she sits down and continues reading her book, now on her laptop computer.

While this is arguably possible with all web pages, the reading experience is often nowhere near optimalized for all platform as a responsive web page is, especially so on mobile phone platforms. With new web technologies, a designer is able to construct a web page that reflows properly, adjusting font sizes and omitting content depending on the size of the screen that is used to view the content, making for the best viewing experience independent on the device. The content adapts to the device, not the other way around.

On pagination

Research suggests suggests that pagination has a quite a few benefits when it comes to structuring content, especially....

There are, broadly speaking, two major kinds of solving pagination. The first, most obvious one is by having a For convenience, let's call these static and dynamic pagination.

Static pagination

The reasons for paginating pages like this is done for a few different reasons. The first reaso

  • Limiting the page size
    • Bandwidth concerns
    • Psychological concerns (chunking of content)
  • More ads

There are several reasons to why a web page is paginated.

There is also the issue of the usability myth that people does not scroll..... This is arguably false, and is more than anything en People today are ... with popular web pages such as Facebook, Tumblr and Pinterest not only being scrollable, but has implemented the technique of "infinite scroll"

Additionally, the number of ad impressions per person is increased, as a new page could load new adverts. Some sites also puts ads in between pages.

displayed.

Scrolling

Infinite scroll

Infinite scroll is a usability pattern where the page dynamically

Mostly applied to..... , such as Twitter updates or Google search results.

This is in contrast to loading every entry when the page is loaded, or to statically paginate the page and having the user press a button to navigate to the next page.

This is usually accomplish by creating the page in paginated chunks, for example by having the server return 20 entries per request. When the user has scrolled down to the bottom of the page, the server then autmatiacally is queried for the next 20 entries in the series. The content is then placed at the bottom of the page, creating the "illusion" that all the content is rendered on the same "infinitely long" page.

There are some usability issues with this approach, the biggest being that it renders the scrollbar with its functionality and affordances largely useless as it does no longer represent the length of the content on the page.

Dynamic pagination

Here, the content adapts itself to the screen size dynamically, making

Where, on the myriads of different screen sizes and resolution available today, a page is This, compared to the fixed pagination, where the two metaphors are combined into a chimera of sorts, where a user often has to scroll the page and then turn the page.

Clementine is implemented using dynamic pagination, and is readable on every device with a browser that supports the pagination feature.

Client based model vs. Client-server based model

Among the very first design descisions taken when designing Clementine was wheter to implement it as a single web page, written in static HTML (med litt attåt) or as a client-server based web page. The main difference between these two models lies in how the data is stored and retrieved.

With static HTML files, the data is stored as plain text files available to the browser........ With a client-server based model, the data is stored as text strings inside a database, which a programming script is

When requesting a web page from the With a static web page, the HTML files is retrieved as-is directly from the server, and presented in the web browser. With a client-server based model, the HTML-files are littered with "holes" that a The programming script running on the server populates these "holes" with data from a database There are, of course, nuances to this....

Static webpages

Static webpages

Static in this context means a web page that No particular p

The early web consisted of static, hand written web pages that were manually linked together.

Static web pages have in the latter years gained a resurgence with the arrival of static page generators. Modern static web pages are often generated with the use of frameworks; scripts that interprets input data (often in the form of MarkDown files for content and template files for structure), and produces HTML files.

Popular frameworks that enables the compilation of static web pages includes Jekyll and the framework used by Clementine DocPad.

This is different to the popular LAMP stack consisting of Linux as the operating system, Apache as the web server, MySQL as the database management system and PHP as the programming language that powers many web pages on the Internet today.

Compared to, generators lets the users ... Compared to traditional server based language based web pages, static web pages are faster and are platform agnostic.

In effect, with a static web page, the action of packaging the web page for distribution is a lot simpler, as the technology stack needed to present the web page is very limited compared to the client-server based model.

The main advantage of implementing Clementine as an application that lives purely in the web browser is that it is completely server agnostic and, with some limitations, can be run directly from the client's file system.

Limitation

XHR

This is to protect the computer

Case: A malicious site

To keep malicious sites from being able to read files directly from the file system.

Further, there are some limitations on how web applications are able to communicate across servers.

Case:

  1. A user visits www.db.no
  2. The site replies with the site, which inludes a script that tells the browser to retrieve data from www.vg.no with an asynchronous XHR request
  3. The browser refrains from making the request due to domain mismatch

It is however possible to avoid this restriction in several ways. Modern browsers has the ability .... something something CORS.

Implementing. ... Not being ... Makes it easier to make it possible for the users to download the book

If the company providing the hosting croaks, the book is potentially lost forever, the content locked in an inaccessible database never to be available again. The company could also after some time simply restrict the access to the book.

While this will always be the issue when serving a web page on the server, regardless of the

, if the book needs a specific server architecture, programming language, database model ++++, This compared to a

A client-server based model

It does set some restriction on where the application can be run, including platform, system architecture +++.

Clementine

As discussed above, both choices comes with their own sets of advantages and disadvantages, and there seems not to be

The answer seems to be a hybrid solution, where as much as possible is retained and stored in the client, and the server is ...

Clementine is implemented with a pure client based model. This is due to serveral factors, the main one being that it is simpler to implement, and this project shall not

... an administrative section, where the author is able to

Retaining user data

There are considered to be two distinct solutions to this problem: storing the data on a central server which the client can access; and storing the data in the client.

User accounts

The first solution to the problem of retaining user data is to store the data on a central server. This is best solved by creating Clementine with a traditional client-server model.

insert picture here

Here, a user is able to access the site that hosts the book, log in, and retrieve a personalised version of the book, complete with annotations, highlightings and whatever else one choose to make it possible to add to the book.

The data would be accessible from

LocalStorage

The second solution to the problem of retaining user data is to store the data in the client itself.

Modern browsers has the ability to store data more permanently in the client

Session based storage, long time storage

This lets the user access...

Limitations to this is that the data is strictly tied to the client

Search

The limitations of how search is handled by Clementine is first and foremost a result of descisions of how to implement the application

Server side search

By creating the book in a more traditional manner, with a proper client/server model, a search feature capable of traversing all the files that constitutes the book is absolutely possible.

Client side search

This is not to say it is impossible to create a JavaScript based search engine able to traverse all the documents, but is comparably slower.

This would entail having the web application be aware of all (traversable) documents, fetch the documents asynchronously (to not interrupt the user experience) and store them in the client's memory bank, traverse all of the documents and present the results. While not too dissimilar to how

  • JavaScript has limitations on what files can be read directly
    • Hackable by using XHR
      • Has to run on a server, cannot be rendered from the client file system
    • Fixed with new File API present in modern browsers?
  • JavaScript does not do threading, can be slow
    • Can be unresponsive
    • Solvable by using WebWorkers?

Again, this is not to say that it is impossible, but rather im........ Keep in mind that I have not discussed the simple manner of designing the search algorithm here. There seems to be ability to search through documents on the client instead of on a server seems to

... considering how the world seems to evolve web apps. Offline...++

and maybe even worthy of being a thesis in and of itself.

Page numbering

As the pages are dynamically adapted to the viewport size of the device the book is viewed on, page numbering does not mean all that much anymore. Usability wise is the need for page numbering thus a point that needs special consideration.

  • strictly unncessary
    • why should I even consider having it?
  • useful metaphor
  • why it could be harmful
    • relying on page numbering for refering to the placement of content
  • alt: percent?
  • alt: rely solely on a progress meter (which is kinda the case with traditional vertically scrolling web pages)

Visual design

Or: the choices taken and contemplated upon when developing the visual design of Clementine.

There are a great number of studies

  • Font selection
    • Serif vs. sans-serif
  • Columns/number of characters per line
  • +++

While disagreeing on several points

  • what causes what and why

: design matters.

  • a cluttered page is harder to read than a clean page

The goal: produce a book that is professional, aestethically pleasing and a pleasure to use. (UX is paramount, the visual design is second - while beauty is only skin deep, ugly goes to the bone)

...something something beauty encompasses UX .... - Steve Jobs

Future development

Clementine was created with a simple tool for converting formatted text to static web pages, linking them together and whatnot.

fin

Being web based, everything possible on the general web is possible in Clementine, including illustrative animations, audio and video, interactive content ++++

Multimodality.

This is beyond the scope of the prototype, as the Clementine was created to illustrate and research ways to represent digital text.

Authoring

The biggest improvement on Clementine would perhaps be a proper authoring tool.

The tools used to create Clementine, while easy to grasp for a person with technical experience, is cumbersome for a person without this.

Kort sagt: make it easy for whomever to create and author ebooks.

Typography

There are a limited number of typographical features present in Clementine, mostly for aesthetic reasons and to furhter emulate the genre of the source material.

  • (Annotated) figures
  • Pullquotes
  • Info-boxes

All of which can be improved upon. Authors could have needs ....

Who is Clementine

One of the more obscure decisions that has been made when designing Clementine was the decision on how to regard the prototype itself: is Clementine a framework for creating a book; is Clementine a book; or is Clementine a collection of books.

As always, there are advantages and disadvantages with both solutions.

... related to the question of what functionality that should be implemented in the application and what functionality that should be left in the browser.

If left to the application.

Again, the question on where to store this data the question of having the book run serverless arises, and the same advantages and disadvantages applies here as well.

If left to the browser...

In a way, the browser itself can be ... as a library application, with bookmarks being used as ... The Opera desktop web browser has a note function built in. These notes exists

, and as students wanted the notes to be connected to the text in some way, this note feature is not sufficient to fulfill this need as it is exists today. It is however easy to imagine this feature being ... Likewise, every modern browser has a bookmarking feature, which lets a user store a collection of their favorite web pages. The bookmarking feature of the browsers does not however store all the data needed to...... , but is limited to storing a title, an url and in some cases a comment and/or tags. (URLs can be stored with a #hash, but this too has some limitations, such as every bookmarkable element has to have a unique id)

Again, it is easy to imagine the browser bookmark feature implementing the ability to intelligently store the position in the text where the user is reading, either for read-(more)-later or there-is-a-nugget-of-information-located-here purposes for later retrieval.

All modern browsers has the ability to synchronize data across browsers on different devices, limiting the problems of data storage (where to store what data).

Single-page or multi-page

to either load the content of the book into a single page, or represent the book as a set of interlinked pages.

Advantages/disadvantages

The largest advantage of implementing Clementine as a single page document is that you would then have the ability to do a document wide search without server side logic. See the discussion on search below. One is also able to have a measure of the number of pages that there is in the book.

With the standard maturing, the ability to have the book as a single-page document could potentially be more achievable, as discussed below.

The future of the standard

Clementine has been implemented using an imperfect, immature implementation of the standard.

Functional where it counts, but lacking in several places....

Features

Search

As mentioned, the search feature of Clementine is limited to searching inside single chapters, due to web browsers only being able to load single web pages at a time.

Page numbering

At the bottom right corner of the page you can find the

The future of the web technology used to implement. .....

The browser can find....

For instance

The first group of interviewees seemed to enjoy the low number of pages, as cited it as....

With this feature, the best of both worlds could be achieved. Each chapter having a separate page counter, the complete document having ...

´The future of the standard ........................ page 3´

(both leading ... and possibily.. .. is part of the standard proposal)

Progress meter

In addition to having , a simple progress meter is placed at the bottom of the page. This meter will fill up gradually as the reader This is accomplished by dividing the number of read pages on the total number of pages, and filling the meter accordingly on each page turn.

Based on feedback, the meter starts out empty as a simple usability measure. This opposed to having the meter start out as being filled as if the user has read one page. TRAINWRECK

Animations

Many of the elements that constitutes Clementine is animated. This make the application both prettier and more pleasing to use, but can also be a way to indicate interactivity on the page.

There is however a fine line between animations that are pleasing to the eye and provides a richer user experience and animations that are eye-catching and distracting.

The respondents in the initial prestudy pointed to the animated progress bar as being a distraction. One of the interviewees mentioned that he felt as his eyes was lead to the movement on the screen. This animation was removed in the later version of Clementine.

When the page loads (for the fist time?) the sidebar bounces slightly to indicate its presence. This is as the respondents in the prestudy had some issues in locating the menu button. // actually not implemented yet. hurry up!

The page turning is animated on Microsoft Windows and in the experimental version for the Android platform, but not in the Mac OSX version. This is a limitation of the implementation of the layout engine, not the CSS produced for the prototype. The standard proposes the ability for designers to choose between several page flip animations.

The left sidebar has a slide animation

Highlighting of text

According to a bunch of the reviewed literature, a highlighting function is regarded

This was confirmed by the respondents in the prestudy, and has been added to the prototype.

While not strictly a part of the study, the prevalence of it being mentioned in literature, also in the prestudy, it has been added.

For the first part of the study

How to visibly and intuitively present the functionality to the user has been an issue that

Two solutions has been created and tested in order to find the best possible one: a clickable button that toggles a "highlight mode"; and a context sensitive menu that appear when the user selects text.

Button

Simple and easy, the toggle button approach functions by having a the user press a button to activate "highlight mode". Now, when the user selects text, it is highlighted and saved for later.

Buttons to toggle a "highlight mode" is used by Apple Preview,

Context sensitive

The second approach to solving the issue of making the highlight function visible is to create a context sensitive toolbar that. Here, the ability to is hidden from The main advantage of the context sensitive approach is that it appears without warning when the ...... – the user does not have to search for the functionality, but the function appears
The context sensitive approach brings its

In contrast to the toggle button approach, the action of selectiing text is something that the user needs to do when highlighting either way. With the context sensitive approach, the a

The Amazon Kindle desktop applications uses the context sensitive approach.

Many applications created before Clementine has had similar issues, and research (SETT IN LINK)...

The highlight functionality is implemented without the ability to delete highlights, something that needs to be rectified in a later version. There are also some bugs, when This leads that in case of an error, the text will not be highlightable

Another improvement that a

How the ability to select text on tablet computers

The sidebar

The primary goal for the application is to make text as readable as possible, but there is still a need to supplement the text with extra information and functional features. One of the more important ones is a readily available table of contents where the user can easily navigate through the sections of the book. To keep the text as clean as possible, with as little superfluous information and buttons on the screen whenever the user does not explicitly need it. Such information and functionality is needed to be hidden, but readliy available. An expandible sidebar on the left of the screen, as found in many applications today (see ....) was decided to be the solution to this problem.

The first version of Clementine has a sidebar containing nothing but the table of contents and is expanded by pressing a big, contrasting button positioned on the top left corner of the page. While initially thought to be an adequate solution, a few issues manifested themselves during the prestudy interviews, as well as suggestions on improvements. The biggest flaw with the solution was that the button to unveil the sidebar was not visible enough.

Features that were requested included a way to taking and keep track of notes. The sidebar is a prime candidate for the position to contain such notes.

, options such as adjusting the text size, keeping track of notes and highlights.

Table of contents

The first version of the prototype

A version with this tree structure was

A more dynamic version that is able to read contents of the

A suggestion on how to improve the table of contents was to have the .... nested , so that the subchapters under each of the chapters are accessible. As a result, a working implementation of this has been developed. This feature has been realised by having an arrow next to the chapter name, a button that is to signal a way to reveal more content contained in the entry, similar to the Master–detail interface pattern. When the button is pressed, the sidebar content slides left, revealing the content of the chapter with links to each of the subchapters. While there could be an unlimited number of sub- and subsubchapters nested under each other, for Clementine, there are only two levels; the chapter and the subchapter.

The content for each of the chapter entry is dynamically generated from the HTML files, and works as follows:

  1. The user presses the reveal-sidebar button
  2. The user presses the arrow button to reveal the subchapters contained in a chosen chapter
  3. The application fetches the HTML asynchronously in the background
  4. The application sifts through the document to collect all H2 elements
  5. The application builds the index and presents it to the user

An alternative solution to this would be to define the chapter structure separately, either staticly typed out by the author, or constructed when the web page is built. The latter of these solutions would probably be the best solution for a non-prototype version of the book, but is not used due to the framework used to produce it not supporting such behavious out of the box.

If the user presses the chapter name, the application navigates to the beginning of the chapter.

A potential user experience hazard here is that due to the chapter entries now being two buttons "in one", there might be some confusion among the users. User testing with scenarios will have to show wether or not the solution chosen is adequate, and the affordance is clear enough for the solution to be intuitive.

An additional benefit to the usability of the book, by having the subchapters available in the table of contents, the user is able to rapidly skim through the contents of the book.

Additional content

The prestudy toched upon some additional features that best would be made avaiable through the sidebar, due to not being ...

Text formatting

The ability to change the font as well as font properties was among the features unanimously requested in the prestudy.

While there is a study that shows that customizability could be a detriment to the, there could be a good idea to implement this.

There are fonts Case in point: a font created for dyslexic people http://opendyslexic.org/ http://www.pixelscript.net/gilldyslexic/

While the zoom feature present in all modern browser will adjust the font size, this will adjust the size of all other elements on the screen. A way for the user to adjust the font size, and the font size alone should be created.

Typographical features such as letter and line spacing are among the other things that could be adjusted by the user.

Other related features includes a "night mode", where the screen colors are inverted to make the screen easier to read from at night.

Fonts

Google Web Fonts is the main repository for fonts used in Clementine.

  • Open Sans for sans-serif text
  • Open Sans Condensed for headers
  • Merriweather for body text

The choice of serif text for

The hypothesis is that the serifs on the letters helps in distinguising the different letters from each other, creating a text that is more readable. This is however heavily disputed, and one can find many ....... Still, a sans-serif font has been chosen for Clementine to not only (potentially) increase readability, but also as it better emulate its alternatives. Most pedagogical texts, often found as PDFs generated from LaTeX, have serif body text.

An ability for the users to change the font is a feature that is relatively easy to implement in Clementine, making for the possibility to.....

There are fonts specifically designed for sufferers of dyslexia. Comic Sans is ugly as sin, but is found to be very readable by all.

FontAwesome

Far from a traditional font, FontAwesome is a repository of icons loaded into the browser as a font. This makes for icons that are infinitely resizable (due to being vector based) and are easily colorable (as all fonts are).

Hyphenation

While support for hyphenation, making for

the lack of proper browser support for the feature in Opera made it

Hyphenator.js

To make it easier

This will crawl through the text from start to finish, creating so-called soft-hyphens in every place a word can be hyphenated. The end result of this is a text that can be reflowed dynamically

Based on the Liang-Knuth algorithm ...

Search

Searching is one of the main benefits of having a digital book. Unfortunately, Clementine does not support search in other ways than searching through a single chapter through the built in search feature available in modern browser. This is mostly due to Clementine being implemented as a set of static HTML files, with no server logic that could take care of such a feature.

There are several ways of implementing a proper search, four of which will be discussed below.

The most obvious one is to contain the entire book in a single HTML file, where one could then use the browser's search feature to find keywords. The discussion above on single vs. multiple page implementation .... The second way of implementing a search feature is the one found in the wild: searching with server side logic. This is not possible with Clementine due to it being implemented as a set of static HTML files......

The third, experimental way, is by using the new HTML5 File API. Here one could, in theory, build a JavaScript search engine capable of reading and indexing the files that constitutes the book, making it searchable while still being a static web page. While possible in theory, this is beyond the scope of this thesis, and probably deserving of a thesis on its own.

A fourth way of implementing search is to do nothing more than making the files available and indexable by third party search engines such as Google or Kvasir and use these.

Redirects

Clementine stores the reader's progresstion in the book by storing the location of what is last displayed on the screen.

When the user accesses the

This is based on a simple use case where the user has read for a while in a book, closes the web site/web browser, and reopens it at a later time.

  1. A user reads
  2. The user gets tired, closes the web page
  3. Some time passes
  4. The user wishes to read some more

Here, the user is likely to want to continue reading from the same position as she left off, not having to remember the position and navigate herself.

a feature that was specifically requested in the prestudy. To save this data to either a central server or in the client itself is trivial. How to best make use of this data is however not.

The two most apparent solutions to this problem, is to either for the user being redirected to the last position registered in the application, or to present a link to the user.

To automatically and intelligently redirect the user to the last position seems to be a common approach, and is used not only ereader applications the Amazon Kindle (both the apps and the tablet), but also video sites such as YouTube and Netflix where the video resumes from the point where user left off (only in longer YouTube videos).

There are however a few potential user experience hazards, as it can potentially be very problematic to make choices on behalf of the user, if the user does not expect such choices to be made.

The other approach is to let the user himself choose what the application should do. While this circumvent the dangers of an application making an erronous choice, this is potentially a detriment to the user expericence, as this interupts the flow...

(at least) two dangers in doing things on behalf of the user....

The first, most obvious one is that the choice might not be the correct one.

The second is that an autonomous application might be confusing , where the user does not know why an action happened. insecure users might not be aware that the application did this on its own, and might think that he or she in error pressed a button at some point.

Might be the right thing to do in some cases, wrong in others.

Where in the web browser, the user is used to be

This might be the wrong approach as this is something that might go against user expectations of a web page.

The prestudy unveiled that, even thought the navigation in the application was different from what one would expect from a "regular" web page, Clementine was still perceived as being a web page.

This could lead to an unfortunate series of events where the user enters the URL for a web page, and then is being redirected to a different one – one that is not the one that they initially, consciously requested.

This could mean that, even if the choice in a perfect way was made correctly 100% of the time and the choice always was the best one possible, the approach could be wrong, as it is made on behalf of the user which might contradict what a user expects from a web page.

some diagrams, etc.

There are, as always a few drawbacks to this To store the data persistently, the URLs needs to be as persistent. This could potentially be an issue when editing and updating a book. The URLs must thus be chosen carefully with forethought.

Technical implementation

Issues

  • creating-clementine.html#issues
  • 3.html#section6
  • chapter4.html#issues

  • Titles as the URL - most semantic, more information, if a little crufty. Potential problems if the title is edited

  • Chapter and section ID numbers. Not semantic, but more stable
  • Aliases - hybrid solution, potentially more stable than the title, more semantic than the ID numbering

Storing user data

To store the last read, there are, as mentioned above, two directions the application could take.... whwatym : either to store the data on a server from which the user can retrieve the data from; or store the data in the client itself.

Hybrid solution: store the data in the client, but synchronize the data in a central place.

LocalStorage

Clementine stores the data in the client through a web API called LocalStorage. This is an API that is able to store data as text strings to a repository, a local storage, which can be queried to store and retrieve data locally in the browser itself.

window.localStorage.getItem('itemName')

window.localStorage.setItem('itemName', 'itemvalue')

Or, more realistically window.localStorage.setItem('itemName', JSON.stringify({"key": value})), where the data is represented as a JavaScript object, which then is "stringified" (made into a text string, due to the limitations of the API) and stored permanently to the browser's LocalStorage.

Data types

While the data stored by Clementine is a JavaScript object, somehting that actua , modern JavaScript engines has the ability to parse and "stringify" between these two datatypes with ease.

There are a few disadvantages to using this compared to its alternatives, including speed of retrieval, size restrictions and the datatypes that can be stored, but due to the simple nature of the data that is to be stored and the relative ease that the data can be stored (one simple line of JavaScript compared to a complex SQL query), the LocalStorage API was chosen as the technology to be used to store user data.

Browser differences

There are, as is the case with most of what the web is capable of doing, differences in what the different browsers can do. LocalStorage, is by far the solution that is implemented best by all modern browsers. There are however slight differences, but these differences are by and large limited to the amount of data that the web page is allowed to store. Considering the miniscule amount of data that Clementine is storing, this is a non-issue.

Alternatives

There are a couple of storage alternatives available, namely: the (extended) File API, where the client can store and retrieve data to and from the client file system; and the Indexed database API, where the browser can store and retrieve data that can be accessed through a query language such as SQL.

If considering Clementine as a library application as discussed above, the Indexed database API could for instance be leveraged to provide a way to do complex queries such as ordering all the books available based on author and publish date.

A possible scenario for leveraging the File API is to store the content of Clementine to the client file system, as a text file (rather than a series of text strings) caching it for the forseeable future.

Both approaches solves the problem of storing user data, but are much more complex compared to the LocalStorage solution. The LocalStorage solution is also more compatible across browsers. A future version of Clementine, with broader browser support could possibly benefit from using the more complex solutions with the promise of more useful features implemented.

Synchronization

One of the major features of Clementine is that being a responsive web based application is that is available wherever a (compatible) web browser is installed. While this is brilliant in the way that makes it possible for those of us fortunate enough to own more than one device to read the book in different form factors, there is now a need to synchronize user data between the different clients. As Clementine is implemented as a static web page, this is problematic, as there is no server that can store the data, no server that the clients can conect to to retrieve the data.

Modern web technologies does however intend to solve this by providing a way for web browsers to synchronize offline data between clients. The Chromium Projects team has proposed the SynchFileSystem API, and the Mozilla Foundation proposes the SyncStorage API. These proposals this moment not interoperable, and are both experimental and not properly standardized, but the intention and goal of both proposals are the same: to provide a standard, interoperable way of synchronize offline data between clients. This can in effeect solving the synchronization problem, making it possibel to have all the data that the user leaves in the client, including reading progression and notes, available in all browers and devices that she uses. As the proposals are at a very experimental stage at this moment in time, this is not to be implemented in Clementine.

KeyListeners

All custom, based on the ones delivered with the browsers