Give me the Content!!!

Events happening in the community are now at Drupal community events on www.drupal.org.
CraigBertrand's picture

How do you guys get the content from your clients?

Do you start designing/programing without it? Why or why not?

What about a Client Needs Analysis?

Basically, what do you all do to get the information from your clients that you need and what work flows do you use?

Comments

I'd be interested in this,

rszrama's picture

I'd be interested in this, too... I built a site super quick per the client's request expecting the content to arrive any day... and that was a month ago. Wish I knew I could've taken more time on the project. : P

my 2.0 cents..

Dublin Drupaller's picture

Hi Craig,

re: do you start designing/programming without it? Why or why not?

Here's my 2.0 cents...(I maybe stating the obvious a bit, but, it is an interesting discussion point and would like to hear other opinions/viewpoints.)

Design/programming, which comes first?

It depends on the relationship with the client, but, If you're starting a site from scratch, sometimes a good approach is to use lorum ipsum text, dummy images, audio and video to build the user interface and functionality before the design/theming happens and before flowing in 'real' content.

In other words, build the functionality first, before you start the theming and leave the 'real' content until last.

That is just my 2.0 cents, but, the breakneck speed of Drupal development means that only seasoned veterans will know what modules and functionality are available and clients rarely know what they can or can't do with a Drupal site. i.e. Most think Drupal is just a Content management system. Anyone who has done more than skimmed the Drupal.org site or tried it out, will know that Content management is only a small part of what Drupal can do.

So, running a feasibility study - where you build functionality on a demo/pitch site helps get over the hurdle of explaining to the client that "you know, you can plug your forums into facebook, like this..." or "if you use the drupal audio modules, you can publish and manage your podcasts direct from your site, like this...", or, "if you use the invite module, members can invite other members to join the site and you can track who invited who..like this" and so on...

From a clients perspective, they get a huge amount of value from the feasibility study. It not only satisfies the inevitable 'proof of concept' requirement, but, it's also probably the best way of illustrating to clients what Drupal can do and educating the client that Drupal isn't just a content management system...it can do this, this and this...or this as well.

From a drupal developers perspective I think it's better following that approach than having numerous meetings with a client at the proposal stage (where you usually don't get paid) or suffering from the other scourge of writing proposals/quotations - companies just fishing for ideas/competitor prices.

As an aside, I used to write lengthy proposals for Drupal projects. That is, up until recently. Now, I just provide a 2-pager that nudges the client towards a price for a feasibility study demo. Even for medium sized projects, where the client might be deliberating between Joomla/Drupal/Mambo/others, it makes a lot of sense. It means those lengthy meetings with the client, that you normally don't get paid for, is embedded into the feasibility study.

From a theming perspective, a common approach is for a designer to ask the Drupal team, "here's the layout, guys, can you convert that to Drupal?"..but if you flip that around...i.e. do the functionality first and say to the designers "here's the functionality, guys, can you design the theme and user interface for that?" it not only saves a huge amount of time..but, money for the client as well. The designers can then design dealing with a known set of building blocks and the project runs much smoother.

It's infinitely easier and more efficient for the designer to go back to the Drupal developer and ask them "can I put that here?" or "is it difficult to put the billing on the same page as the delivery address?" or "you know when someone is logging in, can we put this here on the same page?" type thing, rather than the Drupal Developer going back to the designer and saying "sorry..the design didn't allow for all these elements here, so I just threw them all in based on the general layout"..which usually completely destroys any balance and design of the original user interface.

It's plausible to bounce back and forth between designer and developer when the design is done first, but, I think things run much smoother when the functionality or building blocks are in place in a demo/feasibility study site before the designer lets the creative juices flow.

Also, many designers are savvy with HTML & CSS these days, so, once the functionality is built and in place, the designer has the CSS from the markup to work with and play around with ideas.

re: getting the content.

This is a common problem and I've never stumbled across a 'holy grail' method of solving it. The closest I've come is making it clear to a client that I'm booked in for these dates...and they'll be paying anyway for my time even if the content isn't there..which puts the onus on the client to ensure the content is delivered on time. That can be a little tricky to do with a new client, but, it's the closest I've got to ensuring you're not twiddling your thumbs...

Dub

skip the content

moshe weitzman's picture

