Getting a Website is Easy

Book Review: The 4-Hour Work Week by Timothy Ferriss

admin — Wed, 21 Oct 2009 10:39:10 +0000

This is a new bit I’d like to do to add to my other posts, a book review of some excellent books that I’ve read and think my readers will benefit from. The first one is titled “The 4-Hour Work Week” by Timothy Ferriss. So here we go.

Published in April 2007 by Random House, The 4-Hour Workweek, made Timothy famous as it hit number one on the New York Times and Wall Street Journal best seller list. This transformed Ferriss, an unknown Princeton graduate, into a sort of celebrity. The success of his book is attributed to his heavy marketing through his blogs, a marketing technique that has since been adopted by many in the trade.

The 4-Hour Workweek has attracted a lot of attention, mainly because of the intriguing title, and has received different kinds of reactions ranging from adulation to scorn. While some considers his ideas too outlandish, others regard them as very practical and timely. Of course, Ferriss wants people to take notice of his book, hence the title, although he does not actually mean to really reduce the workweek to only 4 hours. The main idea of Ferris is to cut down one’s workweek dramatically to give oneself much time for other life’s activities. As he claimed in his book, Ferriss spent more than 50 hours a week working with software and nutritional supplement business. Realizing that he might end up forever in front of his computer, he felt that he has to change his life and the way he works, coming up with the ideas for The 4-Hour Workweek.

Ferriss is a believer and ardent follower of the Pareto Principle, also known as the 80-20 rule, or the principle of factor sparsity, which states that for many events, roughly 80% of the effects come from 20% of the causes. The principle was an offshoot of the idea of Italian economist Vilfredo Pareto who observed at the turn of the 20th century that 80% of the land in Italy was owned by only 20% of the population. In business, it is observed that 80% of the sales come from 20% of the clients. While 80% – 20% sharing is not absolute, many real systems have percentages somewhere around this region in their imbalance of distribution.

Ferriss’ idea is to apply automation to business so that only a minimal time will be required to produce the maximum result. By investing 20% of time/effort, he hopes to get around 80% of the expected results. This could be done by using more efficient practices such as hiring virtual assistants from overseas who can do one’s job for a meager $5 or less per hour. While this idea is just an offshoot of the widespread practice of business outsourcing, Ferriss utilized this to benefit not only large businesses but also small and mid-sized businesses or even start-up businessmen who operate business by themselves. Even an overworked employee can hire overseas assistants to help him do his job and get a lot of free hours for other activities. What Ferriss advocates is actually outsourcing one’s life and to enjoy the freed hours for other activities that are not normally available for someone who is trapped in the 9-5 rat race.

While the idea could sound attractive, especially with the success of business process outsourcing employed by large corporations, it does not sound as feasible as Ferriss wants to put it. You cannot outsource that much function of business and let it run on autopilot as successful business outsourcing will require a close supervision and strict control. Doing otherwise could have the business spiral out of control because the outsourced employees can do only as much as they were told to do, bereft of the necessary leeway and freedom of action to make decision on their own. Not every businessman can be as lucky as Ferriss who took a one year hiatus from his business only to find that he made more money while he was gone. He must have stumbled on some geniuses who ran his business while he was away!

Ferriss’ discussion on information overload and his proposed solutions are also suspect. While it is true that most people are overburden by too much information that they have to digest on a daily basis, we cannot just ignore information that we feel are eating much of our time, leading us to go below our money-earning potential. Ferriss proposed Extreme Selective Ignorance as an answer to the information overload but this is not likely to work with most businesses. Businesses today are global and are grounded on an intricate web of interrelationship where even a minor incident or event in a remote part of the globe could have repercussions on the economy in general and to a certain type of business in particular. Businessmen therefore must be keenly aware of everything that is going on around them to make them prepare to take actions or make adjustments in their business plans as unfolding events may demand. While Ferriss speaks of distractions the internet offers, we have to be reminded that his book The 4-Hour Workweek became a best seller because of the internet, specifically the blogs.

The book is also a step-by-step guide to designing a luxury lifestyle. All an individual needs is to sit down and decide what he wants from life. This is a bold attempt to define life’s philosophy as each person is enjoined to make early decisions and determine a way of finding money necessary to make such decisions work. The assumption is that people can be happy only by working less, traveling more and enjoying a bacchanalian life, while counting all the money he made while his outsourced personnel ran the show. He considers people who enjoy their jobs and the challenges that go with them as rather outmoded.

The success of Ferriss’ book can mainly be attributed to the fact that it caters to what people want to hear, giving hope, with himself as the example, that working less, earning more and living a full and satisfying life is really possible. It gives people ideas on how to cut corners and be successful (whatever it means) right away. The book is rich in time-saving ideas and resources which can be applied in many instances and is therefore worth reading but it falls short in philosophy and over-all message. This is not a good read for people who find enjoyment in the long hours they work, especially those who touch other people’s lives every single minute they spend in the workplace, regardless of the amount of money they receive. This book is not for the healthcare workers who brave the risks of infectious diseases, not for the firefighters who spend days battling forest fires or members of the armed services who stay in the battlefield for months; they have different philosophies in life.

Blue & Yellow Sidebar For Color Scheme Inspiration

admin — Wed, 21 Oct 2009 10:39:10 +0000

