<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    I'd like to see some real examples of what you mean by "companion
    plugin".  My general rule of thumb is that if a "feature" isn't
    specific to the theme or if it concerns data portability, it's
    plugin territory.  Sure, that line gets a bit blurred once in a
    while, but for the most part, it's pretty simple to follow.<br>
    <br>
    One recent example I've done is a portfolio plugin that a couple of
    my themes support.  I don't think I have a single support question
    on my site even remotely like your example about the plugin/theme
    combo.  I'm sure I will at some point, but it's not typical.<br>
    <br>
    I have one of the longest-running WordPress theme/plugin clubs
    around and rarely have I had users who couldn't figure this stuff
    out.  My guess is that it's about transparency.  It's not just about
    good documentation (though that helps).  You've got to be completely
    up front about what the user must do.  It also helps a lot if
    there's very little configuration -- plug-n-play is what it's all
    about.<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 5/22/2013 7:16 PM, Bryan Hadaway
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAP3jXhR1aPN5uxP5oCHQRxe96zSS9NgFNM489dYFxqoexO7zGg@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div>
            <div>
              <div>Agreed. My personal philosophy is everything off by
                default so they have a palette to work with, then they
                can simply check a box to turn a feature on as needed. I
                also agree that making things as simple as possible is
                key, which is why a companion plugin is most definitely
                a bad idea in those terms.<br>
                <br>
              </div>
              I have exhaustive customer support experience (years and
              thousands of customers now from all around the world in
              every imaginable demographic and plenty of war wounds to
              account for it) and can always predict the pitfalls. I can
              already guarantee this would lead to this scenario over
              and over and over again (regardless of how much
              documentation is written):<br>
              <br>
            </div>
            <b>Customer</b>: "<i>Umm, this theme doesn't have any of the
              options you promised, I feel a little mislead...</i>"<br>
            <br>
          </div>
          <b>Me</b>: "<i>Did you make sure to install the companion
            plugin as instructed? This is what houses all the features,
            please read... [providing doc link]</i>"<br>
          <br>
          <b>Customer</b>: "<i>I have to install a plugin?</i>"<br>
          <br>
        </div>
        I want my themes to be as self-contained, easy to use and
        friendly as possible because that's what the customer wants, and
        expects. Too many steps, too many moving parts is bad business.
        And considering that most free users are just as demanding as
        paying customers, they pretty much have the exact same
        expectations and attitudes.<br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
theme-reviewers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:theme-reviewers@lists.wordpress.org">theme-reviewers@lists.wordpress.org</a>
<a class="moz-txt-link-freetext" href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>