i press clients very hard to deliver wireframes and or mockups. we do some iterations and when we are happy with those, we start building. content is not a prerequisite for me. i usually build out my content types and then toss dummy content in there with devel_generate module. i have done a lot of work on that module recently so it suits this exact use case.

on the subject of dummy content

Dublin Drupaller's picture

Has anyone worked out how to create a bunch of dummy forum categories & posts. I was trying to do that recently but got caught for time and couldn't finish it. I was playing around with the import/export Api and that couldn't handle forum posts at the time..

What I mean is a bunch of "lorum ipsum" style dummy posts/comments and forum categories you can just drop into a wireframe Drupal forum.

dub

Devel

thanks

Dublin Drupaller's picture

Thanks Michelle.

for others stumbling across this topic, Michelle's link points to a page that recommends using the devel module to populate the forums, along with an sql snippet that updates the tables. Categories and the forum structure needs to be built by hand.

I wonder if one of the forum migration modules (that converts 3rd party forums to Drupal) might offer a solution.

Dub

Plan, build and then fill

trevortwining's picture

I've had a wide range of experiences in regards to getting content. In most cases though, I end up with a design to work with but no written content until much later in the process. Wireframing is a great tool for getting the mechanics of a site down without that content. My usual workflow is something like this:

  • Initial consult. A mix of a few phone calls, links to existing drupal sites (mine and others). Occasionally my dev sandbox is used to show off a particular module.
  • Agreement. I push for by the hour billing, paid out on completion of certain milstones. Your mileage may vary.
  • Wireframing. Diagrams about functionality and layout on everything from napkins to visio. I'm geting rather fond of the OSS app Scribus for this task as I can use master pages for common layout elements and share the app with whomever I want.
  • Scaffolding: putting up the drupal install and getting all the modules configured for their out-of-the-box behaviours
  • Client design usually gets submitted around this point.
  • Customizing: changing things based on client requirements and preferences.
  • Theming: Fitting the structure to the design
  • Refinement & Approval: Usually 2-3 iterations of between a day and a week each to wrap up any loose ends.

I've had a few experiences with clients where they 'didn't know what they wanted until they saw it.' I let them know that Drupal is flexible enough to accommodate a more freestyle type of development, but such work can't be done on project pricing and requires a per-hour billing model to be fair to both parties. These projects can be a lot of fun because they often allow for the most experimentation. They can drag on for a while though.

I haven't had a lot of success with orienting designers to drupal, but recently I've worked with many who haven't even heard of it. (I know, I was shocked too!) It's an iterative process though and next time they will be more comfortable. I like the idea of sharing the theme with them and designing to that rather than the other way around.

I dont have time to

tjholowaychuk's picture

I dont have time to elaborate much on this but I would highly suggest getting as much information as you can BEFORE you start. Have them be fully aware and fine with any design implications that may or may not later how the site can/will expand in the future and make sure it is all covered. You dont want to limit the future of their project without their consent, if they are more worried about cost and time having them sign off on features that will currently be implemented and again have them understand that it must be done in a "dirty" way. Also just to note that if I have learned anything in the past few years it would be that you cannot plan enough!


vision media
350designs

A Client's Perspective

PRFB's picture

I've had to deal with pesky clients in a non-technical capacity, and am currently trying to be a non-pesky client to my Drupal contractors. Here's my 2 cents...

Be clear about what you need, and when. Ideally as part of your spec/contract discussion, lay out who is responsible for what, on what date. Also, throughout the project, if you need something, make sure the other person knows (is reminded) in advance. Regularly scheduled check-in calls can help with this. It's OK to assign things to the client!

You probably don't need (much) real content. What you do need is to understand is the structure of the content. You can fill in the rest with dummy data (ideally something that will be easy for him to search for and delete later). It's better for you to press your client to spend time on the structure than word-smithing

Base your payment milestones on things you can control. As the developer, you getting paid shouldn't rely on your client finishing HIS work. I'd recommend setting your major payment milestone around a site that's got all the frameworks in place (with dummy content)

Teach your client to add the content themselves. After all, they're presumably responsible for maintaining content going forward. They may as well learn to add it from the start.

Hope this helps.

Thanks

CraigBertrand's picture

Hey thanks for all the input guys I will post here if I come up with some kind of "best practices" for me at least, but maybe someone else will be able to benefit. Thanks again!

Hey this comment preview is cool...except the "loading" alert is a bit distracting.


Until all have heard
Craig Bertrand

Consulting and Business

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: