jQuery menu few simple steps ;)
January 29th, 2009 by adminhere is an example of code if you can’t understand something pls ask me 
but i think this is very simple for you we you will use just really small javascript and css that’s all 
what you gonna do :
1 – made html file for example “menu.html”
2 – open file “menu.html”
3 – copy this html code below
4 – paste this code into your “menu.html” file
5 – save “menu.html”
6 – run it in FireFox for example
7 – made a changes in this code if you need it
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
<html xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<title>Menu Demo</title>
<script src=”http://jquery.com/src/jquery.js”></script>
<script>
$(document).ready(function(){
$(“dd:not(:first)”).hide();
$(“dt a”).click(function(){
$(“dd:visible”).slideUp(“slow”);
$(this).parent().next().slideDown(“slow”);
return false;
});
});
</script>
<style>
body { font-family: Arial; font-size: 12px; }
dl { width: 100px; }
dl,dd { margin: 0; }
dt { background: #999; font-size: 14px; padding: 2px; margin: 2px; }
dt a { color: #FFF; }
dd a { color: #000; }
ul { list-style: none; padding: 2px; }
.s { background: #999; font-size: 14px; padding: 2px; margin: 2px; }
.s a { color: #FFF; }
</style>
</head>
<body>
<dl>
<dt><a href=”/”>Menu jQuery</a></dt>
<dd>
<ul>
<li><a href=”http://blog.branding-studio.com/2008/12/simple-css-menu/”>Item 1</a></li>
<li><a href=”http://blog.branding-studio.com/2008/12/the-technology-validation-of-the-forms/”>Item 2</a></li>
<li><a href=”http://blog.branding-studio.com/2008/11/ajax-email-validator-ajax-php/”>Item 3</a></li>
</ul>
</dd>
<dt><a href=”/Menu1/”>Menu1</a></dt>
<dd>
<ul>
<li><a href=”http://blog.branding-studio.com/2008/11/your-own-scrollbar-color/”>Item 1</a></li>
<li><a href=”http://blog.branding-studio.com/2008/11/css-image-effect-you-can-use-it-in-your-gallery/”>Item 2</a></li>
<li><a href=”http://blog.branding-studio.com/2008/10/some-rules-for-web-designers/”>Item 3</a></li>
</ul>
</dd>
<dt><a href=”/Menu2/”>Menu2</a></dt>
<dd>
<ul>
<li><a href=”http://blog.branding-studio.com/2008/10/7-simple-ways-to-get-repeat-websitetraffic/”>Item 1</a></li>
<li><a href=”http://blog.branding-studio.com/2008/10/do-you-want-build-your-website-what-do-i-need-to-do-for-star-my-online-project-first-steps/”>Item 2</a></li>
</ul>
</dd>
<div class=”s”><a href=”http://blog.branding-studio.com/2008/10/how-to-build-a-great-web-site/”>Menu3</a></div>
<div class=”s”><a href=”http://blog.branding-studio.com/2008/09/web-design-web-development-seo/”>Menu4</a></div>
<div class=”s”><a href=”http://blog.branding-studio.com/2008/10/4-stages-of-web-site-design/”>Menu5</a></div>
<div class=”s”><a href=”http://blog.branding-studio.com/category/for-all/”>Menu6</a></div>
<dt><a href=”/Menu7/”>Menu7</a></dt>
<dd>
<ul>
<li><a href=”http://blog.branding-studio.com/2008/10/what-is-specification-how-its-look-like/”>Item 1</a></li>
<li><a href=”http://blog.branding-studio.com/2008/09/here-some-sites/”>Item 2</a></li>
</ul>
</dd>
</dl>
</body>
</html>
an example
be happy !!!
The technology validation of the forms
December 9th, 2008 by adminFirst part :
<script type=“text/javascript”>
//<![CDATA[
function checkform()
{
document.getElementById('urltosend').action="addmess2.php";
document.forms['addform'].target=”process”;
top.document.forms['addform'].submit();
}
//]]>
</script>
…
<form id=“urltosend” name=“addform” method=“post” action=“addmess.php”>
…
<input type=“button” onclick=“checkform()” value=“Отправить данные”>
…
<iframe name=“process” id=“process” width=“0″ height=“0″ style=“visibility: hidden”></iframe>
…
<div id=“alerts”></div>
Second part:
<?php
/*
$alerts.=”Error1<br />”;
$alerts.=”Error2<br />”;
и так далее.
*/
print ‘<script type=”text/javascript”>’.“n”;
print ‘//<![CDATA['."n";
if ($alerts)
{
print "top.document.getElementById('alerts').innerHTML='".$alerts."<br />';"."n";
}
else
{
print "top.document.getElementById('alerts').innerHTML='all is great !<br /><br />';"."n";
print "top.document.getElementById('urltosend').action='addmess.php';"."n";
print "top.document.forms['addform'].target=’_top’;”.“n”;
print “top.document.forms['addform'].submit();”.“n”;
}
print ‘//]]>’.“n”;
print ‘</script>’.“n”;
Just simple example javascript and php
Your own Scrollbar color
November 4th, 2008 by adminIn IE5.5+ and above, you can use CSS to customize the color of the scrollbars on the page, which includes various components of the scrollbar. The below CSS shows the relevant CSS properties for scrollbar coloring. Note that if your page uses a doctype that triggers a “Strict” mode in IE, the scrollbar properties need to be assigned to the “HTML” tag instead of the conventional “BODY” in order to work.
The CSS (for non “strict” doctypes):
body{
scrollbar-face-color:#EBF5FF;
scrollbar-base-color:#EBF5FF;
scrollbar-arrow-color:black;
scrollbar-track-color:#F3F3F3;
scrollbar-shadow-color:#EBF5FF;
scrollbar-highlight-color:#EBF5FF;
scrollbar-3dlight-color:#78AAFF;
scrollbar-darkshadow-Color:#78AAFF;
}
The CSS (for “strict” doctypes):
html{
”
”
}
CSS Progress bar ;)
October 29th, 2008 by adminThoughts
We’ll put a cool background image in the container and define fixed width and height. First child (SPAN) will act as a progress bar. We’ll absolutely position second child (EM) above the progress bar and shift it to the left to a desired value. EM has the same background as the container so it gives an effect of progress bar stopping at certain percentage.
Read More »
Preloader…
October 26th, 2008 by adminHere is image preloader you can use this this script to not only preload images before displaying them, but also, get a live update on it’s progress through an update bar. Once the preloadiing is complete, the surfer is then directed to the page containing the preloaded images.
here is sample of code :
P.S. sorry I forgot. You need made 2 gif images one 1X1 pix black dot and other 1X1 pix blue dot . Call them blue.gif and black.gif and paste them in the same scriptfolder.
Opera and Safari
October 26th, 2008 by adminBack in the day, there used to be a hack for Safari using the pound (#) sign. Safari didn’t like that symbol, so you could declare something like this:
p { color: red; }
p { color: black;# }Every other browser will read the second line replacing the first line and the text will be black. Safari doesn’t like that pound sign and will stick with the first declaration and the text will be red. This is the perfect example of why using hacks are a bad idea, because it no longer works (Safari 3 and beyond).
Now there is a new hack on the block targeting newer versions of Safari as well as Opera 8/9:
@media screen and (-webkit-min-device-pixel-ratio:0) {
/* Safari-Opera specific declarations here */
}Originally published here.
4 stages of web site design
October 12th, 2008 by adminTypically, web site designs evolve. In the beginning, many web site owners become enamored with “bells and whistles” that, on the surface, might appeal to their target audience. Flash movies, Java applets, animation and other rich media has become increasingly popular over the years.
However, in the rush to have the “coolest” site design, web site owners forget whom they are designing their site for: their target audience. Your audience might find that Flash movie irritating after viewing it multiple times. Your audience might not be able to find your site in the search engines. “Bells and whistles” are attributes of a web site that need to be measured and tested to see if they increase or drive away sales.
Below are the various stages of evolution web sites typically undergo:
- Stage 1 – Style Over Substance
- Stage 2 – Designing for Online Visibility
- Stage 3 – Designing for Your Audience
- Stage 4 – Site Redesign
- Conclusion
Stage 1 – Style Over Substance
The first stage is to design a site that the CEO, venture capitalists, and ad agencies like to see. There are all types of “bells and whistles” in this design. An entire site might be a Flash site. Or there might be some beautiful JavaScript mouseover effects or drop-down menus in the design. It’s always a pretty design, but the message is clear — style over substance.
Stage 2 – Designing for Online Visibility
In Stage 2, the reality of an ineffective web design begins to hit, usually around 3-6 months after the initial launch. A site will typically get rejected by many of the major directories, not be indexed by the major search engines, or not get the traffic or sales that were projected based on the various types of marketing strategies used. Typically, that’s when companies decide that they will try to hire a professional online marketer to promote the site. Doorway page companies, in some way, shape or form, rear their ugly heads.
Unfortunately, many web site owners fall for a doorway page company’s pitch because the beautifully designed site couldn’t possibly be the problem with low site traffic. Yahoo might have rejected a site, or the site might have been listed in Yahoo and the company cannot understand why they have no description next to their company name. But in no way would many ad agencies or doorway page companies want to tell potential clients the truth — they simply did not design and write an effective web site — because it would mean losing thousands of dollars in business.
Stage 3 – Designing for Your Audience
By Stage 3, after spending an exorbitant amount of money on pretty web site designs and various marketing strategies, web site owners generally figure out that they did not design or write an effective Web site for their target audience.
Typically, web site owners will bring in a usability expert to analyze potential problems and present various solutions. Bringing in a search engine marketing expert to help with search-engine friendly design templates early in the design phase can save a company thousands of dollars in online marketing costs.
Stage 4 – Site Redesign
After careful usability and search engine visibility analyses, web site owners finally have an effective web site. A site that is written, coded and designed for user friendliness and search engine visibility generally gets the most traffic and resulting sales because it was written, programmed, and designed for end users.
Conclusion
Web sites should always be designed with your target audience in mind, not your own personal preferences. Colors have meaning. Professional designers understand the psychology of color and the use of white space to best project the image your audience wishes to see. (For example, try not to use the color red on a financial site.)
Understanding the products/services/information your target audience is searching for is paramount to designing and maintaining an effective web site. When you launch a site, you might have to make an educated guess as to what your target audience wants. After that, tools such as site statistics software and reporting from site searches tell you exactly what your visitors are looking for. Then content and marketing strategies can be adjusted accordingly.
Unless the advanced technology clearly benefits end users, do not use it on your site. If your venture capitalists or CEOs or lawyers like the site, ask if they are going to spend the thousands or millions of dollars to keep you in business. They’re not.
Your target audience who will ultimately determine the success or failure of your site.
If you have any specific questions about our web site design tips, or if you would like permission to republish this design tip on your web site or newsletter, please use our contact form or email us at suppor@branding-studio.com
What is specification? How it’s look like?
October 11th, 2008 by adminDeveloping a site specification
The site specification is the planning team’s concise statement of core goals, values, and intent, to provide the ultimate policy direction for everything that comes next. Designing a substantial Web site is a costly and time-consuming process. When you’re up to your neck in the daily challenges of building the site, it can be surprisingly easy to forget why you are doing what you are, to lose sight of your original priorities, and to not know on any given day whether the detailed decisions you are making actually support those overall goals and objectives. A well-written site specification is a powerful daily tool for judging the effectiveness of a development effort. It provides the team with a compass to keep the development process focused on the ultimate purposes of the site. As such, it quickly becomes a daily reference point to settle disputes, to judge the potential utility of new ideas as they arise, to measure progress, and to keep the development team focused on the ultimate goals.
At minimum, a good site specification should define the content scope, budget, schedule, and technical aspects of the Web site. The best site specifications are very short and to the point, and are often just outlines or bullet lists of the major design or technical features planned. The finished site specification should contain the goals statement from the planning phase, as well as the structural details of the site.
Goals and strategies
- What is the mission of your organization?
- How will creating a Web site support your mission?
- What are your two or three most important goals for the site?
- Who is the primary audience for the Web site?
- What do you want the audience to think or do after having visited your site?
- What Web-related strategies will you use to achieve those goals?
- How will you measure the success of your site?
- How will you adequately maintain the finished site?
Production issues
- How many pages will the site contain? What is the maximum acceptable count under this budget?
- What special technical or functional requirements are needed?
- What is the budget for the site?
- What is the production schedule for the site, including intermediate milestones and dates?
- Who are the people or vendors on the development team and what are their responsibilities?
These are big questions, and the broad conceptual issues are too often dismissed as committees push toward starting the “real work” of designing and building a Web site. However, if you cannot confidently answer all of these questions, then no amount of design or production effort can guarantee a useful result.
Avoiding “scope creep”
The site specification defines the scope of your project — that is, what and how much you need to do, the budget, and the development schedule. “Scope creep” is the most prevalent cause of Web project failures. In badly planned projects, scope creep is the gradual but inexorable process by which previously unplanned “features” are added, content and features are padded to mollify each stakeholder group, major changes in content or site structure during site construction are made, and more content or interactive functionality than you originally agreed to create is stuffed in. No single overcommitment is fatal, but the slow, steady accumulation of additions and changes is often enough to blow budgets, ruin schedules, and bury what might have been an elegant original plan under megabytes of muddle and confusion.
Don’t leap into building a Web site before you understand what you want to accomplish and before you have developed a solid and realistic site specification for creating your Web site. The more carefully you plan, the better off you will be when you begin to build your site.
One excellent way to keep a tight rein on the overall scope of the site content is to specify a maximum page count in the site specification. Although a page count is hardly infallible as a guide (after all, Web pages can be arbitrarily long), it serves as a constant reminder to everyone involved of the project’s intended scope. If the page count goes up, make it a rule to revisit the budget implications automatically — the cold realities of budgets and schedules will often cool the enthusiasm to stuff in “just one more page.” A good way to keep a lid on scope creep is to treat the page count as a “zero sum game.” If someone wants to add pages, it’s up to them to nominate other pages to remove or to obtain a corresponding increase in the budget and schedule to account for the increased work involved.
Changes and refinements can be a good thing, as long as everyone is realistic about the impact of potential changes on the budget and schedule of a project. Any substantial change to the planned content, design, or technical aspects of a site must be tightly coupled with a revision of the budget and schedule of the project. People are often reluctant to discuss budgets or deadlines frankly and will often agree to substantial changes or additions to a development plan rather than face an awkward conversation with a client or fellow team member. But this acquiescence merely postpones the inevitable damage of not dealing with scope changes rationally.
The firm integration of schedule, budget, and scope is the only way to keep a Web project from becoming unhinged from the real constraints of time, money, and the ultimate quality of the result. A little bravery and honesty up front can save you much grief later. Make the plan carefully, and then stick to it.
