Basically, I thought my professors were crazy. Maybe that was because, as a middle and high school student, I kept hearing we were learning the metric system because the United States would be switching from our antiquated English system of measurement to a metric system during my lifetime. The switch still hasn’t happened. At this point, all my measuring tools include English and metric, yet we’re far from changing to metric-only anytime soon.

So when my professors professed that I would be engaged in a global economy someday, I was, shall we say, less than receptive to the idea. Mind you, this was all pre-Internet, way back in the last century. My attitude at the time was, “I’ll believe it when I see it, and not a moment before.”

Well, as humbling as it is, especially for a guy who prided himself during his twenties on being “right,” I was way, way wrong. It happened: the time is now, and I’m working for an international company with a vibrant international audience and an international staff. I wish I could go back in time and slap some sense into myself. How could I not have seen this coming? Under what rock was I living? Was there something blocking my view? How could my perspective have been so clouded? Why didn’t I prepare for this better? Why couldn’t I accept the concept of a connected global village?

One morning last week, I arose at 5:30 a.m. to shower, shave, dress and caffeinate myself for a 7:00 a.m. videoconference with a large organization in London. We used Skype and it worked better than I expected. I was attending a 3:00 p.m. meeting with eight people at the organization. There was less than a quarter second in the audio delay, so our conversation was almost as if we were right next-door to one another. I’m in Oregon on the west coast of the USA; they were clear across the continent and an ocean away and I could see and hear everyone in some meeting room in the UK. Via wireless connection, I appeared “inside” a laptop that was placed on a table in a London conference room, while physically sitting in my home office in Oregon.

I tried to behave as if this was a typical day for me, nothing special. “Yeah, I commute to meetings through cyberspace all the time, no big deal, just another day at the office. La la la… ” In reality though, this experience was a major eye-opener for me. I’ve spent the better part of the last five years with my face in a flat-panel monitor online at all hours of the day and night. The Internet has become so commonplace in my daily routine that I rarely take a step back to look at the big picture anymore. I’ve been taking the web for granted.

When I pause just long enough to consider what it took to make that one-hour videoconference happen between my home office in Oregon and that organization in London, I’m in awe; it’s nothing short of magic.

So I was wrong, and my university professors were right. I can live with that and have learned from it. The question subsequently arises though: What part of the future could I be preparing for now, if only I would accept that it will happen?

The magic here will be using the weblog entries tag with the search parameter and segments.

Shall we? 

For this article, we’re going to focus on filtering all bug reports by their severity.  We’re going to be careful to build a template that we can use later for filtering by other custom fields while re-using the same template.

To begin, duplicate the index in the bug tracker template group and call the new template filter_by.

Now, open up that new template and find this code:

To this, we’re going to add the search parameter.  We’ll add it like so:

We’re turning dynamic off here as we’re again defining our own semantics.  For the search parameter, we want to keep this flexible so we can use it for our other custom fields, hence calling segment_3.  We also want to be able to pass a variable to it so that we can re-use the template for all of our custom fields, so we’ll call segment_4 as well.

You’ll remember that our custom fields were all prepended with the short name of the weblog; however, we don’t want that to be reflected several times in the URL as that would be redundant.  To keep the URLs neat and tidy, we’re adding short name to the search parameter and then appending segment 3.  Momentarily you’ll see why.

Before that, as we did in last week’s article, we’re going to add the no_results variable pair here, like so:

And in order to have a conditional heading telling us what we’re filtering by, we’ll add this right below our already existing count conditional, and above the opening table tag:

We’ll make one more change to this template, and that is the embed calling inc/.head.  We need to pass it a correct title to display, so it should now look like so:

It’s time to create links that allow for filtering by severity and segments.  Open up inc/.leftnav.

We’ll want to replace the severity link with a list of severities to filter by; replace this link:

with:

The search parameter is not case sensitive; however, we’re also going to use this in our heading tags, so we will want it to have proper capitalization with minimal mark-up; capitalizing the severity in our links helps reach this goal.

Now visit the bug tracker, and click on the Trivial link - it should look like this:

And here is the template code for bug_tracker/filter_by:

and the code for the updated inc/.leftnav template:

And now we can easily filter posts by any severity, using one template.  We’ll expand on this concept as we go through and implement the features indicated in the left navigation menu.

When I served as the director of a childcare center we also tackled the challenge of communicating information within a somewhat dispersed staff. Even though we all worked in the same building, we were situated in different rooms in the building, we worked overlapping shifts, and employment laws and childcare laws created a situation in which the whole staff could not meet at the same time, in the same place, without the center having to pay overtime wages. Our staff had to meet after closing in the evenings, and we had to pay folks their hourly wage plus one-half hour’s time for every hour of the meeting. This made meetings very expensive so we only held them about 10 times a year.

