johnnyS:
Quote:
|
I like Google Chrome browser's approach to space - to allocate as much space as possible to content and minimize chrome as much as possible. It seems that other browsers are taking this approach to space also. From this point of view it seems to me that the bottom bar in content pane is unnecessary and takes precious space which can be used for displaying publication. Of course, bottom bar contains much used buttons, but instead of Bookmark, Previos/Next, Increase/ Decrease font buttons keybindings can be used or functionality of some of these buttons can be placed in browsers toolbar (Bookmark and Increase/decrease font). It seems to me that it would be great if in Preferences dialog it were an option enabling to hide/display bottom bar of the content pane.
|
johnnyS:
Quote:
The question about bottom is not so much about saving 35 pixels but more about intrusiveness of EPUBReader's interface. From my point of view EPUBReader should not force on user the ways of navigating through and customizing of the publication. Ways of navigating and customizing should result from choices of publication authors and readers. Since EPUB format is essentially HTML + CSS and possibly some scripting, in many ways navigation and customizing can be built-in inside publication. For example, nothing prevents to add Previous/Next links inside each page; or, with the help of some scripting, to add font chooser or font size chooser, or style switcher allowing to choose among completely different page styles. In such cases some or all bottom bar buttons would duplicate publication's functionality or even interfere with it. (EPUB specification does not incourage scripting, but also does not forbid it - it says user agents "should not" execute scripts inside publication; it does not say "must not").
That's main reason because I advocate the concept that botton bar buttons and all bottom bar should be optional (shown by default but having possibility to be hidden).
|
I agree with this line of reasoning. I seems to me that all our thinking about ebooks is too much influenced by the analogy of physical, linear book. Analogy of the website would serve us much better. And as in the websites there are no obligatory Previous/Next buttons (and some other) on the bottom of each page so in an ebook there is no need for such obligatory buttons on each page. As website authors are free to create navigation suitable for the site so ebook authors should be free to create navigation systems best suited for their publications.
I would like to press Johnny's suggestion to its limits: not only the reader should be able to fully customize the interface of EPUBReader in the sense that he should be able to open/close any available panes or remove/restore any buttons, but publication authors also could be able through some API to set default interface of the publication. E.g., if the publication author finds it useful he could set that the publication by default should be displayed with TOC closed/opened, with or without Previous/Next buttons, with or without font-size changer etc. I don't think that such API needed right now; I presented idea of it only to show that our current thinking about ebooks is quite limited and that Johnny is right saying that EPUBReader's interface should not pressuppose anything about what is needed or not needed for publications. In other words EPUBReader should give maximum freedom for creativity of ebook authors not only in the matters of content but also in the matters of interface.