Boyink! - Spring Forward on the Web

The other day I posted the following on Twitter:

Continually frustrated that addons are the first suggestion for functionality that can often be pulled off with native code.

This tweet kicked off a busy discussion that really just proved (yet again) that, while Twitter can be a great tool for communicating sometimes, other times a quick tweet can just create a hotbed of misunderstanding.

So let me say what I really meant:

Continually frustrated that addons are the first suggestion for functionality that can often be pulled off with native code.

Hmm.  Not that different.  Let’s dissect what I did say:

Continually frustrated

Yes, this is a frustration of mine.  I have a somewhat unique position in the EE community in that I teach more people to use EE than most other EE developers.  I’ve had many students come to class with either preconceived notions about EE given to them by previous experience with other CMS or by the EE community in general.  I get students coming in with a site built by someone else now tasked with taking it on both from a content management perspective and system management perspective. I’ve seen sites loaded up with screen after scrolling screen of plugins, extensions and modules - with no documentation of their use from the developer. I’ve had to evaluate sites loaded up with both commercially available add-ons and custom-developed add-ons, and tell the client that it would be easier to re-create the site in EE 2 than it would be to migrate it.

I often think about how much more quickly I could get someone up to speed on EE if they came in with good HTML & CSS skills but no other knowledge about EE.  Sometimes I need to tear down their preconceived notions so that I can lay a foundation for better development approaches with ExpressionEngine.

addons are the first suggestion for functionality that can often be pulled off with native code.

In my time on Twitter and in the forums I often see newcomers to EE ask a “how do I” question and the first response they get is that they need an add-on.  I’ve always thought - and taught - that they should look to see what they can do with native code first and start there.  Why?  Simplicity.  If the desired functionality is achievable with native code to the point where the end client is happy with the approach and outcome then this is a win for everyone involved.  The install, the support model, and future upgrades are simpler.

Now let’s talk about what I didn’t say.  I did not say to never use add-ons.  I did not say any and all functionality could be always be achieved using native code.  I know there are parts of EE that benefit from add-ons.  I use add-ons on most of my sites (but do note this interesting response from Les Camacho of EllisLab). I appreciate the aftermarket for EE and the greater degree of client projects I can do using EE + add-ons.

I simply meant what I said.  First look to native code for a solution.  At least figure out if EE can do what you need without an add-on. This decision will obviously be a quick one where the required functionality is large (the site needs an eCommerce section that can accept credit cards) or not so quick where the task at hand is much smaller (the client wants to manage meta content for SEO purposes). 

If for your particular need the choice isn’t immediately clear then take the time to model a solution using native ExpressionEngine code.  Get feedback on it from your client.  If then for any reason you or your client aren’t happy with the results by all means look to an add-on for a more advanced or elegant solution.

However - keep in mind that no one in the EE community is formally vetting add-ons.  Being listed on the Devot-ee.com is no indication that the add-on was written well, by someone intimate with EE, with security and scalability in mind, that you will get any sort of support from the developer, or that it will be available next time you need it.  Some add-ons are created by developers new to EE and possibly just not aware of existing ways to produce the required functionality.  Other add-ons are created by developers to satisfy needs or clients that aren’t exactly your needs or your clients. 

This add-on will become part of your work, your deliverable, your abilities, and your face to your client.  Be smart about taking on that risk.  A good add-on can make you look like a hero, a poor one can make you the villain.  Being careful about this process is part of being a responsible developer and business person.

Comments are closed, but you can read the comments other people left.

1. Steven Grant on March 15, 2011

   I thought you got a bit of a hard time from what I saw on Twitter the other day.

   I think you’re right, an addon should only be used if there’s no other way to achieve a solution using native functionality.

   People seem to forget as well that addons can impact on the performance of an EE site as well (Joel Bradbury’s presentation at EECI showed that very well).

   There’s only 2 addons I use by default, 1 is essential and the other is personal preference. Every client I’ve had has asked for WYSIWYG so I throw that in by default now.

   The other is Structure - it’s not essential but I find it makes for really rapid development and clients love being able to see their site in a tree structure.

   Other than that, other addons should be on a project to project basis.

2. Boyink on March 15, 2011

   Thanks Stephen - I’m still not clear why the hyperbole machine kicked in so quickly around that tweet. I suspect though that when devs hear the word “add-on” they immediately think of all their favorites - the ones they can name off the top of their heads and that have really been game-changers for EE.  Pretty much I didn’t mean those…;)

   I also suspect that the by and large the EE folks on Twitter are the ones really pushing EE and doing the most complex sites and hence the most likely to be needing add-ons to get the job done but are likely not representative of the “average” EE user (witness Leslies tweet).