There were 27 employees, six daily volunteers and other volunteers who comprised the staff of the center. At the time I started as the director, the center had a ton of dysfunctional issues that needed attention, and I was leading some pretty major change initiatives and really needed some way of communicating with staff to keep it up to speed on a daily basis. The building had one computer, two phone lines, no employee lunchroom or break room, and no intercom. Basically there was no way to communicate between the office and the classrooms or from one classroom to another except to have someone physically walk from room to room or yell down the hallway.

The building was very old and among its many challenges it had one adult toilet for the entire staff and visiting adults. Over 100 adults worked in or visited the building each day and we had one toilet in a small room with a sink at one end of a long building. Student toilets were in rooms with little or no privacy and were not suitable for an adult. It was also not a good practice for students to use the same facilities at the adults.

It wasn’t long before I realized that the one adult toilet was the functional bottleneck (constraint) of the whole center. If just about any other functional system in the building quit working, we could stay open and legally continue to care for the 80+ children we were licensed for. But if that adult toilet ever quit working, even for a couple of hours, the whole operation would have to shut down.

One night, I was writing a contingency plan to cover us in the event the one adult toilet ever quit working, and something occurred to me. That toilet was the one place, the only place, that I could pretty much guarantee the entire staff would visit on any given day. Also, I could presume that at least one daily visit would take three or four minutes with the person sitting still long enough to read something.

The next day, I wrote the first edition of my “Soapbox;” a mini-newsletter printed in a large font. I taped it to the back of the toilet room door so that it could be easily read from the “seated position.” Within an hour, one of the staff was so offended that I had found a way to invade her “personal space” that she ripped it down, wadded it up, and ran water over it in the sink to ensure it wouldn’t be put back up.

That first week, I remember replacing the Soapbox with a fresh copy about 10 times as staff kept removing it in protest. Then one day, I noticed the copy hung on the door was one that had been ripped down, crumpled up, retrieved and re-hung with fresh tape. Someone on the staff actually wanted to read the thing and had hung it back up.

I continued to publish the Soapbox at least once a week and each edition improved on the layout and presentation of information. After that first week, it wasn’t ever ripped down again. Within the first few months the staff accepted this new form of communication, and I knew the acceptance had reached critical mass when a staff member asked me to start putting a second copy of it on the outside of the door for those waiting in line to read.

The Soapbox became our primary source of news and information at the center. Once information was posted, nearly the entire staff would know about it within 24 hours. The staff learned to rely on the Soapbox for important information about employee benefits, vacation schedules, changes in funding, policies, procedures changes, requests for input to assist with decision making and updates on our ongoing remodeling projects: essentially everything and anything that mattered to the staff and parents. One edition featured paint color samples so the staff could choose the color we would have the building painted.

The consistent flow of up-to-date information from the main office, and the fact that everyone had equal access to it on a daily basis made the Soapbox a success. Our staff was kept updated on all pertinent news and announcements, as often as new information was available. This proved to be a big help with preventing and controlling rumors, and encouraging useful conversations between staff members.

The key things that made that made the Soapbox a success were:

1. A captive audience with 100 percent attendance; everybody read it within 24 hours of each other
2. Regularly updated information from a reliable source
3. A presentation format that made the information quick and easy to consume

Today, I’m considering what might prove equally successful that can be served up to our dispersed staff at EllisLab. We have some systems in place now; might there be something even better? What’s the best way to ensure the captive audience? Who will be in charge of posting the information to ensure the steady flow of updates? A blog, RSS, staff forums, bulk email, a weekly podcast, project management software? You would think that with all these options available, and all the geeky, techno savvy folks here at EllisLab this communication thing would be easy to figure out, and maybe it will be, but for now, it’s a work in progress.

If you work in a large group of folks that are dispersed in one way or another, what’s your winning solution, and how’s it working out for you?

Some days I have to remind myself that the Internet is still a new experience for many people. Even folks who have been using email for a decade may not know much about the web or how websites work, and frequently they are the very people charged with choosing a CMS and/or CMS consultant for their business.

Also, among these folks is a sub-group I’ve run into that hate anything that has to do with databases. They have an emotional reaction to databases as if they are inherently evil and out to destroy the world.

When we’re presenting to folks like this, we might be using the latest techno-speak to describe the website we’ll build for them, and they might be hearing something completely different.

I might say, “Your new dynamic website will be built in a Content Management System called ExpressionEngine, running on a foundation of the powerful open source technologies of the PHP language and MySQL database.”

By the time you finish that sentence, they are thinking, “Ack! It requires a free database I’ve never heard of, it’s in some language I’ve never heard of and the whole expression whatever and dynamic thing just sounds like it will create a lot of drama around here we don’t need. I don’t want a database, I want a website!”

When I sense this is going on, that the person or group I’m presenting to is not receptive to my carefully practiced techno-speak (I’ve seen people turn red and start shaking), I try to take a step back in the conversation to explain how EE works. My favorite analogy is that of a short-order cook in a breakfast restaurant.

