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.
I agree with almost all of these, so I'll just point out the few I don't or have issues with or have something to add.
Scrapping tour.js for SQLite: If it depends on a PhoneGap plugin, what do we do on mobile web? If you're talking about using WebSQL, then that would work, but it seems it would make MAP/mulberry syncing much more complicated. If you're talking about constructing a SQLite database and then dropping that into an app, that's going to depend on a PhoneGap plugin which seems to only exist for iOS and isn't up to date with the latest PhoneGap (https://github.com/davibe/Phonegap-SQLitePlugin)? I can see how we'd want to have better support for other data structures than the limited tree structure represented in tour.js. @TheGoldenToilet can probably speak more to this, but dojo.Store isn't dependent on a json implementation. We could add Stores that are backed by WebSQL. But I'm really hesitant to do that since WebSQL is deprecated and I don't want to bake-in dependency on something that's deprecated. And Windows doesn't support it. We don't support Windows yet, but I don't want to tie our hands if we want to support it.
Sibling Nav overhaul: This seems like very Toura-specific functionality that I'd like to remove from the core framework. I agree, the implementation should be improved, but this seems more like a Toura problem than a Mulberry problem.
Standardized Component Library: Agreed. Very much so. Although I'm curious what you mean by nav bar. This should be standard, but customizable with your own buttons. This is already possible, but it's not as clear or easy as it should be.