Chapter 2 Web Development Overview Presented by Thomas Powell Slides adopted from HTML & XHTML: The Complete Reference, 4th Edition 2003 Thomas A. Powell
Five Pillars of Sites Web sites have five aspects with two participants (users & site owners) 1. Content 2. Structure 3. Technology 4. Presentation 5. Delivery Fail on one and you may find that the whole thing falls apart from the user s perspective
Need for Web Design Process Today we a Web crisis at times Just look around it is easy to see flaws It is even easier to break Web sites with just a little effort Many sites follow a simple ad hoc process at best HTML poorly executed Navigation seems poorly planned JavaScript doesn t follow simple programming practices Broken Links In short little planning and poor quality assurance Beyond ad hoc process the simplest way to improve things is to adopt a process model that guides a project. The most well known are top-down models
Design Process Standard Waterfall
Design Process Issues The waterfall model is easy to understand but it doesn t address all the issues facing Web designers Discrete steps aren t always easy to define Doesn t deal with change well Web sites are always changing Slower than many other process models Web sites seem to be on a deliver it yesterday timeline Lots of risk involved when the first stages are rushed However, despite its problems the Waterfall model is easy to implement and should be a first step for many designers. It is particular good for initial site development. Modification of the waterfall can be made to deal with risk and change factors
Design Process Modified Waterfall
What about Joint Application Design? Even the modified Waterfall approach doesn t deal with all problems Invariably clients or other decision makers change their minds. Some clients are unable to articulate what they are looking for Sometimes we just don t really know what will work so taking a shot or building a prototype works well. Many sites use this spaghetti approach see what sticks Joint Application Design (JAD) seems to deal with these issues but has serious drawbacks End up building the wrong site many times to make the right one People often marry the prototype Problems with prototypes can be damaging (The release too soon syndrome) Cost control can be hard; it s difficult to budget for these projects
What about Joint Application Design?
Learning a Web Design Process We are going to adopt a simple modified Waterfall approach to design for our discussion A great deal of time will be spent on the goals and early planning to avoid building sites that don t make sense Significant time also should be spent considering the user needs carefully. Give the people what they want!
Why are we doing this? First talk about goals and problems No goal Vague goal Goal should be measurable otherwise you are at risk Build a customer support site that will improve customer satisfaction by providing 7/24 access to common questions and result in a 25% decrease in telephone support. Create an online car parts store that will see at least $10K/month of product directly to the consumer. Develop a Japanese food restaurant site that tells potential customers about menu, hours, and prices. Is the last goal a good one? Why or why not? A goal at the start of the project should be to come up with a short a long form of a site s goals. (Mission Statement + Project Description)
Figuring Out the Goal Brainstorming process Techniques Get read to use the whiteboard Start with what people don t like particularly on a redo project if it is difficult to determine what to do. Create a wish list. Let the wish list get a big as it needs too Don t throw out any idea at this stage Narrow the wish list and try to get people to compromise Beware: Everybody wants to be on the homepage 3x5 card technique helps
It s for Users Audience discussion Profile your audience Who are they What do they want to do Talk to users Surveys and interviews Be careful not to direct the results Always remember you are not the user
Putting it together Given goals and audience you should be able to begin to figure out what is necessary to accomplish the goal. These are the requirements. Requirements include staffing, content, technology, graphics, etc. In short everything you need to do the job. You don t have to put it together quite yet.
The Site Plan Short goal statement Detailed goal statement Audience Discussion May include user Scenario Discussion Requirements Content Requirements Make a matrix of what is needed Technical Requirements What type of tech is needed (JavaScript, Flash, etc.) Visual Requirements Are there design parameters like color, font, logo, other media that needs to be considered when building the site.
The Site Plan Contd. Delivery Requirements Where will it be hosted Site Structure diagram (flowchart)
The Site Plan Contd. Other Requirements Staffing Timeline Budget With the design document in hand and approved it may be time to actually start the design. Tip from the Real World: Always collect the content before design if at all possible. Slowest aspect of projects. Content should influence the design (form follows content)
Continuing the Process Once you are ready to build a site you might want to work out more details on a page level. For example use wireframes or page level block diagrams to work out content and general position.
The Design Process: Comping Design composites ( comps ) or sketches can be made but should always be framed by a browser window. Tip: Start from the home page and then work down.
The Design Process: Comping Commonly Macromedia Fireworks or Adobe Photoshop are used to create graphical composites.
The Design Process: Comping You may need to storyboard an action such as form fill-out.
The Design Process: Cut Up Once you have finished your composite you will have to cut it up to begin building (X)HTML templates for your site. Many tools like Fireworks or the ImageReady portion of Photoshop can automate this but you may find they produce lousy markup. Tip: Don t marry your design prototypes and always listen to your users and customers for refinements.
Producing the (X)HTML Markup is the page foundation. It s production should not be approached lightly. Create markup incorrectly and it may effect other things Demo
Producing the (X)HTML Method Example Pros Cons By hand Coding pages with Notepad + Great deal of control over the markup + Can address bugs and new HTML/XHTML elements or CSS properties immediately - Slow - Error prone - Requires intimate knowledge of HTML/XHTML elements and CSS properties - No direct visual representation Translation Save as HTML from another tool like Microsoft Word + Quick + Simplifies conversion of existing documents - Produced markup often is problematic - Often requires editing to add links and clean up problems Tagging Editor Using HomeSite + Great deal of control + Faster than hand editing + Provides help addressing errors and writing structured markup and correct CSS - Can be slow - Requires intimate knowledge of HTML and CSS WYSIWYG Editor Using Frontpage or Dreamweaver + Works on visual representation of page + Requires no significant knowledge of HTML/XHTML or CSS - Often generates incorrect or less than optimal markup or CSS - Tends to encourage fixed size presentations that do not separate look and structure
The WYSIWYG Promise When comparing code editing to visual editing it would seem that WYWIWYG editors are the way to go. But are they really?
WYSIWY-might get! In some ways WYSIWYG is impossible on the Web Even when it is close enough it does not allow us to take advantage of the idea of logical markup Interestingly WYSIWYG editors are getting better as more strict markup is used.
Validating Markup Regardless of how you produce markup it should be well-formed! Use a validator to check your work Online validators: http://validator.w3.org Software validators: http://www.htmlvalidator.com Be careful some validators in editors are not strict syntax checkers Validation Lab Type in the example on page 46 of the 4 th edition and test it with the W3C validator
Markup Production Tips Always follow the rules (lowercase, etc.) Validate, validate, validate Name well File names and tag id values Try not to mix style and structure or script and style Use Templates Format and comment for yourself, crunch for delivery No value for view source in the long run Crunching Demo
Site Building Process Once you have templates build a mock site with no content. You might call this an alpha site Use greeking lorem ipsum text to fill in pages http://www.lipsum.com/ Consider retesting the mock site design with users Implement your site with real content and add technology At this stage you should have a beta site
Testing XHTML & CSS I 1 Law: Sites always have bugs. Testing should address all aspects of the site including content, function, visuals, and purpose. Visual acceptance Functional testing Content proofing Browser test Delivery Test User acceptance and usability testing
Finishing the Site Once your site is released you aren t done. Site development is an ongoing process. Plan, design, develop, release, repeat. Study your log files, interview users and measure your success or failure before you start changing things It isn t as easy at it seems. The real world has lots of challenges. Outside experts, silver bullet tools, bad timelines and budgets, people problems, etc. Webmasters? Not likely Web Teams? More likely