Remaking the Roadmap - tell us your thoughts.

I realise getting more accurate "When" labels on things is hard - particularly the sections at the lower end of the page in the R&D section, but that would be appreciated, even if the labels are loose and prove later inaccurate.

The bigger issue I think is the page is too infrequently updated - right now the 2018.3 beta just came out, and we've got no insight into what'll be in 2019.1; presumably someone at Unity has already made a bunch of decisions there, and it would be nice to see 1-3 versions in advance of the current beta/release version.

 

Yeah - I absolutely understand slippage when things get rough stabilising; but at least for us, we don't tend to focus on a specific Unity version - more "What's coming in the next 3/6/9 months".

I would be absolutely fine with a "Tentative" label thrown over items which might be borderline (infact I think there is/was a colour coding for that already) - but it would be helpful to have, there's been several cases where we've implemented a complex feature, then Unity has re-implemented it internally 6 months later with no forewarning.

I realise there are other business requirements to this (e.g. having something to announce at Unite/GDC/etc), but the more we can know in advance, the better.

 

Just one further comment - depreciations are a much larger issue; we've had a couple spring up out of the blue; the following ones have all caused us serious pain (or are about to) in the past 2-3 months:

• Removing the old particlesystem [I admit I did expect this, but I also expected some kind of upgrader that didn't require loading it in an old version...]
• Removing internal substances support
• Removing support for Surface Shaders [in the SRP],
• etc.

Having a up to date depreciations roadmap would be equally useful if not more so.

 

I'd like the roadmap to be reversed. Have a list of features (categorised if they're too many, in say, graphics/scripting/workflow whatever) which will then say approximately what the target release is (with maybe some confidence level).

Then also have a traditional roadmap only for the next version, which I expect to be accurate (within reason). Like if 2019.1 is released, I would expect to have the full 2019.2 features in the roadmap.

 

Plotting how to take over the world. I like to see what is coming, and some things are worth shuffling our own roadmaps for. Why reinvent the wheel? That is why a decent and predictable roadmap is a very good thing.

Predictable is everything because nobody uses a map which directs you off a cliff. Come on, really? (joking). Please note that I do like the "at risk" etc that is also very useful as well. If something is at risk of slipping it is something that staff can buy some time with and people can see if it's amber, it's probably going to pop in a later version. If it's green it's great.

Since each roadmap is tied to a Unity version and packages are independent yet sometimes dependent on Unity versions, it would be best to just separate package roadmap from Unity version with the provision the package information indicates compatible with... <Unity versions>.

I regularly check package manager, and it's trivial to do so - one click of a docked tab. Pestering for something that is undesirable to change (chat to other Unity staff about this) is not a good idea at all. Packages are about specifically choosing to have an old or new behaviour - Unity staff were clear on this before, so some people will want to use an older package in the end, for some purposes. So nagging is not a good idea here.

I think it's great you're looking into a better roadmap. This is something that first should be designed around reliability because people will mob mentality at the slightest sign of "broken promises" - you know how people can be. It is particularly useful to me on the forums to direct people to the roadmap so having it reliable can quell most people's fears and arguments.

Do keep the "subject to change / R&D" stuff, it's nice and also interesting to see and discuss what Unity might be planning in the longer term.

 

1) I come to the roadmap site to see either progress of features I know to be in the works, or see what new features or updates are planned.

2) I'd like the detail to increase as plans become more firm. So no more detail of plans is needed than is known by Unity. I would accept that with any feature development, and any dictates coming down from product management, that plans and details can change at any moment.

3) I'd somehow put core Unity and packages in a completely separate section of the roadmap site, such as a separate tab for example.

4) I like the idea of notifications for status changes, such as something going from research to in development, or from in development to an actual Unity 20XX.x release. I'd prefer if the notification system could be tied into the forum here, either with the forum Alert system or sending a message to your forum inbox. Unity has been upping their emails lately to bordering on spam levels, so I'd prefer that the notification system not go to my email box.

Additional comments:
My biggest issue with the current roadmap site isn't even its structure, but with the provided information. More often than not the features I know to be in the works are not even mentioned in the roadmap site. For example, I know that a new networking API is currently in development for release around 2019.1. I know that because Unity has said so in public blog posts and in sticky threads in the Connected Games forum here. You will find no mention of this fact anywhere on the roadmap page though. So my impression of the current roadmap page is that it is not a reliable source of roadmap related information - random forum posts and Unity blogs for some reason are more reliable.

