If you're new here, you may want to subscribe to my RSS feed. So that you can read the latest updates about Web2.0 tools, Making Money Online, Tips in SEO, Ajax and many more. Thanks for visiting ProgramimiCOM!

Users love search for two reasons:

• Search lets users control their own destiny and assert independence from websites’ attempt to direct how they use the Web. Testing situations routinely validate this. A typical comment is: “I don’t want to have to navigate this site the way they want me to. I just want to find the thing I’m looking for.” This is why many users go straight to the home page search function.
• Search is also users’ escape hatch when they are stuck in navigation. When they can’t find a reasonable place to go next, they often turn to the site’s search function. This is why you should make search available from every page on the site; you cannot predict where users will be when they decide they are lost.

Search is a big deal: the usability of the search on intranets we have tested accounted for 43% of the difference in employee productivity between intranets with high and low usability.

Search Should be a Box

Users often move fast and furiously when they’re looking for search. As we’ve seen in recent studies, they typically scan the home page looking for “the little box where I can type.” We’ve long known that users scan, and the implications are clear:

• On home pages, search should be a type-in field and not a link.
• The search input field should be wide enough to contain the typical query; if the box is too small, the query will scroll and diminish usability.

When I changed the useit.com home page to include a search box instead of a link, search engine use increased by 91%. Small change, big effect (as is often the outcome when implementing usability guidelines). (Interior pages may use a search link if they have a very simple design; complex interior pages should use a search box.)

Query Reformulation: Not

Given that search is becoming old hat on the Internet, you might think users would develop advanced search skills. Not so. Typical users are very poor at query reformulation: If they don’t get good results on the first try, later search attempts rarely succeed. In fact, they often give up. We recently studied a large group of people as they shopped on various e-commerce sites. Their search success rate was:

In other words, if users don’t find the result with their first query, they are progressively less and less likely to succeed with additional searches. Many users don’t even bother: In our study, almost half the users whose first search failed gave up immediately.

There is no question that we need to develop methods to help users hone their searches. Probably the only long-term solution is for the school systems to teach kids strategies for query reformulation. In the short term, search interfaces could show users easy ways to extend queries.

Realistically, though, search design should assume that most users won’t be willing or able to refine their queries. Given this, the emphasis should be on increasing users’ success on the first attempt.

Another reason to emphasize early success is that users typically make very quick judgments about a website’s value based on the quality of one or two sets of search results. If the list looks like junk, they may abandon the site completely. At a minimum, they’ll forgo the site’s search in favor of external search engines like Google.

Advanced Search: Not

In our recent search study, the mean query length was 2.0 words. Other studies also show a preponderance of simple searches. Most users cannot use advanced search or Boolean query syntax. This has two implications for search design:

• Emphasize your search engine’s ability to handle single-word queries and very short multi-word queries and still produce high-quality results.
• Do not offer advanced search from the home page. Advanced search leads users into trouble, as they invariably use it wrong. When it makes sense, offer advanced search as an option users can link to from the search results page: “Didn’t find what you were looking for? Try advanced search.”

Scoped Search: Maybe

Scoped search lets users limit the search to results from specific areas of the site (the search scope). In general, this is dangerous. Users often overlook the scope, or they think they are in a different site area than the one they are actually searching.However, as websites continue to grow and offer multiple services in a single site, my attitude toward scoped search is changing. I now believe scoping can be sufficiently useful if you offer it in areas of the site that are both clearly delimitated and address specific problems.

If you choose to use scoped search, I recommend following a few basic rules:

• Set the default search scope to “all” (search the entire site).
• When the user chooses a narrow search scope, explicitly state the scope at the top of the results page.
• Offer one-click access to enlarge the scope. It is especially important to give users a highly visible way of searching the entire site if their scoped search fails to return any results.
• If a search returns too many results, give users suggestions for limiting the scope.

First Results Page is Golden

