Oops, I did it again.

The big news in 2006 was getting the site out of Flash and onto a CMS so the owner of the Villa could manage the content himself.  After 5+ years, however, the design was showing it’s age and the site wasn’t performing as well in search engines as it used to.  Earlier this year we set out on a redesign effort to address both of those issues.

For the visual design I enlisted the help of Erwin Heiser of Stookstudio. Erwin is an old ExpressionEngine friend and I felt his clean, elegant and international style was a good fit for this project.  For better input on a search strategy I enlisted the help of the East Lansing, MI based NetVantage Marketing.  The folks there helped with getting some baseline analytics in place and doing some keyword research that I used to put the overall architecture & strategy together.  New photography was a key aspect of this effort and the client sourced a local provider in Italy for that work - with great results.  The imagery really carries the site from a visual perspective.

Part of the overall strategy was also launching some one-page sites based on the targeted keywords that the initial research drove out, so along with the main site launching we also put live:

TheVillaBellini.com
WeddingsLakeComo.com
Luxury-Italian-Villas.com
LakeComoVillaRentals.com

All of these domains are run out of one installation of ExpressionEngine using the Multi-Site Manager for separating out content on the back end. This whole multi-site approach is arguably a bit experimental.  We’ll track where traffic goes and make changes to the overall approach based on success or failure in any one area. 

Thanks to everyone involved - nice to get this live before year-end!

The site design is by Grand Rapids, Michigan based Visual Hero and the front-end code was done by Andy of Ford Interactive out of the Sacramento, California area.

The project was an interesting one for a number of reasons:

EE1 - EE2 Upgrade
The previous version of the site was built in ExpressionEngine 1 by another agency. This meant that not only did I have the challenge of an upgrade, it had to be done to a site that I didn’t build initially so wasn’t as familiar with.  I won’t lie - the process was tedious and did take a couple of attempts.  I kept notes during the process and plan to write an article on Train-ee outlining my approach.

New IA
The driving purpose for the redesign was that MorganFranklin had changed the way they thought about and described their business.  This necessitated an information architecture change on the site which in turn meant that the content structure in the existing EE backend no longer had a close relationship to the front-end.  Further compounding the challenge here was that site had a decent amount of content and based on the project timeline the goal was to do as little content re-working as possible.

The solution?  An add-on!  (I’ll pause here while the collective EE community recovers from shock).  In this case the Taxonomy Module from developer Iain Urquhart successfully bridged the gap between backend content structure and front-end navigation structure while giving the client a new sense of control over their navigation.

New Template Code
While the content stayed relatively stable I re-worked the entire site from a template code perspective in an effort to be more DRY.  I still want to do a more detailed benchmarking report (and some things may still change for performance reasons) but the number of templates went from 113 to 41 and the number of channels from 17 to 11.

Built on the Fly (but not like that)
As you may or may not know, I spent the last year travelling the US by RV and I worked on this site during that trip.  Near as I can tell this is a “21-state website” getting worked on from Georgia to the west coast, then up to Washington and back across the plains to Michigan. 

Thanks to Visual Hero and Ford Interactive for their part in the project, and thanks to MorganFranklin for being flexible and working with a mobile developer!

Experienced User?
I’d like to know more about your use of the module, what problem you feel it solves, and how you educate your clients around it (vs the content that doesn’t use it).  Have you used 3rd party addons in conjunction with it and if so, which ones?  Have you run into issues with it that needed workarounds or additional addons to solve?

Confused Newbie?
Have you looked at the Pages Module and just don’t grok it?  What requirement led you to looking at it? Did you install it and experiment?  What didn’t make sense to you?

You can either reply with a comment here or by emailing me using my contact form

The finished article will appear on Train-ee with full attribution for quotes, etc.

Thanks!

For example, the site has many field groups where there are 6 relationship fields to determine sidebar content, and the templates have 6 sets of conditionals looking for content in each one before returning markup.  I want to convert these to single Playa fields.

However I also see very large fieldsets where I suspect a number of the fields are empty and I’d like to strip out unused fields.  I know I can create a quick template with all the fields in it for a quick inspection, but it’s tiresome with so many fields.  I know I can drop to the MySQL level and write some queries, but I imagine this need isn’t specific to me and think an addon might be a great solution here, especially as more of us work on upgrading & refreshing older ExpressionEngine site builds.

