Welcome to the Geeks & God Static Archive. Read more »

Case Study: Muddy River Media.org

5

You are missing some Flash content that should appear here! Perhaps your browser cannot display it, or maybe it did not initialize correctly.

Have you ever looked at a website and wondered, "How did they do that?" In todays episode we explain how we built MuddyRiverMedia.org. You've been asking us for years how we built certain sites. Most of the time we shy away because so much of the fun stuff is site specific. This time around we dig in, we talk about modules, we talk about theming, and we talk about the concepts where we got into some crazy site specific scripting magic. There is less than many of you would think.

If there is an area you would like more detail on please ask. If there is an area you want us to dig in deeper in future case study episodes please let us know. Over the next few episodes we are doing case studies of different types of sites and the more complete we can make them them more they will help you out.

Before we dive into pulling about this site we have more user feedback and we talk about html email newsletters.

Great series

I think that this is a great series idea. I actually use many of those exact same modules on the Drupal sites that I build.

One quick thing though...how to pronounce "hierarchical". You guys keep adding a "t" (hierarch-t-ical).

Keep up the good work guys. I appreciate your hard work and look forward to the podcast each week.

Hierarchical

Yeah. It's a form, of course, of hierarchy. Higher-ark-ick-al. :)

great podcast!

A few thoughts:

1. Thanks for talking about the path auto module. I really need to start using this one.
2. The embedded media field rocks! I used it for a site last week. I think Rob suggested this to me in IRC a while back.
3. I agree about legal module. I have used it on an org site and man it works good.
4. Wow! Nice job on www.mollom.com. I checked it out when announced by Dries on drupal.org. Very nice! A nice segment for the future would be to discuss the differences in D6 theming. I am not there yet, but interested.

Nice job again.. Love hearing the inside on how you are doing your Drupal dev.

Thanks!
Shrop

Mark Shropshire "shrop"
Geeks & God Forums Moderator
http://geeksandgod.com/users/shrop

Great Show DuggIt!

Hey guys wanted to say outstanding show. You really did one for the GEEKS this time!

I gave you a Digg as well. Hopefully you guys will get some blessings from that.

Also, yes mollom.com is amazing. Congrats on the recognition from Dries to have you do that.

Time breakdown

I would be interested in more details on your time breakdown. I am a little confused because you said that Muddy River took 3 months, but the Mustardseed redesign took 9 hours. That is a huge difference. What did the large blocks of time on Muddy River go towards? Was the 3 months at 40 hours per week?

Differences

There are a lot of differences between the 2 projects to take into account.

One is that the Muddy River site had several new modules built for it and there was a bit of crazy custom theming. Getting the details for, writing, testing, and launching new modules takes a little bit of time. Mustardseed didn't involve this part of the process.

Another part is content. There is a lot more on the Muddy River site. It takes longer to load it, test it, check it, and tweak it.

Complexity is another thing. The Mustardseed site is much less complex on many levels than the Muddy River site. On the Mustardseed site there is no fancy rotating banner, there is no video that starts as an image but changes to a video when you click the images, and dozens of taxonomies to display on the media types.

Does this start to make sense? This really has to do with the complexity difference between the two projects.

Matt Farina
Geeks and God Co-Host
www.innovatingtomorrow.net
www.mattfarina.com

Matt Farina
Geeks and God Former Co-Host
www.mattfarina.com

Two not Three

I would add this as well... while it may have felt like 3 months for Rob, to be dealing with us, it was more like 2 months. :-) We signed the agreement on January 28 and was beta testing by the end of March.

Also, there were times when Rob would have to wait for us to make decisions on issues, or provide necessary materials for a next step. That wouldn't be an issue while working on his own site.

Mark Fogarty
www.MuddyRiverMedia.org

-----------------------
Get Muddy... It's Free!
-----------------------

Mark Fogarty
www.MuddyRiverMedia.org

-----------------------
Get Muddy... It's Free!
-----------------------

I still say 3 :)

I'm gonna disagree with Mark, here, and it's not because it felt longer (he was an ideal client, actually) but because he's only counting hand-on development time.

Yes, it was 2 months from the signing of the contact to 'official launch'. However, if we take the full timeline into account (things such as pre-production 'take-2', catching the vision, him confirming the budget, some 'live' bug testing time of the site online, etc) I would say we were at about 3 months total....hands-on development time (again, not the whole story) was about 2 months of me tweaking knobs and buttons.

-Rob Feature
Geeks and God Co-Host
www.mustardseedmedia.com

-Rob Feature
Geeks and God Co-Host
www.mustardseedmedia.com

Excellent Question

hey kswan....
I have to say this is the best question I've heard in a long time. Indeed, what was the huge time difference??

Matt gave you a few, but in my estimation, these weren't the most important differences that took the greatest amount of time. I struggle myself with this question often...why do some sites take so much longer than others? I laid out some of the ideas here in an article written this week. You can read it here

