Hi Daniel, On Monday, 22 July 2013 at 17:59, Daniel Buchner wrote:
> In my opinion, the current spec's complexity in relation to its feature goal, > is high. I'm not sure what this means, to be honest. The engines that have used widgets always managed to do it without significant problems and seem to be fit for purpose (in the way's they use the capabilities afforded by the format) - I'm of course, extremely bias as I wrote the things and was directly involved with many projects using widgets. Regardless, for example, Opera's Extension platform successfully used widgets and related technologies without significant problems (it was then abandoned in the switch to Blink, as Opera is now able to cleverly leverage Chrome's extension platform). Also, WAC's runtimes made use of widget's <feature> element to enable APIs without any problems, AFAIK (see http://specs.wacapps.net/). > This doesn't mean it was a bad spec or deficient, it could be due to a number > of factors: different assumptions about what widgets should do, packaging > choices that existed before web apps gained steam, or a different focus on > where and how widgets would be displayed. In the case of WAC, I think it was just poor execution (compared to, say, FirefoxOS and the great developer drive behind it … again, I'm bias because I work for Moz also ^_^). Opera Extensions were quite successful as a platform and served Opera's users well, IM-Biased-O. Anyway, I could rant for hours about how different *product management* choices affect the uptake of widget technologies :) > I'd like to step back and formulate a strategy based on the progression and > growing prevalence of widgets on native mobile platforms, as well as how we > can align widgets with the packaging and distribution of web apps. This is basically what we are doing with: http://www.w3.org/2012/sysapps/manifest/ > The paradigm of declaring/packaging widgets inside app packages is a > beneficial pairing that reduces the amount of code and management developers > are forced to think about, while taking advantage of natural synergies that > result from reusing a common base. I see widgets as a web page (perhaps the > same page as a "full" app, if the dev chooses) with near-zero additional, > cognitive overhead. Declaration via the app manifest is a huge piece - I'd > argue that this alone would realize a huge increase in developer utilization. Historically, this has not been the case however. Web apps are significantly different beasts to the experience provided by a packaged application: packaged apps offer a more tradition software experience, while web apps generally work better as services (… someone should try to do a PhD about this… oh, wait! that poor fool was me :) ). > Let's look at current consumer perception of widgets, and how the space is > evolving: > Widgets are commonplace on mobile platforms true. > In the view of consumers, search, discovery, and purchase/installation of > widgets is now distinguishable from apps true (in some stores). > Widgets remain a feature used primarily by savvy users, but new presentations > will blur the lines between what a widget is - let's get ahead of this! Sure: this was the intention of the view mode media feature. > The last point here is important for the next generation of 'widgets'. > Widgets in the "statically-present-on-a-home-screen" incarnation are > currently the most recognizable form, but this is changing. Look at Google > Now - those cards, they're just widgets IMO. Sure, or they could just be iframes. Point is, there is more than one way to skin this cat: the use case is more important than what technology is used to address the use case. > Conclusions: > If users no longer distinguish between apps and widgets in practice, a common > packaging vehicle makes sense. I believe we have this covered by the suite of specifications already available. For those that want packaged web apps "today", they can use: "Packaged Web Apps (Widgets) - Packaging and XML Configuration" - http://www.w3.org/TR/widgets/ For those that want to "install" web pages (or have an allergic reaction to XML), the Web Manifest format is under development: http://www.w3.org/2012/sysapps/manifest/ And for those that have an allergy to XML, but want things in a zip file - the SysApps runtime and security model spec has that covered: http://runtime.sysapps.org/ > We are seeing proactive, contextual presentation of data in widget-esque > forms on Android and iOS (Moto X looks like it will introduce more of this). > Under the proposed direction of widgets, developers need only know what > context their widget is being evoked in, and how best to layout a UI for the > intended display. (media queries for something like "blocks" - just an > example, you get the idea) > I believe we should retool efforts in this area to focus on sharing the app > packaging vehicle and reducing complexity to near-zero (besides things like > widget-specific media queries) > If we want to make a splash, actively encourage implementers to add features > based on widgets or widgets + apps (this is a feature we've discussed for > future enhancement of the Firefox desktop experience) > I'd like to hear any additional feedback, and your thoughts on next steps. I guess the next best steps in my opinion would be to see what is missing from the view modes spec and the either manifest format (by means of a prototype or just a thought experiment). We spent quite a few years specifying the old Widget stuff (I think we are in our 7th year now?), and I feel like we covered everything you discuss above. IMO, all we need to do is just make use of the stuff now and/or prove where it doesn't actually work (i.e., we might already be done). -- Marcos Caceres
