Re: Charter [via Core Mobile Web Platform Community Group]

On Wednesday, 29 February 2012 at 19:52, Robin Berjon wrote:

> Hi Marcos,
>  
> On Feb 29, 2012, at 19:01 , Marcos Caceres wrote:
> > On Wednesday, February 29, 2012 at 5:06 PM, Robin Berjon wrote:
> > > I don't think anyone would have noticed if you hadn't brought it up.
> >  
> >  
> >  
> > Shheesshh… you ask for a review and when you get one… :(
>  
> Don't get me wrong, I very much appreciate your review, and you do bring up some important points later. But we're trying to break the ancient unspeakable curse that makes every spec take five years to ship. So no offence to you but stylistic considerations are not as important as anything else, and can take a back seat while we battle our lovecraftian nemesis that is spec timing.
I'm sorry, and here I stupidly thought we were trying to put a charter together as a community so we could agree on scope and *specs we might work* on together … as a community (I did not even know we had a proposal for a spec at all, so I didn't sign up for the timing fight?). Or have you guys already decided behind the scenes what you are going to do ahead of everyone else and how you are going to do it?  

Or perhaps informing and being open with a community and with folks that want to participate is what slows everything down? That may be true: agile, small, focused teams might be more efficient than having 80 people sending in comments - but that mode of operation should be captured in the charter (i.e., "A select group of individuals will work on spec X undisturbed; and when they are done, they will drop it back here for feedback."). I would not have a problem with trying something like that if you think it would move things along faster (and captures the JFDI-spirit).     
> > > > The point is that some things are identified best at features and others as use cases… I needed to detect an iPad because I needed to add touch enabled scrolling, but only for the iPad (and not for Desktop).  
> > >  
> > >  
> > > It looks to me like you're using UA detection when you should be using feature detection (I don't know what "iScroll" does).
> > http://cubiq.org/iscroll
> >  
> > No, Chrome may support touchEvents, but I want to know if you are "on an iPad". It doesn't help me to know if touchEvents are supported because you may be using a Desktop browser with a mouse and keyboard (hence the experience would suck for you if I gave you the iScroll enabled version).  
>  
> Without getting into a discussion of the amount of bad practices going on here,
I think that is kinda the point - we need to have the discussion (because they form real use cases). I'm willing to pull up my skirt and have everyone inspect my code - but not have my work dismissed as "bad practice going on here": it's an example of how an average developer does something and I'm sure it's no worst than what anyone else is doing (i.e., don't go dismissing stuff because it doesn't meet your ideals about "best practice" … it is what it is… and I'm sure you will be disappointed if you go viewing the source of other sites too).  
> isn't the feature you want just touchscreen-compatible positioning and overflow scrolling?

No, that doesn't work (specially on the iPad, where overflow-scroll requires a two finger gesture that *feels unnatural* and hence hardly anyone knows about it!). I want to know if you are *right now* accessing the site through an touch enabled device AND are actually touching stuff. That determines how big I make things on the screen, where I put things so you can reach them with your thumb easily and comfortably, and make sure I don't put things under your thumbs so you won't touch them accidentally. So, no, it's not as simple as you describe: the user experience and design of the site can be radically different if I know for sure that you are on "touch only" VS you are coming at this with a mouse and keyboard - plus the iPad may have a very specific way of handling touch-scrolling that may not be the same on other devices (where overflow-scrolling just works with a one finger touch… hence, iScroll.js to save the day on the iPad for me).     
> > > It is taking the problem to the responsible WG. That's what we do when we see a gap. Says so in the charter.
> >  
> > Right, but why not go straight there? What does this group provide us that we currently don't get from the relevant groups.
>  
>  
> "The goal of the Core Mobile Web Platform Community Group (CG) is to accelerate the adoption of the Mobile Web as a compelling *platform* for the development of modern mobile web applications."
Ok, don't want to get all Derrida here and deconstruct the above… but most of the words there are talismans, don't exist, or are relative. Moving on.   
> Most groups are tasked with solving a single problem: drawing some vectors, producing some sound, interfacing with the home toaster. This group takes the platform view. It's likely that we'll spot gaps with this approach that aren't visible if you're only looking at segments.

I'm all for it.   
> > > Cf. previous comment about brains, knowledge, experience, etc.
> >  
> > Ok, lets make sure we get the right people from each WG in there… like the Chairs from HTML, CSS, WebApps etc. (I know Artb and Chaals are already on the list!)
>  
> Obviously everyone is welcome, but I wouldn't want to make that a prerequisite since a lot of the time it would be busy work for those people unless they're specifically interested in the minutiae of our work. Everyone here is of course encouraged to build up personal relationships in other groups in order to lubricate interactions!

At some point, we are going to have to take the work over to those groups. Best wine them and dine them and shower them with gifts as early as possible … or is part of strategy to "route around" the W3C WGs and lobby browser makers directly instead? That might also work. I know from previous experience that browser makers try to work very closely with large content providers, such as Facebook to make sure things always run smoothly for users: users blame the browser when stuff breaks, not the websites!       
> > > That might be a problem when we get to Ring 2 or so. For previous rings, certainly for ring 0, I would expect that if you don't understand why developers need a given feature then you've never written a web app that works on a mobile device :)
> >  
> > I don't know anything about the rings things yet, sorry.  
> > > Either way, right now we don't have demands. JFDI dictates that we cross that bridge when we get there. Right now the first order of business is setting up the work-mode rules and pushing a Ring 0 document out. Problems will be dealt with as they happen.
> >  
> >  
> > Ok, obviously there have been discussions behind the scenes about pushing out rings or whatever… for those of us not in the know, can you articulate what you are about to JF-Do? What is this Ring 0 document? It was not in the charter and I've not seen anything on the mailing list?… bah, I never get the memo :(  
>  
> There is no cabal :)  
Booo! :( Life in standards bodies is never as exciting or conspiratorial as I want it to be.  
> "Ring" is just a convenient name, it works nicely with what the Ringmark people have been doing, see http://rng.io/.
>  
> The notion of Ring encapsulates this:
>  
> "The CG will develop a series of specifications which combine core features from web standard specifications by the W3C and other standards bodies. Multiple levels of the specification will be published and each successive level will build on the previous one by adding new features."
>  
> It's similar to levels but across a set of specifications instead of just for one silo. If you think in terms of timing for the platform to be delivered, you are likely to splits things up into three buckets: Now, Soon, and Afterwards. That ought to give you Rings 0, 1, and 2 :)
Ok … that sounds conveniently "cabalish" (I'm going to pretend, at least… just to make my life more exciting) :)  
> > Ok, I hope so… but I do see a lot of ex-[Favorite Failed Mobile Industry Initiatives] participants on the CG participant list (I include myself here!). So it's natural that people will ask "not this, again?! (face-palm!)". Hope we can do it differently and learnt from previous mistakes.  
>  
>  
> Yeah, let's make more interesting mistakes this time around :)
Indeed! Happy to help make 'em … by your judgement of my javascript/web skills, I'm an expert ;)  

Kind regards,  
Marcos

Received on Wednesday, 29 February 2012 22:46:21 UTC