Unlike building a house, development of a website takes place on a copy of the site instead of the real site. This means that while the site is being built, it is not available for the public to view and use on the Internet. With a bit of thought, this should make sense. Any potential community member who comes across your site would probably become frustrated with bits and pieces that don't work, error messages, untidy presentation, or any other thing that could scare people away at the drop of a hat.
Some readers may well be wondering what to do with their domain in the meantime, assuming one has already been purchased. The best solution is to put up what is known as a placeholder page that delivers a simple message to the effect that this is the right site, the development is in progress on the working site, and that potential members should visit again in the near future.
If you want to learn how to get a page onto your internet site before going any further, then check out Appendix A on Deployment, which outlines the process of moving a fully functional website onto a live web domain. The process for doing the whole site and a single page is more or less the same, but naturally, moving a single page is a lot less complicated.
Before we take a look at what the demo website is going to be, it is important that as the creator of a new site you spend some time gathering information on the needs of the community you are attempting to serve. Doing this now will help you in the long run because having a thorough understanding of your site's requirements allows you to develop it with specific goals in mind. This in turn gives you a more focused and coordinated approach to the site's development.
One of the best ways to determine what you will need, is to build a list of tasks that the site must be able to perform (by this I mean a written list, not a mental one). Effectively, after creating a list of the various things you need, the site's administrator (most probably yourself) should have a clear enough idea of the requirements to go ahead and begin working. Unfortunately, it is often hard to predict exactly what is needed by simply sitting down and writing. A good way to start is by looking at similar sites. You should go ahead and take note of everything that is useful and desirable on other sites and add this to your list.
If you get stuck, or run out of ideas, it's helpful to try a little thought exercise as follows. Split yourself into two people:
The community member who knows what his or her needs are
The Drupal administrator who needs to find out what to build
Use the administrator persona to question the community member about what has to be done. Approaching the problem from two perspectives often helps mimic real-world situations where software developers try to find out exactly what their clients need by asking probing questions before they start working on a project.
If you can get to a stage where you feel comfortable that you understand at least 80% of what is required from your site, then it is probably more efficient to go ahead and begin creating the site, rather than waste time scraping out more information. As Drupal is so well designed, extensible, and flexible, it is quite easy to modify it at a later stage should you need to.
What type of requirements should I be looking at? you may ask. Here is a list of some of the most important topics you will need to decide on:
The type of site—forums, polls, or other things
The way you are going to run the site—stats, logging, or performance issues
The security, roles, and permissions involved
The need for integration—syndication, aggregation, or alerts
Apart from your site's functionality you should also start thinking about how you want the site to look. Obviously an attractive and unique interface for users to work with is your ultimate goal in this respect. The use of themes to create a visually appealing site is a fairly important topic that we discuss later in the book in Chapter 8, but please do give some thought to this aspect of your site early on regardless.
Of course, you not only want to design an interface that looks pretty, you also want to make it intuitive and easy to use. This is very important as studies have shown that users will often base their opinion of a site on how easy it is to use and not always on other criteria, which you might think important, such as speed. People often believe that a slower running site is faster if they manage to accomplish their tasks on it more easily.
There is a brief specification of the site that will be built throughout the course of this book in the section entitled The Demo Website later on in this chapter. By observing similar sites and anticipating the needs of your site's users, you can develop a specification for your own Drupal site. Having a site outline or specification to work towards is very valuable in the world of website development—even if Drupal mitigates the need for writing code ourselves.
Once there is a specification to work with, we know what we need. It is time to look at how to deliver it. Off the top of your head, it may seem that one simply sits down and works through the specification list point by point until everything has been checked off. From one perspective this is absolutely fine and certainly at some stage everything should be ticked off the list. But if we look a little closer, the picture begins to get a bit fuzzy because we really need to go back over all the points listed and find out what is involved in getting each one done. Knowing what lies ahead is the best way to handle problems preemptively!
The three main areas of concern that we need to deal with are discussed next.
Having a wish-list is a great way to decide on what you want, but that doesn't mean it is feasible. In order to be feasible, the criteria should not involve an inordinate amount of effort relative to the benefits it will return. For example, if the site specification calls for a feature that requires a hundred hours of brutal, frustrating programming, then it is probably not in your interests to waste time doing it if it is not going to affect your community significantly.
Ultimately, it may be better to look for a cheap and elegant alternative either amongst the plethora of contributions, or from third-party software providers. One of the old programming mantras, There's more than one way to do it! holds true here.
Look at your requirements very carefully. Are you sure you can actually provide everything that is required? If not, spend some time looking over this book and the Drupal site to see if you can learn anything new. If you are absolutely stuck, then get on the forums and lists and ask for help. One of the great things about Drupal is that it is a community-driven project, which roughly translates into: There are generally people around who are happy to help. Bear in mind that this is not a one-way relationship, and once you have some experience and knowledge to share, there are always people who are grateful for a helping hand.
In order to determine the priority of tasks during your site's development phase, it is a good idea to divide all your requirements into two categories—those that are fundamentally necessary to the success of your website, such as finding a service provider, and those that are not, such as deciding on whether to make your hyperlink color dark blue or light blue.
There are a couple of reasons for this:
Doing so will help you allocate time and resources to certain tasks while putting others on a backburner.
You are aware of those features that do not necessarily need to be included at all in the event that time is short.
In both these cases, it is important to know what has to be finished and what can perhaps be left out or left for another day. With all that in mind, let's take a look at what the demo site is, and how it intends to meet the requirements of its community…
In order to do something fairly distinctive, we will, throughout the course of this book, build a wildlife and conservation community site called The Contechst Wildlife Community, or CWC, that will cater to the needs of a wide range of people involved in everything from conservation and rehabilitation to research and policy making. The intention of this site is to become a central meeting point for like-minded people who wish to stimulate discussion and exchange ideas and information, which can be in virtually any form.
Not only is the site going to foster a community feeling by creating regular newsletters and posting information on important events, but it is also going to encourage open debate in its forums. It is hoped that the forums will become a popular meeting place, but this will not in any way be the only facility provided by the site. Regular polls will be taken in order to gather information on various important topics and industry experts will be invited to become bloggers for the site.
Of course, it is only natural that we will need a striking and pleasing look and feel for the site, which will end up like this (actually, there is a lot more to the site, but in the interests of fitting everything on one page it has been simplified a bit):
One of the sad facts is that even if this community site is very popular, we will still need to make money out of it just to cover the costs of having someone administer or moderate it. How can we do this without charging people for membership? There are two methods open to most sites that have a large associated community: donations and advertising. Accordingly, the CWC will make use of some third-party software and a downloadable module to raise money.
The CWC is designed to show off much of the default behavior of Drupal, and you will see in due course that the following functionality will be enabled from the default distribution:
Blogs: A blog, or weblog, is almost like a journal, maintained by one person only. In the case of the demo site, there will be a bunch of blog writers who post to the site regularly in order to keep the general public informed about their movements and developments in their specific areas of focus.
Books: A book can be created by a wide range of users using pretty much any type of content possible. Polls, pages, weblogs, and others can all be easily added to a book. This is a very interesting feature of Drupal because it allows for the creation of a truly unique online book that can harness the power of web-based dynamic content to give your stories an ultra-modern feel.
Comments: Naturally, in any community, people will feel the urge to comment on topics of interest. Because of this, the Drupal comment functionality allows users to append or attach comments to pretty much any content they like (depending on the permissions set by the administrator). In fact, forums are based on the use of comments, which are added to specific forum topics that have been posted to the site.
Forums: A forum is a medium for discussion and voicing ideas. In the case of the demo site, a variety of different forums will be set up to provide users with an area in which to discuss important subjects and interact. As you will see, you will be able to control the content of forums quite easily if you so desire—in fact, Drupal allows you to examine any and all content that attempts to make its way onto your site.
Locale: This allows you to present your site in a variety of different languages in order to create a truly international site. In fact, Drupal goes one step further by allowing individual users to select their language of preference in order to view it in that language automatically whenever they log on.
Polls: The poll content type allows an administrator (or whoever has sufficient permissions) to create a content type, which contains a question and several options from which poll users can select their preferred answer. This is a useful tool for gathering pretty much any sort of information ranging from what features your users would like to see on your site, to whether or not people believe there is life on other planets.
There are actually quite a few more features that will be utilized in order to make our site fully operational, but we need not go through all of them here as some of them are fairly trivial, and others are explained in detail later on in the book. Trust me, there is plenty more to work on!
From the previous list you can tell that there is already a powerful set of features available to Drupal administrators and we will actually look at how to enable, modify, and use all these features and many more, in due course.
We are not limited to using only those features that come with Drupal by default. Drupal has been designed to make it easy for people other than the developers to enhance it with more functionality. The modular design of Drupal means that creating entirely new functionality is often as simple as copying a few files into your Drupal folders—although, admittedly it can be more complex and we will also look at contributions that require modifications to the database amongst other things.
The CWC will make use of a whole bunch of contributed modules including, but not limited to:
Taxonomy Access: Allows the administrator to maintain exceptionally fine-grained control over who is allowed to do what and on what type of content. As you will see later, there will be certain users whose help is required to moderate the forums but who should not have any other broad-based powers. Using this contribution makes it easy to outline the permissions for any user based on the type of content you want them to work with.
Flexinode: Provides the administrator with the ability to create custom content types. This can be exceptionally useful if there is a specific need that cannot be easily catered for using one of the standard content types like a page or blog.
Adsense: Allows administrators to incorporate advertising from Google. In this way, traffic from your site can be directed to related sites for a small payment. If you have enough traffic moving through your site then these small payments can mount up, providing you with a nice source of revenue.
Not content with simply utilizing various modules to add functionality to the site, we will also get our hands dirty by ensuring we have properly structured the site's content using the taxonomy system provided by Drupal. We will also look at how to add some dynamic additions to the site using third-party scripts and even AJAX.