Here in the States, we have restaurants that specialize in serving the American breakfast. At the center of these restaurants are one or more short-order cooks who can take a customer’s request for two eggs (cooked anyway he likes) bacon, hash browns, toast and a stack of pancakes, cook it and get it on a hot plate in a manner of minutes. A good short-order cook in a well-designed kitchen can plate 100 meals an hour during morning rush. It’s a bit like a highly improvised kitchen ballet.

This kind of restaurant is familiar to most of the folks to whom I end up explaining EE to, so it has proven to be a good analogy for me. Here’s how I might use the restaurant to explain a dynamic EE site versus a static website.

If you walk into a “static” restaurant for breakfast, you will be served the same breakfast prepared the same way as the person before you, and as the person who comes in after you will have. The place basically serves one breakfast, cooked one way, for everyone that visits. In fact, the food may have been precooked and/or prepared weeks in advance; think frozen dinner.

If you walk into a “dynamic” restaurant, a waitperson will send your request for breakfast back to the kitchen, where a very busy short-order cook will read your request and quickly prepare your requested breakfast from scratch, out of resources in the kitchen. He will go get eggs, butter, bacon and bread and start cooking those on the grill. He may also find some pre-mixed batter from a bowl (a cache) and pour some of that on the grill at the same time to make you some pancakes. The second everything is cooked, he assembles it all on a hot plate and your waitperson brings it out to your table. In a good breakfast restaurant, this takes less than five minutes. When EE does this for your website, it will take a fraction of a second.

The kitchen is very much like a database of information that has been stocked, stored and positioned so that it can be accessed quickly and assembled into a hot breakfast by your short-order cook. ExpressionEngine acts as your short-order cook assembling your meal for you as you requested. The restaurant is your hosting server and your waitperson is your browser in this analogy.

This is analogy is far from perfect, but enough folks identify with it that I just keep using it. Also, by avoiding unfamiliar technical speak, and using somewhat familiar terms related to kitchens and restaurants, some people feel more comfortable talking with me about EE. The whole CMS conversation becomes less threatening and sometimes quite silly.

If you’ve not encountered the kind of restaurant I’m talking about in this post, I found this video of a short-order cook preparing a late night meal. This will give you a visual even though this cooks not preparing breakfast during rush-hour. This video is nearly perfect for my analogy though, as you can see the cook querying the database, retrieving the data, formatting it, and assembling it.

Short Order Cook Video

So far, I’ve had pretty good luck using this short-order cook analogy to explain how EE works to folks who are unfamiliar with the web, computers and databases. I’m always on the lookout for a better analogy though, and I’ll bet there are some good ones out there. So I invite you to share yours if you’ve found one that works for you.

How do you explain EE to the non tech savvy?

They say that in life, timing is everything.  In 2003, fresh out of college, Paul was hired by the Oregon Wine Board to build a website using our first generation publishing system, pMachine Pro.  That site had a number of needs that were not able to be met natively by pM Pro, so Paul, despite never having coded anything in PHP before, rolled up his sleeves and figured out how to develop those features.  He then generously donated his new code back to our community, which is how I first met him. 

I remember looking at his code and being blown away that he had only been coding a few weeks.  He was a natural.  He also happened to live in the same city as I did, and as luck would have it, my little company had grown to the point of needing some development help, so I offered him a job.  Paul became employee number three.  There was me, a guy named Chris doing tech support (who left the company years ago), and Paul.

At the time Paul came on-board, I was a few months away from unveiling ExpressionEngine, the secret new project I had been working on.  In order to stay focussed on EE, I turned pMachine’s development over to Paul; a risky move for sure, given how little experience he had.  To Paul’s credit, he took the challenge by the horns, dove head first into the code, and single-handedly developed the very next release of pM Pro.  A natural indeed.

As good as Paul’s technical skills were, his work ethic and commitment were even more impressive.  Paul immediately became my trusted right-hand man, and for the past four years has been an integral component to our success.  During those early years in particular, Paul was more like a brother than an employee.  I can’t express how grateful I am that Paul emerged in our forums one day, and helped shape who we are today.  I couldn’t have done it without his help.

A couple years ago, we had a similar good fortune in finding Derek Jones.  He had been participating in our forums, having built a couple projects using our software.  We needed to grow our team just as Derek’s career was transitioning, so we offered him a job.  Similar to Paul, Derek was very new to programming when he started, but he had that special mojo that enabled him to learn rapidly and get productive very quickly.  In less then two years Derek has gone from having little programming experience to becoming CTO of our company.  Impressive.

Paul, and later Derek, taught me my philosophy on hiring:  Hire people who are brilliant, who get things done, and who show great aptitude—and this is important—even if they don’t have a particular skill-set.  Skills can be learned.  The other stuff can’t.