Users almost never look beyond the second page of search results. It is thus essential that your search prioritize results in a useful way and that all the most important hits appear on the first page.Also, look through the most common queries in your search engine logs and determine the optimal landing page for each common query. You can then manually tweak the search engine to show these pages as the #1 hit.

• 0 Comments

The Internet enriches many seniors’ lives, but most websites violate usability guidelines, making the sites difficult for seniors to use. Current websites are twice as hard to use for seniors than for non-seniors.Seniors are one of the fastest growing demographics on the Web. The United States alone has an estimated 9 million Internet users over the age of 65 as of September 2004. Indeed, all industrialized countries have huge populations of senior citizens, many of whom have substantial assets. Although they are typically retired, seniors lead very active lives and often have great interest in modern technologies such as the Internet, which gives them another method to communicate and stay informed.

In our study, email was the main Internet application used by seniors. Our participants used the Web mainly for:

• Research
• News
• Tracking investments
• Researching medication and medical conditions
• And, to a lesser extent, to shop and bank online

Indeed, our study participants used the Web to read about and research a wide variety of hobbies and special interests, ranging from genealogy to cooking, war strategy, and musical instruments. Taken together, reading about such hobbies constituted a major use of the Web: The diversity of specialized sites is just as much a killer app for seniors as it is for other users.

Research with Seniors Using Websites

To learn how seniors use the Web, we conducted three series of usability tests:

• A measurement study, using three websites and a Web-wide task, with 20 seniors and a control group of 20 users between the ages of 21 and 55.
• A qualitative study with 20 U.S. seniors using 10 U.S. sites.
• A qualitative study with four seniors in Japan using four Japanese sites (to assess the international applicability of our findings).

We define “seniors” as people over the age of 65. Most of our test users were in their 70s, but we also included some people who were 80 years or older, and several people between 65 and 69.

Usability Metrics Twice as High for Non-Seniors

In the quantitative study, we asked users in both groups to perform the same four tasks:

• Fact-finding
• Buying an item
• Retrieving information
• Comparing and contrasting

The following table shows the measurements of four usability attributes averaged across the four tasks.

The differences between seniors and the control group are all highly significant.

Normalizing the usability metrics so that the seniors’ scores are the baseline value of 100% in all cases leads to an estimated overall usability of 222% for non-seniors. (Averaging computed as the geometric mean.) In other words, overall usability was slightly more than twice as good for non-seniors as it was for seniors.

Why Usability is Lower for Seniors

Websites tend to be produced by young designers, who often assume that all users have perfect vision and motor control, and know everything about the Web. These assumptions rarely hold, even when the users are not seniors. However, as indicated by our usability metrics, seniors are hurt more by usability problems than younger users. Among the obvious physical attributes often affected by the human aging process are eyesight, precision of movement, and memory. Also, many seniors retired without having used computers and the Internet extensively during their working careers. Thus, they have not necessarily learned good conceptual models of how these technologies work, which makes it more difficult to understand their quirks. For example, we observed several users who did not differentiate clearly between a website’s search box and the browser’s URL box. After all, both are input fields that you type in when you want to go elsewhere. The lack of experience with good conceptual models is obviously not fundamental to human biology, and may disappear as the current workforce retires.

Our testing identified many instances of poor design that compounded to make the Web more than twice as hard for seniors to use. Complying with the guidelines for designing for seniors would remove many such usability problems. And, while Web usability might still be slightly better for younger users, the differences could be reduced drastically.

Readability and Clickability

The most widely known principle for supporting seniors’ computer use is to support larger font sizes than those younger users prefer. The principle may be well known, and it was indeed confirmed by our study, but still, it is frequently violated by sites that freeze text at a tiny font size. Sites that target seniors should use at least 12-point type as the default. And all sites, whether or not they specifically target seniors, should let users increase text size as desired — especially if the site opts for a smaller default font size.

For hypertext links, large text is especially important for two main reasons: 1) to ensure readability of these essential design components, and 2) to make them more prominent targets for clicking. You should also avoid tightly clustered links that are not separated by white space. Doing so will decrease erroneous clicks and increase the speed at which users hit the correct link. This rule also applies to command buttons and other interaction objects, all of which need to be reasonably large to be easy to click.