While visiting some hosting sites for website design ideas and inspiration, I found this one the had a nice blue and yellow combination with a hint of gray colored backgrounds and pale yellow for the navigation hover effect. These colors work really well together and I think I’ll be using this color scheme for my next project. Notice the glossy effect on the buttons too, looks pretty nice and elegant.

Source: WebHostingGeeks.com

The Structural Approach to Web Design

admin — Wed, 21 Oct 2009 10:39:10 +0000

Photo credit: rudiriet

When designing a website, several factors are taken into consideration. One of the main objectives that designers often are required to satisfy is the usability of the website. It is important to note that if you have specific objectives to promote user friendliness instead of aesthetics that a structure-first approach to designing web sites should be used. A structure first methodology, which can look like an unintuitive way to design web sites for visually oriented designers actually carry several advantages.

Structure-first web design approaches are pedagogical; the designers are required to conceptualize the design as a separate but interrelated step. They are also practical, if you consider the functionality and effectiveness of a site it is measured by the validity of solid HTML code, which requires a separation between structures of the document by using tags and aesthetics by using Cascading Style Sheets.

Taking on a structural perspective in web design ensures that the contents of your web site will maintain readability in cases where the styling rules are disabled in your user’s browser. In situations where the user browses the pages by using a handheld device, like cell phones your visual formatting and assistive technology like screen readers are often ignored. A structural focus leads to the generation of many flexible web pages, which are viewable by users in several ways. These pages are easily reformatted if necessary, and can easily be revised and updated.

Remember that although an aesthetic approach will provide you with more creative freedom; it comes with its own disadvantages. When designing content that needs fast access and is usability centric you must take into consideration that the demographic targeted for the web site’s specific function might not benefit from a visual approach. Projects which require database searches or make use of a web design to post a large quantity of research or analytical data will often need to restrict its visual limitation to providing graphical representation or navigation aids which will help its users find the specific information it is looking for in an accurate and speedy manner.

Taking on a structural approach to web design makes sure that the designer doesn’t fall into the death trap of creating an overly flamboyant page and get lost in his creative impulses. One of your major priorities as a web designer is to ensure the fluidity of your content in any web browsing consideration. If you decided to put a lot of visuals in your programming there is a higher chance that the page will do two things which are not favorable to the user; pages might load slowly and content will not be visible right away depending on their connection speed and several browsing situations will prevent your website from loading properly or from displaying as how you intended for its design.

There are various ways of creating your website, weather you decide to take on a structure-first approach to web design or take a visual approach it is important to consider the type of end users you plan to market your website to, chose whether to prioritize style or function and create informed decisions based on it.

Why We Click? – Another Way of Looking at Web Design

admin — Wed, 21 Oct 2009 10:39:10 +0000

by Giancarlo Gallegos

Have you ever wondered why we choose certain web sites over other web sites? Let us take my case for example. Two days ago, I wanted to check for a USB stick that looks like a camera. I had only one intention, to buy a flash drive looking camera. As I typed it in Google, I had hundreds of listing of USB sticks with a REAL camera attached to it. WOW! How did I fair in my search? Let us say, I ended up wasting 2 hours of my time browsing websites and getting distracted with all the cool stuff I saw especially the retro cassette 4 GB usb flash drive. Did I eventually buy a USB stick? Nope, I totally lost interest when I saw cassette USB stick.

So what makes us chose websites over the others? Disclaimer. I am not a psychologist. However, I have always been fascinated with human behavior. Here is my theory: We are attracted to a site if it evokes certain emotions. I was reading this book on the psychology of web design. The author mentioned an interesting point that most human behavior are governed by the unconscious. The author said, “To get us to click, they have to persuade us. But donʼt make the mistake of thinking that the best way to persuade us is to make a logical presentation”.

We know that all websites have target behaviors. They are either get us to buy, to register, to donate, to read, to follow and to click. But how do they get us to buy, register, donate, read, follow and click? If, we, designers understood how our minds work, we can create effective websites that engages our target market to make that sought after “click”.

In my reading and research of the “psychology of clicking.” Clicking a website is a result of several factors.

We click because we think we are gaining something. When we act or interact we are motivated by gain. Whether it is business gain, increased intelligence or bragging rights, often times we find ourselves checking a website because it means something better for us.

We click because we are curious. Many of us click because we are simply curious about what is in the site, what we will find in the site, if what we heard are true.

We click because we trust. When we decide to click or navigate a website, we make several assessments in a blink of an eye—Will this be a waste of time? Will the site I click to be safe? Will the information I seek be relevant? Will I get what I need efficiently? We need to feel a sense of reliability and trust in what we are doing when we decide to interact. When we do, we are more likely to interact with a sense of purpose.

However, these reasons does not seem to provide an adequate understanding on the science of the click. In my research, I discovered that the human psychology plays a major role in why we chose websites over other sites. Here is what I discovered:

We value what others think. Most people view themselves as independent thinkers. The truth is that the need to fit in and belong are wired in our nature. We want to fit in. We want to be like the crowd. There is a strong drive that when people are in social situations, they look at others to see how to behave. This is especially true when we are uncertain about what action to take. Take the online ratings for example. If we see a product that has only one out of five stars, we do not even take a closer look. However, if the product has around five out of five, we are curious why people rated it like that. This is because online ratings validate that other people opinion are important and if they think it is good then it must be good. In addition, if the online rating provided a personal experience with the product or service, we feel that we are making the right decision in clicking into that product.

