24 Apr 2015

feedPlanet Openmoko

Chris Lord: Web Navigation Transitions

Wow, so it's been over a year since I last blogged. Lots has happened in that time, but I suppose that's a subject for another post. I'd like to write a bit about something I've been working on for the last week or so. You may have seen Google's proposal for navigation transitions, and if not, I suggest reading the spec and watching the demonstration. This is something that I've thought about for a while previously, but never put into words. After reading Google's proposal, I fear that it's quite complex both to implement and to author, so this pushed me both to document my idea, and to implement a proof-of-concept.

I think Google's proposal is based on Android's Activity Transitions, and due to Android UI's very different display model, I don't think this maps well to the web. Just my opinion though, and I'd be interested in hearing peoples' thoughts. What follows is my alternative proposal. If you like, you can just jump straight to a demo, or view the source. Note that the demo currently only works in Gecko-based browsers - this is mostly because I suck, but also because other browsers have slightly inscrutable behaviour when it comes to adding stylesheets to a document. This is likely fixable, patches are most welcome.


Navigation Transitions specification proposal

Abstract

An API will be suggested that will allow transitions to be performed between page navigations, requiring only CSS. It is intended for the API to be flexible enough to allow for animations on different pages to be performed in synchronisation, and for particular transition state to be selected on without it being necessary to interject with JavaScript.

Proposed API

Navigation transitions will be specified within a specialised stylesheet. These stylesheets will be included in the document as new link rel types. Transitions can be specified for entering and exiting the document. When the document is ready to transition, these stylesheets will be applied for the specified duration, after which they will stop applying.

Example syntax:

<link rel="transition-enter" duration="0.25s" href="URI" />
<link rel="transition-exit" duration="0.25s" href="URI" />

When navigating to a new page, the current page's 'transition-exit' stylesheet will be referenced, and the new page's 'transition-enter' stylesheet will be referenced.

When navigation is operating in a backwards direction, by the user pressing the back button in browser chrome, or when initiated from JavaScript via manipulation of the location or history objects, animations will be run in reverse. That is, the current page's 'transition-enter' stylesheet will be referenced, and animations will run in reverse, and the old page's 'transition-exit' stylesheet will be referenced, and those animations also run in reverse.

[Update]

Anne van Kesteren suggests that forcing this to be a separate stylesheet and putting the duration information in the tag is not desirable, and that it would be nicer to expose this as a media query, with the duration information available in an @-rule. Something like this:

@viewport {
  navigate-away-duration: 500ms;
}

@media (navigate-away) {
  ...
}

I think this would indeed be nicer, though I think the exact naming might need some work.

Transitioning

When a navigation is initiated, the old page will stay at its current position and the new page will be overlaid over the old page, but hidden. Once the new page has finished loading it will be unhidden, the old page's 'transition-exit' stylesheet will be applied and the new page's 'transition-enter' stylesheet will be applied, for the specified durations of each stylesheet.

When navigating backwards, the CSS animations timeline will be reversed. This will have the effect of modifying the meaning of animation-direction like so:

Forwards          | Backwards
--------------------------------------
normal            | reverse
reverse           | normal
alternate         | alternate-reverse
alternate-reverse | alternate

and this will also alter the start time of the animation, depending on the declared total duration of the transition. For example, if a navigation stylesheet is declared to last 0.5s and an animation has a duration of 0.25s, when navigating backwards, that animation will effectively have an animation-delay of 0.25s and run in reverse. Similarly, if it already had an animation-delay of 0.1s, the animation-delay going backwards would become 0.15s, to reflect the time when the animation would have ended.

Layer ordering will also be reversed when navigating backwards, that is, the page being navigated from will appear on top of the page being navigated backwards to.

Signals

When a transition starts, a 'navigation-transition-start' NavigationTransitionEvent will be fired on the destination page. When this event is fired, the document will have had the applicable stylesheet applied and it will be visible, but will not yet have been painted on the screen since the stylesheet was applied. When the navigation transition duration is met, a 'navigation-transition-end' will be fired on the destination page. These signals can be used, amongst other things, to tidy up state and to initialise state. They can also be used to modify the DOM before the transition begins, allowing for customising the transition based on request data.

JavaScript execution could potentially cause a navigation transition to run indefinitely, it is left to the user agent's general purpose JavaScript hang detection to mitigate this circumstance.

Considerations and limitations

Navigation transitions will not be applied if the new page does not finish loading within 1.5 seconds of its first paint. This can be mitigated by pre-loading documents, or by the use of service workers.

