Sep
23
2005
[Update: Some of the specific concepts behind this post are a bit dated, especially when it comes to creating custom content types in Drupal. As of Drupal 5, custom content types can be created from within Drupal core, and enhancements can be added to any content type through use of CCK and complementary modules (as opposed to using Flexinode, which is no longer the preferred way, from my own perspective). I'm leaving the post as-is. If I write an updated concept, I will post the link here. Thanks! -- Laura Scott, 25 April 2007]
On Drupal.org there is a discussion about how various web designer/developers would approach developing a simple website with just a few static pages.
The pejorative term for this kind of website is "brochureware" ... and in this case it is rather descriptive. Most websites -- especially small business sites -- follow this holdover of 1990s worldwide web thinking, where the website in question effectively serves as an online brochure.
The exercise on Drupal.org turned out to be interesting, at least to me, so I thought I'd repost what I wrote there:
The idea of having a CMS to do a brochure site is that the client can change the content easily. Even a simple brochure site goes through periodic updates, and not just from press releases. Prices change, contact info changes, who's in the company changes, and so all of these changes can happen much more easily than with strictly html. That is why I think it's worth the extra work maintaining the code security, etc. [This first part was in response to previously made comments.]
- The Pages
- An About Page -- This would be created using page node type. I would remove the author info from node-page.tpl.php and put a time stamp visible in full body only, to note the update date. Some people fear placing a date on content, but I think it's important to know how fresh the info is. The client would have to be reminded to manually update the date on the node when she/he edits the node, and I would recommend making versions.
- A Contact Us Form -- I would use webform for this, and create a custom form that allows for business-specific queries.
- A Products (or services page) -- This would be created using page node type. If there are offerings in subcategories, I would consider using outline to create books, or using the book module itself. Alternately, one could use taxonomy to create the structures. If it's a visually appealing array of items, I'd also urge an image gallery, and set up the image assistant to link to the image nodes. This can prove helpful in other content types.
- A simple front page with two paragraphs about your company and contact information -- This would be a page node type, and the only node "promoted" and "sticky" (why, explained below).
- plus a sidebar with links on the right or left which link to headlines from your five latest news articles -- This would be a custom php snippet in a block.
- A news page with news articles about press releases, events and news -- This would actually be a story node type with php snippets to show the most recent relevant items, drawn by taxonomy. The individual items -- events, press releases -- would be flagged by taxonomy, and accessible from links on this anchored page.
- The Modules
- Image and Image Assist -- These would be used for products and for staff portraits. The nodes themselves would have detailed descriptions/bios, while the pages into which the images are inserted can have more general info. This makes for easy updates of this kind of content. Image assist would be configured to link to the relevant image node. node-image.tpl.php would be customized as node-page and node-flexinode-x to show just the date.
- Flexinode -- For events, and for press releases. The flexinode for press releases would be pre-formatted with the "For Immediate Release" etc. Press releases will have their own tag, and the RSS feed for that taxonomy will be linked on the front page. The module also would be used for events, obviously. Both would share a taxonomy that puts them into the news page php snippet.
- Taxonomy theme -- This would enable each page to have its own unique and complementary look. Before this module was available, I used custom theming on different node types, but this module would allow for entire color shifts.
- Taxonomy image -- Sometimes it can be very helpful to have a nice graphic show up in association with a topic. A product line could have its logo on all its pages, for example.
- Pathauto -- I would use the regular path to define the anchored pages, but the press releases and events would benefit from automatic descriptive addresses.
- Simplenews -- Because email lists are still the popular way for a lot of people to keep up with your site and business. This would have a block on the front page.
- Nodewords -- Keyword metatags are losing significance, but they're not irrelevant yet.
- TinyMCE -- Depending upon the client's comfort with html, I would consider adding a wysiwyg text editor.
- Glossary -- If there's a lot of jargon on the site, the glossary module could be very useful to have on-site background info without cluttering the site with footnotes or TMI for knowledgeable visitors.
- The Architecture
- Main navigation -- I would put this in the header, saving the sidebar (using only one, most likely) for the dynamically updated info.
- Nodes -- I would leave the default node.tpl.php alone, and use customized node templates for the content, leaving the most flexibility down the line for expansion.
- Blogs -- Even if blogging is not in the cards in the short term, I always urge clients to consider business blogging as a way of offering more personalized publicity and a better sense of who's in this company and what they're about. Blogs could be added simply by enabling permissions and adding a link in the navigation, with a complementary theme to be added.
- Promotion -- It's amazing what a dynamic front page can do for SEO. I would encourage the client to consider promoting the news-flagged nodes to the front page (and thus falling under the sticky), with say 3-4 nodes displayed per page. Teasers would be short. But front-page changes with new content is valued by search engines, so if net-based promotion is important, I would urge this.
- Strategy -- Many people who want a brochure site don't really grok what (I hate to use this term, but in absence of a better alternative for now...) "Web 2.0" sites can do for them. So part of building the site is educating them on what they can do in the future. A client that gets more out of their website than they expected is a happy client, and that's a good thing.
Overall there would be about 5 themes to create, to give each page its own look (via taxonomy theme). This way the site can expand without requiring rebuilding from the ground up.
This is an interesting exercise. I welcome comments on these ideas.
Bookmark/Search this post with:
- Company: Web, Deployment
- Tags: Web 2.0, Drupal
Comments
too much
I love Drupal.
But I don't find that Drupal is always the right tool to let a company owner edit his five pages (from time to time).
Drupal is so powerful and has so many features that are confusing - even to developers (as I've learned over the past three years using Drupal) - that it is exactly the admin interface that makes Drupal a less than optimal choice for a brochure site.
I've done a couple myself - using Drupal - and the maintainer of the site inevitably gets confused by "taxonomy", "node", etc.
Drupal has a strong admin interface for the daily editor, admin etc. But it is too much for most people.
Best
Gunnar
True, perhaps, if you don't look forward
Thanks for the comment, Gunnar!
I think the question is, "What's the alternative?" If you pay someone to design for you five static pages, you've not saved much at all, but you've totally undercut the potential power of your website. You bought a screwdriver when, for just a bit more, you could have bought an entire toolkit. Even if he or she doesn't know how to use all those tools, does that mean the toolkit is "too much" for them to handle? I think not -- especially when we're in this business to empower business owners (and political campaigns and artists and writers and community groups and....). To give them less, for essentially the same cost to them, would feel to me like we were cheating them.
The challenge we face is educating the customer about what's possible with a dynamic website. I would argue that spending money on a static site these days would be pretty much a waste. Search engines don't notice them. Web surfers don't return to them. It's like putting up a shingle in a back alley where nobody goes. What good does it do?
Now there are dynamic website alternatives to Drupal that are, in theory, simpler. But are they, really? "Taxonomy" can be called "categories" but it's the same concept to grasp. A "node" can be called a "post" but it's the same concept to grasp. Too difficult for people? If I took that attitude, I'd be insulting every client and potential client. I don't think it's too difficult at all.
What's more of a challenge is understanding how your (i.e., the customer's) website can work effectively in the rapidly evolving new media realm. Even though the theoretical project discussed here is a "brochure" site, it's becoming increasingly obvious that a website that really is just an online brochure isn't going to achieve much in terms of marketing or converting visits into sales. So really, any site that's going to be worth the money is going to be a dynamic website with robust interactive features -- even if it serves as an online brochure. At the very least, even a brochure site will need to be updated frequently -- not just because one can, but because that's what it takes to attact visitors. And when it comes to SEO, features like taxonomy are not luxuries for the computer experts, but essential for every website owner.
It seems to me that not many CMS packages are up to the task -- and most of those will cost tens of thousands of dollars for a single seat. (And even then, you often have to go to the same vendor to alter any code -- code which they still own.) Yet among this well-monied competition, Drupal fares remarkably well, and with the software's being free, the client's money is going almost totally into design work that leverages an awful lot of value into the site, and leaving him or her empowered with a dynamic site that they own outright.
To me, selling someone a site not as powerful as what a Drupal-powered site can offer would be like selling someone who wants to watch movies a VHS player. It would work, but it wouldn't have much future.
/evangelizing
Evangelizing
I've been advocating and evangelizing your viewpoint for years. Evenb specifically trying to "sell" the idea of Drupal and taxonomy.
I'm slowly changing my attitude.
I no more think that "taxonomy" is a concept easy to grasp, or that it equals "category" (which is of course very wrong - taxonomy is a much more complex concept).
I no more think that Drupal is the answer to all your prayers. After 3 years with this system (and more with other systems) I've seen what happens when you throw the admin interface at an unsuspecting "non-geek". It does not work.
Education is fine. I'd love to educate these new admins. But it doesn't work that way. They don't have the time or motivation to learn the concepts and the interface when all they want is 5 pages of static information and the opportunity to change a few things by themselves.
And the idea that it may grow - and they may get new insights and ideas. No they won't! Not in 100 years.
Other people will - but small business owners with the need to advertise on the web don't. It is not their core business.
If it were - I'd be sure to recommend Drupal, taxonomy, feeds, blogs etc. I actually do that all the time. But no more to the guy who maintains that all he needs is 5 static pages, and that he does not have the time to learn more about his options. His business is elsewhere. He does not want to spend his ressources on trying to convert clicks to clients. He has other priorities.
It is us - the geeks, the developers and the evangelists (me) who don't understand. We think that the world is about websites and dynamic content and content management systems. It is not. And the client who has another kind of business is in his good right to expect that we deliver what HE needs and not what WE think will be good for him a future that we envision and expect to come true.
That is my opinion. Learned the hard way.
Best
Gunnar
Static websites are professionally managed
And that means that if all they want is a static site, then if we set it up as a dynamic site, it makes it easier for us to manage and cheaper for them to have updated.
Meanwhile, there's no real gain to buy a static site. It still takes design and coding it into xhtml and css. In other words, there is no real savings in designing a static site. So what is the upside?
While "the customer is always right" is sage advice, I believe that there's a question of when the customer is right -- especially when we're talking about professional services that involve knowledge and experience that the customer does not have.
For example, in law, one of the common stituations -- and one of the cliches in law television shows -- is that often the defendant will insist upon testifying in a case, in the face of the attorney's advice not to. Who's right? The defendant? Is the attorney wrong to offer his/her professional advice, or to insist upon it? If the defendant testifies, and for whatever reason rubs the jury the wrong way and gets a conviction, was he/she right? I'd say that if the defendant wins the case by following the attorney's advice, then I'd bet that the defendant would praise the attorney and, at that point, have the best perspective to make the judgment of what's right.
If a client pushes me to make a dead site, and then sees no return on investment, the client will blame me for bad work, when the problem was the concept of a flat, dead, static site that cannot succeed in today's internet competition. And I would say that the client's negative judgment of me would be justified, because I knew better, but let the client talk me into doing something I felt was a waste of money. I could hope for a second chance to remake the website as a dynamic site, but I don't think I could count on it. The client will go elsewhere, and I will have only the initial contract fee, and no repeat business, no positive recommendations, no client referrals. And I will deserve that.
We could do what most of the web design industry does. We could prey upon people's ignorance and take their money to create websites that may seem to look fine, while lacking some of the very essential features to let them actually succeed. We could sell them 1995 websites in 2005, at 2005 dollars. And then, when the client wakes up and (hopefully) turns back to us, we could charge them all over again to repurpose their site into the dynamic site that can succeed today.
Or we could give them 2005 technology in 2005, give them a fighting change in today's internet, and put them onto the path into the future. This isn't up-selling, it's keeping things up-to-date, for the present, not just the future. It's making the site effective and visible and findable and optimized for search engines, so that even a "brochureware" advertising site can actually do what it's supposed to do -- be noticed. And it's all for roughly the same price, with cheaper maintenance and streamlined updating and upgrading as the business changes (e.g., price changes, product line changes, address changes, personnel changes, expansions, sales, specials....).
Isn't this really about the content model?
Of course enabling a client to change their web pages is good. The argument here is really about how the CMS models content. For clients who won't ever 'get' the concept of nodes, taxonomy etc, they'd be better off with a CMS solution which took a more hardwired approach to generated site structure - e.g. one in which content is definitely created within folders, and which presents those folders as being the site structure. E.g. OpenCMS (and probably countless others).
That can be emulated
Using the pathauto.module, content can be placed in a "folder" (or subdirectory) automatically, with index aliasing enabled to view content by "folder" ... or not.
As for node and taxonomy, I don't think the concepts are difficult, just the words themselves. When you explain that a "node" is a post of any kind (aside from a comment) that is then formatted and displayed via the theme (which is where the actual design work is done), most people get it.
And when you explain that "taxonomy" means categorization, like labeling drawers (and perhaps files) in a file cabinet, most people get it. (To follow up on your "folders" example, the "taxonomy" "vocabulary" could be named "folders," and the categories would then be listed there. In creating a new post, you choose which "folder" the post [aka "node"] should go into. And pathauto will give the post a custom url based on the "folder" selected. So if you create a post in the folder "products," the post will appear under yourdoman.com/products/....)
I think what amount to exotic terminology in Drupal create an impression that the concepts are more difficult than they really are.
it is not Drupal ...
Hi Gunnar
I appreciate Your comment, as it reflects a valuable thinking and feeling, I have had long time, but I do not share it anymore.
Here are some first points why and how I feel different today.
Supposition
Even a "brochure website" with only a few pages will always need a webmaster or builder who knows what he is doing.
For an ordinary "small" business owner or professional without any IT background, most other tools or CMS are equally overkill - or they lack features and extension capabilities, once they are needed.
Based on the before, it is the job of the IT professional or IT savy to make things easy and transparent - that is part of the job.
Remember: Among bling chicken, those who have one eye are king :-)
My own background is traditional publishing and communications with incursions in direct, dialogue or response marketing to journalism.
I have gone through several experiences, mostly with small and microsize business owers and organisations in Central America, who have almost no or only very little PC-Knowledge - I mean, start up the PC, write a letter or make a spreadsheet.
Most of them would be unable to understand how a network of PCs works. Like the Internet. Even the explanation of a local harddisk and file systems is a mind bugging challenge.
So if such is reality of business in many cases - except youngest business owners - than those who know more have a real job to do:
1) make things as easy as possible
2) prepare work routines in a simple way so a bling chicken could post "I am hungry".
3) make a manual - as easy or even easier to understand as You can see in the Bryght scenery.
And finally there seems to be a wide spread missconception about the new technologies - or its usefulness:
While it may be true in some future, that everybody becomes his own editor and publisher, think "citizen publisher / journalist" - I personally believe this will not be true for a long time.
Ofcause, everybody who has or learns the necessary skills can publish today what ever he / she wants - but that ability does not yet mean a freeway to success.
There is much more to learn, than fill out forms and "update" brochure websites.
So this is the situation, where I think that communication professionals with IT background see there market and future.
Coming back to the starting point:
The question of success online is not related to Drupal or other CMS, but is related to the quality of professional advice and assistance a company may get.
Referring the focus on DRUPAL:
YES for me Drupal has been a head-egg and still is. But I have learned about, installed and tried dozens of other "CMS", like Nuke-family (phpNuke, PostNuke), Xoops, XARAYA, Moodle, b2evolution, wordpress, et al.
After that I stay with Drupal, as there is no other tool for taxonomy, multilingual sitebuilding and freedom of design when I want or need it.
Ofcause You are right, when You say "too much", but it is with every dish: You usually see much more food and beverage than what You need or can eat.
So with Drupal, just don't fill Your plate with everything You may have in Your reach but select carefully only what You really need.
And there may be a reason, why You feel as You said:
Drupal freedoms and chaos of development makes it hard to learn and understand the needed basics - with out getting confuses over so many competing modules without almost any comparison or evaluation.
You even dont find easy information, about what module would work in which scenery. As I understand it now, that is just part of the job.
Just a few cents as feed for thought :-)
Roland
http://centroamerica.tv/
( a soon to be drupalized net of sites )
Question
roland: i am somewhat lost in all this debating, but i am really curious as to what exactly is a "bling chicken"? is it like chicken marsala? i know a cilantro/lime/ginger chicken recipe that in my humble opinion will beat the feathers of any other avian but never heard of a "bling chicken"
may the nizzle shizzle the blingest chizzle!
Would you write a tutorial?
Hi Laura! I'm just starting to use Drupal, and I think this is a very exciting article. Would you write a step by step tutorial, how to do this? It would be very useful for beginners like me. (I've found a tutorial at Bryght, but they use a different method.) Best regards: Tamas Hajas
Beginner tutorials are in the works
The Drupal Documentation group, of which I am but one member, is working hard on improving the Drupal.org documentation, including adding How-To guides for beginners.
I know I tend to use shorthand and jargon in this post, as it was written with other website developers in mind as the audience, so it probably seems a lot more obscure than it really is. Once you understand how the modules work, it should all start to make some sense. Perhaps if you have some specific questions, I could clarify.
Thanks for answering...
Thanks for answering! I think I'll try drupal and maybe what you wrote. When I'll have specific questions, I'll writ again!
Best regards. Tamas Hajas
creating brochureware in Drupal
Laura,
I agree with your notion that even if Drupal seems to be an "overkill" for small site, and even if small business owner doesn't plan to expand into advanced features (or doesn't know that she will) - Drupal is still worth it. Just because "all other things are equal" - there is little or no downside compared to Dreamweaver, Frontpage, etc.
I first tried Drupal couple days ago, and I slapped a quick brochureware site for my wife's new business. One thing that I couldn't find is some example of your sample "Products" page. That is, some page in Drupal that submits a query, and the server code (preferrably, de-coupled, so it could be Perl, Java servlet, whatever - but PHP is good, too - as example) processes the request; and a page (same, or different) shows the results.
Most of the examples of PHP snippets are "Display this" or "Show that". I hope something like this wouldn't require a full-blown module...
As I said, I think I looked pretty thoroughly - but I've only played with Drupal for couple days. So, maybe I'm just going blind and missing the obvious...
did this ever happen?
Hi. I'm trying to use drupal for exactly what it talked about in this thred and can't find any real world examples. i think the thing I'm most confused about is how to manage multiple dynamic content sections. For instance I want on the homepage to have two ifames each with different content controled by drupal. To do this would I create two node types like explained here(http://drupal.org/node/35686)? And then on other pages I want to have other contect controled by drupal. Would I then just create more custom node types on those pages?
This site is one example
Obviously, we have blogs and other "web 2.0"-type of features, but if you click on the services tab, you get a brochure-like area of our site right here.
I find there to be a real lack of basic tuturials
I have installed a drupal site but I am totally lost with their terminology and I am not new to web design.
I feel positive about Drupal - intuition - and am going to perservere, but Google searches do not bring me very much in the way of tutorials for newbies.
Drupals own are far to embroiled in their own terminology and do not bridge the gap well between their own terminology and a simple grasp of what the heck it does.
Examples are good. Similar to statements are good. Graphical representations are good.
I was surprised by this because Drupal is not some new CMS system.
I have been aware of it for over 2 years and I'm sure it is older than that.
There may be a reference I have missed, but I am used to finding an overwhelming number of tutorials on any one subject.
This leads me to wonder whether Drupal is indeed an esoteric zone of knowledge, but if it is ever to survive there needs to
be an attempt to communicate it's elements in a more assimilable
fashion. People do not demand what they feel is beyond their ability to comprehend.
And businesses do not automatically trust experts. The barrier is communication arising from esoteric terminology.
It is not just a business owner who will have trouble but if someone like myself is having trouble - someone familiar with css, php html is finding it hard to grasp then there is a barrier.
I need someone to tell me a story about Drupal and it's terminology and what it does. Why it has it's structure and what is bit is similar too. This could probably go for about half an hour and be in MP3 format.
Thanks for listening
re
Glad to read such a nice piece of information.
You can get a lot of support
You can get a lot of support on Drupal.org forums, on the support list, support@drupal.org, and in the Drupal support IRC chatroom, #drupal-support.
--Not to mention the Drupal.org handbooks, which are being improved and updated every day. It's a big community, and sometimes requests for help can get lost in the crowd, but persistence and specificity in help requests can often garner helpful answers.