Tip: Add reviewer feedback to your website. If you can add names and dates to the feedback it becomes a power tool in making us click.

We click because there is a sense of obligation. What happens if someone gives us a gift? It triggers a feeling of indebtedness. We feel the need to reciprocate that act of giving. Anytime something is given away at a Web site, it creates a feeling of indebtedness and reciprocity. Take antivirus softwares for personal computers. They often provide free download of their software for a 30 day trial period. You run it and test on your computer and it works. It cleans all the viruses out. Out of relief, you now feel obliged to buy the software as it has already proven its use to you and solved your problem.

Tip: Give away free information in your website. For example, if an e-commerce site sells a camera, there could be a portion of the site that features an excellent guide in taking pictures. If users come to the site to read about taking pictures, and they appreciate the information that is provided for free, they might feel as if they have been given a gift. This does not guarantee that they will buy the camera but it does increase the likelihood they keep away from a competitor.

Sponsored Links

We click because we feel that there is less of that product. If something is scarce, it will seem more desirable and more valuable to us. Showing a limited stock or a limited time frame motivates us to act. We treasure exclusivity, rarity, uniqueness and we act quickly when opportunities arise. We are absolutely pushovers when things have a time limit. This work because we perceive a chance to miss the deal if we donʼt act.

Tip: When you design an e-commerce website, try to invoke scarcity. Add the phrase “only left in stock.” You would discover that many people will feel better if they hurry up and purchase that item before they are all gone.

We follow the rule of the first. If you type a query in google search, do you look at the very last page of the search results? No. All of us go to the first page first listing. And if we are interested enough we go to the second page of the results. This is the rule of first. The reason for this is that our mind freezes if we see a lot of options. We may say we prefer a lot of options, but the reality if there are a lot of choices, we canʼt decide.

Tip: Create a website that if we see something we like, we can get it right away. If we cannot promise to give it immediately, let the web user know it will be very soon. In addition, if you have a product or information that you want the web user to use, list it as the first product or information in your website. Chances are it will have a strong pull among your web users.

We are afraid to lose. Remember the old adage, “ A bird in the hand is worth two in the bush.” We are most afraid of losing what we already have. We are reluctant to take away or subtract items. Letʼs take for example the model of a computer you are configuring has the better processor. It is “included in price”. If you want to spend less money, then you chose a lesser processor and subtract money. If we feel that we cannot afford the entire package, we have to face the idea of taking away options — an idea we donʼt necessarily like. Why? Because, if we experience the whole package, we are most likely to be reluctant to take something away.

Tip: In designing a e-commerce website try creating a layout that includes everything you want to sell and add a choice of subtracting rather than adding items. More often than not, the web user will be reluctant to lose what they, in some sense, feel they already have.

In the end, we are but social animals. Many of our decisions stems from the fact that we want to fit in and belong to a community. We will always figure out a way to use whatever technology out there to be able to communicate and be social. Hence, the growth of many social networking sites such as Facebook, LinkedIn, Twitter, MySpace, etc.

Giancarlo Gallegos is a writer, communications designer photographer, entrepreneur, and a post production professional based on New Zealand. He is the official photographer for a little pink pig’s travel blog called The Adventures of Spider Pig. You can view his work on www.giancarlogallegos.com. On his spare time, he travels, cooks, drinks coffee and mind maps new ideas.

