Having been beaten and cajoled into structuring this blog series around the development of an ExpressionEngine 2 module, it quickly became apparent that the missing ingredient was a module idea.
An appeal to my adoring public brought forth a few interesting suggestions, but none of them fit the bill. Clearly, a better brief was required.
I began by listing which aspects of module development I want to cover in this series. Any module idea would need to tick most — ideally all — of the boxes below:
With requirements in hand, I began to dig through my “someday” list of add-on ideas, looking for a match. In pretty short order, I found one that fits the bill. Here’s the pitch:
Tweedee makes it easy to build a custom Twitter search, and control which tweets are displayed on your website. Tweedee automatically removes duplicate tweets from your search results, and enables site administrators to approve tweets for display on the website with a single click. Perfect if you want to display the latest Twitter buzz about your new product, without opening the doors to everyone with a hash-tag.
After some concerted thinking spanning up to three minutes, I was able to determine that this idea would not only make my wishlist whimper with fulfilment, it was also the most original concept in the world ever, and utterly without precedent.
Suitably full of myself, I next jotted down a list of functional requirements. As ever with these things, we’re working with a limited budget (time), so I split the requirements into “must haves” and “optional extras”.
There’s still plenty of room for interpretation there, but it covers all the major bases.
The optional extras, in no particular order, are as follows:
One of the trickiest parts of add-on development has nothing to do with user interface design, or getting your PHP on. It’s the ongoing struggle to keep your add-on focussed, and free from bloat.
One way to achieve this, whilst still providing other developers with the means to customise your add-on to suit their requirements, is to implement your own custom extension hooks.
Scanning the list of “optional extras”, the last item jumps out as being a prime candidate for this. It isn’t core functionality, and will potentially require ongoing updates as the range of URL shortening services continues to expand.
Rather than tying ourselves into a never-ending series of updates and “new service” feature requests, we can make the search results available for manipulation prior to display in the template, using a custom extension hook. More on this, once we get into the development stage.
The user interface, that’s where. How very exciting.