If the information on the roadmap is not kept relatively up to date, then no amount of additional features will do anything to improve it.

As a feature request, it would be nice to also get information in the roadmap when deprecated/obsolete features or API's are going to finally be removed from Unity. This would help with planning to replace them in games on a long dev cycle or supporting legacy games. Currently the best information for this is either forum or blog posts. You get console messages in the editor but these don't usually say when removal is planned. A deprecated API that is being removed within months will need an entirely different response from myself, as opposed to a deprecated API being removed in years or one with no planned removal date.

Back to the networking example again, Unity's legacy networking API was marked deprecated years ago but was only recently removed. The replacement for that API, Unet, is planned for removal on a far more aggressive timeline of 2019.1 according to forum and blog posts, even though it was only just deprecated a month ago. Developers not watching the forums or reading Unity blog posts likely don't even know yet this is happening and so quickly, and the roadmap currently says nothing about it. Users of 2018.2 are getting no notifications that the API has been deprecated (not sure about 2018.2.8). It would be helpful if the roadmap could provide this kind of information for major features being removed.

 

on the roadmap page itself
I click item it expands then if i want to copy and paste the text i can't because when i stop selecting
the frigging item is closed taking my selection with it.

tags in @awesomedata

 

just random comments (as the roadmap is not too important for me to follow, and current version is ok)

- if roadmap would be in github issues (or similar), easier to follow and get alerts, could see history and read comments from others (which might explain more than the actual roadmap text title, and even have links to more info about the topic, and could url link to specific feature) *and of course unity people shouldn't waste time on replying "when?" comments if commenting was available. *actually trello could work too

- feedback builds, didn't actually realize earlier that the toaster icon (without tooltips) is link to the build.. was about to ask for links to the builds..: /

- difficult to see what has changed since last visit to the page (rss feed shows updated date for changes, but not in the page)

- the roadmap page itself, that ~10 meters tall header image looks great for the first time visit, but its pretty annoying after that (i wanted to have a quick look at roadmap, not the banner image and then scrolling..)

 

I'm mainly checking the status of specific items and not really about a specific Unity version. The current layout is bad for that as I must check every group to find specific items and/or play with the filters for each item. This is even worse when trying to find items about new upcoming features that might have been recently added to the roadmap.

Every item should at least have a timestamp of the last change to it and possibly even have a label of the change type, ie. description or status change.

Each item should also a have a column for ETA which could be a specific Unity version or a quarterly estimate (ie. for packages), like 2018.3 or 2019 Q2. We need to know a rough estimate even if they will not hold up. Current in research or in development sections should not exists as you must already have some internal dates or limitations on how much time can be used on specific items. Split them to smaller milestone items if there is no clear ETA even at a yearly range.

If items are on hold or cancelled we need to know about it. Removing items or not having them on the roadmap at all makes the whole roadmap being incomplete and have less value.

I'd like to see them all since they are all features regardless how they are implemented or delivered. The items could have a type tag that could be used in filtering and sorting.

I think the asset store notification system works well and is very similar to what I would like to see. I get an email summary daily/weekly and in the editor store tab there is a bell icon that shows a list of recent notifications.

 