Have you ever wondered why we
chose certain web sites over other
web sites? Let us take my case for
example. Two days ago, I wanted to
check for a USB stick that looks like
a camera. I had only one intention,
to buy a flash drive looking camera.
As I typed it in Google, I had
hundreds of listing of USB sticks with
a REAL camera attached to it.
WOW! How did I fair in my search?
Let us say, I ended up wasting 2
hours of my time browsing websites
and getting distracted with all the
cool stuff I saw especially the retro
cassette 4 GB usb flash drive. Did I
eventually buy a USB stick? Nope, I totally lost interest when I saw cassette USB stick.
So what makes us chose websites over the others? Disclaimer. I am not a psychologist.
However, I have always been fascinated with human behavior. Here is my theory: We are
attracted to a site if it evokes certain emotions. I was reading this book on the psychology
of web design. The author mentioned an interesting point that most human behavior are
governed by the unconscious. The author said, “To get us to click, they have to persuade
us. But donʼt make the mistake of thinking that the best way to persuade us is to make a
logical presentation”.
We know that all websites have target behaviors. They are either get us to buy, to register,
to donate, to read, to follow and to click. But how do they get us to buy, register, donate,
read, follow and click? If, we, designers understood how our minds work, we can create
effective websites that engages our target market to make that sought after “click”.
In my reading and research of the “psychology of clicking.” Clicking a website is a result of
several factors.
We click because we think we are gaining something. When we act or interact we are
motivated by gain. Whether it is business gain, increased intelligence or bragging rights,
often times we find ourselves checking a website because it means something better for
us.
We click because we are curious. Many of us click because we are simply curious about
what is in the site, what we will find in the site, if what we heard are true.
We click because we trust. When we decide to click or navigate a website, we make
several assessments in a blink of an eye—Will this be a waste of time? Will the site I click
to be safe? Will the information I seek be relevant? Will I get what I need efficiently? We
need to feel a sense of reliability and trust in what we are doing when we decide to
interact. When we do, we are more likely to interact with a sense of purpose.Have you ever wondered why we
chose certain web sites over other
web sites? Let us take my case for
example. Two days ago, I wanted to
check for a USB stick that looks like
a camera. I had only one intention,
to buy a flash drive looking camera.
As I typed it in Google, I had
hundreds of listing of USB sticks with
a REAL camera attached to it.
WOW! How did I fair in my search?
Let us say, I ended up wasting 2
hours of my time browsing websites
and getting distracted with all the
cool stuff I saw especially the retro
cassette 4 GB usb flash drive. Did I
eventually buy a USB stick? Nope, I totally lost interest when I saw cassette USB stick.
So what makes us chose websites over the others? Disclaimer. I am not a psychologist.
However, I have always been fascinated with human behavior. Here is my theory: We are
attracted to a site if it evokes certain emotions. I was reading this book on the psychology
of web design. The author mentioned an interesting point that most human behavior are
governed by the unconscious. The author said, “To get us to click, they have to persuade
us. But donʼt make the mistake of thinking that the best way to persuade us is to make a
logical presentation”.
We know that all websites have target behaviors. They are either get us to buy, to register,
to donate, to read, to follow and to click. But how do they get us to buy, register, donate,
read, follow and click? If, we, designers understood how our minds work, we can create
effective websites that engages our target market to make that sought after “click”.
In my reading and research of the “psychology of clicking.” Clicking a website is a result of
several factors.
We click because we think we are gaining something. When we act or interact we are
motivated by gain. Whether it is business gain, increased intelligence or bragging rights,
often times we find ourselves checking a website because it means something better for
us.
We click because we are curious. Many of us click because we are simply curious about
what is in the site, what we will find in the site, if what we heard are true.
We click because we trust. When we decide to click or navigate a website, we make
several assessments in a blink of an eye—Will this be a waste of time? Will the site I click
to be safe? Will the information I seek be relevant? Will I get what I need efficiently? We
need to feel a sense of reliability and trust in what we are doing when we decide to
interact. When we do, we are more likely to interact with a sense of purpose.

Three Awesome Web Design Lists For Inspiration

admin — Wed, 21 Oct 2009 10:39:10 +0000

Fresh, just from the oven, three awesome, creative inspiring lists to get your creative juices flowing.

Beautiful Examples of Inset Typography in Web Design

48 Creative Websites Designed in Blue

50 Amazing Flash Website Designs

Writing web applications with CodeIgniter – Part 2

admin — Wed, 21 Oct 2009 10:39:10 +0000

Last week, we covered the basic structure of a CodeIgniter application. Let’s now jump right into developing a simple todo list application using CodeIgniter. We will be keeping the actual functionality of the application itself simple here, as the goal here is to give a good overview on what it takes to build a CI application from scratch.

Okay, the first thing you have to do is to download and extract the latest build of CodeIgniter. Next, download the controllers, models and views that I have used in this sample todo list application. You should refer to these files as you read the tutorial. Here is the demo of the sample application (use “demo” as username and password).

Directory structure

All the files related to our application will be placed in the "system/application" folder:

As you can see, we have to place our controllers, views and models in their correspondng /controllers, /views and /models directories. Initially, we will have a sample controller (Welcome) in the /controllers directory, and its corresponding Welcome view in the /views directory. The model directory will be empty.

The /config directory consists of various files which will help us fine-tune the CI framework to our development environment. We will ignore the other directories in the /application directory for the time being.

Some basic configuration first

We need to modify some of the configuration files in the /config folder to set up the framework:

database.php – this is where we will be filling up our database connectivity details. The file has ample comments to help you fill in all the necessary details correctly!
config.php – we have to fill in the path to our CI root folder here in the variable: $config['base_url']
autoload.php – this file allows us to autoload any libraries or helpers that CodeIgniter provides us so that they are available across the entire system. We will be using the session library and the url helper class, so initialise the $autoload['libraries'] and $autoload['helper'] variables to:
- $autoload['libraries'] = array(’database’,’session’);
- $autoload['helper'] = array(’url’);

By default, all CI URLs will have a ".index.php" included in them. E.g. example.com/index.php/blog/edit

To remove this, we can optionally place a .htaccess file in your CI root folder with the following content:

RewriteEngine on
RewriteCond $1 !^(index\.php|images|css|scripts|robots\.txt)
RewriteRule ^(.*)$ index.php/$1 [L]

With the above rule in place, all requests other than those for index.php, images, css, scripts and robots.txt are treated as a request for your index.php file.

CodeIgniter session class

Before we go further, let’s have a brief review of CodeIgniter’s sessions class, which will be using in this application to keep track of the user’s session. CI’s session class can handle user session data stored using either cookies or in a database. CodeIgniter’s session class does not utilize native PHP sessions. To make use of the session class in our application, we must either initialize it in a controller’s constructor, or we have to auto-load it so that it will run in the background, and will be available for us across the entire system. To load the session class manually in the controller’s constructor, we do that by calling:

$this->load->library('session');

To auto-load the session class, we have to open the file "application/config/autoload.php" and add the item to the "autoload" array as I have mentioned in configuration step above.

Reading and writing data to the session class is a breeze! To write data to a user’s session, we simply do:

$this->session->set_userdata('some_variable', 'some_value');

