Here, again, are some of the notes I took while reading Principles of Web Design by Joel Sklar. This post has not been proofread. It is here merely to be my reference if I need help in these topics later on.
As with all major projects, building a website begins with the design process. It may often begin with a brief sketch of you website layout. Make all the necessary edits as you see fit for designing your home page and subsequent sections and subsections. If this is a big team project, there will probably be many meetings to discuss this portion of the project. Draft a timeline for due dates and milestones. As the project evolves, you should not find yourself needing to plan nor edit your design as you build the site. All design experimentation should be at the beginning of the design process.
When sitting down to think about the design of a website, think of these requirements:
- Purpose for the site – information dissemination, product promotion, social outlet, etc.
- Target audience – students in school, women, men, sports fans, etc.
- Specifications – logos, branding, accessibility, color scheme
Soon after organizing what you want on the website, begin creating design sketches and page mockups. Organize the page as you like in your sketches. After you have created multiple drafts and as your design becomes more stable, your mockup will become more refined and you will be able to lay out exactly what goes where. A more detailed sketch is often called a wireframe, which is often a complete sketch of what your usable site will look like.
Constructions and content development will take the most time and require the most technical skills. Testing for quality assurance and usability will also occur as necessary during the development stage. Usability testing ensures that the viewer sees what you think they will see and can navigate the site without too much trouble.
Next comes publishing and promoting your site through various media and then site maintenance. Maintenance is always required to keep fresh material on the site. New sections may be added to include more content.
Tracing back to what we discussed in the Chapter 2 notes, it is important to draft up sketch of your website, the home page and subsequent section pages. After that process and after coming up with a web design that you like and are happy with, the next part of the planning process is creating a site specification document. This site spec doc is a more detailed description of what your site entails and helps keep you in focus as you build the site. (Don’t lose sight of your site!)
A site spec doc should answer the following questions:
- Who is the client for this site? This is not the user of your end-product but the person or organization who decided they need a website. What does the client hope to gain from this internet product? For this Web Design course, the client I am “working for” is the Berkeley Optometry. “We” are creating this website to disseminate information about our School and OD program.
- What is your mission statement?
- What are the requirements for the site, i.e., your list of wants? Be explicit in your required functions.
- Are your requirements feasible? Do you have a team that can build what the client is looking for?
- How do you know that you’ve built a successful website? What are some factors you can use to assess the effectiveness of the new site?
- What is your target audience? How do you know? Where and how can you find out more about your audience?
- What are the limiting technical factors affecting your site?
- Do you have a budget? What are some milestones for the site? What is the schedule like?
- Are you building a completely new site or making changes to an existing site? If it is an existing site, why are you making changes and what are some things you can learn from the first edition of the site?
About content building – again, always keep your user in mind. This is starting to sound like an adage in web-design-speak now, but it rings true. No one wants to build a website only to have it go kahoot when the user reaches your site and then leaves frustrated after 20 clicks to find the information they are looking for. Your team of designers and other stakeholders may be more concerned about the look and feel of the site, which is completely valid, but you as the site developer should pay more attention to your user analyses data. Let those testing results guide your decision on how to build content. The goal here is to create a website your target audience will enjoy using. Ensure the ease of access for content they are looking for and provide a good navigation system for them to discover new content!
File naming conventions – just to make a quick note about this. The ISO 9660 Standard is the base file-naming convention that works on all operating systems. The ISO 9660 has a maximum of eight letters followed by a period and a three-letter extension; allowed characters are letters, numbers, and underscore ( _ ) symbol. To ensure that all systems can open your files correctly, start the habit of naming your files using all lowercase. While there is no case sensitivity between Macs and PCs, the UNIX server IS case sensitive. <picture.gif> and <Picture.gif> are two different files for UNIX.
URL stands for Uniform Resource Locator. There are two kinds of URLs – complete and partial. A complete URL contains the exact location of the file page. Here is a breakdown of a complete URL: <a href=”http://http://www.yoursite.com/business/trends/laptop.htm”>
http = protocol
http://www.yoursite.com = domain
business/trends = path
laptop.htm = file
Partial URLs are links to files that reside in your own computer or server. These omit the protocol and domain or server name, and specify a path to the file that is in the current server. Here is an example: <a href=”laptop.htm”>link text</a>
Now here comes a point in the textbook that I don’t quite get and would like some clarification. In the section about setting your directory structure, there is a little bit more about partial URLs. Now, remember that your files need to be transferrable from your own computer to the server that hosts your site. Any URLs that you link in your pages that lead to another page on your website must include paths that are transferrable. Sklar writes, “You should never specify an absolute path in your partial URLs” (Sklar 126). By definition, a partial URL will not go far enough to reach the root directory, does it? Or is Sklar referring to the fact that you just omit the domain in the partial URL but might still need to write out the full path to the file. So, instead of writing /business/trends/laptop.htm, we should write /trends/laptop.htm. Am I getting this right?
After you have down your main content outline, you can start sketching out your folder structure (or a site flowchart, as I like to think of it). This structure will help you organize your site in a way that makes sense to both you and your user. There are two common types of structures – single and hierarchical. A simple site (like a personal site or a mom-and-pop shop site) can easily have a single folder structure. All the files needed for the main page are contained in one folder. However, if your site is a little bit more complicated (for example, with sectional tabs and interactive media), it is a good idea to organize your files in a hierarchical way. You will have one main folder and many sub-folders (and sub-sub-folders).
A quick note to self about creating hyperlinks between your pages (I will probably read about this later in subsequent chapters): <a href=”../index.htm”>Home Page</a> will lead you up one folder to your home directory. <img src=”../images/logo.gif”> is an example of going up one level and then down again to find a logo for your current page.