Todd, thanks for including us in your presentation at jsconf :)
sorry it took me so long to do this post, been busy with work, and went on holiday for a bit (needed that :) )
ok, so here's what i learned building splitview, and some heads up on the issues you may face when you do:
issues:
1) changePage
changePage currently assumes there is only one pageContainer and one activePage - that's not too big an issue, except when pageTransitionQueue comes into the picture - multiple page transitions on different panels just can't happen, because changePage is not panel aware. I did a very simple fix to this in my fork by putting in a new parameter for changePage called container, and renaming the 'to' parameter to targetPage (because changePage changes the 'to' var before unshifting it into the queue)
2) persistent footers and headers
Footers and headers - especially persistent ones, dont work with splitview because it is also not panel aware - when you click on a link that's on the menu panel, but you transition a page that's on the main panel, the footers on the menu panel get persisted on the main panel - messes things up. haven't worked on this yet, coz it was a little lower on my priority list. :)
also, I was checking out apple's mail app on both the iphone and the ipad, and i saw that the footers and headers are pretty much interchangeable. for example,
you can see that the shortcut buttons sit at the bottom of the page as a footer, but in the ipad:
you can see that the same footer with the same shortcuts (minus the refresh button) is now sitting up top, as a header, probably because it enhances readability, and removes clutter (not too many headers and footers). I believe we should be able to provide the same kind of flexibility for our headers and footers. what if, instead of defining data-role="headers" and "footers", we define a data-role="toolbar" and assign its position by data-position="header, footer, top, bottom" etc? just a suggestion
3) Active buttons
I still haven't quite figured this out yet, but we need to figure out how active buttons will work when dealing with two panels - example, if I put a 'next' and 'prev' button on the main panel, and use that to change pages (for example when looking thru emails) - how would the menu panel's active menu link be changed?
this is also an issue due to the inability to have persistent footers - so navbar buttons will have to be clicked twice before the button has an active class. this isn't too hard to fix tho.
4) Scrolling
I've had some users of the splitview plugin asking me about issues they've had with scrolling. when i pointed them to iScroll4, they came back telling me everything was fixed. How about integrating iScroll4 into jquerymobile? I checked the code size - when you include easing and scrollview, the size is approximately the same as iScroll4 - i could be wrong tho :P (could've forgotten to check min versions)
5) $.mobile.media
I tried to use this to test for screen width when a resize event occurs, but found that for some reason, on the iPad, it generates a lot of fakeBody elements and doesn't remove them after. it practically crashed splitview on the iPad so i went instead to just checking for $window width.
6) history and transitions
for some reason, when going thru a bunch of pages on the main panel (generating a lot of history entries) - and then when hitting the back button a few times, you'll find that the page transitions, but sometimes in reverse, and sometimes not in reverse. i think this is a small issue, but i haven't debugged it yet.
Things to think about (heads up)
1) context pages
some pages are just plain related to each other so much so that when you bring one up on the menu panel, the other page needs to appear on the main panel. for example, when you bring your inbox list into view on the menu panel, the first email (or first unread) needs to appear on the main panel. if the main panel doesn't transition, it just wudn't make sense (what if i was viewing a sent message previously?).
in splitview we fixed this by setting a data-context attribute either on the panel, or on the page itself. the data-context value needs to be a jQuery selector that points to an anchor tag in the particular page that's being brought up.
2) CSS grids and font sizes
I think there are two types of grids that jquerymobile may need. one is the current grid you have - one that scales according to screen width - mainly for buttons, navbars etc. the other one is a grid that drops to one column as the the screen size shrinks - checkout cssgrid.net. this is mostly for content - you have way too many empty space in desktop/tablet view without grids. but the grids need to fallback to a single column for mobile view. the work done by Andy at cssgrid.net is a really good base to start things from. This is what I'm currently working on.
the other thing is also font and ui element's size - when viewed in desktop, they are just way too big to be optimal for usability. also something I'm working on right now.
3) crumbs and history tracking
currently, only main panel is tracked in history - seems to work ok for now (tracking history for both panels seemed a little clunky when you actually use it), but one issue i seem to see is context. when i move back in history, only the main panel is changed. the menu panel doesn't, and this puts context at risk. I'm currently unsure of how to do this - haven't thoroughly thought this thru yet.
maybe in the future, each historystack entry tracks an entire queue of pageChanges?
also, crumbs - since some pages don't need page history tracking, but you do need some form of traversal, i created the crumb button - which basically changes the back button to a button that references the previous activePage on that panel.
that's about it from me now - I'll post some more ideas or lessons learned as i develop splitview more.
Hope this helps. thanks!
Asyraf Abdul Rahman,
CEO, CS8,
www.cs8.my