And, to retrieve the data again, we just call:

$item = $this->session->userdata('item');

Apart from that, CI’s session class by default, provides us with the following information:

user’s unique Session ID
user’s IP Address
user’s User Agent data (the first 50 characters of the browser data string)
user’s "last activity" time stamp

Our application features:

With that, out of the way, let’s get started. Our to-do-list application will have the following "features":

a simple user sign up and login system
session management using CI’s session class
a single to-do list which allows multiple users to add and delete items using AJAX

Database schema

Given the rather simple nature of our application, it’s not too difficult to identify what database tables we will be needing upfront. We will need two tables:

users : stores the user id, username and the hashed password.
items : stores the to-do list items and their attributes like item_id, user_id (ID of the user who created it)

CREATE TABLE IF NOT EXISTS `items` (
 `item_id` bigint(20) NOT NULL auto_increment,
 `user_id` bigint(20) NOT NULL,
 `item_text` varchar(255) NOT NULL, `is_done` int(11) NOT NULL,
 PRIMARY KEY  (`item_id`)
 ) ENGINE=MyISAM DEFAULT CHARSET=latin1; 

CREATE TABLE IF NOT EXISTS `users` (
 `user_id` bigint(20) NOT NULL auto_increment,
 `username` varchar(100) NOT NULL,
 `password` varchar(100) NOT NULL,
 PRIMARY KEY  (`user_id`)
 ) ENGINE=MyISAM DEFAULT CHARSET=latin1;

Setting up the above tables in the database which you have mentioned in your database.php configuration file above.

Here is a breakdown of all the controllers, views and model we will be needing for this application. I will explain the purpose of each of them, as we go about tackling them.

The login controller

The login controller first checks whether the user is already logged in – in which case, we simply redirect him to the dashboard. This, we do by checking whether the "logged_in" field exists in the user’s session data. We are using CI’s session class for this:

if( $this->session->userdata('logged_in') )	// user already logged in
{
	header("Location: " . base_url() . "index.php" );
	die();
}

The login controller serves two needs:

render the login form initially for a user who wants to sign in to the system
when the user submits the login form, authenticate the user and either redirect him to the dashboard or show an error message

When the controller is called, we can find out whether we should render the login form, or treat the request as a login form submission by checking for the POST variable ‘login’, which is the name of the "login" submit button in the login form.

if( $this->input->post('login') )
{
	// treat this as a login form submission
}

else {
	// render the login form
}

If it’s NOT a login form submission, we simply load the login_view defined in application/views/login_view.php. This file will render the login form.

On the other hand, if its is a login form submission, we first retrieve the username and password variable from the POST request. We then load the Users_model class, and use its validate() function to authenticate the user. If the user’s username and password match, his user_id field from the database is returned. Else, a -1 is returned. For a valid user, we initialise his session by:

$newdata = array(
 'user_id'  => $user_id,
 'username'  => $username,
 'logged_in' => TRUE
 );

 $this->session->set_userdata($newdata);

We then redirect him to the dashboard. If the username and password provided do not match, we load the login_view by passing a variable ‘$message’ that contains the error to be displayed.

The Dashboard

The welcome controller is the default controller for CodeIgniter. It will already be found in the /application/controllers directory, and this is the controller that will be called when you access our application’s URL directly without using any URL segments, as discussed in the previous article. Let us just make use of this controller for our application’s dashboard. Assuming the user has already logged in successfully, let’s build our application’s dashboard – the page the visitor first sees after logging in. In our case, it will be a page which will display a set of to-do items, and in addition, provide a way to enter a new to-do item or modify the done/not-done status of any existing item using AJAX. Here is the index() function of the welcome controller.

function index()
{

	if( !$this->session->userdata('logged_in') )	// user NOT logged in
	{
		header("Location: " . base_url() . "index.php/login" );
		die();
	} 

 	$this->load->model('items_model','items');
        $data['all_items'] =
$this->items->fetch_all_items($this->session->userdata('user_id'));
 	$this->load->view('dashboard_view',$data);
 }

The welcome controller will check whether the user is logged in (using the session data set earlier in the login controller). If the user is not logged in, or his session has expired, we will redirect him to the login page. The base_url() function belongs to the URL helper that we autoloaded in our configuration, and it returns the base URL of our application (including the "/" at the end of the URL). Otherwise, we will load the Items_model class which will be used to interact with the items table in the database. The fetch_all_items() function of the item_model class will fetch all the todo items of this particular logged in user from the "items" table. The only other thing to note here is that we are using the session class to retrieve the user id of the user that we have stored as session data when the user successfully logs in to the system.

function fetch_all_items($user_id)
{
  // fetch the to-do items of the user identified by $user_id:
  $query = $this->db->query("SELECT * FROM items WHERE user_id = $user_id");
  return $query->result();
}

The index() function of the Welcome controller then loads the view "dashboard_view", defined in "dashboard_view.php" in the system/application/views directory. When the view is loaded, we are passing to it the todo items we fetched from the database using the Items_model class. The view then renders all the to-do items on the page.

dashboard_view.php links to an external stylesheet (todoapp.css) and a JavaScript file (todoapp.js). The AJAX functionality is defined in the JavaScript file. In our application, we are using AJAX to add a new todo item to the list, and also update the done/not-done status of any of the todo items. The function addNewItem() in the JavaScript file is bound to the click event of the "Add" button.

