RE: [ACTION-908] good practice for login forms

Hi Adam,

I agree with your summary in general, although I'm less inclined to
remove the "obvious" BP's due to the real chance that what we think is
obvious is actually not, to many mobile developers (or would-be ones).

 

Re "if publishing a best-practice that states that leads ultimately to
somebody creating a library that supports it and makes it easy for
hobbyists to improve the quality of their applications... then here at
least is something concretely positive we have done" though, given the
current group scope applied to the BPs requiring that they reflect
actual *current* practices in the mobile market, I don't know if
spriting meets that criteria. I have said though that MWABP should be
guiding developers to what they *can do* to "create great mobile web
applications" (the intent of MWABP as captured in Nov 2007 when it
started). So from that perspective, if we are willing to consider great
ideas that are not fully *current* wide practice, then I agree with
including the concept of spriting for those devices that support it,
given that it is possible to know that they support it (e.g. if this is
a device capability attribute retrievable from a DDR, or there is an
easy real-time test for it).

 

Best regards,

Bryan Sullivan | AT&T

 

From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On
Behalf Of Adam Connors
Sent: Thursday, February 05, 2009 1:44 AM
To: Luca Passani
Cc: public-bpwg@w3.org
Subject: Re: [ACTION-908] good practice for login forms

 

Hey Luca,

I wish we'd heard more from you earlier on, this is a very useful
conversation :)

To me, the only approach that would make sense for a document like BPAWG
is to be strong and take a position wrt multiserving vs LCD (least
common denominator). That would enable everyone in the group to think
much more clearly and on more solid ground.


I agree with this. In my head at least this is exactly what the document
is trying to do. It's why we haven't defined a DDC. But because of that
we have had a lot of problems with the document being too broad / woolly
with every BP taking the form: "in this case do this, in that case do
that, but you might want to consider the other..." Which obviously
limits usefulness.

In my head at least, I'd go a step further than your statement: Knowing
about device capabilities and being able to multi-serve in order to
exploit those capabilities is a core assumption of the document.
Furthermore, this document is only really concerned with what you serve
to high-end devices (which essentially means: compliant css, javascript,
etc). E.g. Top-of-tree for a certain popular open-source browser engine
we all know and love. If you want to target a broader range than that,
you should check out BP1 for what baseline assumptions you can make
about devices in general.

(The implicit assumption that a "Web application" is unlikely to be very
interesting / useful on anything other than a device that supports css /
xhr / dom etc is something we should probably call out more clearly one
way or the other). 

In practical terms, there are a great many content providers
(professional and hobbyists) who are only really interested in targeting
a couple (read 1) very specific devices. By defining recommendations for
how best to write web-applications for that kind of device hopefully we
can offer something useful to those people.

The takeaway from that is that Francois raised an issue earlier that
knowledge of which capabilities are required for a given BP to be
relevant should be called out more explicitly. I haven't done this yet
because I'm not sure how to do it in a way that doesn't become
incredibly repetitious... but I agree that it's something we should do
in order to prevent further confusion.

I'll go through a few of your other points in more detail. My instinct
though is that most of the issues raised are down to this implicit
assumption that we are talking exclusively about compliant css / xhr /
dom / javascript / etc devices... That this isn't clear right now is
something I'll address in the next draft.

> Include Background Imaged in-line in CSS style sheets
bad practice (unless you have a DDR to tell you that background images
are supported)


This is an example of a BP that is self-evidently only a good practice
if background images are supported. We should make that more explicit.
Note though that knowing this is simple, even for a hobbyist:

if (request.user-agent == [insert favourite high-end target device
name]) {
  // serve my whizzy ui
} else {
  // sorry -- buy a better phone
}

Or indeed, a hobbyist / small-scale content provider might choose (very
reasonably) to target only devices that support such features and not
care about the experience of the small number of less capable device
which stumble upon their page... This is a perfectly reasonable thing
for a content provider to do provided they know the scope / limitations
of such a decision... Whether or not that choice is good-practice
(ethical?) is beyond the scope of this document.

> A single request for more data is considerably more efficient than
several smaller requests.

not necessarily a good practice, depending on context.


Can you elaborate on this? On Edge / UMTS this is definitely true. On
WiFi it might not be but it certainly won't do any harm and I'd assert
that wifi is still a small portion of mobile use-cases. What other
contexts did you have in mind?

> Aggregate Static Images into a Single Composite Resource

definitely wrong, unless a DDR can tell you when this is OK. Also, this
kind of sprite generation is very time-consuming to produce. It's in the
domain of professionals who certainly don't need MWABP to know what they
are doing.


So for the first part, yes, assumption is that this BP is relevant only
if it's okay (e.g. css clipping, positioning is supported). For the
second part of your point, this is very interesting. Yes, I'm concerned
that some of the BPs are only non-obvious to the kind of people who
wouldn't bother reading this kind of document anyway (e.g. the login
discussion that started this thread). But I guess I'm on the opposite
end of the scale to you... I want to drop the obvious BPs and maintain
the advanced ones... There's two parts to this:

1. I disagree that just because a company is professional / has
resources it doesn't need a BP doc.

