Sunday, December 14, 2008

Creating the Mock Site

Creating the Mock Site

After all design photo-types have been finalized, it is time to create what might be called the mock or alpha site. Implementation of the mock site starts by cutting a digital comp into its pieces and assembling the pages using HTML and, potentially, cascading style sheets ( CSS ). Try building the site using templates so that the entire site can be quickly assembled. However, do not put the content in place during this phase. Many of today’s modern publishing tools aid in the assembly of sample pages from screen composites. For example, consider the digital home page composites of the Demo Company site shown below.
We then can use a tool such as Macromedia Fireworks (www.macromedia.com/software/fireworks) to “slice” the sample layout into its appropriate pieces.

Designers should be cautious when using the HTML produced by slice and save features of applications such as Fireworks or Adobe ImageReady. These applications often produce non-standard, very complex, or difficult-to-maintain markup.

With the various pieces that make up the Home Page and the various sub-pages of a site, a Web designer can use a Web editor to assemble the components into fully working pages lacking real content; greeking text of the form “lorem ipsum dolor sit amet” should be used to give pages form. The fully constructed mock site may lack real content, but can give developers and testers a true flavor of how the site will eventually work.

Producing the HTML
While visuals and technical elements are very important to Web designers, the heart of nearly every modern Web page is still markup. Creation of HTML/XHTML should be taken very seriously as it must be a stable foundation upon which we will build presentation and interactivity.


Interactivity of page
Build with server and client side programming
Presentation of page
Build with HTML, CSS, flash and media elements
structure of page;
Build in HTML / XHTML


Yet despite its important as the page’s foundation, Web designers often are more concerned with how they creation is. In truth, there are pros, and cons to every method of HTML page and some of their pros and cons are presented in one of the images in the last post.
The reality of creating HTML documents is that there are occasions to use nearly every approach. For example, making a quick change of a single tag often is fastest in a pure text editor, saving out large existing print documents might make sense using a translator.






Saturday, December 13, 2008

The Site Plan

The site plan

Once a goal, audience, and site requirements have been discussed and documented, a formal site plan should be drawn up. The site plan should contain the following sections;
Short Goal Statement;
This section contains a brief discussion to explain the overall purpose of the site and its basic success measurements.

Detailed Goal Discussion;
This section discusses the site’s goals in detail and provides measurable goals to verify the benefit of the site.

Audience Discussion;
This section profiles the user who would visit the site. The section would describe both audience characteristics as well as the tasks the audience would try to accomplish at the site.

Usage Discussion;
This section discusses the various task/ visit scenarios for the site’s users. Start first with how the user arrives at the site and then follow the visit to its conclusion. This section may also include a discussion of usage measurements, such as number of downloads, page accesses per visit. Forms being filled out, and so on as they relate to the detailed goal discussion.

Content Requirements;
The content requirements section provides a laundry list of all text, images, and other media required in the site. A matrix showing the required content, form, existence, and potential owner or creator is useful, as it shows how much content may be outstanding. A simple matrix is shown below;

Technical Requirements;
This section provides an overview of the types of technology the site will employ, such as HTML, XHTML, CSS, JavaScript, CGI, Java, plug-ins, and so on. It should cover any technical constraints such as performance requirements, security requirements, multi-device or multiplatform considerations, any other technical requirements that are related to the visitor’s capabilities.

Visual Requirements;
The visual requirements section outlines basic considerations for interface design. The section should indicate in broad strokes how the site should relate to any existing marketing materials and provide an indication of user constriants for graphics and multimedia, such as screen size, color depth, bandwidth, and so on. The section may outline some specifics, such as organizational logo usage limitations, fonts requirements, or color use; however, many of the details of the site’s visuals will be determined later in the development process.

Delivery Requirements;
This section indicates the delivery requirements, particularly any hosting considerations. A basic discussion of how many users will visit the site, how many pages will be consumed on a typical day, and the size of a typical page should be included in this section. Even if these are just guesses, it is possible to provide a brief analysis of the server hardware, software, and bandwidth required to deliver the site.



Content
Item Description Content type Content
format Exist? Owner
Butler Robot
Press Release Press release for new Butler 7 series robot that ran in Robots Today Text Microsoft Word Yes Jennifer Tuggle
Software
Agreement form Brief description of legal liability of using trial robot personality software Text Paper Yes John P. lawyer
Handheld Supercomputer
Screen Shot Picture of the new Demo Company Cray-9000 handheld palm size computer Image GIF No Pascal Wirth
Welcome form
President
Message Brief introduction letter from President to welcome user to site Text Microsoft Word No President’s
Executive
Assistant


