Tuesday, December 26, 2006

Expression Engine: Implementing New Site Architecture

Details of the new site architecture in version 3. of Wide-Eyed & Laughing

Well, I promised when I was near completing stage three of my website, that I'd deliver some details about the re-design process. And in all honesty, I definitely owe any of my regular visitors who stuck around during the two weeks the site was down. The original redesign, was suppose to be just cosmetic. I want a cleaner, leaner looking site, and a wider footprint. That was really just a weekend's worth of work, I had already fiddled with modifying the main content areas from 780px width to 815px width; and knew where and what I needed to change in the CSS to implement the site.

Something happened on the way to grandma's. The new design was in, but I realized that it wouldn't help me post more often, or encourage me to post better articles. A new site architecture was required for that. When I started this site years ago, using the first version of Expression Engine, I was brand new to it. I loved the power and that it was built on PHP. One of my biggest issues with Moveable Type was it's Perl code. Nothing against Perl, in general, except I suck at it—plain and simple. Obviously, that's not a downfall of the system (Moveable Type), but a glaring gap in my education. I went to school to be an engineer not a programmer. And while basic COBAL and BASIC programming where part of the curriculum, I never really got a in-depth training in programming. For me, Perl is too like C, I look at the code, and get a slight brain freeze. But PHP, well, I picked up a book, SAMS Teach Yourself PHP, and low and behold a week later, I had more than enough skill to build basic applications.

But long story short, when I started in Expression Engine, it was a brand new application to me, and the site was also brand new. I didn't really know what I wanted, so I kept it simple

Someone has said it better than I, but simple is your friend, until its not. Sometimes you need complexity to retain simplicity. And that's where I was. I wasn't posting as much, because it was a major effort to think, this is a playlist post, it needs this, this, and this…, but all I really had was one really large big old body field, that meant every post had to be hand coded, if I wanted specific formatting. This needed to change. I wanted specific publish forms for different sections of the site. Indeed, at actually wanted different sections, instead of just categories; and this all required a redesign and site architecture changes.

Expression Engine is Powerful

One of my favorite things about Expression Engine (EE) is it's power. It really is incredibly flexible. I often think of it as a PHP framework with a built in Content Management System (CMS). As I've gained more experience with it, I'm always very impressed with how far I can take it; and how much more there is to discover about what the system can do. Expression Engine allows for custom fields, custom statuses, multiple weblogs/sections, and custom categories. Sets of fields, status, and categories can be set to any particular weblog/section so it's possible to create specific data entry processes for each section of a website; as well as mini-application processes.

I started with sections. I still wanted to keep the simple, free-form style of some posts, so my old singular "weblog1" was relabeled "main" and kept the old style, and the old articles. But then, I broke things about between the main section of the media section. Media items are all fairly structured. I don't always fill out all fields, immediately, but I didn't want to skip details just because I forgot to think about them. Since the media section is really dedicated to my commenting on other people's hard work and efforts, a more formal or structure system of fields of inclusion is what would make life simple. Why write a book review/recommendation is you forget to include things like the author's name, or who published the book, etc. Custom fields allowed me to add the structure, and separate sections allowed me to implement the structure.

You can see from the above image. I grouped each publish form under the overarching classification—main, media, or application—for my purposes. The Main areas were pretty easy, mostly my free form work, playlists, and then the colophon (aka the about section). I decided to label it colophon; because I wanted to include more details—facts as you may—about the site development, the tools used, reasoning, etc. You can also see, that for the Media areas, each distinction became its own section—videos differ from books, which differ from music, etc.

Customizing the Experience

Once, I had the sections in places, I needed to distinguish them. This is where custom fields come in to play. EE allows you to create any number of custom field groups. A group of custom fields can be assigned to a section or multiple sections. Custom fields can allow you to control your data entry process—making it consistent regardless if your entry something today or two months from now. As you can see from the image to the left, I've created a number of field groups. What I want to know about a book, is different than what I want to know about music, or a television show. A lot of it overlaps, but I didn't feel the need to force the issue, just to keep the number of fields and field groups down.