Pull-down menus, hierarchically walking menus, and other moving interface elements cause problems for seniors who are not always steady with the mouse. Better to use static user interface widgets and designs that do not require pixel-perfect pointing.

Supportive and Forgiving Design

When websites violate the guideline to use different colors to clearly distinguish between visited and unvisited links, seniors easily lose track of where they have been. We’ve certainly seen the same problem among all age groups: It’s confusing when websites change the standard link colors, and it’s particularly confusing when the same color is used for all links, whether or not you have visited the destination page. However, seniors have a harder time remembering which parts of a website they have visited before, so they are more likely to waste time repeatedly returning to the same place. Seniors also have a harder time using unforgiving search engines and forms. We saw users thwarted because they typed hyphens in their search queries, and punished because they used hyphens or parentheses in a telephone or credit card number.

Error messages were often hard to read, either because the wording was obscure or imprecise, or the message’s placement on the page was easily overlooked among a profusion of other design elements. Simplicity is even more important than usual when seniors encounter error handling: Your message should focus on the error, explain it clearly, and make it as easy as possible to fix. Also, as much as possible, website tasks should adapt to seniors and their preferred way of doing things. After decades of writing telephone numbers in a certain way, it’s not a very nice experience to come across a form that insists on a different format.

Usability Increases Satisfaction

Seniors strongly prefer those websites that are easiest for them to use. The correlation between the success score for our test tasks and users’ subsequent subjective rating of the sites was very strong: r = 0.78, which is higher than we have found in most other studies, though not as high as the 0.95 we found in our equivalent study of users with disabilities. Usability for seniors is important, and not just so that they can perform a task aimed at a one-time purchase. By focusing on improving usability for seniors, you can increase their satisfaction and the odds of forming a long-term relationship.

Intranets should also cater to seniors. Most companies have employees in their 60s, and many big companies have special extranets for retirees that provide online benefits information and help the company maintain contact with former employees.

Besides the business reasoning, we all have a very personal interest in increasing usability for seniors: It’s the one user category we’re all likely to join one day.

When it works for them, the Internet is already an enriching part of many seniors’ lives. Websites can become much more approachable, however, by following the simple design guidelines in our new report. If you consider these guidelines from the start, implementing them will rarely add to the cost of a Web design or intranet project. Also, many of the guidelines for increasing usability for seniors help other users as well.

• 1 Comment

AJAX-style Within-Page Refreshs

Ole Begemann writes:

While I agree with your assessment, I wonder how AJAX fits into this. AJAX is all about interactivity within the same page. Do you think this does more harm than good because of the confusion it causes (and e.g. the Back button does not work as expected anymore)? Or should AJAX actions be invoked by buttons rather than links?

Jakob’s answer:
Interactivity (i.e., features) and navigation are different. So it should be OK to have things happen within the same page as long as they are not seen by users as representing a movement to a new location. See this screenshot for an example:

Screenshot of the price of a stock over three months from Yahoo! Finance.

This is a stock chart showing the price of Amazon.com’s stock over three months. Click the link marked “1y” to get the price over a year instead. It so happens that the implementation is a link to a new page, instead of a within-page refresh-in-place, but there’s no reason for that, except for the benefit I get from being able to easily copy the URL and link to it in the caption. Anyway, if Yahoo had used a button instead of a link to change the view of that chart, it should have worked well as a within-page refresh.Most likely it should be a guideline to use a different UI widget than a plain-text link for this purpose. For sure, we know that it’s a guideline to use buttons for commands and links for navigation, and changing the view of a chart seems more like a command than it seems like navigation. An alternative, in the example in the screenshot, would be to use tabs to alternate between the views. This would certainly comply with the standard use of tabs in applications, even though there would be a conflict with the way tabs have often been abused on websites (which often use tabs to denote navigation instead of alternate views).

