Design

Why I don’t use the Structure module

By | Monday, June 6, 2011 Filed under Design
36 comments

While clients and potential clients are welcome to read this Blog entry, it is primarily aimed at Web developers familiar with ExpressionEngine, so it gets a little technical.

There seems to be a lot of debate within the ExpressionEngine community about whether to use the Structure module by Travis Schmeisser and Jack McDade.  Some believe that it makes content management simpler for end-users because it organizes content in the control panel in a list of nested pages.  I’ve built some sites using Structure and although I’ve always received top-notch support from Travis, I’ve concluded that it’s not for me.  This post explains why.

Problems I’ve encountered with Structure

  1. The last time I used Structure, it only allowed for two levels of depth in the navigation tag.  This became a real problem once my client decided - after the site had been built on Structure - that she required three levels of depth in some sections. 
  2. Structure also didn’t allow for multilingual design.  I often work with Canadian non-profits who need their sites to be fully bilingual, but Structure’s navigation menu tag uses the titles of entries to label the menu links to those entries. So it didn’t matter that I’d created a custom field to hold the French title for an entry; Structure wouldn’t let me use it in the navigation.
  3. This also means that my menu links had to be labelled the same as their corresponding entries.  Most of the time this is standard procedure, but non-profits often have elaborate but official event names like “The 2011 Annual Professional Conference and General Meeting.”  Despite this, they usually want the link to be labelled something more succinct and recognizable like “Conference.”  With the Structure module however, the entry and the link to it must be the same.
  4. I sometimes like to link to a page from two sections of the site.  The only way to do this with Structure is to create a false entry whose only purpose is to launch a template that contains nothing but redirect code that sends the visitor to the true entry.  Imagine how confused a client would be if she opened up the false entry thinking it was the real one only to find a blank publish form!

The real problem

Granted, many of these particular issues may have since been resolved in subsequent Structure updates [EDIT: Indeed some have, as Jack explains in the comments] but the real problem was a realization that I had upon encountering those ones: Structure is a commitment.  If I invest in the Structure module to organize my content, there’s no turning back.  If I encounter a roadblock during development and decide to abandon the module, I’ll need to completely re-code my templates and re-train my client on how to manage content.

Let ExpressionEngine be ExpressionEngine

Another gripe I have with Structure is that it undoes a lot of what I like about ExpressionEngine.  Structure’s philosophy holds that even within the control panel, your site content is a collection of pages.  Sure, this may be familiar to clients since they already see the front-end of their site as such, but I would argue that that’s a problem in itself.  In suggesting that a site’s content is a collection of pages, you reinforce the idea that content resides in one place and not in another, like the pages in a book.  If a character dies on page 200, he does not also die on page 50.*

I’ve seen clients get confused by the listings vs. pages thing and add listing entries as child-pages:

image

When you consider that they understand their content to be a collection of pages, it’s not surprising that they would do that. 

Besides, there are plenty of CMSs that display content in the control panel in a page-tree format.  If I wanted that, I’d use one of those options.

I prefer to teach my clients a philosophy that is at the core of ExpressionEngine: That a site is a made up of content, not pages.  In ExpressionEngine 2, EllisLab wisely named content containers Channels, implying a stream of information without position.  Some EE developers had previously - and inaccurately - suggested the term Sections, which implies location.

On the Web, something can exist in several places at once.  When you add a News entry, you’re not creating a page, you’re simply adding that content.  Where it appears on the public-facing site depends on how we’ve designed it.  It may appear in the News section, on the Home page, and in the footer of every page.  The Structure module unravels this notion.

Alternatives

One real problem with EE that Structure attempts to address is that there is no easy way to allow non-technical clients to manage navigation menus.  I am currently handling this with Booyant’s add-on NavEE.  While it’s not perfect, it does what I want it to and nothing I don’t. 

NavEE doesn’t hijack ExpressionEngine’s content management architecture.  I can still teach my clients to add content using the appropriate channels.  NavEE just lets them create links to that content.  And since it only recognizes entries that use EE’s native Pages module, there’s little danger of them confusing listing entries with pages.

Like Structure, NavEE displays its content in a nested list, but in this case it’s appropriate since the display reflects the front-end navigation menu itself and not the back-end content.  Using NavEE, I haven’t experienced any of the problems I’ve encountered with Structure as mentioned earlier.

NavEE is also an add-on in the true sense of the term: it is added on to the CMS, and thus can easily be removed if needed.  If I decide NavEE is not the right solution, I can relatively painlessly extract it from my site and go in another direction.

Conclusion

Whatever technique you use to manage content and navigation on your ExpressionEngine sites, it’s good to know that there are great add-on developers out there like Travis, Jack, and Mike who are working to make EE better, and I’m grateful for that.

* Zombies excluded.

Comments

Gravatar of Brian
Brian 

From United States
Monday, June 6th, 2011 at 5:11pm

It must have been a really long time since you’ve used Structure. It definitely goes more than 2 levels deep. Its infinite. The 3.0 version also lets you use navigation titles based on a custom field of your choosing. Granted, it may not be for everyone, but your first 2 cons are not applicable anymore.

Gravatar of Boyink
Boyink 

Monday, June 6th, 2011 at 5:19pm

Thanks for this article - I just haven’t had a good site to use Structure on so can never speak authoritively on it, so it’s good to hear from someone who has.

The “content vs. pages” thinking resonates strongly with me - and is a very key piece of what I’ve always covered in Train-ee classes.  I’ve always felt that one of EE’s greatest strengths was getting rid of the notion of pages as content storage containers.  It’s a tough paradigm to break out of, but once you see past the page EE really shines.

Gravatar of Jack McDade
Jack McDade 

From Albany, New York
Monday, June 6th, 2011 at 5:22pm

