06:36:24 RRSAgent has joined #bpwg 06:36:24 logging to http://www.w3.org/2008/10/21-bpwg-irc 06:36:26 RRSAgent, make logs public 06:36:26 Zakim has joined #bpwg 06:36:28 Zakim, this will be BPWG 06:36:28 ok, trackbot; I see MWI_BPWG()2:00AM scheduled to start 36 minutes ago 06:36:29 Meeting: Mobile Web Best Practices Working Group Teleconference 06:36:29 Date: 21 October 2008 06:36:38 Chair: Jo, DKA 06:37:43 Meeting: Mobile Web Best Practices Working Group F2F Meeting Day 2 06:37:58 Regrets: Soonho, Bryan 06:38:31 Agenda: http://www.w3.org/2005/MWI/BPWG/Group/Meetings/Mandelieu/agenda.html 06:46:26 RRSAgent, draft minutes 06:46:26 I have made the request to generate http://www.w3.org/2008/10/21-bpwg-minutes.html francois 06:48:25 rob has joined #bpwg 06:50:09 JonathanJ has joined #bpwg 06:51:36 JonathanJ has left #bpwg 06:53:17 SeanP has joined #bpwg 06:54:25 Kangchan has joined #bpwg 06:54:46 JonathanJ has joined #bpwg 06:55:20 seungyun has joined #bpwg 06:57:08 Present: Abel, Nacho, Adam, Rob, Jeff, Jonathan, Francois, KaiS, Dom, DKA, Seungyun, SeanP, KangChan 06:57:31 Observers: SophieAveline, AndrewArch, @@@ 06:58:35 Obeserver: Hyunjeong Lee (from ETRI) 06:58:48 Obervers+ KaiH, HyunjeongLee 06:59:44 hlee7 has joined #bpwg 07:01:00 Scribe: Francois 07:01:05 ScribeNick: francois 07:01:10 HLEE7 = HyunjeongLee 07:03:40 SeanP, can we swap our scribing sessions? I'll have to go to another meeting at 15:30? 07:07:58 jeffs has joined #bpwg 07:08:05 DKA: [welcomes participants] 07:08:26 welcomes in progress at TPAC face-to-face 07:09:32 jo has joined #bpwg 07:10:12 Kai has joined #bpwg 07:11:02 dom has changed the topic to: BPWG F2F Day 2 07:11:08 DKA: Spent yesterday on Content Transformation 07:11:27 ... Made a lot of progress, which is good, but we now only have one day to run 1.5 days of schedule. 07:11:58 ... I'd like to clean our morning session so that we can address Mobile Web Applications Best Practices 07:12:55 Jo: We could rather do a few easy things such as mobileOK Scheme, mobileOK Basic Tests, then we have Stéphane 07:13:27 DKA has joined #bpwg 07:14:05 ... in short try to leave the afternoon for Mobile Web Applications Best Practices. 07:14:15 abel has joined #bpwg 07:16:34 DKA: [playing with the agenda] 07:16:45 http://docs.google.com/Doc?docid=dd3jk8v_128gb3xp5hq&hl=en 07:17:10 Topic: mobileOK Scheme 07:17:12 http://lists.w3.org/Archives/Public/public-bpwg/2008Oct/0050.html 07:17:35 (> http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/081018 mobileOK draft 45 07:17:44 s/mobileOK Scheme/mobileOK Scheme - mobileOK Basic Tests/ 07:17:44 s/(>/->/ 07:17:58 -> http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/081018 mobileOK Basic 1.0 Tests 07:18:10 Jo: I'd like to start with a first resolution on mobileOK Basic Tests. I sent an email shortly before the meeting. 07:18:20 aconnors has joined #bpwg 07:18:24 steph has joined #bpwg 07:18:25 ... Changes in the latest draft are pretty limited. 07:18:47 q+ to note that Thomas said "close enough" 07:19:12 Topic: MobileOK Basic Tests HTTPS Change 07:20:00 ... the only difference is the insertion of the HTTPS section, removed from the HTTP Response section because it did not quite fit there. This was triggered by a comment from the Web Security Context Working Group. 07:20:18 ack fr 07:20:18 francois, you wanted to note that Thomas said "close enough" 07:20:19 ... I'd like us to resolve that we request transition of this document to Proposed Recommendation. 07:20:37 nacho has joined #bpwg 07:21:01 francois: I sent the link to Thomas yesterday who said "close enough". 07:21:36 PROPOSED RESOLUTION: Request Advancement of mobileOK Basic Tests to PR, skipping CR on the basis that implementation experience informed the return to Last Call, and those issues have been dealt with. 07:21:56 +1 07:22:00 +1 07:22:08 +1 07:22:08 +1 07:22:09 +1 07:22:09 +1 for jo (in absentia) 07:22:16 +1 07:22:41 +1 07:23:12 PROPOSED RESOLUTION: Request Advancement of mobileOK Basic Tests to PR, not waiting until the checker catches up with latest small change, skipping CR on the basis that implementation experience informed the return to Last Call, and those issues have been dealt with. 07:23:23 dom: independently of the update of the Checker? 07:23:31 Jo: I'd prefer so. What do you advise? 07:23:38 dom: yup. 07:23:46 RESOLUTION: Request Advancement of mobileOK Basic Tests to PR, not waiting until the checker catches up with latest small change, skipping CR on the basis that implementation experience informed the return to Last Call, and those issues have been dealt with. 07:23:49 +1 07:23:57 jo has joined #bpwg 07:24:35 andrew has joined #bpwg 07:24:42 DKA: wonderful outcome, and the resolution is taken before 9:30am :-) 07:24:56 Jo: OK, back to mobileOK Scheme. 07:26:06 -> http://lists.w3.org/Archives/Public/public-bpwg/2008Oct/0049.html mobileOK Scheme 07:26:14 ... A bit of history, two years ago, one mobileOK, splitted into mobileOK Basic and Pro, yada yada. I ended up being the editor of the Scheme document. 07:26:53 ... The document explains what are the relations between the best practices and mobileOK, how to claim for mobileOK confromance. 07:27:07 ... It is a relatively short document 07:27:17 [scrolling through the document] 07:27:52 Jo: The "claiming conformance" part will have to be revised on the light of the legal license we talked about yesterday. 07:29:03 ... The section details how put a machine-readable claim in a page. 07:29:21 ... The RDFa solution is a bit misleading since an RDFa doc is by definition not mobileOK. 07:29:24 Kai has joined #bpwg 07:29:44 ... but it could be put in a representation that is not the mobileOK representation. Anyway. 07:30:17 ... In short, I think the document is the one we should produce but the details need to be sorted out. 07:30:26 ... If you have other views, please say so. 07:31:07 q? 07:31:12 q? 07:31:18 q? 07:31:22 q? 07:31:32 DKA: do you need a machine-readable claim to claim conformance? Does the presence of the image constitute a claim in itself? 07:31:33 q+ to point out that maschine readable claim may aid in propagating mobileok 07:31:42 Jo: That's one thing we need to resolve. 07:32:27 ... We may consider that putting the logo is enough. 07:33:06 Kai: If we have a machine-readable claim, it makes propagation mobileOK easier. 07:33:28 RRSAgent, draft minutes 07:33:28 I have made the request to generate http://www.w3.org/2008/10/21-bpwg-minutes.html dom 07:33:29 DKA: Taking it from the perspective of a site manager of company X. 07:33:50 ... They know that their resources are mobileOK, and now they want to set the claim. 07:33:54 RRSAgent, make log public 07:34:03 q+ i don't like this need for assertion at all 07:34:08 ... What's the workflow? 07:34:12 q+ 07:34:28 ack me 07:34:28 Kai, you wanted to point out that maschine readable claim may aid in propagating mobileok 07:34:37 Jo: I think it's important not to trivialize the notion of a claim. 07:34:58 q? 07:35:21 DKA has joined #bpwg 07:35:23 ... It's an assertion made by someone that something is true at a given point in time. A logo doesn't say "Jo said that resource X is mobileOK on 20 Oct 2008". 07:35:34 ... The notion of trust is important 07:36:07 ... POWDER contains more information, so that could be the reason to push this forward. 07:36:15 q+ to point out that there is a section in the licence which says that groups of resources can be claimed to be mobileok. this may need maschine readability as well. 07:36:24 ack me 07:36:25 ack jeffs 07:36:57 jeffs: could we mandate some string in the ALT attribute that goes with the logo? 07:37:09 Jo: I don't really want us to go down that path. 07:38:49 DKA: The barrier to adoption is higher with POWDER, because people will then have both to understand mobileOK AND POWDER. That may not be as easy as it seems. 07:39:27 Kai: POWDER would help for groups of resources as well. You can group resources in one POWDER file. 07:40:26 DKA: I don't think that's POWDER against logo. It's more how to do it for Mom's and Pop's web sites. And then POWDER could be used for Pro sites. 07:40:39 ... What can we resolve today about this? 07:40:56 how about the validator maintains a registry of MobileOK conforming sites? 07:41:34 Jo: I appreciate the point on simplicity, but I think we should emphasize the fact that POWDER contains more information. 07:42:12 q+ jeffs 07:42:21 q? 07:42:23 ack kai 07:42:23 Kai, you wanted to point out that there is a section in the licence which says that groups of resources can be claimed to be mobileok. this may need maschine readability as well. 07:42:52 DKA: So the workflow would be: you check a page, and you get the POWDER file that you could put at the root of your server. Maybe that should be part of the Checker's results then. 07:43:27 q+ 07:43:30 Kai: if we want people to adopt mobileOK, it has to be true. 07:43:40 q? 07:43:41 ack jeffs 07:43:42 ack jeff 07:44:48 jeffs: I push my students to run their pages through the validator, and what they get as a result is a short piece of text that they can put in their page. Easy. And the thing is it puts the brand out there. 07:44:49 q+ 07:45:52 ack hendry 07:46:31 Hendry: maybe we could maintain a registry of mobileOK web sites. 07:47:00 ... I don't see it really working otherwise. The assertion won't be always true. 07:47:04 q? 07:47:07 ack jo 07:47:21 Jo: I acknowledge that Kai has a point. 07:48:58 ... In response to Jeffs, the point in mobileOK is that there are little details we want to push forward. It's a statement that at some future point when you resolve a URI, it will be mobile-friendly. 07:49:13 ... Running a checker is not necessary (although most probable). 07:49:47 ... In particular, it's not so much a claim saying "I passed the tests" even though it is by definition. 07:50:03 PROPOSED RESOLUTION: With regard to MobileOK Scheme, it must be rationalized with the new terms & conditions of the logo usage. Some machine-reable version of the claim must be present - the logo is not enough on its own. 07:51:17 dom: I think POWDER is a nice thing to encourage, but having the logo is the most important thing to have for people in the short term. 07:51:38 ... Personally, I would certain go to say that the logo is enough. 07:52:33 PROPOSED RESOLUTION: With regard to MobileOK Scheme, it must be rationalized with the new terms & conditions of the logo usage. The logo is enough to claim conformance. However, we will encourage checkers to provide end users with not only the logo but also instructions for claiming with POWDER to encourage the spread of POWDER-based claims. 07:53:11 (is mobileOK scheme targeted to be a WG Note?) 07:53:16 q+ to propose to add the date 07:53:46 [the latest draft of mobileOK scheme says "This document was developed by the Mobile Web Best Practices Working Group. The Working Group expects to advance this Working Draft to Recommendation"] 07:53:49 q+ to respond to Dom 07:53:51 (reluctantly) agree with Kai about including date 07:54:56 DKA: having the checkers return both the logo and the POWDER file would help go in the direction we want people to go in the end. 07:55:17 q? 07:55:20 ack kai 07:55:20 Kai, you wanted to propose to add the date 07:56:12 Kai: My main concern is really about the value of the logo. I would be happy to use the logo. I would just suggest that we take the idea to add the date. 07:56:29 PROPOSED RESOLUTION: With regard to MobileOK Scheme, it must be rationalized with the new terms & conditions of the logo usage (including putting the date in the meta-data of the logo). The logo is enough to claim conformance. However, we will encourage checkers to provide end users with not only the logo but also instructions for claiming with POWDER to encourage the spread of POWDER-based claims. 07:56:40 ack jo 07:56:40 jo, you wanted to respond to Dom 07:57:13 i/Hendry:/Andrew: adding the date the logo could help improve the information carried out by the logo/ 07:57:43 q+ to say how about at least watering down "claim conformance" to "checked with" (less substance) 07:57:57 Jo: what we have produced here is an image without substance. 07:58:17 q? 07:58:24 Kai: I agree. But that's not without substance. 07:58:46 There is a licence connected to it, which gives it more weight 07:59:12 dom: I agree. The question is: are we going to go around and chase people that use POWDER or the logo incorrectly? 07:59:51 ack hendry 07:59:51 hendry, you wanted to say how about at least watering down "claim conformance" to "checked with" (less substance) 07:59:54 ... This would really depends on whether people really use mobileOK, but it's independent of the fact that the claim is made using a machine-readable claim or not. 08:00:34 Hendry: I was suggesting that we tone down "claim" to "checked with". 08:01:00 Jo: I think it makes it as valuable as the sticker my kids get at the dentist: "I brushed my teeth this morning". 08:01:20 q+ Jo to respond to Dom's question on future status of document 08:01:28 +1 08:01:30 +1 on resolution 08:01:33 +1 08:01:38 +1 08:01:40 DKA: I think the proposed resolution here allows for the most basic needs and the evolution towards a more complex scenario. 08:01:42 q+ 08:01:45 0 08:01:46 +1 08:01:53 ack kai 08:01:55 -1 08:02:02 +1 08:02:44 0 08:03:13 +1 08:03:18 Kai: Just to say that since you can provide the claim in a POWDER form along with the text for the logo, we may want to consider that to make POWDER mandatory. 08:03:35 RESOLUTION: With regard to MobileOK Scheme, it must be rationalized with the new terms & conditions of the logo usage (including putting the date in the meta-data of the logo). The logo is enough to claim conformance. However, we will encourage checkers to provide end users with not only the logo but also instructions for claiming with POWDER to encourage the spread of POWDER-based claims. 08:03:43 RRSAgent, draft minutes 08:03:43 I have made the request to generate http://www.w3.org/2008/10/21-bpwg-minutes.html dom 08:03:44 ±1 08:03:58 q? 08:04:03 ack Jo 08:04:03 Jo, you wanted to respond to Dom's question on future status of document 08:04:05 ack jo 08:04:34 dom: will this be going to be a note or a Rec? 08:04:40 Jo: A note in my view. 08:05:25 [break] 08:17:13 see http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Korean/ 08:17:42 RRSAgent, draft minutes 08:17:42 I have made the request to generate http://www.w3.org/2008/10/21-bpwg-minutes.html dom 08:19:45 Topic: Korean Task Force report 08:20:01 scribenick: Kai 08:20:31 Seungyun: I will explain the status of the Korean TF created last March. 08:20:47 http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Korean/#documents 08:20:55 seungyun: want to avoid fragmentation of standards 08:21:02 andrew has joined #bpwg 08:21:37 seungyun: wanted to create a trial service report 08:22:00 ..gap analyis, requirements for new standards 08:22:13 ...showing roadmap 08:22:54 ....want to issue issue a report in January 2009 08:23:27 ...two documents - status of trial and 1st draft of gap analysis 08:23:59 ...goal of the trial service is to defin the feasibility of the web standard 08:24:14 ...have many member to invoke the trial service 08:24:25 ...will do a three year project 08:24:56 .. 2nd phase is an activation stage for apps and contents 08:25:17 ....3rd phase is to complete the mobileok eco system 08:25:30 ...there are 14 organisations participating 08:26:08 ...this year we are developing some key components such a DDR, Test and Certifiaction server... 08:26:17 ...web browser, web portal 08:26:37 scribenick: hendry 08:27:02 seungyun: using device inonformantion 08:27:37 seungyun: showing service scenario 08:28:21 seungyun: issues regarding device context key 08:28:31 ..real world deployment issues 08:28:51 ..no key context of device 08:29:10 ..in Korea URI based devilery 08:29:37 ..Korean opertors do it their way, instead of using standards 08:30:01 s/opertors/operators 08:30:15 ..interested in providing mobileOK services 08:30:46 ..want to provide clearer path for operators to conform to standards 08:31:08 ..no trustmark for mobileOK conformance 08:31:50 ..Koreans considering using their own logo/trustmark for mobileOK 08:32:14 http://docs.google.com/View?docid=ddkw3489_43cfkqjsdm 08:32:33 ..content adaption different meaning to CT 08:32:54 ..content adaption includes media transformation 08:34:04 ..types of mobile device ISSUE. legacy devices not being supported 08:34:57 ..video media is very important in Korea, mobile IPTV is popular. ISSUE re supporting this in mobile 08:35:55 ..trial in development. In december there will be further results published. 08:36:27 -> http://www.w3.org/2005/11/MWI-Icons/mobileOK.png mobileOK logo 08:36:31 jo: restate issue re logo/trustmark 08:36:53 DKA: will rigo's information yesterday address this issue? 08:37:24 seungyun: cannot use logo because our rules are different 08:37:44 seungyun: we need to resolve fragmentation issues between Korea & W3C 08:38:39 jo: asks what is the requirement for different devices (asking for clarification) 08:38:45 q+ 08:39:05 seungyun: contents providers use UA strings to provide services 08:39:44 seungyun: trying to employ standard UA prof approach 08:40:28 jeffs: wondering about different media types like flash & mobileOK 08:40:58 q+ 08:41:04 ack je 08:41:06 seungyun: look&feel is very important for mobileOK adoption using visual media 08:41:06 ack kai 08:41:10 ack me 08:42:10 Kai: suggests using DDC and asks about minimum requirements 08:43:06 seungyun: addressing DDC problem. considering profile based DDC. 08:43:56 seungyun: size issues different in Korea 08:44:20 seungyun: we are setting the page size limit at 50 K rather than 20K 08:45:52 hendry: issues surround trustmark, validity, suggests upto date realtime checking of mobileOK conformance 08:46:25 seungyun: discussing certificate with Figure 3: Basic service scenario for mobileOK trial service 08:47:02 jo: comments the koreans have thought moreabout the trustmark than he has 08:47:28 JonathanJ: showing the gap analysis document 08:48:04 s/thought moreabout the trustmark than he has/taken mobileOK to a greater level of sophistication than we have/ 08:48:19 JonathanJ: going through figure 1 08:48:42 ..analyis of gaps, three of them 08:49:43 ..three types of gaps explained in figure 08:50:01 ..and relations to activities in W3C 08:50:27 jonathanJ: gap 1 - perception differences, gap 2 .- activity differences, gap 3 - diffs in standards 08:51:14 ..three main inputs; mobileOK forum, forum's member requirements & industry at large 08:52:00 .. gap1 market requirements, gap2: standardization scope; gap3: standards 08:52:16 .. focused on gap2 & gap3 08:52:57 .. figure 3 activies in the W3C 08:54:08 ..table 1: comparison chart of differences between elements of mobileOK in Korea and W3C 08:54:38 ..mobileOK basic tests 1.0 <---> K-mobileOK basic tests 1.0 08:55:25 jo: asks for clarification re character sets 08:55:49 JonathanJ: supporting both EUC-KR & UTF-8 08:56:40 seungyun: UTF-8 has the emphasis, though we test *both* 08:57:25 JonathanJ: DDC <---> K-DDC 1.5 08:57:45 JonathanJ: trustmark issue again raised 08:58:29 ..increate value to 50 for external resources 08:58:48 ..page size increase to 50K 08:59:12 ..we need to implement DDC 08:59:42 ..new document K-MWBP 1.5 addressing 20 items 09:00:59 doesn't the web compatibility test do this? http://www.w3.org/2008/06/mobile-test/ 09:01:01 ..type2 relasonship with full browsing. in Korea many way for "full browsing" to be achieved 09:01:34 ..organising deployment task force 09:01:47 ..interested in addressing mobile widgets 09:02:27 DKA: asks to follow widget standards 09:02:37 jonathanJ: yes, will follow standards 09:03:17 ..K-G3-002 evolution of DDC --> K-DDC 1.5 09:03:49 ..html4 included along with xhtml 09:04:13 ..higher minumum screen sizes 09:04:37 jo: how can screen size be tested? 09:04:55 jonathanJ: tests not considered 09:05:23 .. PNG is added 09:05:38 .. supporting ECMAscript 3 09:05:46 .. & AJAX 09:05:52 .. & SSL 09:06:14 .. & DOM L1/2/3 & events 09:07:06 .. Mobile Web Best Practises translated ( no modifications ) 09:07:33 .. CT Guidelines not started 09:07:45 .. looking at 2.0 applications 09:08:18 .. [APPENDIX2: Comparison Table: MWBP 1.0 and K-MWBP 1.5] 09:08:25 .. Black icon is defined 09:08:41 andrew has joined #bpwg 09:09:09 .. finalised at end of year (gap analysis) 09:09:21 .. & proposal coming too 09:10:19 seungyun: overal picture is we support more 09:10:59 DKA: can we take some elements and import it? 09:11:52 jo: we want to use your work 09:12:49 jo: there are practical issues, what can we help you with & how can we work together? 09:13:51 jonathanJ: possibility of back translating additions 09:14:42 seungyun: wanting to avoid fragmentation by working together 09:15:16 jo: suggests liasing telcons 09:16:12 .. in a month's time? 09:16:34 seungyun: every two weeks from there? 09:16:57 jonathanJ: not happy, but ok with this 09:17:18 RRSAgent, draft minutes 09:17:18 I have made the request to generate http://www.w3.org/2008/10/21-bpwg-minutes.html dom 09:17:42 ACTION: Dan to liaise with Seungyun and Jonathan re setting up a call in 4 weeks with a view to having 2 weekly calls in the morning European time 09:17:42 Created ACTION-870 - Liaise with Seungyun and Jonathan re setting up a call in 4 weeks with a view to having 2 weekly calls in the morning European time [on Daniel Appelquist - due 2008-10-28]. 09:31:47 ScribeNick: rob 09:32:01 Topic: MW4D Presentation 09:33:14 steph: Some background information... 09:33:41 ... 1.5bn web users in the world; 4.5bn to go 09:34:02 ... biggest hole in Africa 09:34:13 jo: (and Greenland!) 09:34:49 steph: particulary the poorest on JonathanJ has joined #bpwg 09:34:51 Kai has joined #bpwg 09:35:19 rrsagent, make draft minutes 09:35:19 I'm logging. I don't understand 'make draft minutes', JonathanJ. Try /msg RRSAgent help 09:35:40 ... The point isn't to connect people to the web; the point is access to essential services 09:35:42 rrsagent, draft minutes 09:35:42 I have made the request to generate http://www.w3.org/2008/10/21-bpwg-minutes.html jo 09:36:04 ... There are two trends: 09:36:40 ... 1 is to provide low-cost laptops and internet connections 09:37:24 -> http://www.w3.org/2008/10/sb_mwbp/ Stéphane's slides on MW4D 09:37:46 ... 2 is to use mobile phones; 3.5bn people have access to a mobile phone, 80% of the population is covered with GSM signal 09:39:36 ... Some impressive success stories, eg farmers finding markets for their produce instead of vice-versa 09:40:02 [stephane pumps m-pesa ...] 09:41:16 ... So how can we help and encourage development of access to such services? 09:44:47 ... Four strands: 1) understanding the technology channels; 2) people from these communities who know the needs, education issues etc; 09:46:15 ... 3) the tools to support these people and 4) raising awareness of the whole issue and who can help 09:47:59 ... The MW4D group runs to June 2009 09:48:29 ... and expects to produce a handbook 09:49:21 ... and a roadmap for actions for organisations that will lower barriers to MW4D 09:49:56 ... and to identify a set of resources for all the players 09:50:25 ... There is already a MW4D Factsheet available to everyone 09:50:54 http://www.w3.org/2008/MW4D/ 09:52:17 ... The heart of the group at the moment is the wiki (link from the homepage above) 09:54:31 ... There have been workshops in India and Brazil so far, the next will be in Africa 09:54:55 jo: Is the BBC involved? 09:55:22 ... Lots of their mobile traffic is from Africa 09:55:40 steph: not yet! 09:56:19 dka: Is there any way BPWG can help? 09:57:18 steph: we're not gathering training material yet - but clearly mobile web is one channel and ths will be coming soon 09:58:11 q? 09:58:15 jeffs: This is an issue I want to push - a broad base of people who know how to make these services will drive this 09:58:37 hendry: how did it become *mobile* web? 09:59:16 steph: the web foundation programme "Web for Society" is broader 09:59:39 s/steph: the/dom: the/ 10:01:10 steph: have to recognise the idea of an Internet cafe in some places doesn't exist 10:01:41 ... but GSM penetration is good in these places 10:02:57 ... Even the needs of electricity for mobiles vs Internet PCs are fundamental 10:04:26 dka: Remember Mobile Tech for Social Change in San Francisco on US Election Day 10:04:29 http://barcamp.org/MobileTechForSocialChangeSanFrancisco 10:04:42 (sign up now!) 10:06:27 steph: The huge plus point for mobile services is that you can build them on an existing platform 10:06:51 http://lists.w3.org/Archives/Public/public-bpwg/2008Oct/att-0001/ED-mobileOK-pro10-tests-20080731.htm 10:07:00 Topic: BP1.5 10:08:31 stef has joined #bpwg 10:08:58 Kai: We've reduced the test-like language in the document and moved it to an addendum 10:10:24 "mobileOK best practices" don't exit; we have "mobileOK Basic Tests" and the "Mobile Web Best Practices" 10:10:31 ... So the purpose (of the addendum) is now more precise 10:10:55 ... Test format pass/fail/warn criteria are removed 10:11:29 ... and tests are now evaluation criteria 10:12:19 ... Now does the group have any feedback on this? 10:12:43 q? 10:12:45 ... since te group previously asked for this change 10:13:00 [I certainly prefer the new format and orientation] 10:13:29 jo: I think this doc needs to be an addendum to MWBP but I don't think it has much (or anything) to do with mobileOK 10:14:13 ... these evaluations apply not just to mobileOK but are more widely applicable 10:15:58 ... for example if people see this as a supplement to mobileOK (which is only about the DDC) then some of the contents will be confusing 10:16:48 ... for example some of this document is useful for an iPhone experience which is not likely to be mobileOK 10:17:49 q+ to ask what will be done when mobileOK basic defines a DDC-independent test (e.g. images_specify_size) 10:17:55 Kai: where (aside from the title) are the strong references to the mobileOK Basic Tests? 10:18:19 jo: the BP doc itself loosely contains tests 10:18:35 nacho has joined #bpwg 10:19:07 ... the introduction likns to this doc 10:19:20 s/likns/links/ 10:20:05 q? 10:20:09 Kai: Jo, can you please provide clearer text for the introduction? 10:20:19 ack dom 10:20:19 dom, you wanted to ask what will be done when mobileOK basic defines a DDC-independent test (e.g. images_specify_size) 10:20:36 dom: the switch from test to evaluation is an improvement 10:20:40 +1 to Dom - moving to "evaluation" from "test" a good step. 10:21:00 ±1 to Jo 10:21:29 ... avoiding reference to checker and mobileOK is nore difficult 10:22:30 ... eg best practices on image sizes are impossible to talk about without having a device in mind 10:22:32 q+ DKA 10:22:40 ack d 10:23:06 dka: I don't see the need to expunge references to mobileOK basic 10:23:43 q+ 10:23:44 ... nobody's going to mistake the references to mean it's normative 10:24:04 q? 10:24:10 Kai: I agree with Dan, I don't see the risk 10:24:32 ... and I see advantages in cross-refererences in this family of documents 10:24:42 ack fran 10:24:44 ack fran 10:25:45 francois: The Purpose section can clarify this - the rest of the document can still include references 10:26:31 jo: Now think this document should be titled "Supplementary evaluations for mobileOK Basic" (!!!?!) 10:26:55 francois: mobileOK Basic is based on DDC 10:27:38 jo: What's the "call to action" with this document? 10:27:52 ... ie what are we asking people to do here? 10:28:13 Kai: the Purpose states this 10:29:07 ... it is to provide guidelines on how to get better than mobileOK Basic 10:29:47 jeffs: and it is stuff that requires human intervention, it isn't machine-testable 10:30:10 q+ 10:30:51 dom: These aren't "guidelines" though, they are "evaluation procedures" 10:31:12 q? 10:31:21 ack fran 10:31:26 dka: We're not setting this up as mobileOK Pro though - that isn't clear 10:31:42 francois: I prefer Jo v1 10:32:15 ... we're adding to the lack of clarity about what relates to what 10:32:53 q+ 10:33:06 PROPOSED RESOLUTION: The group agrees with the approach to BP 1.5 started by Kai. 10:33:08 ... so clarification of the Purpose and the relationship between the 3 documents is most important 10:33:09 ack k 10:33:51 PROPOSED RESOLUTION: The group agrees with the approach to BP 1.5 proposed by Kai (removing "test" language and positioning it as an addendum to BP 1.0). 10:34:05 +1 10:34:12 Kai: I'm not sure these evaluations are emopletely separate from the DDC 10:34:21 +1 10:34:31 +1 10:34:31 s/emopletely/completely/ 10:34:42 +1 10:34:57 PROPOSED RESOLUTION: The group agrees with the basic approach to BP 1.5 proposed by Kai (removing "test" language and positioning it as an addendum to BP 1.0). Jo to work with Kai on clarifying 1.1 "Purpose" and present back to group. 10:35:10 +2 10:35:24 +1 10:35:29 +1 10:35:32 +1 10:35:37 ACTION: Jo to work with Kai on clarifying purpose text of bp 1.5 10:35:37 Created ACTION-871 - Work with Kai on clarifying purpose text of bp 1.5 [on Jo Rabin - due 2008-10-28]. 10:35:40 +1 10:35:41 RESOLUTION: The group agrees with the basic approach to BP 1.5 proposed by Kai (removing "test" language and positioning it as an addendum to BP 1.0). Jo to work with Kai on clarifying 1.1 "Purpose" and present back to group. 10:35:43 +1 (CTIC is very happy with the great work from Kai pending editorial issues) 10:36:20 aconnors has joined #bpwg 10:36:29 Kai: Scope needs to change as well then 10:36:47 jo: Yes; we'll cover that in this review 10:37:23 .. There is naff-all point in doing further work on this doc unless the group reads and reviews it 10:38:49 dom: I can reformat the main body of the document if it's not going to change 10:39:01 ACTION: Dom to work on reformulating 4 "tests" of BP 1.5 10:39:02 Created ACTION-872 - Work on reformulating 4 \"tests\" of BP 1.5 [on Dominique Hazaël-Massieux - due 2008-10-28]. 10:39:18 ... can I start on the two tests and pass them back for review? 10:39:27 Kai: Yes, thanks 10:40:06 RRSAgent, draft minutes 10:40:06 I have made the request to generate http://www.w3.org/2008/10/21-bpwg-minutes.html dom 11:38:10 q? 11:43:09 Topic: Mobile Web Application/s Best Practices 11:45:05 ScribeNick: nacho 11:46:06 jeffs has joined #bpwg 11:46:07 adam about to present his documents with discussion points about the BP2 document 11:46:12 PROPOSED RESOLUTION: The name of the document is: Mobile Web Application Best Practices 11:46:52 +1 11:46:56 +1 11:46:57 +1 11:46:58 +1 11:47:08 +1 11:47:43 RESOLUTION: The name of the document is: Mobile Web Application Best Practices 11:47:44 aconnors has joined #bpwg 11:47:53 +1 11:47:56 http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20081008 11:48:54 aconnors: some questions after comments in the document I am using to present 11:49:04 s/http:/-> http:/ 11:49:37 s/ED-mobile-bp2-20081008/ED-mobile-bp2-20081008 Latest Editor's Draft of MWABP/ 11:50:01 better to start by top level headings and refactor the doc and see if there is something important missing 11:50:16 s/better to/aconnors: better to/ 11:50:37 aconnors: some text on SVG from Abel 11:51:02 ... does that sound a reasonable plan? 11:51:21 Kai has joined #bpwg 11:52:08 ... personalization, retaining info between sessions 11:52:16 ... dimishing the need for user input 11:52:51 ... sensibility to network connection quality 11:53:01 .. section on conservative use of resources 11:53:28 hlee7 has joined #bpwg 11:53:44 [reading through the google doc...] 11:53:52 q+ to discuss conservative use of resources 11:54:17 http://docs.google.com/Doc?id=dft77cn8_25gc7r7kcv&hl=en 11:54:38 s/http/-> http/ 11:54:55 s/=en/=en Adam's List of Issues 11:56:41 ... yellow section treated in the last F2F; need for refactoring 11:57:28 ... some formal resolutions needed 11:58:03 .... one web section, wondering whether this is a top leve section 11:58:31 .... UI section, maybe needs refactoring... some stuff needs more level of detail, maybe some additions 11:59:15 Jo: Input from the Korean TF needed 11:59:37 [aconnors adds it to the google doc] 11:59:54 jo: intent of One Web section? 12:00:11 q+ 12:00:14 aconnors: thematic consistency, basically 12:00:59 ... my concern is that the top level headers are not appropriate and consistency of the documents in itself and against the BP 1.0 12:01:12 [someone please correct the scribe on his mistakes] 12:02:18 jo: more than editorial work needed.. there are stuff here that we did not have in BP1.0... a lot more practical stuff 12:04:32 [nacho please asks people to speak a bit louder (not adam and jo :-) )] 12:05:46 ack henry 12:05:52 ack hen 12:06:09 aconnors adding a section in the gDoc on User Experience, mentioning One Web issues within it 12:06:22 PROPOSED RESOLUTION: In BP2.0, "user interface" section becomes "user experience" and "Offer A Consistent View Across Multiple Devices" section goes into "User Experience" 12:06:44 PROPOSED RESOLUTION: In BP2.0, "user interface" section becomes "user experience" and "Offer A Consistent View Across Multiple Devices" section goes into "User Experience" (thereby removing "one web" ase a top section). 12:06:49 s/aconnors/aconnors:/ 12:07:06 hendry: I see UI as HTML+CSS thing 12:07:23 [anybody improving my scribing on KHendry?] 12:07:54 +1 12:08:20 +1 12:08:27 +1 12:08:33 +1 12:08:36 hendry: i do not see the sense of the One Web issue 12:08:48 DKA: it is an important preamble 12:09:24 Rotan has joined #bpwg 12:09:53 francois: how about a first preamble on One Web and then insisting and clarifying within the User Experience subsection? 12:10:00 DKA: right 12:10:12 ... but let's get into resolutions 12:10:30 RESOLUTION: In BP2.0, "user interface" section becomes "user experience" and "Offer A Consistent View Across Multiple Devices" section goes into "User Experience" (thereby removing "one web" ase a top section). 12:10:40 +1 12:10:47 q+ 12:10:59 q- dka 12:11:58 dka: conservative use of resources... from an operator perspective, as more users reach plain data rates it might not bring benefit to operators but it does to the user.. although it fosters the usage of mobile web so in the end it is a win-win 12:13:32 jo: responsiveness is a key point here... smaller apps being rendered faster 12:13:41 ack me 12:13:47 aconnors: i agree but hard to word it 12:13:56 dka: i volunteer to do that 12:13:57 q? 12:13:59 q- 12:14:36 ACTION: DKA to provide some words on conservative use of resources 12:14:36 Created ACTION-873 - Provide some words on conservative use of resources [on Daniel Appelquist - due 2008-10-28]. 12:15:03 [phillip hoschka introducing himself] 12:15:20 [Rotan hanrahan doing the same] 12:16:12 aconnors: we should recap on where we are not, rather than start refactoring the doc 12:17:18 jeffs: about user awareness and control, it should talk about the user retaining control on his PIM 12:18:18 aconnors: renaming "personalization" section into "retaining information on personalization" 12:19:37 ... "handling device capabilit variation" section, need for explaining the need for device clasification to facilitate adaptation 12:20:37 dka: referring contributions in the mailing list about device capability and also section 3.8.3 of the current draft of the BP2.0 doc 12:22:03 jo: original intention in my mind of this section is device clasification in terms of not having classes so use your own classification (but do it) 12:23:21 Rotan: we had a little bit progress about classification (Structures oldie document) and the idea is to write device classification so others can read it... usage of ontologies for modelling that 12:24:13 ... the definition itself is up to the web developers and other stakeholders, but it has to be made in a way that can be understood by others 12:24:54 ... there is a bit of art in this process so it is impossible to "standardize" on what a tablet, or a smartphone is 12:24:58 q+ 12:25:15 ack j 12:25:27 q? 12:26:01 jeffs: conversation with blind people made me think about this... maybe the most important are things like input mechanisms 12:27:23 rotan: if your focus is accessibility, you'll classify based on multimodality and other issues of interest for accessibility 12:27:46 ... but others interested in other issues than accessibility will create other categories 12:27:51 ack me 12:27:57 dka: let's focus on the doc 12:28:37 ... maybe examples of categorization needed in the terms in the current draft (good, better, best bullets in the draft BP 2.0 doc) 12:29:18 ... maybe reference DDR work as the source for classification information 12:29:49 q+ 12:30:45 ack nacho 12:31:06 PROPOSED RESOLUTION: In BP2: Group agrees with the approach taken in 3.8.3 - provide examples of classifications but do not define classifications. 12:31:09 nacho: yes to classification in the bp2.0 just in terms of examplification... and clarifying this 12:31:18 +1 12:31:20 +1 12:31:21 +1 12:31:22 +1 12:31:30 +1 12:31:31 +1 12:31:32 +1 12:31:41 RESOLUTION: In BP2: Group agrees with the approach taken in 3.8.3 - provide examples of classifications but do not define classifications. 12:32:38 aconnors: graceful degradation... more detail than what we might need in this section sometimes 12:33:05 ACTION: aconnors to refine the wording on graceful degradation trimming and making more explicit the text 12:33:05 Created ACTION-874 - Refine the wording on graceful degradation trimming and making more explicit the text [on Adam Connors - due 2008-10-28]. 12:33:36 hendry: what about fallbacks? (when some feature is missing) 12:35:13 [nacho can barely hear jeffs] 12:36:00 DKA1 has joined #bpwg 12:36:41 DKA has joined #bpwg 12:36:47 jeffs: should encourage graceful degradation... when some technology is not supported, provide an alternative content/app to the browser.. exploit device capabilities that the server side knows somehow 12:37:36 hendry: i'd like some words about AJAX here 12:38:57 aconnors: the concept is like the one in google web toolkit... some JS to detect stuff and then the "real" JS for what the browser actually has to do 12:39:26 jeffs: not just degrade, also talk about enhancing in the doc 12:40:01 aconnors: it is useful to recommend to take decisions on the device too (not only server-side) 12:40:36 jeffs: for example, i am offline so proceed accordingly 12:41:08 jo: there are deeper underlined questions, about what is the guidance promoting here 12:43:33 [nacho begs on his knees to jo to scribe his words later as ithard for him to follow his words] 12:43:51 s/ithard/it was hard/ 12:44:17 Kangchan_ has joined #bpwg 12:44:41 ScribeNick: dom 12:45:07 Jo: any assessment you make about the norm is prejudiced by the market you're in, who you're trying to serve, etc 12:45:18 ... your judgment is likely to be fragile in any case 12:45:31 ... so the best advice to give is to tell people to take this into account 12:45:59 adam: should the section on handling devices variation have guidance on what kind of detection to trust? 12:46:20 ... e.g. favor server-side detection, and fall back to on-device decision 12:46:29 ... including things that can not be determined a priori 12:46:48 ... would be good to identify which of these priorities are 12:47:08 Jo: e.g. battery level, signal coverage 12:47:37 JeffS: I think pushing for graceful degradation is important 12:48:15 ... we should advice developers to be prepared to vary based on their mid-point device 12:49:46 Adam: you can do adaptation by having a script that adapts given values to the devices that host it 12:49:53 JonathanJ has joined #bpwg 12:50:04 ... or have different bundle of javascript/stylesheets served on a device per device basis 12:50:10 ... do we want to promote one over the over? 12:50:40 ... it seems like something that is extremely dependent of the applications 12:50:48 Jo: we can point out the trade off 12:51:06 ... although developers would more likely to be looking for more concrete advices 12:51:12 DKA: still think it's worth highlighting 12:51:21 ... if we discuss it more 12:51:40 Jo: we need to point out the variables: time to download, latency, ... 12:51:48 Adam: the cost of maintenance is also an important one 12:52:27 rob has joined #bpwg 12:52:33 q? 12:52:55 SeanP has joined #bpwg 12:53:04 Adam: so we would refactor 3.8.5 to say to favor server-side capabilities detection 12:53:14 ... take into account that some capabilities cannot be determined server side 12:53:46 ... balance adding device conditional statements to a single applications vs having different bundles per devices or devices classes 12:53:50 PROPOSED RESOLUTION: BP2 - refactor 3.8.5 to prefer server-side capability detection ; in some cases, client side cap detection is necessary, in which case: balance adding device specific statements into a single applications or having different modules / bundles ... 12:55:04 DKA: "some of my best friends are media queries" 12:56:13 PROPOSED RESOLUTION: BP2 - refactor 3.8.5 into the form of 3 recommendations: 1) prefer server-side capability detection ; 2) in some cases, client side cap detection is necessary (example); 3) balance adding device specific statements into a single applications against serving separate device-specific modules / bundles. 13:07:50 abel has joined #bpwg 13:14:48 steph has joined #bpwg 13:15:17 steph has left #bpwg 13:21:32 +1 13:21:36 abel has joined #bpwg 13:21:38 +1 13:21:42 +1 13:21:46 +1 13:21:52 +1 13:21:54 +1 13:21:55 +1 13:21:56 RESOLUTION: BP2 - refactor 3.8.5 into the form of 3 recommendations: 1) prefer server-side capability detection ; 2) in some cases, client side cap detection is necessary (example); 3) balance adding device specific statements into a single applications against serving separate device-specific modules / bundles. 13:21:58 Topic: DD Interlude 13:23:41 Rotan: after many years of work, the DDWG is coming to a close 13:23:52 ... the charter concludes at the end of this month 13:24:02 ... hopefully coinciding with the publication of the DDR API as W3C Rec 13:24:25 ... the API comes with a core vocabularies that contain essential properties for basic content adaptation, particularly in the mobile space 13:24:33 ... but it is only illustrative 13:24:45 ... it defines properties such a height, width, accepted mime types 13:24:59 ... you can use these properties to query the repository 13:25:13 ... which can run in front of any kind of system (e.g. a database) 13:25:39 ... The API is a server-side API, described for the Java language but usable in a variety of other languages, incl. IDL, WSDL, C# 13:26:09 ... the API is expected to be used by anybody providing adaption technologies 13:26:16 jo has joined #bpwg 13:26:17 ... the existing solutions operate in silos 13:26:53 ... we're hoping this group will be able to refer to this API when talking about adaptation 13:27:11 ... This API is qualified as "simple", and is quite easy to implement 13:27:25 ... it can serve as an illustration of what more complex systems could do 13:27:44 ... There are other ways to do adaptation: DCCI (developed by the DIWG/UWAWG) 13:27:56 ... that maps devices capabilities into a DOM structure available to javascript 13:28:32 ... there is OMA's DPE (Device Profile @@@), where a server and a device work in concert and enables the server to retrieve information from the server on the fly 13:28:39 ... e.g. whether the user has turned the sound off 13:28:58 ... so useful for information not available a-priori (thus not relevant for the DDR use case) 13:29:20 ... The vocabulary is defined in a very simple way, with references to simple type (string, booleans, etc) 13:29:21 s/@@@/Evolution 13:29:32 ... it doesn't have a formal definition for its concepts, though 13:29:55 ... we're hoping that the ongoing work in UWA to provide a common ontology could be used to provide formal semantics for our vocabulary 13:30:19 ... We expect new vocabularies will be created - e.g. the Korean market place could use a new vocabulary for its use 13:31:07 ... The danger might be that without a common ontology, digression between these vocabularies could appear 13:31:25 ... so having this common ontology with units, dimensions of scripts, etc is critical 13:31:40 Delivery Context Ontology latest public draft-->http://www.w3.org/TR/dcontology/ 13:32:07 ... We will be keeping our Wiki alive even after the end of the group's charter 13:32:15 ... with commitment from editors to maintain it 13:32:37 Seungyun: where are the existing implementations of the API? 13:32:54 Rotan: there is a Java module derived from the spec 13:32:59 ... available to developers 13:33:15 shawn has joined #bpwg 13:33:21 ... there is also an IDL description, and OWL description, coming a c# description 13:33:35 -> http://www.w3.org/TR/2008/PR-DDR-Simple-API-20080917/DDRSimpleAPI.jar Java representation of the DDR Simple API 13:35:46 DKA: so UWA has a work item to continue some of your work? 13:35:59 Rotan: yes, the ontology is a continuation/complement of our work 13:36:11 ... it should be usable to formally define our core vocabulary 13:36:27 ... and should reduce the risks of incompatibilities across vocabularies 13:36:32 q? 13:36:38 Jo: what's the ETA for the first version of the ontology? 13:36:52 Rotan: UWA is meeting at the end of the week - would know more afterward 13:37:28 ... we're hoping to have a sufficiently clear ontology in the next 6 to 12 months to describe the core vocabulary 13:37:46 ... but we need it to work across the various ubiquitous web applications 13:38:10 ... I intend to continue pushing for this work in UWA 13:38:52 ScribeNick: SeanP 13:38:54 Scribe: SeanP 13:39:23 Topic: Back to BP2 13:40:12 Topic: ETSI 13:40:26 Topic: Statement from Bruno 13:40:57 Bruno wants us to review the work of ETSI 13:41:03 s/Topic: Back to BP2// 13:41:13 s/Topic: ETSI// 13:41:35 Jo: [reads statement] 13:42:28 text from bruno: 13:42:31 A team of mobile usability experts in ETSI Human Factors I am leading are 13:42:33 developing a set of guidelines for generic user interface elements for 13:42:35 3G/UMTS mobile devices, services and applications. 13:42:36 Detailed information and an earlier draft is available at 13:42:38 http://portal.etsi.org/stfs/STF_HomePages/STF322/STF322.asp 13:42:39 The work provides: 13:42:41 1) Infrastructure and device-related guidelines: 13:42:43 2) Guidelines for services, media and applications: and 13:42:45 3) Guidelines for other (related) areas. 13:42:46 A topic of 2) is "Mobile Internet access and development guidelines", where 13:42:48 deliverables are a strong reference and starting point. 13:42:50 This and possibly, several other topics addressed may be of interest to MWBP 13:42:52 experts. We'd like to warmly invite those interested to review the stable 13:42:53 draft (to be released by the end of the week) and provide their comments and 13:42:55 feedback. 13:42:56 An availability announcement will be made to the list(s). 13:42:58 For further information and any questions, contact bruno@vonniman.com" 13:43:38 Jo: It is likely that there are some things in here that apply to Mobile Web Best Practices 13:43:56 Jeff: Seems like a short amount of time to review 13:45:01 Jeff: Is is Ok to share this with some of the ACI folks? 13:45:05 ACTION: Jeff to scope current draft and see what aspects may be of interest to us. 13:45:05 Sorry, couldn't find user - Jeff 13:45:09 Jo: I think it is in the public domain. 13:45:32 ACTION: Sonstein to scope current draft and see what aspects may be of interest to us. 13:45:32 Created ACTION-875 - Scope current draft and see what aspects may be of interest to us. [on Jeffrey Sonstein - due 2008-10-28]. 13:45:39 Topic: Back to BP2 (really this time) 13:46:30 Adam: Continuing the theme of handling device definition variability 13:46:59 ...The question is do we want to say "Provide Alternatives to Client Side Scripting" 13:47:23 ... My concern is that no all devices can do this. It may just be ignored if people can't follow it. 13:47:36 ...Not all apps have non-scripting counterparts. 13:48:22 DKA: Could we say something that if your app must have Javascript, we give them a nice message. 13:49:00 ... The "upgrade your browser" message is not great, but better than junk on the screen. 13:49:34 Adam: What is the recommended response? 13:49:42 Jo: use 406 response 13:49:57 ... message goes in the body. 13:50:14 Rotan: Sometimes the error message itself is a source of errors. 13:50:29 DKA: Error message should be mobileOK. 13:50:59 Francois: Not all mobile browsers handle 406. This could confuse the user. 13:51:14 ... Some browsers just say there is a connection problem. 13:51:19 ... just a generic error. 13:51:28 seungyun has joined #bpwg 13:52:09 Jo: Isn't it better practice to send a response "javascript not supported"? 13:52:39 Adam: No, we want to prefer server side detection. 13:53:15 Kangchan has joined #bpwg 13:53:26 ...For an app that requires JS, it is best just to say "Your device cannot support this app." 13:53:35 Jo: 406 is the right option. 13:53:56 Francois: Unfortunately, it is problematic for some browsers. 13:54:24 Jo: How about 200 response with an auto-refresh to a 406. 13:54:41 Adam: Should I put in 406 for now? 13:54:50 Jo: How about a placeholder for now. 13:55:01 Jeff: A point of tension here. 13:55:37 Kai: We are dealing with possible bad app design. May be a bad assumption that a device has JS. 13:55:46 Jo: What about a game that requires JS? 13:56:03 Adam: Not all web apps can work without JS. 13:56:19 Kai: shouldn't have a link to the app in the first place. 13:56:32 Jo: What if my friend sends a link. 13:57:07 Jeff: I think a message to the user would be best. 13:57:22 Kai: What about the