[steamer_ctn]

Hi Chris,

Thanks for the feedback.

cjakeman, on 13 June 2021 - 10:01 AM, said:

The v1.4 was indeed held up until Monogame was ported. I see that delay as an exception and we certainly want to release versions more frequently

Could v1.4 have been deployed without Monogame in a shorter time frame? I am sure that there would have been lots of other good features that were not dependent upon Monogame.

cjakeman, on 13 June 2021 - 10:01 AM, said:

For example, deferred rendering of graphics will be needed before we can deliver multiple light sources and ambient occlusion (and possibly realistic water too).

I agree that it would be good to show dependencies. Could we develop some form of feature "coding" that shows that one feature requires another before it can be developed. For example if we coded the first feature in your example "D1", we could then indicate that the other two features require "D1" before they can proceed (or some other similar scheme).

cjakeman, on 13 June 2021 - 10:08 AM, said:

I've left v1.5 at the top of the table and removed the others.

Thanks for taking on board some of the suggestions in the thread.

However I still have concerns that we are showing v1.5 on the roadmap before we have even released v1.4.

Do we have developers assigned to developing all the features indicated in v1.5? Have we sought EOIs from developers to take on all these features in the desired development time frame of 6 months (if we go to a 6 month release cycle)?

For example, we have indicated that three different editors will become available with the release of v1.5. How will we ensure that they will be definitely delivered as part of v1.5 and they don't become "vapourware"?

The current roadmap format still also implies that certain features from the different functionality columns will be released within the same version (time frame), even though it the version is un-numbered.

[roeter]

steamer_ctn, on 13 June 2021 - 03:14 PM, said:

I agree that it would be good to show dependencies. Could we develop some form of feature "coding" that shows that one feature requires another before it can be developed. For example if we coded the first feature in your example "D1", we could then indicate that the other two features require "D1" before they can proceed (or some other similar scheme).

Fully agree with Peter on this. The fact that these features are listed for different versions does not imply that there is a depedency. And the reverse is also true, i.e. the fact that a feature depends on another feature does not rule out that both features are introduced in the same version. For instance, introduction of the first step could be delayed because of some problem, but it could well be that this problem is not an obstacle to create the dependent features and these could be completed before the problem in the first step is properly cleared, thus allowing these dependent features to be released at the same time as the first step.

Also, I would suggest to remove the multiple "V ?" lines, and just set one line with "Future versions". Not only is it quite impossible to predict when a particular feature will become available, but there is also no link between the features in the four categories, and those listed now for the same version in one particular category might well be completed long before those listed for that same version in other categories.

One other point. Regarding the sequence of editors, I think that the route editor should have a much higher priority, and the timetable editor much lower. Creating a route without an editor is impossible, creating a timetable without a dedicated OR editor is almost standard practice.

Regards,
Rob Roeterdink

[steamer_ctn]

Some further thoughts.

I think that we also need to align the Trello site with the roadmap site on OR (as there is a link to it from the Roadmap). At the moment the Trello cards are grouped in version number categories, which will not align with the OR Roadmap discussion that we are having.

Could we resort the cards into the same broad categories that we might use in the Roadmap, ie "Desired", "Future", etc? And then further subsort it into different "Major Features (or Categories)" (see item i below).

I am also wondering whether we can add some additional scope to Trello, say as follows:

i) Group features together (perhaps by colour coding the Trello cards as sub features in a particular category using the same colours shown on the current Roadmap, eg Light Blue for for all Editor type Trello cards). We could possibly add some some additional categories to give some more detail. This approach may allow us to set the Web page up as an Executive summary and Roadmap navigation "portal", and allow Trello to act as the detailed description. (I notice that there already appears to be some level of category grouping applied to some of the Trello cards - perhaps these are the major categories that should be used in the Roadmap? But only have one category per card.)

ii) Would it be possible in Trello to show dependencies? For example I notice that some of the Cards have a "Progress" bar function. Could we set these up on a card, and where there is a dependency show this as the first step in the Progress bar (Perhaps a link as well, so users can find the dependencies quickly)? Or is there another feature in Trello that could be used to highlight dependencies?

[James Ross]

Genma Saotome, on 10 June 2021 - 11:20 PM, said:

Only thought that comes to mind is to ask about the availability of any Direct X standard not presently used. It might be implied in "Better looking water" but that is not mentioned in the trello card.

I expect it is too early to know if any of the graphical improvements would require using DirectX 10 or 11, but we'll certainly flag it up once it is known.

roeter, on 14 June 2021 - 01:10 AM, said:

Fully agree with Peter on this. The fact that these features are listed for different versions does not imply that there is a depedency. And the reverse is also true, i.e. the fact that a feature depends on another feature does not rule out that both features are introduced in the same version. For instance, introduction of the first step could be delayed because of some problem, but it could well be that this problem is not an obstacle to create the dependent features and these could be completed before the problem in the first step is properly cleared, thus allowing these dependent features to be released at the same time as the first step.