Stylesheet application duration will be timed from the first render after the stylesheets are applied. This should either synchronise exactly with CSS animation/transition timing, or it should be longer, but it should never be shorter.

Authors should be aware that using transitions will temporarily increase the memory footprint of their application during transitions. This can be mitigated by clear separation of UI and data, and/or by using JavaScript to manipulate the document and state when navigating to avoid keeping unused resources alive.

Navigation transitions will only be applied if both the navigating document has an exit transition and the target document has an enter transition. Similarly, when navigating backwards, the navigating document must have an enter transition and the target document must have an exit transition. Both documents must be on the same origin, or transitions will not apply. The exception to these rules is the first document load of the navigator. In this case, the enter transition will apply if all prior considerations are met.

Default transitions

It is possible for the user agent to specify default transitions, so that navigation within a particular origin will always include navigation transitions unless they are explicitly disabled by that origin. This can be done by specifying navigation transition stylesheets with no href attribute, or that have an empty href attribute.

Note that specifying default transitions in all situations may not be desirable due to the differing loading characteristics of pages on the web at large.

It is suggested that default transition stylesheets may be specified by extending the iframe element with custom 'default-transition-enter' and 'default-transition-exit' attributes.

Examples

Simple slide between two pages:

[page-1.html]

<head>
  <link rel="transition-exit" duration="0.25s" href="page-1-exit.css" />
  <style>
    body {
      border: 0;
      height: 100%;
    }

    #bg {
      width: 100%;
      height: 100%;
      background-color: red;
    }
  </style>
</head>
<body>
  <div id="bg" onclick="window.location='page-2.html'"></div>
</body>

[page-1-exit.css]

#bg {
  animation-name: slide-left;
  animation-duration: 0.25s;
}

@keyframes slide-left {
  from {}
  to { transform: translateX(-100%); }
}

[page-2.html]

<head>
  <link rel="transition-enter" duration="0.25s" href="page-2-enter.css" />
  <style>
    body {
      border: 0;
      height: 100%;
    }

    #bg {
      width: 100%;
      height: 100%;
      background-color: green;
    }
  </style>
</head>
<body>
  <div id="bg" onclick="history.back()"></div>
</body>

[page-2-enter.css]

#bg {
  animation-name: slide-from-left;
  animation-duration: 0.25s;
}

@keyframes slide-from-left {
  from { transform: translateX(100%) }
  to {}
}

I believe that this proposal is easier to understand and use for simpler transitions than Google's, however it becomes harder to express animations where one element is transitioning to a new position/size in a new page, and it's also impossible to interleave contents between the two pages (as the pages will always draw separately, in the predefined order). I don't believe this last limitation is a big issue, however, and I don't think the cognitive load required to craft such a transition is considerably higher. In fact, you can see it demonstrated by visiting this link in a Gecko-based browser (recommended viewing in responsive design mode Ctrl+Shift+m).

I would love to hear peoples' thoughts on this. Am I actually just totally wrong, and Google's proposal is superior? Are there huge limitations in this proposal that I've not considered? Are there security implications I've not considered? It's highly likely that parts of all of these are true and I'd love to hear why. You can view the source for the examples in your browser's developer tools, but if you'd like a way to check it out more easily and suggest changes, you can also view the git source repository.

24 Apr 2015 9:26am GMT

29 Mar 2015

feedPlanet Openmoko

Michael "mickeyl" Lauer: freesmartphone.org API docs live again

After the outage of the VM where freesmartphone.org has been hosted on, we are now almost fully back. I have integrated the DBus API documentation (that has been hosted on the doc subdomain) into the top level documentation which now lives at http://www.freesmartphone.org. The source code has already been moved to https://github.com/freesmartphone and the new mailing list has been alive for a few months at goldelico.

Now that the documentation is live again, I have plans for short, mid, and long term:

1. Short-term I'm working on completing the merge to libgee-0.8 and then cut the next point release.

2. Mid-term I want to discuss integrating the unmerged branches to the individual subprojects and continue cleaning up.

3. Long-term I'm looking for a new reference hardware platform, funding, contributors, and decide whether to move the existing reference platform to kdbus (or another IPC.)

If you have any plans or questions with regards to the freesmartphone.org initiative and its subprojects, please contact me via the FSO mailing list (preferred) or personally.

Der Beitrag freesmartphone.org API docs live again erschien zuerst auf Vanille.de.

