- From: Mikko Rantalainen <mikko.rantalainen@peda.net>
- Date: Tue, 07 Jun 2011 14:45:04 +0300
I'm pretty sure that most people on this list have seen page transitions in Internet Explorer 5.5+ (http://msdn.microsoft.com/en-us/library/ms532847%28v=vs.85%29.aspx#Interpage_Transition). I think that web application user experience could be improved if transitions between pages were supported. However, I'm also pretty sure that the implementation in IE 5.5+ is not a good one because it gives too much power to the page author and too little control for the user. I'll start with a use case: I have a web service/application that has a wizard for registration. The wizard consists of multiple forms (HTML pages) that must be filled in a sequence. Each form has "Next" and "Previous" submit buttons. I think that the user experience would improve if I could attach transitions to these buttons. I'd like to have "slide the next page from right" for the "Next" button and "slide the next page from the left" for the "Previous" button. (If you have seen Android Phone OS and it's system menus, this is very similar setup - it slides the next screen from right when selecting a submenu item and it slides previous screen from the left if one presses "back" button. Android also uses zoom in and zoom out to represent opening an application and returning to the home screen.) The things I don't want to have in this specification (page author control): - actual transition animation ("slide the next page from the left") - transition duration - ability to specify easing for transition movement Instead there should be a method for defining that submitting a form with a given button, the UA should use transition to "next page". Hitting another button on the same form should use transition to "previous page" and hitting some link should use "closing" transition. The transition to use for "next page" is up to UA and user preferences. I'd prefer that UA started the animation immediately instead of waiting that the next page is ready. If the animation were slow, it could re-render the next page on the fly during the animation as pieces of next page come ready. Note that the "next page" button may or may not match with rel="next" and as such, I think that there should be additional method for specifying this kind of relation. Perhaps the attribute should be called "transition" with possible values such as: * next (advance to next part of the sequence/drill down the menu system, possible transition could be sliding the current page towards left and the next page sliding in view from right) * prev (go back to previous part/return upwards menu, possible transition could be reverse of next) * open (open a document e.g. open a google docs document from the list of possible documents, possible animation could be zoom to the next page) * close (close current document e.g. close currently edited document and return to the list of possible documents, possible animation could be reverse of open) * swap (replace the current view with another view with some transition that gives a hint that the previous view was not destroyed e.g. select another "open" google document from some kind of quick menu, perhaps some kind of 3d animation where page rotates around vertical axis and another page is behind it) I think that it would make sense to use "next page" transition for rel="next" by default, but there's a need to attach "next page" transition to interactive elements other than rel="next". I think that this could be sensible to have in HTML instead of just in the CSS (or some other method) because it's possible that other software but just the styling system could use the information about target type for links and buttons. This needs to be implemented by the UA because transitions between different URLs cannot be implemented with JavaScript unlike in-page transition effects and animations. -- Mikko
Received on Tuesday, 7 June 2011 04:45:04 UTC