So today marks a day of transition.  Paul Burdick is leaving to spread his wings, tackle some new challenges, and meet some personal goals.  And Derek Jones is emerging as the cornerstone of our technical team.  Paul leaves a big void to fill, but fortunately we’ve had some months to make the transition internally, and he will still be with us in a reduced role, so our development goals shouldn’t be affected. 

Thank you for all you’ve done for us, Paul.  You’ll be missed!

To begin, let’s start by quickly supply the reporters a list of their own reports.  That way they can track the status on those reports as well as respond to any enquiries for further details.

In order to achieve an infrastructure that can easily be expanded down the line, we’re not going to restrict ourselves to one mega-template; instead, we’ll create function-based templates that we can expand on later in order to get detailed reports.

Our first goal for this is to be able to limit bug reports by the reporter.  So, let’s make a template and call it by_author.  This will be in the bug_tracker template group.  When you create this template, duplicate the bug_tracker template group’s index.

This template is going to remain largely the same as the index template.  Only now, we’re going to add the dynamic= and username= parameters, with the username= calling the third segment.  This will be the new weblog entries opening tag:

Important to note is that if we did not turn dynamic off here, then the weblog entries tag would believe that Segment 3 was a URL Title, and would give us different results than what we are after.

Now we’ll add a link in our left navigation, under “Search and Report”, and call it “View My Bugs”.  The link will look like this:

Not only have we now set up the ability for the reporter to view their own reports, we have also set up the infrastructure that will allow us to create links for any bug reporter, by simply passing the username in the URL. 

If you test at this point, it beccomes readily apparent that we get a rather uninformative page if we pass an non-existing username via Segment 3.  At this point, it would be good to make use of the if no_results conditional variable pair.  You can do that by simply adding the following code directly under your opening weblog entries tag:

Here is the finished by_author template:

Of course, there are other ways that we could have handled this, and I’ll give a brief mention of them.  We could have, for instance, used:

However, to do that would have involved either a dedicated template, or a series of conditionals in order to ascertain what segment 3 contained.  In this case, by simply using the logged in member’s username, we were able to create a clean, optimized template with all the functionality that we required.

It is easy to see how important URL segments can be to ExpressionEngine; not just in the normal usage, but when we vary up what they mean, and define our very own semantics. 

When I took over the leadership role at the center there were a lot of dysfunctional practices and systems that needed overhauling; one of them was the way we hired new staff.

Traditionally, we had run ads in the local paper to attract candidates. Each person interested in working with us was required to come to the center to pick up a copy of a three-page application that he or she would need to complete and submit with a resumé by a deadline. The Director of the center would then review the applications, pick eight to 10 candidates and line them up for 30-minute interviews. At the end of the day of interviews, one candidate would be chosen by the Director and would receive a job offer by phone while the rest were mailed a postcard informing them they were not chosen.

That system had a lot of room for improvement. One day, I just couldn’t stand it any more and I set out to design a new system.

For starters, why have all candidates fill out three-page applications if, instead, you could screen them for interviews based solely on their resumés? Most of the information on the application was already in the candidates’ resumés, so why would you want to look at the same information twice? It takes twice as long to review all that extra paper. If you have 200 candidates submitting resumés for an opening, why on earth would you want to add 600 more pages of information to review, especially if you only needed that information for, say, maybe four people?

We made a new rule that the three-page application would only be filled out by people we invited for a second interview. If you weren’t invited to interview, you received either a yellow postcard from us thanking you for your submission and stating that your resumé was reviewed but we didn’t feel it matched the set of experience we were currently seeking, or you were mailed a green postcard letting you know your resumé would be kept on file. We sent out very few green postcards, but we actually contacted these folks and ended up finding a couple of good hires in our “green poll.”

We really wanted to screen our candidates better than we had in the past, so we divided up the interview process into three steps: Step One was with me, the Director, Step Two was with the Head Teachers, and Step Three was with some of the children in a supervised classroom setting.

After the Head Teachers and I had reviewed all the resumés, we would sort them in order of preference and I would invite the top six to eight candidates for a one-hour interview. This interview was one-on-one with me. During the hour I would take the applicant on a tour of our center so the candidate could see the full facility. I would explain our organization’s culture, the compensation package we were offering and our employee benefits. I would also ask the person five questions and note his/her responses. I asked every candidate the same five questions:

1. If I asked a young child you taught, to describe what he or she remembers about you 20 years from now, what would the child/adult tell me?
2. What is/was the single most difficult challenge in your life that you have overcome?
3. What are you passionate about?
4. What will you be doing five years from now?
5. What would you die for?

Finally, I would hand the applicant a copy of our three-page application and ask her to go home to think about our interview, the center and everything she learned about us, and to decide if this was a place where she would enjoy working. The candidate could call me anytime after 12:00 noon the next day with an answer. I would not accept an answer any sooner. If she called and said he didn’t want to work with us, I would wish her well, and encourage her to share what she had learned about us with others. If she did want to join our team, she needed to submit the three-page application with references within 48 hours and schedule a second one-hour interview, this time with our Head Teachers.

