RaceOneDesign.com is a new community website powered by Drupal 6 for one design sailboat racing enthusiasts. One design sailing is a worldwide sport with a long Olympic heritage. RaceOneDesign provides wind forecasts, how-to article publishing with both wiki and byline administration features, classified ads, blog aggregation, extensive use of mapping, and other features important to sailors in North America. The site was built by two sailors at a Drupal development company in the Seattle area in their evenings and weekends. We're still in the early stage of building out our content base and our community, and welcome any feedback or questions about our site!

RaceOneDesign Home

Key project features

  • Article publishing system with both "wiki" and “byline” editorial features, custom admin console, rich text editing and wikitext parsing, image/slideshow support, comments, taxonomy integration, request architecture, and trigger/action support.
  • Weather display of over 2500 weather stations shown on a Google map mashup with Ajax updating, with local observations updated every 30 minutes, 24 hour wind history, wind forecasts, and National Weather Service marine and zone forecasts.
  • Custom-built theme with flexible columns based on standard ad sizes, custom layout areas, and a "content stream” architecture for aggregating content.
  • Classified ads with taxonomy-based filtering, image support, and on-page response form using CAPTCHA.
  • Facebook Connect integration, custom login and registration pages, user profiles, drop-down user favorites, and contributions stream.
  • Directory of over 400 sailboat racing venues in North America, 500+ yachtclubs, and more than 100 one design types of boats. Each of these items has its own page, most with weather mashup and content such as articles identified by taxonomy.
  • External blog aggregation with taxonomy integration and integration into our “content stream” architecture.
  • Built using agile software methodology in a dev shop with two (very) part-time developers.

We are starting to push our custom modules up to contrib.

Contributed Modules We're Using

Devel module: Couldn’t live without it. Awesome module.

Administration Menu: Couldn’t live without it.

Content (CCK): We chose to build much of our information architecture directly in custom modules but use CCK for file and image upload.

Filefield/Imagefield: We use filefield/imagefield for image support on wiki articles and classified ads, although we have customized the theming and behavior of the standard imagefield form.

HTML Purifier: Used as part of our wiki/publishing system.

Mollom: We pass our comment and other text through Mollom. Awesome service!

Statistics Advanced Settings: Provides useful additional system stats.

Remember Me: Easy to use, easy to implement.

Masquerade: Very useful tool for debugging.

Taxonomy redirect: Great module! We have hooked in some custom caching to reduce the number of SQL queries on complex pages.

CAPTCHA/ReCAPTCHA: Provides security testing during registration and for certain form submissions.

Tagadelic: We’re testing tag displays on the site and Tagadelic has been a great module for generating displays through their API.

Views: We use views primarily for some admin-only blocks . We expect to do a lot more with Views in the future.

FCKEditor: The RTE for our wiki articles. We built a "lite" module to integrate FCK into our forms as a custom element.

Text_Wiki: PHP-based wikitext parser that we use in limited but important way to parse interwikis and wiki links.

Boost: Just need to read the install file carefully, but awesome caching solution. We chose because it works well with our Adsense component.

Site Layout

We are now on our third-generation layout scheme. It is not very flashy to look at since we are programmers on a shoestring budget and not graphic designers, but it is very clean and very flexible. Our goal is an uncluttered layout that provides just enough visual clues to help the user navigate through the content we provide.

The default layout (all CSS, except for our custom form theme) is three columns but it is easy to turn off or resize the first or third columns, or both side columns, on a page-by-page basis. Column layout is controlled by CSS tags that are set in template.php, but any module or page can choose from a large set of column options. This gives our custom modules the opportunity to suit the layout of their pages based on the “shape” of the content, and provides both a consistent look to the site and some "design motion" as you move through the site.

Content Streams & Taxonomy

One of the things we’ve developed is a “content streams” architecture that lets our different modules (wiki, classifieds, weather, blog aggregation, etc.) aggregate content for different presentation contexts such as the front page. A content stream is basically a list of teasers that are similarly themed. For example, on our front page, the list of “Articles” is one content stream and the list of “Classified Ads” is another content stream. A content stream can be inserted into a block or into any template-defined content area within a page. There’s nothing revolutionary about a list of teasers but we think the innovation is in how we control the aggregation of content and direct it into different layout areas.

