Posted by CraigBertrand on December 13, 2007 at 6:50am
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,
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..
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.
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
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
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
See http://shellmultimedia.com/tutorials/populating-forum-devel
Michelle
See my Drupal articles and tutorials or come check out life in the Coulee Regio
thanks
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
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:
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
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
Tj Holowaychuk
Vision Media - Victoria BC Web Design
Victoria British Columbia Web Design School
A Client's Perspective
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
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
Craig Bertrand