For switching between alternate views of the same data, it’s actually better if the Back button doesn’t work, because it would mainly be used when the user wanted to return to the previous location (say, the list of stocks they’re tracking), not if they want to see the previous data view again.

The operative question is whether the user’s action feels more like a manipulation of the same data or a movement to some new data. If the former, then it’s a command. If the latter, it’s navigation. To really find out, you need to observe users and perform a task analysis, but often you can come up with a good first guess and use for your initial design before it goes to testing.

“Return to Top” Links

Vincent Simard writes:

Should “Return to top” links be avoided? They seem accepted by a lot of developers and users although I have not tested them vs. users scrolling back to the top of a page manually.

Jakob’s answer:
Yes, “return to top” can be avoided, because the exact same functionality is provided by simply dragging the scrollbar to the top of the page. It’s almost always better to rely on a single, generic interaction technique so that users don’t have to ponder the choice between two alternate interaction techniques for the same goal. The time it takes to make the decision is usually more than the time saved by the shortcut. (The exception would be for extremely long pages that would take forever to scroll, but such pages should be avoided in the first place.)

Horizontal Scrolling

J. D. A. Wiseman writes: Internal links are not only for long lists: also wide maps that cannot be less wide.

Jakob’s answer:
Of course, in general, there’s a guideline to avoid horizontal scrolling, but a wide map would be one of the exceptions. For a low-tech solution, within-page links may be an acceptable way to jump to a specific part of this type of map. A more fancy solution would be to have a special map controller, but that would be overkill for a simple site like yours.

Skip Links for Users With Disabilities

Mike Elledge writes:

I would suggest another situation where skip links are both a benefit and meet user expectations: When used to skip navigation (or, alternatively, go to content) for persons using adaptive technology.

This is commonly recommended by persons within the accessibility community to enable AT users to avoid unnecessary tabbing, reducing fatigue and repetition. Screen readers, such as JAWS, identify such links as “in-page” so that users are further informed.

Jakob’s answer:
This is a good point, and may be one of the few cases where the user experience is better for users with disabilities than for non-disabled users. In general, our testing has found that blind and low-vision users suffer three times as bad usability problems as sighted users, so it’s only fair that they get one thing in their favor. When you use a browser that gives special (and appropriate) treatment to within-page links, then they can certainly be helpful. The most common use of “skip links” is a link on the top of the page that moves users directly to the content area of the page, thus bypassing the extensive amount of crud in the form of navigation bars and other utility information. Sighted readers almost always skip this information initially, simply by looking in the content area first. Non-sighted users sometimes (but not always) like to start with the content as well, and skip-links is one way to give them this choice.

A skip-link is usually made invisible to sighted users, and thus it won’t bother people with traditional, visual browsers.

In the long run, I believe that a better solution would be to have a semantic encoding that would denote different parts of a page as content vs. navigation and include a dedicated command in screen reader software for switching between the two. These two different areas of a page need to be accessed in different task modes, and it’s almost as common to need to move from content to navigation as the other way around.

Some specialists in technical accessibility (which is a different discipline than usability for users with disabilities) suggest an alternative: place the content first and the navigation second in the file and then use CSS to reverse this order for sighted users. This is not a good idea:

• Many low-vision users alternate between visual and auditory modes of access, so they would be hurt by an inconsistent placement of the two types of information across their two browsers.
• As just stated, users also need a way of skipping from the content to the navigation, and if the navigation options are at the end of the page, you will sometimes force people to wade through masses of content that they don’t want, just so that they can get to the links to other pages.
• Blind users form mental models of websites, just as sighted users do. Blind users obey Jakob’s Law, just as sighted users do (”users spend most of their time on other sites”) Therefore, blind users have strong expectations for the structure of a website when they first arrive, and these expectations include the convention that the navigation comes first. Swapping the order of navigation and content will confuse many blind users.

• 0 Comments

