First Draft: Please review Product Roadmap

[LadyNaggaga]

Please take a moment to review the Try .NET product roadmap.

Note: This is only a product roadmap and it only focuses on the Try .NET themes and high level features. I am still working on the technical roadmap that will further broken down our engineering goals, timelines and operations.

Request for feedback

• @shanselman @jongalloway @csharpfritz - Please let us know if you have any suggestions or feedback.

• @rowanmiller ,@BillWagner and @mairaw - Can you please review the roadmap from a content developer standpoint? It would be great to hear your feedback and suggestions on some of the product features.

• @TheRealPiotrP @jonsequitur @rchande @colombod @TyOverby - Please review the docs and please make a pull request if you would like to change or add anything.

Suggestions welcome - Please fork the wiki and submit a PR.

[rowanmiller]

From a developer perspective, the main pain point I have at the moment is the security that only allows request from certain domains. This is painful for local development, as we have to edit hosts file, change to use something other than localhost for the local URL etc.

From an end user perspective, here are the main things I'd like to see:

• Mobile support
• Cross-browser improvements (we regressed on our browser support when we moved the .NET In-Browser Tutorial to Try.NET)
• "Loading" screen - sometimes the UI takes a few seconds to be ready, which is the period during which a user is building a mental map of what is on a page. If there was some kind of "We're getting your editor ready" message, this would help folks parse the pages we use Try.NET on.
• Save to GitHub - for the Playpen experience we are working on, it would be great for users to be able to save things to GitHub.

I think it would also be good to have an item around standing up some form of web presence for Try.NET. As it becomes more of a thing, we'll want to take users to a pretty page that tells the Try.NET story. This will also mean sorting out the split between infrastructure and customer facing content.

[rowanmiller]

BTW for the security thing, my ideal solution would be some form of "free quota" that allows a small number of requests from a certain location. When I'm working on this content, I probably send a couple of hundred requests a day at most.

[LadyNaggaga]

@rowanmiller this is all very good feedback and a lot of the features you have mentioned are inline with the current product roadmap.

• I had missed the "loading" screen in my initial draft but will add it under a friction-free exploration. Since a slow load time does make for a very bad user experience.

• I was going to add this "From a developer perspective, the main pain point I have at the moment is the security that only allows request from certain domains. This is painful for local development, as we have to edit hosts file, change to use something other than localhost for the local URL etc." in the technical roadmap so, thank you for bringing this up.

[csharpfritz]

I think we need to trim out the chrome around the editor experience on the website when it is not embedded on another site. A menubar, help pages, and configuration links would go a long way to making the application more usable

[jongalloway]

Storage: What about HTML5 Local Storage?
Should a Blazor-based experience be listed on the roadmap?
It would be nice to include better editing support - Monaco or similar.

I made a few minor tweaks - punctuation, one spelling error.

[LadyNaggaga]

@jongalloway these are both great discussion points for the Technical Roadmap
Storage: Just reading up HTML5 Local storage and it has some really advantages. Web Storage API is worth exploring.
Blazor is definitely on top of our radar for the Try .NET experience. cc'd @jonsequitur

[rowanmiller]

We use local storage in the In-Browser Tutorial to keep the users code at each step of the tutorial. That way if they close the browser and come back later, or go back to a previous step, we have the code the way they last left it.

[timheuer]

As mentioned in a call with @LadyNaggaga I really think that NuGet/library support needs to be strongly considered for roadmap. The examples that I see primarily being shown for Try .NET are not in line with what I think people really are wanting to try, which are beyond Console.WriteLine kind of things. Think about a learner's journey and how they really are likely going to be googling a LOT. They will come across snippets that say "use JSON.NET" as an example.

I know for some learning platforms we may be able to pre-provision a set of packages/libs in an environment maybe, but we should consider some type of aspect that allows for use of libs/NuGet in the Try experience. It will be more authentic to what they will see in other learning C# content online to support that.

[BillWagner]

I love a lot of what's in the proposal:

• The multiple file support is a big win for teaching new developers. It's the first bridge beyond the very simple "Hello world" style tasks.
• The save my work, and download and work locally are also huge steps in creating learning materials.

From a curriculum / learning standpoint, I'd like to see these considered (from most useful to more edge scenarios):

• An output display for expression evaluation: Any of our samples use Console.WriteLine to display output. It would be great to have small snippets that run code to perform a calculation, and have the final value displayed in output. (Similar to what F# interactive does).
• Add support for other assemblies (likely as NuGet packages, as @timheuer suggests above)
• Move more toward "full" C# as opposed to the C# interactive syntax. The interactive is great early in learning, but gets limiting as soon as we're teaching larger building blocks.
• Select language version. I think this will get important soon to let developers try nullable reference types in preview mode. Being able to select "C# 7.0" and "C# 8.0" and see the difference will be a great experience to learn.
• Support for unsafe context: The unmanaged generic constraints needs an unsafe context for most interesting examples. So does constructing a Span<T> from a fixed array.

[svick]

@BillWagner

Move more toward "full" C# as opposed to the C# interactive syntax. The interactive is great early in learning, but gets limiting as soon as we're teaching larger building blocks.

Isn't that already supported? When I go to try.dot.net, the example code that shows up has a normal static void Main() inside a Program class. You can omit all that and it still works, but it's an option if you want it.

Though the one thing that doesn't seem to work is declaring namespaces ("error CS7021: Cannot declare namespace in script code").

[BillWagner]

@svick:

Isn't that already supported?

As you say, mostly. I want to declare namespaces. I avoid using the #r syntax because I have to explain it, and explain that it doesn't work when you're working locally. We've had progress, but we're not where I want to see us yet.

[jonsequitur]

@BillWagner, @timheuer, and @svick, full C# and support for NuGet packages are implemented.

The default console experience gives you control of all of the code for your program, and includes a reference to Newtonsoft.Json. Namespaces will also work. https://try.dot.net/?workspaceType=console

In order to still allow the "code snippet" experience we also have Gist support where we only display and allow editing of a specified region, but the program can include multiple files: https://try.dot.net/?workspaceType=nodatime.api&fromGist=8e2ea50af097df663d9c8e19eb8fbf0a&bufferId=TryNodaTime.cs@fragment&canShowGithubPanel=true

A limitation of the current NuGet package experience is that we pre-provision specific packages. Content authors and end users can't currently add their own packages.

Edit: Since it's probably not clear, the querystring parameters in these examples work identically in the embeded iframe's src attribute.

[timheuer]

@jonsequitur I'm not talking about pre-provision with specific packages...I want to be able to use Alexa.NET library as an example...I can't unless you pre-provision for me.

[LadyNaggaga]

@timheuer for the scenarios we are targeting right now pre-provisioned environments are best user experience. On the fly NuGet packages calls that is a little out of scope for now :) . The goal is to have the required ones warmed up for the customer.