wiki:Documentation/UIDesign

Translations:

  • English

UI Analysis & Design

(original document (russian):  http://docs.google.com/View?docid=dqrcvtb_11qdp895v3

this is still work in progress

Global reader functions

  1. Bookshelf
  2. Continuous reading (mostly fiction)
  3. Working with texts (e.g. dictionary, handbook, encyclopedia)
  4. Secondary features (image viewer, mp3-player, etc.)

Chapter A: functions

1. Bookshelf

Book collections, sorted by:

  • author
  • read / unread
  • book title
  • date added / date started or finished reading
  • book type (fiction literature, dictionaries etc.)

Introduction of a tagging system (preconfigured/hard-coded or user-defined or both)

Implementation of a search system, however, since there's no keyboard, it's probably a better idea to search for a couple of first characters, selecting from a list of existing words (or prefixes)

Ideally, there should be a window where you can read the book annotation/book review

Book statistics:

  • page, words, symbols (characters) count...
  • % read
  • a diagram displaying the % read of all current books

2. Continuous reading

Two modes (display types):

  1. fullscreen
  2. hint mode:
    • by pressing and holding a certain button a pictogram is shown ("back", "forward", "left/right", etc)
    • indispensable pictograms/labels are allways visible

The display type could be configured in the settings menu of the fullscreen mode:

  • "real" fullscreen
  • fullscreen with hints (tips)

The user should be able to decide, if he needs any statistics in the status-bar, configurable through settings menu as well.

3. Working with textual content

Essential

  1. fast navigation within content - introduction of "fast forward/back" buttons for 1, 10, 100... pages
  2. free text search - without a keyboard and other kind of input devices (e.g. touchscreen) this task could be solved individually for each device, but since the screen refresh time is quite high and there's usually enough CPU power, we could build a thesaurus - a list of words used in the text to choose from.
Variant 1 Variant 2
http://docs.google.com/File?id=dqrcvtb_12dvmt5p8x_b http://docs.google.com/File?id=dqrcvtb_13gwwh2zdf_b
+ possible to navigate through thesaurus in upper part of the screen, selected words will be highlighted in the lower window + more free, unoccupied space
- not enough space for work (you can't move that fast through thesaurus) - delays (one second and more) while jumping back and forth will scare the users away, at least from using the device as a handbook
- if the screen is completely refreshed while it's redrawn (and not only a part of it) then forget this variant, it's actually unusable
  1. moving through ToC entries, and if possible - an automatic creation of a ToC
  2. a basket – the possibility to create new text snippets by adding certain parts of a book text to a new document, a convenient storage for quotes, formulas, definitions and other information for further usage

4. Secondary functionality

  1. A convenient way to manage bookmarks (especially when working with text snippets)
  2. Auto-scrolling (for particulary perverted :))
  3. Zooming of text and images ( + related navigation buttons)

4.1 Bookmarks

Types:

  • user-generated
  • automatically generated (e.g. html, if the format allows it)
  • ToC (if possible)

Types can be displayed separated from each other or all together – come up with a way to distinguish between those two types

Bookmark views:

  • ToC – bookmarks are displayed as-is (e.g. a list of links, and place a pictogram at the link target, so it's clear that you navigated to this point through a bookmark) This pictogram can be clicked, which will get you back to the needed ToC entry
  • automatically generated – same as above, boomarks are titles and subtitles, preferably using a visual hierarchy
  • user-generated -
    • if the user creates a bookmark, the bookmark can look like: "some_words_from_the_top_of_the_page"+"page_number/%current page"+"total number of pages"
    • user sets begin/end marks in the text, to be used as bookmark title
    • special bookmark – is automatically set to the point where the user finished reading/working and is clearly visually distinguishable from other bookmarks. Must be part of the list of all bookmarks.

User-generated bookmarks can differ from automatic ones by brightness and/or boldness. Actually, we need to come up with a global coloring solution for secondary interface elements (thesaurus, bookmarks etc) so that their redrawing would take a minimum of time.

Chapter B: views

So we have a couple of sections with views:

1. Bookshelf

view_1

List of books, sorted alphabetically, ideally: last_first_name - year - title

view_2

Like view_1, but a bit extended (even better if the user is able to change/rearrange the displayed columns):

Last, First NameTitlepage countread,unread,in progress...
William ShakespeareRomeo and Juliet500in progress (page 231 of 500) ...

view_3

One section with three columns or a section with three subsections:

  • read
  • unread
  • currently reading

Users are able to add custom sections, like "postponed", "recommend to a friend", "don't ever touch it", etc.

view_4

Sortings section. A simple list of books/documents. User can sort (through 1 or 2 clicks) by: author, title, year, full date, custom column or some other info.

view_5

Tags If we introduce a taggin system, then all above views could, actually, be based upon this view_4. This way the user can create a fully customized functionality and partly the interface. Once again: since there's no decent input device, we can delegate this functionality to a desktop program

view_6

Search. That's a tricky one: if we can search through the bookshelf then view_6 has a purely nominal meaning – it's much easier to find a book using view_4 "Sorting", if it's a real full text search then it's unclear whether the CPU, the software etc. will be able to handle it

Independent of the search type, it will look almost the same in all cases:

  • an alphanumeric row: 0-9,A-Z,А-Я;
  • hilited or displayed in the row are only existing letters and cyphers
  • the device is building a glossary (either only for titles or a full-text one)
  • user can make the search more precise by choosing from an attributes list ("by name", "within text", "in all books", etc.)

view_7

Same as view_1/view_2, but part of the screen is occupied by a window with an annotation or review for the selected book.

2. Reading

Combined sections of Chapter A "2.Continuous reading" and Chapter B "3. Working with textual content". Depending on current needs, the user is offered following views:

view_1: fullscreen

Clear text without any bells and whistles. Mode for continuous/page-wise reading or for advanced users, who have customized all buttons as needed.

view_2: custom fullscreen

Err, the screen is, like, full, but not so full actually :) By default there's a title, number of pages, percent read and labels for some buttons. View_1 is the default view (can be changed by user in the settings menu). View_2 – customizable mode.

view_3: work with text

Virtually all interface elements are displayed here. Virtually all that are available. Task: don't confuse the user ("bloody hell! too many buttons! get me out of here!") Initially we can display here the text navigation buttons, fast back/forward buttons, a "switch to search" button, a "quick settings menu" button, zoom, bookmarks and some statistics. The user should be able to customize it some time...

Sure, we could've skipped all those three views and put it all into the settings, so the user can manage it all by himself for each reading device individually. However, we read different books and we read them differently so I consider such a division quite rational.

3. Miscellaneous

view_1: bookmarks

The appearance stems from functions described in Chapter A, 4.1