AliAbuRas saidThat’s why the Progress bar rocks, because you would have known by now where you are in the queue
Hi, How much longer can be takes? because I submit my files since 3 days and there is nothing happened! Thanks
As stated earlier in the thread, that isn’t true. The bar as not an accurate indication of where your item was in the queue or how close it was to being reviewed. It could actually vary quite wildly. It did, however, seem to give authors that warm fuzzy feeling of progress (albeit often false).
When team resources allow, I’m sure they’ll be able to work on improvements to this.
What it seems many people are missing here is that we’re not saying we won’t make this change in the future.
from the first post of this thread (I’ve read it again just now) I’ve got the impression that:
- queue info was broken as queue process changed
- queue info had been fixed
there is nothing about this being a transition period versus a different solution, being told that I’ve missed the meaning of the message is a bit off.jremick saidcan you share with us how the finalized upload feedback information will look and how much time the current transition period will last?
This is an iterative approach and this has been one iteration change towards an overall goal. We’ve taken all feedback on board.
Unfortunately, no. To be clear, I’ve not called this a transition period.
I can see two possible outcomes of this situation. A massive response from the community clearly indicates that the progress bar was, in fact, useful, and a vast part of authors never thought of it as ‘broken’ – perhaps only inaccurate.
If the person who took the decision to alter the way in which progress bar works is high in the chain of command, we can expect they will defend their decision no matter what, simply to prove that they ‘can’ and they are consistent. I once worked in a company where the managing director acted in a similar way. It led nowhere and was destructive for the whole organization.On the other hand, anyone who follows this thread can obviously see that we would love to see the number of items in the queue, because we need it. It may be a rough estimation, it may only show the amount of days remaining for our item to be reviewed, something, anything. I can’t possibly imagine that it isn’t feasible. I even volunteer to write the necessary code myself, if it helps (i know it won’t). My feeling is that this particular point of view reflects the general attitude of many authors here. Envato, don’t throw out the baby with the bath water.
What it seems many people are missing here is that we’re not saying we won’t make this change in the future. This is an iterative approach and this has been one iteration change towards an overall goal. We’ve taken all feedback on board.
Imagine that you go to the bank. There you get a ticket: A208 (for example), under this number you also will see such words: “You are 23 in the queue.” But actually you are not 23 (you may be 54), because there are tickets with other letters: D103, I406, G343 and so on. You are 23 person who has ticket with A letter. And in fact, you didn’t know where you are in the queue exactly to this ticket window. That is how banks work (at least in my country). And it’s normal.
You may simply write “There are 58 items before yours”. And after this message do a small button with ”?”. When mouse over this button, people can see the explanation that they are actually not 58, that this number can be higher in the future because… reason, reason, reason. And that is all!
Yup, I completely understand this concept and banks here work the same way. That said, there’s a specific purpose for this. You are given a number because they don’t want you to have to stand in a long line to wait your turn. Instead they provide you with the convenience of sitting down but still understanding when you’re up next because you physically have to get up and go to their counter.
A system like this is, for the most part, valueless in a digital queue where no action is required by the user. So what is the value to the user (you guys, the authors)? It’s in knowing how close your item(s) are to being reviewed. But you authors won’t be able to know that without knowing how long items take on average to be reviewed in recent history. There’s lots of considerations that start coming up in order to implement this well so that it doesn’t begin raising thousands of unnecessary questions based on everyone’s perceived judgement of the historical progress of the queues.
However, like I said before, we’re not saying this won’t happen, we’re just saying not in this particular iteration.
Thanks for understanding guys!
@ jremick: why don’t you simply show our position in queue like some years ago?
@jremick no one is expecting to see exact time when the review will be done, and as far as I remember no one asked for that. Authors only need to know some sort of numerical information related to their queue position. Whatever system you have and how complex it is, it is not relevant to simple fact that your system knows how many items are submitted as new items and as updates, and that it knows position of each item. Why you don’t want to show this is beyond me.
Again: no one expects exact information, but something that has a meaning for their current position in the queue. Even if item changes queues, new items are added and removed, but in every point item has to have position that can be easily determined, it doesn’t matter when it will get reviewed, only position in the queue.If you don’t want to do so, OK, it is your right, but at least rename the name of this topic: removing a feature and replacing it with something totally useless is not ‘fixing’. You fixed nothing, you choose not to fix it and only remove the whole feature. Let’s call things as they are.
First let me clarify that one reason we’ve chosen not to display some form of numerical information is available resources (people’s time) and project priority. Think of this as our “MVP” solution for this iteration on this component. No, it’s not ideal (we all, staff included, agree with you on that), but it’s the right decision given all the situation variables.
Thought it might seem simple to just add in a couple numbers, it can use more time than you might think. That isn’t to say it’s a large piece of work, but there’s many other, much higher value, pieces of work going on that are currently higher priority. But let’s be clear; we’re not saying that further improvements won’t ever happen. We very much intend on making future improvements!
As you might know, I used to be Review Manager (I’ve since changed roles) and I know the review system and its data intimately. I was responsible for initiating changes in the review system “flow” that increased its complexity (causing the need for the progress bar to change) but also improved review efficiency. The progress bar has long been a complaint, but more importantly it has been a resource consumer. We get support tickets, emails, forum complaints and tweets about it and due to it. When you combine all the time spent on those inquiries, it adds up to a massive amount of the team’s time that could be spent improving other areas of the system and authoring process.
However, the progress bar is not an easy one to fix. You can’t predict that a reviewer will get sick, causing a multi-day delay in review turnaround time for one or more categories. You can’t predict when a software release will cause a flood of high priority item updates, causing delays to everything else in the queues. The system complexity is at a point where accurately predicting when any given item might be reviewed is a difficult task. That isn’t to say it can’t be done, but that it’s not something we can quickly do and isn’t among our highest priorities (there are many more features you all have asked for that are more helpful and valuable, therefore higher priority).
So we need to reduce the resource consumption the progress bar was causing (so we can actually use those resources for making things better) but also fulfill the purpose of that little box you see once you’ve uploaded your item.
But what is its purpose?
- Provide accurate information about the current state of your uploaded item
- Set an expectation of when it would be reviewed
This change improves the available information about the current state of authors’ uploaded items but also, importantly, resets authors’ expectations about when we say their items will be reviewed. The accurate answer to that is we don’t exactly know and it’s not right for us to knowingly provide inaccurate information that sets expectations we may or may not be able to meet.
The progress bar may have felt good for some, but, unfortunately, gave a false sense of “progress”, which was more frustrating when something didn’t go as you expected (eg. the bar moved backwards). So I know this change might feel like a step backwards, but it’s really a step toward a better and more accurate system for indicating status and progress of your uploaded items. Sometimes you have to take a step back before you can take two forward.
From here we can consider the best ways to indicate estimated time to review, average turnaround times or other information. Most importantly, this enables us to spend more of our time making things better that are more helpful and valuable to all of you, rather than spend that time continually answering everyone’s questions about why the progress bar is jumping around like a neurotic monkey.
I understand you are allowing “upgrading” of files but not “downgrading”, however is there a list of what constitutes a sufficient alteration to a file?
The variations policy states “It has been rebuilt to primarily serve the purpose of the extended functionality (eg. eCommerce) ok so the judge of this is down to the reviewers knowledge and opinion? I think it would be wise to have a slightly more definitive explanation or criteria of change (unless I have been stupid and missed it)
We agree! The policy needs more definition and examples, which we will work on providing in the coming weeks.
A forum thread was recently started in which some members of the community wanted to discuss “lite” versions of themes being sold along side the full featured version.
This was a great question to ask as it has been a point of confusion for quite some time now.
But first, some history…Originally our undocumented policy around this was a strict No. However, over time, things have changed and the benefit to both authors and buyers, if done correctly, makes sense. Just like in every other major marketplace, versions of a core product or “upgrades” are commonly available. As the demand for eCommerce grew, so did the demand to sell a standard theme and an eCommerce version, separately.
Once the pricing for these features was reconsidered, we also eventually reconsidered allowing an eCommerce version to be sold separately as the work involved was often significant and justified a price increase. These themes commonly had an eCommerce focus rather than being an all-in-one like we see frequently today. eCommerce support is also much easier to add to a theme than it used to be.
As the marketplace landscape continues to change, there’s an increasing demand for theme variations and themes that focus on a certain purpose. To better accomodate this demand for both authors and buyers, a limited degree of theme variations would need to be allowed (ie. not strictly limited to eCommerce). However, as we had no documented policy for this, we have worked towards getting things like this both clarified and documented publicly.
The Updated WordPress Variations PolicyYou can read the recently published variations policy here.
Our goals for this were to:
- Document the existing policy publicly
- Clarify where the “line” is which justifies a new version
- Adjust the policy according to community feedback and demand
We have completed the first and are working on the second and third. We are listening to community feedback and discussing the future of the policy.
What is the policy?In short, “lite” theme versions are not permitted. However, multiple theme versions are permitted.
What we’re trying to be careful of here is the confusion around what a “lite” theme is. There has been many instances where a “disabled” version (most often called “lite”) of a theme has been requested to be sold (either separately or on its own) in which the buyer could then “unlock” the full set of features via subsequent purchase. We do not feel this approach is appropriate for ThemeForest and have not allowed it. So the term “lite” had become associated with “not fully functioning.”
We want to make clear that the minimum requirement for ThemeForest items is fully functional products (a “standard” product).
Beyond this, however, a theme can have significant additions in functionality and purpose that justify a new version being sold (just adding a plugin and a few extra styles will not cut it). If a new version of a theme is permitted, it does not mean it can be sold elsewhere when you are an exclusive author. The core product is still viewed as being the same and we feel this would breach your exclusivity with Envato. The only exception to this is when the theme has been rebuilt for another platform (eg. WordPress vs Drupal).
Questions that need to be answered…
- What is a “standard” WordPress theme?
- Won’t this flood the marketplace with versions of everyone’s themes?
- Are there future improvements planned for this policy? If so, what are they?
We will be working to answer these questions and clarify the policy documentation in the coming weeks. Please let me know if there’s any questions I’ve missed or clarifications you’re looking for in the policy documentation. Thanks, everyone!
Unfortunately I’ve not been able to respond to this thread as quickly or as often as I’d have liked. As you can imagine I’ve been very busy working on various projects for ThemeForest and, most importantly, discussing the feedback everyone has provided here with the different teams. This tends to take a little time, thus the delay in followup to this thread.
I realize this policy comes as a surprise to some of you, although it has actually been in practice for some time now (though without official clarification or documentation). This is an area the team is working hard at improving (documenting and improving submission requirements, policies, etc).
Tomorrow morning I will be clarifying the concerns in this thread via a new thread where the discussion can more appropriately continue, which will be easier for me to compile and discuss with the team so we can make the necessary appropriate changes.
Thanks for understanding, everyone!