Support control templates

[stefanolson]

This may not make version 1, but one of the beauties of WPF xaml is that you can reskin any control. I think it's important that this is possible with the xaml standard. But there may need to be additional options on the control template so you might need the capability to define a different control template for each platform for example, e.g:

[monkeynoises]

(this was mentioned in the channel9 inbetween show interviews) I hate to rain on everyones parade, but this is not about doing a new "runtime" or even doing new functionality in the "target" platform....there will be no new or special "controls" created for Android or iOS....this is purely a "renaming" exercise of the Xamarin Forms.....to bring UWP and that closer together...so its possible to use 1 XAML...instead of multiple variations....so whatever XAML is used has to map to existing native controls.

[stefanolson]

@monkeynoises I would hope that as has happened with .net core, that what people are looking for will drive the development of the xamarin forms platform. Unless it has functionality like this it's really not going to be particularly practical for the kind of development that most xaml developers need to do. I don't think I've developed a single xaml app that used only the very basic controls referenced in the current v1 standard. Thanks for the reference to the video - I haven't got around to watching that one yet. Will go watch it now

[monkeynoises]

It's this video: https://channel9.msdn.com/Events/Build/2017/C9L10

Personally, I think there are 2 viewpoints in how to handle different platforms:

1) Provide an experience which is as close/follows the native platforms look/feel/behaviour

2) Provide a "common behaviour"/look feel across platforms - this is what "Silverlight" was trying to achieve...and it had to do this via a plugin.

The people that argue about following 1).....argue that people "expect" things to behave like the native platform. Yes, this is "true" for people that reside purely in that ecosystem e.g. they are an all "apple" follower.....or an all "android" person.....and wouldn't appreciate being forced to use "Windows" paradigms.

However, they are discounting people that own multiple platforms which are different (lets say I own Windows 10, an Android Phone, iPad, MacBook, and say a Linux tablet...which just has a Browser). I would hope and expect the "app" to be useable on all those platforms in the exact same way.....as I don't have a preference for any one platform....also I might still be very unfamiliar with certain native platforms (i.e. don't use it that much).

In certain circumstances, when using an "app".....users want its behaviour/look to be the same no matter which device/platform they use it on. Why?....Because they will be "learning" functionality, and behaviour of the app, and will be building up muscle memory etc. If the app behaves slightly differently on different platforms due to the native differences....this can be jarring. If you were playing a game on Android (lets say Minecraft)....and then the next week you were somewhere else borrowing a friends iPad to play it.....you wouldn't appreciate having to "relearn" due to differences in how you interacted with it.....to you it's the same game, it should behave the same in all aspects. So, I should not have to "think" what device I am using it when using the app. Support and documentation is also helped when things look/behave the same way - you don't have to describe it with different variations.

We know Silverlight is dead....but there is an opportunity here. This isn't about doing plugins again. What we "could" have is "apps" described in Standard XAML......but there is a codegen/common controls generated step for all platforms.....which provides a consistent experience.

The codegen would be so good, that you wouldn't be carrying a large payload around with your app...it would have just the absolutely minimum needed to provide the functionality being used in your app. As it's not a plugin, there is no issue with trying to submit them to other platforms stores.

There are 2 ways that the "consistent" look could be provided.

1) by doing the same "pixel" "rendering" using whatever native technology the platform provided e.g. Canvas, or OpenGL, etc.....an app would then be the interaction/display with that "surface".

2) by providing native controls that behaved/looked the same on each platform....and then apps would be a composition of those controls.

The "output" platforms would of course be:

• UWP
• Android
• iOS
• Browser HTML/JS

Yes, you can keep/provide the "mapping" style of codegen that Xamarain.Forms does right now.....but I propose we can get richer and more consistent functionality (as an option).....by going for the whole enchilada.

[bowencode]

Common look and feel across platforms has been done many times and for the most part fails, especially when it comes to consumer types apps that are the main focus of a cross platform mobile effort like this.

