FW: some thoughts on current state of bp draft

Hello Tom

Thanks for your wittily put feedback.

A general comment: the document is targeted at people who are unfamiliar
with the opportunities and limitations of mobile devices. It does assume
familiarity with Web concepts and development.

The intention was specifically not to repeat general good practice or
accessibility practice. The rule of thumb for including recommendations was
that they should either be unique to the mobile environment or should have
some particularly important mobile angle. 

Having said that, it seems from your comments that this is not as clear as
it might be and so we should reconsider the introduction.

It's interesting that you use as an example the word
'floccinaucinihilipilification', which means 'describing something as
worthless' - which is what you seem to be doing of our document. Sorry you
feel like that about it - as mentioned in the introduction, it is a first
draft and is in part intended to stimulate debate. 

Anyway, thanks for the feedback, a couple of additional comments in-line.

Jo
(co-editor) 

> From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On
> Behalf Of Tom Thurston
> Sent: 19 November 2005 08:34
> To: public-bpwg@w3.org
> Subject: some thoughts on current state of bp draft
> 
> Dear BPWG,
> 
> I have read the recent draft of your document. Thank you for taking the
> time
> to write it. May I offer the following observations?
> 
> 1. The document tries to get readers to subscribe to the concept of
> putting
> information on links to let the user know how what content follows. I read
> the document with the expectation that it was going to fill me with
> insight
> about how to make a mobile website. Upon reading it I felt that it was
> akin
> to some kind of MobileWebDevelopment 101 course, and thus, with an
> associated enlightenment factor of 0, felt somewhat cheated, as it took a
> long time to read. It was the same dissappointment that I experienced on
> first reading the word 'flockynockynihiliphilification' only to discover
> that the word meant 'nothing'. Thus, if you are planning on writing a
> document for mobile novices, then please label this clearly at the top of
> the document. If you are going to follow your own advice on links, then
> you
> might want every link to the document to say for example, "a 100,000 word
> document describing ideas for how to build  a mobile website for the first
> time - containing some good  - some bad - some really basic -
> and some conflicting ideas".

The current text on adding descriptive text to links will likely be updated
in the next draft. In general it seems [to me to be] unnecessary to provide
explicit signposts where the context makes it clear that the links are to
things that are clearly large technical documents and that are less likely
to be of interest to a user while mobile. On the other hand, if you were
reading a news feed on your mobile device, which mentioned the release of
the second draft of this document, then you'd want to be careful to make it
clear from the context of the hyperlink that it lead to the document itself,
rather than just some additional story about the document.

> 
> 2. One example of a basic concept was telling people that they should try
> and do adaptation on the server, rather than on the device. Now I know
> that
> if you're a novice reading a document, it's sometimes nice to come accross
> a
> really simple concept, as it gives you confidence that you understand what
> you are reading. I love simple concepts, in fact, I can only understand
> simple concepts. However, I feel that if there is anybody out there who
> without reading the Mobile best practices document, would be taking, a
> 1MegaByte image, and sending it to a mobile device with the intention that
> the device will transcode it down to a 128x128 wallpaper... then that
> person
> should perhaps not be trying to make any kind of website. I mean the
> document mentions lowest common denominators... it omits some basic
> advice,
> such as 'turn on your computer before you start typing'... I believe that
> you can get away without having to emphasize that transcoding on a server
> is
> better than transcoding on a device, for say images / video and sounds.
> 

I believe that people are in fact doing exactly what you describe above. Our
job is to point out to them that this is not appropriate in the mobile
context as it may cost the user an unreasonable amount of money. I don't
think it is our job to tell them that they (in your words) "should perhaps
not be trying to make any kind of web site". 

> 3. One example of a wrong concept was telling people to never use an image
> in place of text. I think that if companies making mobile wap sites told
> their customers... "oh no don't bother making a logo banner - we'll just
> use
> text"... they wouldn't have that customer for very long. In my experience,
> customers don't want to see any text in menus... they want nice good
> looking
> buttons which make good looking websites... Our job is to get those
> buttons
> down to a size where they look good, but don't exceed the pageweight for
> the
> device. So maybe you want to recommend that people use thin (small height)
> banners... especially if you are adapting to fill the device screen width,
> that is, if they are going to take the risk and use an image instead of
> text...

I'm not clear which statement you refer to when you say that the document
tells people never to use an image in place of text. 

> 
> 4. Were you trying to suggest that we should remove whitespace from
> documents post editing or just to write all xml documents on one line?
> Assuming the former is the intention, then this would mean that you'd have
> to have some kind of xslt stylesheet to remove it during a production
> build.
> Obviously, its not too hard to make one but if you're aiming your document
> at novices, then you don't want to even let them have a hint that there
> exists such thing as xslt, it'll put them right off before they have even
> made their 'helloworld' mobile webapp.
> 
We've noted that this could do with more explanation. Pretty printed mark up
aids maintainability but increases page weight. The developer's maintenance
convenience is being traded against the users cost and time.

If you can strip extra white space before delivery then this would be a good
idea.


> 5. I didn't get the bit about a graphical / textual sitemap. In my
> opinion,
> a mobile website should be its own site map. It should be very clear where
> each bit of the main menu will take you...

I too think that this section requires more thought.

Received on Tuesday, 22 November 2005 13:56:15 UTC