1. Depth. This one is actually completely FALSE. Structure supports unlimited nesting with a wide plethora of tag parameters to let you carve the output up 9 ways from Sunday. ExpressionEngine itself has a 10 URI limit (e.g. this/that/the_other/another/yet_another/a_sixth/seventh/eighth/ninth/and_tenth/), so naturally Structure would from a routing point of view.

2. Also FALSE. A number of people have some really creative and POWERFUL solutions for Multi-lingual sites. The guys at EE Harbor (http://eeharbor.com) actually have a module coming out with an explicit Structure integration. Many, many options here, especially with Freebie.

3. This too is now FALSE. The tags now support a new parameter, channel:title. All you need to do is specify which field(s) you’d like to be used as the title and VOILA! All set! They will fall back to {title} if they haven’t been set in a particular entry.

4. This one is mostly true, for now. The next major release will have new link types AS WELL AS optional multiple and independent nav groups (e.g. like NavEE). You’ll be able to add links to anything and everything as you wish.

and finally 5 (The REAL Problem). This is true and not true at the same time. While you should definitely do some research before embarking on a huge site build, everything Structure does is based on Entries, all of which can be reordered in a number of ways. Coming soon, Structure will also support more granular control over “dynamic” content like listings and assets (if you so choose). But these are merely organizational controls, not architectural ones.

Nothing Structure does completely hijacks anything ExpressionEngine does, it merely controls your nav more rigidly and (some might say) properly, when it comes to Hierarchal content. It allows much MORE flexibility in many cases, as single templates can be easily reused at will, throughout the site, regardless of template_group.

Anyway, that’s enough for me! I hope you read my whole comment before making your conclusion. However, Structure ISN’T right for every site! I’ll say that right now. Just lots of them smile

All the best, keep EE-ing!

Gravatar of Natetronn
Natetronn 

From San Diego
Monday, June 6th, 2011 at 5:27pm

This is a great writeup!

And to be honest this talks allot about why I currently do not use Structure either. I too think the support that Travis gives is top notch and they have put allot of good work into their add-on. After really wanting to make it work, I did however decided that Structure it just to well…structured for my tastes.

I think the word “channel” is great. You can explain it to your clients in terms of television. If you want your viewers to see news then you as the publisher need to add content to the news channel. If you want your viewers (or traffic) to see images in your gallery you need to add content to the gallery channel etc…

I also use NavEE and it does work as expected. Even created a crazy drop-line menu with the help of Mike over at Booyant which was amazingly complicated for me to get my head around though, I can imagine now after that experience NavEE can handle any setup that you throw at it.

Gravatar of Chad Crowell
Chad Crowell 

From Novato, Ca
Monday, June 6th, 2011 at 5:38pm

Fantastic article - and also great follow up comments. This is exactly why I chose to talk about Structure vs. Template Groups in tomorrow’s EngineSummit 3.  Full disclosure, we use Structure a lot, but certainly not always. And, we’ve had our share of issues, typically addressed in fine fashion by Travis and Jack. We’ve found that clients are much, much happier to work in Structure than the default EE entries listings and that it greatly increases the CP usability. As you noted, there are training issues- but we’ve also done a few project *only* geared around taking a typical EE site and getting it into Structure, and every client has found the difference a great improvement in knowing where their content lives so they can add/edit it. Again, great article.

Gravatar of Travis Schmeisser
Travis Schmeisser 

From Brooklyn, NY
Monday, June 6th, 2011 at 5:46pm

Thanks for the writeup and comparison. It’s always good to get people’s feedback from outside our team and seeing what is and isn’t working for people. Jack has covered the main points you addressed and why they’re either are off-base, no longer existent or in the works for being resolved.

I think part of the issue and maybe the disconnect is that I’m not sure why there’s an “EE way” to do things. One of the amazing things about EE is it’s flexibility and that you can accomplish things in many ways. If anything, Structure makes it quicker and easier to build within as pages can share as many or as few templates as you want (same for channels), while using our dynamic tags to build your navigation and sew everything together with little effort. Fundamentally - setup, channels, custom fields, etc are all the exact same as building a normal EE site. You’ll find quite often you need less templates, but that’s about it as far as the “traditional” EE. Structure doesn’t stop you from building anything with traditional methods either, you can use as much or as little of its power as you want. The gains however, through time, ease of use and flexibility far outweigh any reason to stick to template_group/template.

Gravatar of John D Wells
John D Wells 

From London, UK
Monday, June 6th, 2011 at 6:05pm

I’ve hit every brick wall you’ve mentioned and more.  I’ve also overcome them all (OK, one I’m in the middle of vanquishing, let’s hope I maintain my 100% success rate), but it hasn’t always been easy.  Travis & Jack have made amazing improvements as they’ve continued development (Jack nailed those above), and yes occasionally overcoming a hurdle has required the aid of 3rd party addons (like Freebee, Triggers, Structure Entries, etc).

But I sort of liken Structure to WYSIWYGs - us developers might despise the can of hurt they potentially open up, but its the only thing our clients get.  Clients understand tree structures and thick text as bold; clients DON’T understand SEO-friendly, “browsable” URLs and HTML markup.

To be fair I’ve never used the Pages module, but I can’t really imagine teaching my client how to assemble URLs that are consistent, accurate, and otherwise mimic what Structure can do automatically.  Then you throw in goodies like drag-and-drop reordering, and for any medium-to-large website that is largely structured tree-like on the front-end, I would hate to build it _without_ Structure.

I’d highly recommend giving Structure a go on your next site (that appears might be a good fit), just be sure you charge your client well - no addon is a silver bullet… despite Travis & Jack’s every effort to prove otherwise. smile

Gravatar of MediaGirl, Inc.
MediaGirl, Inc. 

Monday, June 6th, 2011 at 7:00pm

I highly recommend Structure and have used it on projects small and large. It’s a different way of building and takes a little time to get the hang of but on certain sites build time is faster IMO. It also gives clients ultimate control over navigation and provides them a one page look at their site hierarchy.

I don’t use it on all projects but I do use it on most here at MediaGirl.

Gravatar of Mike Mella, Be like water
Mike Mella, Be like water 

From Toronto, Canada
Monday, June 6th, 2011 at 7:09pm

Thank for the great comments guys, and for the clarification about Structure’s current capabilities, Jack and Travis.

@Brian (and everyone who pointed this out),
I’m not surprised that most or all of my specific concerns with the module have since been addressed, but as I mentioned later in the post, for me there was really a larger underlying issue, or several.

@Chad,
> [...] every client has found the difference a great improvement in knowing where their content lives so they can add/edit it.

For me, that’s exactly the problem: the location of content within Structure’s tree is precisely not where that content lives, although that’s the implication. When users are required to submit blog listings directly into a page called Blog, how can I blame them for getting confused when they see that post appear elsewhere in their site as well?

@Travis,
I wouldn’t claim that there’s an “EE way” to do things; as you point out, its flexibility is certainly the real benefit.  I’m just saying that EE’s native content management philosophy is what drew me to it in the first place, so that’s not a problem that I’m looking to solve.

@John,
> [...] us developers might despise the can of hurt they potentially open up, but its the only thing our clients get.

This is the mindset that I would challenge developers to correct.  Educating clients about how their site really works allows them to see more possibilities for what can be done with it.  We shouldn’t perpetuate an inaccurate understanding just because it makes our jobs easier.

Gravatar of Ira Salsberg
Ira Salsberg 

From Montreal, QC, Canada
Tuesday, June 7th, 2011 at 9:08am

Nice post Mike,  and always interesting to hear how others are (or aren’t) using these addons.

For what it’s worth,  I thought I’d chime in,  in case this post scares anyone away from potentially using Structure.

We now use Structure at our agency,  for just about every EE project.  Our clients tend to be in the high-end software/hardware industry,  and their sites can become quite complex in terms of content structure and functionality.

Each site usually has numerous ‘splash’ (section landing) pages,  dozens of in depth product pages,  and the usual suspects (Press Releases,  Events,  Media Galleries, Jobs,  Lead forms, etc).  In addition,  many of these types of content need to be interwoven in unholy ways,  and require the utmost flexibility in placement within the Information Architecture.

Prior to Structure,  our typical client site had content that was structured up to seven levels deep,  and this was quite a chore to set up using the “standard” EE methodology,  and required tons of complex template logic (custom php,  embeds, segment conditionals,  etc.).  And I still had to say, “no, we can’t add a form as a child of X page…Forms have to go in the /request/ Forms Section”.  We would end up with two dozen template groups,  dozens of templates,  tons of embeds.  Above all,  this also required our clients to have THEIR ee ‘lightbulb’ moment,  to figure out the EE template group / template / channels concepts.  Defeats the purpose of a CMS in my view.  It should be dead easy for clients to grok how to add/edit/manage their content.

Enter Structure.  Since we began using it,  we are building sites with the same complexity,  but the usability (and even the flexibility) has increased tenfold.  Here are some key reasons why:

Channels and Content
- We still create as many channels as needed,  but now have the flexibility to not only decide if we want to run them through Structure,  but also use Structure to help define their role within the site (pages, assets,  etc)
- Content is king.  Clients should be able to arrange the content how it makes the most sense for communicating their message.  Channels are a great concept,  but the template group / template concept negates this concept,  and tends to force more limitations on content structure within the site.
- URLs.  The nested url structure makes much more sense to us,  and to our clients.  /products/gardening/garden_weasle/features/  is easily understandable,  reflected in the “tree” view,  and can contain different channels per level if needed.   


Structure Tree
- Visually simple to understand the context of their content
- the “Add Child” channel picker allows my clients the freedom to mix their channel entries HOWEVER THEY WANT within their site structure.  This is HUGE.  We limit these options as needed,  but allowing them to add a “redirect” as a child of a “product” entry,  or a “lead form” entry as a child of a “product download” entry, goes way beyond what would be doable using the “standard” EE method.
- While not perfect,  the concept of “Pages”, “Listings”,  and “Assets” is easily understood by clients,  and allows tremendous freedom in content structure
- Dragging to reorder content,  without having to modify any template code is huge.  With the standard EE system,  moving a “section” or reorganizing navigation is tricky,  and requires the assistance of the design agency.  Here,  they click/drag/drop,  and the templates are smart enough to figure it out (remember:  no channel, template_group,  template,  segment conditionals,  url_title parameters needed in templates)
- Context.  The publish and edit menus are rarely touched by our clients.  Everything can be (optionally) managed in one Structure page. And in context.  This is definitely not so,  for the Edit screen.


Templates:  Oh my god,  the templates… 
- Because structure pages are location aware,  the channel tags are much simpler to template (no need for channel=”...” entry_id=”...”,  unless you WANT/NEED to)
- Child pages / Listing pages are easily output as well,  with equally pared down channel tags
- Main and sub navigation is automatic,  and there are some powerful parameters for the Structure menu tags as well,  if you need to customize the output/functionality
- The nav tags are status aware as well,  so “Open: Main Nav Only” is a possibility,  as is “Open: Left Nav Only”. 
- When we start a project,  and lock down the site’s IA,  we can do a live FULL SITE mockup,  including hundreds of (nested, ordered, etc) pages within a couple of hours.  We use ONE channel for this,  and ONE or two templates.  Full working mockup of the site,  including all navigation.
- With similarly complex site structures,  we’re now down to 8-10 structure based template,  all in one group,  compared to many template groups, the hundreds of templates / embeds used on similar sites in the past (pre-Structure)
- Have a crazy one-off template requirement?  No worries,  you can re-assign the template PER ENTRY if needed.  Structure doesn’t force you to use any given template,  but is smart enough to use ‘defaults’ per channel,  based on your preferences


Client site Hand-off / Training
- With a properly implemented Structure/EE site,  the time it takes to teach clients to add/edit/manage their content,  including post training followup questions,  has dropped by 90% since moving to Structure driven EE sites. 
- They don’t need a “light-bulb” moment,  they don’t need our help to re-organize the site,  they just get it, and can work with confidence and autonomy
- Template Group / Template:  Again,  since this is no longer really a main concept,  I am a lot less embarrassed when explaining site functionality to non-technical folks.  When set up correctly,  clients barely even need to about templates at all. 
- If I want to feel ‘special’,  and show my tech-savvy clients what I clever monkey I am,  I could still have an in-depth training session,  explaining the inner workings of the CMS concepts… But really,  they usually hire us to make their lives easier,  and just need a tool to help them efficiently complete JUST ONE of their MANY, many, daily tasks:  updating their site.  YOUR CLIENTS PROBABLY AREN’T WEB DEVELOPERS.  So don’t assume that what draws you to EE,  is what draws them to it. wink


EE or Structure?
Ultimately,  the most important fact that often gets missed,  is that it’s really not a choice of one way,  or the other.  We use Structure.  But this does NOT mean that we give up the ability to use regular EE logic for ANYTHING.  If needed, I can always use native EE functionality,  with or instead of the Structure method/templates/etc.  If I have the need,  I CAN create a simple template_group/template setup for one channel or another.

I also have complete access to the “Structure” entries,  to do with as I please (eg: homepage listings,  CTA boxes,  footer links,  related entries,  playa relations,  etc).  A simple dynamic=“no” or specifying the channel or entry_id turns any part of my template into the “standard” method at any time.

On the other hand,  REMOVING Structure from an existing site would bring on the real Armageddon,  so you should evaluate the site needs before committing,  and see if it makes sense for you / your clients.

Ultimately,  I go with what makes my clients jobs easier,  while giving them the most flexible way to generate and present their content,  based on what their marketing needs dictate.  This is what Structure has allowed us to give them in spades.

Hope this helps anyone who may have been on the fence,  or scared about loosing basic EE functionality. Structure really is a unbelievable extension to the core functionality of EE. 

- Ira

Ira Salsberg,  The Red Eye Design Agency
++++++++++++++++++++++++++++++++++++++++
Some client sites on Structure:
- http://www.presagis.com
- http://www.averna.com
- http://pierrebelvedere.com
- Many more in the past,  and in the works!

Gravatar of Ryan Irelan
Ryan Irelan 

Tuesday, June 7th, 2011 at 11:07am

I think using almost any add-on (especially field types) in your site build is a commitment. This isn’t just in the case of Structure.

Essentially, that’s the game we play when building sites (or writing code). Make as many good decisions along the way as possible to ensure the site is usable, flexible and maintainable in the long term. That involves making a commitment to your own code or someone else’s.

Gravatar of Mike Mella, Be like water
Mike Mella, Be like water 

From Toronto, Canada
Tuesday, June 7th, 2011 at 12:51pm

@Ira,
Thanks for the great comments, and glad to hear it’s worked so well for you.

@Ryan,
Sure there’s always a commitment, certainly with field types, but most other add-ons serve one specific purpose (i.e. NavEE, or almost any field type) and it’s quite easy to determine ahead of time whether it will suit your needs.

Structure on the other hand presumes to “correct” native EE functionality, to control navigation “properly” as Jack himself suggested.  I would argue that it’s not just navigation that it controls, it’s the content architecture.  This is why I used (perhaps harshly) the term “hijack”, and therein lies the commitment.

When I used Structure (I realize it was a primitive version and it’s much better now) I encountered no fewer than four serious problems as a result of the client trying to grow their site after the fact, but due to the lack of flexibility of the add-on at the time, I wasn’t able to help them.

Considering the coding involved and the client training, Structure changes far more about EE than any other add-on that I’m aware of, so the commitment is that much greater.

Gravatar of Chad Crowell
Chad Crowell 

From Novato, Ca
Tuesday, June 7th, 2011 at 1:00pm

In fact it changes nothing - Structure uses the same function as the native Pages module to determine whether it should take control or not, based on the URL.

Gravatar of Mike Mella, Be like water
Mike Mella, Be like water 

From Toronto, Canada
Tuesday, June 7th, 2011 at 1:34pm

@Chad,
I don’t only mean from a technical perspective.  It changes workflow, requires a different approach to template coding, and changes the way content is to be managed in the control panel, and - perhaps most significantly - perpetuates the myth that website content lives in pages.

Gravatar of Travis Schmeisser
Travis Schmeisser 

From Brooklyn, NY
Tuesday, June 7th, 2011 at 1:44pm

@Mike - Website content in pages is a myth? What do your clients call it?

Gravatar of Mike Mella, Be like water
Mike Mella, Be like water 

From Toronto, Canada
Tuesday, June 7th, 2011 at 2:12pm

@Travis,
“Content”! 

I educate them on the subject, and they appreciate that.  As Lea Alcantara once said on the EE Podcast, “A client who feels smart around you is a client who loves you.”

Gravatar of Gregor McKelvie
Gregor McKelvie 

From London
Tuesday, June 7th, 2011 at 3:13pm

I agree in most with this post for the following reasons:

1) EE has it right with channels and not by managing the content by using a site map / site structure (like most CMS systems do). If you need a basic site then there are plenty of CMS systems to choose from, but I think EE’s strength is that it caters very well for medium - large dynamic sites with different publishing owners / producers in mind.

