Roadmap: 3.0 release

[joseph]

The 3.0 release will be the next major release after 2.2.

Goals:

• Retire support for all iOS versions below 4.2. This primarily gets rid of the TouchMonitor workaround, which I'm very proud of, but which is quite bloated. (Disagree? Leave a comment below.)
• Retire legacy flipper support. Now that Opera has columns, there's not really much point to the legacy flipper, and everyone loves to hate it. Basically, if a browser doesn't do columns (IE), you can't run Monocle. At Booki.sh we use Google ChromeFrame for IE users, and we just have no solution for Windows Phone.
• Clean up Monocle.Events. In particular, improve the touch/pointer coordinates calculations.
• Overhaul Monocle.Flippers.Scroller. Improve speed and tactility. Investigate two-page spread in landscape environments.
• Recommend a flipper class based on the browser environment. It'll go something like this: desktop+iOS: Slider, Android 3: Scroller, Kindle+eInk+Android < 3: Instant. You will be able to override this with the flipper option to Monocle.Reader, of course.
• More automated testing!
• Further investigation of preloading content, including revisiting the thorny problem of whole-book page numbers.

I expect some minor API changes to result from this work, but trivial implementations should be unaffected.

[aronwoost]

Count me in for retiring <iOS4.2 and legacy flipper! I think it would be good for monocle to have a more clear and compact codebase. Therefor it's totally fine to focus on the things monocle is good in and leave out "edge cases". It might sound harsh to name IE "edge", but hey, this is the reality in times of html5. Windows mobile might be an issue, but I think we will see alternatives there (or are there already?).

All other things sound great also!

However, lets do the total page numbers in monocle 5.0... ;)

[quangvu3]

Good news is Monocle appears to work (with a few rendering issues) on IE10 (Win 8 Preview). However, the lib could be much more compact (and popular) if it based on an established JS framework like jQuery.

Total page numbers can be calculated if we know percentage of every chapter on the whole book length, I suppose.

[joseph]

Zero dependencies is a key feature of Monocle.

Requiring a generic framework like jQuery would substantially bloat overall Monocle script footprint. It's not clear to me what benefit it would bring. It might shave a few lines from Events, Factory and CSS? Maybe a kilobyte or two all up. Right now, Monocle plays along with jQuery, Prototype, MooTools, YUI, or any other popular framework; I don't see why we would narrow the ambit.

I'm very happy to see a counter-argument developed in a fork, of course.

[joseph]

As for page numbers, yes, I have been thinking that a getPercentageOfComponent optional function in the book data is the path we'd take, along with a running tally of actual page counts for accessed components (since the last resize/resize/recalculate). The problem, of course, is that percentages are arbitrary.

A component with three paragraphs and thirteen images — how do you calculate its percentage? Number of bytes? That would be wildly different to a component with 36 paragraphs, although they might both be 14 pages long. Even if you did something insane server-side, like run every book through a headless Monocle and calculate exact percentages, you will still get substantially different percentages at another resolution (because of full-height images, margins, etc), or with minor modifications to the stylesheet (like line-height or font-size).

Ultimately the only way to get precise page numbering is to load every component into a page frame on each recalculate, which would be obscenely slow and CPU-intensive on mobile devices. So there's no perfect accuracy; I guess the question is whether, with total page count, close enough is good enough.

[quangvu3]

I think it's not only about saving a few KB but community supports and it would be easier to extend the lib (like creating custom flipper effects) for many developers who are familiar with jQuery/Mootools/...

There may be no total solution for calculating exact page numbers, but sth like getPercentageOfComponent could be used in some kinds of app (web view app, for example) where screen width/height are fixed IMHO

[aronwoost]

Monocle even works with vapor.js. Lets keep it that way... ;)

[joseph]

Work is underway on 3.0 in the retirements branch. I think a 3.0 release will probably be a few months off, so you should definitely upgrade to 2.2 on all active projects.

[joseph]

Just an update on this. The first three points, plus a few other things, are covered in the retirements branch. I've got a couple of experiments in master — selection events and proportional font-sizing — that I'll roll into the next major version too.

I think I'll chicken out of calling it 3.0 for now, even though there are a few compatibility implications for legacy platforms. Probably looking to push out a 2.4 release instead, this week or next.

After that we can talk about 3.0 plans again — I have a few ideas I want to thrash out.

[aronwoost]

I'd love to see that selection stuff in monocle! Makes no sense that everyone is implementing a own custom solution.

Also big up for the mobile safari deselection solution. Because of that bug and the inability to get copy events in iOS < 5 we entirely disabled selection on iOS.

[joseph]

Great! The plan with selection events is pretty straightforward: a monocle:selection event is fired (with all sorts of data in the evt.m object) every time text is selected or the selection is changed, using a poller. A monocle:deselection event is fired the first time nothing is selected after a selection.

So you would likely see many more monocle:selection events than monocle:deselection events. If you are working on logic that needs to know whether a selection has been changed, you would track that yourself by comparing event data. Hopefully this is a simple and complete API for a wide variety of needs.

I've just added a ticket for a new interaction model that has implications for selection (it should make it much easier for users). See #87.

[gerald1248]

Thanks for the amazing work you're doing on Monocle.

The fourth point (tactile scroller, possibly two-page spreads) would be huge for us. Am I right in thinking the new magic panel will help with this? My best guess is slide will become the default transition on most ebook readers soon.

[joseph]

Yes, I'd definitely like to see a smoother Scroller flipper. But I must admit I've always bet on the 'slider' style over the 'scroller' style for a user experience reason. With the slider style, when paging forward, the next page of text is stationary, which makes it easier for your eyes to find reference points. You're not trying to "follow" the animation over time. I find this reduces fatigue.

But I'd still like to do a better scroller.

As for two-page spreads, at the moment, I think the best opportunity is in the CSS element() property. Try this out in the latest alpha of Firefox:

http://monocle.inventivelabs.com.au/static/scripts/src/test/experimental/moz-element-flipper/index.html

I'm currently encouraging the WebKit team to adopt this property — it would have implications for all sorts of Monocle things.

[joseph]

While I'm here — there's a preview of the new Selection and Formatting (proportional font-sizing) features in the twofour branch, which replaces the old retirements branch.

Please kick the tyres if you're likely to use these features.

[gerald1248]

Re sliding/scrolling, Firefox and two-page spreads - I agree, the demo looks great on Firefox. You're also absolutely right about the reference points when going to the next page, but in terms of what users perceive as intuitive and tactile on touch screens my (Monopoly) money is on sliding. Looking at how the CSS lays out fixed-height columns (your Monocle docs are the best explanation of the feature I've seen anywhere) it also feels like a more straightforward implementation, something that can be optimised for performance more easily.

Re selection and formatting - Yes, they look great! I've given selection and formatting a spin and they're miles better than the messy stub we'd put in to make selection and highlighting possible.

[patrickmesana]

Any news on 3.0 release ?

[joseph]

The twofour branch has most of the planned features. Progress has slowed a bit for incidental reasons: I have one hand in a cast so I'm not super-productive. But a stable release is not too far away.

[nono]

Maybe this issue can be closed now that Monocle 3.0.0 has been released.

[jlbruno]

Agreed. I'd love to know what the roadmap looks like now, @joseph