I thought I’d share a little bit of what I’ve learned from noodling around with stylesheets these past few years. Here are some basic organizational practices I try to follow. ( Much of this might be old hat for you, and if so, just think of it as a refresher. I run into enough messy stylesheets that I thought this might be of some interest. )

Grouping Your Styles

Group your styles into categories (ex. layout, typography, forms, so on) and visually seperate them in your css file. A title and table of contents doesn’t hurt either:

/*
	HuddleTogether.com Screen Styles

	Table of Contents:
		layout
		typography
		forms
*/

/* layout
----------------------------------------------- */

/* typography
----------------------------------------------- */

/* forms
----------------------------------------------- */

Choosing Your Categories

Even though I do have some common practices, I don’t have a ‘template’ for how to breakdown styles into categories.

For starters, I almost always have layout and typography categories. With typography defining the sitewide look and feel. Depending on the complexity, I may break out the table and form styles into their own categories.

Next, I address the physical sections of the page with their own categories: header, sidebar, content, and footer for example. Lastly, I collect the page and content section specific styles and place them in their own category (and sometimes subcategories).

Importing Stylesheets

Another method is to categorize the styles and place them in seperate CSS files which are all imported by one main CSS file. I find this method good in theory but it can lead to overlapping styles, specification issues, and general confusion if you’re not very careful:

@import url("layout.css");
@import url("typography.css");
@import url("forms.css");

Linebreaks and Indenting

When styling multiple tags, ids, or classes with common attributes, display each on its own line. Also, indent closing braces. Both these actions keep the left column clean so you can quickly skim your stylesheet:

h2,
h3,
h4 {
	font-weight: bold;
	padding-bottom: 1.5em;
	}
h5 {
	font-weight: normal;
	font-size: 1.5em;
	padding-bottom: 0;
	}

Descendant Selectors

Use descendant selectors generously and consistently to keep your styles grouped neatly and CSS specificity in check:

#header {}
#header .logo {}
#header .logo img {}

Quick Disable

A trick I use all the time to temporarily disable a style attribute involves simply adding an ‘x’ in front of the attribute name. It’s safer then cutting and quicker then commenting out:

#footer{
	border-top: 1px solid #e5e5e5;
	xborder-bottom: 1px solid #e5e5e5;
	}

Keeping Track of Divs

Quick HTML pointer. For div tags that stay open for a number of lines, add a small comment after the closing tag about the opening div’s id or class:

<div id="content">
	<h2></h2>
	<p></p>
	<p></p>
	<p></p>
	<p></p>
</div><!-- end #content-->

• 0 Comments

A few weeks back in Cupertino, I saw Aaron explain how the specificity of CSS selectors is calculated in a way which I hadn’t seen before. Then today I came across a knotty problem while building XHTML and CSS templates for a new project where two selectors behaved differently to how I expected and I realised that I had not completed my training.

The Dark Side

My problem was a simple one, how to feed a transparent PNG image to browsers which support transparency and a GIF image to older browsers which don’t, without resorting to hacks. Here’s the markup,

<div id="nav-supp">
<p><a id=”a-02″ href=”#webstandards-org”>Top</a></p>
<!– etc. –>
</div>

and my CSS starting point.

a#a-02 { background-image : url(n.gif); }
a[id="a-02"] { background-image : url(n.png); }

I had assumed that a modern browser would see and apply both rules (with the second overriding the first) and that an older browser which does not understand attribute selectors would see and apply only the first, ignoring the second. I was wrong. Modern browsers did not apply the PNG image as I expected. The reason? A standard id selector wins over an attribute selector in terms of the cascade. Dagnammit! I know I should have read the specs, but somehow that particular pleasure had escaped me. If I had, I might have learned that;

ID selectors have a higher specificity than attribute selectors. For example, in HTML, the selector #p123 is more specific than [id=p123] in terms of the cascade.

Sith Lords

A little Googling uncovered some rather dry reading on the subject of selector specificity (resources below).

First, let’s look back at the subject of specificity (with one or two minor changes to fit our nefarious purpose).