Video Fields
For this example, I'm going to focus on the "video section" of the site. The video section is just a lowly hobby section for me, but it's incredibly popular. I like certain details to be included with videos—the song I'm using, which television show or shows did I take images from, which couple am I'm pairing together, etc. Sure their just musical mash-ups; but I hate when I'm viewing other's video and then have to spend time trying to find these details out. I also made a second decision—I wanted the ability to include/highlight/recommend video mash-ups from other creators—this included embedding videos from YouTube or Google (even if they were my own.

The fields reflect the information I want to be required for each video I post. I may not complete the form when I first post, but eventually, I go back and make sure that I have url's for the show, the song, recording artist, etc. Plus this means, less HTML coding when I publish, most of the code is taken care of on the template, so I can just think, write, then edit—which makes life easier.

Here's an example of what the data entry form (publish form) looks like from the backend.

Creating the User Experience (Templates)

So now I have the sections, fields, categories, and even some custom statuses, so let's try to tie it all together. Templates are the glue of Expression Engine (EE), at least from my perspective. They allow me to define your experience with the site. I'm into a fairly simplistic architecture for the user—I tend to like each section to have three templates. I call these my template set—my primary set is an index, article, and archive templates. Every section has at least these three templates.

As you can see in the above image, EE allows for template groups. I tend to have the template groups match the various sections of the site that I want, since the template group name is included in the url. I've also had this weird mental issue with whether or not the actual template names should be singular or plural. I started out with plurals—articles, archives—but then decided to make the switch to singular, except that I couldn't come up with a flexible htaccess redirect for the past archives. So you'll not that article is singular and archives is plural. It's not purely idiosyncratic on my part, the desire to have templates within the template group by singular, also just matched my philosophy of the site. An article template pulls an article, individually—if you every see multiple articles on an article page, it means there is a page error somewhere. Same theory with my hoped for, but unimplemented switch to the singular archive, each section would have a section archive, then the site would have an archive. The site archive would be called archives, the section archives would be singular. If I can figure out the htaccess, I may still do so, in the future, but for now, it works.

Embedding Templates
I'm a big fan of EE's ability to embed templates within templates. This is pretty much like uses PHP includes or server side includes; but to the nth degree. In terms of basic embedding, I start off with header, footer, a sidebar when in use, navigation, etc. These items can be embedded into the various templates, so I only need to edit once to update every section of the website—including galleries.

That's nice, but where the real power is, is that embeds can be used with if elseif statements, to build more complex includes. For example, my article page at each template group level, includes just a single line of code . That single line of code then allows me to tell EE which article structure I want to use based on where I published the article, if I have special considerations for specific categories or related to a specific field. All my code, for any and all exceptions at this level is in the primary embed—include/article. But the meat of each page is contain in the secondary embeds—article_book, article_music, etc.. These files, control all the formatting for the pulled article for that section. These files also use if, elseif statements, other embeds, and occasionally even PHP to accomplish there feats.

In exploration, I want links to display for publisher's websites, author's websites, amazon purchasing, etc. But I only want the links to display, if I've entered data in the appropriate field. So little checks, if this is empty display , else display the author's name as an HTML link. I also use this to assist with my laziness or not having enough time. Sometimes I want to publish or recommend a book, but I don't feel like I have the time to do a full recommendation—even though my recommendations aren't very formal. With the new system, I can check to see what information has been included and change the page format based on if it's a written recommendation, versus a quick book introduction. This way, you don't see tons of blank white space that says, I didn't care to complete this post. But it also allows me to not have to label all incomplete posts as In Progress so that they don't display on the site. I can have a book, song, or any media recommendation go live, with some fairly basic information; then add my review/recommendation at a later date.

See, sometimes complexity, aids simplicity

Concluding Thoughts

So the new architecture is far more defined then the prior site. Hopefully, everything is still very easy to navigate, especially since the navigation is now hidden away, under the Site Map button at the top of the page. But, the changes are allowing me to publish more articles at a more frequent pace. I no longer have to plan a full fledge review to recommend a song, book, or television episode. Which is great, because sometimes I'm just feeling, "This song is great!" And no other coherent thoughts exist beyond that. After, I've listened to it 30 or 40 times, especially in various mixes, or in shuffle mode on my iPod. This allows me to learn how the song makes me feel in context of other music or various life situations. Does it pick me up, make me introspective, leaving me longing, make me want to dance? Am I anticipating when I'll hear it? Am I surprised at how well it sounds after _____ (fill in the blank)?

The new site structure allows me to be moody. I don't have to be in super productive mode to get a post done. Ms. I Don't Want to Work or Research can show up and I can still post. That makes life easier, especially since Ms. Whine and Cheese has been coming out far to frequently.

Other Details

Viewed: 1462
Permalink: http://www.wide-eyed.org/colophon/article/expression_engine_implementing_new_site_architecture/