We are planning to integrate a feedback functionality into v2.1.0, so we would like to know your thoughts about it.
What is the feedback functionality?
It is a “Feedback” link/button which will send a list of configuration parameters to our server each time you click on it.
What is its purpose?
It will help us to sort out the following:
the importance of add-ons and functionalities
the weight of feature requests (if some functionality is very popular, we will concentrate on it)
priorities for bugs (so we could increase the speed of patch making)
abandoned functionality (so we can hold the clear code)
What parameters will be sent?
Currently, we are planning to send the following data:
setting values
add-ons availability and options
products stat (number of products, options, features, filters, etc)
taxes & shippings & payments
promotions
users stat (number of users, admins, user groups, etc)
The point is that no money values will be sent at all. No accounts, passwords, email or any other private data.
Before the feedback is sent, the list of prepared parameters will be displayed in picker (see the screenshot below), and after that you will be able to click the “Send” button.
Please post you ideas regarding how the feedback button should be displayed, how often you would like to send a feedback, and others.
I think is acceptabel to get a faster a better and stable system. But it dont may send out important datas from the shop, meaning: Names from customers, monthly amounts and so on.
And if it possible to made an E-Mail manager addon for all outgoing emails and if that not very high expensive i will pay ot that you can do this in core version too.
Email Manager means that Admin can control the complete outgoiung mail with the included editor in cs-cart.
You can send me pm if you dont like to write here.
I think the issue of user-submitted code needs to be addressed independently as does your feature request. There is currently a suggestion in the Ideas forum requesting email management capability:
[COLOR=“Red”]- the weight of feature requests (if some functionality is very popular, we will concentrate on it)[/COLOR]
priorities for bugs (so we could increase the speed of patch making)
abandoned functionality (so we can hold the clear code)[/QUOTE]
imac-
Will this replace the UserVoice/Ideas forum or will this be used as an additional means to express interest in a new feature? If it is used to supplement the UserVoice input, it will be important that ideas sent in via the “Feedback” system are entered into the UserVoice forum for voting and to maintain a single repository.
I’m afraid you guys will spend so much time looking at 5000+ submissions that you could use that time to fix bugs, improve usability and add new features and addons. I thought the ideas lab was the place to see the importance of new feature requests. Any bug little or big should be top priority and fixed immediately, I don’t think bugs should be prioritized because any and every bug needs fixed asap, not put on the back burner of a priority list because someone doesn’t think it’s important enough to get fixed now.
Instead of spending time on a feature like this I think what people would like to see is an online bug patch upgrade, similar to the online upgrade but instead an online bug patch as they become available, which should be asap. When the root admin logs into the admin panel the green popup box should display and say Bug Patch #2673 available would you like to patch the files now? The bug patch online upgrade should then display the affected files for investigation before upgrading - Sno
This is my concern, as well. We were told that the Ideas forum was going to be the single repository for feature requests and where we could voice our enthusiasm for a product by voting. This seems like it would create a competing list for feature requests.
I thought the whole idea of getting the feature requests out of the Bug Tracker was to make the Bug Tracker more manageable. Obviously, reported bugs should get priority over feature requests.
I do like this idea for bug reporting. It will provide the support people with much more information (basically what they have to chase down by logging into your site after a bug is reported) which should help to provide more timely fixes.
I also like the idea of a bug patch system. We kind of have that in the Bug Tracker when the diffs are provided; what we need is the ability to apply the patch automatically.
Will this replace the UserVoice/Ideas forum or will this be used as an additional means to express interest in a new feature? If it is used to supplement the UserVoice input, it will be important that ideas sent in via the “Feedback” system are entered into the UserVoice forum for voting and to maintain a single repository.
Bob[/QUOTE]
NO! UserVoice will remain the main feature requests repository.
Feedback won’t contain any feature requests or anything of this kind - it only gives us idea of store configuration.
But in case some features have the same number of votes, we can refer to feedback data to find out the most popular one (if it is possible, of course).
[quote name=‘snorocket’]I’m afraid you guys will spend so much time looking at 5000+ submissions that you could use that time to fix bugs, improve usability and add new features and addons. I thought the ideas lab was the place to see the importance of new feature requests. Any bug little or big should be top priority and fixed immediately, I don’t think bugs should be prioritized because any and every bug needs fixed asap, not put on the back burner of a priority list because someone doesn’t think it’s important enough to get fixed now.
[/QUOTE]
We are not going to look through all the requests. Mysql will save us:). We need statistics.
You are quite right about bug priorities, moreover, when we release the cart, it should not contain any bugs. We have this light bulb over our heads, which always puts us on the right track. And we are doing our best to achieve this aim, and Feedback is the next step.
[quote name=‘snorocket’]
Instead of spending time on a feature like this I think what people would like to see is an online bug patch upgrade, similar to the online upgrade but instead an online bug patch as they become available, which should be asap. When the root admin logs into the admin panel the green popup box should display and say Bug Patch #2673 available would you like to patch the files now? The bug patch online upgrade should then display the affected files for investigation before upgrading - Sno[/QUOTE]
This feature wil be really useful, and we are thinking about it, but there are some issues with it (e.g. the upgrade). We will create a separate thread for it soon.
[quote name=‘imac’]Ok, so I have several questions:[/QUOTE]
imac-
I think it might best be delivered as an addon so that people who don’t want to participate do not have to. With that said, hopefully most people will participate so that the developers have a better understanding of their customer’s installation and setups.
To be statistically meaningful, it would probably be best to establish an automatic regular reporting interval which the admin can then confirm to send. However, I think it is also important to have an ad hoc reporting method for when a bug is encountered. To me, the most important time for data collection will be when a problem arises. When I encounter a problem, I want to be able to report a description of the problem with data relevant to my environment automatically attached. These bug reports should be identified differently from the regular interval reporting.
The data being sent should be available for review - this is how most the automated bug reporting I am familiar with works. One bit of data you are not collecting is the server environment (Linux or Windows, PHP and MySQL versions, HTTP server and version, etc). I think you need to have this data available too.
I would like a button in the lower-right corner (like the current “Report a bug” button). You could limit display in the storefront to just admin users (like the current console).
[quote name=‘snorocket’]I’m afraid you guys will spend so much time looking at 5000+ submissions that you could use that time to fix bugs, improve usability and add new features and addons. I thought the ideas lab was the place to see the importance of new feature requests. Any bug little or big should be top priority and fixed immediately, I don’t think bugs should be prioritized because any and every bug needs fixed asap, not put on the back burner of a priority list because someone doesn’t think it’s important enough to get fixed now.
Instead of spending time on a feature like this I think what people would like to see is an online bug patch upgrade, similar to the online upgrade but instead an online bug patch as they become available, which should be asap. When the root admin logs into the admin panel the green popup box should display and say Bug Patch #2673 available would you like to patch the files now? The bug patch online upgrade should then display the affected files for investigation before upgrading - Sno[/quote]
You take the words right out of my mouth… I couldn’t have said it better.
Preferably as CORE functionality that can be turned off.
A) If I encounter an issue, it’s easier to turn something “on” rather than install it. This may work just as well as an addon so long as it’s “one click” but if the addon functionality is broke it’s self-defeating.
B) I would prefer that the system do two things:
(1) Export the settings to an XML file where possible.
(2) Export to CS-Cart at will via XML? or preferable format.
As much as it’s important that CS are kept upto date with changing server environments etc, I’d like to keep this information accessible (Apache auto-updates, functionality is broke and I’ve got a report that tells me what’s changed)
Autopatching: Ability to turn-off. I’m now developing a highly customized store, a single patch to view.tpl and my site is down
an add-on is a better way of doing this so we will have a choice if we want to participate or not and give us choice(check boxes) of what information we want to send, some people might be sensitive about information being sent.
I consider ALL of our business related details highly confidential and personal! This includes anything related to shipping addresses, products shipped, etc. etc.
Essentially I will not allow any of these details passed on to any entity including CS-Cart. I highly suggest this functionality to be dis-allowed in the cart or I can assure you that you will have many business owners / managers concerned & quite upset!
If you need to collect statistics for whatever reason, then there are other ways these details can be collected, however, business owners with any level of success will always make certain they are in control of exactly what details are being shared.
There are plenty of bugs already reported to you in the “Bug Tracker”, many of which have laid idle for months or even years, there is enough there to keep you busy for quite some time.
[quote name=‘Struck’]If you need to collect statistics for whatever reason, then there are other ways these details can be collected, however, business owners with any level of success will always make certain they are in control of exactly what details are being shared.[/QUOTE]
Based on the original post, it appears they are only interested in collecting general statistics - for instance, you have 50 categories and 1500 products, not the actual products or categories. The same would be true for users - you have x number of users and y number of user groups. I think the point here is to understand the needs of their customers based on their actual installation statistics.
As I mentioned above, I would like there to be a bug reporting capability which would actually send specific information when I choose to report it. This is really no different than giving them access to your server so they can suss these things out.
I agree that storeowners should be able to review (and maybe even set) which information is sent but I don’t think people should be getting all paranoid about gathering some general usage data.
I see this as a way for the cs cart devs to see usage stats for the different features of the cart. They are not interested in your customer information or your total sales. They want to know that if Z # of cart owners use addon/feature A and Y # of cart owners use addon/feature B, then they can decide what is the best path of priority for the new addons in development.
[quote name=‘adodric’]I see this as a way for the cs cart devs to see usage stats for the different features of the cart. They are not interested in your customer information or your total sales. They want to know that if Z # of cart owners use addon/feature A and Y # of cart owners use addon/feature B, then they can decide what is the best path of priority for the new addons in development.[/QUOTE]
One of the other items they mentioned specifically in the original post:
[QUOTE]Currently, we are planning to send the following data:
setting values
- add-ons availability and options
products stat (number of products, options, features, filters, etc)
taxes & shippings & payments
promotions
users stat (number of users, admins, user groups, etc)[/QUOTE]
I am happy they are finally trying to understand how their product gets deployed and configured.