About half our candidates would bail out at this point. This was great as I didn’t even have to consider them for the job, they hadn’t used up any of my Head Teachers’ valuable time and they made the decision not to work at the center before we had invested much energy in them. Also, those folks were not rejected and most left with a good feeling about us even if they knew this was not the right fit for them.

My interview with the potential candidates was all about finding out if our culture, pay and benefits were a good match with the needs of each candidate. The Head Teachers’ interview was all about the candidates’ educational background, teaching philosophy and current knowledge in the field of early childhood education. That second interview included teaching a short lesson and, just like mine, sent the candidates home to think about things over night. If at this point, after interacting with our Head Teachers (the two people who would be supervising a new hire most often), they didn’t think this was the place they wanted to work, they could opt out, and over half of them did.

If they still thought our center was a place they wanted to work, we would have them back for a third and final interview. Up to this point, the candidates had not been in any of our classrooms and had not interacted with any of our students or classroom teachers.

For our third and final interview, we would rely on the people in our building who were the best judges of character: our two-year-olds. I’ve never fully understood how this works, but two-year-olds in a group setting are brilliant judges of character. They can size someone up in short order and issue a definitive judgment on a person in the time it takes you to read, “Everybody Poops.”

The third interview involved the candidate spending 30 minutes interacting with our two-year-olds under the supervision of both Head Teachers along with the two teachers whose class the candidate was visiting.

If the two-year-olds quickly adopted the candidate into a playgroup and engaged in active play with the candidate, and the candidate appeared comfortable and confident in the playgroup, then there was a good likelihood we would extend an offer to the person. If the children did not engage with the new person on their own, or had to be prompted to play with the candidate, or ignored the candidate, then, regardless of any degrees or credentials, or flawless answers to previous questions, the person would not be offered a job with us.

After 30 minutes in the classroom, the Head Teachers would ask the candidate how he or she thought the experience with the children had gone and would share observations with the candidate. At the end of the interview, the candidate would again be asked to go home to think about the experience and decide if our center would be a good match. About one in four would opt out at this point.

If a candidate didn’t opt out, and the third interview with the children had not proceeded well, one of the Head Teachers would call the person and give the person an honest assessment of what our staff observed and what we would need to see in the future from this person should he or she ever decide to apply for another position.

If more than one person progressed this far in the interview process and we had two or three people who appeared qualified for the position, and none of us had any objections to the candidates, then it was my job to try to disqualify one of them. I would at this point call references, call the universities listed and make sure all their credentials listed could be confirmed. If we had only one suitable candidate, I had to check references and credentials anyway, so this wasn’t a big deal.

If all the qualified candidates survived the references and qualifications checks, then the Head Teachers and I would meet to pick the person we thought would best balance our current team in place. I would offer the chosen candidate the job. I would also call the other candidate to explain why another person was offered the job and why he or she wasn’t receiving the offer, and then I would ask this person to check in with me every two weeks if he or she was still looking for employment.

The final step in the hiring process was to run a criminal background check on our final candidate. If he passed this (and all of the final candidates did) then he had the job.

There was a lot we liked about this hiring process.

Within a year of implementing it, we experienced a 120 percent reduction in staff turnover. Other changes we made at the center also contributed to this sharp reduction in staff turnover, but this new interview process played a huge role in ending the revolving door of teachers the center had experienced for years.

About 80 percent of our top candidates self-selected out: half of them opted out after the first interview with me, and another 30 percent opted out after the interview with the Head Teachers. Very few candidates made it to the classroom interview, typically only one or two, and nearly all of them passed with flying colors. The two who didn’t opted out.

By the time we extended an opportunity to someone, she had already spent an hour with the center’s Director, accepted our pay and benefits structure, our culture, our work place, who her supervisors would be and what their personalities were like, met a couple of our classroom teachers and seen our most challenging children close up and personal. She had been given at least three chances to opt out if she felt this was not the place she wanted to work.

Also, I had spent an hour with the candidate, our Head Teachers had spent two hours with this person, our office manager had interacted with him or her, two of our classroom teachers and over a dozen of our students had had a chance to observe this person and express any concerns before a job offer was made. We had a lot of folks engaged in the process.

We did not involve the parents of the children in the hiring decisions. We thought about it, talked with our Parent Advisory Board and the decision was made that the system we had did such a good job of selecting the best people for the job, the parents did not feel the need to be involved before a new teacher’s first day.

By the time a new teacher was hired and placed in one of our classrooms, he was committed to working with us, and we were confident in him and committed to seeing him succeed at our center. The new teacher felt like he belonged there, and we felt like he belonged there.

