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
>
>
>