This document is a template that should be used to send implementation feedback for the Mobile Web Application Best Practices W3C Last Call Working Draft dated 13 July 2010 that followed the W3C Candidate Recommendation dated 11 February 2010. Submitted feedback will be used to prepare the implementation report of the document.
Implementors of the Best Practices are invited to copy this implementation report template and edit it to reflect the results of their evaluation of their Web application through the Best Practices, accompanied with their comments and feedback on the work required to implement this or that Best Practice.
Please send filled implementation reports to the publicly archived mailing list <public-bpwg-comments@w3.org> if you agree with having the results public, or to the <member-bpwg@w3.org> otherwise (please note that the archives of this second mailing-list are W3C-Member visible; also note that you will receive a message saying that your message is pending moderator action in that case. This is normal, no further action is required on your part).
Note that Web applications are not expected to implement the whole set of Best Practices. The Mobile Web Best Practices Working Group rather expects Web applications to implement one or two Best Practices, and strongly encourages implementors to provide implementation feedback on this(these) Best Practice(s) while leaving out the Best Practices that do not apply to their Web application in the table below.
The notion of Web application is precised in the specification, and includes "regular" Web pages with some elements of interactivity as well as applications running in other kinds of Web run-time such as widgets.
Anyone can submit implementation feedback.
For each Best Practice implemented by the Web application: please indicate whether the implementation complies with the Best Practice, or complies partially; please use the comments column to precise partial implementations and to include any feedback or remark you may have on the Best Practice. Feel free to provide feedback on Best Practices that are not implemented by the Web application if needed.
| Best Practice | Implemented | Partial | Comments |
|---|---|---|---|
| 1. Use Cookies Sparingly | No cookies used at all, unpersonalized app | ||
| 2. Use Appropriate Client-Side Storage Technologies for Local Data | Not used yet at all | ||
| 3. Replicate Local Data | This app lives completely client-side, server data are only read from external webservices. | ||
| 4. Do not Execute Unescaped or Untrusted JSON data | +1 | using dojo's JSON methods (mapping to native implementation if exists) | |
| 5. Ensure the User is Informed About Use of Personal and Device Information | No device data used. | ||
| 6. Enable Automatic Sign-in | no sign-in needed in this app | ||
| 7. Use Transfer Compression | App is executed from local filesystem. | ||
| 8. Minimize Application and Data Size | JavaScript code is minimized. | ||
| 9. Avoid Redirects | Its a one page app. | ||
| 10. Optimize Network Requests | Optimized by the nature of the app, which is running local and only getting data from online. | ||
| 11. Minimize External Resources | +1 | lies in the nature of the app | |
| 12. Aggregate Static Images into a Single Composite Resource (Sprites) | +1 | Done rather for convinience than for reducing the number of requests. | |
| 13. Include Background Images Inline in CSS Style Sheets | Not necessary, all data are served from local. | ||
| 14. Cache Resources By Fingerprinting Resource References | |||
| 15. Cache AJAX Data | +1 | done when possible | |
| 16. Do not Send Cookie Information Unnecessarily | +1 | no cookies used | |
| 17. Keep DOM Size Reasonable | +1 | big issue, we optimized hard for that! AND "make DOM with meaning", means use a LI for a list, etc. imho very important on mobile even more | |
| 18. Optimize For Application Start-up Time | +1 | we optimized by deferring some resource loading | |
| 19. Minimize Perceived Latency | +1 | as above | |
| 20. Design for Multiple Interaction Methods | +1 | very importanant!! touch and keyboard navigation | |
| 21. Preserve Focus on Dynamic Page Updates | -1 | marginally relevant on touch devices imho | |
| 22. Use Fragment IDs to Drive Application View | it's an app, there is no necessity to create links, imho this doesnt apply to apps (to websites only!) | ||
| 23. Make Telephone Numbers "Click-to-Call" | good input! but: no phone numbers shown yet | ||
| 24. Ensure Paragraph Text Flows | +1 | very important also in our eyes | |
| 25. Ensure Consistency Of State Between Devices | not relevant (yet) | ||
| 26. Consider Mobile Specific Technologies for Initiating Web Applications | not used yet | ||
| 27. Use Meta Viewport Element To Identify Desired Screen Size | +1 | ||
| 28. Prefer Server-side Detection Where Possible | app has no server side component | ||
| 29. Use Client-side Detection When Necessary | Every app is packaged device specificly, no need for client-side detection, handled at build time | ||
| 30. Use Device Classification to Simplify Content Adaptation | not used yet | ||
| 31. Support a non-JavaScript Variant if Appropriate | was not in scope, becomes less relevant imho | ||
| 32. Offer Users a Choice of Interfaces | not done (yet) |
The document also contains a small set of advisory notes from the Mobile Web Best Practices Working Group. While implementation of these advisory notes is not required for the document to transition out of Candidate Recommendation, the group invites submitters to provide feedback on these advisory notes as well, when relevant.
| Advisory note | Implemented | Partial | Comments |
|---|---|---|---|
| 1. Consider Use Of Canvas Element or SVG For Dynamic Graphics | |||
| 2. Inform the User About Automatic Network Access | |||
| 3. Provide Sufficient Means to Control Automatic Network Access |