So what I want is a addon that will tell me:

• Channel name
• Total number of entries
• Totally empty fields by name
• Populated fields with a count of entries that have content in that field

Example:
Channel: Our Staff

Empty Fields:
Job History / {job_history}
Previous Employer / {previous_employer}
Photo / {photo}

Other Fields # with content / total entries
Title / {title} - 57/ 57
Name / {name}  - 57/57
Full Name / {full_name}  - 12 / 57
Spouse Name / {spouse_name} -  2 / 57

Finding field cruft is my immediate issue, but wonder if an addon could look for all system cruft in addition to unused fields?  Unused channels, unused templates, pending member accounts, etc?  And then more than just reporting them give tools to manage right from a centralized interface.

Easy to wish…;)

Working on the road has been a challenge - but one that I’ve greatly enjoyed.  I’ve been on conference calls at highway rest areas, did work for clients while in somewhat remote New Mexico campgrounds, alternated work with daytrips to places like the Grand Canyon, and have had days not go well because an expected visit to a local library didn’t find a comfortable seat or reliable wi-fi.  I’m writing this post from an RV park outside of Durango, CO where it’s currently 40 degrees and snowing - which is causing us to rethink our plans to go both north and higher in elevation. 

I expect at some future date I’ll put together a more complete post on the up and downsides of being a “technomad” - but suffice to say for now I have a hard time thinking about going back to life as it was, working in my basement office back in W. MI with its little ground-level windows with views of my grass.

I couldn’t have lasted this long in business without owing thanks - to God, my wife and family, many clients & students over the years, EllisLab, and the great ExpressionEngine community. 

That’s a big question, and in reading the thread the only immediate thought I have is I’m glad that it’s Leslie Camacho’s job to figure it out and not mine.  One of the bigger reasons I feel for Les is that the decision is largely a business decision, one that needs to be made in the context of the EllisLab business model. Not to say that user & customer input isn’t important - EllisLab is asking for it and I’d encourage you to respond.  I’ve already coordinated some conversations between clients and EllisLab and had some great feedback from both sides.

That aside, my name was brought up in the thread as a provider of learning materials for EE and I wanted to respond to a couple of points.

EE forum user Strudel posted the following:

I feel what’s missing for some of us is a reference so that if I want to know how to do X, I can just look it up under “here’s how to accomplish x”. The problem with the resources I’ve used is that they are tutorials to building a whole site, and so just looking up a procedure is not that easy.

I can’t speak for the other authors, but for myself the only possible way to write an EE book was to do it in the context of building a specific site.  I know - all too well - that the minute you choose one type of site to cover in the book that by definition you aren’t covering a thousand other type of sites But understand that writing a book is a huge project.  I didn’t track my book-writing and production hours specifically but I’d say it was about 6 months of work (and that was for a re-write). In addition to my hours my wife followed behind me, doing not only copy editing but also working up the project site and finding any technical issues.  Because of the step by step, layer by layer aspect of the site any issues could be small or at times could require reshuffling content in multiple chapters.

In addition to the sheer scale of producing the work there’s also the opportunity cost and business risk.  Time spent working on the book was time not spent immediately doing client work or having family time.  There’s the context of the project - in which we were also getting ready to take our lives on the road for an extended RV roadtrip.  My kids were unfortunate victims for a few months, having lots of unscheduled time while MsBoyink and I were distracted.

Mind you, I’m not complaining.  Getting the book done has been rewarding both from a personal and financial perspective.  Rather, what I’m trying to say is that the task of writing an all encompassing “reference manual” for ExpressionEngine where each tag is broken down and examples are given for every parameter is simply too overwhelming for me to ever think about writing.  When you think about the number of tags and parameters, and then the ability to use them together in almost unlimited number of ways, solving a given challenge in multiple ways that all might be “right” depending on the site, the client, and the developer I can’t even begin to imagine how such a book might be structured.

