A Step By Step Process To Develop An Optimized Online Community Website


(Sarah Hawk) #1

The launch of this site marks the completion of my second community platform design/build/migration project and I’ve learned a lot from both. Here are some of the lessons I’ve learned, along with some useful resources.

Building something like this takes time and money.

Bespoke software is expensive. It’s also not the best approach for a community platform in my opinion. Too much time is spent reinventing the wheel. What we decided to do when we planned this site, was take two established but flexible platforms (WordPress and Discourse) and integrate them to create something new and appropriate to our audience.

I began this project when I started with FeverBee in January. The rest of the team already had an idea of what they wanted to achieve and had put together the bones of a functional spec.

I began the conversation with our development team on January 20th 2015. We soft launched on July 13th.

It took 6 months from start to launch.
It cost US$20k for the platform customisation.

On top of that there are some extra costs:
$2k for a Discourse consultant (our dev team had no Discourse experience)
$120 for a WordPress template (we are using Eptima by Sketchthemes)
$264 for a font (we are currently using Rehn Condensed)
$450 for a designer (to design our homepage)
$60 for an EU cookie compliance law solution (we use Cookie Control by CivicUK)

Ongoing costs:
$20 per month for secure WordPress hosting (we use Cloudflare)
$220 per month for secure Discourse hosting (we use Discourse)

A very important thing to note:
I managed this project and wrote the inner pages (i.e the pages which aren’t the homepage). If you don’t have someone on your team with the experience to do both these things, you can probably add another $10k onto the bill.

Platform limitations

Discourse has been around for a couple of years now but it has really only recently started to become mainstream. It is open source so theoretically you can do anything you want with it, but in reality there are limitations. Firstly, unless you self-host (which I wouldn’t recommend unless you have a dev team that are comfortable working with Rails), you are limited to what you can change through the admin panel.

Secondly, Discourse is very much a work in progress and as such is frequently changing. In my previous job we made the mistake of very heavily customising it, to the point that we hamstrung ourselves and couldn’t update without having to rework a whole lot of things.

Don’t let this put you off though. Start simple, and then if necessary, commission plugins. Discourse has a marketplace where you can find developers to work with, although at the moment the demand well outstrips availability.

Plugins

The plugins that we currently use for Discourse are:
Discourse-Akisment (spam protection)
Discourse Tagging (adding tags to posts)
Polls (for creating polls)

And for WordPress (aside from a number of standard SEO and comment validation plugins):
WooCommerce (for selling resources)
Mailchimp for WordPress Pro (sends new signups to our mail list)
Discourse for WordPress (ports article comments to Discourse)
Username changer (by default you can’t change your WP username)
Paid Memberships Pro (for subscriptions)
Shareaholic (for social sharing)
Primetime WP Discourse SSO (for single sign on across platforms)
Stripe for WooCommerce
WordPress Social Logins (for login in via social media)

WordPress Themes

If you decide to use WordPress, you can choose to base it on a theme or a theme framework. Your developer will advise you. Frameworks are more flexible but require more work and therefore the site will cost more to develop. Themes allow you to choose an aesthetic that suits your brand, and come with built in modules that offer different functionality. They also mean that the non tech-savvy people in your team can control the site using the UI.

Free themes are available, but not recommended. If you want something secure and robust with good support, you’ll need to pay. A good theme will cost somewhere between $50 - $200.

The biggest theme marketplace out there is Envato’s Theme Forrest, but beware of their exorbitantly priced extended licenses (which you’ll require if any part of your site is behind a paywall).

PremiumWP also has a great range, as do Creative Market and Mojo Themes.

Important note: Any theme can be customised so focus on the overall look and feel (does it reflect the professional/fun/slick nature of your brand?) rather than the granular details. As mentioned previously, this site is based on Eptima by Sketchthemes.

Integrations

We use Stripe for managing our sales and subscriptions and MailChimp to automate our on-boarding. We’re happy with both decisions, but there are a couple of things to note.

When migrating data from Braintree (or any other payment platform) to Stripe, subscription data isn’t transferred, so you’ll need to manually recreate any subscriptions. Unfortunately that process tripped fraud triggers with a number of credit card providers, and the payments were blocked.

When new members register with us, their details are automatically sent to a list in Mailchimp. That kicks off an automated series of on-boarding emails. We think this is crucial and recommend it for any new platform.

Working with designer

One of the first steps in a project like this is coming up with a design. We worked with Joel Carlo to design our homepage, the rest we did ourselves. Try to avoid designing by committee – it drags out the process and can result in everyone feeling disappointed. Make sure you have a clearly documented concept (and ideally wireframes) when you go to the development team.

Working with a developer

We used Grazziti, who are based in India, to do the bulk of the development. They are great to work with and very reasonably priced. We negotiated a fixed price for the project which included project management on their end. We would definitely recommend Grazziti, but note that although their technical work is top notch, they are not very strong on design, so make sure you have that side covered.

Where community and UX collide

There are almost always aspects of a UX project that have to be compromised. A UX designer’s primary goal is to minimise the cognitive load required when consuming a web experience. Two of the key ways to achieve this are to provide short-term memory support (achieved by visually displaying things that would otherwise have to be remembered eg: change the colour of links once visited) and using recognition over recall (eg: using internationally recognised icons or unambiguous CTAs).

