How-To Tutorials - Web Development

(For more resources on Drupal, see here.) Setting up the e-commerce system Ubercart has existed since Drupal 6 so those users who have used Ubercart with Drupal 6 will have some experience setting up and configuring this module for Drupal 7. In this section we'll install and set up the basic Ubercart configuration. Goal Set up the system that will allow visitors to purchase take-out from the website. Additional modules needed Ubercart, Token, Views, CTools, Entity, Token, Rules (http://drupal.org/project/ubercart). Configuring Ubercart In order to utilize an e-commerce solution within a website, you must either build a solution from scratch or use a ready-made solution. Because building a professional e-commerce solution from scratch would take an entire book and weeks or months to build, we are fortunate to have Ubercart, which is a professional quality e-commerce solution tailor-made for Drupal. To begin using Ubercart: Download and install the module from its project page. The current stable release for Drupal 7 is 7.x-3.0-rc3. To use Ubercart, you will also need to install some dependency modules in order to get the best functionality and performance from Ubercart. These dependencies are listed on the Ubercart Website: Token, Views, Rules, CTools, Entity API, Entity Token and Token. Go ahead and install and enable the dependency modules and Ubercart. Once installed, we will begin by enabling the following Ubercart modules: All of the modules in the Ubercart—Core section including Cart, Order, Product, and Store. Then enable the following Core (Optional) modules: Catalog, File downloads, Payment, Product Attributes, Reports, Roles, and Taxes. Then in the Extra section enable the following: Product Kit and Stock. For our Payment method and module enable the Credit card, PayPal, and Test Gateway modules. We will not be shipping any items so we do not need to enable shipping modules at this point. There are a variety of other modules that can be optionally enabled. We will explore some of these in future topics. If you are planning to use the PayPal Express Checkout payment method with Ubercart you should make sure you have enabled the CURL PHP extension for use in your PHP configuration. To do this you can ask your hosting company to enable the CURL extension in your php.ini file. Otherwise if you have access to the php.ini file you can open the file and uncomment the CURL extension to enable it. Then save your php.ini file and restart the Web server. When you check your PHP info via the Drupal status report you should see the following section showing you that the PHP CURL extension is enabled.     Now, you should see the following Ubercart modules that you have enabled on your main modules configuration page:   Ubercart installs a new menu item called Store next to the menu item called Dashboard in the Administer menu bar, which includes the options shown in the following screenshot:   The first thing you'll notice is a warning message telling you that one or more problems exist with your Drupal install. Click on the Status report link. On the Status report page you'll see a warning telling you to enable credit card encryption. In order to use Ubercart for payment processing for your online store transactions you first need to set up an encryption location for your credit card data.   To do this click on the credit card security settings link. That will load the Credit card settings screen. Under Basic Settings, for now let's enable the Test Gateway. Later we'll discuss integrating PayPal but for testing purposes we can use the Test Gateway configuration.   Click on the Security Settings tab. Here we need to set up our card number encryption settings. We can first create a folder outside of our document root (outside of our Drupal directory) but on our web server to hold our encrypted data. We'll create a folder at the root level of our MAMP install called "keys". Go ahead and do this then type in /Applications/MAMP/keys in your Card number encryption key file path field. Also make sure the folder allows for write permissions.   Now click on the PayPal Website Payments Pro tab and disable the gateway for use. Click on the Test Gateway tab and leave this enabled for use. Click on Credit card settings and leave the defaults selected. Under Customer messages you can specify any custom messages you want to show the user if their credit card fails during the transaction process. Click Save configuration. When you save your configuration you should get the following success message: Credit card encryption key file generated. Card data will now be encrypted. The configuration options have been saved. Now, we have successfully set up our payment processing with the Test gateway enabled. We're ready to start using Ubercart. To begin using Ubercart, we will need to: Edit the Configuration settings, which are shown in the following screenshot: Clicking on the Store link allows you to configure several options that control how information on the site is displayed, as well as specify some basic contact information for the site To edit the settings for a section, click on the tab for that section. On the Store settings page, we simply need to update the Store name, Store owner, e-mail address, phone and fax numbers for the store. You can also enter store address information. If your store is not located in the United States, you will also need to modify the Currency Format settings. If you are shipping items you may need to tweak the Weight and Length formats. You can also specify a store help page where you'll provide help information. You can simply create a new page in Drupal and alias it, and then type the alias in here. Once you finish entering your Store settings click the Save configuration button Configuring Ubercart user permissions You should also create a role for store administration, by clicking on User management and then Roles. We will call our role Store Administrator. Click Add role to finish building the role. After the role has been added, click the edit permissions link for the role to define the permissions for the new role. Ubercart includes several sections of permissions including: Catalog Credit Card File Downloads Store Payment Product Product attributes Product kit Order Taxes Since this is an administrative role you may just want to give this staff person all permissions for an admin level role on the site. Go ahead and check off the permissions you need to grant and then save your role's permissions.If your site has employees, you may also want to create a separate role (or several roles) that do not give full control over the store for your employees. For example, you may not want an employee to be able to create or delete products, but you would like them to be able to take new orders. Ubercart provided blocks The Ubercart module ships with a core block that you can enable to make it easier for visitors to your site to see what they have ordered and to check out. Go to your blocks administrative page and you can enable the Shopping cart block to show in one of your block regions. I'll put it in the Sidebar second region. These are the basic configuration options which need to be done after you enable the block. Click on the configure link and then you can title your block, select whether to display the shopping cart icon, make the cart block collapsible, add cart help text ,and more. I'll leave the defaults selected for now. You should see a block admin screen similar to the following:  

(For more resources on WordPress, see here.) At its most basic, a simple implementation of the loop could work like this: <?php if (have_posts()) : while (have_posts()) : the_post(); ?><?php the_title(); ?><?php the_content(); ?><?php endwhile; else: ?><p>Sorry, no posts matched your criteria.'</p><?php endif; ?> In the real world, however, the WordPress loop is rarely that simple. This is one of those concepts best explained by referring to a real world example, so open up the index.php file of your system's TwentyEleven theme. Look for the following lines of code: <?php if ( have_posts() ) : ?><?php twentyeleven_content_nav( 'nav-above' ); ?><?php /* Start the Loop */ ?><?php while ( have_posts() ) : the_post(); ?><?php get_template_part( 'content', get_post_format()); ?><?php endwhile; ?><?php twentyeleven_content_nav( 'nav-below' ); ?><?php else : ?><article id="post-0" class="post no-results not-found"><header class="entry-header"><h1 class="entry-title"><?php _e( 'Nothing Found','twentyeleven' ); ?></h1></header><!-- .entry-header --><div class="entry-content">3<p><?php _e( 'Apologies, but no results were foundfor the requested archive. Perhaps searching will helpfind a related post.', 'twentyeleven' ); ?></p><?php get_search_form(); ?></div><!-- .entry-content --></article><!-- #post-0 --><?php endif; ?> Most of the extra stuff seen in the loop from TwentyEleven is there to add in additional page elements, including content navigation; there's also some code to control what happens if there are no posts to display. The nature of the WordPress loops means that theme authors can add in what they want to display and thereby customize and control the output of their site. As you would expect, the WordPress Codex includes an extensive discussion of the WordPress loop. Visit http://codex.wordpress.org/The_Loop. Accessing posts within the WordPress loop In this recipe, we look at how to create a custom template that includes your own implementation of the WordPress loop. Getting ready All you need to execute this recipe is your favorite code editor and access to the WordPress files on your server. You will also need a theme template file, which we will use to hold our modified WordPress loop. How to do it Let's assume you have created a custom template. Inside of that template you will want to include the WordPress loop. Follow these steps to add the loop, along with a little customization: Access the active theme files on your WordPress installation. Find a template file and open it for editing. If you're not sure which one to use, try the index.php file. Add to the file the following line of code, which will start the loop: <?php if ( have_posts() ) : while ( have_posts() ) : the_post();?> Next, let's display the post title, wrapped in an h2 tag: <h2><?php the_title() ?></h2> Let's also add a link to all posts by this author. Add this code immediately below the previous line: <?php the_author_posts_link() ?> For the post content, let's wrap it in a div for easy styling: <div class="thecontent"><?php the_content(); ?></div> Next, let's terminate the loop and add some code to display a message if there were no posts to display: <?php endwhile; else: ?><p>Oops! There are no posts to display.</p> Finally, let's put a complete stop to the loop by ending the if statement that began the code in step number 3, above: <?php endif; ?> Save the file. That's all there is to it. Your code should look like this: ?php if ( have_posts() ) : while ( have_posts() ) : the_post(); ?><h2><?php the_title() ?></h2><?php the_author_posts_link() ?><div class="thecontent"><?php the_content(); ?></div><?php endwhile; else: ?><p>Oops! There are no posts to display.</p><?php endif; ?> How it works... This basic piece of code first checks if there are posts in your site. If the answer is yes, the loop will repeat until every post title and their contents are displayed on the page. The post title is displayed using the_title(). The author's name and link are added with the_ author_posts_link() function. The content is displayed with the_content() function and styled by the div named thecontent. Finally, if there are no posts to display, the code will display the message Oops! There are no posts to display. There's more... In the preceding code you saw the use of two template tags: the_author_posts_link and the_content. These are just two examples of the many template tags available in WordPress. The tags make your life easier by reducing an entire function to just a short phrase. You can find a full list of the template tags at: http://codex.wordpress.org/ Template_Tags. The template tags can be broken down into a number of categories: General tags: The tags in this category cover general page elements common to most templates Author tags: Tags related to author information Bookmark tags: The tag to list bookmarks Category tags: Category, tag, and item description-related Comment tags: Tags covering the comment elements Link tags: Tags for links and permalinks Post tags: Tags for posts, excerpts, titles, and attachments Post Thumbnail tags: Tags that relate to the post thumbnails Navigation Menu tags: Tags for the nav menu and menu tree Retrieving posts from a specific category There are times when you might wish to display only those posts that belong to a specific category, for example, perhaps you want to show only the featured posts. With a small modification to the WordPress loop, it's easy to grab only those posts you want to display. In this recipe we introduce query_posts(),which can be used to control which posts are displayed by the loop. Getting ready To execute this recipe, you will need a code editor and access to the WordPress files on your server. You will also need a theme template file, which we will use to hold our modified WordPress loop. To keep this recipe short and to the point, we use the loop we created in the preceding recipe. How to do it... Let's create a situation where the loop shows only those posts assigned to the Featured category. To do this, you will need to work through two different processes. First, you need to find the category ID number of the Featured category. To do this, follow these steps: Log in to the Dashboard of your WordPress site. Click on the Posts menu. Click on the Categories option. Click on the category named Featured. Look at the address bar of your browser and you will notice that part of the string looks something like this:&tag_ID=9. On the site where we are working, the Featured category has the ID of 9. Category IDs vary from site to site. The ID used in this recipe may not be the same as the ID for your site! Next, we need to add a query to our loop that will extract only those posts that belong to the Featured category, that is, to those posts that belong to the category with the ID of 9. Follow these steps: Open the file that contains the loop. We'll use the same file we created in the preceding recipe. Find the loop: <?php if ( have_posts() ) : while ( have_posts() ) :the_post(); ?><h2><?php the_title() ?></h2><?php the_author_posts_link() ?><div class="thecontent"><?php the_content(); ?></div><?php endwhile; else: ?><p>Oops! There are no posts to display.</p><?php endif; ?> Add the following line of code immediately above the loop: <?php query_posts($query_string.'&cat=9'); ?> Save the file. That's all there is to it. If you visit your site, you will now see that the page displays only the posts that belong to the category with the ID of 9. How it works... The query_posts() function modifies the default loop. When used with the cat parameter, it allows you to specify one or more categories that you want to use as filters for the posts. For example: query_posts(&query_string.'&cat=5');: Get posts from the category with ID 5 only query_posts(&query_string.'&cat=5,6,9');: Get posts from the category with IDs 5, 6, and 9 query_posts(&query_string.'&cat=-3');: Get posts from all categories, except those from the category with ID 3 For more information, visit the WordPRess Codex page on query posts: http://codex.wordpress.org/Function_Reference/query_posts

  (For more resources on this topic, see here.)   Understanding Vaadin In order to understand Vaadin, we should first understand what is its goal regarding the development of web applications. Vaadin's philosophy Classical HTML over HTTP application frameworks are coupled to the inherent request/response nature of the HTTP protocol. This simple process translates as follows: The client makes a request to access an URL. The code located on the server parses request parameters (optional). The server writes the response stream accordingly. The response is sent to the client. All major frameworks (and most minor ones, by the way) do not question this model: Struts, Spring MVC, Ruby on Rails, and others, completely adhere to this approach and are built upon this request/response way of looking at things. It is no mystery that HTML/HTTP application developers tend to comprehend applications through a page-flow filter. On the contrary, traditional client-server application developers think in components and data binding because it is the most natural way for them to design applications (for example, a select-box of countries or a name text field). A few recent web frameworks, such as JSF, tried to cross the bridge between components and page-flow, with limited success. The developer handles components, but they are displayed on a page, not a window, and he/she still has to manage the flow from one page to another. The Play Framework (http://www.playframework.org/) takes a radical stance on the page-flow subject, stating that the Servlet API is a useless abstraction on the request/response model and sticks even more to it. Vaadin's philosophy is two-fold: It lets developers design applications through components and data bindings It isolates developers as much as possible from the request/response model in order to think in screens and not in windows This philosophy lets developers design their applications the way it was before the web revolution. In fact, fat client developers can learn Vaadin in a few hours and start creating applications in no time. The downside is that developers, who learned their craft with the thin client and have no prior experience of fat client development, will have a hard time understanding Vaadin as they are inclined to think in page-flow. However, they will be more productive in the long run. Vaadin's architecture In order to achieve its goal, Vaadin uses an original architecture. The first fact of interest is that it is comprised of both a server and a client side. The client side manages thin rendering and user interactions in the browser The server side handles events coming from the client and sends changes made to the user interface to the client Communication between both tiers is done over the HTTP protocol. We will have a look at each of these tiers.   Client server communication Messages in Vaadin use three layers: HTTP, JSON, and UIDL. The former two are completely un-related to the Vaadin framework and are supported by independent third parties; UIDL is internal. HTTP protocol Using the HTTP protocol with Vaadin has the following two main advantages: There is no need to install anything on the client, as browsers handle HTTP (and HTTPS for that matter) natively. Firewalls that let pass the HTTP traffic (a likely occurrence) will let Vaadin applications function normally. JSON message format Vaadin messages between the client and the server use JavaScript Objects Notation (JSON). JSON is an alternative to XML that has the following several differences: First of all, the JSON syntax is lighter than the XML syntax. XML has both a start and an end tag, whereas JSON has a tag coupled with starting brace and ending brace. For example, the following two code snippets convey the same information, but the first requires 78 characters and the second only 63. For a more in depth comparison of JSON and XML, refer to the following URL: http://json.org/xml.html <person> <firstName>John</firstName> <lastName>Doe</lastName> </person> {"person" { {"firstName": "John"}, {"lastName": "Doe"} } The difference varies from message to message, but on an average, it is about 40%. It is a real asset only for big messages, and if you add server GZIP compression, size difference starts to disappear. The reduced size is no disadvantage though. Finally, XML designers go to great length to differentiate between child tags and attributes, the former being more readable to humans and the latter to machines. JSON messages design is much simpler as JSON has no attributes. UIDL "schema" The last stack that is added to JSON and HTTP is the User Interface Definition Language (UIDL). UIDL describes complex user interfaces with JSON syntax. The good news about these technologies is that Vaadin developers won't be exposed to them. The client part The client tier is a very important tier in web applications as it is the one with which the end user directly interacts. In this endeavor, Vaadin uses the excellent Google Web Toolkit (GWT) framework. In the GWT development, there are the following mandatory steps: The code is developed in Java. Then, the GWT compiler transforms the Java code in JavaScript. Finally, the generated JavaScript is bundled with the default HTML and CSS files, which can be modified as a web application. Although novel and unique, this approach provides interesting key features that catch the interest of end users, developers, and system administrators alike: Disconnected capability, in conjunction with HTML 5 client-side data stores Displaying applications on small form factors, such as those of handheld devices Development only with the Java language Excellent scalability, as most of the code is executed on the client side, thus freeing the server side from additional computation On the other hand, there is no such thing as a free lunch! There are definitely disadvantages in using GWT, such as the following: The whole coding/compilation/deployment process adds a degree of complexity to the standard Java web application development. Although a Google GWT plugin is available for Eclipse and NetBeans, IDEs do not provide standard GWT development support. Using GWT development mode directly or through one such plugin is really necessary, because without it, developing is much slower and debugging almost impossible. For more information about GWT dev mode, please refer to the following URL: http://code.google.com/intl/en/webtoolkit/doc/latest/DevGuideCompilingAndDebugging.html There is a consensus in the community that GWT has a higher learning curve than most classic web application frameworks; although the same can be said for others, such as JSF. If the custom JavaScript is necessary, then you have to bind it in Java with the help of a stack named JavaScript Native Interface (JSNI), which is both counter-intuitive and complex. With pure GWT, developers have to write the server-side code themselves (if there is any). Finally, if ever everything is done on the client side, it poses a great security risk. Even with obfuscated code, the business logic is still completely open for inspection from hackers. Vaadin uses GWT features extensively and tries to downplay its disadvantages as much as possible. This is all possible because of the Vaadin server part. The server part Vaadin's server-side code plays a crucial role in the framework. The biggest difference in Vaadin compared to GWT is that developers do not code the client side, but instead code the server side that generates the former. In particular, in GWT applications, the browser loads static resources (the HTML and associated JavaScript), whereas in Vaadin, the browser accesses the servlet that serves those same resources from a JAR (or the WEB-INF folder). The good thing is that it completely shields the developer from the client-code, so he/she cannot make unwanted changes. It may be also seen as a disadvantage, as it makes the developer unable to change the generated JavaScript before deployment. It is possible to add custom JavaScript, although it is rarely necessary. In Vaadin, you code only the server part! There are two important tradeoffs that Vaadin makes in order achieve this: As opposed to GWT, the user interface related code runs on the server, meaning Vaadin applications are not as scalable as pure GWT ones. This should not be a problem in most applications, but if you need to, you should probably leave Vaadin for some less intensive part of the application; stick to GWT or change an entirely new technology. While Vaadin applications are not as scalable as applications architecture around a pure JavaScript frontend and a SOA backend, a study found that a single Amazon EC2 instance could handle more than 10,000 concurrent users per minute, which is much more than your average application. The complete results can be found at the following URL: http://vaadin.com/blog/-/blogs/vaadin-scalabilitystudy-quicktickets Second, each user interaction creates an event from the browser to the server. This can lead to changes in the user interface's model in memory and in turn, propagate modifications to the JavaScript UI on the client. The consequence is that Vaadin applications simply cannot run while being disconnected from the server! If your requirements include the offline mode, then forget Vaadin. Terminal and adapter As in any low-coupled architecture, not all Vaadin framework server classes converse with the client side. In fact, this is the responsibility of one simple interface: com.vaadin.terminal.Terminal. In turn, this interface is used by a part of the framework aptly named as the Terminal Adapter, for it is designed around the Gang of Four Adapter (http://www.vincehuston.org/dp/adapter.html) pattern. This design allows for the client and server code to be completely independent of each other, so that one can be changed without changing the other. Another benefit of the Terminal Adapter is that you could have, for example, other implementations for things such as Swing applications. Yet, the only terminal implementation provided by the current Vaadin implementation is the web browser, namely com.vaadin.terminal.gwt.server.WebBrowser. However, this does not mean that it will always be the case in the future. If you are interested, then browse the Vaadin add-ons directory regularly to check for other implementations, or as an alternative, create your own! Client server synchronization The biggest challenge when representing the same model on two heterogeneous tiers is synchronization between each tier. An update on one tier should be reflected on the other or at least fail gracefully if this synchronization is not possible (an unlikely occurrence considering the modern day infrastructure). Vaadin's answer to this problem is a synchronization key generated by the server and passed on to the client on each request. The next request should send it back to the server or else the latter will restart the current session's application. This may be the cause of the infamous and sometimes frustrating "Out of Sync" error, so keep that in mind.  

