While I like the general direction that Envato is taking, I’m pretty disappointed with the drop in sales in the last week, and especially last 4 days.
I’m sure the break-down in rating making its affect. I really hope that Envato will be able to “separate flies from cutlets”, otherwise these kind of ratings will work against us and not for us.
I suspect that majority of 1-star ratings are misuse or misunderstanding of the product on consumer part, especially when overwhelming majority gave a product a rating of 5-stars. And my guess is, that majority of 1-star “clients” never even contacted their respective authors. After all, I think authors should have a way to reach out to the “unhappy” customers and offer their “magical” support.
It would be great, if Envato had a sophisticated support/ticketing system, where they could measure the “important” things like: response time, type of issues, customer satisfaction with the product and support. Correlation between support response time, longevity of conversation and overall rating. This way we could see the 1-star ratings for what they really are and not just guess.
I wonder, if I force the default jQuery library by default, do you think there is a high risk that it might affect some themes or plugins that still replying on the older versions like 1.4.1 and 1.6? I always can show people how to deactivate that, in case it causes a problem. Thoughts?
SimpleRealty saidthe themeforest review team is spouse to be using those same standards(at least thats what was announced) was what I was trying to get at
Yes, the .org team is reviewing themes according to their code standards now.
Oh, I see. I didn’t pay attention to the theme release date on those that had issues.. but I know they are still very much available for sale here on the network.
most the themes on here “should” go through the same standards(plugin) that the themes that get submitted to the .org repo there were some threads about it almost a year ago saying they are going to reject themes that don’t follow proper script standards unless somethings changed and wasn’t announced or reviewers aren’t running the theme properly there shouldn’t be an issue with themes on themeforest but…....... not saying the systems perfect
Yes, the .org team is reviewing themes according to their code standards now.
I’m not bashing the local “system”, I’m just trying to concentrate on “how I can do this better within the current system”
SimpleRealty saidForgive my ignorance, but surely the approval process now must expect standard wp-coding practices for plugins? Otherwise what are the reviewers approving? Or are you talking about very old plugins that are sold here?
iamthwee saidActually, ALL of the themes and plugins I had support issues with are commercial and sold on Envato network.
Unfortunately, you can’t stop buyer’s stopping off at wordpress.org and installing the several of the poorly coded plugins/ or no longer supported plugins.
I think it’s impossible for the reviewers to review the code… on the other hand that’s exactly what WordPress Themes Review Team started to do last year in order to accept free themes into their official repository. They just realized that they got too much junk on their hands.
Just because a theme or a plugin works, it doesn’t mean it will work with other plugins – that’s why WordPress has a development API , as well as furnished their platform with standard libraries, so the platform becomes highly modular and flexible. By not following the API standards you’re risking to break that chain of modularity.
P.S. Simple example. Let’s take our jQuery library, which seems to be creating the highest support volume. WP requires programmers to put scripts in a “bucket”, so it can see what it has before outputting them on a page. After all scripts are in a bucket, WP inserts those scripts into the page according to their dependencies. If you ignore that order, something might break. You can avoid letting WP to put your script in the bucket, and instead insert it into the output yourself. What happens here? Well, it still might work and your code can be correct, but WP is unaware that you did that, because WP only can control all the scripts in the bucket. WP API instructions tell you to put the script in the bucket, but you didn’t do that for some reason… It’s not about the way we write our code – in pajamas, naked, drunk, while standing on the head or some crazy way on our smart phones – it’s about following simple pre-defined rules for this particular platform. So all the geeks’ code, no matter how hammered they were when wrote it, would play nicely with others at the end. So we achieve harmony. Think of it as highways and driving rules. Amen
@pixelentity – I hear you. This definitely helps and I’ll try to incorporate yours and modrauk’s feedbackl into a better support workflow for myself.
http://wordpress.org/extend/plugins/debug-objects/ should help atleast find issues
Thanks! Will definitely check it out.
jQuery conflicts caused by incorrectly loading jQuery is the single most common support ticket I get. What I have found works really is just being very up front with the buyer about what the issue is, and make sure they understand that it is the theme (or another plugin) that is loading jQuery incorrect.
It works really well if you can point out the actual error (or location of bad code); that way the buyer doesn’t think you’re just trying to avoid helping them.
I usually offer to find the source of the problem, then tell the buyer that I will fix their theme (or plugin) for a small fee. Most of the time users are fine with this. When you get a buyer that gripes because they feel like they are paying twice, or that they have bought a broken item, you just have to be very, very clear with what the issue is, how it can be solved, and tell them exactly what to say to the developer that coded it wrong.Aside from the things above, one of the only other things you can do is work to educate others. When you see a theme that is incorrect, contact the developer; write tutorials on how to do it correctly; offer to teach developers doing it wrong what the right way is.
@mordauk – I think you have very good points there when it comes to structuring your support in a way when you don’t become a hostage of other people’s mistake.
So a few things I could take from here:
1. Outline possible issues, how to identify them and how to fix. 2. Provide a debugging routine – deactivate plugins one by one to identify the conflicting one. Switch to default theme etc. 3. After performing items #1 and #2 if a client identifies a third party product at fault – they should contact the product author for support, or they can hire me to investigate further. 3. If clients need help with fixing a third party product – offer help for additional charge.
Something like this incorporated into my workflow, but in a way that makes sense for everyone, could really make it work better.
Thanks for your input man!
From a buyer’s perspective, ... For a customer like me, a non coder, sometimes we ‘expect’ the product we purchase to ‘work’ out of the box (I understand there can be problems like this, but others don’t) but going that extra mile for a minute or two to fix a simple problem can really result in a very happy customer
I appreciate your feedback!
I’m not trying to get around providing excellent support, and to be fair, while I have a full time 9 to 5 job, I have managed to answer every single comment for the plugin, I also exchanged 113 personal emails with my buyers in the last week. I have logged into half-dozen clients’ sites and for the most cases fixed their issues. My last issue took me an hour to realize that I can’t fix it on my client’s site. I have emailed the theme author and requested a copy of the theme to help me out to debug the issue on my own server. When I finally got the theme, it took me another half an hour to debug it pretty much line by line through half-dozen of JS and PHP files, only to find out that the theme author used another third party plugin, which is now built into their theme, which directly embeds jQuery library into the code (against the WP coding practices) on all pages of admin panel. It’s a lot of work that doesn’t improve my plugin nor improves the theme that’s being sold to hundreds of other users and breaks my product.
Since I’m new to the support process, I’m trying to figure out a better way to serve my clients. By fixing their third party themes I’m doing disservice to myself and my clients, because they don’t realize that the theme they are using is not high quality when it comes to coding standards for WP. The only thing that my clients know is that my plugin wasn’t working when they installed it. If I fix their theme and something else breaks afterwards – I’ll be the one to blame. Plus I can’t do extensive enough testing to assure that my fix won’t affect anything else on their site, just because the original author doesn’t follow the same standards. And finally, next time they update their theme, it will break my plugin again by overwriting my patches.
So, while I see how this could look as an awesome service from a buyer’s stand point, when I fix their other product… going extra mile… this extra mile will bite me and my client in the butt when first opportunity arises.