I came to this project from a UX angle, Rich from a social psych/marketing one. We both had to compromise our ideals on a few things.

The Ask FeverBee button
Good UX practice dictates that button labels describe what will happen when you click them. For that reason I proposed that the homepage CTA was labelled Start Discussion. Rich suggested Share Tip or Get Help because he wants to nudge and train people when to use the site (ie he wants the discussions to be practical and focussed). We settled on Ask FeverBee but that will likely change. We’ll test a few options.

Gridlines
Our vision for this site is to have crowdsourced content blended with our own content on the home page – a one-stop community shop. Part of our strategy to encourage people to post great content on the forums is to display their avatar on the home page when they contribute, in essence strengthening their personal brand. I love the idea, but without visual cues, people have no idea where the content is coming from. My initial design included gridlines between rows which would carry source indicators (New from FeverBee, Latest from the Community, More from FeverBee etc). We ended up doing away with those so that we could maximise the content displaying above the fold.

We compromised by using round avatars from Discourse on the community posts, and square ones on the blog posts. It is still not best UX practice by a long shot, but I can live with it.

Launch with something and then refine it.

It’s very easy to make assumptions about the way people will use a platform, either because that’s how you’d use it, or because that’s how you hope they will. It’s important not to get too bogged down in the minutiae at this point. It makes more sense to launch with something functional and then tweak things that aren’t working.

Use a tool like Optimizely to test different options. Make sure that you launch with analytics or you won’t have a clear picture of what those things are.

My No 1 tip for new players: Test early and often

If you’ve never developed software before, you probably have no concept of how much time goes into testing. Testing is not a one person job. People follow processes differently and have different requirements, so it’s easy for one person to miss something that might be important to another. It is also crucial to encourage all stakeholders to start testing processes as soon as they are stable, so that there are no surprises down the track when it’s too late to change things easily.

And lastly, test often. Changing one thing can have knock on effects across your site, so something that was working yesterday may get broken by seemingly unrelated changes made today.

If anyone is embarking on a project this large and wants support, get in touch, we can help.


Introduce yourself (or at least just say hi)
What's your (online community platform) flavour?
Insights on various community platforms
(James Higginson) #2

Very useful indeed, thank you @hawk


(Nick Emmett) #3

Really great post @HAWK, thanks for sharing


(Sarah Hawk) #4

No problem. There isn’t a lot of transparency around this kind of thing and I think it’s really important. People read ‘open-source’ and think ‘free’ which usually isn’t the reality.

We’ve made a lot of tweaks since I wrote that post, both styling wise and to correct functionality that broke when Discourse made changes to core. The communication of those changes and the potential ramifications isn’t as good as it could be.

Ongoing cost wise, as well as hosting I spend a couple of hours per week making small platform changes.


(Joel Zaslofsky) #5

@HAWK, your post about how you integrated WordPress, Discourse, and third-party services for things like billing and email marketing is a-maz-ing! Thanks a ton for writing this up with a huge amount of clarity and detail.

After three months of research, my Puttytribe partner and I have decided our first choice for migrating from Ning is the WordPress framework with SSO Discourse inside of it. There’s a lot in your post that gives me hope, and also a lot that gives me pause since our project budget is $20,000 USD max (although we’d like to be closer to a $15,000 spend).

We have some things going for us like an internal community team that can fill a number of project roles from Project Manager (me) to Design Lead (my partner). And we’re confident that a few of our members will step up once we ask them to co-create this new community platform (e.g., we have a good UX guy ready to go).

I’m just having trouble envisioning pulling off most of what you’ve done here at FeverBee with the Puttytribe – especially once the ongoing platform costs are factored in (e.g., the coding changes you’ve made when Discourse updated their core and broke some of your functionality).

So here’s a big question: now that you’ve been on Discourse for a while, what components of your project were non-negotiable and what would you put in the optional/nice-to-have bucket with the benefit of hindsight?

Also, if you have the time, have you ever considered licensing parts of or the whole custom WordPress/Discourse build to other communities? I imagine our Puttytribe team would be interested in something like that if the price was right.

(Side note: I’m intentionally excluding some of our project specs like the need for member created, led, and organized events within WordPress since I’m confident we’ll figure that out with the right WordPress plugin or another solution).


(Sarah Hawk) #6

Hey Joel,
You’re welcome. :slight_smile:

Pulling Discourse data onto the homepage was very important to us at the time, and that was a large part of the development cost. There are a few plugins around now that would potentially make that work unnecessary. Here is one example.

We moved away from a membership model so a lot of the work to integrate and customise Paid Memberships Pro was also redundant.

Without those two customisations our project would have easily come in under US$20k. It also sounds like you have the right mix of skills in your existing team to carry this off.

Don’t freak out too much about this bit. My background is .NET – which when it comes to Discourse and WordPress essentially renders me code-illiterate, yet I managed to handle this stuff by myself. If you have anyone onboard that has some basic coding skills, they should be able to stay on top of things with the support of the Discourse community.

The above assumes that you’re going with a hosted solution, not self-hosting. If not, you’ll need someone to manage upgrades and maintenance.

I’m happy to be grilled further on this stuff if you still have questions.

We haven’t to date. If you want to talk about it further, PM me and I’ll put you in touch with the right person.