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)
• [x] 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.

[timheuer]

I'll challenge that thought a bit in that it is counter to the statement on 'Simple to Embed' -- for me, as the owner of Alexa.NET I want to embed a Try .NET experience into my documentation. Will I be able to identify what packages to pre-provision? or will I be limited to what is provisioned based on what MSFT wants. If the latter, then it is no longer simple to embed for 3rd parties to put in their documentation/learning.

[LadyNaggaga]

@timheuer yes as the owner of Alexa.NET you will be able to identify the packages to pre-vision. NodaTime is an example of us doing that.
Question: are you describing more of the NodaTime experience or packages on the fly?

[timheuer]

@LadyNaggaga - yeah packages on the fly. I'd love to see the NodaTime experience (read: how does someone on board), but I wonder from a resource standpoint does it make a diff to have 'reserved' pre-provision environments? Dunno, just thinking aloud. But if the onboarding experience is simple, maybe I'm satisfied.

[jonsequitur]

@timheuer We want to make sure that the onboarding experience is easy and we're just at the beginning of figuring out what that entails. At the moment, pre-provisioning is necessary for performance reasons and it's a manual process, which clearly doesn't scale. When we solve the performance problem, then a self-serve bring-your-own-package capability becomes feasible, and we need to make sure we design that in a way where the embed code still works as the service changes over time. We're planning to get there.

[shanselman]

FWIW I like the #r syntax. It's built-in/part of Roslyn and it takes 15 seconds to learn.

[LadyNaggaga]

@shanselman #r is specific to scripting. See @BillWagner comment.

[shanselman]

I get that, but does that preclude us using it?

[kendrahavens]

I'm sure this won't be top priority, but I'd love to have an easy experience for writing and running tests in the browser. Some challenges this brings would be:

1. How to initialize a test run in a browser?
2. Good test architecture implies having a separate test project and references which is difficult represent in a repl

[LadyNaggaga]

@shanselman we are using full C# not scripting. "On the fly" package request is definitely something we need to explore . However, I am not sure the #r would work incase since we are using full C# and not scripting.

Since the support for assemblies has become big part of this thread, I am moving to a new issue here.

[jonsequitur]

@kendrahavens We've talked some about a test scenario and would welcome some help designing it. Among the ideas that came up:

• For test samples, allow the run button to mean "run my tests".
• Allow tests to be hidden and the implementation editable to teach test-driven problem solving.
• Allow the tests to be visible and the implementation hidden to teach test-driven ways of exploring existing behaviors.

We would want a way to display test results that's a little more interesting than the current console output.

[kendrahavens]

@jonsequitur These sound like great options. I think having a TDD page would be very useful! I'll open an issue on a test section design for more discussion.

[LadyNaggaga]

Link to Unit Testing Scenario

[jskeet]

A few suggestions, mostly in the "simple to embed" area (as that's where I've had first-hand experience - thanks team!)

• For Noda Time, I wrote a horribly hacky bit of JavaScript for the various interactions with the server. None of this was complicated, or it wouldn't exist - my command of JavaScript is pretty dire. But it makes sense to avoid wheel reinvention: the Try.NET project could provide the JavaScript to make all of this work with very little effort on the part of the site developer wanting to embed Try.NET.
• Using Blazor potentially removes all of the security/provisioning/onboarding aspects, which would be wonderful.
• Using Blazor would also allow offline experimentation (on a plane!) and potentially be more responsive. Really looking forward to this.
• If the core of Try.NET becomes open source, with the "agent selection" part being still proprietary, that would give more freedom in terms of the security/provisioning/onboarding aspects. For example, suppose we wanted to provide our own agents with extra features to allow users to interact with Google Cloud APIs on the fly (within their own project) - if the core of Try.NET is open source, that would be achievable, I suspect. This could unblock a lot of enterprise uses.
• Another potential win from the open source version is the "host a server in a classroom/conference" scenario, which would be great for teachers in areas with limited internet capability, but a reasonable intranet. It could be really useful for conference workshops where dependencies might otherwise take a while for attendees to install.

[LadyNaggaga]

@jskeet this is great feedback thank you!
I have opened few issues to get into deeper into the conversation. Simple to Embed: JavaScript Support Experimenting with Blazor Add ability to write and run Tests OSS Journey[link coming soon] :)

[rowanmiller]

On the .NET website side we'd be very interested in the testing scenario too. For the .NET Playpen idea we're experimenting with, we want to include coding challenges. Having a proper unit test for pass/fail would be fantastic!

[BillWagner]

Another item that should be on the roadmap is to have the try.dot.net experience use the current culture from the user's browser. See discussion in dotnet/docs#5440