Website Conceptualization

Every business these days wants to have a presence on WWW; the main objective is to be able to target the global market and creating a profile of the company, which can be accessed by anyone from anywhere! This is opened many opportunities for the business involved in designing & development of websites, and depending upon the size of the business processes and approach for deploying a web based application changes. Which is very fair because everyone has his/her style of working and making deliverables, if the process & approach does not include all the basic steps of a software development life cycle it leads to the problems like – deadlines are not met and the scope of the work changes as the work progresses.

The clients might not be tech & internet savvy so they are not able to visualize how their site will look like and when they get the first demo of the application that is being developed for them it acts as the food for thought. They then try to relate it with what they are looking at and there business model. As a result they expect some changes to be done to the features or the style in which the information is being displayed on the website. Which results into requirement of additional time and effort for accommodating such things, and leads to the above mentioned problems.

There is a believe that anyone can start delivering web based services and can keep the cost low by not hiring people who actually are skilled to accomplish this task. The thought originates a company with the problems of delivering work which is not quality and ending up with unhappy customers.

Why this happens?

Continue reading

Stylesheets Advantages

Because you are able to create a separate Stylesheet and link it to all your webdocuments, you have great control over how your website looks. So if you want to change a certain aspect of your page, you only need to alter one file: your Stylesheet!

This Of course, generates some great flexibility. This flexibility is not available when your website is using tables for layout, inline font tags or inline defined colors.

A single CSS file can contain positioning, layout, font, colors and style information for an entire web site.

2. You site uses less bandwidth and loads faster

Because stylesheets are so lightweight, your website will load much faster. The main reason is because you do not need table layouts anymore for the positioning of elements. Since text loads really really fast your website will be visible in a flash.

This means that visitors will be happier when surfing your website. They only have to download the Stylesheet once, and it’s automatically reused for every page. So the only thing that needs to be loaded is the actual content.

On average a website will load five to ten times faster if it makes use of cascading style sheets.

3. Your website will automatically gain better search engine results

With CSS, you can position any element, anywhere you want. So if your menu is at the bottom of your HTML document, you can bring it up using absolute positioning. The reason this is useful is to make sure the search engine spiders pick up the main content first.

Another advantage you automatically gain is that your HTML code is much cleaner. So the search engine spider will not have to separate the junk code from the real content.

So make sure you put your logo text and your menu at the bottom of your HTML document at put it at the top using CSS!

4. CSS is compatible with newer browsers

Because more and more browsers are used other than Internet Explorer on a Windows machine, you need to be sure that your website is accessible by all major and newer browsers.

By using webstandards, defined by the w3c, you are making sure your content is viewable in the future.

Because there are so many browsers these days, it is impossible to test your website in all these browsers on different configurations. Coding to standards is then the only practical solution.

5. CSS can be used to display the same content on different media.

Because you are able to define different stylesheets for different media you have great flexibility in presenting your content.

The printer for example, is a medium on itself. If someone prints out your website, you will be able to modify the look of it. Add an extra black and white logo, remove the advertisements and change the colors to black and white values. It’s all done easily by using cascading stylesheets. And the best thing is, visitors do not even have to know you created a new Stylesheet especially for the printer.

Stylesheets can also be created specifically for PDA’s and such. As you will understand, this adds some great flexibility to the presentation of your web document.


Cascading Style Sheets are created to make things easier. It gives you great control of your website and makes your visitors happy when they are surfing your website.

You are prepared for the future and will gain better search engine results automatically. Start using CSS to its full potential today! It will suit you well.

Do not use flash in web pages

I am a person who hates to keep flash in a web page as it reduces the website loading speed drastically.Hence i am writting some of the resons for not including flash in your web pages.Please do have consideration on them and decide yourself.

  1. You can’t use the browser’s Find command to find a word on a Flash page.
  2. You can’t cut-and-paste text from a Flash page.
  3. You can’t use the browser’s “back” button to go back in a Flash file.
  4. To create a Flash website, you need to buy the $500 Flash application from Macromedia; to create an HTML website, you can do so with any free text editor.
  5. It tempts designers to prioritize using Flash over making an easy-to-use and useful website. In the hands of 95% of designers, Flash is used to create websites that would have been better made as HTML.