3. Sean on March 15, 2011

   I haven’t done any super complex sites in EE yet and really only have 2-3 add-ons that have made every build. A wysiwyg editor (wygwam), imgsizer, and trunchtml.

   I did notice an addon devotee recently that replicates the switch tag and I wondered why. Perhaps it does something that I didn’t see in addition to that. However i don’t think so and also feel that is the type of add-on that Mike is referring to.

4. Rob on March 23, 2011

   One of my favourite quotes when talking about EE is “EE does stuff out of the box that other system need plugins for”.

   When assessing a new EE site build I never even think about addons, it’s only when I come up to a problem it’s when I start even considering them, and even then it’s after looking hard and seeing a particular thing isn’t possible without.

   I think we all know where this mentality originates from - they begin with “W” and “J” :)

5. Boyink (Author) on March 23, 2011

   Hey Rob -

   Thanks for the comment. Sounds like our mindsets are quite similar.

6. Rob on March 24, 2011

   Ha ha - same mindsets yes!

   Another thought struck me last night is the fact that getting to know how flexible EE is does take a while.
   Anyone using it for the first time won’t have had many “lightbulb moments”, and hence it’s easier for them to reach for an addon to solve a problem, rather than think things through and play with the existing toolset.

   I don’t think you can necessarily “blame” anyone for that because it’s the mindset they’re probably used to working with. That said, does that sort the the men (developers) from the boys (plug n play)?

7. Boyink (Author) on March 24, 2011

   Hah - ain’t touching that one…;)

8. Ira Salsberg on May 11, 2011

   Hey Michael,

   As usual,  much respect,  and I totally disagree with your hypothesis. ;)

   I think perhaps the hyperbole and vitriol that result from a tweet like this,  comes when people are thinking about the product in a philosophical way,  rather than a contextual way.

   The context is the type of sites that you typcially build,  using EE as the CMS / Framework.  Designers/Developers/Agencies tend to have a niche specialty in the type of sites that they build,  some smaller and more straightforward,  some much more complex.

   I sometimes speak/chat/tweet with other EE devs who work on 30 or 40 sites a year.  At The Red Eye,  we develop around 1 or 2,  with at least two people working full-time 80 hours weeks, year-round.  These are incredibly complex sites,  and many require 12 to 30 addons to achieve the required functionality.

   I’ve been working with EE for about 5 years exclusively,  so it’s not that I just can’t figure out how to achieve something natively.  And this is what your tweet tends to imply,  while your post clarifies that quite a bit.

   According to Leslie though,  I am in a very small minority who need addons at all,  which is surprising,  but does help contextualize the issue.  During the early Private Beta for EE2,  I asked why many core features from EE 1.x were left untouched / unimproved (eg:  Categories,  Pages,  Field Groups, etc),  and why many critical features left out completely (Forms, Taxonomy, Nested pages a la Structure,  Matrix style functionality,  etc).  The answer from EL was that moving forward,  they wanted to actively foster and promote the 3rd party addon developer community,  and that such feature improvements would better be served by that community.

   If Leslie’s correct,  then this isn’t an issue,  because the majority of the user base is building less complex sites,  and don’t require extended functionality,  such as:

   - WYSIWYG Editor
   - Structure (nested content structure,  with Client friendly content structure view.  Clients shouldn’t need to have a ‘lightbulb’ moment like we did.).  Sure,  there’s the Pages module,  but this is a total kludge in terms of functionality and UI compared to Structure.
   - Complex Categories (Any complex site using native categories,  almost always requires at least 3 or 4 addons to properly handle cats on the front-end)
   - Taxonomy:  Complex and content rich sites need to be able to relate entries via keyword (Tags Module).  This cannot be coded using native categories,  without additional addons,  and many extra custom queries
   - Multi Language:  More than one language on the front-end?  If it’s going to be user-friendly in the CP,  and work properly on the front-end,  you are looking at at least 1 or 2 addons to help
   - Search:  Thousands of entries?  Dozens of Channels?  Forget the native EE search,  which quickly shows its limitations and lack of flexibility
   - BRANDON KELLEY’S BRAIN.  Nuff said,  this is missing from the core,  and we’ve found that all of his major addons are necessary to implement our required functionality.  You could not rely on native relationships on a complex site,  unless you hated yourself and your clients.  Matrix is a must.  WYGWAM essential (+ a file manager replacement for images/files embedded in content).  Playa. Period.
   - CP:  For EE 1.x sites,  there are at least half a dozen addons that we need to install,  in order for the CP to be more user friendly (Publish Improve,  Edit Remember,  grouped weblogs in the publish dropdown since there are 20+ channels,  edit ajax,  hidden weblogs).  Unlike many people,  I find that a lot of these issues HAVE been resolved in EE2,  but still use a few plugins to improve the UI in some areas.
   - Image manipulation:  Simple sites can rely on a few image size standards.  Complex sites often need to use one image in several places (eg:  Entry Banner Image,  reused and resized on splash pages,  call-to-action boxes,  etc).  ImageSizer or CE Image required to automate this for the clients,  and allow them to upload only one image.
   -  Files:  EE 1.x and EE 2.x (including Beta 2.1.4) fall VERY short in the file/image upload area.  Third party addons required,  for the uploads and management to be user friendly
   - Downloads:  No native way to protect and track software or file downloads.  Add a couple of addons.
   - Forms.  Got forms?  What large site doesn’t have a myriad of required forms.  Enter another addon, Freeform
   - Members.  Does the site require control over the base member functions and more complex template functionality?  Enter Solspace User.
   - Need a gallery per entry?  You could shoot yourself in the head and try using the native Gallery module (1.x only),  or enter Channel Images,  where your clients can easily grok how to add multiple images per entry
   - Low / Fresh Variables.  EE’s insane parsing order issues making it impossible to get the result you need?  If your templates require complex conditionals,  and you want to avoid ONE INSTANCE of the template parser to be run for each embed…  Enter these addons
   - Need some other custom integration for your client?  We often do,  so on top of all of the above,  you can count on at least half a dozen complex, custom addons,  for integrating other systems and data sources.

   And I haven’t even included all of the addons we normally require,  for the types of sites that we build!

   That said,  I am certainly not complaining.  We use EE not in spite of the above,  but BECAUSE of the above.  Someone else tweeted,  that ultimately,  this topic depends on HOW you use the system:  As a CMS or as a Framework for build a CMS for your clients.  I couldn’t agree more.

   We fall into the latter,  and love EE because of this,  and because of an active,  like-minded 3rd party addon developer community,  who have faced similar challenges in building complex sites,  and made their solutions available for purchase.

   Again,  I may be in the minority,  but this is why I think that tweets like, “why use addons?”  stir up some strong emotions in a certain part of the community.  It implies that we are somehow lazy,  plug-in addicts,  of the Joomla/Wordpress mindset.  It’s just not accurate,  and is vaguely insulting to people pushing the bar in EE site development and implementation.

   Bro-hugs,  and much respect,

   Ira