2) I believe the future of websites include channels of content not the standard “about us”, “our services”, etc. structure - these sites will be dead within 5 years. How many static or semi-static sites do you build now?

3) If you are managing a medium - large site then web content skills are paramount. The problem is most clients think managing web content is like writing a report in a Word document. It’s not (and is years away from being). I can understand why clients get frustrated with “creating a page” in EE, but I’d argue that with EE it is easier to post dynamic content than it is in other CMS systems.

Gravatar of Mike Mella, Be like water
Mike Mella, Be like water 

From Toronto, Canada
Tuesday, June 7th, 2011 at 4:06pm

@Gregor,
Thanks for the comments.  Yes, I can’t stress enough the value of educating clients at least a little on how EE’s content is managed, and pulling them away from the notion that everything is contained in pages on the back-end. 

...Call it “Client Progressive Enhancement.” 
wink

Gravatar of Graham Huber
Graham Huber 

Tuesday, June 7th, 2011 at 7:41pm

#1: Surprised no one has mentioned using Structure and NavEE together.

a) While it might seem redundant, what I’ve found is that it’s a nice complement to creating arbitrary nav menus that don’t need to explicitly be tied to site structure. Clients can rearrange NavEE nav all they want without the worry of changing URL structure and breaking pages/links. This is a big, big deal for sites that have already launched.

