When I shared some of my thoughts on building Single Post Message, I received some good feedback via Twitter and Email from others who enjoyed reading about the work that went into building the plugin.
Though my approach to this particular plugin is different than that of Single Post Message, I thought I’d do the same for this just to share a slightly different perspective.
So here’s how I went about building Comment Images for WordPress:
For the post part, there were several key differentiators between this and my last plugin:
- The idea came from a conversation with others a meetup – not out of something that I needed for myself
- The actual design wasn’t sketched out first, only the flow of control for out it should work
- I had to contend with the various themes, their various designs, and how the images would render
- There’s issue with various hosting environments not supporting functions for uploading files
- Which versions of files should be supported and how should end users be notified when they’re doing something wrong
Obviously that’s a handful of issues, but I plan to keep this as succinct as possible.
Don’t Let Them Fail
One of the internal mantras that my team at 8BIT follows when building our products is Don’t Let Them Fail. Every time we make a decision, we try to determine the points of fail that may exist and then do our absolute best to eliminate them.
In the case of Comment Images, there are two major points of failure:
- Administrators need to know if their hosting environments offer support for the file uploading mechanism
- Users need to know what files they can upload
Administrators
To handle the case of administrators, I run a function just after the plugin has been activated to determine if the hosting environment is compatible. If not, then the administrator will see the following error in the Dashboard:
From this point forward, the plugin will not offer any functionality despite the fact that it’s active.
Readers
As far as readers are concerned, the plugin supports the ability to upload PNG, JPG, JPEG, and GIF but it’s not enough to simply show them the option in the input’s label, right?
After all, who really takes the time to read those?
Behind the scenes, if the user attempts to upload a file type that does not match what’s listed above, the file is simply ignored.
To give a second heads up, the plugin will notify the users whenever they’ve set an invalid file:
Obviously, this is a bit more aggressive in letting them know. Sure, they can still submit the comment, but if they complain that their image isn’t showing up, the author can say “don’t say I didn’t tell you so :).”
Kill The Feature Creep
To say that Comment Images For WordPress is lean is an understatement. There’s not a single option for this plugin – it’s either on or it’s off.
I’m a firm believer in having a strong 1.0 and then iterating based on user feedback. For example, issues that I considered introducing:
- Allowing users to select where the image is displayed. Right now, it’s below their comment
- Allowing the administrator to give users the ability to upload multiple photos
- Giving administrators a thumbnail view of the comment image in the dashboard
- Improving the positioning of the upload field above the ‘Post Comment’ button
None of these made the final cut, but why should they? I think a strong case can be made that it’s adding features that may not ever be needed or be used.
In fact, users may want to see something that I can’t anticipate. So I’d rather lay a foundation of features that I know will be used, rather than introduce a variety of featured that may never be used.
At this risk of sounding cliche, less is more and it’s always easier to add than take away.
A Word About JetPack
Currently, the plugin does not support JetPack – that is, it only works with the standard WordPress commenting form. This is by design.
Though I’d love to introduce support for JetPack comments (and have an idea on how to do it), I opted not to include it in this particular release as I want to make sure that the time spent won’t actually be lost.
If the plugin receives enough downloads and/or interest, then it’s of high priority for the next version.
The Usual Tools
As with much of my recent work, I used the usual set of tools:
- Coda 2 for my IDE
- CodeKit for LESS and JSLint
- Staging Environment for testing it in action
- Cornerstone for Subversion
That’s it! From the ideas, decisions, trade-offs, and tools that I used. Feel free to leave any questions, comments, push backs, or whatever in the comment thread. I’d love to hear you guys’ thoughts on this plugin and the work that went into it.
Leave a Reply
You must be logged in to post a comment.