| I would like to assign owners to each App so that I can easily identify who "owns" a particular App. This could be as simple as the person who created or last modified the App or a separate field where we can assign an owner. This would be very useful when trying to address any issues or questions with a particular App. |
Hi Siobhan,
This seems to be quite a common type of response on these forums.
These forums have very low engagement levels from users and to use votes to gauge the need for the features like James-E-Johnson-Jr has raised above means GoCanvas will continue to underestimate the importance of many of these items.
Dave
Hi Dave,
First, thanks for your feedback above and across the Community. I appreciate you taking the time, even if it feels futile.
The reason that response is familiar is because we do try to surface popular, frequent, and related feedback and ideas to the appropriate people. This feedback is just one (and obviously the most public) way that the Product Team gets information about what users need from GoCanvas. We have other methods and touch points with customers (and potential customers, and former customers) to try to gather that information, so the Community serves as one of many inputs.
The reality is, sometimes what we're hearing from people here doesn't align with what we're hearing elsewhere or what we're seeing from competitors. Other times there are bigger initiatives that will solve for some of these items, but are part of larger, slower moving projects that simply take more time.
We also have a pretty hefty backlog of things that we want to do, some of which are captured here and some that are more general improvements as opposed to feature-specific ideas, like "make the App Builder easier to use." We also have some less fun things that we need to do, like keep our core technology up to date, which in turn helps us ensure your data is safe. Another example would be putting things in place to become GDPR compliant. Those things are incredibly important and take up significant resources that could potentially be devoted to rolling out new or improved features.
All of that said, we do advocate for what is being asked for here, especially as we see patterns and consensus around issues. Things like the upvote counts and number of comments give us really useful data when we're having those conversations, which is why we encourage it. It's the difference between saying "a few people have asked for this" and "38 people have asked and 16 have left comments about this" or "30% of posts are about how difficult this feature is to use."
We're going to be able to check off a few big items that I think people will really appreciate (static images are coming soon) and will keep asking and making the case for more. I would love to keep having your input, as much or as little as you're willing to give.
Thanks,
Sara
For a premium subscription service all of those things that are going on should be business as usual and expected.
Regarding the upvoting - you've reinforced my point. Exceptionally low engagement levels does not produce really useful data .
Hope the expectation isnt that in our instance we need to get each of our 200 licenses to log in and up vote items?
To move this back on topic - it would be useful to know in instances like this were there is a short coming in the system how other accounts manage this issue.
Specifically in this case - how does GoCanvas recommend its customers manage identification of App owners.
To Dave's question:
"Hope the expectation isnt that in our instance we need to get each of our 200 licenses to log in and up vote items?"
Does GoCanvas consider the number of licenses we each represent, or are we expected to have each individual user log in and vote for things? For some reason I have been under the impression that our license counts were possibly being taken into consideration some how.
I'm going to circle back to Dave's question in a subsequent post (working on a couple of options), but wanted to address the engagement question and how we look at those numbers.
The short answer is: the expectation isn't that you're going to have everybody log in and vote, but realistically, it doesn't hurt, either.
The medium-length answer is: we look both at the raw numbers (x number of votes on a post) as well as how many users those votes represent (so, Nate's 1 vote represents x number of users on the account). Generally, we look at the raw number first before digging into what types/# of users represented are looking for a particular feature.
Again, these numbers are just one data point that goes into deciding what does and doesn't get built.
A couple of options of varying complexity.
The most straight forward way, especially to keep track of who built the App to begin with would be to use the App Description field:
You could keep adding to that with a line for each updater, or store the creator and creation date in there. That's likely what most folks are using.
The (probably too complex) way to get to a more sophisticated version control would be to add some fields to the App (hidden on mobile and from PDFs) and require people making changes to the App to update those:
The updater would put their name and the edited date as the default values for those fields. Then you could see the last person to edited the App.
If you wanted to take it a step further, because those values will be included in the Submission (again, not visible to anyone), you could create a Zap to pull that information into a Google Sheet to create a dashboard of the most recent updates and editors to all of your Apps or even a full version control log of every update.
As an example of that, I've created a Zap that updates a specific row of a spreadsheet for my Demo App that pulls in the Updated Date and Last Updated By Fields. I'm using static values (the name of the App, the original author, and the created date) to populate the things that won't change. Every time a submission comes in, it puts in those update-able values (and you could put some filters in there to only do it when that value changes). Then I have another duplicate Zap that pulls in that information from a different App (called New App), and on and on.
You end up with a dashboard of the most recent updates, that changes when the App is updated (assuming the editor changed the default values each time:
And then here's what that looks like when a Submission comes in with new info and the Zap updates the sheet:
There's a ton you could do with this method - instead of looking for the same row each time, you could just add it to a list, so you'd capture every change. The downside is the manual aspect (the editor has to update the fields) and that you need a Zap for each App you want to track this way.
So, a couple of options. I'll also ask around with some of our Customer Success Managers and see if they've helped people set something up to accomplish this.
______________________
Sara Kaplow, Community Manager wrote:
The short answer is: the expectation isn't that you're going to have everybody log in and vote, but realistically, it doesn't hurt, either.
_______________________
To be clear we will not be asking our license holders to log in just to upvote items.
Hello everyone!
Great news, App Edit History is now available in GoCanvas!
App Edit History is a feature found within the App Settings page that allows Admins and Designers to view the high-level changes made to their forms. These events includes:
This feature can be found in the Quick Links section of each Apps Settings page. To access App Edit History, go to the Apps page > App Settings > App Edit History in the Quick Links section at the top.
This is not a retroactive history. You’ll only see the list of events occurring after the official launch date of this feature.
Please visit the Help Center Topic to read all release information.
Please sign in to leave a comment.
Comments
15 comments