Inside Menestrello — Part 4: Future work

This is Part 4, the last one, of a "behind the scenes" tour of Menestrello app. In this post, I describe some improvements and future work to be done on Menestrello. In Part 1 I gave the motivation that made us develop this app, in Part 2 I described its high level architecture, while Part 3 explained some of its advanced/experimental features.

Here is a list of features to be added or improved in Menestrello, divided into easy (= we will probably do them, sooner or later) and hard (= it is unclear we will have motivation and/or resources for them).

Easy (but time consuming)

Saving settings per-book

Currently the typography settings are saved globally, so if you switch between two books on which you need to apply several customizations for optimal reading, you will need to re-apply them every time you open a book. Thus, a very nice improvement would be saving them separately for each book, like Menestrello already does with the reading position. Since we have much of the required code in place, this is probably the feature that will ship in the next minor version (2.8.0).

EDIT 2014-07-27: implemented in Menestrello 2.8.

Saving internal book structure

In addition to saving the user settings, we also might want to store in the local storage, the parsed data representing the structure of each open EPUB files, like metadata, spine, ToC, Media Overlays data. This would allow us to avoid parsing the EPUB file every time it is opened by the user, resulting into a snappier UX.

Here the trade-off is between space consumption (and code complexity) and time. So far, on decent hardware, opening an average Audio-eBook takes just a few seconds, so we deemed it acceptable. However, on older devices or very large EPUB files, from selecting a title in the Library and its displaying in the Reader View a good 5-10 seconds might pass, which is not optimal. Again, here the main hurdle is the necessary code refactoring/extension, but this feature might make into 2.8.0.

And, of course, we will give the user an option to toggle it. For example, if her device has limited storage space, she might want to disable it.

Pagination

A couple of users asked for having the "traditional" paginated display of a book. I still think that pagination is not essential for Audio-eBooks, but thanks to CSS columns a first approximation is relatively easy to implement. (Yes, it is just an approximation of the better, but way more complex, pagination algorithms.) The major hurdle here is coding the machinery for switching between flowing text and paginated text, and the interaction with Media Overlays.

EDIT 2014-07-27: implemented in Menestrello 2.8.

Audio view

When displaying an Audio-eBook, Menestrello offers a progress bar with the associated counter and play/pause/stop buttons, and it also has a "Playlist" dialog for quick access to the chapters with audio. These functions decently serve the user when she wants to "just listen" to the audio, but here there is room for improvement. I would like to have a new view, similar to an audio-player app. And, of course, the ability to switch between the audio-only and audio+text views.

Better audio/file management

Right now, an audio file is extracted only when the corresponding chapter is being loaded into the WebView, e.g. when the book has been just opened, or the previous chapter has finished. This introduces a small delay (1-2 seconds), which might be avoided by proactively extracting the next track while playing the current one. Again, this would imply a trade-off between UX responsiveness and (temporary) storage used by the app.

Another really cool feature will consist in loading the audio resources from a remote URL when an Internet connection is available (making the EPUB files extremely light in comparison to embedding all the audio within the EPUB container), and caching them locally if offline consumption is desired at a later time.

Similarly, another nice feature will be the ability of fetching EPUB files directly from a URL or a cloud storage (e.g., Dropbox).

Parallel texts and other experimental stuff

Time/resources permitting, we want to extend our support for parallel texts, at least to publicly demonstrate that something can be done in this area by "general purpose" reading systems. (IMHO parallel texts eBooks will make evident the advantages of ("semantic") markup.)

E0 is another very interesting concept that I plan to explore. (See also here.)

Hard (and time consuming)

Better UI controls

Menestrello UI controls are really simple, featuring only panels, buttons, and sliders. This is mainly due to the fact we do not have a UI designer, so we rely on jQuery Mobile (jQM) and its theming mechanism, and a good deal of common sense and testing. Yet, we are well aware that some controls are not really great: for example, when selecting the font size in the Reader View, a slider might be more useful than pressing the size up/size down button repeatedly. (BTW, for this specific function, which is probably the most used, you can also directly pinch-and-zoom over the book text.)

The same goes for other UI details, like the contents of the list of books in the Library View: we rely on what jQM allows to put there "out-of-box", but the current display could be improved with a more appealing design, and a complimentary cover-only grid view.

Full EPUB (3) parser

As I mentioned earlier, Menestrello has a "reduced" OPF parser in native code as part of the Librarian plugin, while we wrote the full EPUB parser in JS from scratch.

When we started developing Menestrello, Readium SDK was very crude, hence unsuitable for our needs. Plus, the licensing terms of Readium SDK were and still are, unacceptable for a freeware (but closed source) project. The commercial alternatives we surveyed either were still too expensive or offered difficult/limited/poorly documented APIs, so we rule them out. (And, before you ask, integrating RMSDK into a hybrid app would have been a nightmare.) At last, we decided for a quick-and-(possibly, not so)-dirty approach, trying to minimize the amount of native code required, limiting the native parser to just extract the metadata needed to populate the library.

The full parsing of an EPUB file takes place (in JS land) after the user selects a book in the Library. In particular, this is the chain of events:

1. the user taps on a book in the Library;
2. the JS code asks the Unzipper native plugin to unzip the corresponding EPUB into a temporary directory, not extracting all the zip entries but those associated with audio files (this usually results in XHTML, CSS, PNG/JPEG, and SMIL files being extracted);
3. once completed, the JS code receives a callback, and starts the (full) parsing of the EPUB file, resulting in a JS object containing all the information required to properly display it;
4. at this point, if the EPUB has to be opened at a chapter associated with audio, the JS code asks again the Unzipper plugin to extract the required file only;
5. once completed, the JS code receives a callback, loads into the WebView the XHTML file, and starts the playback of the audio by notifying the MediaRB plugin, while simultaneously maintaining the timers for the synchronous highlighting.

Before embarking in coding our own EPUB parser in JS, we looked at the FOSS alternatives out there, readium.js and ebook.js in particular. The main problem we had with these library was that they were a bit difficult to hack into, to connect their inner mechanics with our app logic. Eventually, we decided to proceed on our own way, creating our own JS parser. This probably was a bad decision, and we are discussing whether dropping our parser to embrace readium.js. This move would automatically solve some issues/limitations that our parser currently has, but the cost/opportunity ratio is unclear.

Fixed layout

I have mixed feelings about Fixed layout eBooks (FXL). While I appreciate that for certain niches FXL is the right way to go, I hate seeing books that could have been reflowable, being produced as FXL just because "so we can add widgets/MO/JS", and not because they really needed absolute positioning of complex elements.

So, at the moment, FXL is not in our plans, but we keep our brains open to the possibility of working to support it.

Conclusions

Between the Android and the iOS versions, Menestrello is approaching 5,000 users, which I think is a quite remarkable result, considering its extremely experimental nature and very frugal development resources. I hope you enjoyed this "behind the scenes" tour of the app; if you have questions left unanswered about the app and its development roadmap, please feel free to write us!