Windowstemplatestudio: multiple versions of a page versus page enhancement options?

[mrlacey]

As a rule, we focus on having pages with minimal functionality to aid the getting started scenario. "Here's something that works."
I've heard from people willing to contribute more advanced code (to do things like handle edge cases in video playback for some streaming scenarios.)
Having code like that would be useful to some but not all developers adding a, for example, video player page.
Should we push all information like this into documentation or consider having more than one version of a page. Named "XXX Page (Basic)" and "XXX Page (Advanced)" or similar.
Could also apply to #186 (extended web page functionality)

[jamesmcroft]

Rather than having multiple version of pages, we could adapt the way we add a page to include additional features for that page.

For example, select to add a new Map page. Then select additional options before confirming to add a feature to change the map style, support traffic, etc.

[crutkas]

I like @jamesmcroft idea, We have "pages" then "page enhancements" that could appear after the fact. If telem backs the statement of people always selecting the enhancements, we just roll those into the main page.

Would love to see what other people think here

[degant]

Page enhancements sounds like a better idea than multiple versions. Can the same be extended to features as well, like feature enhancements as a level 2 option after selecting a feature?

_e.g. When a user selects 'Toast Notification' in the wizard, he might then choose between a simple toast or much more advanced and interactive ones that allow text boxes, drop downs, reminders, audio etc._

[crutkas]

@degant a Notification can do all that already by default, it is just swapping out the XML. We'd point at the Notification Visualizer and let that do the heavy lifting for the XML.

[mrlacey]

Enhancements make me slightly nervous about how complicated they could end up making template authoring. Each option within an enhancement would need it's own configuration and would have to support composition with other enhancement options too. This is the M*N issue on steroids.

[mrlacey]

Note that if we do enhancements I expect the functionality to be equally available to features and pages.

[crutkas]

I think that is fair.

[jamesmcroft]

Agreed on this. @mrlacey on the complexity front, we may end up bloating out with multiple pages that nearly do the same functionality which may be confusing to a user. The enhancements would be designed to light up additional features within a page but yes, this could definitely become difficult for template authoring...

[crutkas]

What is an example of an enhancement that shouldn't be in the base?

[ralarcon]

We can consider the "enhancements" like parts being or not generated based on user input. As a basic example, think in the Map page: we can have a parameter which is the initial location. If the user in the UI provide it, then the code to setup this initial location will be generated...
From the generation perspective, the challenge here is to do not create an extremly complex staff to author the templates considering that we need to provide mechanisms to dinamically gather user inputs based on the template definitions.

I would say that the fist thing to do is to define some sample usage scenarios and then think about the requirements.

[mrlacey]

My understanding of the intention behind enhancements was more like this.
Consider the WebView.
The original version had comments about adding a loading indicator and error handling.
The newer version now implements these by default but these would be better served as an optional enhancement. If people want them they're there. If they don't they just don't tick the box and then there's nothing for them to remove.

Enhancements are the bridge between things that "most" people will want but not forcing them on everyone.
They enable adding simple extras to a page (or feature?), rather than having multiple versions of a page or including things that not everyone wants or needs.
They should not be a substitute for having some things that are left to the end developer to set or add. For instance, I wouldn't want the setting of the MapsServiceToken through a prompt in the wizard. A TODO comment in the code does this just as well without complicating the wizard process.

[mrlacey]

Closing this out as we've been working for a while on the assumption that we'll add some form of enhancement options.