Content streams are built on top of three key Drupal mechanisms—hooks, taxonomy, and the theming engine. Each of our custom modules implements a custom Drupal hook which fields a request for content for a particular context. The content is passed through the hook mechanism in an intermediate form (array), which themes it using the Drupal theming engine. Content streams can also be filtered by taxonomy term or vocabulary. With this mechanism, each module "sends" content on request in a standardized format for downstream formatting.

Article Publishing System/Wiki

RaceOneDesign Home
Although there are excellent contrib modules available for implementing wiki functionality, we decided to build our own module in large part as a learning opportunity. The result is what we call the “Superwiki” module, which standards for “supervised” wiki and is a blend of standard wiki features (community editing, history, versioning, diffs) and a more editorial approach to content creation (e.g., “byline” articles that only an author or editor can change). Our goal is to balance community involvement with editorial supervision. Our wiki has the following features:

  • Each article can be set up as either “community edited” or “byline” (meaning only the author can edit). This difference is reflected in editing permissions and in how the article is themed.
  • We use a request mechanism where any user can request an article but only a wiki editor or administrator can actually create the article. We store the text with the request and can easily create an article using the text submitted by the user. Every time a request is submitted the Superwiki editors receive an email message ensuring quick (though not instantaneous) response to user requests.
  • Integration with taxonomy. The wiki is divided into sections and articles. Each section is associated with a primary vocabulary that is used to organize the articles in that section. Each article is assigned a primary taxonomy term ID. This way, whenever a list of articles is shown, they can be organized by vocabulary and term.
  • Articles use an SEO friendly URL path and we permit up to three renames for an article with appropriate content forwarding. Users can request an article rename but only an editor or administration can fulfill the request.
  • We leverage Drupal’s revision system for maintaining revisions of each article and also use a diff engine for displaying diffs. Only a wiki editor or administrator can see an article’s history or revert the article to a previous revision.
  • We use FCKEdit for rich text editing. This has been a good solution for us because of the (relative) ease of customization of the interface. What is particularly valuable to us is the ability to control which editing features were made available to the user and to make certain features (such as source-code editing) only available to editors and administrators. We use HTML Purify on input text.
  • We use custom-built Drupal filters in conjunction with the excellent Text_Wiki wikitext parser to provide a limited but very useful wikilink (or interwiki) capability within article text to link to other articles (by title) or other nodes (by type:title).
  • We have built an admin console to help manage the wiki. The console shows the existing requests and makes it easy to create new sections, articles, etc. There is a separate “editor’s” page for each article that is used to set and modify structural aspects of the article, such as its primary taxonomy affiliation.
  • We use imagefield and CCK to manage the images associated with each article. We use form_alter and theming to modify the base imagefield form and use hooks to change the Description field into a Caption field and to reorganize how the preview image looks on the form. Once an image is uploaded we create several “preset” images for use in previews, at the top of the image display, etc. (No, we don’t use imagecache, since we wanted more control over how our images are stored.)
  • Users may specify up to nine images for each article and these images are combined into a slideshow. The first image of the nine is always shown on the article display page.
  • We enable users to email an article, print an article (displays a clean page of text, no columns etc.), and use the “ShareThis” system for social bookmarking/sharing.
  • For comments, we use the comment module and the Mollom service. We currently do not support threaded comments—all comments are at the same level. We have modified the theming of comments to better fit the structure and design elements on our article pages.

Weather & Mapping Mashup with AJAX

RaceOneDesign Weather
If there's one thing sailors have in common the world over it's an interest in what the wind and weather are doing. RaceOneDesign has an extensive weather backend: we gather and store data from over 2500 reporting stations in North America twice an hour (using XML parsing, METAR reports, and HTML scraping) and separately gather and store forecast data that covers the entire US. Our wind data is presented in several forms: (1) as a Google map mashup showing wind strength for reporting stations; (2) using an innovative scrolling meteogram called the WindTrak which lets users easily see the wind history and wind forecast for a sailing location; and (3) as a table of recent wind observations. We also provide zone and marine forecast data as part of our display. We will shortly offer daily email messages to registered users that show wind predictions for their racing areas. All our weather code is in a custom module and in back-end Grib processing. One of the features of our weather mashup is the ability to update the weather information via AJAX calls without refreshing the page, this way users can open their weather page in a browser and refresh it during the day by clicking on the "Update Weather Data" link.

