Aug 14

CodeCanyon: Common Rejection Factors

Sun, 08/14/2011 - 10:17 — julie

Before submitting your first template to CodeCanyon, consider the following factors, which frequently contribute to rejected submissions. Please note that this list should only be used only as a guideline.

[This post is taken from the Envato Marketplace Wiki.]

 

CSS Rejections

  • Low Quality: The most obvious: sometimes, the design simply isn’t of a high enough quality to warrant being sold as a Premium item.
  • Too General: Because many CSS files are available around the web for free, items must distinguish themselves, and go above and beyond what’s typical.
  • Similarity: If a new submission is far too similar to items that are already available on the marketplace, it will be rejected. To be accepted, yours must be either unique, or of a higher quality than the currently existing items.
  • Inline CSS: Do not use inline CSS. Export all styling to an external stylesheet.
  • Validation: Excluding any vendor-specific prefixes, all of your code must validate. Otherwise, it will be rejected.
  • Inline -> Block: Do not place block level elements (div, h2, etc.) within inline elements (span, em).

JavaScript Rejections

  • Degradation: If an item requires JavaScript to work, you MUST provide an operable degraded version as well. For example, picture sliders should still be functional, at a minimal level, even when JavaScript is disabled. The practice of progressive enhancement should be employed to ensure that the script gracefully degrades in such a way that it remains minimally accessible to all users (or at least, the vast majority).
  • Complexity: The item is not of sufficient complexity or features to warrant approval. It’s important to us that items we approve are unique and do not offer more of what is already abundantly available online. It’s best to look at what scripts are already online and then possibly improve on what you find, possibly by adding unique features or even a superior implementation — anything to differentiate your item from what’s already available online.
  • Implementation: The item’s implementation is simply not up to the level of quality expected. There seems to have been only minimal thought given to application design. I can’t see much abstraction or any intuitive API for the buyer. It seems somewhat rushed and a buyer would find it difficult to customize this or integrate with it their own design and preferences. I suggest looking into design-patterns in JavaScript and abstraction.

PHP Rejections

  • Is it Unique: There are plenty of open source solutions available for nearly everything out there. We’re really looking for unique functionality, or items which provide a unique twist to an existing functionality.
  • Implementation: We expect code that’s top notch, secure and well commented. A clean application design and proper abstraction is implicitly expected.
  • Features: Less is more, sure; but when it comes to, say, a utility class, buyers are going to appreciate more features. There is such a thing as being too focused. Providing just a single, very simple feature isn’t going to get you far unless its implementation is spectacular.
  • Ease of Integration: The code must be easy for the purchaser to include in his existing projects relatively painlesslessly. Provide a more intuitive API, document your code better so that the user knows where he can hook into; provide separate config files to make it easier and provide a sample mini codebase to show them how it’s done.
  • Documentation: With code, documentation is king. Even for a very spartan utility class, we expect a well written, thorough help file expounding on the various methods it exposes, its signature and so forth. With a user script, take your time to create an installation guide and a quick start guide explaining all the features it provides. Please try to be as pictorial as possible in these guides. Our purchasers need not be tech savvy to use our scripts and being visual gets the point across quickly. Extra cookies for screencasts.
  • Lack of Market Prospects: This doesn’t happen often but, at times, we receive items that are generally well written, but have zero sales prospects. Before starting to write some code, please take a moment to think whether purchasers will pay money for such a functionality.

.NET Rejection Factors

  • Lack of Code, Binary, or Project: .NET is a rather unique category here at CodeCanyon in that .NET-based code can be compiled and distributed as a binary. However, CodeCanyon is a marketplace for selling code, and all submissions must include the source code, the compiled binary, and the project and/or solution of your component.
  • Failure to Follow Submission Instructions: Following the submission instructions is not only vital, but it saves time for everyone involved. They can be found here.
  • Design: A critical part of every piece of code is its design, and the folks at Microsoft authored a set of design guidelines for developers to follow to encourage consistency and predictability. It is expected to be designed according to the information foundhere.
  • Configuration: The best location for configuration settings is the web.config or app.config file – not in code. While the configuration section is useful for individual settings, components or libraries that need more complex configuration should incorporate the use of custom configuration sections. You can find a primer to custom configuration sections on Nettuts+.
  • Too General: You can find code freely available on the web. So, your item must distinguish itself from free code by providing features well beyond those free items.
  • Packaging: Non-visual components should be packaged as class libraries. Visual components (UI) should be packaged according to how they’re developed. ASP.NET user controls should be packaged as ASCX files (with code-behind if necessary), and UI controls developed as inheriting Control or WebControl should be packaged as class libraries.
  • Documentation: All public data types and their public members should be properly documented using XML documentation. This ensures that Intellisense gives the consumer appropriate information as they use your component in their project.

Other Rejection Reasons

  • Browser Testing: Have you tested your design in IE6 (optional), IE7, IE8, Firefox, Safari, Chrome, and Opera? While we do allow for alternative displays for older browsers — think simplified layout for IE6 users — your design must not break in any of these. If they do, your item will be rejected, with a request from the reviewer to make the necessary updates.
  • Documentation: Every template on CodeCanyon must include documentation to make the installation process as simple as possible for the purchaser. While you don’t have to teach the reader how to code, you should absolutely discuss any unique aspects of your template, which require further explanation.We encourage you to use the documentation template, found here.




Copyright 2009. E-mail Me
Auto Spare Parts