(For more resources on WordPress, see here.) Blog design principles Blogs tend to have a fairly simple, minimalist layout and design. This has always been one of their key characteristics. Blogs are all about frequently updated content, so the main purpose of their design is to present that content as efficiently and conveniently as possible. The vast majority of blogs present their most recent content on the page that visitors arrive at; hence, the front page contains the latest posts. There's no home page with a verbose welcome message and a long navigation menu to click through to the important stuff. The visitor gets straight into the meat of the blog. By default, this is the structure that WordPress provides. It is possible to set a static page as your blog's front page, but, in the vast majority of cases, I wouldn't recommend it. So when considering the architecture of a blog, unlike other types of website, we don't have to worry too much about a complex navigation structure. There is a convention that we can follow. Yes, we may want to add some extra static pages, but probably only a few of these. What we are most concerned with in blog design is not a complicated navigation structure and how all the pages link together, but how the actual blog page should look and feel. This can be broken down into four key components, which we will examine, one by one: Layout Color Typography Usability and accessibility Layout Good design is all about making something easy for people to use. Designers achieve this by employing standards and conventions. For example, cars have a standard design: four wheels, a chassis, a steering wheel, gas pedal, brake, gear shift, and so on. Car designers have stuck to this convention for many years. First, because it works well and second, because it enables us to drive any car we choose. When you sit down in any standard road car, you know how it works. You turn the key in the ignition, select a gear, hit the gas, and off you go. It's certainly not beyond the ken of car designers to come up with new ways for getting a car in motion (a joystick maybe, or a hand-operated brake) but this would make it more difficult for people to drive. Cars work reasonably safely and efficiently because we are all familiar with these conventions. The layout of blog pages also tends to follow certain conventions. As with cars, this helps people to use blogs efficiently. They know how they work, because they're familiar with the conventions. Most blogs have a header and a footer with the main content arranged into columns. This columnar layout works very well for the type of chronological content presented in blogs. Because of these conventions, the decisions about our blog layout are fairly simple. It's basically a case of deciding where we want to place all our page elements and content within this standard columnar layout. The set of page elements we have to choose from is also based on fairly well entrenched blogging conventions. The list of things we may want on our page includes: Header Posts Comments Static content (for example, the About page) Links to static pages (simple navigation) RSS feeds Search Categories Archives Blogroll Widgets and plugins Footer If we look at this list in more detail, we can see that these page elements can be grouped in a sensible way. For example: Group 1 Header Links to static pages Group 2 Posts Comments Static content Group 3 RSS Feeds Search Categories Group 4 Archives Blogroll Widgets and plugins Group 5 Footer This isn't the only possible grouping scheme we might come up with. For example, we may place the items in Groups 3 and 4 into a single larger group, or we may have widgets and plugins in a group on their own. From this grouping, we can see that the type of items in Group 2 are likely to be the main content on our page, with Groups 3 and 4 being placed in sidebars . Sidebars are areas on the page where we place ancillary content. Having considered the elements we want on the page and how they might be grouped, we can think about possible layouts. Within the conventional columnar structure of blogs there are quite a few possible layout variations. We'll look at four of the most common. The first is a three-column layout. Here, we have two sidebars, one on either side of the main content. Using this type of layout, we would probably place the items in Groups 3 and 4 in the sidebars and Group 2 in the main content area. A variation on the three-column layout is to have the two sidebars next to each other on one side of the page (usually the right), as shown in the following diagram. This is a popular layout for blogs, not just for aesthetics, but because the search engine spiders encounter the post column first as that content is at the top of the template. Using two sidebars is useful if you anticipate having a lot of ancillary content on your blog. The list of page elements given earlier is really the bare minimum you would want on your page. However, if you decide to use lots of widgets or have a long blogroll, it's a good idea to spread them across two sidebars. This means that more of your content can be placed above the fold. The concept of above the fold in web design applies to content in a web page which is visible without having to scroll down, that is, the stuff in the top part of the page. It's a good idea to place the most important content above the fold so that readers can see it immediately. This is particularly true if you plan to monetize your blog by displaying adverts. Adverts that appear above the fold get the most exposure, and therefore, generate the most revenue Another popular layout amongst bloggers has just two columns. In this layout, we would place the items in Groups 3 and 4 together in the one sidebar. It doesn't really matter which side of the page the sidebar is placed, but it seems more common to have it on the right. Studies have shown that a web user's eyes are most often focused on the top-left region of a web page, when they first open any page. So it makes sense to place your main content there, with your sidebar on the right. Also, remember that the search engine spiders will find the leftmost content first. You want them to find your main content quickly, which is a good reason for placing your sidebar on the right, out of their way. An important benefit of a two-column layout is that it allows more room for your main content area. This may be important, if you intend to use a lot of video or images within your blog posts. The extra room allows you to display this visual content bigger. Many blogs place some of their ancillary content just above the footer, below the main content. This also has the advantage of leaving more space for the main content, as with the two-column layout. The following diagram shows this type of layout. Here, the content just above the footer isn't strictly speaking a sidebar, but I've labeled it this way because it's the terminology most often applied to this type of ancillary content. Wireframing The layout diagrams we've just seen are referred to as wireframes by web designers. They give a simple overview of where the elements of a page should be placed. It would be a good idea for you to create your own wireframe for your blog design. This can be done using most graphic software packages or something like Microsoft Visio , or a simple pen and paper does the job equally well! Color This is the next design principle we need to consider. It may be that you already have a corporate color scheme based on your company logo, stationery, or existing website. In this case, you'll probably want to continue that theme through your blog design. Even if you already have your corporate color scheme, this section may still be useful in case you decide to change your blog colors in the future. The subject of color in design is a large one. Design students spend a great deal of time learning about the psychology and science of colors and techniques for achieving the best color schemes. Obviously, we don't have enough space to go into that kind of detail, but I will try to give you a few pointers. The first thing to think about is the psychology of color, in particular, color associations. This is the idea that different colors evoke different feelings and emotions in the eye of the beholder. To a certain extent this can be rather subjective and it can also depend on cultural influences, but there are some generalities that can be applied. For example, red is often perceived as being exciting, passionate, or dramatic. Yellow is an active and highly visible color, which is why it is used in warning signs. It is also associated with energy and happiness. Blue is sometimes thought of as being cold. It can also be a calming color and may sometimes be seen as corporate or conservative. White, for many people, gives the idea of cleanliness, purity, and perfection. Black can be seen as strong, elegant, and chic. Obviously, these color associations can vary from person to person, so designers don't rely on them solely in their color decisions, but they are certainly worth bearing in mind. There are more practical considerations regarding color that are probably more relevant than color psychology. For example, we all know that some color combinations don't work well together. There is a great deal of design theory aimed at devising good color combinations, but unless you're a professional designer, it's not really worth going into. Probably the best method for working out good color combinations is trial and error. If you're trying to figure out a background color and text color for your blog, simply test a few out. You could use a graphics package such as Photoshop or Microsoft Paint , or one of the many online color tools such as, http://colorschemedesigner.com/ or Adobe's Kuler at http://kuler.adobe.com. When choosing background and text colors you need to think about contrast. For example, yellow text on a white background can be very difficult to read. Some people also find light text on a black background a strain on their eyes. It's also important not to use too many colors in your design. Try to limit your palette to a maximum of three or four. Sometimes you may only need two colors to make an attractive design. One method for devising color combinations is to look for examples all around you, particularly in nature. Maybe look at a photograph of a landscape and pick out color combinations you like. Also consider the work of professional designers. Think about websites and blogs you like, and examine the color schemes they have used. You will also find good examples in offline design—pick up a book and see how colors have been used in the cover design. If you would like to base your blog's color scheme on your company logo, you could use lighter and darker versions of one color from the logo. Use the most vivid color in the logo for emphasis or headings. Web color theory At this point, it's worth looking at the technical theory behind colors on the Web. Web browsers use the Hexadecimal RGB color system to render colors in web pages. This is because computer monitors use an RGB color model, which means every pixel is colored using a combination of red, green, and blue light (hence RGB). There are 256 different levels of red light, 256 different levels of green light, and 256 different levels of blue light. These can be combined to create 16,277,216 different colors, which are all available for your web browser. The hexadecimal system gives us a way of counting from 0 to 255 using numbers and letters, which covers all 256 levels of RGB light. In the hexadecimal scale, 0 is 00 and 255 is FF. A six-character hexadecimal color code specifies the levels of red, green and blue, which form a particular color. For example, the color white combines red, green, and blue at their highest possible levels, that is 255. Remember that in hexadecimal 255 is FF, so the color code for white is FFFFFF (Red: FF, Green: FF, and Blue: FF). The color code for black is 000000 as the levels of red, green, and blue are set to their lowest, or 00 (in hexadecimal). The code for red is FF0000, blue is 0000FF, and yellow is FFFF00, and so on. We can use six-character Hexadecimal RGB codes to define all of the 16,277,216 web colors. So how do we know the hexadecimal code for a particular color? Well, there are many tools available that define the Hexadecimal RGB codes for the colors you choose. Some are standalone applications for PC or Mac, and others are online. Take a look at https://www.webpagefx.com/web-design/color-picker/ or do a quick search in Google on color picker . For more information on web colors , read the article at http://en.wikipedia.org/wiki/Web_colors. Typography Another important consideration for your blog design is the fonts you use. Your choice of font will have a big impact on the readability of your blog. It's important to bear in mind that although there are literally thousands of fonts to choose from, only a small number of them are practical for web design. This is because a web browser can only display fonts that are already installed on the user's computer. If you choose an obscure font for your blog, the chances are that most users won't have it installed on their computer. If this is the case the web browser will automatically select a substitute font. This may be smaller or far less readable than the font you had in mind. It's always safest to stick to the fonts that are commonly used in web design, which are known as web safe fonts. These include the following: Arial Verdana Times New Roman Georgia There are two types of font, serif and sans-serif. Serif fonts have little flourishes at the end of the strokes whereas sans-serif fonts don't have this extra decoration. Arial and Verdana are sans-serif fonts, whereas Times New Roman and Georgia are serif fonts. As you'll see later in the article, when we look at CSS, fonts are usually specified in groups or families. They are listed in the order of the designer's preference. For example, a designer may specify font-family:"Georgia, Times New Roman, serif". This means when the browser renders the page it will first look for the Georgia font; if it isn't installed, it will look for the Times New Roman font and if that isn't installed, it will look for the computer's default serif font. This method gives the designer more control over the font choices the browser will make. The size of your font is also an important factor. Generally speaking, the bigger it is, the easier it is to read. Computer displays are getting bigger and bigger but the default screen resolutions are tending to get smaller. In other words, the individual pixels on users' screens are getting smaller. This is a good reason for web designers to choose larger font sizes. This trend can be seen on many Web 2.0 sites, which tend to use large and clear fonts as part of their design, for example http://www.37signals.com. But be careful not to go too big as this can make your design look messy and a little childish. Remember that you're not limited to using just one font in your blog design. For example, you may decide to use a different font for your headings. This can be an effective design feature but don't go crazy by using too many fonts, as this will make your design look messy. Probably two, or at most three, fonts on a page are plenty. Font replacement Font replacement refers to a relatively new group of technologies that are pushing the envelope of web typography. In theory, they allow designers to use any font in their web page designs. In practice, things are a little more complicated. Issues around browser compatibility and font licensing make font replacement technologies a bit of a minefield for anyone who is new to web design. It's true that, thanks to font replacement technologies, professional designers are no longer constrained by the notion of web safe fonts. But, if you are a web design novice, I recommend you stick to web safe fonts until your skills improve and you are ready to learn a whole new technology. A full discussion on font replacement is way beyond the scope of this article; I mention it only to give you a better overview of the current state of web typography. But if you are interested in knowing more, three popular font replacement technologies are Cufón (http://cufon.shoqolate.com), Font Squirrel (http://www.fontsquirrel.com), and Google Fonts API (http://code.google.com/apis/webfonts/). There is also something known as @font-face, which is part of CSS3, the latest specification of CSS. Again, it offers the tantalizing possibility of giving designers free rein in their choice of fonts. Sadly, @font-face is also hindered by browser compatibility and font licensing issues. The Font Squirrel technology, mentioned previously, resolves these issues to a certain extent, so this is something to be aware of as your web design skills develop. But for the time being, I recommend you concentrate on the basics of web typography and don't worry about @font-face until you feel ready. Usability and accessibility This is another very important area to consider when designing your blog. Many people, who live with various disabilities, use a range of 'assistive' software to access the Web. For example, people with visual impairments use screen readers, which translate the text in a web browser into audible speech. There are also people who are unable to use a mouse, and instead rely on their keyboard to access web pages. It's the responsibility of web designers to ensure that their websites are accessible for these different methods of browsing. There's no sense in alienating this group of web surfers just because your blog is inaccessible to them. There are also many other circumstances when your blog might be accessed by means other than a standard web browser, for example, via mobile phones, PDAs, or tablets. Again, a good designer will ensure that these modes of browsing are catered for. The web design industry has been well aware of these accessibility issues for many years and has come up with guidelines and technologies to help conscientious designers build websites that are standards compliant . These web standards help ensure best practice and maximize accessibility and usability. Luckily, WordPress takes care of a lot of the accessibility issues simply by the way it's been developed and built. The code behind WordPress is valid XHTML and CSS, which means that it complies with web standards and is easily accessible. It's important, then, that you don't break the system by allowing bad practice to creep in. Some of the things to bear in mind relate to a couple of design principles we've already discussed, for example, using a color scheme and font size that makes your text easy to read. Other issues include keeping the number of navigation links on your page to a minimum—a whole load of useless links can be annoying for people who have to tab through them to get to your main content. You should also ensure that any third-party plugins you install are standards-compliant and don't throw up any accessibility problems. The same is true if you decide to use a ready-made theme for your blog design. Just make sure it's accessible and satisfies web standards. For more background reading on web standards, you could take a look at http://www.alistapart.com or the World Wide Web Consortium (W3C) website at http://www.w3.org. Implementing your blog design We've now considered the principles involved in designing our blog. The next thing to decide is how we actually carry out the design work. There are three main options available, each of which involves varying degrees of work. However, they all require knowledge of the design principles we just covered. The first approach is probably the easiest; it simply involves finding a readymade theme and installing it in WordPress. By working through the earlier design principles, you should have an idea of what you want your blog to look like and then you simply need to find a theme that matches your vision as closely as possible. A good place to start looking is the official WordPress Free Themes Directory at http://wordpress.org/extend/themes/. You'll also find many more theme resources by running a search through Google. There are hundreds of very attractive WordPress themes available for free and many others which you can pay for. However, if you adopt this approach to your blog design, you won't have a unique or original blog. The chances are the theme you choose will also be seen on many other blogs. At the other end of the scale, in terms of workload, is designing your own theme from scratch. This is a fairly complicated and technical process, and is well beyond the scope of this article. In fact, it's a subject that requires its own book. If you intend to build your own theme, I recommend WordPress 2.8 Theme Design by Tessa Blakeley Silver ISBN 978-1-849510-08-0 published by Packt Publishing. The third approach is to modify a readymade theme. You could do this with any theme you choose, even the default Twenty Ten theme that ships with WordPress. However, if you edit a fully developed theme, you spend a lot of time unpicking someone else's design work and you may still be left with elements that are not completely your own. A better method is to start with a theme framework, which has been specially designed to be a blank canvas for your own design. Over the last few years many WordPress theme frameworks have appeared, some free, some paid-for. Two of the most popular paid-for theme frameworks are Thesis (http://diythemes.com/) and Genesis (http://www.studiopress.com/themes/genesis), while popular free frameworks include Hybrid (http://themehybrid.com/), Carrington (http://carringtontheme.com/), and Thematic (see below).