But, here's 6 ideas of why the time difference was so big:

  1. Freedom. The biggest and most sweeping difference between MuddyRiver and Mustardseed was freedom to develop what I thought best. Now, this (or anything following) is not a slam on MuddyRiver. It's just the reality of working with a client.

    You see, when I work with a client, I spend LOTS of that time making sure

    • I understand their vision, including design and functionality
    • I carefully explain the reasons I'm doing things so they fully understand the project

    These two things take alot of time. I can't just do what I want without their input and without explaining WHY I did things. With Mustardseed, that was the difference. I was the client and the developer...there was no communication needed.

    I would venture to say that if a client came to me and said "I trust you 100% and will not question your decisions" I could have built 95% of MuddyRiver Media's site (or a simliar site) in 9 hours.

  2. Design Time. Tying into the one above, I had to come up with a design that was acceptable to the client and that I was happy with. This process takes a while. However, when it's my own project, I can do something I like, often in a matter of minutes.
  3. Custom stuff. Yeah, we had a bunch of custom modules. However, I won't even suggest that building these took a ton of time. MUCH of this time was deciding that they were needed, how they should function, and clarifying specifics. Again, communication is what took all the time here. Actually building these modules took under 20 hours total (could have been done in 2-3 days) not to mention they were developed by additional developers, so that was 'simultaneous development' time....meaning (so far) that the site could have been developed in about 20 hours total
  4. Content Addition. Sure, this took some time...but I think Mark will attest that it didn't take that much time. He probably could have added all this media in one day or a little more
  5. Complexity. There was some complexity that needed to be worked out to the MuddyRiver functionality that Mustardseed's site didn't have. Deciding how taxonomy should work, doing slightly more complex styling, determining registration workflow, etc. This all takes some time
  6. Bug Testing. Muddy River included a couple weeks of bug testing. Mustardseed's bug testing consisted of me firing up IE6&7, Firefox and Safari for a check. So, big difference here.

You also ask a great question: "3 months at 40 hours per week?" Not even close. Just for fun I figured what, at that amount of time, this Muddy River site would have cost him....it would have been 6X what it actually cost :)

No, alot of this time is 'waiting time'. The client is waiting for me to develop, then I'm waiting to hear back on decisions, budgets, design comps, etc. The actual hands on development time (for all developers total) was in the ballpark of about 80 hours.

The problem is, we look at that and go "Ok, so this really only took 80 hours..not 3 months." No. It took 3 months. You have to look into 'real time' numbers (which includes more human factors than just hands on development time) in order to plan a timeline for a project.

I think what you point out here is a HUGE issue. It's one that, if I had total trust (from the get-go) of my clients (which I don't blame them...I mean, it's not like I'm their pastor or someone else who is on the inside of their ministry) I could develop these sites about 10x faster, and probably 10x cheaper than I do. But the reality of people is: that's not the way it works....so things take much longer than we'd hope.

-Rob Feature
Geeks and God Co-Host
www.mustardseedmedia.com

-Rob Feature
Geeks and God Co-Host
www.mustardseedmedia.com

Thanks Rob

That is interesting and makes more sense with my limited understanding of drupal.

There are several custom modules and they sound good, but for someone that knows what they're doing as well as Matt I expect they would take just a couple days each.

