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.