The addNewItem() function, when fired, makes an AJAX POST request to the "add" controller which will handle the addition of a new todo item. The add controller will return the ID field of the newly added todo item in the database. If the operation is a success (if the ID returned in not -1), we simply append the new todo item (along with a checkbox) to the bottom of the existing items. We also clear the text in the textfield.

The updateItem() function is bound to the click event on each of the checkboxes. When fired, it checks whether the checkbox that the user clicked is selected or not, and it sends this information to the "update" controller.

The add controller

In all the controllers, we will have to first check if the user is logged in, before we carry out any action. For a valid user, we retrieve the text of the new todo item to be added (from the POST variable sent to the script) using:

$this->input->post('item_text',TRUE)

The second parameter is set ‘TRUE’ to indicate that the input must be filtered to negate XSS (cross site scripting) attempts. XSS is a major problem faced by many web applications, and as a golden rule, any input which might potentially get rendered on the front end must be passed through an XSS filter that escapes/strips out the dangerous elements. As an added precaution we also check whether the todo item’s text is not empty, and if all is clear, we load the "Items_model" class once again, and call the add_item() function to add the todo item to the database. The add_item() function uses another handy function that CI provides, to escape the data by adding single quotes around the data:

$item_text = $this->db->escape($item_text);

The update controller

What the update controller does is similar to the add controller and also fairly straight forward. It simply retrieves the POST variables sent to it (the ID of the item which is to be updated, and its updated status). The update controller then loads the Items_model and invokes the update_item() function to peform the update.

The logout controller

The logout controller destroys the session data of the user, and then redirects him to the login page once again.

$this->session->sess_destroy();
header("Location: " . base_url() . "index.php/login" );

User registration

Finally, let’s get to the user registration, which is handled by The Register controller. First off, I should mention here that for the sake of simplicity, I have implemented a very simple registration form, with absolutely no spam control!

The Register controller is similar to the Login controller in that – it again serves both the purposes of rendering the registration form, and as well as handling the form submission. The register_view simply asks the user to pick a username and password. The

’s action attribute points to the URL of the register controller.

When the form is submitted, the Register controller first checks to see that both the username and password fields are not empty. It then loads the "Users_model" which handles all database operations concerned with the "Users" table. We will invoke the is_valid_username() of the Users_model to see whether the username that the user has chosen already exists (the function returns a -1 if no such username is found on the system). If it a username is indeed found (in which case the function will return the ID of the user), we will initialise a $message variable with the text "That username already exists." and load the register view again, by passing the $message variable for rendering.

if( $this->users->is_valid_username($this->db->escape($username)) != -1 )
{
	// username already exists
	$data['message'] = "That username already exists.";
}
...
$this->load->view('register_view', $data);

If the user has chosen a non-existing username, then we go ahead and add the user to the database by calling the Users_model’s add_user() function, by passing the username and his hashed password. We are simply using a plain SHA1 hash here to store the password (which is again considered not secure enough without salting, but enough for our simple application). Once the user is added to the MySQL database, we use the nifty "mysql_insert_id()" PHP function to retrieve the auto increment ID field of the user row just added to the "users" table. After a successful account creation, we initialise the user’s session and redirect him to the dashboard, so the user can start using the application right away.

With that, we come to the end of this second part of CodeIgniter tutorial.

Writing web applications with CodeIgniter: Part 1

admin — Wed, 21 Oct 2009 10:39:10 +0000

CodeIgniter is a PHP framework that makes writing secure web applications a breeze. Being extremely light weighted, it’s an impressive toolkit which promotes the Model-View-Controller (MVC) approach to software development. CodeIgniter’s incredibly useful libraries, helpers and simplicity give you a sound foundation to quickly build your web apps on. This will be the first part of a series of tutorials focusing on CodeIgniter. Today, let’s get started with the basics of CodeIgniter and familiarize ourselves with the structure and semantics of a CI application.

I am assuming that you are already familiar with the MVC pattern, so let’s briefly see how it applies to a typical CI application.

View – A view is simply the content which a user sees rendered on a any page. It can be either a full web page, or even code snippets like the header or the footer of a web page. The view’s primary aim is to render data on the screen, which will be passed to it by a controller.

Controller – A controller handles the actual application logic. It acts as an intermediate between the View (front end) and the Model (the data). The controller, typically fetches records from a database via a model class, and then passes it to a view for rendering.

Model – A model is concerned with reading and writing data to and from a data souce – in our case, a database. It essentially consists of functions which help you isolate database operations from your core application logic. In CodeIgniter, a model is not necessary, should you wish to manipulate the database from a controller itself.

The URL structure

One great thing about CodeIgniter is that it generates URLs which is search engine friedly and also extremely logical for programmers. Instead of using query strings (like index.php?action=display&id=223) to pass variables, it uses a very semantic segment based URL structure. By default, the CI URLs are parsed this way:

example.com/controller_class_name/function_name/ID1/ID2

As we can see, the first segment of the URL refers to the name of the controller class, the second part referring to the function in the controller that should be invoked, and the subsequent parts representing various parameter values that can be passed to the function. Having understood that, it’s a good time to see the structure of a controller class.

Let’s take a simple example of a blog. Let us say we want a page where we want to show the entries of a blog, we can have a controller "show" which will be defined this way:

class Show extends Controller {

