A bit of post-holiday fun today - a quick writeup on transforming an antique phone into a mail organizer. 

This phone was given to me by my parents some years ago.  They had purchased a number of them years ago here in West Michigan - as I recall the story was the phone company was selling these off after transitioning to newer technology some time in the 1960’s.  Dad had rigged up two as an intercom between the house and garage, and the leftovers were stored.

After receiving this one it was stored longer - in our early married years we moved a few times and never wanted to mount it until we had settled down.  I came across the phone again in a purging binge and decided it either had to be sold off or used - I was tired of it sitting on a shelf.  Some time online checking it’s potential value found that we weren’t going to make a house payment by selling it, so I decided to put it to use instead. Some measuring and experimentation found that its interior dimensions were well-suited to holding normal size envelopes, so I set about reclaiming it as a mail organizer.

The first order of business was to remove most of the guts of the phone—a bit of a pity since you could still turn the crank and make the bells ring.

Then I got some scrap sheet metal, and a few hours with a cut-off wheel and my welder netted an organizer rack to fit in where the hand-crank original generator was:

I made another shelf for the lower portion of the phone - so now incoming and outgoing mail store in the top and notecards/postage store in the bottom:

Looking to mount the phone it was clear the best place was right over the live phone jack.  Which, of course, I couldn’t do without making the phone actually ring. So I purchased this Remote Bell Ringer for Radio Shack and installed it into the phone (you can see it in the previous picture in the middle shelf area).  The ringer uses an actual brass bell - so the phone rings and sounds almost authentic.  It’s a bit muted being inside the door but still plenty loud.  There’s just something pleasing about it’s sound that’s missing in newer electronic phones.

Here’s the phone mounted into place:

I love these kinds of projects - turning something old and beautiful but essentially useless into something old, beautiful and useful. 

Although my first thought was to Twitter this (apparently the frequency for which I do that is starting to make cats salivate), but it deserved more than 140 characters. That being said, had it been a little tweet it would have said this:

@veen: increasingly, it’s clear that everything I learned, I learned from HotWired

I’ve mentioned it before in a couple of posts, and in person to Mr. Veen, but as I do some work for a media client examining their competitors and forming some online strategies and best practices, that site and its primary colours raced back in mind.

Maybe it was the electronic music being streamed into my headphones (the first online music I regularly listened was webcasted from HotWired via Beta Lounge).

Maybe it was that nearly every guideline I outline was done by that crew back in in the mid-1990s.

Maybe it was the nature of my client’s business.

Maybe its the the current debate over “purpose.”

Nevertheless, it’s inspired me to collect my thoughts and respond to a point I made a few weeks ago. After the Online News Association’s conference in Toronto, one of my posts alluded to the fact that mainstream media has failed to pick-up on some of the independent Web’s best practices.

Over the coming weeks, I’ll start posting some longer essays collected under the tentatively group under the title of “Saila Suggests” that will respond and expand on those best practices.

The first, appearing this weekend will be an overview, and will be followed by an piece on created user-friendly Web addresses. Although my self-imposed schedules are infamously erratic, I hope to a have a few more posted before the year is out.

The challenge: Build on Approach D of building navigation for static content in ExpressionEngine, but only show 3rd level links when any page on a specific branch is active. 

In Approach D I introduced the idea of using ExpressionEngine’s Relationships to drive navigation for 3 level content. This installment builds on that approach by creating a menu that only shows the 3rd level pages when you click into that branch of the navigation.

To follow this tutorial you’ll need:

• The EE components covered in Approach A.
• The additions mentioned in Approach D - so essentially a weblog with content and relationship fields and an index template.
• Several entries posted with some of them being assigned to a parent page.
• The entries need to be ordered by date in an order that matches their position in the menu.  Put another way - the date ordering should be such that if you showed them all at the same time they would be in the right order - Parent A with it’s children before Parent B with it’s children.  Getting the children to show up correctly in all cases depends on this sort being correct.
• A template group and template structure such that url_titles will display in the segment_3 position.  If your structure is different you’ll need to adjust the code.

Note: this approach does require the query module, which isn’t included in the Core version of ExpressionEngine.

The Results
Let’s first look at the results - so you can determine whether the outcome is something you’re interested in building.  Here’s the working example.  The index loads initially only parent pages showing in the left nav - so these are pages with nothing assigned in the relationship field.

Clicking a parent page link will load that entry, and also refresh the left-nav with child pages for that section.  Clicking a child page loads that entry and keeps the navigation the same. Choose a different parent and the 3rd level options change to only show the children for that parent.  Behind the scenes - no javascript trickery, no CSS showing and hiding, no dynamic HTML - it all runs on straight EE conditionals with one query thrown in.

OK - so that’s the finished product.  Let’s take a look at what it takes to get there.  In this example I broke out the menu-building code into an e Embedded Template so that it could be easily reused from different areas of a site that needed the same type of navigation.

Index Template
Let’s start in the parent template - it features this code which calls the embedded template while passing in all the things the code in the embedded template needs to generate the navigation:

my_weblog_name: Used to set the weblog to create the navigation from.

my_index_entry: There will be one post in the weblog that holds the index content for this section - and we don’t want to display that post in the subnav.  Passing in the url_title of that entry will allow the embedded template to exclude it.

my_detail_path: We’ll need to build links in the embedded template so will need to know the path.  Note that you can use this in two ways - either have one template for everything or use an index/detail template arrangement.  In this example I’m using a single template.

my_relationship_field: The embedded template will need to know what field holds the relationships. Different weblogs will have different names for this field so its passed in as a variable.

Embedded Template
Now for the meat of the code - the embedded template.

There are essentially three parts to this code:

• Showing the parents only
• Showing children when a parent is selected
• Showing siblings when a 3rd level page is selected

First let’s look at the weblog:entries tag:

You can see we are using two of the passed in values to choose the right weblog, and exclude the post that represents the index entry.  We set the sort and turn dynamic=off so EE doesn’t look at the URL to choose its results.

Showing Parents Only
The first conditional finds entries that have no relationships assigned:

Showing Children When a Parent is Selected
Within this conditional is another:

The code assumes that when the index for this section is loaded there will be nothing in the segment_3 position.  So - remembering that we are still on an entry with no relationship specified - if there is something in segment three that means the user must have clicked a 2nd level—or parent - entry.  Now we need to show the children for this entry so the code uses the reverse_related_entries tag to do so:

Those two situations are the easy part.  The harder part is determining when a child entry has been selected and then displaying the siblings for that entry.

Showing Siblings When a 3rd Level Page is Selected
The first part - detecting when a 3rd level page has been selected - is handled by this if:elseif in the main conditional:

This finds the case when the currently-displayed entry has been assigned to a parent (so is a child page) and whose url_title is displaying (so has been selected).

Now for the trickiest part - finding other pages with the same parent - or siblings - to this page.  There is currently no built in tag to do this in ExpressionEngine, so we have to use a custom query (I won’t go into the specifics of the query here - I was only able to figure this out by bringing EE data into MSAccess where I could use the visual query builder to figure it out):

Note that the query uses the global homepage variable, the passed-in my_detail_path variable, and a query-specific variable of my_url_title to assemble the proper link.

So there you have it - a one weblog, one field group, one template way of building static navigation that requires no client-side trickery to only display children for one branch of the navigation tree at at time.

I do need to thank Rob Dircks of Dircks Associates for permission to share this code.  I developed some of the trickier parts as part of a project for Rob.