- From: Sullivan, Bryan <BS3131@att.com>
- Date: Thu, 13 Mar 2008 13:48:01 -0700
- To: "Sean Owen" <srowen@google.com>, "Mobile Web Best Practices Working Group WG" <public-bpwg@w3.org>
Sean, We need to be careful not to follow too strict a "mobile-specific" focus or we will end up saying very little indeed. Certainly the Mobile Web shares technology and service paradigms with the Wired Web. But to say that anything which has any significance whatsoever in the Wired Web case is thus out of scope for the MWI, is not helpful. I included various topics of interest to the broader web specifically because the nature of the Mobile Web raises their importance to be addressed as best practices, either because they are more important fundamentally in the Mobile Web case, or the techniques which support them are more problematic in the Mobile Web case. Personalization as an objective of increasing service value is one such aspect. These are issues that we as a mobile web service provider have been helping developers deal with since the beginning of the mobile web. As W3C tries to introduce the broader community of developers to the mobile web, it should try to understand, or at least take at face value, such issues that those who have served this market from the beginning consider important. Here's an attempt to explain this in a less technical way: Personalization increases the value of content and services to users, which is important in the mobile environment due to the extra effort necessary to find relevant content, interact with applications, and the limited output possible in mobile devices. In the PC environment, users have a variety of useful/easy input methods and controls making it easier to input personalizing information and surf to the content they want, and can more easily scan a large amount of content for the bits that are relevant to them. Each of these aspects are more limited, and thus more difficult to address in the mobile environment. Automatic personalization, and easy-to-use methods for input of personalizing information when necessary, make this a realizable goal for mobile services. Re methods of protecting personal information, obviously some basic appoaches e.g. HTTPS are shared with the Wired Web. But due to resource limitations on mobile devices I don't think anyone would expect that any personalized service will be restricted to HTTPS. There are other methods which can be used and supplement HTTPS for critical personalization phases, e.g. as I have mentioned in the best practices. Many developers simply will not be aware that there may be concerns about personal information trust/security, and further have any clue how to do it other than use HTTPS, which will work fine as I have said for the Wired Web, but not as a general approach for the Mobile Web. Thus there is a higher need for something (personalization), and a less robust environment to provide it. These combine to an issue which is valuable to address as a best practice. Re 5.3.2, many web applications will use device storage outside the browser cache, and the market is "gearing" up for this. We need to recognize this and prepare best practices that set expectations on the impact to limited device resources. Re 5.4.2, BP1 said simply "don't do it" re Redirect. What I'm saying is that there needs to be *realistic* guidelines on what should be the typical use of redirect in the cases I have mentioned, which are typical. BP1 did not adequately address this, as I pointed out in the Nov 07 F2F. Re 5.9.4 Provide Alternatives to AJAX, this specifically is assuming that not *all* devices will support AJAX, which is reasonable. The point is that AJAX/scripted applications need to be provided in alternate forms to work on such devices. Perhaps obvious, but then we are SME's and this is not written for us. In Seoul we were not able to crystalize any one aspect of the Apple guidelines to include. But we did agree to continue considering the external guidelines in general, so we can still pick up something from Apple, especially if someone wants to provide some text. Best regards, Bryan Sullivan | AT&T -----Original Message----- From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On Behalf Of Sean Owen Sent: Thursday, March 13, 2008 12:56 PM To: Mobile Web Best Practices Working Group WG Subject: Comments on BP2 We were asked on the call today to again review the BP2 draft at this time, and comment. Hats off to the editor, naturally. What a job it is to condense miscellaneous thinking into a coherent recommendation. I suppose I still take issue with the types of things that have been contributed by the group into this document so far. The majority of these BPs are not ones I personally would have included. Some that I definitely would include have not been. Let me call up a few representative examples that illustrate some issues I see: 5.2.1 Protect Personal Information Used in Transactions This is not mobile-specific, it seems to me. Nothing about the recommendation does not apply to the web at large. I don't disagree with the sentiment a bit, but think our charter in the *M*WI means we are to confine ourselves to discussing what is new, or different, in the mobile context. This is one practice I would simply remove. 5.3.2 Inform the User About Device Memory Impact for Application Installation and Use This seems to be veering into application-land, out of web-land. I think this is categorically out of scope for the M*W*I. 5.4.2 Minimize Redirects in Server-Server API's What does this add over BP1? 5.9.4 Provide Alternatives to AJAX Other BPs here seem to tacitly assume we're talking about a device with "AJAX-ish" scripting capability. This BP says, but if that's not so, do something else. Yes... but this seems like writing a best practice like "provide alternatives to mobile", instructing mobile applications to provide a desktop experience to desktop browsers. That is, I suppose it goes without saying. I would think it more natural to say "we're talking about devices that do AJAX here in BP2" rather than finesse it with a content-free suggestion like this. On the other hand I find BPs like this quite good: 5.9.2 Use Reliable Methods for Determining Script Support This offers a concrete, clear suggestion that is relevant to mobile insofar as the question of script support is far from a foregone conclusion in mobile, is relevant to web technologies, and is not a restatement of BP1. I see in the Seoul meeting notes that my suggestion to look at Apple's developer guidelines was more or less shelved. I suppose I had seen that as precisely the sort of thing we should be writing. In particular the "viewport" trick seems like by far the #1 thing I'd mention to someone wondering what's new in the world of the high-end mobile browsers. Comparing that to what is coming into the document, I suppose I'm left wondering whether this is on the right track? To be concrete: I'd remove the BPs I name above to start. I would like to at least reconsider a viewport meta tag BP. And so on from there.
Received on Thursday, 13 March 2008 20:49:18 UTC