Skip to content

1.next planning

Jump to bottom Edit New page
toddparker edited this page Nov 23, 2011 · 12 revisions

This is not a final or prioritized list for 1.1. Instead this is just a discussion document to get us thinking about some of the key areas to focus on that we can refine into a roadmap.

Page transitions

  • need a re-think to embrace the constraints we have - scrolling the docs can't be avoided, but we cn hide the jumpiness = introduce 1-2 new transitions that are smooth on all our platforms
  • video sketch for animations (slow to illustrate the steps) - http://www.youtube.com/watch?v=di3-fz5TZKQ
  • consider packing the new transitions with the switch from keyframe-based animations to transitions so we can package these with Opera, Firefox and IE10 support
  • speed up page load/enhancement/transition time overall

Fixed headers

  • The dynamically re-positioned bars are just not good enough and they seem cause cause issues with virtual keyboards on Android if you put form elements inside.

  • Re-think whether we should use or dynamic re-positioning script or just use position:fixed since browser support is pretty solid. Some browsers that "snap" into place look like our dynamic re-position script anyway. Watch the video for results. Sounds like there may be some bugs with 2.2 and even iOS5 with fixed - see comments: http://bradfrostweb.com/blog/mobile/fixed-position/

  • We have a few avenues to explore:

  1. The touchOverflow (iOS5) feature gives us true fixed toolbars by placing them outside of scrolling regions. To make this work in more places, we'd need to both push on brewer makers and consider a polyfill for older platforms - either focus on finishing scrollview or just support the ability to drop in other scrollers as a polyfill.

  2. Replace the dynamic re-position script with just position:fixed CSS rules and refine by doing lots of testing and targeting (i.e. don't add this rule to growers that do bad things). Seems like this is supported in a fair number of platforms and falls back gracefully for the most part (see link move for support details).

On that specific point, I think it would be cool to add a new option for the initial behavior:

  • hidden by default
  • visible by default, but auto-hide after X seconds (like the iOS video player)
  • visible by default

We already have an option to turn the tap to hide/show behavior on or off.

scrollOverflow & scrollview

  • Need to do more testing and debugging to see how smooth we can make this. I have concerns over the smoothness of scrolling in OS5 and how long it will take for other platforms to achieve acceptable performance to rely on this.
  • Also think about whether we should leverage the same dual container model to allow a scroller polyfill to be hooked in
  • Figure out a plan for scrollview - does this become official at some point or maintained by Adobe? What work is needed to get this ready? How many resources do we dedicate?

Touch Events & Scrolling

  • Improve scrolling performance by tweak how we handle events (and maybe also force pre-rendering)
  • Can we make mouse more reliable? Confusion about how to use this
  • Look into touch event model for IE10

Dialog

  • new markup so dialog is in a wrapper, overlay is a sibling, not a parent
  • eliminate the scroll up/down when a dialog is opened/closed
  • don't delete the parvenus page when a dialog is open, most times people go back
  • consider having the dialog sit over the previous page

Link-based buttons & navbars

  • support disabling? lots of people asking to to do this, even though technically disabling a link is odd, even if it looks like a button
  • general confusion between link that looks like a button (buttonMarkup) and the button plugin

Tablet optimized layouts

  • Review work already done by Sven - http://www.stokkers.mobi/valuables/multiview/page2.html
  • Work out the key use cases we want to support in core, plan extension points
  • Use media queries with a polyfill like respond.js to do the heavy lifting
  • Figure out how to deal with hsitory and deep-linking in a rational way
  • Create lots of small atomic tools we can assemble into larger demos:

Ajax include pattern (new plugin)

  • a link on the page points to a page or fragment, at certain screen widths, this link is used to formulate an AJAX request that essentially works like an include.This way, at smaller screen sizes you can have a link to view the weather forecast but at desktop sizes, you can load the module in.
  • control where the content goes: replace the link, append before/after
  • decide the min width breakpoint to AJAX load the content
  • encode what fragment to pull in, either through a data-attribute or force them to use an ID so we could do: foo.html#fragment

Popup/popover (new plugin)

Navigation (new plugin)

  • add a few simple responsive design navigation patterns to transform a horizontal nav bar into a menu, hide/show a search icon, etc.

Responsive layout grids

  • create a few simple RWD layout patterns and focus on documenting how to write your own custom ones (this is all/mostly CSS)
## Ajax include pattern

Looking at the multi-pane, dialog, and other future widgets like tabs, I think we need to try to leverage the nav model more to provide simple tools for loading content. Here are the basic capabilities we need to support:

  • Use a link to load content into any container (page, dialog wrapper, random div on the page)
  • The link can either point to a local resource (#foo) or AJAX load and auto-enhance external resources
  • Broaden our thinking to use the nav to not just load pages, but any snippet of content
  • Animate the loading process - at a minimum, show the spinner, then fade in the content but ideally use any standard transition to show a page, dialog, popup, or update a container on a page
  • Option to add this change to the history stack for back button support
  • Option to prevent the change from being deep-linkable (requires #4 if yes)
  • Show content in a floating modal popup layer with all the same options as above
  • Add the ability to do actions based on media query type info. Ex. Load this content above 480px to allow this to work like an AJAX include that only triggers at a larger screen size = load in the left panel content if we're on a tablet or larger

So we could make links more powerful by extending the current system a bit. Combined with the responsive web design layout techniques, this could accomplish all the multiview panel functionality with less code and more flexibility. For example, you could only load in the left panel (mailbox list) on tablet and larger devices and drilldown within this panel to a message list by having each folder link target the left panel container. The message list links could target the right panel. The key is only load the essential content for a view on a smartphone, then lazy load in other assets on larger screens.

By breaking apart all these features into link capabilities, you could build a simple tab strip by having each tab target a block below to update it when each is clicked. Or build a simple slideshow pager by having the previous/next links target the image container and either reference local images (#) or external images pulled from a page (a href="image.php?id-123" data-target="#slideshow" data-load="div.photo"). Or make a popup menu by linking to a listview (#nav) with rel="popup". You can make a ton of widgets by mixing these attributes.

In a nutshell: add the ability to point to local (#) or external (page.html) content fragments (load ="my-selector") then either throw that into an overlay (rel=popup) or use the content to update something within the page (target="selector"). Choose whether these should be history tracked and deep-linkable.

Here are some of the key link attributes, some old, some new:

href="#local-content" or "content.html" Just like we do with pages now, a link can either point to a local ID or external page for content. The only difference is that we can broaden the link to not just point to a "page" but also to a snippet of content that will be loaded into a container (the data-target) to let this work as both a client-side include or as a way for a link to update a portion of the screen.

data-target="#primary" We assume the link will replace the data-page container, but if the target is set, the response of the AJAX request will replace the contents of this jQuery selector. This would allow people to load content into any block on the page, inside a popup, or even use the link like an AJAX include by setting the target to the ID of the link itself. In a panel or popup, a link could update the panel or popup itself which is effectively a drill down. (default to data-page container)

data-load="#main" When loading an external page, we assume you want the data-page container, but this allows you to specify any selector to grab content from. We trigger create as part of this process to enhance everything. (default to data-page container)

data-history="true" Add the link action to the history stack (default to true for Back button support)

data-deeplink="true" Add the link action to the history stack (default to false)

rel="popup" Popup is just the most simple modal overlay wrapper. We can keep the dialog rel too, but this may just be a standard configuration of these basic options so they don't need to be set them multiple times. Or maybe

data-load-trigger="max-device-width: 480px" Specifies a media query for automatically triggering the link action. For example, above 480 pixels, load in the foo content

data-transition Transition for the load. I think we'd do the transition (slide, fade) then show the loader embedded inside the container (page, div, popup). When enhanced, we'd fade the content in over the loader.

data-theme Theme for the popup

data-overlay-theme Theme for the overlay

History tools

  • expose a simple way to let people include/exclude links or other JS-based actions in the history stack

Ajax nav

Download builder

Search for docs
Add a custom footer
Add a custom sidebar
Clone this wiki locally