20 pro tips for web development

The difference between a good web designer and a great one is the ability to know how to take short cuts and save time without compromising the quality of work. Pixelsurgeon’s Jason Arber has put together 20 top tips and tricks you should be using to give your work that all-important professional edge

1. Planning

When you’re itching to get started, it’s easy to overlook the most obvious step: planning. Whether it’s drawing wireframes and site diagrams in OmniGraffle or Visio, or even on a scrap of paper, you’ll save time by having an overview of your design at the site and page level before you start building. Obvious errors can be detected and solved before it’s too late to go back and it makes explaining your ideas to clients and colleagues a lot simpler than waving your hands in the air.

2. Do it by hand

Although there are some excellent tools around for building web sites, such as Adobe GoLive and Adobe (formerly Macromedia) Dreamweaver, professional code monkeys prefer to code by hand. Are they crazy masochists? Quite possibly.

There’s only one way to learn HTML, and that’s to roll up your sleeves and get your hands dirty with some actual code. But fear not: HTML has one of the easiest learning curves you’ll ever come across and you can create a basic web page with only a couple of lines. Writing code by hand also ensures that you write the leanest code possible, which is the ultimate aim of all HTML geeks.

Don’t throw out that copy of GoLive or Dreamweaver just yet. Both applications have excellent code writing environments, and have useful features, such as collapsable blocks of code and split views so you can code and see the results at the same time. If you want to try the code-only route, then any text editor that can save in the basic .txt format should do, but Mac users might want to check out Bare Bones Software’s BBEdit, and Windows users should give the freeware AceHTML editor from Visicome Media a whirl.

3. Stylesheets: importing vs linking

There are two ways to attach an external stylesheet to your HTML page, and not all browsers understand both methods. This can be used to your advantage to feed one stylesheet to modern browsers and another to Netscape 4.x, which would otherwise choke on more complex CSS.

Cascading stylesheets are designed to flow over each other. The secret is to create a simple stylesheet that works in Netscape 4, with more complex CSS relegated to an additional stylesheet that’s attached using @import, which Netscape 4.x will ignore:

<link rel=”stylesheet” href=”simple. css” type=”text/css” media=”screen”>
<style type=”text/css” media=”screen”> @import url(simple.css); </style>

4. Smarter gradient backgrounds

CSS gives you a lot of control and flexibility over the tiling of background images. And the great thing is that tiled images are not limited to the Body background but can also be applied to any DIV, block level or inline element.

Images that tile conventionally or just along the x or y axis can be set to scroll with the page or remain fixed while the rest of the page scrolls over it. Backgrounds can also be offset. This means that it’s easy to create a vertically graduated background that never repeats no matter how long the page is, using graphics that are only a few kilobytes in size.

Using the following code, the background.png file need only be as tall as the gradient and one pixel wide. This example assumes that the gradient fades into white, but the backgroundcolor attribute could be any value.

body { background-color: white; background-image: url(background.png); background-repeat: repeat-x; }

5. Commenting

When you come back to a site that you designed months ago, there’s nothing worse than trying to figure out what you did and attempting to untangle a spaghetti of code. Do yourself (and anyone else who wants to check out your code) a favour by putting comments in your HTML. Comments might add anything from a few bytes to a kilobyte or two to your page, but the time savings are invaluable.

Commenting also encourages you to keep your code tidy by breaking it into logical chunks. Some coders even use comments to create a table of contents for the page, which is only visible in code view.

Be aware that HTML and CSS use two different kinds of commenting, so you may want to learn the difference.

<!– HTML commenting looks like this and is enclosed within angle brackets and two dashes. The opening tag includes an exclamation mark. –> /* CSS comments are enclosed by a forward slash and an asterisk. */

6. Use simple PHP to build sites

