By Rachel Andrew CHAPTER 11This log is important as it allows you to check whether a feature is
indeed requested by a lot of different people, or whether it just seems that
way because of one or two noisy people repeatedly asking for it. Once you
have that list of requested features and can see what is floating to the top,
you have something to work with.
PRoTeCTing The CoRe uSe CaSe
Perch has very much been driven by customer requests. We launched with
a product quite different in scope to what it is today. At launch we had a
simple content editor — no ability to add new pages or resize images, and
no API, so no add-ons or ability for users to develop them.
With new pages, for example, we had assumed that our target market
would want to protect the website architecture as designed and not want
clients to add new pages all over the place. However, our customers had
other use cases in mind and the ability to add new pages became a top fea-
ture request, something we added to the product fairly early on.
It is vital that you maintain control of your product and protect it from
feature bloat as you try to fulfill customer requests. Remember that it is
perfectly acceptable for your product not to be a perfect fit for everyone.
If you try to cater to every possible need then you’re likely to end up
with a product that’s difficult to use, with so many options that people find
it hard to get started. In our case, that would mean ending up like so many
other CMS products of the type we try to provide an alternative to.
We deal with this by strongly protecting our core, basic use case — a
use case that hasn’t changed in the four years since we launched. Once
Perch is installed, to start editing content on a page you need to include the
Perch runtime and then add a Perch content tag to your page.
Then, all you need to do is reload that page in your browser and the
region will show up in the admin area where you can select a template and
start editing.