You’ve done a great job architecturally on the 2.1 series of releases and fixes.
Unfortunately, you’re getting somewhat spanked on the customer reaction side of things, due primarily to theme designers not keeping up.
While it’s definitely the responsibility of the theme designers to prepare for architectural changes and track the notifications Woo puts up on their website, it’s all kind of lost on the end users who seem to be getting caught in the middle.
Clearly the themes need to be updated in tandem with your new release, to avoid this kind of s***storm in the future.
I’ve got a couple of communication and procedural suggestions to help out next time.
(I) In the run up to the big architectural releases, prior releases should have notification banners that the big update is coming, and the end user should get on to their theme provider to be sure that theme update will be ready in time.
(II) On the Big Architectural Change Release itself, set up a different auto update mechanism.
- Rather than the update changing the world on install, have the update go to a confirmation screen.
- On the confirmation screen, inform the user of the big change.
- Give them a button to click on, to confirm that the theme is ready for this change, making sure they did an update before, etc. The release changes nothing (neither plugin code nor database) until this confirm button is clicked.
- If the user does not hit the confirm button at this time, the screen is available at any time until the update is applied. And no further updates will be able to be applied, until this one is done first.
I think this will help bring the end-user into the loop, and they can act as a direct catalyst to ensure that the theme is ready for the new update, before the changes take place.
It’s extra work on your end, but this would help reduce the offal hitting the rotating blades.
- The topic ‘A Suggestion for Future Big Releases’ is closed to new replies.