Yesterday we pushed a change that tidied up the email subjects used for notifications. This change came from looking at how simpler email clients create threads of notification messages. However not everyone was happy with the new format.
Ed Johnson commented, "I'd like to see two categories of subject lines. One that combines posts and comments into one easily identifiable subject line and another that combines page creations and edits."
A good idea that we've already done. But the lesson here is that any significant change to Wikidot need to be measured twice and cut once. That is to say, discussed publicly before we start changing code.
On this blog I started, some months ago, a "designs section" for such discussions. Initially it was for new modules, other building blocks. We'll start using it more systematically for all important changes, so that our process becomes:
- We see demand for a certain major new feature or change
- We propose a design sketch ('we' usually being myself)
- We get feedback from the Community and use this to improve the design
- When comments have settled down, we move to implement the design
- The design becomes, ideally, the documentation for the new feature.
We've used this successfully in a few major new features. The advantages are clear: instead of fixing design problems in the product, deliver a close-to-perfect design first time.