One of the big problems is that to define the common standard you either need to:

1. Define a new standard separate from the existing iOS/Android/Windows UI standards
2. Pick one of the existing platforms to use as the standard

In both of those cases you can end up with jarring differences between these new "standard" apps and platform specific ones and risk alienating users. For something like an enterprise app or large app like Photoshop that is being used for hours a day that might be fine, but for a consumer app it's a very poor experience.

Looking at users that do have multiple types of devices, they are probably not going to immediately install a new app across all of them and appreciate that it looks the same. They are going to start using it on their primary device on any of the platforms and be annoyed that it doesn't behave like the rest of the OS that they're currently using and maybe just stop using it right then before it even gets to their other devices.

I'm not saying it's impossible but it's essentially the problem of creating a new standard to unify all the other existing standards (each of which has their own merit). https://xkcd.com/927/

Specific to this proposal, having the default look and behavior of "XAML standard" controls conform to whatever platform they're running on provides that native experience, but including templating on all those standard controls would allow the unification of look and feel across all the platforms if that works better for your app. Without templates it's one or the other.

[Mike-E-angelo]

Meh. Why not both? I have never been a fan of adhering to a platform's expected (or conditioned 😉) UX. Great UX is great UX... why limit/impose/constrain creativity? The same people who whine and complain about a UX not being "iOS" or "Droid" interestingly enough turn right around and visit a web page, voicing no dissent that it operates nothing like a "native" experience.

That "web page" is actually an application, btw. ;) Platform-specific UX is really a fad that will expire in the next 10 years anyways (see: great UX is great UX).

In any case, any great theme/control system will allow you to apply themes and skins to any control graph. I would love to apply Droid semantics/experience to an iOS app and vice versa. This approach/mindset is possible in WPF. If only it were cross-platform. 😛

[monkeynoises]

If I drive a car, I expect and want the indicator to feel the same, operate the same, and the way I turn on the lights, and the way it "drives" to be the same no matter what manufacturer it is. Ok, a car is maybe a bad example, as you usually only have one...and get "used to it". However, for someone that constantly drives different cars, for whatever reason (whether that is forced on them by their employer, or because of temporary use).....the "option" of a consistent experience.....avoids a) relearning, and b) alienness. It's bad enough that some cars show their "speed" indication in slightly different ways......for example....some shop the MPH as 10 30 50 divisions...and you have to "mentally" fill in the value on the inbetween indicators.....while others will do so at 10 20 30 increments.

(An even better example of where the interfaces are quite different...but you would want them to look and operate the same...is self-service checkouts. I'm sure you can remember how "stressful" it was when using them for the first time, and "learning" them....then you go to another supermarket....and it's completely different. Even after learning each one....you just don't quite use them as efficiently as they could be).

(Actually.....an even better example.....the latest and greatest triple-AAA game title.....you wouldn't want the HUD display, or the way different indicators are provided to you, or to have to press/swipe things in a different order....just because the "game" is on a different platform/system, would you?......You wouldn't be able to build up "total" experience in that environment....due to "differences")

In a world of different devices.....and where their proliferation is growing...and our use of multiple ones more likely.......but using different UI "languages"....why should I have to know every one....with each having their own subtle differences ? It's a bit like languages...the one you are born into, and grow up with...that;s the one most natural to you. You never really become comfortable fully in your "second" and "third" languages.

Sometimes you are in a consumer environment at home, sometimes you are at work in an Enterprise environment. Enterprises usually care about consistency, and usually have to provide support, and want things to work in an efficient manner. Having to support 3 different ways to do things...just because platforms decided to do it different ways...is a cost to business. Consumers....well they don't care....or they just have to adapt, as they have no choice/influence.

And yes, I might have the same app on more than one device....I might have an iPad that I keep at home....I might have a cheat Android phone that I take out.....I might have an incar system for media, etc.....and then I might have a word device, which is different too.

So I am just opening to debate, that there is no technical reason why one has to follow the native look....there's an equal argument to provide a consistent feel as an option.

Another thing...what if god forbid...one of the platforms "dies".....or alternatively, it's paradigms are completely changed.

Xamarin.Forms aren't "themeable" are they (yeh, you can change "certain" colours and properties through a "style"....but you can't create an entirely different look or derivative control....with a controltemplate) ?....unless I stand to be corrected - the controls don't follow the "lookless" behaviour....because they are native underneath.

