Data is not created equal. You have numbers, text, images, sounds, video, animation, PDF, and so on. You can capture data by typing it into a form or from a drop down or from check boxes. Because data comes in different forms, the way it is displayed, stored, and viewed varies. The amount of space data takes up varies. All these conditions influence the design and development of your site. They also affect the processes and tasks you use to sustain your site.

Assume you have identified a type of content and have determined the content for that type can be broken into at least five potential data fields: title, goal, client, status, and body. The next question is, what will those data fields contain?

As mentioned earlier, data can include numbers, text, images, sound, video, animation, PDF, and so on. The form of your data influences several aspects of your site:

• type of data field
• data entry strategy
• data storage 
• data visibility
• screen real estate.

Type of Data Field

Because not all data is the same, the fields that hold the data probably won't be the same. There are numerous content data field modules that allow you to add different types of data to your node. For example there are text fields, numeric fields, data fields, image fields, link fields, calculation fields, node reference fields, view reference fields, user reference fields, and so on. In order to know which type of field you need, you need to know the form of the data.

Data Entry

It is one thing to type numbers and text into forms on the screen. It is another thing to include such files as images, sounds, video, animation, and PDF. Assuming your site's server will hold the various media you want to present in your site, what process do you want your users to use when uploading and displaying media in your pages. Depending on what you want to be able to do with the images after they have been uploaded, you have several options to choose from.  

At this point of your analysis, try to include decisions regarding the following:

• Upload via online form or ftp. Not all files will be uploadable via form so you need to plan for those occasions.
• File type restrictions. To avoid giving someone the ability to upload an executable file that can do serious harm to your server and site, you need to limit what types of files can be uploaded. Drupal provides default options that avoid security issues but if you need to change what can be uploaded, don't include file extensions that can be harmful.
• Media file to be displayed in a view. File uploaded via a WYSIWYG editor are not seen by the Views modules (the module used to create database queries).
• File width requirements. How wide must the media be in order for it to be shown as desired?

Other considerations such a file storage are addressed next.

Data Storage

Not all data is created equal. Text and numbers get stored in the actual database. The web friendly files such as images, sounds, video, animation, and PDFs are stored on the server in a directory (similar to HTML sites). The database also stores information about the files (file name and page reference information).

Different upload features store data in different locations on your server. Some upload features allow you to designate a default directory of your choice for each type of upload. Others do not. Will you require specific storage locations for each type of file or media uploaded? If yes, where?

Data Visibility

Numbers, text, and images are the easiest data to see on a web page. You can easily link to sound, video, animation, PDF, and other non-web friendly files. The catch is seeing these other types of files in the browser. By identifying the forms of data and how you want your audience to see the data, you can make sure your design has the screen real estate and the necessary technology to accommodate your requirements.

Screen Real Estate

This refers to the amount of space available to show your content. Your content space competes with the space the header, menus, sidebars, and footer take up. Different forms of data take up different amounts of space. Some can flex within its environment (text and numbers). Others such as images have a fixed size and shape once they are input into its field. 

Why do my requirements need to convey the form? To answer, let’s jump ahead for a moment to screen layouts. The size and shape of your content can influence whether you have sidebars and if so, how many.

Below are three sample layouts. From left to right, the area that holds the core of your content gets larger allowing larger forms of data to be presented. Depending on how wide your content is, you might not be able to have the sidebars you want. Data tables, images, and other media often need more space that text.

Maybe you are thinking "Okay, when I add a data table or image to my page I will simply turn off one or more sidebars when I need more space." Well, in the world of HTML and possibly other content management systems, this thinking would be fine (assuming you want to ignore the topic of usability as well). In Drupal, the goal is to plan well so that content in your sidebars will appear based on a condition being true versus you manually adding a block to every new page that gets created. For example, if the URL path includes a term from a specific taxonomy vocabulary, show a specific menu block.

Imagine a site where you have multiple content authors each adding pages of content, would you want them adding, removing, or changing the content from in the sidebars as they create content? Probably not. For one thing, that would be a pain. Secondly, you would have to grant them access to administer blocks, not a good idea. And third, you could create a usability issue with menus and other relevent content appearing and disappearing based on a content developer's wishes or needs.

So, you need to plan ahead. Know the form of the content you will want to include in your pages. Create a set of parameters that your designer and developer can use when creating your layouts.

Conclusion

If you do not use separate fields for your data, you still need to consider data form. For example, on this site I added an imagefield to the book content type. I installed the Insert module so that with a quick click, the image path would be loaded into the body field so that I could use the WYSIWYG editor to resize and position the image. I then hid the image in the imagefield so the images wouldn't show up twice when you looked at the page.

I have the best of both worlds. I can reuse the images in a view and I can use them in the body field.