c) The downside is maintaining two nav trees—but this is mostly a “one-time setup” in initial dev (i.e. your job, not the client’s), with a bit of upkeep here and there if new pages are added.

d) I’m happy to hear Jack mention the next major release of Structure will support more flexible / arbitrary nav structures—maybe using both will not be necessary then, but for now, it’s working well for me.

e) I have to second Mike’s point about potential client confusion. This isn’t really Structure’s fault, but it’s a legitimate worry. Imagine the nightmare of a client innocently dragging and dropping a Structure page in the tree only to drastically alter the entire site’s structure. Yikes. I prefer to lock clients out of Structure entirely and use NavEE + Flexible Admin to point them to the appropriate places to add/edit entries.


#2: Regarding the “pages” myth.

a) I agree with this—the trend is evermore toward “page-agnostic” content—i.e. channels.

b) Structure provides a valuable and flexible hierarchy to model content. As Single Page Interfaces and AJAXified loads become the norm, hard page reloads may become a bit archaic—but content will still need to be organized in context in the URL, much as hashtags are now emulating for SPI.

c) There’s nothing to say you can’t point your SPI / AJAX loads at Structure pages, even just used as an internal organizational tool for making sense of many embedded templates.

d) Note: I haven’t yet built an honest-to-goodness SPI with EE, but have a couple projects coming down the pipe that might qualify… I’m curious to see whether EE’s native channels and/or Structure make this less complex than some of the custom MVC scripts I’ve seen floating around out there (for those who are curious, hack your way around this bad boy: http://www.akqa.com—source: http://www.akqa.com/library/js/akqa.modals.js )

Gravatar of Steven Hambleton
Steven Hambleton 

From Australia
Wednesday, June 8th, 2011 at 12:50am

Our client’s say that Structure (and Low Variables btw) are the best things to happen to ExpressionEngine.

Structure has scope to become even better and I don’t think it does mar the ExpressionEngine philosophy, it compliments it.

With regards to the person that said their client gets confused by posting to Blog but seeing their content elsewhere, I suggest further education. I watch the news on the TV but I don’t get confused when I see it on a website too. Content is distributable but on a site it generally lives somewhere whether it’s by category or section.

We’ve accomplished a lot with Structure including e-commerce, news and corporate. It sometimes gets in our way but we either work around it or move the templating outside and back to traditional EE.

Freebie and Zoo Trigger are two great add-ons which should be part of your arsenal.

I would like to see a section of the Structure site which highlights creative solutions to developer’s problems submitted by the likes of us. It could help overcome any objections if people see a problem that’s holding them back or they can’t find the answer in the documentation.

Go Structure!

Gravatar of Yvonne Martinsson
Yvonne Martinsson 

Wednesday, June 8th, 2011 at 6:15am

I’ve recently come across a site with Structure and, yes, it took all the joy out of EE. It’s like putting a straightjacket on EE, instead of developing the internet. Made me think a lot about this issue. Maybe it’s time to withdraw to some remote island?

But, here we go. Any EE site that is a bit more complex than the ordinary broschure site - for which you EE is an overkill - pages don’t really work. Data returns in many places, maybe even on several sites.

Yes, it’s hard to break out of the pages/print Gutenberg paradigm, of the taxonomic and hierarchical thought of Linnaeus, and the more mainstream EE goes the more we will probably see of this. But that is not the internet; the internet belongs to a new paradigm of dissemination, of distribution and remixability, of data that migrates. This requires a well built underlying structure and data architecture. One that is grown out of the content at hand. Not a predefined, super-imposed one. It requires that the dev takes the time to think it through - that you dig into the development of the internet. There are no shortcuts, no lazyweb. Once you’ve have a good, sustainable install, redesigns and further development of the site is made so much easier - and faster.

And clients? What do they say? Mine at least find my installs well thought through, smart, fun to work in and a timesaver.

Gravatar of Michael Witwicki
Michael Witwicki 

From Beverly, MA
Wednesday, June 8th, 2011 at 10:46am

Hey Mike,

Really excited to see this post. I think you’ve started a great dialog here and it’s awesome to see the Structure folks weighing in and everyone having a good, positive conversation about what is clearly a polarizing topic amongst EE developers.

I should preface this response by saying that we have never tried Structure internally - but we’ve heard lots of great things from the community.

In the year or so that NavEE has been around, we’ve tried really hard to listen to everything that the community has said about it, and take that into consideration with how we have continued it’s development. Whenever Structure is a part of the conversation - the overall feedback we’ve gotten is that Structure is the end-user centric solution and that NavEE is the more developer focused solution. I don’t want to speak for Travis or Jack, but I’d assume that it is both camps goal to continue moving towards the center of that divide to have products that are useful for as many people as possible.

NavEE 1 was built (as it so often happens) out of an internal tool we had developed for our clients in EE1. When we decided to modularize it, our mission statement was really to make the exception the rule. So we set out trying to brainstorm every potential parameter and variable that could be needed to fill any navigation style. This guided our decision to have simple {exp:navee:nav} and {exp:navee:crumbs} tags which just output basic unordered lists - but also to have {exp:navee:custom} and {exp:navee:custom_crumbs} tag pairs in which you can generate any HTML you like. This, coupled with some advanced features like regular expressions for catchalls made NavEE pretty flexible (we thought).

Almost immediately - we realized that (although we tried) we hadn’t imagined EVERY possible navigation need. A big suggestion we got very early on was the need to dynamically build navigation subsets based on NavEE identifying the current page the user is on and using that information to intelligently build a secondary navigation on the page. This led to, what I can only assume are some of the longest parameter names out there in the EE universe:

- only_display_children_of_selected = “true”
- start_nav_from_parent = “true”
- start_nav_from_parent_depth=“2”
- start_nav_on_level_of_selected=“true”
- start_x_levels_above_selected=“2”
- and so on

In our quest to make things as flexible as possible, we also made a decision to entirely divorce NavEE from the EE content structure (with the exception of Pages integration). This was a blessing and a curse. The blessing being that your NavEE links can be whatever the heck you want and NavEE will still be able to intelligently identify the page you are on and add classes, build dynamically, etc. The curse, was this question: “What happens when my user changes the URL title?”. The answer, was unfortunately they have to also go into NavEE and update all associated links.

So about six months ago we started white-boarding all the feature requests which had been (for one reason or another) impossible to integrate into NavEE 1, and the biggest was related to our decision to divorce content from navigation entirely. Resolving that issue, is OUR attempt at moving more towards the center and trying to be more end-user friendly. NavEE 2, which is currently just finishing up BETA adds the ability for users to select one of three methods for creating navigation item:

- Manual - just like NavEE 1, any string you want
- Guided - select a template, channel and entry for a dynamically built item
- Pages   - select from the list of Pages Module entries

The two latter options are now directly tied to content, so when your user updates their template name, url_title, pages entry, etc - all NavEE links will also be updated. We’ve also added a fieldtype which will allow end-users to quickly add/edit a navigation node for the page they are on from the publish screen.

I think the point is, that whether you are a Structure or a NavEE user - it is wildly useful to us as Addon developers to see dialogs like this one. It assists us in ultimately doing what we hope is best for the EE community which is to improve our respective products and create useful tools that enable EE users to make great sites. I am particularly excited to see Graham weigh in about using NavEE and Structure together. Obviously there is some overlap in our products - but that doesn’t mean that they can’t both be awesome in their own right. I’d love to hear how we can continue to extend NavEE to make it even more useful when installed alongside Structure.

Anyway, again, great post.

Gravatar of Mike Mella, Be like water
Mike Mella, Be like water 

From Toronto, Canada
Wednesday, June 8th, 2011 at 11:52am

@Michael,
Thanks for weighing in, and I agree, it’s great to see so many people taking part in this discussion. 

It’s a nice problem to have: “Which add-on that makes our jobs easier do you prefer?” and I don’t suspect that the communities of other CMS platforms are that fortunate.

Also really glad to learn about the new NavEE features.  Those two things (No way to create a NavEE node from an entry’s Publish page; and the non-DRY need to update URLs in two places when one changes) were my biggest issues with it.  Can’t wait for the new version!

Gravatar of James Smith
James Smith 

Wednesday, June 8th, 2011 at 5:27pm

Great to see so many well-informed and intelligent comments on a controversial subject. To me it’s almost more important that an EE developer has actively considered the differing approaches than exactly which approach she chooses.

Having said that, my personal opinion is that Structure empowers users to create horrible and boring websites really easily. The Structure home page says it best with its screenshot ironically touting the “Useless Mission Statement”.

This is not a slight against Travis and Jack; their work is undeniably superb, but Structure solves a problem which is better resolved by building strong information architectures and tighter content types.

Having recently completed a large site migration from Vignette (V6) to EE, I’ve seen first-hand what happens when users have the power to create unlimited nested pages. The worst part was not the complication of redirecting 1500 urls to new places due to the lack of portability, it was the terrible user experience of navigating through 5 levels of ‘Useless Mission Statements’...

Gravatar of Travis Schmeisser
Travis Schmeisser 

From Brooklyn, NY
Wednesday, June 8th, 2011 at 6:40pm

@James - I mean this in the most constructive way possible, but your comment “Structure empowers users to create horrible and boring websites really easily” is pretty absurd. Maybe you haven’t used it before, but we do not control IA or content types. You use channels and custom fields for content types just like any other site (you the developer sets that up). What you’re referring to is about educating clients on good content practices and generally maintaining their site and on our end design, IA, content strategy, etc. In fact, you can even build a “horrible and boring” site without a CMS - the two just aren’t related. Our homepage graphic is more of a joke/jab at the type of clients that don’t get that and we’ve all had to deal with that before (the fact that the site you converted had those content issues shows that).

Gravatar of Graham Huber
Graham Huber 

Wednesday, June 8th, 2011 at 7:30pm

“Guns don’t kill people, people kill people.”

The same could be said for mission statements wink

Gravatar of John Macpherson
John Macpherson 

From United Kingdom
Friday, June 10th, 2011 at 11:34am

Great to see so much debate and informed comments.

Iv use Structure on a number sites and in the right circumstance its brilliant for client ease of use.

As many have mentioned its not the right tool for every job but Structure all in all is an excellent addition to the EE toolset. Many have even called for it to be built in to EE natively which speaks volumes.

Thank for this post, 15 mintes well spent.

Gravatar of Kjell Nygren
Kjell Nygren 

Saturday, June 11th, 2011 at 11:50am

Wow. This was awesome.

As someone who is new to developing EE sites this conversation intrigues me. I understand what structure does and why it’s important for some projects. I can also see Mike’s points that structure turns the EE content concept into that more like every other CMS’s approach. I have developed many wordpress themes and am personally tired of the page - tinyMCE - put your content in this little area - and every page looks the same approach to building websites. This is why I’m drawn to EE.

Being a newb though, if the page metaphor fails, what takes it’s place? I understand, content. But wordpress has the_content() function. Is that really that much different? A follow up post from Mike about his perspective in proper alternative technique to combat the page vs content battle would be good. I understand the idea of the channel and it resonates with me. Perhaps I haven’t dug deep enough yet into EE, but what’s the real issue that makes a plugin like structure necessary? EE allows for specific URIs for templates, doesn’t it? So is it clean navigation? Is it complication to the UX in setting up page structures? What’s the other approach?

Gravatar of Mike Mella, Be like water
Mike Mella, Be like water 

From Toronto, Canada
Saturday, June 11th, 2011 at 12:12pm

@Kjell,
Thanks for the feedback.

>what’s the real issue that makes a plugin like structure necessary?

I’m probably not the person to answer this question, since I don’t feel that it’s necessary, but I expect that for many developers, EE’s content management philosophy (that content is not to be considered ‘contained’ in a page) is too abstract for their clients to grasp.  That’s one reason why many of them turn to something like Structure.  Because, as many commenters have mentioned here, their clients “get it.”  As the Structure site itself puts it, “Your clients & authors will rejoice.”

My concern is less about Structure itself and more about that attitude: that clients aren’t smart enough to understand what we understand.  This is a mentality that needs to change.  Educating clients on how EE websites really work will empower them to conceive of ways to take advantage of it within their sites. 

And as for your suggestion of a follow-up article, I’m working on a case-study now, so stay tuned!

Gravatar of Graham Huber
Graham Huber 

Monday, June 13th, 2011 at 9:16am

@Mike - Changing attitudes may be the dream, but the reality is, for any CMS to be client-friendly, it needs to be able to facilitate easily updating page content with minimal complication. Structure achieves this by creating a “one-stop shop” for a highly visible and understandable page hierarchy (regardless of whether this is *actually* how the content or templates are structured/generated) that clients can understand is a 1:1 representation of what they see on the frontend. That’s so key.

By contrast, for clients to “get” EE’s “in house” abstraction of handling content natively through channel entries / template groups requires them to understand what EE even IS in the first place, which I can tell you from my own is actually a very rare thing. I also happen to think it’s completely unnecessary for them to have to understand what EE is just to be able to edit a page’s content.

It’s easy as a dev to forget how unintuitive a MVC structure is to someone that doesn’t deal with it every day. I agree it might help clients understand how to better use their site (and their own data), but hey, that’s really why they are hiring you in the first place, right? Not everyone is (or wants to be) a programmer. In fairness, can you really explain how your car engine works, or do you just go to a mechanic / the dealer when it’s making noises? (And I bet you pay them well…)—And really, even if you did, would knowing how your engine works really help you do your job better as a dev day to day, if you just need something that physically gets you from point A to B? It’s really just a question of roles at this point… A client is not a dev, and thus shouldn’t be expected to think like a dev (or have to call one) just to update their site content. They want a tool that will help them do their job better, not do *your* job better.

I, for one, feel that a content manager ideally shouldn’t even need to access a CP to edit content in the first place. MojoMotor has the right idea there—I’m still holding my breath for a good EE in-line editing solution. Missing Link (http://devot-ee.com/add-ons/missing-link/) is a step in the right direction (allowing “instant” CP access per-page via a modal window), through this still divorces a page from its content. NDG Flexible Admin (http://devot-ee.com/add-ons/ndg-flexible-admin/) can help massage the CP into something more client-friendly.

For those who are missing it, you should check out the conversation happening over at EllisLab on what the CP can (and should) be: http://ellislab.com/blog/comments/getting_started/

What I find most interesting about this conversation is the emphasis on client needs for the CP.

EE is a fantastic tool for devs, far more so than WordPress (with its limited field structure, as @Kjell mentions), but at the end of the day, most of us are building sites for clients who need to be able to run these sites, no matter how cleverly they are built (using Structure or not). I am absolutely in favour of any tool that makes EE a better tool for clients. I count Structure among those.

Lastly, I don’t think the “page” concept is going anywhere anytime soon, nor do I think it’s in conflict with how EE “wants” to do things via template groups. URLs are fundamentally structured to point to specific resources at specific places (e.g. http://www.domain.com/segment/resource.file). WordPress’ post-per-slug structure has curbed the need for hard files or extensions (.html, .php, .asp, etc) at the end of URLs, effectively using segments as queries (as EE adopts for template_groups as well), but the expectation is still that one thing exists at one place. As I noted above, even SPI and AJAX-powered interfaces still wind up falling back to hashtags or queries to emulate “page”-specific interaction—and believe me, it’s missed when it’s not there. All Structure does is provide a more flexible, more intuitive way to build (and manage!!) this page-specific navigation.

Mike, looking forward to your follow-up post on how content can (should?) be approached as well.

Gravatar of Mike Mella, Be like water
Mike Mella, Be like water 

From Toronto, Canada
Monday, June 13th, 2011 at 12:06pm

@Graham,
> It’s easy as a dev to forget how unintuitive a MVC structure is to someone that doesn’t deal with it every day. I agree it might help clients understand how to better use their site (and their own data), but hey, that’s really why they are hiring you in the first place, right?

Maybe the clients I work with are the minority, but in point of fact, no, they don’t just hire me for that.  My services include more than just building websites.  I offer a fair amount of consultation and content strategy as well.  I win contracts because my clients know they get more from working with me than they would from most other Web professionals.

> In fairness, can you really explain how your car engine works, or do you just go to a mechanic / the dealer when it’s making noises? (And I bet you pay them well…)

That’s an interesting analogy.  I don’t own a car now, but I used to own a truck.  I had a great mechanic who did just what I’m suggesting:  Once my truck had a problem with the wheel bearings, and rather than just rattling off a price for fixing them, he took me into the shop, showed me a wheel bearing and explained exactly what it does, where it is on the vehicle, what was wrong with mine, and why it would cost that much to fix.  That established trust: I was confident that he knew what he was doing and he was confident that I was smart enough to understand the explanation.  It also made me more comfortable paying the price I did, and it taught me something about my truck.  For that reason he kept getting my business.

Gravatar of Yvonne Martinsson
Yvonne Martinsson 

Monday, June 13th, 2011 at 1:18pm

What’s client-friendly is in the mind of the developer. If clients understand - or not - it’s a question of what the developer expects/knows/can explain. EE is as good as its developer.

Gravatar of Graham Huber
Graham Huber 

Monday, June 13th, 2011 at 1:57pm

@Mike: Yup, that’s what I mean—You can offer consultation and content strategy to clients because they are willing to pay you to show them how to do it. Being able to offer that domain expertise is the heart & soul of professional service. 

But unless your clients are also paying you to log into their CP and update their content, they need to be able to do that themselves. I actually discourage my clients from paying me to do that (they try), because I don’t have the resources to get bogged down by effectively being their webmaster. That’s where something like Structure is a God-send—rather than those clients needing to understand my mystical template structures, they can just see “About Us” in a familiar nav tree, and click that to edit. Problem (mostly) solved. If they need me to sometimes bail them out, I’m there (as a house call), but otherwise, I find Structure is a great way to hand off a site.

I note in your analogy that your mechanic was still the one that fixed your truck. That’s great he explained what he was doing—but does that knowledge really help you build a better website? (that is, it’s interested, but his job is not related to *your* job). Trust is important, sure… Just not, in this case, exactly relevant to the job(s) at hand. I would say he was really just being friendly.

Ask yourself this… What if your mechanic REQUIRED you to drive across town to look under the hood every time you needed the spark plugs changed or something? Not because you wanted to or cared to know, but because it was actually *necessary* for you to understand how your engine worked in order to actually drive your truck. That would be a different story….

Yet, it seems to be that you are asking clients to “fix their own” through better education?

Gravatar of Mike Mella, Be like water
Mike Mella, Be like water 

From Toronto, Canada
Monday, June 13th, 2011 at 3:12pm

@Graham,
I also don’t generally offer site maintenance.  But even though I don’t use Structure, I set up my sites in such a way that clients can still manage them effectively and intuitively.  Structure is certainly not required for that.

About the mechanic analogy, I’m not arguing that educating a client about how EE works makes their job easier, just that it empowers them to consider ways of making the most of their site.  This may be where that analogy stops being a relevant comparison.  If by “requiring them to look under the hood” you’re assuming that I’m making them go into templates, I can assure that I certainly am not.  It’s just about seeing content management differently (and the case of EE, more accurately) than how they’ve always understood it.

Gravatar of Matt Green
Matt Green 

From Gainesville, FL
Tuesday, June 14th, 2011 at 1:06pm

It seems like the less I have to educate my clients the more they appreciate it, most of them are so busy (especially larger companies) and their time is very precious to them. At the end of the day it matters more to me that my clients are happy, and that I save them time. Generally the more work I do up front and the more I limit repetition in their editing the better and easier for them to understand the process of their Content Management. I try not to get too mixed up in a right or wrong way or an “EE” way to do things, because the client’s satisfaction with the end product and how they interact with it is the primary focus, and in the end is what get’s me more business. I do whatever I can to go as far as possible with that and with flexible development and good content strategy at the same time.

Structure certainly helps me accomplish these goals. It is not perfect but the Structure guys (Travis and Jack) surprise me with amazing updates often. When I first started using it I had similar reactions that you did, since then the updates have eliminated most all of them. I have tried NavEE but again it adds more steps for the client in editing that I would like.

I don’t know about anyone else on here but my goal is client satisfaction and ultimately for the purpose of making more money (I have two daughters that one day I have to pay for their freaking wedding), I don’t care if clients understand about EE and what channels are, I want them to login and know how to add a page, edit a page, create a blogpost from one screen. They normally get the difference between entries and pages pretty easily. Nothing else out there can do that as well as Structure, you will never find the perfect solution unless you build it yourself and no one has the time or budget to do that for every client.

Gravatar of Aaron Kocourek
Aaron Kocourek 

From Dickson, TN
Sunday, September 11th, 2011 at 7:29pm

We also choose to take the same path you did, I’ve said this many times before and I will say it again, EE needs to put out another long overdue update to make the platform competitive again cause it is falling behind.

Leave a comment 

Commenting is closed for this entry. Sorry!