What's more you are limited by whatever the "native" OS designers decide to include in the platform. If they don't care to innovate in any area, then nothing evolved.....or as bad...if one platform innovates, but the others don;t.....you can't use that innovation....because your "standard Xaml" can't map to anything on the other platforms.

[bowencode]

For those of you arguing for standard UI on all platforms: are you in agreement with this proposal to include templating in the standard to allow single custom UI definition across all implementing platforms? To be clear - I am totally for it.

To many of the other points raised, I agree with some, disagree with others, but think some should be going into separate proposals to be evaluated, i.e. "Create standard default UI across all platforms"

[stefanolson]

@bowencode My feeling is that it should be optional to use a single UI definition for the default controls. And I think you should be able to theme each control for each of the different platforms if you want them to look different. But most of the apps that I would be thinking of building for the both Xamarin and UWP I would want to look exactly the same on all platforms.

[birbilis]

If controls were themable, you could use XX platform (or other custom) theme on them and if the templating system detects you're running on the XX platform indeed, it could use native renderers if they're supported (say Xamarin.Forms). But that should be more of an optimization. Thing is how the system would detect that you're not talking to the internals of those controls at some descendent etc. They'd look as opaque subtrees in a UI graph at runtime

[stefanolson]

@bowencode To expand on what I was saying, to avoid too much extra coding, you don't really want someone to have to include pages and pages of xaml code to redefine all the controls to their single UI definition so there might need to be some sort of a setting on the app.xaml for that (Which, as you say is probably a different proposal).

To get back to this proposal I would propose something like this for control templates: <ControlTemplate TargetType="MyClass" x:Os="iOs,Xamarin">

To be a true xaml standard it would have to support control templates at some stage because that is one of the most brilliant things about xaml.

[monkeynoises]

@stefanolson, I agree it should be optional...this isn't about forcing one way....it's about catering to 2 different audiences...namely consumer and enterprise. For too long I think Enterprise has been neglected. Look at how rich Enterprise apps could be done with Winforms or WPF. Due to the big swing to "consumer"...we got UWP, but it had so many gaps in functionality....it made Enterprise more challenging. Heck we are only just starting to get Entity Framework type DB stuff back in NET Core.....we've also been waiting a long time for other Enterprise functionality. Serious Enterprise is kinda still limited to WIN32, WinForms or WPF at the moment....or you have to dump "native" and go all-in-on-web...with the model while having some benefits....has compromises. We have the Desktop Bridge to allow deployment of those apps based on the "old" UI stacks.....and now we can embed UWP functionality.......however, it is still challenging to do greenfield UWP......and greenfield NETCORE is even more challenging....as we only have Xamarin Forms.

@stefanolson ....re: control templates.....yep one of the biggest challenges was having to redo/copy a template, and then redo/modify it all. There is no "inheritence"/recomposition.....that's what could enable maintaining and reusing templates in a better way. Look, at how when a new edition of Windows came out.....your older WPF app, didn't have those "themes" available.....so reverted to the the "base" theme of WPF - themes should be a more "dynamic"/have a downloadable/shareable aspect.

a) this would enable innovation of themes (e.g. a "store") b) themes could be chooseable by the user.....for instance they might want a theme that displays "just text" for accessibility reasons, or high-contrast, etc....but it is their choice what to use....and is best for them...not the "platform" or a "designer"