There’s no need to become a PHP expert to start using it in your site. If your server supports PHP, you can quickly and easily use server side includes to build a library of commonly used elements, inserting them into your web page with a simple link. This is great for elements like menus, which can exist as a single instance, and means that if you add a new menu item or change the design, you just need to change the include file, which will then update the whole site.

Includes are simply snippets of HTML code such as a table or unordered list. The page calling the includes should end .php and the includes are inserted using the following simple code:

<?php include(“filename.html”); ?>

7. Set fonts using ems

Designers love specifying type sizes in pixels because it corresponds easily and naturally with what they do in Photoshop. But as a type size specification for the web, pixels have one major disadvantage: they can’t be resized in Internet Explorer. As monitor resolutions increase, it’s not only the visually impaired who may want to increase the font size in your design, so what’s the solution?

The answer is to specify type in ems. If you’re unfamiliar with the unit, an em is roughly the width of a lowercase em in a font, and using a browser’s default internal stylesheet, an em is roughly equivalent to 16 pixels. Set the font size attribute in the body tag to 62.5 per cent like this:

body { font-size: 62.5% }

This makes one em roughly ten pixels (16 x 62.5% = 10). Now you can equate pixel sizes to ems. For example, type that is set in 12 pixels could be expressed as 1.2em; 9 pixels becomes 0.9em and so on. What’s more, both the designer and user are happy.

8. IE Box Model Hack

Sooner or later you’ll come across an important bug in Internet Explorer that incorrectly calculates the width and height of block level items by including padding values within the box’s dimensions, rather than adding it outside the box. This can wreck layouts. The solution is known as the Box Model Hack, which uses another bug in IE to force it to use tags that other browsers ignore. If you have a div validly specified like this:

div {_ width: 100px;_ padding: 5px;_ border: 5px solid #fff;_ }

You’ll end up with a box that’s 120 pixels wide in most browsers, but only 100 pixels wide in IE. The easiest solutions is the box-within-a-box method, which places one div inside another:

div {_ width: 100px;_ }
div .hack {_ padding: 5px;_ border: 5px solid #fff;_ }

This is applied in the following way:
<div class=”hack”>
Your content goes here

9. Space saver

Nobody likes building forms in HTML, especially as browsers insist on adding padding around them for no reason. Simply add the following CSS to your stylesheet:

<form style=”margin-top: 0; margin-bottom: 0;”>

10. Test, test and test again

While Internet Explorer still dominates the browser market by a huge percentage, its lead is being gradually eroded by other browsers such as Firefox and Opera. There are also plenty of people out there still using archaic browsers like pre-Mozilla versions of Netscape.

It’s virtually impossible to design great-looking web sites that work in all browser versions, so it’s best to decide which browsers you’ll support. Mozilla-based browsers, WebKit-based browsers (such as Apple’s Safari), KHTML-based browsers (such as Konqueror), Opera and Internet Explorer versions four and higher are generally considered a safe benchmark. However, you should still be a good net citizen by ensuring that your code degrades gracefully, so that even unsupported browsers can experience your site – even in a limited form (see tip 14).

11. Format fundamentals

In the old days it used to be simple. If the image contained flat colours like a logo, use a GIF. If it was photographic, use a JPEG. There’s also an overlooked third format, PNG (pronounced ‘ping’) that comes in two flavours: an 8-bit version containing 256 colours, like GIFs, and a 24-bit version with alpha channel support allowing for variable transparency.

The bad news is that Internet Explorer doesn’t support PNG’s alpha channels without resorting to a complex hack. However, 8-bit PNGs generally compress much smaller than the equivalent GIF version. Unless you need animation, which PNGs can’t do, PNGs can replace GIFs in most situations, resulting in an overall file size saving.

JPEGs usually create smaller files than 24-bit PNGs, so unless you’re taking advantage of PNG’s alpha channel transparency using the hack (, then JPEGs are still the best format for continuous tone images.

12. The ‘title’ and ‘alt’ attributes

Ensure that all your images make use of the alt and title tags so that screen readers for the visually impaired can correctly parse your page:

<img src=”logo.gif” alt=”logo” title=”logo/” />

13. The correct format for pseudo classes

For text rollover effects, it’s important that the pseudo classes are in the right order, or they won’t work correctly in all browsers. The correct order is:

a:link { color: blue; }
a:visited { color: purple; }
a:hover { color: purple; }
a:active { color: red; }

14. Use semantic mark-up

The idea behind semantic mark-up is to separate the content of your web site from its appearance so that it degrades gracefully. Ideally, if you were to remove the stylesheets, your web site should still work. It might not look pretty, but it means that users with older browsers, will still be able to get meaningful content from your site.

The positioning, styling and a certain amount of interactivity can then be added with stylesheets and CSS-P.

15. Favicons

Favicons are the little 16×16 pixel icons that appear in your favourites lists and the title bars of web sites. They’re quick and easy to add: save a graphic in .ico format (Mac users may want to consider using Graphic Converter as Photoshop doesn’t support this format) and put it in your site’s root folder. It’s as simple as that.

16. Change capitalisation using CSS

If you need something written in capitals, such as a headline, rather than rewriting the copy, let CSS do the donkey work. The following code will transform all text with an h1 attribute into all capitals, regardless of format.

h1 { text-transform: uppercase; }

17. Wrapping text around images

For a quick and dirty way of wrapping text around images, use the image’s align attribute to push it to the left or right. Rather than jump below the image, text should now flow along the edge.

<img src=”image.jpg” align=”left”>

18. Universal character sets

Character sets are an important part of a web page’s definition, but they’re probably the least understood component. Character sets, which are defined in a web page’s invisible head section, tell the browser what method is being used to encode the characters. A charset ISO Latin 1 (also known as ISO 8859-1) will render the code it finds using a basic Western alphabet, but a charset of Shift JIS will attempt to render any characters it finds as Japanese.

With so many competing character sets, problems can occur, especially when using the MS Windows character set (which contains certain characters that may be replaced by a blank space on other operating systems) or when several languages need to appear on a single page.

The answer is to use a single universal character set that’s able to cover most eventualities. Luckily one exists: UTF-8, which is based on Unicode. Unicode is an industry standard that’s designed to enable text and symbols from all languages to be consistently represented and manipulated by computers. UTF- 8 is rapidly becoming the charset definition of choice, and should be included in your web page’s head like this:

<meta http-equiv=”content-type” content=”text/ html;charset=utf-8” />

19. Print styles

When people print web pages, often they’re not interested in your flashy graphics: they just want a simplified version of the page. Using CSS it’s possible to create a separate stylesheet that only affects printed versions of your site, rather than having to create a new HTML page or adapt an existing one. You add a print stylesheet in exactly the same way that you would add a regular stylesheet to your page:

<link rel=”stylesheet” type”text/css” href=”print.css” media=”print”>


<style type=”text/css” media=”print”> @import url(print.css); </style>

This ensures that the CSS will only apply to printed output and not affect how the page looks on screen. With your new printed stylesheet you can ensure you have solid black text on a white background and remove extraneous features to maximise readability.

20. Learn from others

Finally, a quick and simple tip: learn from great sites built by others. Any site’s HTML is easily accessible by viewing a page’s source code. See how others have done things and apply their methods to your own work.

12 Steps to become a better Web programmer/designer

Whether writing server-side, client-side, or regular-old-markup, you need to develop some debug muscles. Errors are an incurable side effect of human programming, and when they pop on your screen, you can probably hear your bank account draining. Become an adept debugger and you’ll write cleaner apps, in shorter time.
Bigger Debuggers in 12 Easy Steps
Considering how much time we all spend debugging, it is ironic how rare a topic it is in books and conversation. So how does one become a better debugger? Hopefully, the twelve guidelines I’ve compiled here will help you squash bugs faster, smarter, and with more authority.
1. Organize your code.

Let’s face it, building websites isn’t rocket science. If you’ve been at it for 6 months, you’ve probably developed some sort of methodology. All sites share common elements, pay attention to what they are and re-use code as much as possible. Organize your code and includes so you know where everything is.

The W3C is pushing standards that separate content from structure; you’ll find adopting this philosophy helps when debugging as well. Some general guidelines:

- Code once, include often. I’ll say it again, organize your code so you know where everything is. Strive to have no duplicated code on your site.

- Externalize client-side scripts.
Put all CSS and JavaScript into external includes. Your pages will load faster, as the scripts will go into the browser’s cache. Also, you’ll be able to disable all your JavaScript or all your CSS more easily. Resist the temptation from the darkside, never code CSS inline or write javascripts willy-nilly through your pages. You’ll be happy later when you want to either turn it all off, or export it to another project.

- Refine it.
Every website gains features through the development cycle. When a complex project reaches the 75% complete zone, it is usually begging, pleading, and bleeding for a rewrite. Try to take the 2, 3, maybe 4 days it will take to go back through your code and refine it when it feels out of hand. Don’t be the type of a developer that has an FUNW folder for an inbox. Try to build in as much scalability as you can from the start.

2. Isolate and identify the problem.

This is the key to all debugging, and a close cousin of code organization. The problem code block must be identified, and identified quickly. If you’re debugging-while-developing (DWD), you know the first place to look is the code you were just working on. If you’re debugging-while-updating, or wading through someone else’s work, isolation becomes more difficult.

- Trust no-one.
Your first suspect should be the machine you’re testing on. Is the error totally bizarre? Does another, known to be working page serve OK? Computers crash all the time, and test boxes that kick more errors than successes all day will tend to crash more. If you test on a *nix box, you probably find this paragraph funny. If you’re on Windows, reboot your test machine at least once a day.

- Believe the error message.
If you’re reasonably sure your machine is stable, look for clues in the error message. It’s funny how those messages make sense afterwards, isn’t it? Line numbers in error messages are almost always wrong, but are invariably the best place to start looking. Head backwards from the line number reported, and check the nesting of that segment. When you can’t find the error, comment out sections of your code until the error stops popping. Then cut and paste the problem block into a separate template for surgery.

3. Validate your code.

Make the validator your home page. Writing valid HTML of some flavor is an excellent first step in error prevention. If you’re new to validation, start with 4.01 Transitional. There are also many standalone tools available, the W3C maintains a list here.

4.View the source code.

When you’re working server-side, many times you can find problems faster by viewing what came out, rather than looking at what went in. Check the output, test variables using HTML comment blocks, or use a simple JavaScript alert to dump server-side variables. If you’re dealing with a variable that changes throughout the page, output it several times.

5.Be the layout master, not the master layouter.

When dealing with a layout problem, first determine if it is an HTML or CSS problem.

- View it naked.
Try disabling CSS, that is, if you have it in external files.

- Preview in many browsers.
Test in whatever browsers and resolutions are appropriate throughout the entire project. Don’t wait until the very end to discover your client’s V.P. uses AOL 2.0 on an Amiga with a 13″ monitor. HTML with syntax errors usually renders inconsistently across browsers, so if you see this behavior, inspect your HTML. Repeat step 3, and make sure your HTML validates.

6.Man-handle forms

Everyone hates forms. If you don’t, you haven’t done enough multi-page checkouts yet. Bulletin boards everywhere are crawling with people having form trouble, and it’s almost always related to bad-HTML or a misnamed field.

- Dissect the form elements.
Break down the form into small chunks until you find the problem. If you’re using the POST method, does the page even submit? How about with one variable? Same for the GET method, can you pass at least one variable and have it show in the URL of the target page?

- Name fields sensibly.
If the form fields correspond to table columns in a database, use the same names for both, or adhere to some naming convention. Always build and debug server-side validation before introducing any JavaScript validation.

7. Write clean queries.

An extremely typical data-driven website scenario: You write a query in whatever, and then try to output the results. Sounds fine, but how often do you actually test the query output in its entirety? A good cabinetmaker measures twice, and cuts once. Most programmers measure a little, and hack it with an axe until it fits.

- Isolate the SQL.
Cut and paste your SQL into its own template and run it there. Can you output anything? Write a function in your favorite server-side scripting language that auto-dumps complete result sets for you, so you can test them before you try to output them on your pages.

- Declare all columns.
Never write SELECT all FROM table, name your fields explicitly. Even if you need every column in the table, naming them will help your templates become self-documenting.

- Run it at the source.
Websites usually connect to databases through ODBC or some other method. At the first sign of trouble, run the query in its native program if possible.

8. Organize your variables.

Keep your local variables in a structure or array. If you store all your local variables in one object, it is much easier to dump their values onto the screen as a whole, which is an invaluable tool when debugging.

- Keep your ducks in a row.
Every server-side language has a method for outputting complex datatypes. Store your local variables in an array or structure so you can dump them onto the screen. You might create a special footer, triggered by a URL variable, which dumps your local variables. Never put this sort of code on your live server.

- Avoid reserved words.
RTFM and find out what the reserved words for your favorite languages are. Errors caused by reserved word misuse are difficult to diagnose, prevention is the best medicine.

9. Proceed slowly, preview often.

When you first started coding, you probably previewed every H1, and scrutinized every images Typically, the more experienced programmers become the more code they’ll write before previewing.

- Go slow.
Try to find a comfortable amount of coding before previewing, so that you have a manageable chunk to work through when there’s a problem. In my checkered past, I have painted houses for money. I once worked with a guy that seemed to move in slow motion, but at day’s end he had always done the most work.

- Work methodically.
Whether you like to bring all elements of a site to the same point simultaneously, or like to finish each section as you go, decide what you’re going to do and stick to it. Do the hard parts first, and save the easy stuff for when you’re sick of the project.

10. Mirror your test and production setups.

If you’ve ever uploaded files to the server with a local path unchanged, take off your left shoe and eat it. The feeling is right up there with sitting in the Principal’s office, or locking your keys in your car.

- Mirror the server setup.
Though not always possible, the advantages of having the same physical drive and folder setup as your production box are huge, and can save you hours of heartache and sweat drenched ftp sessions.

- Use absolute paths.
Consider using absolute paths as much as possible. Avoid using the base tag, as it will inevitably lead to disaster. A long long long time ago, I uploaded a site with a base tag set to Can you guess what happened? Everything seemed fine when I tested the uploads, because the live site was referencing my local machine. Whatever you do, don’t mix absolute and relative paths choose one and avoid the other.

11. Work like a debugger.

Make your work environment work for you. I like to hog as many machines at once as possible, coding on one and previewing on the others.

- Keep your reference books handy.

- Make sure you have video games and sugar water within reach.

- Tell noisy people to shut their pie-holes.

Nothing clears a room like great music. If Sun Ra doesn’t drive them out, I highly recommend Charles Ives’ Fourth Symphony.

- Become an alt-tab, or alt-arrow ninja.
Windows does a nice job of keeping track of your recent selections, so tabbing between your editor and browser(s) is a quickly learned skill. Soon you’ll be tapping: alt-tab, ctrl-r, alt-tab, rinse and repeat. And if you’re GUI-ridden, use your keyboard to navigate drop-downs in your programs, it’s faster than playing with your mouse.

12. Don’t waste time, take a break, ask for help!

Don’t spend more than 5 minutes trying to fix something (unless you’ve really done it this time).

- Take a break.
Work on something else for a while, work on nothing for a while, beat your head in with a hammer, and come back to the problem later.

- Don’t go it alone.
Sometimes a fresh set of eyes can pick up a missing semi-colon faster, so don’t be afraid to ask for help when you get jammed. If you work alone, find a mailing list or bulletin board you like.

Flex Those Debuggers

Hopefully, this article has gotten you to think about how you debug, which may in turn get you thinking about how you construct your web applications. As programmers, we feed our bottomless curiosities with small victories, and fuel our fires with the burning cinders of lift-off catastrophes. So get out there, write a whole heap of errors, and be proud when you bomb the whole server.

Page 1 of 212