Miscellaneous Requirements;
Other requirements may need to be detailed in the site plan, such as language requirements, legal issues, industry standards, and other similar considerations. They may not necessarily require their own separate discussion, but instead may be addressed throughout the other sections of the document.

Site Structure Diagram;
This section provides a site structure or flow diagram detailing the various sections within a site. Appropriate labels for sections and general ideas for each section should be developed based on the various user scenarios explored in earlier project phases. Organizations of the various sections of the site is important and may have to be refined over time. Often, a site diagram will look something like the figure below.

Staffing;
This section details the resources required to execute the site. Measurements can be in simple man-hours and should relate to each of the four staffing areas; content, technology, visual design, and management.

Time Line;
The time line should show how the project would proceed using the staffing estimates from the preceding section combined with the steps in the process model outlined earlier in this post.

Budget;
A budget is primarily determined from the staffing requirements and the delivery requirements. However, marketing costs or other issues such as content licensing could affect the site cost as well.

This is just a suggested site plan- the actual organization and content of the site plan is up to the developer. However, don’t skip writing the plan even though it may seem daunting. Without such a fashion (almost trial-and-error manner), which may result in many false starts and waste time bids form outside vendors on the Web site without a detailed specification.




A site diagram will look something like this one shown;

Search Home copyright key
Site map database-driven
About Contact Us Jobs
History News
Products Releases FAQs
Domes Corporate Events
Robots Production
Balloons Economy
PSVs luxury
Cargo
Sport

A finished plan doesn’t allow you to immediately proceed to implementation. Once the specification is developed, it should be questioned one last time, preferably by a colleague or someone with an outside perspective. The completed specification may reveal unrealistic estimates that will throw you back to the stage of questioning initial goals or audience. If it survives, it may be time to actually continue the process with the design and prototyping stage.





Friday, November 28, 2008

http:// definition



HTTP

The Hypertext Transfer Protocol (HTTP, http) is the basic, underlying, application-level protocol used to facilitate the transmission of data to and from Web server. HTTP provides a simple, fast way to specify the interaction between client and server. The protocol actually defines how a client must ask for data from the server and how the server returns it. HTTP does not specify how data actually transferred; this is up to lower-level network protocols such as TCP.
The first version of HTTP, known as version 0.9, was used as early as 1990. HTTP version 1.0 as defined by RFC 1945, is supported by most servers and clients (Web browsers). However, HTTP 1.0 does not properly handle the effects of hierarchical proxies and caching, or provide features to facilitate virtual hosts. More important HTTP 1.0 has significant performance problems due to the opening and closing of many connections for a single Web page.
The current version HTTP 1.1 solves many of the past problems of the protocol. It is supported by version 4-generation Web browsers and up. There still many limitations to HTTP however, it is used increasingly in applications that need more sophisticated features, including distributed authoring, collaboration, multimedia support, and remote procedure calls. Various ideas to extend HTTP have been discussed and generic Extension Framework for HTTP has been introduced by the W3C Already, some facilities such as client capability detection and privacy negotiation between browser and server have implemented on top of HTTP, but most of these protocols are still being worked out. For now, HTTP continues to be fairly simple, so this discussion will focus on HTTP 1.0 and 1.1.




Wednesday, November 26, 2008

My Communities

Communities that I am signed up to just to get traffic into my blogs. I have been trying very hard to get traffic flow through my blogs. I have several communities that I’ve signed up to and if your joined into any of these, feel free to add me to your friends list in all of these communities, thanks and have a great day !!!
1.Bebo
2.del.icio.us
3.Mybloglog
4.twitter
5.BlogLogCatalog
6.Zorpia
7.Wink
8.Friendster
9.TypeKey
10.YouTube
11.FaceBook
12.MySpace Blog
13.Stumble
14.digg
15.MySpace Profile
16.Flickr
17.Blog.com
18.yahoo 360
19.yahoo answers
20.livejournal
21.other online
22.Blog Dune
23.Blog Cave
24.orkut
25.AC The peoples media company
26.Bumpzee
27.Helium
28.Fixtser
29.technorati profile
30.LinkedIn
31.My Free IQ
32.newsvine
33.reddit
34.hoverspot
35.I think thats all for now, I will add on if I think of any more of them…Holy Cow, thatz a lot !!!