1. My primary reason for checking out the roadmap is to understand how Unity is progressing as a whole (preferably with detailed information on specific features being considered to be added natively to the engine.) Often, I want more detail than just "terrain system - research status" -- I would like to know the progress of the current research on that particular system, or whether that is currently on-hold (and why!) so I can plan for it in future (or current!) projects if I am able!
   
   
2. I would prefer you said more (at risk of things changing), but be clear about what things *might* change (as much as it is possible to predict). From my experience on the Asset Store, users are more understanding if you are up-front about the fact that you are unsure a feature is going to work the way you're trying to make it work. As long as you tell them this beforehand (and offer clear reasons why your uncertainty is founded), nobody is going to fault you -- even if it is a HUGE feature that everybody wants.
   
   
3. Tags are never that useful to me -- Instead, simple breadcrumb links (from the main roadmap!) to each package would often be helpful for "in-development" packages that are actively being worked on (preferably organized by their relevance to the engine -- i.e. Animation, Jobs, Design, 2d, Modeling, etc.) More specific details to these packages (and how to use them) would be great too, but simply telling us the current status of the package would be most valuable. This might work (visualization-wise) as an "endless" scrolling page with a slider up top. with incremental jump controls?)
   
   
4. Regarding Notifications -- I would think a simple icon beside the package name in the Editor would be enough to make me curious to check out changes. Often, I am not interested in seeing all the changes, but when I am, I'll open up the Package Manager and want to see what's new. Unfortunately I have to dig through all of the packages I have to see if it has an update. An icon would be useful, and I should be able to "Mark as Read" and "Mark all as Read" just as I do with email -- I may not care to update at the moment, but I do still want to watch a particular package or two. Their updates might be worth my time to integrate into my current project.
   
   To be clear -- I don't view an icon as "pestering" me (assuming it is not huge and obnoxiously-colored) as long as I can make them all go away at once, or individually as I prefer, in the package manager. Again, a simple "Clear All Notifications" and a "Clear Current Notification" right-click context-menu item (on each individual item) would be enough -- but a secondary button on the interface would be good for people with Laptops.

Hopefully this helps give you guys some direction!

 

I also wanted to add that I agree with almost all of what @hippocoder suggested, but the "nag" thing is a gray area for me due to the reasons I mention above and this statement below:

Is this "subscribe" or "opt-in" to a feature/package a method to gauge user-interest in a particular package so that packages that are being used more will stay more updated (and others that are used less are given less development resources?)

If so, I feel like this is a dangerous road to travel.

Some things cannot be parametrized.

Interest in a thing does not have anything to do with user-participation.

