See also: minutes Day 2 - IRC log
<jo> Agenda: http://lists.w3.org/Archives/Member/member-bpwg/2007Oct/0075.html
<Kai> ScribeNick: Kai
Introductions being made
scribe: lots of good people in the room
Jo: Welcome to all. there are 35
people registered, 23 member and others as observers
... introduces the agenda
... lots of time for the task forces
[introducing the taskforces]
scribe: dinner tonight, not sponsored
Dan: Reservations made for 15 people. Will do a show of hands later
Jo: tomorrow the topic is charter
2
... need a recap of the issue, like no DDC 2
... we spend the morning on charter 2
<scribe> [continues on agenda for tomorrow]
Jo: we have a tight schedule, depending on discussion
Dan: reiterates call for extra
agenda items
... we are on the cusp of entering the new charter
... have a set of opportunities and all need to be
focussed....if you have burning issues we need to pay attention
to. Please bring them to the table.
... now is the opportunity to bring up those points...within
the context of the charter
Bryan: I did send a couple of things to the mailing list, that might fit, if we have time
Dan: let
... 's do that tomorrow.
... it fits for charter 2, what format with the doc take
Sean: have pretty much finished
mobileOK basic and the checker is the icing.
... it is in alpha state
... it is an implemention in Java of the mobileOK Tests
... several people in the room have been involved
... status is, it has been put out, fixing bugs
<jo> Checker Download
Sean: been quiet now
... it is not bug free yet though.
... want to issue a beta release at the end of the year
... hopefully we will get more feedback by then
... it is will be easier because mobileOK basic should not be
changing anymore...
... so it should be fairly stable. Go ahead and
experiment.
... will be of interest to developers
... if you just want to check a page then the dotmobi checker
is a nicer interface
... the final release is still up in the air
... it might be a couple of months into 2008
... right now we are just trying to find bugs. Best thing to do
is download the JAR file.
... run at the command line
there is a mailing list
scribe: this is it for
status.
... Questions and concerns?
<jo> -> public-mobileOK-checker@w3.org Checker Public Mailing List
Dan: are there outstanding issues?
Sean: I don't think so, but let's check
[there are 4 issues]
Dan: what do we want to do with
this checker in terms of community outreach?
... I think it would reflect well on the work of this group and
on the W3C?
Sean: it doesn't really help us
to produce this and then not talk about it.
... we can post this in our blog and the company blog
... next week in Boston at the Mobile Internet conference we
will introduce this as well
Marie: Next tuesday, Nov 13, we
will announce mobileOK as CR.
... Janet will ask for testimonials to support the press
release
... the text needs a littlebit of a revamp, but will be final
soon
... check later today for the almost final text
Dan: I wonder if we can do any extra PR of the reference implementation of the checker? Can we emphasize that there is code that wraps up mobileOK?
Marie: It is part of the PR
Sean: Once this has gone through Betaquality tests, we will replace the current implemenation on the web. this should happen by teh end of the year.
Jo: It already is backed by the
current code
... testing google's site
Bryan: looks like you have a server that pulls content and checks it. Is there a plan to have this on a laptop as well?
Sean: Yes. It is a library.
[checking again]
[looking at the results of the checker test]
<Jonathan> http://www.w3.org/2007/10/mobileok
google.com/m passed
Dan: I am filled with emotion...in the beginning we talked about all this....now it is here...the vision has been created.
Jo: Let's test the w3c site
<MikeSmith> Dan has tears of joy in his eyes
Sean: It would be nice to have this common reference implementation
Jo: checking t-online
... not working..but it is an alpha release.
Sean: well, not unexpected.
Jo: we should come back to
discussing what we will put in place for a long term
maintanence program for this
... is there anything else on the checker?
... this is a good example of how a checker taskforce can do
quick and good work. The group needs to endorse this
product.
Dan: You are thinking of a
resolution?
... that would be valuable to do at this meeting.
Jo: We need to think of how to do
this. What do they need to endorse it?
... in fact we should record this as an issue
Bryan: Is there a plan for how
experience is gathered?
... how do we get the changes back in the process?
Dan: One issue is how to get this back into mobileOK and that is different from issues raised against the checker.
<MikeSmith> Bryan mentions concern about issues with the checker and mobileOK that might potentially cause "boats to scrape the bottom"
Dan: both things are worth
discussing.
... in terms of endorsing the checker we need a period of
review. We can't expect members to review the code.
Abel: we have been working on a
developers manual.
... we have changed some things recently. Next week we expect
to publish the first draft.
Sean: there will not be a problem
with the implementation or documentation. We have Bugzilla for
all bugs.
... bugfixing is a bit of a separate question compared to
future maintainanence
<MikeSmith> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Checker/Overview.html
Sean: for now there will be enough of us around.
<MikeSmith> Kai : one of the questions we have to address is, Who will be responsible for this thing?
<MikeSmith> ... under whose auspices?
<MikeSmith> Scribenick: MikeSmith
<Kai> testing
jo: I would probably be
appropriate for someone to take the lead ...
... somebody who is not on the Checker TF ...
... somebody to lead on taking care of the signoff criteria
...
<Kai> Scribenick: Kai
<jo> ACTION: Dan to raise ISSUE on setting criteria for group sign off on mobileOK checker once the task force says it is done with the work [recorded in http://www.w3.org/2007/11/05-bpwg-minutes.html#action01]
<trackbot-ng> Created ACTION-586 - Raise ISSUE on setting criteria for group sign off on mobileOK checker once the task force says it is done with the work [on Daniel Appelquist - due 2007-11-12].
<jo> Bugzilla for Checker
Mike: Is there a list of who is
on the TF?
... so people have a contact
Jo: I think that's it for the checker.
<MikeSmith> I'll update the Checker TF page with list of names of BPWG members who have been involved in the Checker TF work
Alan: (showing a
presenation)
... started this TF in July
... the basic idea is to allow access for as many people as
possible, regardless of disability
... users have different problems...sensory such as vision or
hearing....motor as in using a keyboard or mouse
... technological such as old computers and slow
connections
... some disabilities there fore are due to the user some due
to the device.
... mobileusers may use screen readers or magnifiers
... some may use large keyboard if they have motor related
disabilities
... there are lots of parallels between disabled users and
mobile users only that disables users are involuntarily
disabled.
... mobile users choose to use a mobile device and therefore
will not have a mouse
... they may use a screen magnifier..there may be no sound or
be in a noise space where you can't hear anything.
... unlike mobileOK accessibility may be a legal requirement,
as in the US, the UK and the EU has made it a priority.
Jo: if it had been mandated for the CA fires for public sites to be mobileOK to provide emergency information
Bruno: (introducing
himself)
... an example in Stockholm was to buy busticket. You can only
do it via mobile.
... so there is an increasing amout of mobile access and here
we have a good start.
... looking forward for this european law being passed. It is a
resonable set of requirements.
alan: mobile awareness,
accessibility is a good thing to have.
... it is a requirement because users don't have a
choice.
... there are different stake holders
<MikeSmith> Scribenick: MikeSmith
Alan: Has it been considered by the Checker TF that some tests may have already been implemented by Accessibility checking tools?
jo: Very good thought ... I wish somebody has asked that a year ago
chaals: I have something like
that in my back pocket ...
... but the development is all being done in Spanish
<chaals> [/me is very worried if authoring tool vendors are not considered to be a critical stakeholder]
Bryan: There is perhaps another stakeholder you might want to add: Service providers (e.g., mobile operators)
<scribe> ACTION: Mike to upload Alan's slides to W3C webspace [recorded in http://www.w3.org/2007/11/05-bpwg-minutes.html#action02]
<trackbot-ng> Sorry, amibiguous username (more than one match) - Mike
<trackbot-ng> Try using a different identifier, such as family name or username (eg. mchadwic, mike)
<scribe> ACTION: Michael to upload Alan's slides to W3C webspace [recorded in http://www.w3.org/2007/11/05-bpwg-minutes.html#action03]
<trackbot-ng> Sorry, couldn't find user - Michael
<scribe> ACTION: Michael(tm) to upload Alan's slides to W3C webspace [recorded in http://www.w3.org/2007/11/05-bpwg-minutes.html#action04]
<trackbot-ng> Created ACTION-587 - Upload Alan's slides to W3C webspace [on Michael(tm) Smith - due 2007-11-12].
<jo> Use Cases for Accessibility Document
<scribe> Scribenick: SeanP
Alan: Stakeholders need
non-discrimination, content providers and tool vendors need
advice on how to leverage investment
... 2 documents: accessability guidelines and MWBP
... Need a document to bring the two together to avoid
duplication, etc.
... What can MWI and WAI do: Explain synergies between the
two
Some technical difficulties
Dan: How can we put some of the
accessibility stuff into the document we are creating as part
of charter 2?
... Can we have the discussion tomorrow?
... I see a trend toward creating rich apps for mobile
browsers
... If we are going to encourage developers to create rich apps
for mobile devices, we should tell them how to do it in an
accessible context
Alan: Mentioned ARIA document
<chaals> ARIA -> http://www.w3.org/WAI/intro/aria
<chaals> [it is a collection of specs, actually, but that gives a reasonable introduction]
Alan: We're creating a document
that contains: user experience (ex: large pages are hard for
users with restricted vision)
... Color difficult for colorblind people and users with
black/white screens
... Information is there in document, but needs more work to
make it useful
... document covers each of the mobileOk best practices
Dan: the publication of the accessibility document can give a idea of the relationship between the BP document and the WAI document
Alan: example: the BP document is
concerned with devices that don't have color, the WAI document
is concerned with colorblind people
... next section in document: How WCAG compliance can benefit
mobile users
... MWBP contains unhelpful "related to" references that are
confusing
... Out of scope for accessibility document: making content
accessible on mobile devices
... Task force history: started July 2007, several agreed to
take part, Alan got little feedback until recently, getting
feedback from new members now
Jo: (Looking at mailing list) Looks like you're now getting more participation
<jo> [break for coffee]
Jo: Moving on to discuss where we
are now (accessibility)
... Alan has done an amazing job. Document looks good and we
need to capitalize on what he has done so far. Need to get more
people involved.
Alan: (Going over contents of accessibility document)
Jo: How much input have you had from accessibility people?
Alan: Very little so far.
Jo: do we need endorsement from WAI?
Alan: Has had positive
communication with the WAI board
... The WAI education and outreach board has been very
enthusiastic
Jo: Saying that this is a very
important piece of work. Has some support of WAI
... How can we take this work forward?
... Situation with task force--task forces must have 3 active
members
... We don't have three active members of the accessibility
task force
... I think we should take this into the working group as a
whole and work on it as a whole group
<DKA> +1 to Jo's proposals.
Jo: We should publish the
accessibility document now, even though it has some holes
... propose that we close down the task force
Dan: Supports Jo's proposal
<j1> PROPOSED RESOLUTION: Close Accessibility Task Force with a view to continuing the work in the main body of the group
Bruno: Support it as well. Should have some sort of dialog about it.
<rob> +1
<j1> PROPOSED RESOLUTION: Publish document as a FPWD pending adding section of future plans ref WCAG 2.0
Dan: should have some contact with chair of hypertext working group
Alan: Seems strange for entire group to be working on something that another group has as its main job
Charles: In many ways in
agreement with Jo; should have agreement with WAI; usual way
that that is done within W3C is a joint task force
... Don't think we should go to first public working draft
without involvement of WAI
Dan: joint task force seems even
more complex
... We can show that BPWG is working on this topic.
<Kai> ScribeNick: Kai
<SeanP> Charles: Setting up a joint task force is pretty lightweight. Don't think that we should do it without WAI involvement
Dan: my concern is that we set up another set of meetings or calls that will happen at a different time.
<chaals> ALTERNATE PROPOSED RESOLUTION: Coordinate with WAI to jointly Publish document as a FPWD
Dan: if we do it in the group, we
discuss it within the group.
... so I like taking it into the main group.
Chaals: I suggest from the mobile
web side our whole group is the task force and we can invite
folks to sign up
... there is some overhead in coordination
Jo: alan you haven't said anything?
Alan: It seems to me that is
something done jointly with WAI and should be done here in this
group
... WAI doesn't know much about our work but we know their
work.
Dan: could we do this by using the coordination group for this very purpose?
chaals: That should provide the basis for coordination. WCAG is quite old and so there won't be a lot of question about this document.
Jo: we have two proposed
resolutions. is there a virtue in keeping the TF going?
... if not I would like us to take the first resolution.
<j1> PROPOSED RESOLUTION: With thanks to Alan close Accessibility Task Force and continue the work in the main body of the group
+1
<srowen> +1
<chaals> +1
<rob> +1
<edm> =1
<j1> RESOLUTION: With thanks to Alan close Accessibility Task Force and continue the work in the main body of the group
Jo: now we did to figure out when
we publish the first public draft of this document
... and we should also look for input prior to that first
draft.
Alan: tomorrow the education and outreach working group will be looking at the document
<achuter> http://www.w3.org/WAI/EO/2007/11f2f#Agenda
Chaals: WAI has a technical and
an outreach activity? Where does it belong to?
... this we should figure out and who to coordinate with.
Jo: The flavor of the doc is primarily an outreach document
Alan: The bulks is technical in nature but the intent is outreach
Jo: How do we get to the outreach people?
alan: I will be speaking ot them at lunch
Dan: Do we have to have a fully joined meeting? I think we can just nominate people to get this done?
jo: Alan, Dan and I will talk to
whoever is interested at lunch.
... I also want to resolve to publish this as a first public
working draft.
... so we can get it published within a month.
Chaal: the core is the technical
correspondence and so I think it is more a technical
document.
... so the first coordination needs to be carried forward with
teh techical acivity in WCAG
<j1> ACTION: Jo with Dan to raise this document at next HCG meeting informing them of our intentions and soliciting input [recorded in http://www.w3.org/2007/11/05-bpwg-minutes.html#action05]
<trackbot-ng> Created ACTION-588 - With Dan to raise this document at next HCG meeting informing them of our intentions and soliciting input [on Jo Rabin - due 2007-11-12].
Jo: we might want to look at this
document in detail later to see what we can do with it.
... so we should focus on what we want to with it.
Bruno: a few facts. The chance of
getting feedback is better with the WCAG outreach group.
... it is more important to get the coordination going is more
important than with whom we do it
<j1> PROPOSED RESOLUTION: Pending discussion with WAI Outreach Group on Technical Correctness of the document, aim to publish a draft within a month
Bruno: my biggest worry has been the total lack of mobile topics and so we improve their future release by referencing mobile topics that they find useful.
<Zakim> chaals, you wanted to say I supposeit is WAI's job to decide who they think we need to talk to, and we can address that via HTCG as well as talking to people here.
Chaals: we need to clarify what this document is.
<Zakim> MikeSmith, you wanted to ask about authoring tool vendors
Jo: how about that resolution up there?
Chaals: In the end WAI will figure it out. We should just get the blessing soon.
<j1> PROPOSED RESOLUTION: Pending discussion with WAI Technical Correctness of the document, aim to publish a draft within a month
<j1> PROPOSED RESOLUTION: Pending discussion with WAI on the Technical Correctness of the document, aim to publish a draft within a month
<j1> PROPOSED RESOLUTION: Pending discussion with WAI on the Technical Correctness of the document, publish a draft within a month
Bryan: will there be a comment
period?
... we have been working internally on a recommendation in
terms of our style guide and I need to seek input.
<j1> PROPOSED RESOLUTION: Pending discussion with WAI on the Technical Correctness of the document, publish a first public working draft within a month
Jo: A fair point, but it is a public draft and so we are solciting input.
<DKA> +1
+1
Bruno: A question on procedure. we have two chairs. One of them could present the position of the group tomorrow.
Jo: We'll play it by ear and see where we get to.
<j1> RESOLUTION: Pending discussion with WAI on the Technical Correctness of the document, publish a first public working draft within a month
Jo: thank you alan (applause)
<MikeSmith> j1, srowen - I added a "People" section to the Checker TF page - feel free to change/add names if you like
Jo: Rhys will not be available this afternoon, which is a problem. We need to move the agenda around.
<MikeSmith> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Checker/Overview.html#people
Jo: rhys will be around tomorrow for a lengthy and detailed discussion of what the options are for leading to a publication of the guidelines document.
Dan: We need to make sure he can be there tomorrow.
Jo: we may need to move charter 2
discussion to today.
... we have about 45 min and we can get into the discussion of
getting into tools and HTML 5 points.
Jo: This is Chaals' baby.
... this has been on the agenda for over half a year and we
should get rid of it, since nothing has really happened.
<Zakim> MikeSmith, you wanted to comment on this
Mike: last time we discussed this the only person interested was Chaals and it is likely to assume that nothign else will happen with this. If he wants to he can reopen it. It is time to put it to rest.
Bryan: I think that going forward, developers who want to comply to best practices, it is not clear how to comply.
Jo: the problem we have we all feel that kind of advice is needed, but we have not been able to find an effective way to bring this forward. It is one of the undead and we don't need theundead on our agenda.
Ed: do want to create some continuation of the techniques for charter 2?
<j1> PROPOSED RESOLUTION: Put techniques in moth balls noting that they are no longer actively maintained and noting that there is a possibility of them being reactivated at some point
Ed: now that we gone public, do we have a better forum? does it makes sense? which format should it take?
Dan: is there some way to donate
the work to some other group?
... there are a number of activities that kind of replicate the
work we have done and it woudl be a shame ot have our work not
contributing to this?
Jo: W3C copyright would have to be sorted out.
Dan: I am thinking in particular
of dotmobi.
... its gaining quite a reputation....and so does
Google....
... I'd be happy to step forward and offer this. there are
number of places where it could go.
Sean: Can we just leave it where it is and say it is not being maintained.
Jo: that's what we would do and I have say that Dan's idea is not a bad one. Perhaps he can take an action to take care of this.
<j1> PROPOSED RESOLUTION: Put techniques in moth balls noting that they are no longer actively maintained and noting that there is a possibility of them being reactivated at some point
<srowen> +1
<scribe> ScribeNicK: alan
<j1> RESOLUTION: Put techniques in moth balls noting that they are no longer actively maintained and noting that there is a possibility of them being reactivated at some point
<achuter> scribenick: achuter
<j1> ACTION: Dan to look for one or more likely candidates to adopt techniques and make arrangements ref copyright and attribution [recorded in http://www.w3.org/2007/11/05-bpwg-minutes.html#action06]
<trackbot-ng> Created ACTION-589 - Look for one or more likely candidates to adopt techniques and make arrangements ref copyright and attribution [on Daniel Appelquist - due 2007-11-12].
[Mike updates techniques page]
<j1> ACTION: Michael(TM) to propose text indicating current state of techniques wiki [recorded in http://www.w3.org/2007/11/05-bpwg-minutes.html#action07]
<trackbot-ng> Created ACTION-590 - Propose text indicating current state of techniques wiki [on Michael(tm) Smith - due 2007-11-12].
topic Tools Task Force
Sean: This TF has been overshadowed by checker TF.
Jo: Was more about authoring tools.
Dan: If people are ambivalent about it, better to do away with it.
<j1> PROPOSED RESOLUTION: Kill Tools Task Force, no volunteers are available to lead it
<j1> RESOLUTION: Kill Tools Task Force, no volunteers are available to lead it
Dan: Need for some people who are in this group and the HTML5 group.
Jo: Arun is not able to lead it. So we need someone else
<j1> PROPOSED RESOLUTION: Absent Dan finding a leader for HTML5 Task Force within 2 weeks - Task force to be abandoned
<Zakim> Kai, you wanted to say that it seems much easier to suggest a taskforce than to work in it. If there is no interest we should kill it.
Dan: Work is important (mobile use cases for HTML5) and we need to keep on with it.
Kai: Nobody is going to do it so it's a dead duck.
[Shah and Dan volunteer, but no leader]
Shah: Recent talk about things that affect mobile context. Important to follow it.
<dom> [I do think it is quite important that someone follows the HTML5 work pretty closely]
<j1> PROPOSED RESOLUTION: Abandonl HTML5 TF as there is insufficient support for it in group
<srowen> +1
<Kai> +1
<srowen> (HTML 5 doesn't seem at all keen on thinking about mobile -- don't see a point in fighting this battle more than we have)
<dom> [but having the Web split between mobile-XHTML and desktop-HTML5 is quite contrary to one of the missions of this group, I think]
<MikeSmith> As I've mentioned in the past, I think it might be more productive for reps of member companies in the BPWG to also join the HTMLWG and participate in it directly.
<j1> we appreciate this Dom, but if no one puts their hand up to work on the group then
<j1> we don't have a task force
<j1> it's not that we are not intersted, just incapable
<dom> yeah, I understand; I guess I just find it a bit disappointing...
<j1> me too
<j1> RESOLUTION: Abandon HTML5 TF as there is insufficient support for it in group
[break for lunch]
<edm> scribe: edm
<scribe> scribenick: edm
<j1> [note change from published agenda - CT to take place tomorrow morning]
http://www.w3.org/2007/03/MWBP-WG-charter.html
DKA: BP document should
articulate to the developer community how to develop content
and applications that would work across a wide range of
devices...
... ... and how to take advantage of capabilities of specific
devices.
... e.g., iPhone Facebook - as an example of such an
application
Kai: our job is to point out how to do this cleanly - based on published standards
SRO: BPWG should focus on
standards and interoperability - rather than cool hacks
... ... thus perhaps our ultimate goal is to make
mobile-specific authoring obsolete
DKA: we need to look at specific areas where we could make recommendations - e.g., using scripting on constrained mobile devices
srowen: we should stay away from device-specific applications
DKA: we already told people how to do the lowest-common-denominator stuff - need to look forward
Kai: mobile web is still the focus
Bryan: we need to go beyond MobileOk Basic - to make content more accessible and use web wide techniques
jo: I would like to see some
specific examples of what we might want to recommend
... ... and need to figure out what might be testable
... we should try to sketch out what the BP2.0 document may
look like
DKA: I am actually apprehensive about a growing number of Iphone specific cool applications
srowen: let's have a few examples of what BP2.0 may be about
DKA: some of the iPhone browser
specific features could be illustrative of what we may need to
do to make things work across diverse devices - e.g., screen
orientation
... ... codifying some of that and suggesting how this could be
done should be included in BP2.0
jo: let's come up with 5 specific examples of what could be included in Bp2.0
DKA: setting up a device-optimized viewport - e.g., size pop-ups/layers to fit on screen
Kai: solve the top left navigation problem
DKA: use of pop up menus
... conservative use of XHR
... adapating to screen orientation events
Kai: image cropping and resizing
<Jonathan> http://developer.apple.com/iphone/designingcontent.html
DKA: usability features - in the absence of multiple overlapping windows
Bryan: need to address growing capabilities of devices and suggest how some of the existing technologies should be used - e.g., cookies
Kai: would like to see guidelines on what we expect devices to be capable of - in the mobile web context
<Zakim> Kai, you wanted to speak about clear guidelines for device manufacturers
DKA: e.g., multiple techniques could be used to detect screen orientation - which do we want to recommend?
edm: we should be examining
variability of certain features - i.e., support differences
that make a difference to content and application authors
... ... point out what the typical variations might be and what
could be done to exploit these
Bryan: we should also examine "web consistent" design techniques - e.g., responsible use of redircts and cookies
Bruno: we should not forget less advanced delivery contexts - e.g., slower networks, less advanced devices
DKA: data roaming presents a number of interesting challlenges
Bryan: also how do applications and service providers be made more context aware - considering that some of the relevant info may be available on the device
<Zakim> Kai, you wanted to ask if it is a good idea of limiting again
Bryan: ....e.g., location, roaming context
DKA: need to help spread the one web mentality ...
<rob> scribe:rob
<scribe> scribenick:rob
<jo> scribenick: rob
jo: do the 17 items raised (above) meet the "Owen challenge"?
shah: can we really add value in the context awareness category?
kai: don't think these 17 things amount to a goal
bryan: WRT focus of BP 2.0 should focus on where we can add value to 1.0 as well as going into new areas
DKA: agree need focus and a mission for where to go
edm: yes need continuity with
1.0
... remember we focussed on lowest common denominator
... so today we should look at what's changed
... and find the variability (eg Ajax)
... and ways to discover the capabilities and take advantage of
them.
... And what is there we have never considered before?
... Eg BP1.0 says don't rely on cookies returning - is that
true any more?
jo: reason why BP1.0 worked was
it was mostly "don't do this unless" wheras we're now looking
at "do do this if" which is harder
... and crucially we have no editor for this doc yet
... so we should look at Bryan's doc next
<jo> Bryan's Document
Bryan: doc needs a better intro
and amplification of recommendations
... (walk-through of doc above)
... another example of improving BP1.0 - we say "don't use
tables" but not what to do instead to present tabular
relationships
... think there is a lot of good work in the existing doc, it
just needs to be updated a bit
DKA: take care not to confuse/contradict priorities already in mobileOK
Kai: focus on the needs of the
content providers - who do want to create marketable
stuff
... the clearer the pay-off the more sucessful it will be
<Kai> - we need to simply put the web on a mobile device
<Kai> - we need to "follow the money"
<Kai> - we cannot "merely" focus on developers, because developers are not the ones who get content into the web - it is the marketing people who do so ultimately.
<Kai> - we need to identify clear payoffs for content providers to follow the best practices that go beyond "merely" producing clean content
jo: thanks Bryan for this doc
<Kai> - we need to allow clean ways of breaking out of the standard methods
jo: speaking as editor of BP1.0
we know it has failings and does need reorganisation along the
lines of Bryan's suggestion
... however, is this our top priority right now?
... because it will take a lot of work and time to come to a
new consensus with BP2.0
bruno: thanks Bryan, the doc is a
good indication of where help is still reauired
... would like to see a list of what really are the most common
problems content providers face?
Bryan: intent is not to rewrite
BP1.0 but build on it. recognise how difficult it is
though.
... but still is a need to move up from
lowest-common-denominator
... ATTM has a need for this, even just for their content
developer community
srowen: BP1.0 is already pretty
good, the delta could be smaller than we imagine
... knowing how long BP1.0 took to deliver, may be better to go
for a new document - "Dan's document"
DKA: Bryan's doc does contain a
bunch of new stuff which with the 17 points could be a new
"advanced" document that sits alongside BP1.0
... you could simply say "advanced browsers are capable of
displaying desktop content... job done"
... but market doesn't bear that out - eg http://iphone.facebook.com
... so doc would recommend how to sparkle in the context of
these advanced browsers
jo: in danger of preaching to the
choir?
... don't these content providers know this stuff
already?
... just recently killed the "techniques" item
<dom> [to illustrate what jose is saying, "full-web" mobile browsers rely on <div> to allow for smart-zooming]
jcantera: best practices for advanced browsers are well-known for mobile content providers but for the general webspace people need more help
<Zakim> Kai, you wanted to ask, at end of the day, with BP 2.0 having been created, what will have changed?
Bryan: doc is a fairly thorough review of the BP1.0 omissions and there's probably more stuff missing. how this is all addressed is up for discussion.
DKA: if developers are already writing iphone apps, then a doc to say "here's how to make it work on an N95 and more..." is valuable
<edm> FYI: iPhone Dev Center -> http://developer.apple.com/iphone/devcenter/
jo: original BP1.0 doc was to make things possible. On the other hand is there a real problem needing solving to teach iphone developers how other browsers work?
Philip: motivation for BP2.0 is same as 1.0 - far more people don't understand smartphone capabilities and browsers than do
<Zakim> dom, you wanted to ask BP 1.1
dom: recognise how things have changed in smartphones - developers do need to recognise there is a vast difference in what you can do in a smartphone vs traditional mobile websites
Bryan: story started in BP1.0 is *not* over
<jo> [dom makes distinction between a BP 1.1 and BP2.0 which he says is about Web applications i.e. collections pf web pages and how they work together, whereas BP 1 was about single Web pages]
<DKA> PROPOSED RESOLUTION: The group will work on a document for "Mobile Web Applications Best Practices" and a revision to "Mobile Web Best Practices".
Bryan: to keep progress going we need to address how to scale content to suit more advanced display contexts
DKA: and we need an editor
jo: any doc that we write needs
an editor to shape the scope and drive discussion on
... and we've been round this discussion for long enough to
take a decision this afternoon
[break for coffee]
<srowen> scribenick: srowen
<scribe> scribe: srowen
<scribe> ScribeNick: srowen
DKA: what about this proposed resolution?
jo: useful to separate two perspectives, yes
Kai: not sure if need to worry about revising MWBP -- focus on the future
(srowen: +1 to the as-yet-unpasted proposed resolution)
DKA: I think we can't work on both at once
<jo> PROPOSED RESOLUTION: We will separate the work into "Mobile Web Applications Best Practices" and a revision to "Mobile Web Best Practices" (1.1)
DKA: but should focus on MWABP first
(srowen: +1 to that too)
<jo> PROPOSED RESOLUTION: The Best Practices for Mobile Applications Comes First
jcantera: about the 'MWABP' name -- are we saying the MWBPs are not suitable for mobile web applications?
don't agree with the name
DKA: this comes from a definition of web apps that dom put forth earlier
scripting, XML, AJAX, etc.
as opposed to MWBP's focus, which was the page and markup
jcantera: yes but mobile applications can be created with MWBPs
second document is intended to reach mobile applications too
Bryan: intent was to take recommendations into a different space, from static pages and apps to interactive, autonomous, AJAX apps
is the vision limited to only HTTP-based apps? AJAX-based? or are we talking about a new class of applications outside the browser context?
DKA: I think we are still thinking within the browser
Bryan: what about a widget operating outside the browser but using markup -- is that an application?
DKA: yes
premature to make recommendations about 'widget frameworks' I think
<Zakim> edm, you wanted to ask how the scope of BPWG2 work would relate to what WAFWG and UbiWeb are expected to do?
edm: 'web applications' may create some confusion related to WAFWG and ubiweb
DKA: I think this aligns us with WAF actually
who has a definiiton?
<Zakim> Kai, you wanted to ask if we are not artificially limiting the scope by using web application? Even it may be what we are talking about.
<dom> "With the ubiquity of Web browsers and Web document formats across a range of platforms and devices, many developers are using the Web as an application environment. Examples of applications built on rich Web clients include reservation systems, online shopping or auction sites, games, multimedia applications, calendars, maps, chat applications, weather displays, clocks, interactive design applications, stock tickers, currency converters and data entry/display system
<dom> s.
Kai: are we artificially limiting ourselves? we all have a picture of what a web app is but maybe there is more to it
<dom> Web client applications typically have some form of programmatic control. They may run within the browser or within another host application. A Web client application is typically downloaded on demand each time it is "executed", allowing a developer to update the application for all users as needed. Such applications are usually smaller than regular desktop applications in terms of code size and functionality, and may have interactive rich graphical interfaces. "
<dom> http://www.w3.org/2006/appformats/admin/charter.html
[the noise of reading follows...]
Kai: for example, bandwidth issues have nothing to do with web apps -- we'd be precluded from talking about bandwidth
DKA: thinking of mouseover, event flows, triggering requests to server, which entails bandwidth concerns
Kai: suggesting that our scope is larger than web apps
DKA: the term 'web apps' increases scope -- it includes everything we have done so far, and more
Bryan: this group is chartered to assess impact of these new application paradigms in mobile?
dom: Web app WG is standardizing technologies to produce widgets and so on
we are chartered to look at currently available technologies and advise on how to use them effectively in mobile
<Zakim> dom, you wanted to say the mwabp wouldn't be a superset of bp
Bryan: focus is the mobile environment, yes
<edm> UbiWeb (UWA) charter: http://www.w3.org/2006/10/uwa-charter.html
goal is just to assess how new functionality impacts mobile
dom: this could entail covering new topics, like more about scripting, more about latency
but bandwidth may not be biggest issue
jcantera: if we focus on apps in second document, how do you rationalize existing MWBP recommendations like "don't use tables?" some BPs will not apply any more or make sense
DKA: corresponding bp would be to use tables, where supported, in a certain way, to use scripting where supported in a certain way
we don't want to specify a whole imaginary ADC device, but to say for each BP, if you know something is supported, do it in a certain way
Bryan: maybe we should not 'fix' 1.0, but focus on recommendations for devices beyond DDC in version 2.0
Kai: if we write something that contradicts 1.0 then we did something wrong
<Kai> Proposal of goals for BP 2.0
<Kai> - to prevent, at the onset, the creation of a heterogenous, proprietary content environment
<Kai> - to enable the end user to request content on his mobile device and not notice what the intended audience was (PC or mobile)
<Kai> - to enable authors to create new web applications that go beyond today's scope, without breaking standards (extensibility)
1.0 was created to 'fix' what had already been done
don't want to repeat that
looking at this from end user's perspective -- just want the content
allow developers to break out of MWBP 1.0 restrictions
does not exclude web applications
DKA: enable authors to create new mobile web apps beyond today's scope
advanced applications should "degrade" to mobileOK application
how about including the word 'rich' in the doc title?
jcantera: yes
I was thinking how this affects mobileOK -- important
2.0-compliant content may not be mobileOK without adaption
jo: mobileOK is specific about when mobileOK content should be presented
DKA: maybe we can specify that advanced apps must degrade to mobileOK
we should establish this explicit link between the two
make sure nobody thinks we are contradicting BP 1.0
Kai: we are using term "rich mobile web applications"?
Bryan: how about the dynamic v. static dimension? these kinds of apps tend to be dynamic
Kai: just say best practices for mobile content -- there is more to it -- why limit ourselves and focus on this term
<edm> +1 to NOT overqualifying "mobile web applications" before starting the work...
DKA: do we need to explain the mobile context?
dom: I suggest we keep it simple
<Jonathan> FYI : http://thinkingandmaking.com/entries/63
I think the question is mostly whether we want to focus on this more dynamic, etc., aspect of the web or not. The rest is editorial work
DKA: don't think we need a separate doc on context-sensitive apps
Kai: are we all talking about the same thing
DKA: I think this is one document
Kai: first let us decide whether we need one or two docs?
jo: for example we are not saying what to do with cookies where they *are* supported -- let's find a good way of expressing this
<edm> wonders if we may need to complete first a Scope of BP2 document ...
DKA: we can elaborate this later, after taking a resolution
<jo> PROPOSED RESOLUTION: We will separate the work into "Best Practices for Dynamic Mobile Web Applications " including Determining and Exploiting Mobile Context and picking up on where BP 1.0 leaves off with its "unlesses" and a revision to "Mobile Web Best Practices" (1.1)
<jo> PROPOSED RESOLUTION: The Best Practices for Mobile Applications Comes First
Bryan: what is left for MWBP 1.1?
<Kai> PROPOSED RESOLUTION: We will create a document that builds upon BP 1.0, answers the points which were left open and moves on to BPs for newer, more interactive content.
jo: I think we'd all basically agree with you the doc could use a revision
we've identified some deficiencies over time
this would be an opportunity to restructure the doc -- but feel it's better to wait a year
(srowen: +1 to jo's 2 resolutions)
Kai: trying to capture interactive content and so on
DKA: I like specifically talking about web apps since it aligns with web app formats WG
it is a way of saying AJAX without saying it
Bryan: it is more than AJAX -- HTTP-based apps that use web methodologies
DKA: OMA definition of AJAX is
wider, yes
... it's about using browser context, etc.
Bryan: this notion of widgets fits in?
DKA: no, don't think so, but may inform widget developers too
Bryan: we're talking about using existing HTTP methods and semantics, mime types, etc., right?
dom: yes
Bryan: no sockets, etc?
dom: no, strongly doubt it
<jo> PROPOSED RESOLUTION: We will separate work into two distinct documents. One builds on BP 1.0 and answers the points it leaves open, such as "exploiting device capabilities", "what to do if cookies are indeed supported" as well as Dynamic Web Applications (by which we mean things that can be developed using HTTP HTML Javascript CSS DOM) and Determining and Exploiting Mobile Context ... and another document which will be a new revision of BP 1.0 which corrects, clarifies
<dom> +1 to proposed resolution
+1
<rob> +1
<Kai> +1 and succumbs to the flood of words
<jcantera> +1
<kemp> +1
<abel_> +1
<DKA> +1
<jo> RESOLUTION: We will separate work into two distinct documents. One builds on BP 1.0 and answers the points it leaves open, such as "exploiting device capabilities", "what to do if cookies are indeed supported" as well as Dynamic Web Applications (by which we mean things that can be developed using HTTP HTML Javascript CSS DOM) and Determining and Exploiting Mobile Context ... and another document which will be a new revision of BP 1.0 which corrects, clarifies and restr
<jo> PROPOSED RESOLUTION: We will work on the two docs serially, the AJAX one first, oops
<jo> PROPOSED RESOLUTION: We will work on the two docs serially, the Applications one first
<DKA> +1
<jo> RESOLUTION: We will work on the two docs serially, the Applications one first
DKA: who might be an editor?
<dom> Potential editors: Bryan, Ed
<dom> ACTION: Bryan to report whether he can be editor of the document who shall not be named - due November 19 [recorded in http://www.w3.org/2007/11/05-bpwg-minutes.html#action08]
<trackbot-ng> Created ACTION-591 - report whether he can be editor of the document who shall not be named [on Bryan Sullivan - due 2007-11-19].
<dom> ACTION: Ed to report whether he can be editor of the document who shall not be named - due November 19 [recorded in http://www.w3.org/2007/11/05-bpwg-minutes.html#action09]
<trackbot-ng> Created ACTION-592 - report whether he can be editor of the document who shall not be named [on Edward Mitukiewicz - due 2007-11-19].
(srowen: I note that adam connors, not present, is interested in this area and may be able to contribute to the editing)
<dom> (great thing to note, srowen, could you nudge him about it?)
DKA: we are a bit behind milestone schedule
move req to Q2 2008
dom: this is the charter, we can't quite modify it
we should put a copy on the home page and update it as needed
jo: action someone to update home page with new timelines
I will take it
DKA: XHTML Basic 1.1 is ...
dom: now a candidate recommendation, not a proposed recommendation
we cannot do much until then
jo: how long will the transition take?
dom: BPs are in proposed recommendation since last november due to the dependency on XHTML Basic 1.1
needs to prove some implementations
inputmode is a difficulty -- it is not really in fact implemented
we found one implementation
we try to find at least two implementations of each feature
now contacting vendors about producing implementations
the situation is not simple
jo: some mobileOK Basic can't get past PR now either
dom: yes, I think we should not move from CR until BPs move forward too
being stuck in PR is not usual for a year
DKA: mobileOK Scheme
srowen: does this exist?
jo: maybe mine; Kai has been working on it too
DKA: wrapper for mobileOK + labels? do we need it?
jo: yes
DKA: so what is the status -- can we approve it?
what is a reasonable deadline?
jo: I think we need it
DKA: checker is ready to go
(srowen: more or less, needs work)
srowen: checker deadlines are... beta in late 2007? we can call it "1.0" -- it is more of a question of how refined we want it to be before calling it "good enough" for initial release.
could be 2007
do we need "scheme"? seems like "labels" will just describe its own relation to everything else
jo: I think it describes more like the circumstances in which it is used, etc. I can maybe edit this by Q2
DKA: will phil be here tomorrow? he is the labels editor
jo: we have a draft from Oct 18
MWBP 2.0 is probably Q1 2008.... seems tight
this is the "applications" doc
DKA: can we strike ADC?
jo: we need to conclude and reset timeframes
srowen: think we need to kill more docs, like mobileOK Pro and Scheme. we signed up for more than we accomplished already, and just invented two more docs, and conclude we are behind. let's be real and kill more
jo: yes but think we need to keep scheme -- maybe kill the trustmark doc?
DKA: MWBP 2.0 is what we just talked about; "future BPs" is our "1.1" doc
ADC we killed
mobileOK Tests second level -- we need to discuss tomorrow
labels/scheme: need to discuss with phil
srowen: still think we will need to forget more of this to make room for MWBP 2.0
DKA: let's stop for today
<jo> 11 Springfield