We should have a system within Mulberry for controlling and maintaining page states across transitions. Things we might want to remember:
- where a scrolling region was scrolled to
- what screen of a multi-screen template was last viewed
- form data
The system would need to record these things and be able to store them during page destruction and recall them when the page is reassembled. It should also be able to maintain some things while a page is still in memory, as we may want to record some things during a page's lifecycle (e.g. a scrolling area that's constructed/destroyed on orientation change). The developer should also be able to control when this information is destroyed (either with an expiration date/time or by explicitly deleting it).
Pagedefs should support multiple means of displaying their content to parent nodes. This will make much more interesting collection components possible.
For example, a page could contain a subset version with its navigation stripped away that could be embedded into a digest page as a detail view on tablet, but could still be viewed as a child node on phones.
Collection layouts could also get more complex: if pagedefs had half and quarter layout screens, you could have a collection with a more magazine-style arrangement, with the first child node taking up the top half of the screen and showing off the content it contains appropriately, the next two taking up a quarter each, and scrolling below that a list of remaining child nodes. These boxes would have custom layouts tailored to the content they contain and directed from the child node.
Mulberry should be less wedded to tour.json &/or filesystems. Ideally, I'd love a bridging API with configurable modules, something vaguely like ActiveRecord or SQLAlchemy that can "translate" various different data sources into the models that Mulberry uses.
Mostly this means strengthening &/or better documenting the overarching model/routes/stores system Mulberry uses. It's possible we're 90% of the way there and just need to streamline it (i.e. do the other 90%).
Toss out tour.json and replace it with a SQLite database (+ add in the PhoneGap SQLite plugin). This could lead to a radically simplified workflow in MAP/Mulberry integration, make possible live preview, and allow Mulberry's default data structures to be much more flexible. It probably has a lot of pitfalls I haven't thought of, and is also a lot of work.
Mulberry's mobile web support is second-class (at best) because it's an entirely client-side framework; at present to open any page your device must download and parse the content of the entire site. That's bad.
A good solution would let Mulberry run on the server (probably using node.js) to parse the tour.json and tease it out into individual pages, and serve those to mobile web browsers, instead of foisting an entire app on to them.
An even better solution would allow the mobile web version of mulberry to assemble its content piecemeal by getting dribs and drabs of the app fed to it as json, on demand as the user navigated the app. It's possible this would be easier, as it might be able to appropriate pieces of the preview implementation in MAP.
Incidentally, this could also be a dramatic improvement for MAP's preview system.
We've discussed this before, but it'd be great to allow the option for components to have variables when they're called in the pagedefs. Something like:
- components:
- ChildNodes:
- showImages: true
instead of having a separate component for ChildNodesImageList.
Somewhat similar to the subpage display suggestion above, it'd be neat to have pagedefs work in different configurations depending on where they are in the app--for example, if a pagedef is used as the home node, it'd lose its top nav bar and gain the app nav bar. (We would then no longer need specialized home templates.)
I'm not sure if there are other use cases beyond the above, or what other sorts of things we might want pagedefs to react to.
The sliding sibling nav drawer should be overhauled. It's poor UI, buggy, and conflicts with ads. Instead of a sliding drawer, we should just have forward/back buttons as part of the app chrome (similar to the NYT app, e.g.).
Once we've pulled the toura components out, we should put in some standardized elements for developers to build on. For example:
- nav bar
- tab set
- list view
- image gallery
- video player
- audio player
- modal window
- button
- popup
- split view
- hideable caption
Many/most of these can be pulled/adapted from the existing toura components, and the toura components should then be retrofitted to extend these components.
One thing I'd like to discuss is how to improve our testing setup. 2 goals:
I think these goals are achievable if we move away from relying on capybara -- either directly or indirectly through technologies like evergreen -- and write most of our tests directly in Jasmine (or perhaps Mocha) without dependence on a server. Mulberry is at its core (mostly) a purely client-side technology and tests should generally not depend on a server. We should be able to stub/mock servers using sinon for those cases when we do. Having our tests depend on nothing but a browser and testing libraries allows us to do a couple of neat things:
this is an approach that i've just started to implement myself on my own projects.