	function index()
	{
		// access a model class to fetch all the blog posts
			...
		// invoke a view and pass to it the blog posts to render
	}
}

There are a couple of things to note here:

all controller classes begin with a capital letter in CI – i.e Show
we will be saving the above file as "show.php" – the file name is essentially the same as the class name, except that the class name’s first character has to be in capital case.
the index() function will be the default function of the class – much like your main() function in a C program!
you will access the above controller with the following URL: example.com/show/index or just example.com/show

Remember that the first segment refers to the controller name and the second segment refers to the function name. Since the index function is the default function for the controller, we can leave it out from the URL. We can add another function to the class, called entry – which will display a specific blog entry identified by an identifier:

function entry($entry_id)
{
	// access a model class to fetch the blog post with ID $entry_id
		...
	// invoke a view and pass to it the blog post to render
}

Now, to display a particular blog entry, we access the URL: example.com/show/entry/123 , where the "123" is (say) the ID of the blog entry to be rendered. Pretty easy, right ?

Now, let’s define a CI model class. Continuing with the same blog example, let’s say that the name of the model class which will handle our blog entries is "Entry_model":

class Entry_model extends Model {

	function Entry_mode()
	{
		parent:Model();
	}

	function fetch_post($entry_id)
	{
		// do your database query and return the record...
	}
}

Now, to invoke the method fetch_post() from the controller, we do:

$this->load->model(Entry_model');
$blog_entry = $this->Entry_model->fetch_post($entry_id);

Again, it’s very intuitive. We load the model class, and then, invoke a method from the model class which will return the blog entry record. The naming convention for the model class is the same as that for a controller – the class name should start with a capital letter. Thus, the above model class is called "Entry_model" and it will be defined in the file "entry_model.php".

Finally, let’s get to how CodeIgniter handles the View. As I have already stated above, CI is very flexible in how you want to define a view. A view can be a whole page, or page fragments like header, footer, navigation, sidebar etc. It’s always a good practise to logically break down the layout of a web page into a number of components, as it promotes code reusabilty.

As for now, for simplicity, let’s just say that our blog entry will be rendered using a single view. So, we will basically have a .php file that contains the structure (design) of the blog and which will display the blog entry that is passed to it from the controller through the form of variables. Let’s say our view (which display a blog entry) is called "entry_view.php":



Showing a blog entry



$entry_title";
	echo $entry_text;
?>

When we invoke the view from the controller, we will pass in the variables $entry_title and $entry_text. Here is how we invoke the view we have defined above from a controller:

$data['entry_title'] = "A blog post title";$data['entry_text'] = "Lorem ipsum dolor sit amet...";$this->load->view('entry_view', $data);

I have shown a very simple example of how data is passed from the controller to a view above. The variables that will be used in the view are defined as elements of an associative array. To load a view, we call it by its filename – we don’t have to use ".php" extension unless we are using some other extension for the view files.

With that, I have covered the basic skeleton of a CI application. Stay tuned for the next article, in which I will walk you through on how to build a simple application using CodeIgniter, and also cover some more advanced concepts along the way!

Creating an inline contact form

admin — Wed, 21 Oct 2009 10:39:10 +0000

Customer feedback is arguably one of the most critical factors determining the success of a product over a period of time. Hence, it’s not surprising that many websites have some form of contact form or another to encourage users to write back to them. Most of these “contact” pages tend to be on a separate page which is usually part of the navigation or is linked to with phrases like “we encourage your feedback” or “do get in touch with us”, etc.

However, I have often noticed that many people (unless they genuinely needed help), either back away from submitting their comments (when they are confronted by a large textarea on the contact page), or simply move away from the site as the contact page loads.

Today, let’s spice things up a bit by using jQuery to load a lightweight inline contact form. So, instead of loading a separate contact form page when the “contact us” link is clicked, we will just have a small textarea opens up dynamically right next to the link – so that the user can type his feedback and it can be submitted rightaway using AJAX. Our main aim here is to encourage more users to provide feedback and although I don’t have actual data to prove whether an inline form will be any more helpful, I have used it in a couple of places, and it did appear to bring in more casual feedback about the site, features etc. Ok, let’s get started. Here is the demo of how it will all look in the end.

Okay, first let’s have a hypothetical page in which we want to make use of the inline contact form. The call of action, is obviously the “We would love to hear your feedback” link, which has the id “a_inline_form”. Initially, this hyperlink will simply point to the default contact form page. We will have the inline form in a DIV with id “inline_form”, which will be hidden initially.

#inline_form {
		/* keep the inline form hidden initially */
		display: none;

		position: relative;
		padding: 10px;
		width: 260px;
	}

We will now use jQuery to “hijack” this link and fire our inline contact form into action:

 // toggle visibility of inline form when link is clicked
$("#a_inline_form").click( function() {

	$("#inline_form").toggle(200);

	$("#inline_form").css( "left", $("#a_inline_form").position().left +
                                                $("#a_inline_form").width() );

	$("#inline_form").css("top", "-40px");

	// get cursor to texarea, ready to receive keystrokes!
	$("#inlinecmt").focus();	

	// return false to prevent default link behaviour
	return false;
});

The above code is fairly self explanatory – I just want to describe how we are positioning the inline form. jQuery allows us to very easily retrieve the left offset position of an element (even when it’s not absolutely or relatively positioned!) using “$(elem).position().left” property.

