Re: New Draft of MWABP uploaded (13th March) / Comments

Thanks Eduardo! -- comments inline, redraft coming shortly.

On Fri, Mar 13, 2009 at 4:59 PM, Eduardo Casais <casays@yahoo.com> wrote:

>
> My previous post on this topic
> lists.w3.org/Archives/Public/public-bpwg/2009Feb/0059.html
> is still relevant.
>
>
> Section 1.3.2
>
> "Web pages delivered over HTTP which use either server-side or client-side
> processing".
>
> This explicitly excludes applications that have a scripting component both
> on
> the client and on the server (e.g. AJAX). Is this really intended? If not,
> then
> the correct formulation is "...which use server-side or client-side
> processing".
>

done


>
> Section 1.3.4
>
> "Most best practices assume devices with basic XHTML, JavaScript, and CSS
> compliance".
>
> The level of compliance for CSS or Javascript is left open. It is important
> to
> clearly specify the type (XHTML basic? XHTML mobile profile? i-Mode XHTML?
> W3C
> XHTML?) and version of XHTML (many possibilities), or the capabilities
> (e.g.
> support for <script>, <object>, etc) considered. Thus, XHTML mobile profile
> support Javascript/ECMAScript only since version 1.1.
>

agree that we should be explicit about this. i've added editor's note and we
can discuss at the F2F.


>
>
> Section 3.1.2
>
> "If HTML5 is supported".
>
> Has the specification of HTML5 been finalized? How many browsers,
> commercially
> deployed, implement HTML5? I would eliminate explicit references to HTML5,
> and
> generalize the best practice to browsers that "support a client-side
> storage API"
> -- these may be proprietary, of course.
>

I don't know enough about this to comment. Have added a ednote and we can
discuss @ F2F -- Whether or not HTML5 is fully supported / finalized webkit
based browsers have the HTML5 based local store / sql apis (afaik).


>
>
> Section 3.1.3.2
>
> "Mobile Web applications should use these events to control the
> asynchronous
> replication of data back to the server".
>
> Once again, specific features of a future technology are presented not as a
> solution, but as a best practice. I strongly advise asking experts for
> information on how synchronization is achieved _currently_ -- any relation
> with
> SyncML?
>

The approach outlined is a summary of our (Google) experiences of using
client-side storage to optimize mobile application performance... SyncML
isn't a relevant technology in this context, in fact the protocol to
replicate the data is not mentioned, the point of the BP is that application
performance can be improved through the judicious use of client-side
storage.

There are three issues here:

1) This is a summary of practical experience on 3 applications * 3
platforms, but I would love to hear more experiences from other developers
in the WG doing similar things.

2) They are quite complex techniques and there isn't space to do them
justice in a document like this. These BPs would certainly benefit from some
editing to improve clarity.

3) In my experience these approaches definitely improve application
performance and hence user experience... So it feels like a good thing to
mention in this document... But your application won't be pathologically bad
if you don't do it... So in that case can you really call it a
"Best-Practice" ?

TODO has been added for discussion @ F2F.


>
>
> Section 3.3.2
>
> "When automatic network activity is disabled, periodically prompt the user
> to
> make network requests".
> "Consider allowing the user to adjust the polling schedule and to control
> which
> activities are allowed to initiate network requests".
>
> This section seems to be mixing two cases:
> a) exceptional network accesses occurring at unspecifiable times (e.g.
> error
> reporting);
> b) periodic network accesses by well-understood operations
> (synchronization,
> polling).
> The first recommendation relates to (a), whereas the second one to (b);
> they
> should probably be separated into two different best practices.
>
>
I'll come back to this one !


>
> Section 3.4.2.2
>
> "The working group is seeking recommendations for the best / most-commonly
> used
> tools to reference in this section".
>
> Do not use Minify; this utility is known to break applications, especially
> code
> written in Javascript. In general, avoid tools that rely upon pattern
> matching
> instead of proper lexical and syntactic analysis.
>

Agreed. Does that mean you think we should avoid the word "minify" ? I was
using it as a general process rather than to refer to a particular
application...

In-house I use GWT because it does all this and is generally great, but this
is a very specific technology and not sure if we can recommend it in this
document... Which means I'm a bit stuck for recommendations.

I'll create an issue so that hopefully somebody can take an action to
research this and make a recommendation.


> Section 3.4.6
>
> "In some circumstances performance is improved if JavaScript and CSS style
> sheet
> resources are included in the HTML page".
>
> Well, let us put it this way: the actual best practice is "Keep common
> scripts
> and style sheets as external resources, do not include them directly in
> pages".
> The practice 3.4.6, right from its formulation, makes it clear this is not
> a
> best practice, but rather an exceptional one ("consider...", "in some
> circumstances...").
>
> In fact, unbundling common resources from markup is recommended because:
> 1) It is more manageable (modifications of style sheets and scripts are
> centralized, rather than scattered in application templates or individual
> pages).
> 2) It improves caching, between different devices (network cache), and
> between
> pages accessed by the same device (device cache).
> 3) Page sizes on mobile devices varies a lot (anything from 10K to 400K);
> scripts and styling reduce the payload available for markup.
> 4) In some devices, large pages are not cached (apparently, some versions
> of the
> iPhone do not cache pages larger than 25K).
>
> Bundling scripting and styling with the markup is usually done because
> 5) The content is produced by an authoring tool that automatically includes
> or
> generates styles and scripts directly inside the markup, and the tool
> cannot be
> configured to keep these elements separate.
> 6) The target browser cannot use external resources (example: many i-Mode
> devices
> cannot use external style sheets).
> 7) The target browser incorrectly retrieves external resources from the
> server,
> instead of looking them up in the local cache.
>

Inlining resources has a performance benefit because it reduces HTTP
requests. This is definitely a useful technique that we use in a number of
applications.

Of course, it's not a required technique since the app won't be
pathologically bad without it.

I've added a TODO... This is a recurring theme with many of these BPs...
They are useful techniques that improve performance in some cases but must
be used judiciously and are certainly not required... Do things like this
qualify as Best-Practices ? [[ If they don't this document is going to
become much shorter ! ]]


>
>
> Section 3.6.3.2
>
> "The following is a typical configuration of application classes".
>
> Given the focus of the document on applications, which usually require some
> form
> of scripting and API, possibly AJAX, other typologies might be more
> relevant. In
> practice, one will often see "horizontal" partitions that distinguish, for
> instance, between Windows Mobile devices (HTML + JScript), Series60 (XHTML
> +
> ECMAScript), and Blackberries.
>
>
> Section 3.6.4
>
> "Essentially this BP states that it is favourable to support 'Class 1'
> devices
> as defined above if at all possible".
>
> Given the focus of the document, the number of practices that somehow deal
> with
> scripting, AJAX, JSON, SVG, I wonder about the impact of this best
> practice.
>

Agree. We are still a bit schizophrenic in this document... I've added a
TODO to discuss in the F2F. In my working life I don't really care about
non-AJAX / non-webkit devices. I have no more interest in supporting these
than I do in supporting a WML interface... I'd like us to make a firm
decision to focus on XHR based web Applications and remove all BPs that
relate to anything else... (That should keep us busy for a couple of hours
in the F2F if nothing else).


>
>
> E.Casais
>
>
>
>
>
>