9. Boyink (Author) on May 11, 2011

   Hey Ira -

   Not sure what brought up this one again? :)

   Yesterdays add-on related tweets were around just looking at the number of them that were available and using that - somehow - to gauge the value of a CMS & compare it to others.  I don’t think that’s a valid rubric. 

   I actually don’t think I would be opposed to your use of them - this comment actually starts to go down the “show, don’t tell” path.  Just dress it up with some screenshots and links to example client sites and it’d be gold..;) 

   But it does reinforce my overall frustration with addon recommendations—in that they are given (either by “must have addons” blog posts or mentions on Twitter) without context.

   The guy asking for certain functionality might be one of those 30-40 small/simple brochureware site guys and getting recommendations from the 1-2 really complex sites a year guys. 

   It’s repeating the “Show, Don’t Tell” post - but it’s that context I’m really interested in.  I think as a community we need to “show our code” more - and even push that to showing our backend structure more.

   If we filled in more of the picture and told more of the story about the site, how it’s built, what it needed to do, and how addons were a part of that I think everyone would benefit.

   And maybe I’d tweet about something else…;)

10. Ira Salsberg on May 11, 2011

    I blame Twitter. ;)

    Back in the day,  when the EE forums were much more active,  one took the time to explain the full details of their issue.  Forum posts that started with “I’m a total newb”,  and “how do I…” could usually result in one of us seasoned EE users pointing to a user guide link.  Or asking a follow up question,  “Have you tried…?”,  and base our response on a more thoughtful assessment of the situation.

    With Twitter,  and twitter style posts making their way to the forums,  I think we’ve lost a bit of that,  and certainly removes a lot of the context from the Q’s and A’s.

    But I do think my reply above is ultimately related to both the previous “Show don’t tell” post, and this one as well.  All too often,  the Third Party solution IS the more appropriate solution,  because of the way the native solutions are initially developed and then somewhat abandoned (no new feature updates by EllisLab. Eg:  Gallery, Forum,  Categories,  Pages,  etc, etc…).

    Ultimately I guess we do agree.  I suppose my comment was in response to some of the tweet replies and other comments.

    Cheers!

11. Anna Rebbeca on March 11, 2012

    Here’s a total noob question. What functional purpose does a word limiter provide? I was looking at this extension the other day and was wondering how it could be of benifit. Thanks.

12. Boyink (Author) on March 12, 2012

    Hi Anna -

    See my home page, rightmost column, bottom portion of the page?  That paragraph is from my latest blog post. In that spot I want more than the title, but less than the full post. My choices are to either have a specific field to store the portion of the post I want on the home page, or create it dynamically.  The word limit plugin is used there to create it dynamically.

Back to Article