While the ultimate responsibility for hiring the right people rested with me, as I was the Director, the functional responsibility was shared among myself, the Head Teachers, a couple of our most experienced classroom teachers, the candidates themselves and even the children. This not only did a great job of ensuring that we had the right people on our team, it also meant that new hires were accepted by and integrated into the rest of our team much, much faster than ever before, and this helped to ensure their success.

Choosing the people who will serve on your team is arguably the most important decision you’ll make in your company. How you go about selecting those people should be given a considerable amount of thought.

The new-hire selection system the staff and I developed for the childcare center is likely not a great match for you if you’re hiring folks for a web firm, unless of course you happen to have a dozen two-year-olds running around. It may however, encourage you to consider your own firm’s hiring process, and how well your process is meeting your needs and the needs of the folks on your team.

What are you doing to make sure you find the right people for your team?

One of the things that newcomers often don’t realize with ExpressionEngine is that the templates really are entirely under your control.  Expression assumes very little, so it follows that the weblog entries tag outputs only what you’ve told it specifically to output, and this leaves the design entirely in your hands.

While the default templates ship with CSS based layouts, a bug tracker is definitely more tabular data.  So let’s explore how to create a table with the weblog entries tag.

Creating a table within the weblog entries tag is all about controlling the table and table row repeating elements.  We have to remember that everything inside the weblog entries tags loop, and unless you are very specific, your table tags will loop as well, putting each entry in its own table.

At the same time, we don’t want the table tags outside of the weblog entries tags.  Why?  If there are no entries, we’ll have an empty table!

So, what can we do to exercise the control we need?  Bring on the conditionals!

First, we want to open our bug_tracker/index template and locate the {exp:weblog:entries} tag.  We’ll start there.  You should already have this line in your template:

Now, right under that, let’s add our first conditional:

So here we can see that we’re comparing {count} to the value of 1; this tells ExpressionEngine to output this information only if we’re on the first entry in the loop. This is useful as we want our table and table heading tags to appear only once.

The table headings consist of the basic information that we need when listing out bug reports.  So now we simply need to get the rest of our custom fields, status, and ID into our table in the proper locations.  To do that, we simply follow our table headings, with the appropriate variables inside a standard table structure:

Lastly, we want to close off our table, but we want to ensure that only happens after the last entry.  To do this, we’ll compare count with {total_results} so that only if they’re equal, we output that final code:

This code between our weblog entries tags ends up with a result like that should look similar to this:

And the full code, now, for our bug_tracker/index template is like so:

You’ll most certainly want to style your table down the line, as well.  But for now this gives us a working, informative, tabular list to output our bug reports, and we can now move on to sorting and filtering this information in a way that will be useful to both bug reporters and developers.

I launched the site for my new web business on April 2. It was ready for launch the day before, but I just couldn’t bring myself to launch on April 1 due to that day’s association with foolish endeavors. For the next few months, I continued to play music gigs and do construction work part-time, while I refined my skills as a web site builder and continued to market my web services.

Nearly every week, I attended some sort of consultants’ group meeting or met for coffee with some established web-services provider in my area. I was networking with people as much as I could stand, but it hadn’t paid off for me yet. My new business was nearly six months old and I didn’t have a single paying client signed up for services.

One of the tech meetings I attended was with a group of volunteers planning an event near my home called Penguin Day. The intent was to bring geeks, consultants, nonprofit staff and open source software developers together for a day of learning and conversation. This was the next-to-last meeting of the volunteer planning committee before the event.

One of the volunteers was reading through a checklist of everything the committee had accomplished, and what it hadn’t. Of the remaining goals needing completion, two included the creation of a website and an online registration system.

It was about two weeks before the event, so the committee was about to give up on the site and the registration system when I spoke up. I said “I can have the site and the registration system online and ready for you by noon tomorrow, if you can give me the information you want on the site and a list of fields you need to capture in the reg. form.” The committee of tech-savvy volunteers giggled nervously and looked down into their notes in an attempt to be polite about my outlandish claims.

Four hours after the meeting ended, I emailed the lead volunteer on the committee a temporary URL for an EE CMS site that was all set up and awaiting his content. I also sent him a link to the reg form. He was a little surprised at how fast I accomplished this. I had built the site in EE and the registration form in PHPList. At the time, EE was pretty new to me and building a fully functional site in four hours was a personal challenge; I just wanted to see if I could do it.

By the next evening, the new site was live and we had the registration form working and connecting people to PayPal to make payment. I was able to add my firm to the list of sponsors for providing the website, hosting and the online registration.

In the two weeks prior to the event, the website received plenty of updates and the online registration system processed about half of the 100 or so participants. The site worked! There were some on the volunteer committee who grumbled about the site being built on EE because EE was a licensed product (not free open source), but no one complained about how well everything worked.

The night before Penguin Day, I told my wife I was going to snag my first client at the event. I didn’t know what organization it would be, but I was determined to find a client there. The next morning, while getting ready to leave the house, I kept telling myself I would come home with a new client’s contact information. On the drive, I imagined striking up conversations with people looking for a web site developer/designer.

