From time to time here at Mars Hill Church we receive emails with questions about the work that we do, who does it, what we use to do it and how the magic happens. For the second installment lets look at the website that kicked off the current sermon series, askanything.marshillchurch.org

Q. I’d love to get some background on how you developed the Ask Anything app - a very nice app, by the way. Was it all custom?

A. The short answer is “yes it was custom, thanks”.

The big idea was taken from the letter to the Corinthians, wherein Paul uses his letter to answer some popular questions from the church body in Corinth. We wanted to take a few months to collect questions and then take a one Sunday each to preach and answer the top 9 questions.

Development and design was an all done in-house here where we knew generally what we wanted out of it, though we also let the needs evolve as we developed it, and we could get things going quickly and adapt as need, so it ended up being coding in Ruby on Rails.

We looked into some more off the self type solutions, such as ShouldDoThis from the great Robot Co-op guys here in Seattle, but they often did not offer us enough control over the presentation nor the content posted by users, and any kind of phased approach. Though we wanted it to remain as open and as organic as possible, knowing we were opening this up to the world, we planned to need some level of control over things such as vulgarity, personal attacks and completely off topic questions. We did want our admin involvement to be as minimal as possible though.

Going into it there were a few key things we knew we wanted:

1. We only wanted positive feedback, so we did not go with voting things up and down, we only wanted people to be able to vote FOR something, not against it.
2. We wanted it to have a very low barrier of entry for people to ask questions. So we decided to not have a login. Which we knew meant we could not control gaming the system very easily, but we kind of liked that.
3. Although we wanted it to be easy to add questions, we still wanted good questions. So we decided to limit the amount of characters that could be used to 200. It was a somewhat arbitrary number, but the point was to make people think about the heart of the question and not ramble.
4. We wanted a broad audience, so it should be easy to share the question you asked with your friends. So we made sure each question had a landing page with a URL that could be blogged or given to friends and encourage them to go vote.
5. We wanted it to be sticky, interesting and as fair as possible. So we opted for 10 votes a day and a basic comment section for each question. Then later added a small blogging section and RSS features.
6. We wanted some self moderation by users. So we allowed flagging of questions and comments by anyone. These went to a queue and were reviewed by an admin . If a flagged item was approved then it could no longer be flagged. We later also added the ability for users to suggest a similar questions that should be merged.

Overall the site worked great, and was a success. We ended up with doing 4 phases.

Phase 1- Open voting, where anyone could post any question onto the site and vote 10 times a day on any question.

Phase 2- Site closed to new questions. We stopped taking questions about 2 months into it with almost 900 questions asked. Then allowed a month of continued voting on all questions.

Phase 3- We reduced the available questions to the top 50 and let voting continue. During this phase we also merged similar questions, based on user suggestions. To do this we combined votes from similar questions and if needed we reworded the question to include any content from merged question as well, we tried to minimize those changes though and leave the questions as intact as possible.

Phase 4- Initially we had not planned on it but it became apparent that we needed to limit the 50 questions and focus attention on the most popular so with about 20 days to the end we removed all but the top 20 questions. Many of the lower number questions at that point need too many votes to be viable for th top 9.

What did we learn:

1. Where people can cheat they will. We spent a good amount of time watching and deleting votes from people who voted thousands of times a day. Also there is really no fool-proof way to watch IP addresses and sessions and cookies to be 100% accurate without a login.
2. People have a lot of time to debate theology and talk trash to other Christians on anonymous forums. I often thought we needed to offer an apology to some peoples employers.
3. We love Ruby on Rails. It was confirmed that we like developing in this and is now where we are investing our development efforts for most new projects.

Let us know if you have any more questions and we will try and answer them in the comments.

From time to time here at Mars Hill Church we receive emails with questions about the work that we do, who does it, what we use to do it and how the magic happens. This time we’ll start off with one of our more common ones…

Q. I was wondering if you would mind sharing who designed/engineered marshillchurch.org?

A. The short answer is “some great Jesus loving volunteers”.

Over the years, like any good site, the main Mars Hill website has gone though several iterations, as many hands have been put to work for the gospel. A core value of the work we do around Mars Hill and in technology is that it’s all worship, and that has lead to a great team of volunteers who see the design and development of our web properties to be a time of service and worship. The current marshillchurch.org was lead and organized by a few on staff while the execution and implementation was carried out by some very talented individuals who have given countless hours over the years to provide great looking sites that host and deliver our content worldwide.

So that said, we do not currently use outside vendors for the development and design of the site, we do have some more dedicated staff now, but the site for the most part resides in the hands of the faithful; both volunteers and staff.

Have you ever used the site and thought I could do that better, why don’t they do things like this? Then its time to come help out and get connected. Every Thursday is Tech Night at the Ballard Campus and we are always in need of designers, flash developers and whatever code you know, we have a project that can use your skills. So email zack(at)marshillchurch.org or just stop by on Thursday nights.