Of course, I overlooked the communication time. It is also helpful to understand what steps you are including in the lead time you state. I am sure that different people would have a different perspective on what should be included in the lead time of a job. Some might look at only development (don't include approval, debugging, data entry...).

Thank you for the details.

Glad to have stumbled on you

I like the general focus of your site, all to often ministry relegates technology to a back end afterthought, and all to often it shows.

One question though...what is "droopal" (sp?) I assume its a site framework, but I didn't hear you reference it in this podcast, nor is there a link to info on it.

Also, good choice in podcast players :P I use the same one on http://tonyarcher.com when I post a podcast update.

All About Drupal

You'll have to know Drupal if you listen to Geeks and God - Matt & Bob love to talk about it!
Yep, it basically is a web framework. Check out www.drupal.org or The G&G Series on Drupal sites: http://geeksandgod.com/podcast-series/building-a-w...

Enjoy ANZAC Day to all the Aussies and Kiwis here!
Lest We Forget.

Paul Vaartjes
www.paulvaartjes.com
www.cursoryglance.wordpress.com

Paul Vaartjes

ANZAC Day

Thanks for this piece of culture, Paul. I love learning things like this that I never knew. It seems to me that ANZAC day sorta serves as a similiar holiday to the American Veterans Day (although derived from a different source)

Happy ANZAC day to all of you Down Under. I join with you in your remembrance of sacrifice.

-Rob Feature
Geeks and God Co-Host
www.mustardseedmedia.com

-Rob Feature
Geeks and God Co-Host
www.mustardseedmedia.com

Really like this series

I love the case study. It is good for me to hear how you are thinking through the process of designing sites. I probably need to listen to about 4 episodes again: Site Architecture, Website Preproduction, and these two.

I definitely need to learn what to think through before taking on new projects.

John
john-simons.com

front page image rotator

Hi Matt - please, yes!! do blog further about how you implemented the front page image rotator. I am currently playing around with the jquery jcycle plugin, which is built on the "innerfade" plugin (which you introduced me to).

I am particularly interested in how you built an array in views, which you can then step through using jquery, and pre-load just one image ahead - that sounds like you could have an arbitrarily large array of image data being cycled through, without the overhead of having to load everything up front.

I'm really keen to do something like that on our www.lifesourcetv.com site. Currently I am rotating randomly through a group of five banner images, using the jcycle plugin, with some additions to template.php as well as a separate jquery file which calls the jcycle plugin with appropriate settings (random image, 25 second interval between transitions, 1 second transition time etc). The issue for me is that I need to load all of the images up front, whereas you seem to have solved this by only having a single image lookahead. Nice!

if possible (ie if you can find the time!) it would be wonderful if you could blog further about this (possibly even posting some code snippets) - because this would be a desirable feature for many sites.

Cheers & thanks
Pete

missing something... sorry (newbie here)

Hi Matt - (apologies in advance... long post!)

I have read your blog entry on preloading images with jquery, but I am missing something in my understanding. I am still just learning this stuff, so it's all "baby steps" for me.

I'm trying to work out where and how I should apply the jquery pre-loading logic for images.

Over at www.lifesourcetv.com I have managed to implement rotating images in the banner, with smooth crossfades, using the "jcycle" plugin. Here's what I have done...

First, in template.php, I have the following lines:

// added to include jquery cycle plugin
drupal_add_js(drupal_get_path('theme', 'bealestreet') . '/js/jquery.cycle.js', 'theme');
// add our script which calls the plugin
drupal_add_js(drupal_get_path('theme', 'bealestreet') . '/js/jqcycle.js', 'theme');

The first line adds the jquery "jcycle" script to the head of every page, and the second line adds my external script file to every page, which does the actual rotation. Here's the contents of that script file:

$(document).ready(function() {
  $("#bpic").cycle({
    random: 1,
    fx: 'fade',
    timeout: 20000,
    speed: 1000,
    height: '200px'
  });
});

This script finds the "bpic" id on the page, and applies the script to it. My banner block consists of a bunch of images, contained in a single div with an id=bpic. Here's the actual contents of the banner block:

<div id="bpic">
<img src="/files/images/banner/banner1.jpg" /img>
<img style="display: none" src="/files/images/banner/banner2.jpg" /img>
<img style="display: none" src="/files/images/banner/banner3.jpg" /img>
<img style="display: none" src="/files/images/banner/banner4.jpg" /img>
<img style="display: none" src="/files/images/banner/banner5.jpg" /img>
</div>

OK, this works fine, and we randomly crossfade between each of the 5 banner images. At the moment, I am using just 5 images, and they all get loaded. Only the first one gets displayed initially, in case the user has javascript turned off, otherwise they would see all the images!

To keep the page load time down, I have built these images at lower resolution, and they are typically only about 30k in size.

I am wanting to:

  • use much higher resolution images (larger file size; maybe 200k each?) and only load them as needed.
  • have a much larger list of images to cycle through

but I don't want to have to wait all day while the page actually loads!

Is this what the jquery preload logic is all about? I guess I'm having trouble understanding how it all fits.

In your blog post you have two code snippets for preloading images... the first defines the "jQuery.preloadImages" function itself, and the second snippet is an example - "$.preloadImages("image1.gif", "/path/to/image2.png", ...".

Where do I physically put these code snippets? into a script file or into the block content? Can I integrate this preloading technique with what I have already done above?

This will be a huge key for me if I can get this to work... again, sorry for the really long post. I hope it makes sense and you are able to explain this to me!

Cheers & thanks
Pete

2 Things

I've got 2 things that I think will help you out.

First, jQuery.preloadImages is a javascript function and can go anywhere you put your javascript. I usually put it in something like an external script.js file in my theme (with that name D6 will automatically load it like the style.css file).

$.preloadImages("image1.gif", "/path/to/image2.png", ... does the work of actually executing the function by preloading the images. Each value passed is the full path to an image. When you run this all the images passed will be preloaded at that point.

Second, if you watch my blog over the next week I'll talk about how to do this in more detail. I got sidetracked and didn't complete my series of posts on this. Coming up in the next week is a post explaining how to return a view as javascript and even put that in a javascript variable. That will be followed by how to do something like the rotating banner images on MuddyRiverMedia.org. Image preloading and views to javascript are prerequisites to that.

While jcycle is neat I don't like loading all those images on every page. What can I say, I'm a junkie for performance.

Hope this helps. The overall picture is more than I can explain in even a single blog post much less a forum.

Matt Farina
Geeks and God Co-Host
www.innovatingtomorrow.net
www.mattfarina.com

Matt Farina
Geeks and God Former Co-Host
www.mattfarina.com

thanks!

thanks Matt -
I knew it was going to be complex. I'll keep an eye out for your blog.

Cheers
Pete
www.sneesby.com.au
www.lifesourcetv.com