(For more resources on Moodle, see here.) From curriculum to courses: What counts as a Moodle course Let's start this section with me describing the course I'm going to be converting to Moodle as we work together through this book. The course is called "Backyard Ballistics" and it's a science course that forms part of an applied physics qualification. The course is all about the art of firing weird objects through the air with chemicals and equipment that you will find in your average domestic kitchen and garden shed.   There are certain aspects of this course that I can't convert to Moodle. I want my students to get an appreciation of energy and dynamics by "doing" (kinesthetic learning) the science using everyday items you'll find around your house. But there is a good deal of support material, handouts, diagrams, and quizzes, that currently I try and distribute electronically using a "shared drive" on the college server. However, my students can never find the materials I tell them to go and look for. At least, that's their excuse. But I've got to admit that after a few years of use our shared drive is starting to look a bit of a mess. But where do I put these resources in Moodle? The answer is that you put them into a Moodle course. And here is a screenshot of just a fragment of a Moodle course: (Move the mouse over the image to enlarge.) I've divided my course into six topics: Getting Things Flying &#x8B; Lighter Than Air: Hydrogen Filled Balloons Fire Kites &#x8B; Basic Rocketry: The Match Rocket &#x8B; The World Famous Tennis Ball Mortar! &#x8B; Backyard Ballistics: End of Course Project The reason why I've chosen to convert Backyard Ballistics into topics is partly because that's how I teach it and partly because I am happy for the students to "dip into" the resources and activities I have converted to Moodle. Before we look at how we can get a course and start adding content to it we really need to understand what Moodle considers to be a course and how Moodle organizes them. What is a Moodle course You can clearly see now that, at its most basic, a Moodle course is a placeholder for resources and activities. Obviously it's much more than this, as you'll be learning as you work through this book. One obvious advantage Moodle has over a shared drive is that links to resources and activities can be interspersed with text and graphics to make the experience more visually appealing and engaging, and the resources I upload easy to find (I don't accept any excuses these days). How Moodle organizes its courses Let's take a quick look at how you can organize courses in Moodle. To help organize courses, Moodle has the idea of categories and subcategories: Remember that you'll only find resources and activities in a Moodle course. Categories and subcategories are only there to help you organize and manage the organization of courses. So how does that work in practice? For example, I work in the Physics department, part of the Faculty of Science. My Backyard Ballistics course supports the Applied Physics qualification. Here's how we've got our categories and subcategories arranged: I'm sure you could think of examples for your subject area. You could have a category called English that contained two subcategories, Literature and Language. Within literature you could have short courses on particular aspects of the set text you are teaching. You could have a category 20th Century History containing subcategories for Britain, Germany, France, Italy, and USA. Each country subcategory can contain further subcategories called Politics, Society, and so on. Because this is such a key issue when you first start using Moodle, let's spend a little time investigating the more common approaches taken when converting face-to-face teaching to Moodle. Breaking up is hard to do How you break up a face-to-face, traditionally taught course, depends on the age group and the subject area you are working in, so let's study some examples. Often younger children will have the same teacher for all of their subjects. Schools in this situation usually categorize Moodle courses based on year groups, and within the year group each teacher will have their own subcategory in which they are free to create and delete courses as they wish: Each teacher having their own Moodle course means it is much easier for the children to find the resources that have been uploaded and activities created for them. As the children get older you can start running different Moodle courses for different subjects depending on that child's age and ability. Now I could have a category for each year group, and within them categories for each subject area: Instead of a mathematics teacher having just one course they may instead have a course in Year 9, two in Year 10 and another one in Year 12. As the subject areas begin to broaden and the amount of material you need to get through increases, you might need to think about having Moodle courses for particular subject areas, especially those areas that students tend to struggle with. As students become older, things tend to become easier, because qualifications examined by external examination bodies will have their own syllabus. Read the syllabus carefully and you will often be able to see immediately how to break the subject down into Moodle courses. Mathematics, for example, naturally falls into categories, namely: &#x8B; Number &#x8B; Algebra Geometry (shape, space, and measure) &#x8B; Data handling and statistics Within each category there is then a natural divide between subject areas. See whether you can spot a similar pattern in your subject area. For students who are older still (that is, college or university age), subjects are most often taught in units anyway. A short 10-week unit, for example, is an ideal candidate for a Moodle course. To close this section, I will leave you with just a few more thoughts. One is that Moodle courses can also be created to develop a student's key skills. Examples of key skills could be: Communication &#x8B; Application of number &#x8B; Information and communication technology &#x8B; Problem solving &#x8B; Collaboration Another is that Moodle courses are not set in stone; once they are created they can be changed as you require. You will also see later in this book that responsibility for different aspects of your Moodle course can be delegated down to your students, enabling you all to work together developing your page. Have a go hero – developing key skills Try identifying courses that support developing one of the key skills. If key skills are a priority in your school or college, then no doubt you will have lots of skills-based teaching materials already to hand that you can convert into Moodle courses. If in doubt, hold a meeting In this section we've been investigating how we could break up traditionally taught, face-to- face courses and identifying what might be converted into Moodle courses. You can do this along traditional lines, or you can approach the problem by looking at key skills or learning styles. It is an extremely complicated issue and will undoubtedly involve discussions with your department colleagues. I strongly suggest you hold a Moodle meeting to discuss which courses are going to be created, initially. Use the opportunity to discuss who is going to teach them, and what categories they are going to ft into. Plan as much as you can before you start doing anything in Moodle. Remember to involve your Moodle administrator in those meetings, especially if they are the one responsible for creating your categories and courses. Now that we know what Moodle categories and courses we're going to need, we can focus on creating and running those courses. Let's get started: Setting up the course The remainder of the book will focus on just one course. If you're putting your whole department into Moodle then you'll have lots of courses to work through. That's why it's so useful to assign other teaching staff to course creation, and let them share the work. We'll show you how to do that too.

