Re: Comments on Mobile Web App Best Practices

Hi Marc,

Thanks for your comments,

I have added them to our internal tracking system. The Working Group 
will review your comments and get back to you. Note this may take up to 
a few weeks.

Francois.


Marc Wilson wrote:
> Hi W3C MWABP group,
> 
> I have taken a look at you latest working draft and have some comments below.
> 
> - Marc
> 
> ------
> 
> 3.1.1.1
> Cookies being disabled by devices isn't a mobile specific issue as it
> also applies to desktop. New devices Android, iPhone, Nokia s60 and
> beyond, Palm, etc.. all ship with cookies enabled by default.
> Maybe it is covered elsewhere but there is no mention of privacy
> issues sending data back to the server via cookies, only the network
> concern. With access to very sensitive data like location this might
> be worth flagging for mobile.
> 
> 3.1.2.1
> Given that HTML5 is now drafting specs for a Web Storage and Web
> Database that is shipping in iPhone 3.x and Android 2.x it seems odd
> to me to mention Bondi and Opera widgets in this context, especially
> given the focus of this document is for applications in a browser.
> The second point of "making updates locally at first" should be
> supplemented with a need to add UI treatment to make it clear to the
> user that their data is uncommitted.
> 
> 3.2.1.2
> One way to be able to eval() untrusted data is to perform the JSON
> escaping on the server where the processing power is less constrained
> than on the client since we are downloading the data anyway
> (presumably).
> 
> 3.3.1.1
> nit: double period at the end of first sentence
> 
> 3.3.1.2
> AFAIK some devices will provide UI indications in their status bar of
> network activity, with a spinner or mobile data flow indicators. While
> informing users of background network usage may be desirable, it might
> be overkill to have 3 separate indicators. Maybe you could suggest to
> provide UI on devices where the browser does not do it natively
> 
> 3.3.2.2
> "must" seems a bit strong here. Some applications that inherently
> require network access (think IM, mapping, etc..) will not be usable
> with no network access, so providing such an option should not be
> mandatory.
> 
> 3.3.4
> Consider adding something along the lines of
> "If devices persist authentication tokens then the server MUST
> invalidate them if the user changes or resets their password"
> This is especially important with mobile devices that are often
> lost/stolen and provides a user with a way to after the fact lock the
> phone out of web applications it had previously been authorised for.
> 
> 3.4.4.2
> One suggestion to add here is to prioritise your network requests and
> throttle the number of connections in order to ensure that high
> priority requests are not blocked or slowed by lower priority
> requests, if they are unable to be batched.
> 
> 3.4.5.1
> This is a dangerous recommendation when even modern browsers like
> mobile safari on iPhone have a limited browser cache entry size of
> 25kb uncompressed. It is a good recommendation but relies partially on
> the assumption that the caching of a single large resource is no worse
> than multiple single resources.
> 
> 3.4.10
> Although this is a different point to 3.1.1 they are related and maybe
> should be merged, colocated or reference each other
> 
> 3.4.11
> I don't like this recommendation.
> What does "reasonable" mean? What about "manageable"?
> What is a 10Mb DOM?
> How should people measure it?
> Why was this value chosen? (Recent high end browser handle much larger DOMs)
> 
> It is unclear what the recommendation to "Clip content and separate
> content onto separate pages" means.
> Are you saying to make top level URL changes to download new pages
> (and parse new JS)? If you are I think that is a bad recommendation as
> the latency hit is quite bad.
> Typically a better solution is to rather than hide non visible DOM
> elements, to instead remove these elements from the DOM altogether and
> recreate them as needed.
> 
> 3.5.1.1
> App Cache link should now point to: http://www.w3.org/TR/html5/offline.html
> 
> 3.5.1.2
> I like these recommendations. Good stuff.
> 
> One thing you could add is to initiate any network requests before JS
> parsing begins, so that the network request is in flight while the
> parse occurs. This can work well for applications that require fresh,
> rather than, cached data to be useful as it parallelises the network
> request and JS parse.
> 
> 3.5.4
> The tone of this recommendation is odd. I agree that the user
> shouldn't be warped away from their current view but there are cases
> where programatically setting the focus is very desirable if the next
> user action is expected to be character input and setting the focus in
> these cases should be recommended.
> 
> 3.5.6.2
> Maybe a mention of the format of the number used in the tel: URI
> A best practice is to use a full international number prefixed by +
> and a country code.
> This is recommended in the RFC so it isn't necessary to include it
> here, but it is currently quite common for people to use tel: URIs
> with only local numbers that don't work in a different calling prefix
> or different country.
> 
> 3.5.11.2
> Setting minimum-scale=1.0,maximum-scale=1.0 has accessibility impacts
> as it usually makes it impossible to manually zoom into the screen,
> which can be useful for visually impaired users.
> 
> 3.6.3.2
> Class 2 and 3 are very similar, the difference being the advanced APIs
> available in class 3. For example, the iPhone v2.0 browser was class 2
> and v3.0 is class 3 by your classification. Typically these
> differences don't require different variants, the class 3 device just
> has a richer and faster experience. A more useful axis is touch screen
> v non touch screen.
> 
> 3.6.4
> There was no mention of <noscript>. Is this deliberate?
> 
> 3.6.4.2
> Are we really recommending to send the user back a HTTP error code
> that essentially provides no information to the user as to why their
> request is "Not Acceptable". I understand this may be the 'correct'
> behaviour, but the UX it results in is hideous.
> 
> 
>

Received on Tuesday, 10 November 2009 12:22:57 UTC