You give every id selector (”#whatever”) a value of 100, every class selector (”.whatever”) a value of 10 and every HTML selector (”whatever”) a value of 1. Then you add them all up and hey presto, you have the specificity value.

• p has a specificity of 1 (1 HTML selector)
• div p has a specificity of 2 (2 HTML selectors; 1+1)
• .sith has a specificity of 10 (1 class selector)
• div p.sith has a specificity of 12 (2 HTML selectors and a class selector; 1+1+10)
• #sith has a specificity of 100 (1 id selector)
• body #darkside .sith p has a specificity of 112 (HTML selector, id selector, class selector, HTML selector; 1+100+10+1)

If all of these examples were used, div p.sith (with a specificity of 12) would win out over div p (with a specificity of 2) and body #darkside .sith p would win out over all of them, regardless of the order.

Darth (Gez) Lemon quotes the W3C.

A selector’s specificity is calculated as follows:

• count the number of ID attributes in the selector (= a)
• count the number of other attributes and pseudo-classes in the selector (= b)
• count the number of element names in the selector (= c)
• ignore pseudo-elements.

Concatenating the three numbers a-b-c (in a number system with a large base) gives the specificity.

Too much! For me, the W3C really is in a galaxy far, far away!

Is it possible to learn these powers?

Math was never my strong point, so to help me understand calculating specificity better I made a chart based on the following specificity (or Sith power) values (Ed says: Ignoring inline styles and !important).

element selector                class selector                          id selector

Sith power (specificity):  Sith power (specificity):     Sith power (specificity):

0,0,1 (1)                             0,1,0 (10)                             1,0,0  (100)

Each character (selector) is given its own Sith power (specificity value) depending on how powerful they are in the ways of the Dark Side. A storm trooper is less powerful than Vader who is in turn less powerful than the Emperor.

Do not underestimate the power of the Dark Side

Amazingly, Star Wars helped me understand CSS better. Join me, and together we can rule the galaxy as father and geeks!

Any thoughts? (Ed says: Cue Star Wars quotes ;))

• 1 Comment

If you have two (or more) conflicting CSS rules that point to the same element, there are some basic rules that a browser follows to determine which one is most specific and therefore wins out.It may not seem like something that important, and in most cases you won’t come across any conflicts at all, but the larger and more complex your CSS files become, or the more CSS files you start to juggle with, the greater likelihood there is of conflicts turning up.

If the selectors are the same then the latest one will always take precedence. For example, if you had:

p { color: red; }
p { color: blue; }

p elements would be coloured blue because that rule came last.

However, you won’t usually have identical selectors with conflicting declarations on purpose (because there’s not much point). Conflicts quite legitimately come up, however, when you have nested selectors. In the following example:

div p { color: red; }
p { color: blue; }