(For more resources on Liferay, see here.) Designing the site—Painting the full picture Whenever we get the requirements of the portal, we should first ask ourselves, how would the portal look when it goes live? This one small question will open a door to a lot of other questions and a lot of information which will be required to implement the portal. You should always think of the end state of the portal and then start painting the complete picture of the portal. This approach is known as Beginning with the end! Now, as we have just discussed the approach we should take while starting the site design, let's understand what all information we can retrieve or get when we ask this question to ourselves. We will discuss about four main components of the Liferay Portal design. Users No matter what the size of the portal is—small, medium, or large—it will always be designed for the users. Users are in the centre of any portal application. Let's think of a very common portal . Just imagine that you have to implement this portal. You are sitting in your nice comfy rocking chair and thinking of the users of this portal. What all questions would you ask yourself (or the client, if he/she is with you) about the users of this portal? Who will be using this portal? Will all the users of this portal have same privileges? Or some of the users will have more privileges than the others? Can we collect the users into any specific group? Are these users organized in any kind of hierarchy? Can the users leave or join this portal at a will? and so on. Let's discuss about the answers of the preceding questions and the information we can retrieve from the answers. If we want to provide an answer to the first question in only one word, then it can be—Users. It is quite obvious that the portal will be used by the users. However, if we go into the detail of this question we can get an answer like—all the employees of CNN, users from all over the world, John Walter who will be responsible for administration of the entire portal, and so on. So answer to this question will give us the information about all the players associated with the portal. If all the users of the portal have the same privileges, then it's pretty obvious that every user will be able to perform the same function in the portal. However, this may not be the case with our portal, http://www.cnn.com. Here, we have end users who will come to the portal and will access the information; we can also have a group of internal users who can create the content. Similarly, there can be a group who can approve the content and other group can publish the content; there can also be users who are responsible for user management and one or more users who are responsible for portal management. So this kind of question will give us the information about different roles and permissions associated with each role in our portal. It will also give us the information that which user should be associated with what kind of role. This information is very useful when we are working on the security piece of the portal. If the answer of the third question is Yes then we can either create a user group in our portal or group the users into a specific role. This question will give us the information about user grouping in the portal. Now, answer to the last two questions will be discussed in more detail in this article. However, these questions will help us to determine if we should use an organization or community or mix of both in our portal. Every Liferay portal must have at least one organization or community. Once we get the information about the users in our portal, we should think of the content next. Content No portal can exist without any kind of content. The content can be a static HTML, a static article, a video, an audio, podcast, document, image, and so on. To make the portal more effective, we have to manage the content properly. We will continue with our example of : What kind of questions can we ask to ourselves or to the client about the content? What are the types of the content we will use in the portal? Where are we going to store the content? To Liferay database or some other external database? Do we have to create the content from scratch? Do we need to migrate existing content to Liferay? And a few more… I am sure you must be visiting many portals every day. Can you think of the possible answers to the preceding questions? Also, think of the information which can be retrieved from those answers. The answer to the first question can be—document, images, web content, video, podcast, and so on. This answer will give us an idea about the content types which need to be implemented in the portal. Some of the contents like web content and documents can be available out of the box in Liferay; while other content types like video and podcast may not be available out of the box. This information will enable us to determine the types of content and effort required to create the new content. The second question is a bit tricky. By default, Liferay stores the content into database. However, if the client wants we can store the content in some shared location as well. For example, storing documents into file system. Also, it requires high availability. You can refer to wiki about this on . An answer to this question will give us information like if we need to add any additional hardware or not, if we should do any specific configuration to meet the requirements, and so on. Answers to third and fourth questions will be mainly used for the effort estimation purpose. If a portal like site is using a huge amount of content and all of the content has to be built from scratch then it may take a good amount of time. If the content is already available, we need to consider the effort of migrating and organizing the content. We can also think of other questions like requirement of workflow, type of the flow, if staging is required for the content or not, and so on. All of the preceding questions will give us a good picture about the content to be created or used in our portal. Once we are thorough with this section, it becomes easy to appoint someone to do content management design for your portal. Applications We have discussed about the user and the content of the portal. However, what about the applications which will be hosted on the portal? We cannot imagine a portal without any application nowadays. A portal can contain different applications like forum, wiki, blog, document viewer, video player, and so on. Let's get a list of questions which you should ask yourself while designing the portal: What are the different applications required for this portal? Do we have any application available out of the box in Liferay? Do we need to modify/extend any existing application available in Liferay? Do we have to create any new application for the portal? If yes, what is the complexity of this application? Liferay ships with more than 60 applications pre-bundled known as portlets. These applications are very commonly used in many of the portals. When we ask the preceding questions to ourselves, we get the following information: Number of applications required in the portal How many applications are available out of the box? If we have more applications available OOTB (out of the box) then it can reduce the development time Scope of the project. Do we need any integration with external system or not? Kind of applications we have to develop from scratch Once we go through the preceding set of questions, it becomes very easy to get a picture of the applications required in our portal. It will also provide us information about the efforts required to implement the portal. So, if you are managing a portal development project, you should definitely have this information ready before starting the project. Security Security is one of the most important aspects of any portal. When we think about security of any portal, we must consider access to the content and the applications on the portal. You must have come across many of the portals so far. Some of the portals allow you to create your account freely; some of the portals require an authorization before creating the account while some other portals don't allow creating an account at all. Also, there are some portals which display the same information to all the users while other portals display certain information to members only. To put this in a nutshell, each of the portal has its own security policy and it operates based on that policy only. Once we have discussed/thought about users, content, and application in portal design, we should consider the security aspect of the portal. Now, let's think of some of the questions which we should normally ask to ourselves/client while considering security aspect of the portal. Can everyone freely create an account with the portal? Do we need to migrate the users from an existing user base like LDAP? Can everyone access the same information or we need to display certain information to portal members only? Can all the members of the portal access all the applications with the same privileges or certain users have more privileges over other members? And so on… When we get answers to the preceding questions, we get following information about the portal security: If everyone can create an account with the portal, then in that case we need to provide the create account functionality to the users. Also, we don't need to do any authorization on account creation. If the answer to the first question is NO, then we need to either provide some kind of authorization on account creation or we need to remove the account creation facility completely If we have to migrate the users from an existing user base, then we have to think about the migration and integration. Liferay provides integration with LDAP. If the user base is not present, then we will end up creating all the accounts manually or provide users an ability to create their accounts If all the users (including non-logged in users) can access the same information then we will keep all the information on public pages but if we want certain information to be accessed by members only, then we might consider putting that information on the pages which can be accessed only after logging in If all the members of the portal can access the same information with same privileges then we will not need any special role in the portal. However, if a certain group or a set of users have more privileges over the other—like only content creators can create content—then we will have to create a role and provide the required permission to the role When we think of the security of the portal, we are thinking about users and their access, applications and access to those applications, and other security-related aspects of the portal. It is very important to think about the security before implementing the portal to prevent unauthorized and unauthenticated access to the portal and applications within the portal.

  (For more resources on iPhone, see here.) The application icon and essential interaction elements such as the Navigation Bar and Tab Bar are crucial for the success of our work. The user will be tapping the icon every time they go to use our app, and interact with our navigation elements throughout their entire experience in our application. If we want success, we must focus on making these components attractive and functional. Attention to detail and the presentation of these pieces will be key, and we'll need to produce our best work if we want to stand out in a sea of apps. Designing an application icon and preparing it for the user home screen It's often said that a book shouldn't be judged by its cover, but the harsh reality of mobile development is that an app is often judged by its icon. This rounded rectangle will appear on the home screen of every user, and it's important that we create something that is attractive and also a good indication as to what the user should expect after downloading our application. In this recipe, we'll create a strategy for successful app icon design. Getting ready Adobe Photoshop will be our primary tool in the design of our app icon. It may also be helpful to grab some paper and a pencil so that we can sketch out any concepts we may have before we begin working on our computer. How to do it... The application icon is a primary component of any work. Appearing in the App Store, on a user's home screen, in Spotlight searches, and more, it's an important part of our job. Let's take a look at several steps that will be useful in the creation of our app icon: We should start by with either a rough sketch or Photoshop mockup of our intended design. We should create this mock up at several sizes to help represent the different resolutions at which our icon will be viewed. After we've developed an idea that we believe is going to scale well, its time to sit down in Photoshop or Illustrator and begin work on our icon. At this point, we need to determine what size canvas we want to design our icon on. Apple requires that our icon be available at a variety of sizes, with a 512 by 512 pixel square currently being the largest required format, but we should be prepared in case this requirement changes in the future and design our icon accordingly. There are two different ways we can go about making our icon "future proof". We can go about designing the icon in a vector format using an application like Adobe Illustrator. Vector drawings will always be the best way to ensure that our icon will scale to any size, but they can be a bit more difficult to create. If we're more comfortable using a raster image manipulation program like Photoshop, it's best to create our icon at a resolution well above what we'll ever need for the App Store, starting with a canvas of 4096 by 4096 pixels square or greater. Such a large raster size will give us a piece of art that will print comfortably on sizes as large as 13 inches when printed at 300 DPI, while also easily scaling down to whatever size we need for the App Store. Once we've decided which format we're most comfortable with, its time to go about creating our icon. Once we've completed our icon, it is time to prepare it for inclusion into our application. This icon should then be named apple-touch-icon.png and placed inside of our application bundle. iOS will then automatically add the glare effect to the top half of the icon, as seen throughout the interface. The Info.plist is a file that allows us to customize a bunch of different application attributes. We'll learn how to use it to remove the icon gloss effect in an upcoming recipe titled Removing the app icon's gloss effect. After finishing our icon, we may also want to run a small focus group, much like we would in order to gain feedback on our user interface design.We can quickly set up a simple website with a form asking for opinions on our design or even email an image of the icon to friends and family in order to facilitate feedback. When looking to gather opinion on our icon, we want to better understand a user's first impression of our icon. For a good portion of purchase decisions, the icon may be the only bit of insight into our app that the user has before tapping the buy button. We want to make sure that on first impression, the typical user associates our icon with quality, simplicity, and value. If our icon looks amateur, users probably won't consider our application for purchase. How it works... Icon design is tough, primarily because we're required to design a small square that represents our application's purpose, quality, and value. It's truly a challenge to design something that works well at 512 pixels and 27 pixels. Let's take a look at how the steps above work together to create a good icon. Resolution flexibility is arguably the difficult part of icon design, as our work needs to look great at 512 pixels by 512 pixels and at 27 by 27 pixels. Small details that look great at a high resolution can really make an icon indecipherable when scaled down to the lowest resolution required: In the above screenshot, we can quickly see how an icon becomes less legible as it decreases in size. It's necessary to provide the icon to Apple in several different sizes, which can vary depending upon the iOS device we're developing our application for and the current operating system requirements from Apple. These file sizes have varied significantly throughout the life of iOS, so we should verify the current requirements in the iOS Development Center before their creation. Sebastiaan De With keeps an excellent Photoshop file for iOS icon design, complete with resolution requirements, which he updates every time Apple changes the icon requirements. We can find the file here at http://blog.cocoia.com/2010/iphone-4-icon-psd-file/ and it should reference it while designing a new icon. When building our icon, we should really take time to think about what our icon should look like and what users will think when they first set eyes on it in the App Store. This set process works because it systematically creates a piece of work that will be optimized for the various needs of iOS. There's more... It may take a bit of practice to get a firm grasp on what makes a great or poor icon. Here are a few helpful ideas, just in case we're struggling to develop an icon that we're happy with. Dropping the text We should always refrain from including a great deal of text in our app icon. Text tends to become illegible when scaled down to small resolutions such as 27 x 27, so it is often best to keep text out of our icon. If we absolutely must include text in our icon, we should use short words that are large in size and in a bold typeface. Great gradients From an art design perspective, we'll probably be including an artistic gradient in our icon to offer the illusion of brushed metal or progressive lighting. But choosing a strong color palate for a gradient can be difficult. Dezigner Folio has created a large library of fresh, modern gradients that they've offered up for free use in any project. For the entire library, feel free to visit their website at http://www.dezinerfolio.com/2007/05/03/ultimate-web-20-gradients-v30-release. If all else fails.... If we're having a rough time with icon design and all else fails, we can always hire a freelance artist or design firm to help out with the production of our application icon. A quick search of Google can help us find a multitude of artists who have become specialists in the field of icon design. Finding a talented designer can actually be quite affordable, with many freelance artists charging a hundred dollars or less for a high quality icon. As icons can be produced in Photoshop, local graphic designers or students can help out at affordable rates as well.  

  (For more resources on iPhone, see here.) Users have few expectations as to what a typical mobile application should feel like, there is often an expectation with regards to what a game should play like. Mobile gaming platforms have been popular since the Game Boy's rise to popularity in the early 90s, and users have an idea as to what games work well when on the go, and iOS games are expected to match or exceed these preconceived notions of what is possible. However, it isn't necessarily easy to produce a game on iOS, as the device presents one of the first touch screen mobile gaming experiences. There isn't much precedent as to what game genres and control styles work well. This can be beneficial for innovation, but can also lead to a great deal of heartache for any designer.   Planning your game around touch Unlike traditional mobile gaming platforms, we won't have physical buttons and a set interface blueprint to serve as a guide for our game. Mobile platforms such as the Game Boy or PlayStation Portable have a physical control pad and buttons that lend the user to an inherent understanding of the game on screen. The user can quickly pick up and play a game, because they know that there is a finite set of buttons that can control game mechanics. We're in a bit of a more difficult-to-manage scenario with iOS, as there is no control pad or face button to commonly dictate interaction on screen when in a game. Since we're on a touch screen device, we can create any interaction mechanic that we'd like, no matter how unorthodox the interface may be. This offers up an extraordinary opportunity for new gameplay experiences; however it does make our design work a bit more difficult to construct. In this recipe, we'll discuss how touch screens drastically alter the design and playability of our game. Designing a game around touch is never an easy task. Controls are difficult to implement, screen size is often limited, and we'll need to innovate on top of standard game play mechanics to provide a fun experience. While the operating system is only a few years old, there has been a significant evolution in gaming on the platform. Early games, such as Super Monkey Ball by Sega, were often ports of previous console games by big name publishers. Apple's affordable developer program allowed independent developers to step in and experiment on the platform, pushing forward intuitive new experiences like Doodle Jump, Mr. AahH!!, and Zen Bound. In recent years, the market has matured so that both traditional franchises and independent creative ventures can succeed. Getting ready To work on this recipe, it would be useful to have an iOS device along with a traditional gaming console in order to contrast the difference in mechanics between the two machines. How to do it... Depending on the type of game we plan on developing, there are a variety of strategies for success on the iPhone or iPad. However there are a few key attributes that will make any iOS game enjoyable: Remember that users will be using the iPhone or iPad as both a screen and a controller. Don't punish users for accidental interactions with the screen. Keep in mind that these are mobile devices. While a good portion of our interface will vary greatly depending upon the type of game we're looking to create, these three rules are universal and will benefit any iPhone or iPad game. With these guidelines in mind, we can move on and begin to draft up our controls and heads up display. How it works... The low level of entry and unique touch controls have helped iOS evolve into a platform where designers can reach outside of their comfort zone in an effort to release an innovative game on the platform. In step one, it's important to understand that traditionally, users and designers are trained toward expecting games to have an external controller that is used for manipulation of the game world. The screen is a separate device; either a television or portable LCD screen serves as a way to project the game. However on iOS, the screen and controller are one. Regardless as to whether users interact with our game through buttons on screen or by using a device hardware feature such as the accelerometer, it is a guarantee that the iPhone or iPad will be held in a hand while our game is being played. We should always keep this in mind when designing both our game and interface, as the user will need to comfortably hold the device while playing. If we use traditional controls through a software joystick or buttons, we should place these elements on screen in a manner that allows for the iPhone or iPad to be held comfortably while playing. Depending upon our game and orientation, we may find that specific parts of the play area are perfect for the placement of such controls while in other scenarios, we may want to give the user the ability to customize the placement of buttons to their preference. If we expect the user to tilt or shake the controller to interact with our game, we should take this into consideration as well. While it may sound somewhat clichéd, the game and its controls are one and the same. There is no separation and any design that assumes that we can quickly implement controls without taking this fact into consideration is destined to fail. Not being given a set control pad or buttons gives us the flexibility to be creative, but poor design can quickly confuse or frustrate users. In the next screenshot, we can see that Flight Control developer Firemint has used small exclamation point markers to offer up a hint as to where inbound aircraft will soon appear. This offers a quick heads up to the user who may have had their hands in a poor position. Flight Control - © 2009 Firemint Pty Inc. We expand upon this new type of game control with these new devices in step two in the previous section. Because the game controller and device screen are so intertwined, it's very likely that the user will come into accidental contact with the screen at some point. It's just too difficult to eliminate unintended taps, as the finger is an imprecise pointing device. We can assume that the user will make unintentional contact with the screen, and so we should do our best to design a play mechanic and interface that will not punish users for their mistake. For example, if we're building a racing game, it would be silly to place the pause button near the button used for acceleration, as misplaced fingers could often pause the game and frustrate users. How we go about verifying this in our application can vary based on the type of game we're looking to design, but we should be mindful to keep this philosophy salient in our work. The limited ability to include a help menu in our application will encourage users to pick up app controls through point and tap experimentation. If the user experiences frustration in their first few minutes of using the app, they'll be likely to give up on using our app. Finally in step three, we should focus on creating an interface that is mobile. While we're designing with a device that is nearly as powerful as home gaming consoles, we must keep in mind that our users will be using their iPhone or iPad when on the run. They may be playing our game on a train, or in the car, or when walking between classes, so it's important to remember that this is a slightly different game platform than what we've ever developed for before. Because users will be playing our app when on the go and users will be less likely to sit down and play our game for extended periods of time, we should prepare our gameplay and interface around this probability. Big buttons and forgiving controls are the best way to go about designing for a mobile interface. Larger targets on screen will make it easier for the user to perform an intended action, even when walking or riding around. If we'd like to take mobile usability a bit further, we could also implement modifiable controls into our app as well. Giving the user the ability to calibrate settings will enable our game to play well, regardless as to the situation they're currently in. In the next screenshot, we can see how Doodle Jump allows users to adjust the game's controls: Doodle Jump - © 2011 Lima Sky, LLC It's also important to note that we should design our interface for the rapid entry and exit that is common of iPhone users. People will be playing our game on buses, while waiting in line at a store, and in other scenarios where their time spent inside of the app may be no longer than one to two minutes. This will affect game play drastically, so it's important to test such game scenarios while we build our app. Because our first iOS game may be our first touch screen based game, or our first game in general, we should be cautious and conservative with our interface and game play mechanics. That's not to say that the creation of any game is easy; however these are significant pitfalls that could plague our work if we're not careful. There's more... While rare, there is the possibility that our iPhone can be used as a controller for a device other than itself. Using the iPhone as a controller…for the iPad Thanks to the Bluetooth integration that Apple has included in new iPhone, iPod touch, and iPad devices, it is possible to use our iPhone as a controller for iPad games, so long as the developer has produced games for both platforms and supports the feature. It isn't necessarily easy to design and develop a game that includes such a feature, but it is by no means impossible. If we're working on an expansive game, it is definitely possible to create an immersive experience where the iPhone is used to control action on the iPad.  

  (For more resources on iPhone, see here.)   Starting the application with a proper Default.png When an application loads for the first time, the user is presented with a variable duration of loading time. This period can change depending on the device processor or RAM, memory requirements of the application, current free memory available on the device, and any number of other variables. Ideally, the user will only be required to sit through this period for a brief moment. However, this duration can last up to several seconds in length if we're loading an image intensive app on an older device. Apple has designed a loading screen method that is required by each app, through the inclusion of a PNG file in our app bundle. In this recipe, we'll discuss two interface strategies for this loading period. Getting ready For this recipe, we should have a computer with Photoshop or another image creation tool. We should also have knowledge of the devices and orientation types that our application will support. How to do it... Loading times are an inherent problem with all types of software, regardless of platform. As hardware has increased in speed, these times have diminished, but they haven't become non-existent. Apple created a simple design fix for this problem, offering up a quick and easy way to load an image during the loading period. Here are quick, simple steps in order to create an image that will display during the loading period: We should start by designing up an art image measuring either 320 x 480 pixels or 320 x 460 pixels (or the equivalent Retina display double resolution size), containing the art piece which we would like the user to see during the loading screen. Next, we should then save and name that file Default.png. Finally, we should include that image in the resource bundle of our application project in XCode. If we're creating a web application, we can also include the image in our HTML code so that the image is displayed when the user launches the web app. To do this, we should name our file startup.png and place the following code in our HTML header: <link rel="apple-touch-startup-image" href="/startup.png"> iOS is designed to search the bundle for a PNG with this name, and then display it on load if it's available. Once we finish these steps, we have accomplished everything we need to do to have the image load on startup. When it comes to design styles and technique on what we should include on the image, there are two different strategies that we can take: The right way Apple's documentation on the Default.png is fairly clear. According to their design documents, this image should serve as a clean visual of what the application would look like with no pre-populated data. In essence, this provides the perception that the application has already loaded, but the user is just waiting for the data to populate. It's a subtle way to trick the user into thinking our app loads quicker than it actually does. This trick works because it typically takes the brain about 2-4 seconds to see an image on screen, process the layout of what is before them, and then make a decision. Because the loading process for an application is relatively short, typically under three seconds, presenting an overlay of the interface as the Default.png loading image allows the brain to use this time to process what is about to be presented on screen. Phone - © 2007-2011 Apple Inc. As shown above, Phone, Messages, and Photos all load preview images with their Default.png displays, which offer the perception that the application loads very quickly. By preparing the user for the app during the Default.png load image period, the user will subconsciously perceive that our application loads faster than it actually does. The wrong, but possibly preferable way While we're supposed to use the loading image to prepare the user for our app, we may want this time to serve another purpose, such as a way to advertise our development team or Twitter account. It's an important and powerful moment for application branding, so we should feel free to use this moment as a way to build brand equity through use of a logo and appropriate styling. There is no set rule that says we can't use the Default.png as an advertisement of sorts, and many applications succeed using this strategy. We'll need to include a Default.png in the application package, to give our app something to display before loading has concluded. Depending on our application type and loading period, we should be able to include a screen that fits into one of these two methods with ease. How it works... Apple has designed iOS so that it is easy to present a loading screen to the user—we only need to create a PNG image, name it Default, and include it inside of our application bundle. The operating system will do the rest for us. Because this predetermined method works so well, we can instead focus on optimizing the image to best fit into our application. It's important to remember that the Default image is the first thing that the user will ever see in our app, and we should take considerable care in the creation of the art. Attention to detail with such seemingly minute application attributes is what sets outstanding applications apart. For some situations, creating an image that looks like similar to the first screen after launch will be ideal; as it will offer the perception that our application loads quicker than it actually does. This will increase user appreciation and enjoyment of our app. In other situations, it may be desirable to go with this splash screen approach instead of the prescribed approach of faking application load. For applications where loading takes a considerable period of time, usually anything over four seconds, it is difficult to use the load to ease users into our app like Apple does with Mail, Messages, or Phone. The pause becomes so long that the user instead believes that the application has broken. So in such situations, these banner loading Default.png images may provide a better alternative, offering up a way for the user to know that they have indeed loaded the correct application, but that it will still be several seconds before they're able to interact with the initial view. Regardless of what method we choose, it will be necessary to include a Default.png in with the project. With a bit of work and consideration, we can create something that will win the hearts of our user base. There's more... Now that we've learned more about different styles of Default images, we can put a bit of extra effort into going the extra mile with the image as well. Here are a few tips on how to produce a great Default.png. We can retina optimize our Default.png too Like any other art piece, we can include a Retina display specific graphic inside our application. By adding the standard @2x modifier to the end of the image, iOS will know to pull this image instead when running a higher resolution device. As the Default.png is the first image presented to the user, we should take extra effort to show that we're dedicated to a full retina optimized experience. Prepare for multiple orientations On the iPhone, we're limited to only one Default.png orientation requirement, as applications tend to be optimized for one orientation and we can create the Default image to account for the prominent orientation. However, on the iPad, each application should be designed for optimal use in either orientation. This requires us to create two Default images, one for the app launching in portrait and another for if the app launches in landscape. Apple has created an easy system for the simple creation of such different images. We only need to create the images and add a simple –Portrait or –Landscape modifier (for example, Default-Portrait.png) in order to launch the appropriate view.   Planning our application UI for a first impression In the real world, we spend a good deal of time preparing for first impressions. We tuck our shirts in, spend time making sure our hair looks perfect, and iron our shirts so that they're wrinkle free. We do this because it's a common understanding that others will greatly have their feelings toward us determined on the basis of how we look or talk during our first meeting. If we don't impress them off the bat, they'll never be willing to warm up to us. Mobile application development falls under the same sense of unspoken understanding. If our application isn't easy to manage or understand in the first 30 seconds, users will have no qualms over closing our work and deleting it off their device. Are the colors attractive? Is information easy to access? Do they seem to know what the correct next step is? These are all important questions that the user will subconsciously answer during their first several minutes inside our work. In this recipe, we'll discuss a couple of design decisions that we can make, in order to impress our users early. Getting ready Little is needed for this recipe. Ideally, the implementation of this recipe will take place throughout the course of development, as we fine tune along the way. How to do it... The Default.png image is the first visual that every user will see when they check out our app, but it isn't necessarily the first visual that their brain will take a good deal of time processing. That honor will fall on our actual application, once loaded in full glory for all eyes to behold. It's a somewhat magical moment, as our work is first presented to the audience. Like the opening line of a play, first chapter of a book, the front door to a house, the first few minutes of a game, this is an important moment in the user's determination of what they think about our app. So how do we present our application with its best foot forward? Here are a couple of simple tips, to help users quickly feel at home inside of our application: Use simple, clean In-App icons to help signify key features: When selecting icons to fall inside of Tab Bar cells or Navigation buttons, it's important to ensure that our icon use falls in line with expectations found in other applications. The magnifying glass represents search, a star presumes favorites or top performers, three dots represent that the tab contains multiple options, and a square with a pencil infers that the button composes a new email. Start by giving users a push in the right direction: Feel free to offer up a friendly push to the user from the get go. If we make the first step clear, the subsequent steps may become a bit more obvious, as shown in the following screenshot from Grades by Tapity: Grades - © Tapity Hold back sound, flashy animation, or bright colors until the user has had the chance to settle in. Offer content early, if only a little taste of what is to come. How it works... Creating an intuitive application interface from the first second a user opens our app is an art, which requires that we shape our app carefully overtime. As we add new features, create new art, or conceive new ways to present data on screen, we should always be thinking about what a new user will think upon first presentation of our app. For Step 1, Apple routinely updates the Mobile Human Interface Guidelines , https://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/MobileHIG/Introduction/Introduction.html, with suggestions on how to use icons that come built into the iOS SDK . These guidelines account for a limited quantity of icons and uses, which makes it a bit difficult to gain a good grasp of how we should truly utilize such pieces in our app. While it would be impossible to create an exhaustive list of general shapes and their associated meaning on iOS, the best we can do is make ourselves familiar with as many apps as we possibly can in order to best understand how others have paved the road of user expectations. In Step 2, we took a look at Grades by Jeremy Olsen. The application allows users to manage test scores and class grades, with an exceptional level of open-ended opportunity. No matter how complex or simple a class's grade scale may be, the application handles the data with ease. The application makes such scalability easy for the user by using a simple contextual clue on initial launch. By offering direction on how to start tracking information for a class, the user is essentially given a tutorial without even realizing that they're being taught. There is no confusion as to what the first step is, and the user can jump right in and start keeping track of their grades. For Step three, if we are in the mood, or feel as if it's necessary to make our application stand out through a good deal of noise, eccentric color, or excessive animation, that's perfectly fine. Each application has a different art strategy and depending on our target audience, these elements may very much make sense in our work. However, we should be hesitant to use such vivid visuals or loud sounds during the user's introduction to our app. While the user may be in our target audience and enjoy our app otherwise, such sudden extreme sense stimulation may be off-putting. Instead, we should slowly walk our users into the application and give them a chance to prepare for any noise or bright lights that we may throw their way. This way, the user is expecting whatever we decide to present. For example, if we offer loud noises right after the initial launch and our user is sitting in a quiet auditorium, the successive embarrassing situation may turn the user away from our application, just because we presented them with an unexpected bout of displeasure. By working the user into our loud, colorful, flashy application, we'll be less likely to scare away potential long-term users in the first five minute of using our app. With regards to Step 3, if our application is a content heavy application, such as a social network or application that features extensive listings of local sport scores, we may be inclined to encourage users to sign up for our service before we offer the meat and potatoes of our app. Most designers are confident that their content is so valuable, users will jump through whatever hoops necessary in order to gain access. However, the typical user is an impatient soul, unlikely to fill out forms in order to gain access to an app's walled garden. Instead they'll download our app, see the frictional barrier in front of the content, and decide that they're not that interested. By offering a quick glimpse, we hold some hope in convincing the user that our content is worth going through the sign up process. Service applications such as Instagram and Twitter do a great job at this, offering a handful of images or text entries before asking the user to sign up. These quick entries give an example of the wealth of content laying behind the apparent barrier of a sign up form. Through these quick previews, the user can gain an idea as to whether they'll enjoy the service or not. By using a preview method such as this, users are able to gauge interest before the sign up, saving everyone's valuable time. Finally, we know that every iOS device user is familiar with Apple's bundled applications, as they are the only applications that come pre-installed and as such, are the only applications that every user is likely to have used. We should look here for inspiration, as Apple offers a good deal of guidance with their work. When placing an icon on our Tab Bar, ask yourself if every user will instantly know the tabs function based on the imagery. If we have doubts, there is probably a better alternative icon. In many respects, this recipe isn't so much a one-time action like many others found throughout this book. Instead, it's a design philosophy which we will fine tune as we create more applications for the iPhone or iPad. There's more... Tutorials and help menus were a somewhat taboo topic during the early days of the App Store, with Apple holding a hard stance that apps requiring such a menu were too complex for the mobile platform. Times are changing a bit, with Apple themselves offering help menus in complex apps like Garageband or iMovie. Here's a tip on how to best offer support inside of our app. Lend a helping hand While most early apps were capable of success without a help menu, many new apps have become much more complex and require such a way to teach the user about app features. If we want to provide help for our users, we have two choices. One thing we could do is create a specific help view; we could do something like provide a table of topics that the user can tap upon in order to learn more about. This allows us to dive in-depth into a variety of topics, with as much detail as we feel is required. We could also provide a tutorial through on screen overlays, where tapping a help button presents short tips on screen with insight into different app features. This method works well because we can directly point at an interface element and tell the user what its purpose is. However, because we're overlaying such information on top of the interface, we must be brief when using this choice. Our app may be simple and self-explanatory enough, that we won't need one of these two methods in order to provide a help menu. However, if we think that we need to lend a hand, either of these two routes would work well.  

