Re: MWABP 20091704: comments

On Tue, Apr 28, 2009 at 11:19 AM, Eduardo Casais <casays@yahoo.com> wrote:

>
> 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."
>

done


>
> 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".
>
>
done


>
> 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).
>
>
At the application level DNS addresses should be transparent (the
application can only make XHR requests to the origin server).
Storing password (or rather password hash) is tricky from security
perspective but will be covered in an "enable automatic logon" BP.


>
> 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.
>
>
the former -- I believe this is clear enough.


>
> 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.
>

removed "rule of thumb" -- I've reluctant to go into greater detail since it
really depends on the application.

>
>
> Section 3.4
>
> "...to battery life and / or network data costs..."
>
> Replace "and / or" with "or" -- which has exactly the right meaning.
>
>
done.


>
>
> Section 3.4.2.2
>
> "...compressed representations of the underling data."
>
> Let us pressure the underlings until they are reduced to proper
> insignificance!
>

done :)

>
>
> 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?
>

interesting question re: ACID2... These techniques are verified on webkit
based browsers. The intention is for the CSS clipping / positioning icon to
act as a warning that not all browsers support this.

lets leave in for now pending more feedback -- agree that we should look @
these two very closely and consider cutting.


>
>
> 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.
>
>
I'll dig out the origin of this BP. I don't think presentation elements or
not is relevant, but agree it probably needs some fleshing out.


>
> 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.
>
>
good points -- will raise an issue to discuss further and table it for this
minor redraft.


>
> E.Casais
>

thanks,

adam.