Also, I would suggest to remove the multiple "V ?" lines, and just set one line with "Future versions". Not only is it quite impossible to predict when a particular feature will become available, but there is also no link between the features in the four categories, and those listed now for the same version in one particular category might well be completed long before those listed for that same version in other categories.

It looks like the website is missing some key text, which is that the roadmap is completely aspirational. We are not trying to predict the future, only set goals.

roeter, on 14 June 2021 - 01:10 AM, said:

One other point. Regarding the sequence of editors, I think that the route editor should have a much higher priority, and the timetable editor much lower. Creating a route without an editor is impossible, creating a timetable without a dedicated OR editor is almost standard practice.

For the editors specifically, I tried to plan an order which allowed us to build up from simpler things (consists) to bigger things (terrain and routes). We've continually struggled with editors because nobody would take the first step, so I've tried to make the steps a bit smaller so we can actually make progress.

steamer_ctn, on 14 June 2021 - 02:39 AM, said:

I think that we also need to align the Trello site with the roadmap site on OR (as there is a link to it from the Roadmap). At the moment the Trello cards are grouped in version number categories, which will not align with the OR Roadmap discussion that we are having.

Could we resort the cards into the same broad categories that we might use in the Roadmap, ie "Desired", "Future", etc? And then further subsort it into different "Major Features (or Categories)" (see item i below).

The Trello board will be organised in a compatible manner once we've reached agreement about the roadmap labels.

steamer_ctn, on 14 June 2021 - 02:39 AM, said:

i) Group features together (perhaps by colour coding the Trello cards as sub features in a particular category using the same colours shown on the current Roadmap, eg Light Blue for for all Editor type Trello cards). We could possibly add some some additional categories to give some more detail. This approach may allow us to set the Web page up as an Executive summary and Roadmap navigation "portal", and allow Trello to act as the detailed description. (I notice that there already appears to be some level of category grouping applied to some of the Trello cards - perhaps these are the major categories that should be used in the Roadmap? But only have one category per card.)

Looks like adding a colour to cards is a new feature (as of June 2020), so this is certainly something we can explore. The exiting categories obviously pre-date this feature, so once we're done with the roadmap discussion we can resync the Trello board to match.

steamer_ctn, on 14 June 2021 - 02:39 AM, said:

ii) Would it be possible in Trello to show dependencies? For example I notice that some of the Cards have a "Progress" bar function. Could we set these up on a card, and where there is a dependency show this as the first step in the Progress bar (Perhaps a link as well, so users can find the dependencies quickly)? Or is there another feature in Trello that could be used to highlight dependencies?

I don't know of a particularly good way of showing dependencies on the roadmap or Trello board - ideally you'd use lines with arrows. Every option seems clunky and/or unclear. Even that power-up does not seem very clear - it took me a fair while to spot that the tiny icon and text on the cards was showing the dependency:

https://blog.trello.com/hs-fs/hubfs/HelloEpics-EventBoard2%20(1).jpg

In any case, the free Trello only allows 1 power-up, and we're already using the voting power-up, so we'd have to start paying at least $20/month to use the suggested feature. :(

[cjakeman]

roeter, on 14 June 2021 - 01:10 AM, said:

One other point. Regarding the sequence of editors, I think that the route editor should have a much higher priority, and the timetable editor much lower.

I agree with you that the Route Editor is needed more.

If I remember correctly, the thinking behind the sequence was that Editors are not easy to do well and the experience gained in building the simpler editors would pay off for the more challenging Route Editor.

[Genma Saotome]

cjakeman, on 14 June 2021 - 01:02 PM, said:

I agree with you that the Route Editor is needed more.

If I remember correctly, the thinking behind the sequence was that Editors are not easy to do well and the experience gained in building the simpler editors would pay off for the more challenging Route Editor.

May I suggest the route editor is not so hard as you fear as it is highly modular which lets you defer the difficult parts to later. IMO the most important thing to do first is the user interface -- PLEASE use a toolbar where the user selects a function (select, place, move, rotate, etc.) using either (or both) fly out or right mouse click sub menus. World editing is both highly mouse intensive as well as almost always focused on one spot (on the ground or on an object) which means efficiency comes from the least amount of mouse movement. IMO this makes the mouse right click the way to go, especially if the last line item is Toolbar with a sub menu of the main functions. With that in place all of the functions can be obtained w/o further movement leaving the route editor to move his mouse only when he needs to select an object the function will work upon (placed or in the avail;able list).

I believe you could develop and get route builder feedback solely on a UI prototype before dealing with file management and/or the more difficult terrain editing and in doing so allow your developers to be more comfortable w/ the task and who they work with for feedback.

Goku didn't write his editor in one fell swoop and while much of his functionality is quite good IMO he didn't give the UI enough thought up front.

[cjakeman]

James Ross, on 14 June 2021 - 11:39 AM, said:

Looks like adding a colour to cards is a new feature (as of June 2020), so this is certainly something we can explore. The existing categories obviously pre-date this feature, so once we're done with the roadmap discussion we can resync the Trello board to match.

I have coloured the Trello cards so that they now match the 4 tracks in the website overview.