As @hippocoder suggested, we toggle our own roadmaps around features and implementations that will become useful to us in the near-term and plan for those which will be useful over the long-term (but we do not plan seriously, as we don't know if/when those features will ever be implemented.)

That being said, because of this lack of planning or implementation, we do not always get the chance to use or test a feature in its early days (and we are not likely to test it until it is fleshed out to a point where users are no longer reporting bugs openly). This is almost solely for the reason that we do not have plans to implement it -- our work/time/energy must be devoted to more relevant and concrete tasks at these particular moments, so we miss out on the usage of the new features these packages present.

However! -- We do still keep an eye on these packages in planning future projects, despite our lack of participation in testing them out. Many of these are valid ideas, and if their eventual implementation is not up-to-par, we either implement our own version of them, or find ways we can supplement them with our own required features/capabilities (when we decide to test them for usability.)

Another reason we maintain interest (despite not always participating or "opting-in" to use/update a feature) -- Sometimes you guys create packages that are timely for us. Even the barebones functionality is enough to get us going and accomplish what we're after to an extent that helps us out greatly. A good example is the SpriteShapes or Timeline features -- These are great bases to work from despite them not being feature complete. They were still very functional at the time we needed them to be, and as such, we could participate and test them out easily -- while also developing our project with them -- simultaneously. Yes, if they were bug-riddled, we would not have used them, but as with any feature, if we battle-tested it, and we know where it lacks and where it functions well, it's as good to use as any!

Again, @hippocoder is correct in the binary choice of "do I upgrade or not?" -- This is pretty much the question I ask, and why a little "unread" icon and right-click menu for each package item (to mark as read/seen) would be useful to me. If I can grab a few more details with a link to the individual "package roadmap" page (with a detailed outline of the current status and what features are on-hold [and why], at-risk [and why], or still planned in a package currently), it would be even more valuable.

 

1. My primary reason is to see if the version is worth updating to. For example, I am going to jump from 5.6 to 2018.3 for Ordered Mesh Emission (hopefully it will be stable by the time I get back to working on my game, currently writing some new lectures I will be delivering in the next few weeks, including one on Unity). A secondary reason is looking at what features are coming along. Could they be used to improve my game? Do they make other game ideas easier to implement, so rise up the list of which to do next?

2. It would be useful to include links to where to find out more information. It is not always clear what the feature does. An easy to understand description, maybe supported by images or video would help. There are often active discussions on the forums about the features, so a link to those also.

3. I think packages should get their own section, just as each release does.

4. It would be nice to get notifications. A forum alert would suit this.

Overall, I think the Roadmap is the thing that Unity needs to change least of all. The concept works, it just needs updating more regularly, and a bit more information included.

 

Both, viewing what's coming and knowing the state of a feature I'm looking forward to.

This question is kinda tricky, in software nothing can be 100% predictable. Even if we ask for "said less and be more accurate" we both knows that release dates are hard to keep. We are humans after all. But If I had to chose, said less and be more accurate, even If I'm convinced it won't be the case, make me change my mind on this.

For this to work properly, all Unity modules requires to be very modular, if some modules depends on other modules, there will be issues and users will get confuse which package needs to be downloaded and which one is compatible with others. Otherwise I will opt for them to be separate in two tabs, core and optional packages. And they should be separated by sections (eg: Animation, Terrain, Networking, GUI, etc).

Through package manager. Basic idea: make the package manager optionally pop when the Editor opens to show the new package updates (similar when there's a new Editor update). If no updates or the player opt to uncheck "notify me for new updates" then don't open the package manager automatically, let the user do it manually.

Final thoughts, I have no problem the way the Roadmap site is shown, only that it doesn't really reflect the state of upcoming features or things Unity plans to bring to the table. More detail, some of the roadmap features looks more like a Todo note than a roadmap feature. If we plans to invest future projects in Unity, we want to know what Unity is working on and what's coming to make wiser decisions about our projects. A good example of this, Unity is working integrating DXR, there's not a single note of it in the Roadmap. There's others things too such as when features get out of preview or experimental state. Graphics Jobs, Multithreading rendering, etc have been for so long in such state. What up with that?
Lastly, why not link the roadmap site with the package manager so they both share the same accurate info?

 

Honestly, I am using roadmap RSS instead of web-version. Because RSS shows the updates and changes in chronological order.

1. To view what's coming and what's changed.
2. More, with risks. Better for a feedback.
3. Packages can have it's own sub-roadmap, why not?
4. Will be good to automatize the process and make a weekly reports. What was changed/added/removed.

 

Happy to visit the roadmap - though would like some sort of ping when it changes - maybe like the forum notification bar that appears when something is happening. As I stay logged into the forum 24/7.

1. I want to check up on things that matter to me. See the progress of specific things, and see roughly when they're likely to appear.
2. Tell us more, even have a forum dedicated to roadmap entries, so we can interact with you through the design stage and ensure what's being produced matches with what people are wanting.
3. Packages and Core have have forums. Let's get together, chat, and move forward.Every roadmap entry could link to it's forum. Much quicker for devs to keep updated and brings dev closer to the users. The framework already exists.
4. If there's a Roadmap forum, with subforums for each package or core, we can subscribe/watch as normal.

 

Well we need absolutely straight lines or its 100% unusable.

 

Just wanted to point out my latest post in the (heavily-edited) Timeline Events thread is very relevant to this "Roadmap" discussion thread. To sum it up -- I think the wrong questions are being asked in this thread.

@willgoldstone, I feel like the real question isn't about "improving the roadmap" -- but rather "improving user-awareness of what is important to Unity on a development front". Unfortunately passing the responsibility to (initially) answer this question to the users is detrimental in truly answering this question. -- In addition to that, focusing solely on an "improved roadmap" as an assumed "solution" to the problem is a dangerous assumption.

Not beating up on Unity Team this time, but I've been thinking about this a lot, and I am now convinced that something slightly more should be done (in addition to) an improved Roadmap.

For example, the animosity felt toward Unity Team (exemplified by the original version of the Timeline Events thread) has almost always been due (in part) to vague explanations and unclear insights to the general public about Unity's overall (and current) goals with most in-development features. Even now, despite how long the Timeline Events thread has been active, there are still questions (at every turn!) about their overall goal or specific use-case or functionality -- In the end, most users just wait and pray for the features to be "good" or even just "usable" (or develop their own solutions because they don't trust Unity with their technical goals and refuse to wait only to be disappointed.) This, sadly, is how it goes for many users.

Lately, Unity Team has done an excellent job revamping Unity and trying to bring it into the modern world, and you guys probably don't have a clue how grateful some users are to you -- including the naysayers!
That said, I think the major point with the Roadmap should be less "this is what's coming" and more "this is what technical feats you should expect to be freed from with what's coming (as well as what technical obstacles we both could face during -- and after -- this venture)" -- and it is this latter part that makes people drool about (and be able to plan for) what's next.