It might seem that  p elements within a div element would be coloured blue, seeing as a rule to colour p elements blue comes last, but they would actually be coloured red due to the specificity of the first selector. Basically, the more specific a selector, the more preference it will be given when it comes to conflicting styles.The actual specificity of a group of nested selectors takes some calculating. Basically, you give every id selector (”#whatever”) a value of 100, every class selector (”.whatever”) a value of 10 and every HTML selector (”whatever”) a value of 1. Then you add them all up and hey presto, you have the specificity value.

• p has a specificity of 1 (1 HTML selector)
• div p has a specificity of 2 (2 HTML selectors; 1+1)
• .tree has a specificity of 10 (1 class selector)
• div p.tree has a specificity of 12 (2 HTML selectors and a class selector; 1+1+10)
• #baobab has a specificity of 100 (1 id selector)
• body #content .alternative p has a specificity of 112 (HTML selector, id selector, class selector, HTML selector; 1+100+10+1)

So if all of these examples were used, div p.tree (with a specificity of 12) would win out over div p (with a specificity of 2) and body #content .alternative p would win out over all of them, regardless of the order.

• 1 Comment

Probably the most misused thing in CSS are classes and IDs. People just don’t know when to use which.

An ID is a unique identifier. Say if I want my navigation menu to have the ID nav, no other element will have the nav id. A class is, in my words, a definition for how something looks. Say you want everything in multiple IDs to have green text, well you wouldn’t assign all those elements the same ID, you would assign them the same class.

In a nutshell, ID = unique, class = multiple, formatting.

• 0 Comments

MySQL is a popular SQL database platform. It’s commonly installed on servers and is a core PHP extension.

Software such as Invision Power Board, phpBB, vBulletin, and WordPress require MySQL (with support for other database platforms) in order to function. For the novice user, setting up the database and then entering that information in a config file may be a little confusing. I’m going to be using cPanel to set up the database, other control panel software may be different.

First we have to log into cPanel, then click the MySQL icon.

Now, you will see a page with any MySQL databases you already have, then 4 forms, only 3 of which we’re going to worry about. First, we need to create our database, this is the field right under the ‘Add User to DB’ button. If we’re installing WordPress, we might want a database named wordpress, we’ll enter that in the box and press OK.

Now that we have our database, we need to create a user. This form is right below the add database one. The username we enter will be prefixed with your_cP_username_dbusername. Also, the length of usernames are limited, so although I’m entering wordpress, it will only be wordpres. This means my username would be mck9235_wordpres. Enter a password you will remember. Look at the image if you’re still confused.

Last, we need to add our user to the database and give it the proper permissions. This is the first form. All you need to do is find your user and database from the dropdowns and then click add.

Now, when you go to the main MySQL page, you will see something like:

At last we have our database set up, but we still need to be able to enter the details. A sample config file might look like this:

<?php
$host = ‘localhost’;
$user = ”;
$db = ”;
$pass = ”;
?>

Now, the host will be localhost 99% of the time, so you don’t need to mess with that. We know our username is mck9235_wordpres, db is mck9235_wordpress, and the password is whatever you said. All you need to do is fill those values in, then you’re ready to go!

• 0 Comments

It sucks to visit your site and find it hacked or maybe a extremely rare, but deadly technical glitch happened on the server. This only sucks when you don’t have a backup of your database, but it’s actually very easy to do. We’re going to use cPanel’s database backup tools to make a CRON based backup script that will send us, as an attachment, a backup of our database via E-Mail.

This actually isn’t that hard to do, the hardest part was figuring out how to send attachments with PHP’s mail() function. Thankfully, I found an excellent tutorial on it.

First of all, never store CRON files in your public_html directory, otherwise the whole world can access it. Store the file in the directory above it, e.g. /home/username/backup.php instead of /home/username/public_html/backup.php. Now we can move on to the script. Right after the opening PHP tag, we must tell the server to ignore all headers (thanks, Tim!):

<?php
#!/usr/local/bin/php -q
Just to keep things organized, we’re going to create two functions, one to get the database backup, and the other to send. However, we’ll only be calling one function, as it will call the function to get the database backup. There’s going to be a lot of headers, which I really can’t explain, but I can assure you that they tell the E-mail client there’s going to be both a message and an attachment.

function get_database_file($database_name, $domain, $username, $password)
{
//Construct the URL out of all our little pieces
$url = ‘http://’ . $username . ‘:’ . $password .‘@’. $domain .‘/getsqlbackup/’. $database_name .‘.gz’;
//Return the file’s contents
return(file_get_contents($url));
}function send_database_file($to, $from, $subject, $message)
{
global $database_name, $domain, $username, $password;
//Thanks to http://www.theukwebdesigncompany.com/articles/php-file-attachments.php for making this easy
$unique_sep = md5(uniqid(time()));
//Tell our E-mail client that we’re sending both a message, and an attachment
$headers .= “From: $from\n“.
“MIME-Version: 1.0\nContent-Type: multipart/mixed;boundary=\”$unique_sep\”;\n“.
“charset=\”iso-8859-1\”\nContent-Transfer-Encoding: 7bit\n\n“ .
“–$unique_sep\n“.
“Content-Type: text/plain; charset=\”iso-8859-1\”\n“.
“Content-Transfer-Encoding: 7bit\n\n“.
$message.“\n\n“.
“–$unique_sep\n“.
“Content-Type: gz; name=\”wp.gz\”\n“.
“Content-Transfer-Encoding: base64\n“.
“Content-Disposition: attachment\n\n“;
//Get the file from our function
$file = get_database_file($database_name, $domain, $username, $password);
//This is where the file is actually attached
$headers .= chunk_split(base64_encode($file)) . “–$unique_sep–\n“;
//Finally we can mail
if(mail($to, $subject, $message, $headers))
{
return true;
}
else
{
return false;
}
}

We’ve still got to declare some variables for our database, URLs, and user details. Last, but certainly not least, we’re going to send the backup!

//If your database is user_wp, ONLY PUT wp!
$database_name = “wp”;
//Include :2082, it’s cPanel’s port
//No www or http
$domain = “site.com:2082″;
//cPanel username and password
$username = “username”;
$password = “random_password”;
//Who to send the backup to
$email = “backups@programimi.com”;
//Appears in the from field
$from = “server@programimi.com”;//Send it off with the data in the E-mail message.
send_database_file($email, $from, $database_name .” Database Backup”, “The backup of “. $database_name .” was performed at “. date(“g:i A F j, Y”));
?>

Save the above (compiled into one) file as whatever you like, and remember, not in the public_html directory, the one above it! We still need to set up the CRON, hop into cPanel and click the CRON Jobs icon.

Now click the standard button. I’ve made a little image that should get you through the next step:

Your database backup should arrive on whatver day, hour, and minute you told the server to run it! That’s all there is to it.

• 1 Comment

C++ is an extreme language and the one of the most difficult. C++ like PHP derives from C so C functions can be called when programming in C++. I will tell about the very basics to get started into the C++ programming world.
Below you see the very least for a C++ console program just to run and be empty. I have commented on the main points.

#include //contains basic input and output functions like cerr, clog, cout, and cin and basic operators
#include //contains other basic functions and operators
//more headers are available in Dev-CPP’s include directory. These include math.h (C header) for math functions sin, cos, tan, sqrt, fstream sometimes fstream.h (compiler dependent) that contains functions for reading and writing files in C++ (will explain later), and one that is very useful string.h sometimes string (again compiler dependent) which contains string manipulation functions such as erase and replace.using namespace std;//this means that you want to use the namespace std which contains basic input and output functions otherwise you would have to call functions, operators, etc in a manner of namespace::functionname like std::cout

int main(int argc, char *argv[])//main function in console program where everything goes that needs to be done. This is a custom function and can also be seen as taking no arguments, int main()
{
system(“PAUSE”);//the system function. Whatever you put between the quotes is what you want to be sent to the command line. In this case PAUSE tells the program to wait and let the user see the results
return 0;//return value of 0 because the function is an int
}

Now that the structure of a basic console program has been explained now variables. First, what is a variable? A variable is sort of like a variable in math. Variables hold values and can be outputted. These variables can consist of letters, numbers and some symbols. Variables can not have the same name as another variable in C++. For example the first set of code outputs an error on compilation and the second compiles with no errors. Note: The code takes into consideration that the variables are declared in the main functions in the above template.

int i;
i = 0;
char i;//variable already used and declared as variable type int
i = ‘a’;//variable is type int and cannot hold a character

int i;//perfect
i = 0;//perfect
char a;//perfect
a = ‘a’;//perfect

Now for the variable types. A variable type decides what that variable can hold. A type of int can only hold whole numbers for example -1, 0, 1, etc. A type of char can only hold a single character or symbol (unless character array, or pointer). A type of string can hold letters, numbers, and symbols. A type of float can hold a single precision value (decimal, fraction) accurate to 7 decimal places. A type of double can hold double precision values (decimals, fractions) accurate to 15 decimal places.

I have given enough information to write a very simple program. Good Luck.

• 0 Comments