Re: BP2 (BP mobile web-apps) - some words related to scope.

This looks like good progress and looks like we are getting closer, 
hopefully, to settling the scope question for once and for all.

I do have a couple of grumbles:

1. I don't like and have never liked the phrase "great Web applications" 
I don't think that it is inherently meaningful.

2. I think the phrase "follow in the footsteps" needs more explanation 
to avoid the confusions we have been discussing - specifically we should 
make it clear that its main intention is not to replace or update BP 1.0 
- it is to address things that BP 1 did not address.

It might be worth saying that BP1 was mainly about "designing down" this 
document is more about "designing up".

In explaining the relationship to would also think that there is benefit 
in being specific about mentioning the BP "Exploit Device Capabilties" 
and that this document is largely about that.

3. I like the bit about intrinsically mobile features, but wonder 
specifically about "(e.g. limited device processing capability)" as I 
think that it is an enduring feature of mobile devices that they have 
limited processing - relative to a desktop PC, that is.

4. Similar somewhat picky comments about some other wording, especially 
"interactivity and persistent state", where it needs to be made clear 
that we mean "interactivity and persistent state" that is handled by the 
client autonomously from the server.

I'll put a discussion of it on the agenda for later today.

Jo

On 21/05/2008 22:36, Adam Connors wrote:
> Okay, so based on the various conversations and threads we've had these 
> past few weeks on the scope of the BP2 (BPMWA ?) document I've attempted 
> to redraft section 1.4 Scope.
> 
> Pasted below is a straw-man of some words that attempt to assimilate 
> everyone's ideas of what the scope of this document should be and 
> address the various grey-areas that have tripped us up previously. 
> Apologies for the short notice, but if possible I'd like to spend some 
> time on tomorrow's call to iterate on this section by way of helping us 
> zero in on a common understanding of the scope and direction of this 
> document.
> 
> Thanks,
> 
> Adam.
> 
> ---
> 
> 
>   1.4 Scope
> 
> These recommendations follow in the footsteps of the Mobile Web Best 
> Practices (BP1), for which the scope was laid out in "Scope of Mobile 
> Web Best Practices" [Scope]. Where BP1 referred primarily to the 
> extension of web browsing onto mobile devices, this document further 
> extends that scope to consider the use of /web-applications/ on mobile 
> devices.
> 
> This document sets out a series of /best practices /that are intended to 
> help content creators develop and deliver great /web applications/ in 
> the /mobile context/.
> 
> 
>   1.4.1 Best Practices
> 
> The approach in writing this document has been to collate and present 
> the most relevant engineering practices prevalent in the development 
> community today and identify those that: a) facilitate the exploitation 
> of modern device capabilities to enable an optimal user-experience for 
> mobile web-applications; or b) are considered harmful and can have 
> non-obvious detrimental effects on the overall quality of your mobile 
> web-application.
> 
> The goal of this document is not to invent or endorse future 
> technologies. However, there are a number of cases where explicitly 
> omitting a best-practice that referred to an emerging technology on the 
> grounds that it is too recent to have received wide adoption would have 
> unnecessarily excluded a valuable recommendation. As such, some 
> best-practices have been included on the grounds that we believe they 
> /will become/ fully qualified best-practices (e.g. in prevalent use 
> within the development community and considered to have a positive 
> impact on the overall quality of your web-application) in the very near 
> future.
> 
> 
>   1.4.2 Web Applications
> 
> For the purposes of this document, the term "web application" refers to 
> a web page (XHTML or a variant thereof + CSS) or collection of web pages 
> delivered over HTTP which use either server-side or client-side 
> processing (e.g. javascript) to provide an "application-like" experience 
> within a web-browser. Web applications are distinct from simple web 
> content (the focus of BP1) in that they include some elements of 
> interactivity and persistent state.
> 
> It should be noted that there are a number of emerging mobile 
> technologies that allow web-applications to be delivered in a more 
> componentized or gadget-like way, outside of a traditional browser 
> [REFERENCES TO WEBLETS, ETC]. Whilst many of the recommendations in this 
> document remain relevant in these contexts, no explicit effort has been 
> made to adapt them for this scenario on the grounds that there are as 
> yet no convergent technologies or practices for non-browser based 
> web-applications. As such, the reader should remain mindful of potential 
> divergences from these recommendations when dealing with 
> web-applications delivered outside of a browser.
> 
> 
>   1.4.3 Mobile Context
> 
> In an increasingly mobilised world the line between mobile and 
> non-mobile is necessarily blurred and a document focussing solely on 
> best-practices that are /uniquely/ mobile would most likely be very 
> short. With this in mind, the focus of this document is to address those 
> aspects of web-application development for which there are additional, 
> non-trivial concerns associated with the mobile context. This applies 
> equally both to the limitations of the mobile context (e.g. small 
> screen, poor connectivity), and also the additional scope and features 
> that must be considered when developing for the mobile context (e.g. 
> device context / location, presence of personal data on the device, etc).
> 
> Note that additional weight has been placed on those aspects of the 
> mobile context that are believed to be intrinsic and likely not to 
> change in the foreseeable future (e.g. limited input capabilities) as 
> opposed to those that are likely to disappear quickly as the technology 
> evolves (e.g. limited device processing capability).
> 
>  
> 
>

Received on Thursday, 22 May 2008 07:56:16 UTC