29 Mar 2015 12:21pm GMT

22 Mar 2015

feedPlanet Openmoko

Michael "mickeyl" Lauer: RFC: Future of SidPlayer, ModPlayer, PokeyPlayer for iOS

This is a post about the state of Sid-, Mod, or PokeyPlayer on iOS.

Coming from the background of the C64 and AMIGA demo scenes, I always thought that every platform needs a way to play back the musical artwork created by those great musicians in the 80s and 90s on machines like the Commodore C64, the AMIGA, and the ATARI XL.

Fast forward to the iPhone: Being excited about the new platform, me and another guy from the good ole' AMIGA days started working on SidPlayer in 2008, shortly after Apple opened the developer program for european developers. After some months of work, we had the first version ready for the Apple review, standing on the shoulder of the great libsidplay and the HVSC. Due to libsidplay being GPL, we had to open source the whole iOS app. To our surprise, _this_ hasn't been a problem with the Apple review.

SidPlayer for iOS was available for some months, then we developed adaptations for AMIGA .mod files (ModPlayer) and Atari XL pokey sound files (PokeyPlayer). In the meantime, iOS development went from being a hobby to our profession (we formed the LaTe App-Developers GbR), which unfortunately had great impact on our pet projects. Being busy with paid projects, we could not find enough time to do serious updates to the players.

The original plan in 2008 was to create an app that has additional value around the core asset of a high quality retro computing player, such as a retro-museum-in-a-box (giving background information about those classic computing machines) and a community that shares playlists (important given the amount of songs), comments, statistics, and ratings. Alas, due to our time constraints during the lifetime of the apps, we could only do small updates in order to fix bugs with newer operating system versions. There was not enough time to add features, do an iPad adaptation, nor to unify the three distinct player apps. In the meantime, other apps came along that also could play some of those tunes, although we weren't (and still aren't) very excited about their user interfaces and sound quality.

The final nail for the coffin came in 2013, when - much to our surprise - out of the blue (not even due to reviewing an update), we received a letter from Apple where they claimed that our player apps would violate the review guidelines, in particular the dreaded sections 2.7 / 2.8, which read "2.7: Apps that download code in any way or form will be rejected." and "2.8: Apps that install or launch other executable code will be rejected". Although we went past this guideline for several years, this turned into a showstopper - some weeks later, Apple removed our apps from the store.

Unfortunately, those sections really apply - at least for the Sid- and PokeyPlayer. Both players rely on emulating parts of the CPU and custom chip infrastructure of the C64 / Atari XL (hence run "executable" code, albeit for a foreign processor architecture) and said code gets downloaded from the internet (we didn't want to ship the actual music files with the app for licensing reasons). ModPlayer actually was an exception, since the .mod format does not contain code, but is a descriptive format, however back then I did not have the energy to argue with Apple on that, hence ModPlayer has been removed without a valid reason.

In the meantime, my priorities have shifted a bit and we had to shutdown our iOS company LaTe AppDevelopers for a number of reasons. Still I have great motivation to work on the original goal for those players. Due to the improved hard- and software of the iOS platform, these days we could add some major improvements to the playing routines, such as using recent filter distortion improvements in libsidplay2, audio post-processing with reverb and chorus, etc.

The chance of the existing apps coming back into the store is - thanks to Apple - zero. It wouldn't be a pleasant experience anyways, since the code base is very old and rather unmaintainable (remember, it was our first app for a new platform, and neither one of us had any Mac OS X experience to rely on).

Basically, three question come to my mind now:

1. Would there be enough interest in a player that fulfills the original goal or is the competition on the store "good enough"?
2. Will it be possible to get past Apple's review, if we ship the App with all the sound (code) files, thus not downloading any code?
3. How can I fund working on this app? To honor all the countless hours the original authors put into creating the music and the big community working on preserving the files, I want this app to be free for everyone.

As you may have guessed, I do not have any concrete answers (let alone a timeframe), but just some ideas and the track record of having created one of the most popular set of C64/AMIGA/Atari XL music player apps. So I wanted to use this opportunity to gather some feedback. If you have any comments, feel free to send them to me. If you even want to collaborate on such a project, I'm all ears. If there's sufficient interest, we can create some project infrastructure, i.e. mailing list.

Der Beitrag RFC: Future of SidPlayer, ModPlayer, PokeyPlayer for iOS erschien zuerst auf Vanille.de.

22 Mar 2015 9:11pm GMT