Had you seen me that day, you would have thought I was running for office. I wore a nicely pressed shirt, a full-color homemade nametag with my new firm’s logo on it and I had a pocket full of my business cards. I purposefully introduced myself to everyone in the room and tried to hand them my business card and talk to them about what it was my web firm did. I talked about my firm as if it was well established and a recognized name, even though none of these folks had ever heard of it before.

At lunch, I asked if I could join a table where people from three different nonprofits were sitting. Halfway through lunch I moved to another table. By the end of the day I had handed out about 50 of my business cards and had collected about 20 from other individuals. I told everyone who would listen what it was my web firm did and that it was currently accepting new clients.

Even though people had never heard of my firm, or me, being a sponsor of the event meant my logo was printed on the handouts and I was given a couple of minutes to introduce myself and my firm to a captive audience.

The evening after the event, I sent personal thank-you emails to everyone I had an email address for. I thanked them for attending the event and asked them for any feedback I could pass along to the volunteer committee for planning the next year’s event.

Within two weeks, I had my first two clients signed up for website services, and I had met both of them at Penguin Day. The best part of this story is that, all these years later, those first two clients are still with the firm.

When I started in this business, I didn’t have a network of established contacts that could refer services to me. So I had to start from scratch, surfing the Internet for local meet-ups and tech-related trainings that I could crash as a way of getting out in front of potential clients. It was not the easiest way to get started, but it worked.

Presenting at technology meet-ups (like Penguin Day) continue to be a good investment of my time. I volunteered to present at another event about a year ago on the topic of how nonprofits were utilizing the new web technologies, and I ended up with five new clients from an audience of about 40 people. That has to be my most successful presentation to date.

How did you get started? How did you meet your first paying client? Did he come to you by referral, did you meet her at an event, or did that person just find you online? Please share your story with us.

First, we have a beer debt to clear! Steve Hambo had a case of James Boag’s Premium Lager delivered to our hotel for SXSW. After several grueling days at SXSW we were exhausted and Steve’s gift came in quite handy.

Our SXSW 2008 experience can be summed up in two words, wonderfully exhausting. In 2007 we felt we stayed too long and in 2008 we didn’t stay long enough. We arrived, we worked, we talked, we had Steve’s beer, we left. Next year I plan to stay a day or two longer just to meet people and hang out without the pressure of a schedule looming over my head. I think most of the team felt constantly rushed with the exception of a few hours Sunday afternoon.

We arrived late Friday afternoon and stayed up until 2am finishing the presentation. Saturday we were up by 7am and off to the convention center where we presented three times and concluded with a Q&A. That was the exhausting part.

The wonderful part was getting to throw a great party for the community! For three hours we got to take off our work hats and just share a beer or three with the community. It was a stellar experience and worth all the effort it took to pull it off. That was followed up by a relaxing time at the Solspace Nightcap. You can find a number of photos in the EllisLab SXSW 2008 Flickr Pool.

As promised we released the information on EE 2.0 to the public though if you’re reading this chances are you’ve already seen it. Andru from GearLive did record the Q&A session but had a very legit delay in getting it out. You may want to send him a friendly nudge to get it released. By the way, Andru it was great to finally meet you in person! That goes for everyone I was able to shake hands with and spend some time with.

At this point most of you are likely wondering “this is all very nice, but where’s the latest 2.0 news?” For the time being we’re laying low with EE 2.0 news. There are several important items the dev team wants to finish before releasing new information. Right now we’re being highly productive and don’t want to interrupt that until we’re ready for a break. This means we’ll all have to be patient as we want to tell you what we’re working on as much as you want to hear it. 

Stop by the forums and join us in giving Ingmar an official welcome. 

Vote for the ABA Journal.

Vote for MyTerritory.

Vote for Truthdig.

Hat tip to Mitchell and Travis for the heads up. 

“If you can’t be number one in your market, redefine your market.”

I spent a few years involved in Public Radio. I was a volunteer disc jockey and producer for a jazz radio station. I produced a weekly four-hour program that was one of two specialty shows on the station. Most of the week the station played jazz recordings, but on Sunday evenings my show featured music that was categorized as “New-Age.” It was not, by most listeners’ opinions, jazz. Many people hated the show and thought it had no place on a jazz station.

At the time, I was earning a living as a jazz drummer. I played music and/or taught private music lessons several nights a week and was going to college during the day. Sunday evening was just about the only time slot in my schedule I had available to volunteer at the radio station.

Even though the station needed a producer for the Sunday night program, the station managers hadn’t asked me if I would like to take over the time slot because they didn’t think I would be interested in programming a New-Age music show. I was a jazz drummer after all, and this was a New-Age program; surely a working jazz drummer wouldn’t be caught dead playing New-Age recordings in public. I surprised quite a few folks when I agreed to take over the show.