We’re about to enter into Phase 2 of our Ask Anything project. If you’re not aware of Ask Anything, I encourage you to head over to the About page and take a peek at it’s contents, but basically we’re following the example of the Apostle Paul in fielding questions from the people he cared about. In our case, it’s all of you, so head over there and vote for your favorite questions.

In switching to Phase 2, we’re going to take the top 50 questions, put them all on one big page, and let you decide which become the Top 9. These Top 9 will be determined on December 14th, 2007, by whichever 9 questions have the most votes. They will become the sermon series Pastor Mark preaches in January 2008.

So have you wanted to ask Pastor Mark a question? Head over there and do it!

Last week, I came across a good explanation on how social networking “works” from a local Seattle native:

Now, the hidden benefits that the Social Network revealed in the case of this video were such things as a new job or relationship, but these are by no means the limitation of this technology.

Quite recently, knowledge itself has been recognized as something that could be leveraged through your Social Network, something that those that use our Member’s Site to get good referrals already know.

What if Social Networking was redeemed and used for more than just selfish ends?

Context is important. I think we know that. Context refers to the conditions in which something exists or occurs.

It’s important when we read scripture to have an understanding of the context of the verse, not just pull it out and base our world view on the Christian life from one verse.

It’s important when we talk to people to see facial features and gestures, its actually often more important than what the person is saying. Just start using IM for every conversation you have (something I practically did for 8 years) to see this theory in practice.

Its important in relationships when we praise or rebuke someone, that there is an understanding of the context from which that comes.

I believe it is also important to at least think about the context of the content we produce. What are the contributing factors that effect how that particular content in perceived, reacted to, and used. I think some of those questions can help understand the context in which we place our content and better understand what the best avenues are for the content we have to distribute.

Below is a table I have worked up and referenced at times to put my own ideas in context and help me understand what to expect from them.

Some useful links:

• Context in User interface design : “Putting Context into Context“
• The Nature and Purpose of Online Conversations
• Art and Context: Rules and Context
• The Resurgences’ upcoming conference “Text and Context”

RSS Feeds.
Feeds, Feeds, Feeds.

We love our feeds at this church. There is an RSS feed for pretty much every piece of content we put out online, and we put out a lot of content. I have to admit, it is quite a convenient way get the information you want in this over bloated information age that we live in, the only way to avoid information overload, which in some cases can lead to insanity.

They are very convenient, until one of your feeds has an issue and you’re the tech guy charged with fixing it, then it can just be a giant frustrating mystery.

So what is this all about, well, we have many feeds that come out of our Voxpop network site. Voxpop is a site of many blogs and many feeds, but one in-particular has been troublesome, the Voxpop Master Feed. The Voxpop Master feed essentially contains all the latest blog entries from ALL the blogs on our site. The problem stems from the application we use to manage all these blogs, that application is called Wordpress MU. Now for you non blog geeks out there, Wordpress is a very popular open source application that lets you publish a blog and a feed to the blog very easily, and works very well. Wordpress MU is a version of Wordpress that lets you publish multiple blogs, and multiple feeds in one system. The one lacking feature of Wordpress MU, is it doesn’t have an RSS feed aggregator that would produce one feed from all the various blog entries. It does great publishing individual feeds for individual blogs, but nada on the one master feed idea.

So, we did what every self respecting open source user does when they meet a limitation of the software, we wrote our own master feed aggregator. Actually, a very faithful volunteer wrote one, and it worked great, put out a master feed that just about every RSS feed validation tool said was perfect. So, what’s the problem? The problem was feedburner. We use feed burner to give us statistics on RSS feeds (ie, how many people subscribe to our feeds, what is the feed traffic, etc). Feedburner takes our feed, then returns our feed to us, while keeping track of statistics so we don’t have too. Sounds simple enough, but for some reason, feedburner was having an issue with the master feed. It wasn’t automatically getting new content from the master feed. When the master feed got updated with new content, feedburner wouldn’t see it, so the feedburner feed didn’t have the new content. The only way to get feedburner to see new content, was to manually ping the feed using a tool that feedburner provides, but this is very tedious to try and do every day, so we had to find a solution.

One of the frustrations that we faced with this issue is that feedburner doesn’t really provide any information on their side as to why a feed hasn’t been updated. I mean, when we manually pinged the feed, it updated just fine, it said the feed was perfect, no problem. It just wouldn’t tell us why it hasn’t been updating the feed automatically as it was the other feeds. If there was something wrong with the feed, we would have gladly fixed it, but you need to tell us what the problem with the feed is, otherwise, we spend a lot of time just guessing and tweaking, which is where we found ourselves.

So, what now? Well, I began looking around the intertron, and found a feed aggregator plugin that someone else wrote called WPMU Sitewide Feed . Sounded interesting, and exactly what we were doing. So, we tried it out, and it worked great. It did everything we wanted, and feedburner was much happier.

So, we just wanted to say a public thank you to itdamager.com, and recommend this plugin to anybody else who may be struggling with this issue.

Thanks