While the new editor looks nice, it doesn't seem to speed up any power-users, and the long-awaited "rearranging & duplicating of actions/paths" sounds like it isn't in the immediate future.
Since you allow for import/export, and the file is pretty readable for anyone that is used to looking at JSON/basic coding, I was wondering if the team could build a super barebones editor view that you could flip to which would just show the raw code. You wouldn't need to invest tons of resources into allowing for debug functionality, that onus can be placed on the power-users.
Spoke with someone on the product team about it and they thought it was a good idea and wouldn't add a ton of development efforts, while also appeasing many of your power-users' frustrations. Could something like this be feasible?
Best answer by jesseView original
Would love to see this!
Oh my, yes please!
While we're at it, when we test our steps, it would be great if there was a view to see raw GET/POST call data - it's really helpful for debugging odd errors.
@alex (CC @Openside and @Luhhu) I will go ahead and submit this as a feature request on your behalf. In the future, if you can continue to send feature requests to support at firstname.lastname@example.org, we'd super appreciate that! :)
yesssss! I love this idea. Something like js fiddle.
@jesse! It's definitely tough because while this is a feature request, I'm also curious to see how the community reacts to it/builds atop it (or if I'm alone in the request - pulls me back to reality).
Any idea of the best way to handle that type of dichotomy? I love seeing what other users are requesting because it opens up my mind to expand upon it and think differently. Having a direct-to-Zapier feature request via email definitely removes the community aspect, of which helps shape, mold, and transform the idea into something larger.
Not to mention, it's also a great way to get people regularly coming back to the forum. I visit the Asana forum all the time simply just to look at the "feature requests" section because the community discussions around feature ideas are some of the most fascinating conversations.
@alex, totally valid point here and happy to clarify the thinking from our end.
We certainly don't expect feature requests to not exist in the community and know that often, starting discussions about new features and the potential of the platform is what brings the community together. So, we don't want to discourage that kind of conversation in any way.
I will say that where we are at this point in the community beta and as a company, we are not ready to create a specific space in community for feature requests/an ideation structure because we're still having discussions about the best way to support this.
In the future, we want to be able to provide a space for these requests along with public insight into our roadmap. We just need to make sure that before we create a dedicated space for that kind of discussion, the company and our community team is 100% prepared to support it. That means that right now, we're defaulting to our traditional method of collecting and recording feature requests, though our support team.
That being said, please do continue to have discussions about things that might be useful in the product, I'm just asking that for now, folks refrain from titling posts with "[FEATURE REQUEST]" as to not encourage posts focused on feature requests alone. Hope that helps to explain where we're coming from on this!
We'll try to refrain from posting specifically a feature request, and instead treat it more in the form of a discussion 🙂
Did I miss a reply somewhere in the middle here?!
I'm going to make a note of that and see if there's anyway that we can leave the Accepted answer in the conversation flow (as well as having it at the top of the comments) so that we can avoid this kind of confusion in the future!
Yes, that would be useful, as the notification brings us to most recent post in a comment, so you can easily miss an accepted answer like I did.