Project plan and storyboard

Project Plan

Web sites are about presenting information. All the layout, formatting, whitespace, borders, colors, etc are used to organize, and present information to our audience. We will approach that organization and presentation differently to different audiences; i.e. a 5 yr old learning the A,B, Cs or a CEO learning the basics of web design. The Project Plan helps us plan out what the goals of the web are BEFORE we commit any of our time to coding. Coding is simply the medium we are using to implement our vision. We need the vision first.

Use the project plan that was supplied in the file as a template for yours. There is some information about timeline and budget. You won’t have that information now so include the headings but just put in a place-holder like TBD (To be determined).  The main information you need to think about is:

  1. What is the purpose of the web site; i.e. it’s goal(s)? What do I want it to do for me?
  2. Who is my audience?
  3. What content will I have on the site? This gets back to the goals and the audience. What does my audience want? If I’m creating a portfolio, what does my audience (perspective buyer/employers) need to know about me, my work, my process, my fees, my availability, my turn-around time, i.e.. They want to see my work, yes. But they also want to know other information as well. What is it? Answering those quesitons will help you determine the content of the site. Once you know the content, you can start organizing it and presenting it.


The term storyboard means different things to different people. A storyboard for a web designer is different than a storyboard for a movie or animation. In film a storyboard tells the story visually. It demonstrates how the script (written descriptions) will appear on screen. A storyboard to a web designer lays out a rough interface and shows the organizational relationships between pages or screens. Again, it is a way of organizing your project visually.

At the top of page 5 (figure A-2) in your book, it shows a fundamental layout of a screen. Using boxes it simply is trying to indicate how the information will be organize on the screen. The author is using the term storyboard. Most designers would use the term “wireframe”. Here are some more examples

The figure underneathe that show the relationship of the different pages. This is important if you have more than one or two layers of heirarchical information. It helps you figure out how to set up navigation. Here’s another example: A storyboard for a web site mostly shows how pages relate to each other; it indicates how the information is unfolding. Here’s another one… Notice how some give more information. Some give less. All are starting points for design considerations. If you are the only one that is going to see it, the storyboard can be rough. It is  your way of thinking the project through. If you are part of a team, or are communication your ideas to a client, the storyboards need to be more polished. Why? Because you are communicating your vision and no one can see inside your head. Make it easy for them. The better you can help them visualize what you see (without a complete mockup), the better you will be. It’s always a trade-off of time vs utility.

I typically draw rough sketches to help myself think it through. Depending on how “rough” my initial sketch is, I may tighten it up before I show stakeholders. I can see what’s not on the page, most clients can’t. They see exactly what you have. Be careful about what you show your client.

File formats? I recommend uploading project plans, sketches and storyboards as pdfs. Why? they are easy to read on most devices. pdfs are also rendered pages, i.e. as if you sent them to a printer. You can’t assume I’m using the same word-processing software that you are. OpenOffice formats a little differently than Word, or Pages. By printing to a pdf file, you ensure that what I see is what you see. That’s the idea right? A share vision.

Browser coordinate system

Student Question:

“I have a question about the box shadows: what if you don’t want the box shadows to appear on the right and bottom of the box? The code that we used (ex. -webkit-box-shadow: 1px 1px 4px black;) doesn’t specify locations. What if, instead, I wanted the shadows to appear on the top and left sections of a box?”

Response:  “As far as the controling the placement of shadow effects… just a guess, try putting in negative numbers and see how that affects it. Remember, the numbers indicated pixel locations.”

“Why are there negative numbers here?”

“Are you asking why I would try a negative number?”

“Yes, I’m asking why using a negative number would be different than using a positive number. This is the only code we’ve seen that can use negative numbers, and I don’t understand why.”

Let’s go into more detail

Do remember the cartesian Coordinate system from High School geometry? It is simply a way of representing 3 dimensional space on a 2-D surface.

Think of the browser window as having a x, y, and z axis (actually it does). The x-axis is horizontal. The y-axis is vertical. The z-axis is perpendicular to the window. In geometry we learned that positive numbers are to the right and negative numbers are to the left. A location of any point in the window is relative to a point of origin. The point of origin, i.e. (0,0,0) in a browser window is the upper left-hand corner of the window. Positive X values are to the right. Positive Y values are towards the bottom of the screen. Positive Z values are coming out of the window towards you. Therefore, the negative directions of each axis are in the opposite direction.

In the case of working with drop shadows in CCS3, we use the following syntax…

box-shadow: h-shadow v-shadow blur spread color inset;


  • h-shadow is the horizontal distance
  • v-shadow is the vertical distance
  • blur is the blur distance
  • spread is the size of the shadow
  • color is the color of the shadow
  • inset [optional] changes the shadow from an outer shadow to an inner shadow

The distance parameters of the drop (box) shadow are relative to the location of the element that they are affecting. So a 10px distance for h-shadow would be to the right of the element. a v-shadow value of 10px would be under the the element; i.e. towards the bottom of the screen. Consequently, if you use negative numbers, the directions would be in the opposite direction of the relative axis.



Positive direction ,   box-shadow: 10px 10px 5px #888888;


negative direction    box-shadow: -10px -10px 5px #888888;


Q&A: Plain text and HTML

Student question:

Is plain text the same as txt? I’m still having a problem with it.


Beginning students learning how to code with web standards are sometimes confused about what plain text is and how it applies to HTML.

Plain text refers to simple character set, like ASCII, or Unicode. It is the set of characters that allow us to put alpha-numeric characters on a page. They are the symbols that make up certain languages. ASCII (American Standard Code for Information Interchange) is a character set of  128 characters that make up the English language. Since the web is a global network of documents, the ASCII character set is insufficient to represent many of the languages that use it. That’s why in most HTML documents you find a tag like…

<meta charset=”UTF-8″ />

” (UCS Transformation Format—8-bit[1]) is a variable-width encoding that can represent every character in the Unicode character set. It was designed for backward compatibility with ASCII and to avoid the complications of endianness and byte order marks in UTF-16 and UTF-32.”


Plain text refers to characters without any regard to formatting; i.e. font, size, color, justification, weight, style, etc. Many applications are capable of reading plain text information. We normally use plain text editors like Notepad (PC) and TextEdit (Mac), vi, or emacs to create the documents so that we don’t introduce formatting codes into our documents. As web designers, we  introduce the formatting into our web documents through Cascading Style Sheets.

When we use a program like Microsoft Word, OpenOffice, Google Write, or a host of other word processing packages, we are putting simple characters onto a page and then use the programs to add the formatting to change the characters appearance. While you normally don’t see the formatting codes that the software uses to make that happen, they are there, in the background, invisible to us. When we format a web page, we see all those codes in the form of HTML and CSS and have minute control over them. It is the browser that takes those codes and uses them to transform the plain text into formatted text.

Plain text files can have more than one extension but usually  have a .txt extension. An HTML document is created using plain text. We create tags with the plain text characters that communicate specific things to a browser. So in HTML you could say that we are giving instructions to a browser (or user agent) using the Unicode plain text character set. The HTML tags, CSS, and Javascript code that we write needs a program that understands how to interpret those tags and code. We give HTML files  an extension of .html so the Operating system knows to open it up with a browser instead of TextEdit or Notepad. The browser knows what to do with the codes and show us what the content looks like when the codes are rendered. We call that interpreting the code, or rendering the page. A text editor just shows us the characters, it does not interpret them.

For a list of Text editors see the following wikipedia article,