[Mike-E-angelo]

<ControlTemplate TargetType="MyClass" x:Os="iOs,Xamarin">

I appreciate the approach here, but you do not want to couple platforms to resources. This is one of the many failings of Xamarin.Forms (and don't get me wrong either, I appreciate its effort/approach). This would take a little more sophisticated strategy.

[stefanolson]

@Mike-EEE Open to ideas :-)

[Mike-E-angelo]

Oh that's easy, @stefanolson. Just ask yourself: "What would the WPF Team do?" 😄 👼

[monkeynoises]

@Mike-EEE.....Does that team even exist anymore?....Look at the WPF Team Blog....there was interesting talk of local WPF, etc......but then confusingly there has been no activity since Oct 2015 . What they need is someone like Scott Hanselman (the equivalent of) to drive things forward. And look how fast they moved when Scott Guthrie was driving Silverlight....till he moved to Azure...and then that moved fast. I'm probably not paying attention closely enough or it's too early days - but can you really identify the one person that is championing a cohesive XAML story? I'm hoping we get someone with the same gravitas, that has the power to make the changes required.

Ok, we can't change history, but we can learn from it, and what others of done....Instead of coming up with UWP, which rewrote (but not all) what had already been done before, but with nuanced differences.....and forced reliance on native OS support underneath to be provided...they could have followed what happened with ASP.NET CORE....i.e. refactor, dependency injection, nuget packages, native compilation....and being more Agile. Just rip out the dependencies on Windows specific tech (e.g. DirectX9), provide alternatives/workarounds/new concepts that work cross platform/on different target bases (e.g. Canvas, OpenGL, etc).

Heck, I'd argue it's still possible to do that......needs courage.

The reason I am passionate about Microsoft, etc, coming up with a powerful and consistent solution in the XAML domain, is that I don't want my current knowledge to go to waste.....and I want to see it grow into a large ecosystem....so I can find resources that get the job done and faster - the frequent churn in flavours and the varying levels of committment/support to each one has been difficult to watch. I do not wish to go into the spaghetti quagmire that web entails, with all its JS frameworks and flavours of the month...and duplication in efforts.

[Mike-E-angelo]

Does that team even exist anymore?

I think you're looking at it here on this repo, @monkeynoises. 😎 Although what I said was (mostly) in jest, it's great to see the activity and conversations emerging from this resource. Finding a single source of authority to drive this sucker would indeed take political will from inside MSFT, which as you have noted hasn't happened since Silverlight. And, as you (and others on here) have deftly noted, its replacement falls embarrassingly short (seriously, it's been 6 years now and look what they are providing -- they are still trying to figure what a markup extension is!).

So it's a community effort, I am afraid. Brave new world. But I would say we're already off to a good start with the likes of Avalonia and with this hub. Anything but UWP. ;) (Guess I should have asked: "What would UWP not do?" 😆)

[insinfo]

@stefanolson I support and agree with you, about "control templates". I think the purpose here is to define a specification, whether Microsoft or whoever is able to implement this specification the way you want it as long as it follows the requirements of the specification, causing it to be compatible with the platforms that will implement this standard. In other words, we can and should suggest presentation user controls, parameters, properties, symbol names, syntax, compatibility with other standards, incorporation features, theme style definition features and user controls model, among other things XAML.

[admin (crutkas) removed link spam]

[dotMorten]

@insinfo Please stop this cross posting and delete them. This is not a forum.. Keep each thread on topic related to the specific issue

[insinfo]

@dotMorten You're right, I'm sorry, I got carried away a little here.

[JustinXinLiu]

THIS!

Lacking of ControlTemplate support inside controls is the main reason that I have been avoiding Xamarin.Forms.

I would love to be able to create a unified design using XAML across all platforms, without the need of writing custom renders for each platform, otherwise it really defeats the purpose of using Xamarin.Forms in the first place.