You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@devoncarew working on this ticket implies the possibility of having multiple project templates. Is this something that your team can help with? Or, is there any particular reason why multiple project templates would be an issue?
CC @InMatrix were any investigations ever done into multiple templates? If not, can we chat a little bit about it? There are likely benefits across multiple use-cases. I know I had brought this up at some point when were in 1842, but then it got away from me as I focused more on Android APIs instead of tooling...
We need to be really really careful when designing extra templates. Our single existing template is a massive part of our first hour experience and anything that risks derailing new users from that experience is extremely dangerous in terms of our user adoption. Please make sure to loop me in on any design discussions and code reviews.
Mechanically, the IDEs need to be told about each additional template (we support app, package, and plugin) currently.
If the number grows too large, we'll have to change how we present them in the UI. One additional one won't cause issues. We'll just need to be aware, and perhaps do some version detection so we only offer it with versions of the framework that have those templates.
@devoncarew what about a new screen in the flow after you select the app template? I guess technically this isn't so much about project structure as it is about initial Dart source code. Maybe we could make it accessible via a subtle button that wouldn't distract new users?
Thanks @devoncarew. And as @Hixie said, we have to be very careful here not to distract from the first hour experience. So I'm wondering where we can take this from here?
Should we collect some data with @InMatrix and @jayoung-lee? Or should we propose a specific wizard UI that would allow for selecting other source code configs?
Since this conversation has happened multiple times over the last year, I think it would be good to get the ball moving in some direction. Thoughts?
My original thought was just to add a flutter create --ios or flutter create -t app-ios or some such that doesn't impact the onboarding flow.
For IDEs, since it's not an additional dimension (i.e. plugin/packages are already android+iOS), it'd just be another entry in the project type. It can either be Application/Cupertino Application or Application - Material/Application - Cupertino or something like that.
I know some devs write apps only for iOS. This request seems to assume no devs write only for Android. Is that true? I ask because my first thought was if we need a material-specific template, as well.
As we learned in recent research, developers who do use the Cupertino library still use Material widgets, since Cupertino provides a much more limited widget set than the Material library. Therefore, I don't think the original request "A flutter create template that doesn't import material" would provide practical value to users.
That said, making the default template visually more platform-neutral would help improve the perception of Flutter among iOS developers.
@InMatrix do you think we should be updating our app template to be more platform-neutral? I can see that being useful as we encompass more platforms. what are you thinking?of course, we should take into account the note from @Hixie above that cautions us to be careful here.
I think the template can use some styling tweaks to make it feels lighter and flatter to suit iOS aesthetics and replace the Floating Action Button with a regular button, since the FAB is more common on Android than on iOS or the Web. @willlarche had a mock along these lines.
There are definite optimizations we can make. Ian had concerns about
retaining the usefulness. If we're ready to do this, it's not an
inconsequential task but doable.
Activity
zoechi commentedon Feb 18, 2019
Related #15279, #14719, #13611
matthew-carroll commentedon Apr 9, 2019
CC @willlarche
@devoncarew working on this ticket implies the possibility of having multiple project templates. Is this something that your team can help with? Or, is there any particular reason why multiple project templates would be an issue?
willlarche commentedon Apr 10, 2019
I support multiple templates. But that should be spec'd out by needs and research. Has it? (I actually don't know.)
matthew-carroll commentedon Apr 10, 2019
CC @InMatrix were any investigations ever done into multiple templates? If not, can we chat a little bit about it? There are likely benefits across multiple use-cases. I know I had brought this up at some point when were in 1842, but then it got away from me as I focused more on Android APIs instead of tooling...
Hixie commentedon Apr 11, 2019
We need to be really really careful when designing extra templates. Our single existing template is a massive part of our first hour experience and anything that risks derailing new users from that experience is extremely dangerous in terms of our user adoption. Please make sure to loop me in on any design discussions and code reviews.
devoncarew commentedon Apr 11, 2019
Mechanically, the IDEs need to be told about each additional template (we support
app,package, andplugin) currently.If the number grows too large, we'll have to change how we present them in the UI. One additional one won't cause issues. We'll just need to be aware, and perhaps do some version detection so we only offer it with versions of the framework that have those templates.
matthew-carroll commentedon Apr 11, 2019
@Hixie - Will do.
@devoncarew what about a new screen in the flow after you select the app template? I guess technically this isn't so much about project structure as it is about initial Dart source code. Maybe we could make it accessible via a subtle button that wouldn't distract new users?
devoncarew commentedon Apr 11, 2019
We do have a bit of logic there that's template dependent - we'd want to update that as well for new templates.
Here's the UI for IntelliJ project creation:
And for Android studio project creation:
Note that in Android Studio, there is (frequently) and follow-on wizard page which is customized for the project type. cc @stevemessick for fyi
matthew-carroll commentedon Apr 11, 2019
Thanks @devoncarew. And as @Hixie said, we have to be very careful here not to distract from the first hour experience. So I'm wondering where we can take this from here?
Should we collect some data with @InMatrix and @jayoung-lee? Or should we propose a specific wizard UI that would allow for selecting other source code configs?
Since this conversation has happened multiple times over the last year, I think it would be good to get the ball moving in some direction. Thoughts?
xster commentedon Apr 11, 2019
My original thought was just to add a
flutter create --iosorflutter create -t app-iosor some such that doesn't impact the onboarding flow.For IDEs, since it's not an additional dimension (i.e. plugin/packages are already android+iOS), it'd just be another entry in the project type. It can either be Application/Cupertino Application or Application - Material/Application - Cupertino or something like that.
stevemessick commentedon Apr 11, 2019
I know some devs write apps only for iOS. This request seems to assume no devs write only for Android. Is that true? I ask because my first thought was if we need a material-specific template, as well.
2 remaining items
csells commentedon Jan 10, 2020
@xster we have a codelab that shows off the use of Cupertino with Flutter and it's the first thing that comes up when searching on google.com for "flutter cupertino app" -- do you have that sufficient?
InMatrix commentedon Jan 10, 2020
As we learned in recent research, developers who do use the Cupertino library still use Material widgets, since Cupertino provides a much more limited widget set than the Material library. Therefore, I don't think the original request "A flutter create template that doesn't import material" would provide practical value to users.
That said, making the default template visually more platform-neutral would help improve the perception of Flutter among iOS developers.
csells commentedon Jan 10, 2020
@InMatrix do you think we should be updating our app template to be more platform-neutral? I can see that being useful as we encompass more platforms. what are you thinking?of course, we should take into account the note from @Hixie above that cautions us to be careful here.
InMatrix commentedon Jan 10, 2020
I think the template can use some styling tweaks to make it feels lighter and flatter to suit iOS aesthetics and replace the Floating Action Button with a regular button, since the FAB is more common on Android than on iOS or the Web. @willlarche had a mock along these lines.
willlarche commentedon Jan 10, 2020