Initial Thoughts

[Snugug]

Thanks for sharing this w/me @aarongustafson! Here are my initial thoughts! I think the real tl;dr takeaway of these is that I think there should be a separation between defining widgets and configuring widgets, and given that separation.

Basic definition thoughts

• Why use tag instead of id given that tag is defined as client.id? tag isn't clear to me on first glance as the ID for the widget.
• Is it widget (as in sample) or template (as in Templated Widgets) to define what widget template to use?

Overall thoughts

• I'm having a little trouble understanding exactly what this is for based on the descriptions here. Would this allow an installed PWA to offer like and Android or iOS homescreen widget? A Mac sidebar widget? A Windows gadget? The Adaptive Card system mentioned at the end seems like a specific usecase, but one I'm not super familiar with (and I'd imagine others may not be). More concrete examples up-front, maybe with low-res wireframes, would help contextualize this a bit more IMO.
• update feels like maybe it should be something like keywords for frequency instead of seconds? I'm a bit torn here, but saying I want this to update every 900 seconds and then having the definition of update be "thanks for your request, we'll get to it when we see fit" feels worse to me than more vague keywords.
• type feels like it is inherently tied to the widget type, or more likely a bit of configuration for a piece of widget data. See next.
• While both "widgets", I actually think that host-provided widgets and user-defined widgets should be entirely separate entities. A host-provided widget, to me, is conceptually a host-provided component, like in a style guide, that has properties and needs specific to that component. A user-defined widget, though, is more like creating your own component, where you need to define those things yourself. The breakdown of needs is configuration vs creation. With this all said, I think this'd make more sense to me if broken down as follows:
  • WidgetDefinition - Focused on creating a custom widget. Requires an identifier (maybe following CSS's lead with some defined prefix, like widget-{{foo}} like data attributes require a leading data-), url as currently defined, and optional data, which would include a list of required and optional parameters (with some way to do validation, probably in the SW) and the type expected for each. backgrounds and icons are optionally be always optional. This would allow someone to define a custom widget as follows:

    {
    name: 'widget-my-w',
    url: '/widgets/agenda',
    data: {
    required: [
    {
      name: 'feed',
      type: 'text/calendar'
    },
    {
      name: 'cities',
      type: 'text/json'
    }
    ],
    }
    }

    Then it can be used as follows:

    {
    name: 'City Feed 1',
    id: 'city-feed-1',
    template: 'widget-my-w',
    data: {
    feed: '/widgets/data/agenda.ical',
    cities: '/widgets/data/cities.json'
    }
    }

  • Widgets - Focused on configuring a widget, so would require name, id, template, and optional data, update, and actions. Things like icons and backgrounds should live under data. The Adaptive Card example could then be re-written as:

    {
    name: 'My Adaptive Card',
    id: 'my-adaptive-card',
    template: 'ms-acn',
    data: {
    prefer: "medium",
    small: '/widgets/data/agenda-acn-small.json',
    medium: '/widgets/data/agenda-acn-medium.json',
    large: '/widgets/data/agenda-acn-large.json'
    }
    }

[aarongustafson]

Thanks for this @Snugug!

I'm having a little trouble understanding exactly what this is for based on the descriptions here. Would this allow an installed PWA to offer like and Android or iOS homescreen widget? A Mac sidebar widget? A Windows gadget? The Adaptive Card system mentioned at the end seems like a specific usecase, but one I'm not super familiar with (and I'd imagine others may not be). More concrete examples up-front, maybe with low-res wireframes, would help contextualize this a bit more IMO.

Fair point. I had some explainer text over on this thread in WICG but have not brought it back over to this yet. I’ll update accordingly.

update feels like maybe it should be something like keywords for frequency instead of seconds? I'm a bit torn here, but saying I want this to update every 900 seconds and then having the definition of update be "thanks for your request, we'll get to it when we see fit" feels worse to me than more vague keywords.

That’s totally fair. Are you thinking something that is somewhat time-based like "hourly" or totally vague like "often" and "very often"? I also wonder if there should be a "user configurable" option with an initial preference.

While both "widgets", I actually think that host-provided widgets and user-defined widgets should be entirely separate entities. A host-provided widget, to me, is conceptually a host-provided component, like in a style guide, that has properties and needs specific to that component.

I agree to some degree, but also think it becomes super redundant to create multiple bespoke widget definitions for each independent platform. My hope is to create an upgrade path from templated widget to rich widget (should the developer so desire) but also platform enable customization through the inherent extensibility of the Manifest. That way you have a widget that progressively enhances into whatever container.

FWIW, I have an analogous idea of providing a feeds or data array in the Manifest to enable a web app to become a provider of that data within the host OS. Examples include calendars, contacts, weather, etc. I’ll likely noodle on that separately.

Why use tag instead of id given that tag is defined as client.id? tag isn't clear to me on first glance as the ID for the widget.

Totally fair point. I was planning on id initially, but then was thinking about it in relation to Notifications where tag is the key for some reason. I prefer id to be honest as I find the Notification tag confusing too.

Is it widget (as in sample) or template (as in Templated Widgets) to define what widget template to use?

That was my typo. I originally had it as widget and then changed it to template in the sample JSON file. I just missed that instance.

[aarongustafson]

The "feeds" concept is in the sample manifest file (lines 92-103).

[aarongustafson]

@Snugug I just made a ton of additions to the proposal to (hopefully) clarify things a bit more. Would love your thoughts.

[Snugug]

Thanks for the ping! Here are my thoughts on this new read.

• I think the install/uninstall story needs some work; if a host isn't required to show management for these widgets, I'm concerned malicious developers could only provide the install functionality and not the uninstall
• Seeing the sample widget definition, I'm confused by the rich widget and templated widget properties being rolled into one. I think my previous comment still stands; I'd prefer separate objects to define reusable widget templates and configure template instances. The configured instances are then just all "templated widgets" with the template property either being configured to a custom defined widget or a host widget.
• For rich widgets, say a stock ticker widget, how would new data be retrieved if it needed to come from a 3rd party source? Would a fetch request to an off-origin site that doesn't go through a SW just fail? Would a network passthrough for the SW be sufficient? Do developers need to create pseudo API endpoints that only live in their SW to handle these? What about cross-origin media, like CDN'd images, or CSS, or JS?
• showWidget - the data property feels redundant as it's a requirement for templated widgets and seemingly irrelevant for rich widgets?
• showWidget seems to be really heavy on boilerplate. Why do I need to pass in widget if I'm already passing in tag? Can't it look up the widget info from the manifest then? Same for data; this doesn't feel like it'd work cleanly for rich widgets and for templated widgets, why doesn't the host just fetch with the data attribute already present? This also makes the resume functionality feel extra boilerplate-ie to me.
• I'm still not super clear how a displayed widget would change what's displayed to the user based on an action; for instance, if I were to include a create-event action like is in the example, how would I swap from a calendar display to an input form?
• I notice feeds in the manifest file but it's not mentioned in the draft.

Overall, I generally like this new direction. I think I'd really like to see an example of a rich widget (how do MPA transitions work, or does it need to be an SPA? How can I reuse the same rich widget definition multiple times?) and there are still a few things not connecting for me w/r/t data and actions, but the rest of the lifecycle stuff, and the intent, is all much clearer now.