Another challenge at play is ExpressionEngine has a diverse audience ranging from designers who only know Dreamweaver to experienced developers used to rolling their own CMS. Due to that diversity I’m not sure one reference book could ever satisfy the needs, expectations and learning styles of everyone needing such a resource.  Different audiences with different expectations suggest different solutions.

Once published, any such reference would need its own support channel.  I can handle that with my current offerings because the scope is well-defined.  If your question isn’t directly related to the materials in the book, then I have other support resources to point you to.  A “master reference” would essentially have no such bounds, so I’m not sure what the support model for it would be - but it feels bigger than I would want to take on.

So, no great solutions on generating that master reference here - but I thought I would at least provide a perspective that maybe few others in the EE community have.  There may be another EE book in me but it will definitely be in the context of how to build another specific site (the build a church site series could provide the material).  It’s just the only way I can get my arms around it again.

Strudel also wrote:

I’m also completely open to buying such a book (but please, if I buy the bound book, please include the PDF edition with that purchase!) if it really fulfills this need (even with double monitors I find it handy to have a book open by my side).

Minor technicality, but my books are self-published through Amazon’s CreateSpace offering, which (from what I could tell) offered no way to sell a print/PDF bundle.  Sales reporting from Amazon doesn’t include buyer info, so I can’t easily provide the PDF after the print sale.  And - my gut feeling has always been that if you derive benefit & value from something then you shouldn’t mind paying for it.  If the PDF or ePub version provides you extra value past owning just the print version then as the author I’d like to see compensation for that value.  Maintaining multiple versions isn’t fun.

I’m a one-man shop with a mortgage and family to feed just like many of you…and so far I’ve yet to find a gas station willing to trade fuel for a book..:)

While the topics, styles and audiences were different across those classes, there was a common theme communicated by the instructors:

Show, don’t tell.

In other words, rather than writing:

The kids boarded the bus and had a fun drive to the beach.

Try instead:

The kids boarded the bus, and along the way pointed out the windows, chatted with their neighbors, tossed beach balls around, and bounced on their seats until the bus reached the shore.

Granted, that’s no prize prose, but you get the idea: rather than tell the readers that the kids “had a fun drive” you show the fun by including a number of details about the drive.  The reader is led to and feels the “fun” more richly than just being told “yea, the kids had fun”.

So - what’s this have to do with ExpressionEngine?

Today saw another post covering “must-have” ExpressionEngine Addons by the good folks over at MetaQ.  If you haven’t run across them yet, MetaQ have published some great EE-related articles over the last few months - I’ve forwarded on their Never Fear: EE is here document to a potential client investigating ExpressionEngine and received quite a favorable response.

And MetaQ isn’t alone - a quick Google Search returns a number of posts from people listing their “favorite”, or “essential” or “must-have” ExpressionEngine Addons.

And I don’t mean to pick on the authors of these posts - quite the opposite really.  Rather than denigrate their work I want to use it to inspire myself - and possibly other EE developers - to take things a step further.

Let’s show, rather than tell.

Rather than simple lists of ExpressionEngine addons that we like and think others should use, choose one addon and show how it works.  Show how you used it to meet a client requirement.  Show the site you used it on.  Show what it allowed you to do that you couldn’t do otherwise.  Show some sample code.

Lead me as the reader to see why you consider this addon a “must-have”, rather than just telling me.

The end result will be more valuable because it will more fully detail why you are such a fan of a particular addon.  It will also serve more as tutorial for people new to the addon and to ExpressionEngine.  Features and benefits we can usually get from the addon developer’s marketing page - what we need more of are solid examples to learn from and build on.

But I can’t post this without putting my money where my mouth is, so I’m challenging myself to create such a post for Train-ee over the next couple of weeks.  Maybe first in a new series?  We’ll see.  But let’s at least get things going.

Anyone with me?

EECI2010 | Mike Boyink from EECI Conference on Vimeo.

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.

So I’ll do a fun little giveaway.  For the next week leave a comment with the city/airport you think I’ll be flying out of.  If you turn out to be the first person who guesses right I’ll either send you a print version of my ExpressionEngine 2 Book, or donate the sales value to a charity of your choice.

Need some help?  Remember that we left in late September last year and review the map of our travels so far.