Regarding orientation lock and more

Hi guys,

While working with QtWebRuntime and also the N9 WebKit2 browser in Nokia, I
did a lot of work to investigate and clarify how "average joe developers"
would see our platform(s) and try to help expose and remove some of the
obstacles found relating to API, performance, etc..

I would like to share my thoughts on what I see needs to work - and in
which way - to make HTML5 WebApps a viable platform for particularly games
on mobile devices.

In broad terms, the developers need - as a minimum - access to reliable
APIs controlling the following (assuming low latency capacitive multi-touch
available):

* Low latency audio - WebAudio provides a good foundation but even HTML5
Audio (tag/object) could be used for simple thing (we need to make sure it
can be called from a non-user-initiated action/script when the app is e.g.
installed to homescreen).

* Fast graphics - WebGL for advanced stuff, accelerated canvas for more
simple things - but also things like CSS3D (or 2D animations) - when smooth
- can be used.

* Minor things like "keep backlight on" (for non-touch games), etc.

* Reliable Controls!!! :

For the sake of relevance, let's focus on the accelerometer ;)

If I design a game and I am going to use the acceleroemeter as input, in
99% of the cases I will be interested in having full control over the
auto-rotate so the device behaves exactly like I want when the user
moves/rotates the device around.  For this I need an orientation lock (so
far so good) - but I also need to be 100% sure that my accelerometer
readings are always the same relative to the orientation chosen - no matter
what device my users choose to run my game on.

Currently, we are given the first iteration of a proposal for an
orientation lock that has settings like portrait/landscape and
primary/secondary - and even allowed vendors to have "landscape oriented
devices" and "portrait oriented devices", affecting anything accelerometer
and orientation related - almost to the pleasing of the individual branch
of a given mobile device manufacturer implementing the stack (in the end)
providing the values and behavior to the developer and end user.

I have seen - even within the same company - that these mappings were wired
up totally differently depending on device line, base platform and if this
by coincidence was considered mostly a landscape or mostly a portrait
device.

What we need it to keep things robust and stable for the people who are
going to use these APIs/features and not require them to purchase a huge
range of different devices to test on (and do mappings for) and I have some
points I'd really like to get across that I know will make things easier
for all:

1. decide on ONE (either portrait or landscape) "0 degree rotation" =
"device up" that will trickle through all specs relating to orientation.
   In practice, this would mean that lockOrientation("0deg") ~
(x,y,z)=(0,1,0) , where lockOrientation could be an async request telling
if the angle was allowed, etc. - e.g. more options could be given
("0deg,180deg") and maybe "180deg" is set and returned...The important
thing here is that the developer has a consisten way of mapping the locked
orientation to the data coming from the accelerometer.

2. if we really want to win the hearts of native app developers, the whole
spec'ing community needs to consider some changes:

   A. Make a dependency graph of all specs (in use) and how they relate to
one another (e.g. deviceorientation and lockorientation touch base on:
 rotation, accelerometer, etc.).  This holistic view can help make APIs
more consistent and the whole "develop a web app" experience more coherent
   B. Make sure that example apps are made and that average joe developers
are invited to test APIs - BEFORE THEY GO OUT OF DRAFT (or are shipped in
stable => written in stone)
   C. Big companies should stop putting a gag orders on individuals who
have valuable stuff to contribute outside their designated draft or
implementation domain - this is seriously counter productive and limits us
from reacing our common goal in our lifetime (I can say this because I no
longer work for a big company ;))


 br
 Lars Knudsen
 http://www.linkedin.com/in/larsgk