(For more resources on this topic, see here.) Introduction This article focuses on yet another very exciting topic of the HTML5 canvas, images and videos. Along with providing basic functionality for positioning, sizing, and cropping images and videos, the HTML5 canvas API also allows us to access and modify the color and transparency of each pixel for both mediums. Let's get started! Drawing an image Let's jump right in by drawing a simple image. In this recipe, we'll learn how to load an image and draw it somewhere on the canvas. How to do it... Follow these steps to draw an image in the center of the canvas: Define the canvas context: window.onload = function(){    var canvas = document.getElementById("myCanvas");    var context = canvas.getContext("2d"); Create an image object, set the onload property to a function that draws the image, and then set the source of the image:     var imageObj = new Image();    imageObj.onload = function(){        var destX = canvas.width / 2 - this.width / 2;        var destY = canvas.height / 2 - this.height / 2;                context.drawImage(this, destX, destY);    };    imageObj.src = "jet_300x214.jpg";}; Embed the canvas tag inside the body of the HTML document: <canvas id="myCanvas" width="600" height="250" style="border:1px solid black;"></canvas> How it works... To draw an image, we first need to create an image object using new Image(). Notice that we've set the onload property of the image object before defining the source of the image. It's good practice to define what we want to do with the image when it loads before setting its source. Theoretically, if we were to define the source of the image before we define the onload property; the image could possibly load before the definition is complete (although, it's very unlikely). The key method in this recipe is the drawImage() method: context.drawImage(imageObj,destX,destY); Where imageObj is the image object, and destX and destY is where we want to position the image. There's more... In addition to defining an image position with destX and destY, we can also add two additional parameters, destWidth and destHeight to define the size of our image: context.drawImage(imageObj,destX,destY,destWidth,destHeight); For the most part, it's a good idea to stay away from resizing an image with the drawImage() method, simply because the quality of the scaled image will be noticeably reduced, similar to the result when we resize an image with the width and height properties of an HTML image element. If image quality is something you're concerned about (why on earth wouldn't you be?), it's usually best to work with thumbnail images alongside bigger images if you're creating an application that needs scaled images. If, on the other hand, your application dynamically shrinks and expands images, using the drawImage() method with destWidth and destHeight to scale images is a perfectly acceptable approach. Cropping an image In this recipe, we'll crop out a section of an image and then draw the result onto the canvas. How to do it... Follow these steps to crop out a section of an image and draw the result onto the canvas. Define the canvas context: window.onload = function(){    var canvas = document.getElementById("myCanvas");    var context = canvas.getContext("2d"); Create an image object, set the onload property to a function that crops the image, and then set the source of the image:     var imageObj = new Image();    imageObj.onload = function(){    // source rectangular area        var sourceX = 550;        var sourceY = 300;        var sourceWidth = 300;        var sourceHeight = 214;            // destination image size and position        var destWidth = sourceWidth;        var destHeight = sourceHeight;        var destX = canvas.width / 2 - destWidth / 2;        var destY = canvas.height / 2 - destHeight / 2;                context.drawImage(this, sourceX, sourceY, sourceWidth, sourceHeight, destX, destY, destWidth, destHeight);    };    imageObj.src = "jet_1000x714.jpg";}; Embed the canvas tag inside the body of the HTML document: <canvas id="myCanvas" width="600" height="250" style="border:1px solid black;"></canvas> How it works... In the last recipe, we discussed two different ways that we can use the drawImage() method to draw images on the canvas. In the first case, we can pass an image object and a position to simply draw an image at the given position. In the second case, we can pass an image object, a position, and a size to draw an image at the given position with the given size. Additionally, we can also add six more parameters to the drawImage() method if we wanted to crop an image: Context.drawImage(imageObj,sourceX,sourceY,sourceWidth, sourceHight, sourceHeight,sourceHeight, destX, destY, destWidth, destHeight); Take a look at the following diagram: As you can see, sourceX and sourceY refer to the top-left corner of the cropped region in the source image. sourceWidth and sourceHeight refer to the width and height of the cropped image from the source. destX and destY refer to the position of the cropped image on the canvas, and destWidth and destHeight refer to the width and height of the resulting cropped image. If you don't intend to scale a cropped image, then destWidth equals sourceWidth and destHeight equals sourceHeight. Copying and pasting sections of the canvas In this recipe, we'll cover yet another interesting usage of the drawImage() method—copying sections of the canvas. First, we'll draw a spade in the center of the canvas, then we'll copy the right side of the spade and then paste it to the left, and then we'll copy the left side of the spade and then paste it to the right. How to do it... Follow these steps to draw a spade in the center of the canvas and then copy-and-paste sections of the shape back onto the canvas: Define the canvas context: window.onload = function(){    // drawing canvas and context    var canvas = document.getElementById("myCanvas");    var context = canvas.getContext("2d"); Draw a spade in the center of the canvas using the drawSpade() function:     // draw spade    var spadeX = canvas.width / 2;    var spadeY = 20;    var spadeWidth = 140;    var spadeHeight = 200;        // draw spade in center of canvas    drawSpade(context, spadeX, spadeY, spadeWidth, spadeHeight); Copy the right half of the spade and then paste it on the canvas to the left of the spade using the drawImage() method:     context.drawImage(    canvas,             spadeX,         // source x    spadeY,         // source y    spadeWidth / 2,     // source width    spadeHeight,       // source height    spadeX - spadeWidth,  // dest x    spadeY,         // dest y    spadeWidth / 2,     // dest width    spadeHeight        // dest height  ); Copy the left half of the spade and then paste it on the canvas to the right of the spade using the drawImage() method:     context.drawImage(    canvas,     spadeX - spadeWidth / 2,  // source x       spadeY,           // source y    spadeWidth / 2,       // source width    spadeHeight,         // source height    spadeX + spadeWidth / 2,   // dest x    spadeY,           // dest y    spadeWidth / 2,       // dest width    spadeHeight          // dest height  );}; Embed the canvas inside the body of the HTML document: <canvas id="myCanvas" width="600" height="250" style="border:1px solid black;"></canvas> How it works... To copy a section of the canvas, we can pass the canvas object to the drawImage() method instead of an image object: Context.drawImage(canvas,sourceX,sourceY,sourceWidth, sourceHight, sourceHeight,sourceHeight, destX, destY, destWidth, destHeight); As we'll see in the next recipe, not only can we copy sections of an image or a canvas with drawImage(), we can also copy sections of HTML5 video. Working with video Although the HTML5 canvas API doesn't provide a direct method for drawing videos on the canvas like it does for images, we can certainly work with videos by capturing frames from a hidden video tag and then copying them onto the canvas with a loop. Getting ready... Before we get started, let's talk about the supported HTML5 video formats for each browser. At the time of writing, the video format war continues to rage on, in which all of the major browsers—Chrome, Firefox, Opera, Safari, and IE—continue to drop and add support for different video formats. To make things worse, each time a major browser adds or drops support for a particular video format, developers have to once again re-formulate the minimal set of video formats that's required for their applications to work across all browsers. At the time of writing, the three major video formats are Ogg Theora, H.264, and WebM. For the video recipes in this article, we'll be using a combination of Ogg Theora and H.264. When working with video, it's strongly advised that you do a search online to see what the current status is for video support as it is a subject to change at any moment. There's more! Once you've decided which video formats to support, you'll probably need a video format converter to convert the video file that you have on hand to other video formats. One great option for converting video formats is the Miro Video Converter, which supports video format conversions for just about any video format including Ogg Theora, H.264, or WebM formats. Miro Video Converter is probably the most common video converter available at the time of writing, although you can certainly use any other video format converter of your liking. You can download Miro Video Converter from: http://www.mirovideoconverter.com/. How to do it... Follow these steps to draw a video onto the canvas: Create a cross-browser method that requests an animation frame: window.requestAnimFrame = (function(callback){    return window.requestAnimationFrame ||    window.webkitRequestAnimationFrame ||    window.mozRequestAnimationFrame ||    window.oRequestAnimationFrame ||    window.msRequestAnimationFrame ||    function(callback){        window.setTimeout(callback, 1000 / 60);    };})(); Define the drawFrame() function which copies the current video frame, pastes it onto the canvas using the drawImage() method, and then requests a new animation frame to draw the next frame: function drawFrame(context, video){    context.drawImage(video, 0, 0);    requestAnimFrame(function(){        drawFrame(context, video);    });} Define the canvas context, get the video tag, and draw the first video frame: window.onload = function(){    var canvas = document.getElementById("myCanvas");    var context = canvas.getContext("2d");    var video = document.getElementById("myVideo");    drawFrame(context, video);}; Embed the canvas and the video tag inside the body of the HTML document: <video id="myVideo" autoplay="true" loop="true" style="display:none;">    <source src="BigBuckBunny_640x360.ogv" type="video/ogg"/><source src="BigBuckBunny_640x360.mp4" type="video/mp4"/></video><canvas id="myCanvas" width="600" height="360" style="border:1px solid black;"></canvas> How it works... To draw a video on an HTML5 canvas, we first need to embed a hidden video tag in the HTML document. In this recipe, and in future video recipes, I've used the Ogg Theora and H.264 (mp4) video formats. Next, when the page loads, we can use our cross-browser requestAnimFrame() method to capture the video frames as fast as the browser will allow and then draw them onto the canvas. Getting image data Now that we know how to draw images and videos, let's try accessing the image data to see what kind of properties we can play with. WARNING: This recipe must run on a web server due to security constraints with the getImageData() method. Getting ready... Before we get started working with image data, it's important that we cover canvas security and the RGBA color space. So why is canvas security important with respect to accessing image data? Simply put, in order to access image data, we need to use the getImateData() method of the canvas context which will throw a SECURITY_ERR exception if we try accessing image data from an image residing on a non-web server file system, or if we try accessing image data from an image on a different domain. In other words, if you're going to try out these demos for yourself, they won't work if your files reside on your local file system. You'll need to run the rest of the recipes in this article on a web server.Next, since pixel manipulation is all about altering the RGB values of pixels, we should probably cover the RGB color model and the RGBA color space while we're at it. RGB represents the red, green, and blue components of a pixel's color. Each component is an integer between 0 and 255, where 0 represents no color and 255 represents full color. RGB values are often times represented as follows: rgb(red,green,blue) Here are some common color values represented with the RGB color model: rgb(0,0,0) = blackrgb(255,255,255) = whitergb(255,0,0) = redrgb(0,255,0) = greenrgb(0,0,255) = bluergb(255,255,0) = yellowrgb(255,0,255) = magentargb(0,255,255) = cyan In addition to RGB, pixels can also have an alpha channel which refers to its opacity. An alpha channel of 0 is a fully transparent pixel, and an alpha channel of 255 is a fully opaque pixel. RGBA color space simply refers to the RGB color model (RGB) plus the alpha channel (A). Be careful not to confuse the alpha channel range of HTML5 canvas pixels, which are integers 0 to 255, and the alpha channel range of CSS colors, which are decimals 0.0 to 1.0. How to do it... Follow these steps to write out the image data properties of an image: Define a canvas context: window.onload = function(){    var canvas = document.getElementById("myCanvas");    var context = canvas.getContext("2d"); Create an image object, set the onload property to a function which draws the image:     var imageObj = new Image();    imageObj.onload = function(){        var sourceWidth = this.width;        var sourceHeight = this.height;        var destX = canvas.width / 2 - sourceWidth / 2;        var destY = canvas.height / 2 - sourceHeight / 2;        var sourceX = destX;        var sourceY = destY;            // draw image on canvas        context.drawImage(this, destX, destY); Get the image data, write out its properties, and then set the source of the image object outside of the onload definition:     // get image data from the rectangular area     // iof the canvas containing the image        var imageData = context.getImageData(sourceX, sourceY, sourceWidth, sourceHeight);        var data = imageData.data;        // write out the image data properties        var str = "width=" + imageData.width + ", height=" + imageData.height + ", data length=" + data.length;        context.font = "12pt Calibri";        context.fillText(str, 4, 14);    };    imageObj.src = "jet_300x214.jpg";}; Embed the canvas tag into the body of the HTML document: <canvas id="myCanvas" width="600" height="250" style="border:1px solid black;"></canvas> How it works... The idea behind this recipe is to draw an image, get its image data, and then write out the image data properties to the screen. As you can see from the preceding code, we can get the image data using the getImageData() method of the canvas context: context.getImageData(sourceX,sourceY,sourceWidth,sourceHeight); Notice that the getImageData() method only works with the canvas context and not the image object itself. As a result, in order to get image data, we must first draw an image onto the canvas and then use getImageData() method of the canvas context. The ImageData object contains three properties: width, height, and data. As you can see from the screenshot in the beginning of this recipe, our ImageData object contains a width property of 300, a height property of 214, and a data property which is an array of pixel information, which in this case has a length of 256,800 elements. The key to the ImageData object, in all honesty, is the data property. The data property contains the RGBA information for each pixel in our image. Since our image is made up of 300 * 214 = 64,200 pixels, the length of this array is 4 * 64,200 = 256,800 elements. Introduction to pixel manipulation: inverting image colors Now that we know how to access image data, including the RGBA for every pixel in an image or video, our next step is to explore the possibilities of pixel manipulation. In this recipe, we'll invert the colors of an image by inverting the color of each pixel. WARNING: This recipe must be run on a web server due to security constraints with the getImageData() method. How to do it... Follow these steps to invert the colors of an image: Define the canvas context: window.onload = function(){    var canvas = document.getElementById("myCanvas");    var context = canvas.getContext("2d"); Create an image object and set the onload property to a function that draws the image and gets the image data:     var imageObj = new Image();    imageObj.onload = function(){        var sourceWidth = this.width;        var sourceHeight = this.height;        var sourceX = canvas.width / 2 - sourceWidth / 2;        var sourceY = canvas.height / 2 - sourceHeight / 2;        var destX = sourceX;        var destY = sourceY;                context.drawImage(this, destX, destY);                var imageData = context.getImageData(sourceX, sourceY, sourceWidth, sourceHeight);        var data = imageData.data; Loop through all of the pixels in the image and invert the colors:         for (var i = 0; i < data.length; i += 4) {            data[i] = 255 - data[i]; // red            data[i + 1] = 255 - data[i + 1]; // green            data[i + 2] = 255 - data[i + 2]; // blue            // i+3 is alpha (the fourth element)        } Overwrite the original image with the manipulated image, and then set the source of the image outside of the onload definition:         // overwrite original image with        // new image data        context.putImageData(imageData, destX, destY);    };    imageObj.src = "jet_300x214.jpg";}; Embed the canvas tag into the body of the HTML document: <canvas id="myCanvas" width="600" height="250" style="border:1px solid black;"></canvas> How it works... To invert the color of an image using HTML5 canvas, we can simply loop through all of the pixels in an image and then invert each pixel using a color inverting algorithm. Don't worry it's easier than it sounds. To invert a pixel's color, we can invert each of its RGB components by subtracting each value from 255 as follows: data[i  ] = 255 - data[i  ]; // reddata[i+1] = 255 - data[i+1]; // greendata[i+2] = 255 - data[i+2]; // blue Once the pixels have been updated, we can redraw the image using the putImageData() method of the canvas context: context.putImageData(imageData, destX, destY);  This method basically allows us to draw an image using image data instead of a source image with the drawImage() method.

(For more resources on this topic, see here.) Introduction This article is designed to demonstrate the fundamental capabilities of the HTML5 canvas by providing a series of progressively complex tasks. The HTML5 canvas API provides the basic tools necessary to draw and style different types of sub paths including lines, arcs, Quadratic curves, and Bezier curves, as well as a means for creating paths by connecting sub paths. The API also provides great support for text drawing with several styling properties. Let's get started! Drawing a line When learning how to draw with the HTML5 canvas for the fi rst time, most people are interested in drawing the most basic and rudimentary element of the canvas. This recipe will show you how to do just that by drawing a simple straight line. How to do it... Follow these steps to draw a diagonal line: Define a 2D canvas context and set the line style: window.onload = function(){  // get the canvas DOM element by its ID     var canvas = document.getElementById("myCanvas");  // declare a 2-d context using the getContext() method of the     // canvas object     var context = canvas.getContext("2d");  // set the line width to 10 pixels     context.lineWidth = 10;  // set the line color to blue     context.strokeStyle = "blue"; Position the canvas context and draw the line:  // position the drawing cursor    context.moveTo(50, canvas.height - 50); // draw the line    context.lineTo(canvas.width - 50, 50); // make the line visible with the stroke color    context.stroke(); }; Embed the canvas tag inside the body of the HTML document: <canvas id="myCanvas" width="600" height="250" style="border:1pxsolid black;"></canvas> How it works... As you can see from the preceding code, we need to wait for the page to load before trying to access the canvas tag by its ID. We can accomplish this with the window.onload initializer. Once the page loads, we can access the canvas DOM element with document. getElementById() and we can define a 2D canvas context by passing 2d into the getContext() method of the canvas object. We can also define 3D contexts by passing in other contexts such as webgl, experimental-webgl, and others. When drawing a particular element, such as a path, sub path, or shape, it's important to understand that styles can be set at any time, either before or after the element is drawn, but that the style must be applied immediately after the element is drawn for it to take effect, We can set the width of our line with the lineWidth property, and we can set the line color with the strokeStyle property. Think of this behavior like the steps that we would take if we were to draw something onto a piece of paper. Before we started to draw, we would choose a colored marker (strokeStyle) with a certain tip thickness (lineWidth). Now that we have our marker in hand, so to speak, we can position it onto the canvas using the moveTo() method: context.moveTo(x,y); Think of the canvas context as a drawing cursor. The moveTo() method creates a new sub path for the given point. The coordinates in the top-left corner of the canvas are (0,0), and the coordinates in the bottom-right corner are (canvas width, canvas height). Once we have positioned our drawing cursor, we can draw the line using the lineTo() method by defi ning the coordinates of the line's end point: context.lineTo(x,y); Finally, to make the line visible, we can use the stroke() method. Unless, otherwise specified, the default stroke color is black.To summarize, here's the typical drawing procedure we should follow when drawing lines with the HTML5 canvas API: Style your line (like choosing a colored marker with a specific tip thickness). Position the canvas context using moveTo() (like placing the marker onto a piece of paper). Draw the line with lineTo(). Make the line visible using stroke(). There's more... HTML5 canvas lines can also have one of three varying line caps, including butt, round, and square. The line cap style can be set using the lineCap property of the canvas context. Unless otherwise specified, the line cap style is defaulted to butt. The following diagram shows three lines, each with varying line cap styles. The top line is using the default butt line cap, the middle line is using the round line cap, and the bottom line is using a square line cap: Notice that the middle and bottom lines are slightly longer than the top line, even though all of the line widths are equal. This is because the round line cap and the square line cap increase the length of a line by an amount equal to the width of the line. For example, if our line is 200 px long and 10 px wide, and we use a round or square line cap style, the resulting line will be 210 px long because each cap adds 5 px to the line length. Drawing an arc When drawing with the HTML5 canvas, it's sometimes necessary to draw perfect arcs. If you're interested in drawing happy rainbows, smiley faces, or diagrams, this recipe would be a good start for your endeavor. How to do it... Follow these steps to draw a simple arc: Define a 2D canvas context and set the arc style: window.onload = function(){    var canvas = document.getElementById("myCanvas");    var context = canvas.getContext("2d");    context.lineWidth = 15;    context.strokeStyle = "black"; // line color Draw the arc: context.arc(canvas.width / 2, canvas.height / 2 + 40, 80, 1.1 *Math.PI, 1.9 * Math.PI, false);context.stroke();}; Embed the canvas tag inside the body of the HTML document: <canvas id="myCanvas" width="600" height="250" style="border:1pxsolid black;"></canvas> How it works... We can create an HTML5 arc with the arc() method which is defined by a section of the circumference of an imaginary circle. Take a look at the following diagram: The imaginary circle is defi ned by a center point and a radius. The circumference section is defi ned by a starting angle, an ending angle, and whether or not the arc is drawn counter-clockwise: context.arc(centerX,centerY, radius, startingAngle,            endingAngle,counterclockwise); Notice that the angles start with 0p at the right of the circle and move clockwise to 3p/2, p, p/2, and then back to 0. For this recipe, we've used 1.1p as the starting angle and 1.9p as the ending angle. This means that the starting angle is just slightly above center on the left side of the imaginary circle, and the ending angle is just slightly above center on the right side of the imaginary circle. There's more... The values for the starting angle and the ending angle do not necessarily have to lie within 0p and 2p. In fact, the starting angle and ending angle can be any real number because the angles can overlap themselves as they travel around the circle. For example, let's say that we defi ne our starting angle as 3p. This is equivalent to one full revolution around the circle (2p) and another half revolution around the circle (1p). In other words, 3p is equivalent to 1p. As another example, - 3p is also equivalent to 1p because the angle travels one and a half revolutions counter-clockwise around the circle, ending up at 1p.Another method for creating arcs with the HTML5 canvas is to make use of the arcTo() method. The resulting arc from the arcTo() method is defi ned by the context point, a control point, an ending point, and a radius: context.arcTo(controlPointX1, controlPointY1, endingPointX,              endingPointY, radius); Unlike the arc() method, which positions an arc by its center point, the arcTo() method is dependent on the context point, similar to the lineTo() method. The arcTo() method is most commonly used when creating rounded corners for paths or shapes. Drawing a Quadratic curve In this recipe, we'll learn how to draw a Quadratic curve. Quadratic curves provide much more flexibility and natural curvatures compared to its cousin, the arc, and are an excellent tool for creating custom shapes. How to do it... Follow these steps to draw a Quadratic curve: Define a 2D canvas context and set the curve style: window.onload = function(){    var canvas = document.getElementById("myCanvas");    var context = canvas.getContext("2d");    context.lineWidth = 10;    context.strokeStyle = "black"; // line color Position the canvas context and draw the Quadratic curve: context.moveTo(100, canvas.height - 50);    context.quadraticCurveTo(canvas.width / 2, -50, canvas.width- 100, canvas.height - 50);    context.stroke();}; Embed the canvas tag inside the body of the HTML document: <canvas id="myCanvas" width="600" height="250" style="border:1pxsolid black;"></canvas> How it works... HTML5 Quadratic curves are defined by the context point, a control point, and an ending point: context.quadraticCurveTo(controlX, controlY, endingPointX,      endingPointY); Take a look at the following diagram: The curvature of a Quadratic curve is defined by three characteristic tangents. The first part of the curve is tangential to an imaginary line that starts with the context point and ends with the control point. The peak of the curve is tangential to an imaginary line that starts with midpoint 1 and ends with midpoint 2. Finally, the last part of the curve is tangential to an imaginary line that starts with the control point and ends with the ending point. Drawing a Bezier curve If Quadratic curves don't meet your needs, the Bezier curve might do the trick. Also known as cubic curves, the Bezier curve is the most advanced curvature available with the HTML5 canvas API. How to do it... Follow these steps to draw an arbitrary Bezier curve: Define a 2D canvas context and set the curve style: window.onload = function(){    var canvas = document.getElementById("myCanvas");    var context = canvas.getContext("2d");    context.lineWidth = 10;    context.strokeStyle = "black"; // line color    context.moveTo(180, 130); Position the canvas context and draw the Bezier curve: context.bezierCurveTo(150, 10, 420, 10, 420, 180);   context.stroke();}; Embed the canvas tag inside the body of the HTML document: <canvas id="myCanvas" width="600" height="250" style="border:1pxsolid black;"></canvas> How it works... HTML5 canvas Bezier curves are defined by the context point, two control points, and an ending point. The additional control point gives us much more control over its curvature compared to Quadratic curves: context.bezierCurveTo(controlPointX1, controlPointY1,    controlPointX2, controlPointY2,    endingPointX, endingPointY); Take a look at the following diagram: Unlike Quadratic curves, which are defined by three characteristic tangents, the Bezier curve is defined by five characteristic tangents. The first part of the curve is tangential to an imaginary line that starts with the context point and ends with the fi rst control point. The next part of the curve is tangential to the imaginary line that starts with midpoint 1 and ends with midpoint 3. The peak of the curve is tangential to the imaginary line that starts with midpoint 2 and ends with midpoint 4. The fourth part of the curve is tangential to the imaginary line that starts with midpoint 3 and ends with midpoint 5. Finally, the last part of the curve is tangential to the imaginary line that starts with the second control point and ends with the ending point.

(For more resources on WordPress, see here.) Making it easy for people to follow you Take a look at some of the most popular bloggers in the world, and compare their sites. You will notice that, without fail, they all make it really easy to follow them by RSS and Twitter and more often than not Facebook or LinkedIn. Look at the copyblogger home page in the following screenshot: (Move the mouse over the image to enlarge.) Notice how prominently displayed at the top right of the page is a list of large visually recognizable buttons that allow visitors to subscribe to their newsletter, RSS feed, follow them on Twitter, or like them on Facebook. Anyone who is interested in learning about online marketing can, at the click of a button, access all the latest content provided by copyblogger. While gaining a follower on Twitter doesn't necessarily bring revenue directly, each and every follower is a potential customer, or someone who will potentially recommend your blog to a potential customer. This meets the hugely important business objective of increasing reach for the site and its content—something you must also do if you are to have any hope of penetrating the market. WordPress.com has an RSS link widget that can add a nice orange RSS icon to any one of the widget areas in your theme. This is unfortunately not really suitable for our needs as we need a row of icons and links to a number of different things. In order to get a nice row of icons, we will need to write a bit of HTML code and add it to a custom Text widget. WordPress.org users can simply install something like the Subscribe/ Connect/Follow widget, available at http://wordpress.org/ extend/plugins/subscribe-connect-follow-widget. Creating a custom "Follow me" widget Before you begin adding the links, you will need to find and download a set of icons. A search on Google for "social network icons" should bring up some useable results. Remember to make sure that you do not infringe on any copyright conditions. Only use icons that are freely available. Once you have the icons you want (preferably large, instantly recognizable ones), upload them to your media folder on your site so that they can be referenced in the links. For example, the following screenshot shows the Upload New Media page being used to upload an RSS icon: Note in particular that the icon has been given a File URL. It is this URL you will use to reference this icon in the HTML that follows. Once all the requisite icon files are uploaded to your media library, you are ready to drag a new Text widget to the top right of your page and copy and paste the following HTML into it: <ul><li style="display:inline;"><a href="path_to_email"><img src="email_icon_file_url" alt="contact me via email"  /></a></li><li style="display:inline;"><a href="path_to_rss"><img src="rss_icon_file_url " alt="subscribe to my RSS feed"  /></a></li><li style="display:inline;"><a href="path_to_twitter "><img src="twitter_icon_file_url " alt="follow me on twitter"  /></a></li><li style="display:inline;"><a href="path_to_linkedin"><img src="linkedin_icon_file_url" alt="connect with me on  linked in" /></a></li></ul> Make sure that you change the paths in the code to suit your own setup. For example, this code used in my social marketing crash course home page on WordPress looks as shown in the following screenshot: With the icon files correctly referenced, the individual e-mail (you can add your own contact form using the Add New Post page and clicking on the Add a custom form icon), Twitter, RSS, and linked pages also correctly linked to, you can save the Text widget. You might decide to add Facebook or other icons, or you might not want to use LinkedIn. It is easy to add and remove new icons by copying and pasting additional link (<li></li>) elements into the unordered list parent tags (<ul></ul>). In this case, the resulting links are displayed on the live site as shown in the following screenshot: OK, so the icons here are possibly a bit too small. I could hunt around for bigger ones, but it is also easy to add a bit of text to the links (after the img tag), or use some HTML to modify the layout to suit. The goal is to make it very easy and clear for any visitor to convert into a follower. By prominently displaying the various ways in which visitors can convert to followers, you upgrade your blog from the old baseball paradigm to the new black hole paradigm. As time goes by, you will benefit by building up a large network of followers who double as potential customers, and an army of marketers who can spread the word about your content, products, and services. Summary By utilizing your quality content and making it very easy for people so stay within reach of it through RSS, Twitter, Facebook, LinkedIn, and any other appropriate services, you drastically improve your chances of converting visitors into followers. Further resources on this subject: Dynamic Menus in WordPress [Article] Getting Started with WordPress 3 [Article] Social Bookmarking with WordPress Plugin [Article] Tips and Tricks for Working with jQuery and WordPress [Article]

  (For more resources on Moodle, see here.) There are a number of additional plugin types; namely, Enrolments, Authentication, Message outputs, Licences, and Web services. Plugins—an overview Moodle plugins are modules that provide some specific, usually ring-fenced, functionality. You can access the plugins area via the Plugins menu that is shown in the following screenshot:   Plugins overview displays a list of all installed plugins. The information shown for each plugin includes the Plugin name, an internal Identifier, its Source (Standard or Extension), its Version (in date format), its Availability (enabled or disabled), a link to the plugin Settings, and an option to Uninstall the plugin. The table is useful to get a quick overview of what has been installed on your system and what functionality is available. Some areas contain a significant number of plugins, for instance, Authentication and Portfolios. Other categories only contain one or two plugins. The expectation is that more plugins will be developed in the future, either as part of the Moodle's core or by third-party developers. This guarantees the extensibility of Moodle without the need to change the system itself. Be careful when modifying settings in any of the plugins. Inappropriate values can cause problems throughout the system. The last plugin type in the preceding screenshot is labeled Local plugins. This is the recommended place for any local customizations. These customizations can be changes to existing functionality or the introduction of new features. For more information about local plugins, check out the readme.txt file in the local directory in your dirroot. Module plugins Moodle distinguishes between three types of module plugins that are used in the courses—the front page (which is treated as a course), the My Moodle page, and the user profile pages: Activities modules (which also covers resources) Blocks Filters   Activities modules Navigating to Plugins | Activity modules | Manage activities displays the following screen: The table displays the following information: Column Description Activity module Icon and name of the activity/resource as they appear in courses and elsewhere. Activities The number of times the activity module is used in Moodle. When you click on the number, a table, which displays the courses in which the activity module has been used, is shown. Version Version of the activity module (format YYYYMMDDHH). Hide/Show The opened eye indicates that the activity module is available for use, while the closed eye indicates that it is hidden (unavailable). Delete Performs delete action. All activities, except the Forum activity, can be deleted. Settings Link to activity module settings (not available for all items). Clicking on the Show/Hide icon toggles its state; if it is hidden it will be changed to be shown and vice versa. If an activity module is hidden, it will not appear in the Add an activity or Add a resource drop-down menu in any Moodle course. Hidden activities and resources that are already present in courses are hidden but are still in the system. It means that, once the activity module is visible again, the items will also re-appear in courses. You can delete any Moodle Activity module (except the Forum activity). If you delete an activity or resource that has been used anywhere in Moodle, all the already-created activity modules will also be deleted and so will any associated user data! Deleting an activity module cannot be undone; it has to be installed from scratch. It is highly recommended not to delete any activity modules unless you are 100 percent sure that you will never need them again! If you wish to prevent usage of an activity or resource type, it is better to hide it instead of deleting it. The Feedback activity has been around for some time as a third-party add-on. It is hidden by default because it has been newly introduced in the core of Moodle 2, due to its popularity. You might probably want to make this available for your teachers. The settings are different for each activity module. For example, the settings for the Assignment module only contain three parameters, whereas the settings for the Quiz module allow the modification of a wide range of parameters. The settings for Moodle Activity modules are not covered here, as they are mostly self-explanatory and also dealt with in great detail in the Moodle Docs of the respective modules. It is further expected that the activity modules will undergo a major overhaul in the 2.x versions to come, making any current explanations obsolete. Configuration of blocks Navigating to Plugins | Blocks | Manage blocks displays a table, as shown in the screenshot that follows. It displays the same type of information as for Activity modules. Some blocks allow multiple instances, that is, the block can be used more than once on a page. For example, you can only have one calendar, whereas you can have as many Remote RSS Feeds as you wish. You cannot control this behavior, as it is controlled by the block itself. You can delete any Moodle block. If you delete a block that is used anywhere in Moodle, all the already-created content will also be deleted. Deleting a block cannot be undone; it has to be installed from scratch. Do not delete or hide the Settings block, as you will not be able to access any system settings anymore! Also, do not delete or hide the Navigation block, as users will not be able to access a variety of pages. Most blocks are shown by default (except the Feedback and Global search blocks). Some blocks require additional settings to be set elsewhere for the block to function. For example, RSS feeds and tags have to be enabled in Advanced features, the Feedback activity module has to be shown, or global search has to be enabled (via Development | Experimental | Experimental settings).   The parameters of all standard Moodle blocks are explained in the respective Moodle Docs pages. Configuration of filters Filters scan any text that has been entered via the Moodle HTML editor and automatically transform it into different, often more complex, forms. For example, entries or concepts in glossaries are automatically hyperlinked in text, URLs pointing to MP3 or other audio files become embedded, flash-based controls (that offer pause and rewind functionality) appear, uploaded videos are given play controls, and so on. Moodle ships with 12 filters, which are accessed via Plugins | Filters | Manage filters:   By default, all filters are disabled. You can enable them by changing the Active? status to On or Off, but available. If the status is set to On, it means that the filter is activated throughout the system, but can be de-activated locally. If the status is set to Off, but available, it means that the filter is not activated, but can be enabled locally. In the preceding screenshot, the Multimedia plugins and Display emoticons as images (smileys) filters have been turned On and will be used throughout the system, as they are very popular. The TeX notation and Glossary auto-linking filters are available, but have to be activated locally. The former is only of use to the users who deal with mathematical or scientific notation and will trigger the Insert equation button in the Moodle editor. The Glossary auto-linking filter might be used in some courses. It can then be switched off temporarily at activity module level when learners have to appear for an exam. Additionally, you can change the order in which the filters are applied to text, using the up and down arrows. The filtering mechanism operates on a first-come, firstserved basis, that is, if a filter detects a text element that has to be transformed, it will do so before the next filter is applied. Each filter can be configured to be applied to Content and headings or Content only, that is, filters will be ignored in names of activity modules. The settings of some filters are described in detail in the Moodle Docs. As with activities and blocks, it is recommended to hide filters if you don't require them on your site. In addition to the filter-specific settings, Moodle provides a number of settings that are shared among all filters. These settings are accessed via the Filters | Common filters menu and are shown in the following screenshot: Setting Description Text cache lifetime It is the time for which Moodle keeps text to be filtered in a dedicated cache. Filter uploaded files By default, only text entered via the Moodle editor is filtered. If you wish to include uploaded files, you can choose any one from the HTML files only and All files options. Filter match once per page Enable this setting if the filter should stop analyzing text after it finds a match, that is, only the first occurrence will be transformed. Filter match once per text Enable this setting if the filter should only generate a single link for the first matching text instance found in each item of text on a page. This setting is ignored if the Filter match once per page parameter is enabled.  

(For more resources on Moodle, see here.) Introducing the SIMILE timeline widget The Massachusetts Institute of Technology (MIT) has developed various visualization and data manipulation tools as part of the SIMILE project. One of these is a free/open source timeline JavaScript widget, which takes time-based data as input and creates an interactive timeline that scrolls from left to right and contains popup panes and links. A timeline for the life and career of Monet is as follows: You can view more examples on the web site, http://simile-widgets.org/timeline/. In order to use the timeline widget we need these components: The Moodle timeline filter, containing the SIMILE timeline Javascript libraries A timeline data file, in XML or JSON (Javascript Object Notation) format Photographs to show in the popup panes A web page to host the timeline We will deal with installing the filter later, but first we must decide on the subject for our timeline. If you visit the home of SIMILE, http://simile-widgets.org/timeline/, you will be able to explore timelines for the assassination of John F. Kennedy, the life of Claude Monet, and other examples. Timelines can be granular to the minute or hour, as in the case of the assassination. Or they can be spread over centuries or millennia—this is currently the limit for the widget. A suitable subject for our young audience would be significant or important inventions. This can encompass subjects as diverse as printing, paper, penicillin, steam, and the computer. And these inventions originate in different parts of the world, which adds an extra dimension to the subject. Now that we have our subject, a search on Google reveals some useful links, including a list of the top 10 inventions, http://listverse.com/2007/09/13/top-10-greatestinventions/. We may or may not agree with a list like this, but it acts as a useful starting point and aide memoire. There are pictures here, and more information and images on other websites including Wikipedia. To progress from ideas to our timeline, we need to create an XML data file. One of the easier tools to help us produce the XML is a syntax highlighting text editor, which we will install now. If you already have a text editor on your computer that you think is suitable, skip this section. Installing a text editor We have our subject, so the next step is to install some editing software to help us create our XML timeline file. Though most operating systems including Windows contain simple text editors, it will be helpful to install an editor that features syntax highlighting for various computer languages including XML. Some general-purpose text editors are: Notepad2 for Windows, a simple open-source editor, distributed under a BSD license (http://opensource.org/licenses/bsd-license.php). It is a small download, less than 300 kilobytes, from http://flos-freeware.ch/notepad2.html. Notepad++ for Windows, distributed under a GPL license. Download it from http://notepad-plus-plus.org. TextWrangler for Mac OS X, distributed under a Freeware license (not open-source), http://barebones.com/products/textwrangler/. Most flavors of Linux and Unix include the vi or vim text editor. Or use Emacs or your favorite editor. We will carry on and install Notepad2 for the examples in this article. Time for action – installing Notepad2 To install Notepad2 on Windows, visit the website http://flos-freeware.ch/notepad2.html in your browser and follow these steps: Under the Downloads section, find the link to the notepad2.zip file. Download it to your computer. Open the file notepad2.zip with the Unzip program available on your computer (the one built-in to Windows XP or later. Or Winzip, 7zip, or similar). Extract all the files in notepad2.zip to a directory on your hard drive, for example, C:apps2Notepad2. In your new directory, click on the file Notepad2.exe with your right mouse button. Choose Create Shortcut from the context menu that appears. Name the shortcut Notedpad2, and copy it to the clipboard. Now in Windows Explorer on Windows 7, go to the directory C:Users{USER}SendTo (or on Windows XP, go to the directory C:Documents and Settings{USER}SendTo). In each case {USER} is your username. Paste a copy of the shortcut in the directory. (Note, you will probably see a shortcut for Notepad, the basic editor included in Windows in this directory. You may want to delete it to avoid confusion.) Go to your Desktop and paste the shortcut there as well. Whew! Notepad2 is a little fiddly to set up, but don't worry, its easy to use. What just happened? We downloaded and installed a text editor for Windows called Notepad2. This has a feature called syntax highlighting, which as we will see helps us to write the XML file for our timeline widget. Note that the shortcuts we created are useful in different contexts. The SendTo shortcut is useful when we wish to edit a file—simply select it in Windows Explorer, right-click, and choose SendTo | Notepad2 in the context menu. The Desktop shortcut is useful for creating new files. We also found that there are many alternatives for Windows, Mac OS X, and other operating systems. These included Notepad++ for Windows, TextWrangler for Mac OS X, and vi/vim and Emacs for Linux. We have added a shortcut for the editor to the SendTo menu in Windows, as shown below: Now that we have a text editor we can create the timeline XML.

  (For more resources on HTML5, see here.) In the course of building pages using just HTML5 layout elements, in this article, we will explore all four advantages of relying on HTML5 as listed above. Dreamweaver CS5 and HTML5 Before diving in to create HTML5 pages from scratch, let's survey how we are going to get our money's worth out of Dreamweaver in the process. All recent versions of Dreamweaver (CS3, CS4, and CS5) with the HTML5 Pack installed can assist our work in creating HTML5 pages from scratch in three ways. First, with the HTML5 Pack installed, code hints that automatically prompts us in completing HTML5 coding are updated in Code view for HTML5 elements. Those code hints will help us avoid mistakes in spelling elements or constructing the (minimalist) coding syntax that we will need to place HTML5 elements. Second, we will avail ourselves of Split view, so that we will see our layout congealing in Design view as we sketch out what code we need to create in Split view. Third, we will take advantage of what is arguably the single most valuable panel in Dreamweaver—the CSS Styles panel. We will be defining CSS Style rules to associate with each of the HTML5 layout elements we use. Without styles, HTML5 layout elements are nothing, so the interplay between the HTML5 elements we create and formatting we do with the CSS Styles panel will drive our page design process. Moreover, here it is important to review, or at least reinforce two foundational techniques in building any professional-quality website in Dreamweaver: Do nothing without first defining a Dreamweaver site. Secondly, and not quite so essential but still pretty foundational, we always work with external style sheets. This allows the styles we define to be applied globally, across an entire website, and makes updating sites possible. As we begin to coordinate styling in the CSS Styles panel and constructing pages with HTML5 elements, I will be reminding you and when necessary walking you through the steps required to make sure all styles are saved to an external style sheet. With this as a preview, and cautionary reminder, let's dive in to creating pages with HTML5 layout elements. Building an HTML5 page from the top As opposed to laying out pages with tables (grids of rows and columns), or non-standardized Div tags (layout blocks you name and define yourself), we will use HTML5's new, standardized layout elements. The most basic of these are self-explanatory <header>, <nav>, <article> and <section>, <aside>, and <footer> tags. In addition, as alluded to in the introduction to this article, we will use additional elements to help make content more accessible to search engines. For example, within articles, we will use new HTML5 elements that make it easy for people looking for online content (or those making such online content accessible through various forms of search engines) to find things such as the publication date of content, or the date of an upcoming event. HTML5 structural elements In order to alert browsers that we are presenting HTML5 content, we need to indicate at the top of our HTML5 code that this is an HTML5 page. As for those browsers that respond, "huh, what's that?", we will address that challenge shortly. However, first use the following steps to create a new HTML5 page from scratch: With your Dreamweaver site defined, choose File | New. In the New Document dialog, choose Blank Page from the category list on the left of the dialog. Choose HTML in the Page Type column. Choose None in the Layout column. In the Layout CSS popup if you already have a CSS file you use with HTML layouts, you can choose Link to Existing File, and select your existing HTML5-related CSS file as the styles file for your page. From the DocType popup choose HTML5 as shown in the following screenshot: (Move the mouse over the image to enlarge.) Click on Create to generate the blank page. A blank page appears in Design view of the Document window. In Split view, we can see some basic code has been generated: <!DOCTYPE HTML> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <title>Untitled Document</title> </head> <body> </body> </html> Let's briefly walk through this to situate ourselves. The <!DOCTYPE HTML> and <html> tags are sort of evolutionary holdovers from previous versions of HTML, and not actually required for HTML5 browsers. This code though, might be useful when taking into account non-HTML5 browsers, as we will examine shortly. The <head> and </head> tags d emarcate head content that is not displayed on the page, but serves as instructions to browsers. In this case, the content inside identifies that the current, most widely applicable character set, UTF-8, is implemented. This character set allows the display of characters from a wide range of languages. All the content we create for the page will be placed within the <body> and </body> tags. For this reason, our first step in creating our CSS styles for this page, will be to define a couple of basic attributes for the </body> tag. Finally, save this page as an HTML file. Choose File | Save. In the Save As dialog, make sure the folder selected in the Where popup is your Dreamweaver site folder (or a subfolder within that). Give the file a name, like html5_test, and click on Save. While we are at it, enter a descriptive title in the Title box of the Document toolbar. Resave periodically. Creating a CSS file H and-in-hand with our HTML5 fi le, we will create and use a CSS fi le to organize and manage all the styling in the page. Therefore, let's create that CSS fi le now, and as we do, add a line that will make our HTML5 page compatible with all current browsers, and most older ones. To do that, follow these steps: Choose File | New, and in the New Document dialog, choose the Blank Page category on the left, and CSS from the Page Type category. Click on Create to generate, and open a new CSS file. The file opens in Code view. We will be editing it in the CSS Styles panel, so except as a learning experience we won't need to view this page again. However, we do need to save it. Choose File | Save, and give the file a name like html5_layout.css. Make sure the site folder is selected in the Where pop up, and click on Save as shown in the following screenshot: In the tab bar at the top of the document window, toggle back to the HTML file you created, as shown in the following screenshot: View the CSS STYLES panel if it is not visible (choose Window | CSS Styles), and click on the Attach Style Sheet icon as shown in the following screenshot: The Attach External Style Sheet dialog appears. Use the Browse button to navigate to the CSS fi le you just created, and click on OK to attach the style sheet. The CSS fi le appears in the CSS Files panel (use the All tab in the CSS Styles panel as the norm, unless you are doing particular styles detective work that requires the Current tab). You will also see the link to the CSS file in Code view if you look. Next, we will add a single attribute that enables most browsers to interpret the HTML5 elements, even if they are not HTML5 compliant. To do that, follow these steps: Click on the New CSS Rule icon at the bottom of the CSS Styles panel, it is just to the right of the Attach Style Sheet icon identified in the preceding screenshot. The New CSS Rule dialog opens. In the New CSS Rule dialog, choose Compound from the first popup. We are creating a rule that will apply to more than one HTML5 layout element. These are HTML5 tags that we want to prevent from collapsing when viewed in non-HTML5 browsers. In the Choose or Enter a Name for Your Selector field, enter header. We actually want to apply the rule we are working on to additional HTML5 elements, but we will add those shortly. In the Rule Definition section of the dialog, make sure your attached CSS fi le is selected (it will be by default). Click on OK. In the CSS Rule Definition for header dialog, select the Block category, and choose block from the display popup as shown in the following screenshot, then click on OK. The Header style appears in the CSS Styles panel when you expand the CSS Styles file linked to the page. You can see that the display property for the header style has a block attribute associated with it in the CSS styles panel. We want to expand the list of HTML5 elements to which this display:block attribute is assigned. The long, slow way to do that is to duplicate steps we have traversed so far for each additional element. To do that the quick, easy way, click once in the header row, in the top half of the CSS Styles panel, and edit the list of elements to include address, article, footer, nav, section. Use commas (",") to separate the additional elements as you type them in. These are HTML5 tags that we want to prevent from collapsing when viewed in non-HTML5 browsers. The CSS Styles panel should now look like the following screenshot: With the preceding set of steps, we have told most non-HTML5 browsers to keep our basic HTML5 building-block elements on their own distinct horizontal row, so they don't smush into each other. Our basic model and scenario here is creating pages that are intended only for HTML5 browsers (like iPhones or iPads). Using HTML5 to make content accessible Having set up our HTML5 document with basic web page coding, we are now ready to create and format the HTML5 layout elements that will define how the page looks. But wait… as the TV pitchmen say… there's more! Before diving into the page design dimension of HTML layout elements, it will be helpful to quickly survey another reason to use HTML layout elements to organize content: accessibility. As alluded to in the introduction to this article, there are advantages beyond design considerations for relying on HTML5 layout elements to organize page content. These advantages revolve around the way HTML5 layout elements package content for metadata compilers (such as search engines). This emerging connection can make content organized into HTML5 layout elements more searchable, easier to organize and access. Moreover, this will be even more the case in the future as search engines and other web content organizing tools integrate HTML5 layout elements. We will take a rather simple, but interesting example of how this works right now. If you have ever copied and pasted the content between apps on an iPhone (for example, the address of a web page into an app that helps you find public transportation options or content from an article or posting that you read online in an e-mail), then you maybe familiar with the routine where you hold your finger down on the screen and are prompted with a Copy prompt. The next step is to use the somewhat awkward process of using one's fingers to define the content to copy to the clipboard, as shown in the following screenshot:   On the other hand, when content is organized into articles (or sections), a touch on the iPhone screen instantly selects an article or article section for copying, as shown in the following screenshot:   Now, in terms of added value to a website, the convenience associated with iPhone users easily selecting articles or article sections probably isn't going to turn the world upside down, although visitors are likely to note positively the convenience they experience selecting articles from your page to share. However, the fact that the iPhone browser recognizes sections (and articles, and other HTML5 layout elements) also gives a sense of the potential for the associations between content and HTML5 layout elements to make content more accessible. We can expect, for example, that in the not-so-far-off-future, people will be able to tune their search engine queries for "articles" about this or that topic. HTML5 layout and search engines: By relying on HTML5 layout elements to organize page content, you are building (in advance) support for search tools and other ways that HTML5 will facilitate finding content. HTML5 layout strategy Having surveyed the emerging value of organizing content into HTML5 layout elements, we turn to the more dramatically impactful aspect of using HTML5 layout elements: design. However, keep in mind; design and content are linked in HTML5. Unlike previous generations of web page markup language, HTML5 organizes content both to facilitate displaying that content, and to facilitate accessing that content. A basic HTML5 page layout is illustrated in the following screenshot, with self-explanatory placeholder text: The visible borders in the preceding screenshot, by the way, are a product of Dreamweaver CS5's CSS Layout Outlines (if they are not functioning, choose View | Visual Aids | CSS Layout Outlines). Again, before diving into an exploration of the specific elements in HTML5 layouts, and how they are implemented, keep in mind they both define design components of the page, and organize content. Using code hints Dreamweaver, with the HTML5 Pack, is HTML5-friendly, but not exactly HTML5-compatible. By this, I mean that it is necessary to resort to Code view to apply HTML5 elements. However, within that, you get help. As noted earlier, Dreamweaver CS5 helps create the coding for HTML5 code hints. As you begin typing HTML5 elements in Code view, beginning with "<", Dreamweaver prompts you with a set of tags that begin with the letter you type. So, for example, typing <he produces the following code hints, from which you can click on <<>header and press Enter (Windows) or Return (Mac) to place the code. You can use control spacebar on Mac or PC to bring up the full code hinting list. To close (define the end of) an HTML5 layout element, simply type </. When you do that, Dreamweaver auto-enters the close coding for the open element, as shown in the following screenshot:   As we walk through the coding involved in defining different HTML5 layout elements in the remainder of this article, you can enter the necessary code in Split view, utilizing code hints, and seeing the results in the Design half of Split view.