2. Image spriting is available with virtually zero-effort to any
hobbyist / small or large company that wants to use GWT (which works
well on mobiles, btw). There's no reason why an open-source library
shouldn't be created that does the same thing and makes the technique
available at low-effort to everyone... Given that spriting images can
have a large performance advantage when delivering web-apps (with lots
of icons) over mobile-networks, if publishing a best-practice that
states that leads ultimately to somebody creating a library that
supports it and makes it easy for hobbyists to improve the quality of
their applications... then here at least is something concretely
positive we have done.

Hope some of that clears some things up... With the DDR / capabilities
confusion out the way I'm interested to continue discussion on which BPs
make sense and which don't.

Regards,

Adam.






 

On Wed, Feb 4, 2009 at 11:10 PM, Luca Passani <passani@eunet.no> wrote:


Francois Daoust wrote:

	 

	Luca Passani wrote:

	
	
	So does MWABP rejects the concept of a DDC and fully embraces
the idea that multi-serving is necessary?

	
	Isn't multi-serving behind the [CAPABILITIES] best practice?
	 http://www.w3.org/TR/mobile-bp/#CAPABILITIES
	MWABP is built around this best practice.
	
	I don't understand why we would need to reject the concept of a
DDC. Multi-serving is recommended to improve the user experience on
specific classes of devices. The DDC is for the default experience.
	
	I would not use the term "necessary", but "recommended", sure!

 

So, before I delve into this discussion, I should make it clear that I
was part of BPWG, I was unhappy with how the BP document was taking
shape (hence GAP) and I am not going to start that kind of discussion
all over again for this new MWABP. The reason I am here is to keep an
eye on what those obscene transcoders are doing to get W3C endorsement
to their kludges, and not to re-engage with BP discussions.
I had enough of that between 2005 and 2007.

Having said this (and since I am responsible for having started this
discussion), I'll throw in a few comments. You can do what you want with
them, including ignoring them completely. I don't care.

To me, the only approach that would make sense for a document like BPAWG
is to be strong and take a position wrt multiserving vs LCD (least
common denominator). That would enable everyone in the group to think
much more clearly and on more solid ground.
Alternatively, you can also go for both choices (LCD and Multiserve are
both OK), but then each practice needs to be evaluated in the context of
whether the reader has chosen multiserving or not (basically providing
two separate sets of practices side by side). This would make the
document less clear.

Can W3C keep the distinction fuzzy and find practices that apply to
both? yes, you can try, but this will invariably lead to a document with
zero or no value for anyone, a bit like writing guidelines that apply to
manufacturing of motorbikes and cars at one time.





	
	if no, where is the MWABP DDC defined?
	
	if yes, some of the practices listed may no longer be good
practices in case of multiserving.


Could you point them out?

yes

> HTTP 1.1 compression, which uses the gzip and DEFLATE algorithms is
widely supported.

are you sure? I wouldn't recommend it unless you are mandating a DDR
with information about which devices support compression mechanisms.
Certainly not good for LCD approach

> Minimize Automatically Issued Network Requests

yes for LCD. Not necessarily a good practice if conditions that don't
make this a biggie are detected.

> A single request for more data is considerably more efficient than
several smaller requests.

not necessarily a good practice, depending on context.

> Minimize external resources

not necessarily a good practice in case of multiserving and addressing
certain high-end devices


> Aggregate Static Images into a Single Composite Resource

definitely wrong, unless a DDR can tell you when this is OK. Also, this
kind of sprite generation is very time-consuming to produce. It's in the
domain of professionals who certainly don't need MWABP to know what they
are doing.

> Include Background Imaged in-line in CSS style sheets

bad practice (unless you have a DDR to tell you that background images
are supported)

> minimize DOM manipulation

how do you know that the device has a DOM to manipulate. The LCD
approach should be "do not even try to manipulate the DOM", because this
will mean errors and frustration on many devices.

> Design for multiple interaction methods

How can I design for multiple-interaction if I don't have a DDR to tell
me what interaction method to use?
So, is adoption of a DDR mandated?

> Using Scripting to reduce performance

How do you know that a device has XHR()? and even if you do, which XHR()
(standard, MS syntax1 or MS Syntax2)?
a DDR is needed. If not, you cannot say "use scripting", because it
could fail. Also, how do you define "scripting"?

BTW, how do you inject content? can you use innerHTML() or not? do you
need to manipulate the DOM? how do you know that a device can manipulate
the DOM?

There is more to say. Frankly, I disagree with a lot of the practices in
MWABP generally. As it is, the document has little practical value for
developers. It is often misleading. It lacks the touch of someone who
has built real mobile apps.

	 

		
		Also, the spec seems to be sort of inconsistent with the
CT stuff (a transcoder may wreck havoc in the Json, CSS, scripting,
XHR() that go from the HTTP server to the client).

	
	There is an active discussion to have transcoders respect mobile
content explicitly flagged as such. I'm much in favor of it. "The best
practices need to be protected" is indeed the main argument in my view.

 

Good. I am curious to see what the result of the discussion will be.
Please don't write a spec where everyone can read what they want in it,
because this would increase confusion in the industry.

Luca