The first thing I did was study the market to see what else was on the air on Sunday evenings. Turned out this was the only show of its kind on the air in our town of about 40 radio stations. It was one of the few locally produced specialty shows where most of the music was on CD instead of vinyl (tells you how long ago this was), so the quality of the recordings was pretty high. It was also broadcast from 7:00 pm to 11:00 pm, which is a good chunk of the evening for most folks.

The first few months on the air, I took notes of all the calls I was getting from listeners. Some of them yelled at me and even threatened me; others loved the music I was selecting. After a while, I noticed some patterns in the callers and their comments, and I started to experiment with the flow of the music to see if I could get more positive calls and fewer highly enraged “jazz-experts” calling to ridicule me.

After about six months on the air, I saw my first ratings book, which was a poll of what kinds of listeners were tuning in to the show, taken by an independent ratings business. I learned that nearly the entire audience was composed of men in their 40s and 50s. There were a couple of thousand listeners, according to the ratings. I really wanted a bigger and more diverse audience, so I took a close look at my notes from the calls I received, my only other listener feedback and made more changes in the programming.

I played tracks with drums in them, mostly up-beat, soft-rockish tunes for the first hour, then slowed things down with tracks that featured just two or three instruments at a time—solo guitar, piano, and harp. About 10:00 pm I would play a half hour of electronic instruments, and finally, in the last half-hour, started slipping in some jazz ballads to ease folks back into the standard jazz programming.

When the next ratings book came out a few months later, the station manager called me into his office. I thought I was getting canned. He held out the ratings book so I could see my time slot in relation to the whole market on Sunday nights. In six months, the show went from less than a 1 percent audience share to 19 percent of the whole market between 7:30 pm and 11:00 pm.

This was a show that played music most folks had never heard before, during a less than desirable time slot and on a college station with an unreliable broadcast signal. The show was pulling a big share of the women in the market at that time slot and a much broader range of men than any other single offering. Little college radio stations don’t get this kind of market share around here. It just doesn’t happen.

Within a month of that ratings book coming out, three commercial stations in the market launched new locally produced programs to compete directly with my show. They played some of the same artists I featured and tried to copy my format. Over time, the new shows grabbed half my audience away, leaving me with just 9 percent of the Sunday evening market.

In that first year my show went from 1 percent of the audience share to a solid 9 percent and inspired new listening opportunities for another 10 percent of the Sunday evening market. My show held on to its new audience for at least the next four years that I continued to produce the show. It was the first regularly scheduled, locally produced radio program of New-Age music in the market, and the music we played was not only different from any other music on our station at the time, but it was also different than anything you could find on your radio dial in our market.

It was being first in the market, and very much counter programming, that fueled much of the program’s success. I would like to think that having a musician programming the music had something to do with the show’s success too.

Fast foreword a decade to when I was laying the groundwork for my web services business, and that experience in counter programming and being first to do something in the local radio market played a big role in my decision to choose nonprofits as a target audience for my web business.

When I started looking into who was serving the nonprofits in my area, there were only six web firms locally and four nationally that had an established presence. I live in a state in the U.S. with over 11,000 registered nonprofit organizations, so I figured there’s no way this small number of firms could keep up with demand for CMS-based websites. There were so few web providers focused on nonprofits that I took the principals of each firm out for coffee to meet them and to find out if any of them had a compelling reason I shouldn’t go after the nonprofit/education market in our area. None of them did.

Within five years, my web firm became one of the largest providers of web services for nonprofits in the local market. We weren’t the first ones on the scene, but we were the first firm building all our sites in a CMS called ExpressionEngine. We also were the first to offer a two-year comprehensive website subscription-based service plan instead of either an hourly project-based service or the ever popular Application Service Provider model.

Not only were we among the first to serve a segmented client base that almost no one was going after, but we were also the first to offer EE-based CMS style websites and a comprehensive service plan as a package deal.

If your web business is in its infancy, or you feel like your competition is grabbing all the “good” clients, then I recommend you sit down with your favorite search engine to start looking for underserved market segments in your area.

Is there a firm specializing in CMS intranets for small business? Is there a web firm in our town serving all the private schools, the local artists, the farmers, the used-car dealers, the home remodeling companies? How about the CPAs, the lawyers and other professionals? Who’s underserved in your market and who is going to need your services six months from now or a year from now when they are ready to make the leap from static websites to dynamic? Are you placing yourself out in front of them so they can find you?

Need some inspiration? Head on over to our Professionals Network and read through the profiles. Note how many EE Pro Net users are focused on creating websites for a specific market or a small group of markets. Note how many of them were early adopters of EE and among the first to introduce a whole new market segment to EE. These folks know the benefits of being first and carefully choosing one’s market, and stand to benefit from that careful positioning.

Sure, you’ll still want to pick your clients, but being first in your market can play a huge role in your success.