In this example, I wanted to place the inline form right next to the comment link. To do that, we can simply set the “left” CSS property of the inline form to a value that’s the sum of the left offset of the feedback link and the width of the comment link – this will of course place the inline form right next to the feedback link. In addition, we also set the cursor focus to the inline form so that the textarea is ready to receive input right away.

We have a simple “ok” button underneath the textarea which will be used to submit the form. We will once again “hijack” the form submit event using jQuery and perform the form submission using AJAX. I have omitted the actual form submission and processing here.

$("#inline_form").submit( function() {

	// make your ajax POST call here...

	$("#a_inline_form").after('Thanks for the comment!' +
                               '');
	$("#inline_form").hide(200);

	setTimeout( '$(".msg").hide()', 2000);

	// return false to prevent default form submission behavior
	return false;
});

Now, once the AJAX call is successful, we need to notify that to the user and thank him for the feedback. I have chosen to do that by inserting a message right after the feedback link and hiding it (using setTimeout() ) after 2 seconds. Don’t forget to hide the inline form too. With that, our inline form is up and ready to go!

This is by no means a replacement for the traditional contact form, but it will be handy in places where one requires casual feedback from users. And as you would have already noticed, we have used JavaScript here unobtrusively – so in case the user has JavaScript disabled, the feedback link merely loads the default contact page.

Avoiding long polling

admin — Wed, 21 Oct 2009 10:39:10 +0000

Right from Twitter to Google Wave, real time information streaming via the browser seems to be the most "happening" thing on the web arena currently. However, feeding real time information as and when it is available to an user using your web application is not as straight forward as it is on a desktop environment. HTTP is a stateless protocol which does not currently support a two way communication link between the server and the user’s computer via the browser.

The simplest way to simulate real time streaming of information is to poll the server every N seconds, and to display the information (if any). The number N will determine how real time the resulting stream of updates will look to a viewer. This model is simply called, polling. Now, polling is bad because it repeatedly connects and disconnects to the server, which when scaled across thousands of users, cause severe strain on your server. This problem becomes even more apparent in cases when the poller returns with empty data most of the times.

The jQuery snippet below polls the server every 3 seconds for new information and displays it in a simple alert box.

function callComplete(response) {
	alert("Response received is: "+response);
};

function connect() {
	// when the call completes, callComplete() will be called along with
	// the response returned
	$.post('/path/to/script.php', {}, callComplete, 'json');
};

$(document).ready( function() {
	setInterval(connect,3000);
}

Long polling

This technique is an optimisation of the traditional polling method. In long polling, once the client makes a connection with the server (via JavaScript), the server waits for the data requested by the client to become available. If it’s not immediately available, the server (being a PHP script for example) loops and sleeps. When the data is available, the server returns the data to the client and the connection closes. When this happens, the client again reconnects with the server (in the callback function of your original AJAX request).

This method is definitely an improvement over mindless polling, as we will avoid repeatedly opening and closing connections when data is not available for long periods of time. However, it is important to be aware of the server side technical limitations of long polling. Since connections might be kept alive for long durations of time, your web server must be capable of handling such large numbers of simultaneous connections. We talked about how certain light weight webservers outperformed Apache in this particular area in the last article.

Let’s look at a very simple jQuery/PHP long polling example:

function callComplete(response) {
	alert("Response received is: "+response);
	// reconnect to the server
	connect();
};

function connect() {
	// when the call completes, callComplete() will be called along with
	// the response returned
	$.post('/path/to/script.php', {}, callComplete, 'json');
};

$(document).ready( function() {
	connect();
}

In the PHP end, we do:

while(1) {

	$data = "some data fetched from the DB";

	// if we have new data, return it to the client
	if(!empty($data)) {
		echo json_encode($data);
		break;
	}

	sleep(3000);	// we sleep for 3s and check again for data
}

COMET streaming

COMET is a generic term that refers to the use a persistent HTTP connection for the web server to "push" data to the client as and when it arrives. If you have ever wondered how Gmail is able to notify you of a new email message seconds after it is sent, this is what they use to push the new email notifications to the front end.

However, as often is the case with JavaScript, the cross browser compatibility issues mean that a host of methods (targeting different browsers) are used to implement such an interaction. The upside is that these methods rely purely on JavaScript, and hence not dependent on any specific client side plugin. A detailed exploration of these different methods and their caveats is beyond the scope of this article, but let’s get a quick overview of these methods.

Hidden iframe technique: A hidden iframe html element is embedded onto the page, which points to the URL on the server which handles the persistent connection. The server will then push the data as it arrives to the iframe, using

Getting a Website is Easy

Book Review: The 4-Hour Work Week by Timothy Ferriss

You Might Also Like:

Blue & Yellow Sidebar For Color Scheme Inspiration

You Might Also Like:

The Structural Approach to Web Design

You Might Also Like:

Why We Click? – Another Way of Looking at Web Design

Sponsored Links

You Might Also Like:

Three Awesome Web Design Lists For Inspiration

Beautiful Examples of Inset Typography in Web Design

48 Creative Websites Designed in Blue

50 Amazing Flash Website Designs

You Might Also Like:

Writing web applications with CodeIgniter – Part 2

Writing web applications with CodeIgniter: Part 1

Creating an inline contact form

Avoiding long polling