MWABP 20091704: comments

I only had time to review the document for elementary aspects.


Section 1.3.2

"...they include some elements of interactivity and persistent state."

Replace with 

"...they include locally executable elements and persistent state."

since a basic Web application, even with no scripting, is interactive (following
links, filling in forms, etc). What seems to distinguish Web applications are 
client-side executables and persistent state.


Section 1.4

Replace "complimentary" with "complementary".


Section 3.1

Are system settings (e.g. DNS addresses, passwords, etc) included in the category
personalization? Perhaps they had better be mentioned as a third, separate
category, as they are neither application-specific, nor person-specific (e.g.
they are corporate-specific settings).


Section 3.1.2

I am unsure about what the "appropriate" in the title refers to:
a) storing data in local schemes vs. cookies
b) or one local storage scheme vs. another (e.g. Opera widgets vs. HTML5)?
Notice that if the latter, then the best practice does not give any guidance as
to which local scheme to use in what circumstance.


Section 3.1.3

"As a rule of thumb..."

Actually, this is the best practice itself, not a rule of thumb.

Moreover, a best practice should probably mention when deltas and when complete
data sets are to be saved on the server. A best practice is probably using deltas
as a default (with some form of synchronization), and allowing complete data set
uploads (with overriding) on demand.


Section 3.4

"...to battery life and / or network data costs..."

Replace "and / or" with "or" -- which has exactly the right meaning.



Section 3.4.2.2

"...compressed representations of the underling data."

Let us pressure the underlings until they are reduced to proper insignificance!


Section 3.4.6
Section 3.4.7 

I really doubt that these practices can be presented without more detailed 
conditions or disclaimers, given that:
a) they require specific features of CSS that might not be available in all
mobile devices;
b) even if available, their implementation might be erroneous.
Has anybody verified that these two practices can effectively be implemented
without bad surprises on a wide range of devices? If not, what are the devices
whose CSS implementation is too buggy for them? Any relation with ACID2 tests?


Section 3.4.9

This needs some development and justification. If somebody is using AJAX to 
implement presentation elements (which I consider a not so good idea -- why not
use standard markup elements?), then the practice applies. If AJAX is used to
fill in the static framework of a page with dynamic data (e.g. stock ticker,
sports results, calendar events, etc) then associating identical caching 
properties to the static frame and the dynamic data is not at all self-evident.


Section 3.6.1
Section 3.6.2

"For static device capabilities that won't change (e.g. SVG support, 
screen-dimensions)..."

The situation is a bit more involved than the dichotomy static/dynamic. With an
advanced browser, one may install a plug-in for a specific content type, register
it and associate the appropriate MIME type to it, and thus change the supposedly
static properties of the device: before, it could not deal with SVG, now it can.

Secondly, even dynamic properties can be communicated to the server: this is
what dynamic UAProf is about -- and a growing number of devices actually support
x-wap-profile-diff.

When reading the text of the best practices, it thus appears that real 
differences are as follows:
a) Whether there is a standard mechanism and vocabulary to communicate a 
property to the server;
b) Whether a property can be meaningfully set or altered at the granularity of
an HTTP transaction or coarser such as a browsing session, or whether it is 
modifiable at a greater frequency;
c) Whether the property is necessary at the time the content is processed on
the server ...
d) ... and also immediately upon receiving the content from the server.

As an example from the document, it is not really meaningful to inform the server
about space availability on the SD card when sending a request. The SD card is
necessary only later, when a reading/saving operation is launched -- and this
can be preceded by the useful warning "please insert the SD card...continue".
Second, the user may change the property of the SD card after receiving the page
-- e.g. deleting a few files to make some room. Third, it is easy to insert
or take out the SD card (possibly several times) while the HTTP transaction is 
in progress. Finally, there is no standard vocabulary in UAProf to indicate SD
card capacity (which might be an issue as well for Javascript schemes).

Conversely, the terminal must inform the server about support for a specific 
format upon sending a request -- otherwise, the server may just not serve the
request at all. The support must be in place when the response comes -- otherwise
the browser will just present an error. It is extremely improbable that a user 
(and the OS) is swift enough to install a plug-in, configure the browser and 
register the MIME type before completion of an HTTP transaction. Finally, there 
is a well-established way to inform servers about supported formats (the HTTP 
field Accept).

"Scripting enabled", "PIM access allowed" correspond to the former situation;
"screen dimensions" to the latter -- but in the case of terminals that switch
between portrait and landscape mode, _and_ if images must be generated to
correspond exactly to screen dimensions, then we are back to the former 
situation where properties must be checked locally.

Hence, sections 3.6.1 and 3.6.2 need some careful reformulation.


E.Casais

Received on Tuesday, 28 April 2009 10:20:26 UTC