Greetings to all and happy Memorial Day weekend!

As previously promised, this post is going to be a fairly in-depth recap of the launch of RCD’s “proof of concept” / portfolio website: PDXcomm.net. This will include:

• A quick recap of the platform decision (e.g., decision to build using Concrete CMS)
• Site design decisions leveraging Concrete’s strengths as a CMS platform
• Workaround decisions dealing with known Concrete issues
• Update on next steps in this project

Platform Decisions

Let’s start with the decision to build a “community network portal” portfolio site (for my adopted home city of Portland, Oregon) on Concrete as opposed to WordPress. While the initial primary driver for this was a desire to save time and money, it is a decision that has been justified in other ways as well.

This  blog runs on WordPress, the same as roughly 75% of the web, the same as many sites I’ve supported in the past… most of which had relatively little to do with blogging. With the appropriate support/development staff (and appropriate budget), you can pretty much develop anything on WordPress… and, on prior occasions, I have.

But I am not a developer by trade, and my budget for this project was as close to nothing as I could manage. Once I scoped out the time, effort, and/or money required to do this in a relatively short time on my own in WordPress… I decided to seek other options (you can read more about this in RCD’s first blog post). The option I wound up with was Concrete CMS.

The further validation of this decision was the relative ease with which I was able to develop custom solutions to meet my design requirements. Someone who knows WordPress extremely well might have been able to accomplish similar results in similar turnaround time. Someone who knew as little about WordPress as I knew about Concrete when I started this project… would still be learning WordPress. I am completely sold on Concrete, I am currently planning my next Concrete-based project (more on that soon). But for now, I want to further discuss how I used Concrete for this project.

Site Design Decisions

First decision: what’s it gonna look like? That one was easy– a minor re-skinning of Concrete’s current default Atomik Theme was more than sufficient for my requirements (with many other themes as well, both free and premium).

Next decision: how do I build what I need? In WordPress, I would be doing custom work using Custom Post Types, Custom Taxonomies, and Custom Data Fields or buying a premium plugin that (hopefully) had already done the work for me. There are “add-ons” for Concrete (check out their marketplace), just as there are “plugins” for WordPress, but none meeting my requirements… but also no need for them. Almost everything I needed was already part of the core product.

The equivalent feature to Custom Post Types et. al. in Concrete is called Express. It is, for practical purposes, a simple relational database used to create easily rendered drag and drop content objects (in other word, no code required– as detailed in this YouTube video). The “simplified database” required for the content I had in mind for PDXcomm looks like this:

Basically, 93 Neighborhoods in a one-to-many relationship with 5 city Quadrants (it’s a Portland thing… don’t ask), roughly 200 business/organization Listings in a one-to-many relationship with 11 (so far) Categories, and a many-to-many relationship between Neighborhoods and Listings (in order to allow a business/organization listing to be displayed on multiple neighborhood pages).

The initial plan to do the entire information architecture in Express did not last long. It quickly became apparent that I would need, at bare minimum, the usual assortment of static high-level landing pages and detail pages for all 93 Portland neighborhoods. But I was able to make almost all of the content in the detail pages centrally managed Express data. And no pages were needed for the business/organization directory. That is completely dynamic content rendered from Express.

The most time-consuming part of this project was plugging enough of that data into Express to show “proof of concept”. This meant enough content to make neighborhood pages interesting, enough directory data to validate neighborhood listings and search. For that content, I turned to a couple of mixed residential/commercial neighborhoods near my home in SW Portland: Hillsdale and Multnomah Village. For the mostly residential neighborhoods that make up most of Portland, I just added a listing for the nearest city park (of which Portland has many). It’s enough for now.

Platform Workarounds

The next most time-consuming part of the project was developing a unified search experience to make up for the lack of a unified search solution. This is a known issue that Concrete’s principal architects have discussed at some length on YouTube. There are content blocks for searching site page content, there is an Express List content block that lists out the contents of an Express Entity. There is not, at this writing, a solution that does both… and my project needed one.

The workaround I came up with used Concrete’s ability to build fairly complex custom templates for existing content blocks. These templates can both alter visual styling and extend functionality (there is a YouTube video on this subject as well). I did both. The unified search experience on PDXcomm.net looks as much like a unified solution as I could manage with my modest PHP coding skills. More importantly: It actually works.

By the time I figured out how to do that, the rest was actually pretty simple. I wound up creating a total of 15 custom block templates: three of them for my unified search experience, three of them to handle custom styling for a tab/accordion add-on (one of my few purchases for the project, and well worth it), a couple for my neighborhood pages, and the rest for a Listing Details page used as a common component across the site.

The total project runtime, from the day I installed (and started learning) Concrete CMS to the final go-live, ran roughly five weeks. With an actual team, I could’ve cut that schedule in half. Even working solo on a comparable project and applying lessons learned, I could still cut delivery time roughly in half. I’m good with that, actually.

Status Update/Next Steps

As promised, I’m going to end with a status update and next steps.

Status Update– In the week since I concluded phase one on this project, I’ve been investigating open source social media platforms, with an eye toward adding a branded social solution to PDXcomm.net. Although I like the idea, I’ve decided to rule it out of scope. I can’t currently allocate time required to develop, nor am I willing to deal with the potential liability issues of a private label social media platform. I’m keeping it on the backburner, though. The potential profitability of offering websites with privately owned/operated social engagement is too great to ignore.

Next Steps– For PDXcomm.net next steps include the following:

• Continue to build out “basic listings”— the 200 or so listings I was able to find time to create is probably around 5 to 10% of what the project actually requires. I either need a marketing strategy that builds this content out via social engagement, a technology solution that captures available data already on the public Internet… or a combination of both.
• Develop Paid/Premium List Offerings– Basic listings are free of charge content that build the value proposition of PDXcomm.net, but they do not generate revenue. For that, I need to develop “paid listing” options that provide value that is worth paying for.
• Develop a Social Media Strategy– I have even less business calling myself a “social media marketing strategist” than I have calling myself either a developer or a graphic designer. I either need to develop those skills or find a way to make it worthwhile for someone who already has them. Definitely work in progress… whichever way it goes.

That’s it for now. Please subscribe (see below)  and stay with me as this story develops.

Cheers, all!

–MM