Previous Release / Preview Threads Merged

  • Yes you say that about everything anyone mentions, can we actually get some "news" on the features that will make a huge difference to users.


    And again i totally agree with Herbo

    I'm aware that it's vague and doesn't provide news directly, but I can only bring such requests up again and most of the time it's about a functionality that has no release date yet so we try to not make any promises.


    I have briefly discussed this feature (batch rendering panoramas especially) internally now too and again, without being able to make definite promises, this is something we plan to provide in Enscape 3.2 (or in a preview beforehand for example). It will be added to our roadmap as well once the release date is secure.

  • Hey there,


    thanks for keeping up your voice about the visual settings, Herbo.

    Just to clarify it a bit more from our perspective:

    Some of us had the exact same concerns when defining with our UX department the changes for the relocation of functionality. In this case we had strong arguments for both sides. As we did not have enough information to be sure which option would be the better one for all of our users, we let the general UX guidelines decide.

    We already knew that it might be possible that it is the wrong decision and that we have to change our direction afterwards. But 'afterwards' in our situation means 'after 3.0'. Before we introduce further changes, we need to have more feedback from more users to base further decisions on a solid basement.

    So far we received mixed feedback that is not quite telling (and the forum is not our only source).

    This topic IS on our table and we are observing it. But we did not decide to change the current behavior, yet.

    Maybe we will introduce a preview with changed behavior in a few weeks. But maybe we won't.


    We will keep you up to date on this.


    Thanks again. All your feedback is much appreciated!

  • Demian Gutberlet Is there any chance that wording of reply's to certain features and request brought up on the forum be changed to be more specific without making promises?


    I.E. Batch panos


    Stereotypical response: Thank you for your up vote, I will forward it onto our developers and file it Into our feature request agenda. No ETA regarding when this will be implemented though.


    New response (or something similar): Thank you for your up vote. We are not looking to implementing batch panos in this upcoming release. It has been a highly requested item on the last few preview versions. Our developers are looking into implementing it on one of the next few stable releases. (if the feature has no chance at all in being added in the next 1-2 releases the reply should say "it is on our radar/agenda but not a priority on the next few upcoming releases").


    If you keep the response specific enough to let us know what is on your radar without directly saying what the development agenda is that could potentially reduce the amount of "flocking" that happens on popular feature requests.



    [Blocked Image: https://i.imgflip.com/4zff42.jpg]

  • I agree Tearch , we'll be focusing on that, but that is of course only possible if we have more information about a specific feature available. Still, if there is anything we can report when it comes to the actual status and time of implementation right away about any requested feature we most certainly will. :thumbup: Thanks for the feedback!

  • The new video editor timeline looks really great! The very first thing I tried to do was to slide the keyframes in the visual timeline, but it just brought up the settings. Is there any way you can make that visual timeline more interactive, basically like any other NLE software, where you can slide the keyframes left and right?

  • Tearch  Nuge I completely understand your wish to get more precise feedback on the feature requests and we will definitely try to improve it in the future but unfortunately it is not always easy. As you can imagine, we get a lot of feature requests via different channels not only the forum. And be assured , we collect and document all of them and of course we also note how strong the demand is for individual features. So if we say "Thanks for the upvote" or " It is heard" be assured we document it and are aware of every request.

    For our planning which features will come next, we carefully evaluate all requests. In addition, we keep a mix between planning ahead and still being able to react to urgent circumstances at relatively short notice. For this reason, we can not always say with certainty when exactly a specific feature will come. And that's the reason why we don't make any promises until the features are finally scheduled.


    Regarding the Batch Pano , at the moment I can only tell you it definitely won't come in Enscape 3.1


    I know, this is not the most satisfying answer but I hope it helps you to understand it a little bit and as said we'll try to improve it in the future.


    Thank you very much for all the great feedback !

  • Joachim


    I am curious about what other sources you use to make these decisions, I would have thought that feedback from your user base is one of the most important as we are the ones using your product in the real world everyday, Small decisions made by your UX team are having major implications to a number of users (Refer to Herbos comments) and this could have been resolved very early in the development process had you involved your user base. Previously you had a trello board which was a great feature but you decided to discontinue that in favour of "upvoting". As i have said many times on this forum as users we have no idea what MIGHT or MIGHT NOT be coming in future releases. Why don't you provide a list of items that have been upvoted with the corresponding number of votes, I am sure that most users would have expected more from a major release (3.0) than a UI update

  • Tobias


    Sorry but i take exception to your comment "In addition, we keep a mix between planning ahead and still being able to react to urgent circumstances at relatively short notice". I have been using Enscape for many years and i am yet to encounter any feature that has been reacted to "at relatively short notice". you just have to look at this forum to see how long user have been requesting batch rendering for Panos. if your team had to render 20-30 panos for a project i am sure it would have made it into enscape quite some time ago.


    All of the "feature requests" your users make are based on real world problems/bottlenecks that exist in our businesses everyday, some more problematic that others, as a product manager you should be acutely aware of these issues and be advocating strongly to your developers on our behalf. Let avoid another release cycle where the only change is an updated UI when so much more could have been done to enhance enscape as a usable product.

  • Tthe SketchUp issue with syncronized views seems to be fixed! thanks!


    Here to let you know that in the "Output" section, when "lock image ratio" is checked if I change the width in pixel the height won't change accordingly. I have to uncheck and check again. This is only a small misbehaviour, I think it can be rapidly fixed.

  • Nuge let me respond to your two comments in a little more detail

    Joachim


    I am curious about what other sources you use to make these decisions, I would have thought that feedback from your user base is one of the most important as we are the ones using your product in the real world everyday, Small decisions made by your UX team are having major implications to a number of users (Refer to Herbos comments) and this could have been resolved very early in the development process had you involved your user base. Previously you had a trello board which was a great feature but you decided to discontinue that in favour of "upvoting". As i have said many times on this forum as users we have no idea what MIGHT or MIGHT NOT be coming in future releases. Why don't you provide a list of items that have been upvoted with the corresponding number of votes, I am sure that most users would have expected more from a major release (3.0) than a UI update

    I agree with you 100 percent that the feedback from our user base is one of the most important. And trust me, it IS the most important feedback to us, this is why we appreciate all of your feedback and also love talking to you in the forum. But unfortunately, only a fraction of our users is registered in this forum. Therefore, we also reach out to our Resellers and talk to customers directly as well as to long-time partners. We collect all these opinions and take them into account when deciding on what is coming next or how a feature will look like. And if the feedback is clearly that we need to change something, then we do it. Last year, for example, we wanted to put Single Image Rendering and Batch Rendering on one button, with a corresponding dialog. Since the feedback from all sides was clearly negative, we have reversed this as quickly as possible. But as Joachim said, so far we received mixed feedback. We need to have more feedback from more users to make further decisions on a solid basement. Since not all our users are using the preview versions, we will wait after 3.0 is released to get more feedback. But again, this topic IS on our table and we are observing it. But we did not decide to change the current behavior, yet.


    Your question why we don't provide a list with the items that have been upvoted also brings me to your other comment


    Tobias


    Sorry but i take exception to your comment "In addition, we keep a mix between planning ahead and still being able to react to urgent circumstances at relatively short notice". I have been using Enscape for many years and i am yet to encounter any feature that has been reacted to "at relatively short notice". you just have to look at this forum to see how long user have been requesting batch rendering for Panos. if your team had to render 20-30 panos for a project i am sure it would have made it into enscape quite some time ago.


    All of the "feature requests" your users make are based on real world problems/bottlenecks that exist in our businesses everyday, some more problematic that others, as a product manager you should be acutely aware of these issues and be advocating strongly to your developers on our behalf. Let avoid another release cycle where the only change is an updated UI when so much more could have been done to enhance enscape as a usable product.

    I also agree with you that all of the feature request the users make are based on real world problems. But again, the forum represents only a fraction of our users. And even within the forum we receive a lot of different feature request. So, with all the different sources we have, we have several hundreds of feature requests that we consider useful and represent a valid real world problem. And believe me, we are aware of all the issues and also how strong the demand for these features is. But of course, not all users have the same real world problems in their daily work. For example, in the last couple of weeks, I talked to several customers myself. No one, and I am not understating, has mentioned Batch Pano when asked what features should come next. And this is why "reacting to urgent circumstances" does not necessarily mean directly reacting to request in the forum and why we are also not providing a list with upvoted request. Upvotes are a very important factor, that is why we collect them and we take them into account when making decisions, but they are not the only factor when we decide on what is coming next.


    I completely understand that this is very frustrating for the people which have these problems and are waiting for the feature. I assure you, we know that Batch Pano is a feature that have been request since a long time and we are discussing whether we will bring it this year or not. But since there is no decision yet, I can't promise it.

  • Tobias Bauer


    First of all, thank you very much for opening up a little more of the behind the scenes decision making that the Enscape team makes when it comes to the feature agenda. This was not something had I have seen discussed on the forum before, so what you told us is very insightful.


    That being said, I see a few inherent flaws in your post that maybe you could shed some light on/or explain a little more.


    So, why are resellers and "long term partners" (maybe I don't understand your definition of long term partners) the go to for getting feedback on feature requests. I completely understand reaching out to other customers who maybe aren't on the forum because you are correct that not everyone has a say on here. The only information I see being useful from a reseller is the amount of units sold, but that doesn't tell you what the users wish was added to program in upcoming releases. If the resellers are collecting information about what their customers want, the information you are getting from them is in essence customer/ forum feedback. Which furthermore leads to the implicit filtering of the information you are getting from them because of the telephone effect. I'd be interested in knowing the breakdown of who the Enscape team relies more on to steer the direction of the program. Is it 25/25/25/25, is it 50% forum/50% the other three? Ultimately, I agree that getting the most data points is key to making a informed decision but you have a bunch of people who go out of their way to give you feedback on here out of their own volition that I think would carry the most weight if enough momentum was behind a feature request.


    Second, from your explanation, why release a preview version at all? The entire reason of the preview version is to let people explore the changes you guys are making and give you feedback on what they as a customer feel the update is improving or lacking. If you are just waiting until the full release to get the "true customer feedback" you are basically turning your back to people like Herbo who have made really solid points about the product you are about to release. Yes the feedback you might receive from a preview version is tiny in comparison to a major release, but it can be really insightful and prevent a lot of headaches on both yours and our sides.


    Am I completely wrong about all of this or is there any more information that you could shed light on this topic?

  • In my experiences with beta/preview processes - usually the criticisms that the testers consistently bring up turn out to be correct down the road. It can unfortunately be a bumpy ride when the flaws/missing features are released to all users in a stable release, especially when the goodwill of the testing group is dismissed.

  • But as Joachim said, so far we received mixed feedback. We need to have more feedback from more users to make further decisions on a solid basement. Since not all our users are using the preview versions, we will wait after 3.0 is released to get more feedback. But again, this topic IS on our table and we are observing it. But we did not decide to change the current behavior, yet.

    Although I personally don't mind how the current release works, I do have sympathy for Herbo's (and others) concerns.


    Perhaps part of their frustration is that what they are proposing (keep the settings in the render window but don't start the renderer automatically) seems like a good solution, without compromising on the advantages of the current design of having the settings integrated in the frame buffer. It also (perhaps wrongly) sounds like relatively simple to implement. But maybe it's waaay harder than it sounds, and is that also part of what's holding you back?

  • Although I personally don't mind how the current release works, I do have sympathy for Herbo's (and others) concerns.


    Perhaps part of their frustration is that what they are proposing (keep the settings in the render window but don't start the renderer automatically) seems like a good solution, without compromising on the advantages of the current design of having the settings integrated in the frame buffer. It also (perhaps wrongly) sounds like relatively simple to implement. But maybe it's waaay harder than it sounds, and is that also part of what's holding you back?

    It's been awhile since I've used it, but I believe this is the way Thea Render worked. The full render dialog box would comes up every time, but it would only begin rendering if you wanted it to. This made sense and was necessary for a non realtime renderer, but I think the same principle could apply with Enscape. If I had to guess, the vast majority of Enscape users won't have a problem with the way 3.0 is setup currently, but a loud and frustrated minority will. Most of my models aren't large enough to present an issue, but I've had some in the past that are, for which I've had to turn the render settings down and switch to White mode in order to get the model to load succesfully. It's a real issue and deserves attention. It seems to me it would be easy enough to add a check box, similar to the RTX dialog now, which you turn off if you don't want Enscape to automatically begin rendering on startup. Most users will never mess with it and it will continue to work just as you've designed it. For the small minority that do need it however, it will ensure Enscape continues to be functional. Win win.

  • Speaking of Enscape startup - is there a way to set the Enscape window to not always show the help panel by default when you first open it? I thought there might be a settings toggle but I didn't see anything. Please add one if there isn't one already.

    Please go to the CAD sided general settings > preferences and uncheck "Show On-Screen Help on Startup" to change the default behavior of the new help panel.


  • Ok, a final post on this (because it's quite off topic. If you have a specific question, please reach out to me directly. We are also in exchange with Herbo).


    There is no specific waging between the different sources for feature requests. We treat user feedback equally in general. But it is about quantity and quality. Feedback like 'The old version was better' or 'I need it the other way' is valuable but does not help us to understand the WHY. That makes it hard to prioritize it within all the other hundreds of feature requests.

    Therefore: More info helps more. What is your use case?


    Just because we decided with this particular thing to leave it as it is for the release does not mean we do that every time. It was a separate decision made for this particular case.

    We definitely want the early feedback to be able to react in time. That does not necessarily mean that we decide to do so. There are just a lot of things related to that question besides the pure request itself. Capacity, internal processes, company/product strategy, technical limitations and risk management are just a few things that also needs to be considered before making untested (relating to UX testing that we did with the current implementation) undefined (well defined to be implemented) changes right before the release.

    Right now our feature definition and UX testing with users take place months before developing them. And there is a reason for it.


    I know, this is not the usual discussion that we are having in the forums. I really appreciate it. Even if it is not about the product but the process.

  • Minor quibble - but I see that there are 2 "new preset" buttons - one at the top of the list of presets and one at the bottom. They both appear to make a new preset based on the default preset. I liked the previous behavior where the new preset was based on the current settings. I see that you can do that method by copying the preset that's current, but I'd rather have one button to do that automatically instead of by context menu.


    I also don't like how any "live" changes to the current preset change that preset. I like being able to click on the preset and go back to the settings I had saved for that preset. I fiddle with the presets all the time, but only save one if I like the way it turned out. This new way, I lose the way I had the preset before because the saved one gets updated as I adjust it.