Facebook Connect

We chose to implement Facebook Connect on our site primarily as a way to gain exposure and experience implementing the Facebook API with the expectation of richer integration down the road. We let Facebook users connect to the site but we do require them to register as users of our site during the initial FB connect session. Without a local registration we felt we could not offer several important features that require storage of user data. (For example, we store the user’s favorite weather locations, enabling each registered user to easily check the weather in several locations.) In addition, since we do not have access to the user Facebook email address, we request and store an email address for each user. The benefits to users: FB Connect users do not have solve a CAPTCHA when registering for the site, their photos show up in the user bar, and, once registered, navigating to our site in a browser when you are already logged into FB will automatically log you into your RaceOneDesign account.

Directory and Classifieds

Our racing directory provides pages for the many types of sailboats raced in North America, and for the yachtclubs and racing venues where people race. The pages associated with these nodes are created as accumulations of content gathered through our information streaming interface and themed with custom node.tpl.php files.
Our classified ads module uses imagefield for images, leverages our taxonomy, and provides a straightforward filtering interface using URL query strings.

Agile Methodology

Even though we’re a dev shop of two, early on we decided to use agile software development methodologies to help us create a rhythm for our work. We maintain a product backlog using Trac, hold weekly Scrum meetings via teleconference, do all work based on tickets, and organize our development into 30 day Sprints. The Agile methodology has proven to be just what we needed to keep us organized and focused, even for a (very part-time) team of two.

Hosting and Tools

Our weather backend requires significant Grib file processing and C compilation which we could not figure out how to do in a shared hosting environment. We are currently renting a dedicated server from Codero (formerly APlus) and have had good experience with them so far, although we are investigating EC2 for the future. We use a separate SVN/Trac service (www.hosted-projects.com) to maintain our code tree and Trac tickets. The other tools we rely on every day include the unbelievably great Firebug extension for FireFox, the FireFTP extension to FireFox, and the Windows-based TortoiseSVN client.

Comments

kaakuu’s picture

Very, very nice and very CLEAN design.Very good use of white space too. Looks solid, professional and the design allows to spend a lot more time on the contents with ease.

Thanks for sharing.

smooshy’s picture

Great site. I'm also a sailor and am already finding the site very useful and interesting. Especially like the weather section. Very useful, well laid out data. Did you decide to use the fbconnect module (http://drupal.org/project/fbconnect) or the Drupal for Facebook module? Did you have to do any development on that module or are you using it as-is?

Anonymous’s picture

Great, glad you like the site! Would welcome your thoughts on what else you'd like to see--we're at a point where we're looking at what has worked & not and prioritizing next round of features. We looked closely at the fbconnect module but in the end felt it was too much of a solution for what we needed, and ended up creating a more lightweight module, one that also tied more directly into our user data storage. We're working on packaging it as a contrib module.

smooshy’s picture

Great. Would love to see what you've done with it. Your implementation seems clean and straightforward and it's been frustrating with fbconnect since it doesn't seem to have any recent active development.

Anonymous’s picture

given my limited time it'll take a couple of weeks to get it together ready for contrib but I'll post the module name when it's available.

nally’s picture

Hey Guys,

I'm a Drupal dev and sailor from Galiano Island, B.C.

Awesome site! I'm signed up and ready to buy a Laser so I can participate. ;-)

Are you guys going to the upcoming Drupal Northwest Summit ?

cheers

Nally

Christian Nally - B.C., Canada - http://sticksallison.com

Anonymous’s picture

Great sailing up there in Galiano. Yes, planning to be at the Summit at least one of the days, let's plan to meet up there.

slippast’s picture

Well done! The site looks fantastic. I'm working my way through building a proof of concept user generated content site right now and I'm wondering how you did the slideshow piece? Is that structure something you built or something an idea you found? Sorry this question is out of right field but any insight would help me a great deal. Thanks!

kevinquillen’s picture

Could you elaborate a bit on Facebook Connect and why you chose that instead of something like RPX that supports many other services with FB?

===========
read my thoughts

Steven_NC’s picture

I see that one must register to add content and that makes perfect sense. Can you speak about the need for moderators/editors on the wiki? I am working on a community site and have concerns about permissions for adding content.

BTW, very nice work.