4elements, Amsterdam, Holland

  1. Using Pull Requests as Code Reviews

    When developing software, source control makes our lives so much easier. From tracking our changes to introducing code collaboration, it helps increase our productivity. Furthermore, the fact that there are a number of different tools available - Subversion, Perforce, Mercurial, and so on - make it even better by providing us options from which to choose.

    In this series, we’re looking specifically at Git and using Bitbucket and how they can help us in our day-to-day work. In this article, we’re going to be specifically focused on using Bitbucket for feature discussion, bug tracking, release tagging, and more.

    One of the major features of Git - and, thus, Bitbucket - is the idea of pull requests. In this article, we’re going to be looking at pull requests and how they not only benefit us from a source control standpoint, but from a peer review standpoint, as well.

    A Pull Request Primer

    When someone issues a pull request into your project, it means that they are asking to have their code merged into the codebase. That is, they are requesting that you pull their code into the project.

    But we, as maintainers, have the ability to review, to test, and to merge the changes introduced by the request. Make no mistake: We play a very important role in deciding if the particular request meets both the standards and goals of our software.

    If a discrepancy is found, we can ask the contributor to update the pull request by either cleaning up the code, resolving any outstanding issues, or improving the general quality of the code. On the other hand, we may also reject the pull request if we decide it doesn’t meet whatever criteria we deem necessary for the project.

    In order to issue a pull request, a person must first fork the codebase of the initial project. This means that they take a snapshot of the codebase in its current state, create a set of changes, and then commit the changes to their personal copy of the code. From there, the developer then requests that the change be pulled into the initial repository.

    As previously mentioned, pull requests can consist of any number of things:

    • Bug fixes
    • Translations
    • Feature additions
    • Addition or modification to documentation
    • ...and so on

    Used by teams of all sizes - both in-house and distributed - source control management is a valuable part of developing software. The thing is, when it comes to working with source control systems, users have varying roles of permissions.

    That is to say when it comes to maintaining a repository, some developers will have read-only access while others have both read and write access. And those with write access are the ones who are responsible for maintaining pull requests.

    Bitbucket and Pull Requests

    In this series of articles, we’re taking a look at how Bitbucket can enhance your team’s workflow when it comes to developing software. Just as we’ve previously discussed, Bitbucket allows people to participate in the project both by committing code to it, by reviewing pull requests, and conducting merges of said requests.

    One of the nicest features of Bitbucket is that it allows you to add multiple reviewers to a single pull request who can then approve (or reject) the request. This, in turn, gives those who maintain the repository the ability to review the quality of the code that’s specified in the pull request.

    Perhaps they will welcome the additions to the project, perhaps not. Whatever the case may be, Bitbucket gives maintainers the tools necessary to give feedback on any given pull request.

    Finally, Bitbucket supports inline commenting on each pull request which makes it much easier to discuss a specific line, block, or module of code.

    All in all, this approach makes it much easier to determine whether or not a pull request should be merged, if it should be rejected, or what areas of the could should be changed prior to merging the request.

    Learn by Example

    Fork a Repository

    To get started, visit a project’s dashboard in your web browser, and then click on Fork to fork the repository.


    Next, you will be presented with a form that allows you to specify a custom name and custom description. You also have the ability to set the repository’s visibility and permissions among other features.

    If you’re responsible for the code that’s going to be written and want access to additional tools to make it easier to work with a team around the codebase, then select the Project Management option from the corresponding interface element.

    After clicking on the Fork repository button, you will grab the latest version of the codebase of the project and have it available in a repository that’s all your own. In order to check out the code to your local machine, you can use a Git client such as SourceTree, or you can do so from the command line by issuing the following commands in the local directory where your project is stored:

    $ git clone https://yourusername@bitbucket.org/yourusername/reponame.git

    Notice that the URL that we’ve specified above is visible in the dashboard of your repository in Bitbucket’s dashboard.

    After checking out the code, you can begin working on the project on your local machine. As you introduce changes, you will want to commit this to the repository. To do this, you first stage your work and then you commit your work to the repository.

    Make Your Changes

    At this point, we’re ready to actually get to work. What this means will vary depending on the nature of your project: Perhaps you’re working to close a bug, perhaps you’re refactoring a function, or maybe you’re adding a feature.

    Whatever the case, once the changes have been made, you can issue a commit to the repository. This means that you’re taking the files on which you’ve worked and are combining them into a single collection of changes which is called a changeset. Changesets are normally accompanied by a short message that explains what was changed and why.

    When you commit code, at least at first, you’re not actually pushing anything to the repository. In other words, if this is your first commit, then your code isn’t actually stored online in Bitbucket. Instead, the changes only exist on your local machine. Once you’ve performed your initial push, the code then exists in the repository.

    Ultimately, source control gives a way to maintain a clean history of your changes, as well as an easy way to rollback to a certain point in time.

    Issue a Pull Request

    Once you’ve pushed a change to the remote repository (either via a client or via the command line), you’re ready to initialize a pull request. This means that you’re ready to take code that you’ve pushed into your fork of the codebase and ask the original maintainers if they’ll merge the code into their project.

    Doing this within the Bitbucket application is easy. Simply go to the dashboard of the forked repository, and then click on Create pull request.

    Next, you will be presented with an interface that will allow you to create your pull request. The request will include your repository, the original repository, and a title and description.

    From here, you select your repository as the source repository and the original codebase’s repository as the target repository. You may need to change these within the dashboard depending on your requirements.

    For example, if you’ve named your copy of the code “develop” when issuing the “git add remote” command earlier, but the original codebase uses the word “master,” then you will need to make sure that you’ve selected the proper values.

    Finally, this is where Bitbucket allows you to add reviewers to a pull request. As previously mentioned, this makes it much easier to attract the attention of project maintainers so that they can review your work, offer up any comments that they may have, and merge (or reject) your request.

    Following Up With the Pull Request

    Bitbucket automatically updates your pull request when you push code to the source directory so the project reviewer always gets to see the latest code that they can pull. 

    When the reviewer asks for a specific change, s/he can simply push the requested changes in your copy of the repository - that is, the forked repository.

    Managing Pull Requests

    If you maintain a repository that receives pull requests from others, then you are likely to notice that your repository will receive both a notification in the Bitbucket application dashboard, as well as in your email.

    Additionally, if you’re a reviewer, you will also receive a notification and an email. To manage all incoming pull requests, click on the “Pull requests” link and select the pull request with which you want to work.

    As you can see, Bitbucket provides a clean interface where you can discuss and review pull requests. Both maintainers and viewers can reject, merge, or ask for additional work to be done on a given pull request.

    Assuming that you have a request that’s ready to be merged, then you click on the specific option for doing exactly that. If you happen to work with multiple reviewers, then Bitbucket also makes it clear as to who approved the request by applying a check mark on their avatar. Obviously, the more checks that appear across the reviewers, the more likely the request is ready for merging.

    But what happens if merging the pull request fails? At this point, a manual merge must be done (which is a common part of source code management, though outside the scope of this article), after which the code will be committed to the repository.

    Conclusion

    Clearly, source control offers a lot of advantages for teams; however, pull requests are a powerful feature that make it easy to contribute to a project and to have others peer review your code, comment on it, and improve it before merging it into the codebase.

    This alone can help one become a much better developer as you’re learning from the experience of other developers who are maintaining the larger project. If you’re not already, try using pull requests in your workflow to help improve your code, and gather feedback from others.

    Please leave any questions, comments, or other feedback in the comment area below.

     

    0 Comments

    Leave a comment › Posted in: Daily

    1. How to Make Email a Powerful Part of Your Web Application

      My favorite popular productivity tools, iDoneThis and TeamSnippets, give me a simple way to record and share the tasks that I have completed each day with my teammates. Each day, the services send me an email asking me what I completed today. From my email account, I can easily reply with my completed tasks without having to log into the website. Remarkably, a majority of my teammates complete most of their website updates through email replying. 

      You can also create the same powerful functionality with commenting, receiving content via email, and enabling replies to create, continue, and resolve support tickets. With the Inbound Parse Webhook, from SendGrid’s SMTP Service, you can make your applications interactive by inviting replies and responding to users via their email. 

      The SendGrid Parse Webhook lets you parse email contents and attachments from any incoming emails and post the data via JSON to your application. The capability allows you to accomplish the following, from email replies to your website application:

      • Post blog entries
      • Use email replies to update your mailing list or database
      • Upload photos and videos
      • Start and resolve support ticket requests

      Getting Started

      The instructions below are for getting the Inbound Parse Webhook up and running locally. Start by cloning this GitHub repository and cd into its directory:

      $ git clone https://github.com/scottmotte/sendgrid-parse-api-example.git
      $ cd sendgrid-parse-api-example

      Set Up Your Credentials

      $ mv .env.example .env 

      Change the Contents of .env to Your SendGrid Username and Password

      SENDGRID_USERNAME = your_sendgrid_username
      SENDGRID_PASSWORD = your_sendgrid_password 

      Run the Application

      $ npm install 
      $ node app.js 

      If npm install doesn’t work for you, you can try installing through MacPorts

      $ sudo port npm install

      If you are receiving errors that suggest you’re missing a module, this means that you should install it. For example, I received an error that app.js is not able to instantiate the dotenv variable, and after installing dotenv, it resolved the issue altogether.

      $ npm install dotenv

      Setup a Tunnel

      Use a local tunnel like ngrok to test locally and quickly, rather than deploying code to a live server. 

      Ngrok allows you to securely expose a local web server to the web and capture traffic for detailed inspection and replay. Download, unzip, and start the ngrok process. After you start the process, ngrok will give you a unique URL for you to inspect locally on. 

      The instructions below are for getting ngrok to work locally on a Mac. Visit ngrok.com to install a local setup for other operating systems. 

      $ wget https://dl.ngrok.com/darwin_amd64/ngrok.zip
      $ unzip ngrok.zip –d /usr/local/bin
      $ ngrok 3000

      Set Up SendGrid and MX Records

      Note that this can take up to 48 hours. 

      Once your MX records have fully propagated, you can send emails on production in up to 48 hours. 

      First, after your SendGrid account is provisioned, you can set up your SendGrid Parsing Incoming Emails setting. Click on the “Developers” tab for the “Parsing Incoming Emails” link. In the Hostname field, specify your hostname (i.e. yourdomain.com) that you would like. In the URL field, input the unique URL that ngrok gives you. 

      Configure an MX record on the hostname you set above to point to mx.sendgrid.net. It should look something like the following. 

      Now, in two days, your MX records will completely propagate. 

      Send an Email From Your Personal Email Account

      If you send an email to inbound@the-hostname-you-setup.com, in a few minutes, the app you have running will parse and deliver the contents to you in JSON format. 

      Test and Play With the API

      Congratulations, you have set up a simple way to parse your emails efficiently! Now, you are ready to explore and make calls to the API. 

      Inspecting Payload Contents

      If you just need a quick way to inspect the payload contents of the Parse Webhook, you can use RequestBin, a free tool, after setting up your MX records.

      Posting From The Command-Line

      If you’d like to get your hands dirty from the command line, you can try SendGrid’s free webhook debugger tool, which is a fast way to start seeing how events appear. 

      At the heart of the tool is a URL that you can set as your Parse Webhook endpoint. Each time you load the URL, you will get a unique ID within the URL. 

      Below are two examples to get started with your webhook. The GET example will begin listening for new data. From your command-line terminal, paste in the following GET example: 

      $ curl –X GET \ http://hookdebug.sendgrid.com/v1/events/e6a20fffc9c1968dd64684f0b11b9c29 

      To paste in whether your Parse Webhook is receiving data, type in the curl command from the POST example into a second terminal screen:

      $ curl –X POST \
        -d “foo=bar” \
        -d “alice=bob” \ 
        http://hookdebug.sendgrid.com/v1/events/e6a20fffc9c1968dd64684f0b11b9c29

      The response on your terminal window should now have new content:

      {
        “event_id”: “e6a20fffc9c1968dd64684f0b11b9c29”
      }

      Next, send an email to the domain or sub-domain that you are using for inbound parsing. Within a few minutes, you should see the parsed email as JSON in your terminal window. 

      Customize Your Parser

      As you can see, the details of email data separation and routing of an incoming message to the SendGrid script are done behind the scenes for you. Starting from scratch, you can use the Parse Webhook in many creative ways. You’re now ready to place some real email data through that webhook! 

      To custom-parse your emails, you can start to customize the code in routes/inbound.js.

      For example, you can rewrite the inbound.js file to store attachments in a way that would suit your application and database or even complete an action if the email contents contain a word. 

      Conclusion

      For use cases, case studies and examples, download the Parse Webhook Guide or check out the Parse Webhook API library

      When looking at the Parse Webhook examples, you will notice that the two most common ways it is used are: interacting with your users and collecting data within your applications via email.

      With the webhook, you can develop features that make frequent tasks more productive for your users without having them leave their email inbox. Collecting insights and making your emails interactive have never been easier. 

       

      0 Comments

      Leave a comment › Posted in: Daily

    1. Building a Website With Progressive Enhancement

      When building a website, you have a few ways to approach doing so.

      You can start by creating the most advanced version of the site with all of the scripts, styles, and so on, and then have it render in older browsers via graceful degradation, you may opt to ignore older browsers, or you can start with a basic page and add scripts and styles such that it becomes more functional via progressive enhancement.

      In this series, we're going to take a look at the latter.

      Now that we've covered the theory of progressive enhancement, we can create a simple page to illustrate the approach. The site we will be creating will be just a simple information site: a few links, some text, images, and a contact form.

      We will use the widely adopted F layout (if you don't know what it is take a look at this great article on Web Design Tuts+: Understanding the F-Layout in Web Design).


      Step 1: Basic HTML

      Start by creating the index.html file with this HTML code:

      <!DOCTYPE html> 
      <html> 
          <head> 
              <title>Example Website</title> 
          </head> 
          <body>
          </body> 
      </html>

      Step 2: Heading and Menu

      Now let's create a heading for our website. To comply with the rules, we will just use the <h1> tag for it:

      <h1>Our Sample Heading</h1> 

      After that, we can create the menu. Usually, you would use the <ul> tag for it, but since the page has to look decent without CSS, we will use the <nav> tag and place anchors in it:

      <nav>
          <a href="index.html">Home</a> 
          <a href="about.html">About</a> 
          <a href="offer.html">Offer</a> 
          <a href="contact.html">Contact</a> 
      </nav> 

      Note that even if you don't use indentation in your code (and you should to make it more readable), you have to do it here, because without CSS, the spaces between the links are the only thing that will separate them when viewing the page. Of course, you will not notice it since the browser has a default CSS for them.

      Here is how our page should look:

      Step 3: Example Content and Footer

      To get some sample text, you can go to http://www.lipsum.com/ and generate a few paragraphs. Remember the rules: we will not put the content in any special container <div>. It has to be semantic, so we will use the HTML5 <main> element. Put the text in the <p> tags just below the menu.

      <main> 
          <p> Lorem ipsum dolor sit amet... </p> 
          <p> Nam aliquet tempor turpis... </p> 
      </main>

      Now add the footer using the <footer> tag:

      <footer>Copyright &copy; 2014 SomeNonExistent Company. All rights reserved.</footer> 

      The page should now look like this:

      You can create the About and Offer pages in the same way—they will not have anything special in them (you can add their names as <h2> tags just above the content).


      Step 4: The Contact Form

      The last thing to do in HTML is the contact page. Copy the contents of your index.html to contact.html and remove the contents of the <main> element.

      Now add the heading for the form (into the <main> tag):

      <h2>Contact Us</h2> 

      After that, we can add a <form> element with appropriate fields for the user to fill (since the server side of things stays pretty much the same I will not cover it here, so if you want to test your form you will have to write the back-end yourself):

      <form method="POST"> 
          <p> 
      	    <label for="name">Your name:</label> 
      		<input id="name" name="name"> 
      	</p> 
      	<p> 
      		<label for="email">Your email:</label> 
      		<input id="email" name="email"> 
      	</p> 
      	<p> 
      		<label for="message">Your message:</label> 
      		<textarea id="message"></textarea> 
      	</p> 
      	<button type="submit" value="Send">Send</button> 
      	<button type="reset" value="Reset">Reset</button> 
      </form>

      The <p> tags do not break the semanticity rule because the label and input combo is actually a paragraph. The contact page should look like this:

      The CSS

      Now that our page is working, we can start to make it look a bit better. Create a file and name it style.css. Now add this line to the <head> section of your document:

      <link rel="stylesheet" href="style.css"> 

      Step 5: Base Styles

      The first thing to do would be to change the fonts and overall shape of the page:

      * { font-family: Calibri, sans-serif; } 
      body { width: 900px; margin: auto; } 

      Two lines of CSS and you can see that the page looks a bit better as it's no longer using the default fonts.


      Step 6: The Header

      Now let's add some looks to the header: space it a bit, change the font size, and add the background:

      h1 { 
          padding: 100px 10px 20px; 
          margin: 0; 
          background: #dfdfdf; 
          font-weight: normal; 
          font-size: 3em; 
      } 

      Notice how we changed the font size — we used em instead of any other unit. This is because of the last of the rules explained in the first part of this series: Users can change the base size of the font and if we had, for example, used px, their settings would not be respected by our stylesheet.


      Step 7: The Menu

      After fixing the header's appearance, we can get on with the menu. We will also change the font size of the anchors, remove their underline, and add a background when they are hovered over or when they have an active class:

      nav { background: #aed8ff } 
      nav a { text-decoration: none; font-size: 1.3em; color: #333; padding: 15px 25px; display: inline-block; } 
      nav a:hover, nav a.active { background: #dfdfdf; color: #666; } 

      Now add the active class to the appropriate anchors in your files so they are appear "pressed" when the page is loaded:

      <a href="index.html" class="active">Home</a>

      Here is how it should look like now:


      Step 8: The Content

      Here, we will aim just improve the readability by increasing the line height (don't forget about users' settings—we can change the size of purely visual elements like headers and buttons, but users set their default font size for a reason). We'll also change the font and add some padding:

      p { 
          font-family: Helvetica, Arial, Sans-Serif; 
          line-height: 1.6; 
          text-align: justify; 
          padding: 10px; 
      } 

      Here is the result. Notice how the readability improved with such a small change:


      Step 9: The Footer

      This will also be just a small cosmetic change: background, padding, and centered text:

      footer { padding: 10px; background: #dfdfdf; text-align: center; }

      Here is how the footer looks like now:


      Step 10: The Form

      The last thing to do is to fix the appearance of the contact form. First, let's remove the padding and margin of the <p> elements:

      form p { margin: 0; padding: 0; }

      Now let's set the width of the <input> elements and <textarea> to be the same. We also set display: block on them to line them up nicely:

      form input, form textarea { width: 300px; display: block; }

      Finally we change the <button>s to take up half of the form's width:

      form button { margin: 10px 0; padding: 5px; width: 148px; } 

      This is the final result:

      Conclusion

      In the next article, we will use some JavaScript (specifically, jQuery) to add some interactive elements to our website.

      For those of you who are more advanced developers, you may find that this tutorial didn't teach anything you didn't know about HTML or CSS. Since we're working this strategy from the perspective of a beginner, that is to be expected.  

      Alternative, look at it this way: We created a design that is based on its content and not based on a pre-existing design. Of course, it's simple and straightforward, but it helps to demonstrate the point without including a large amount of CSS and other assets on the page.

      If you remove the stylesheet from the document, you should see the point that we're trying to demonstrate: The page's layout stays the same and you can still use the page without issue.

      Before the next article, please leave your questions, comments, and feedback in the form below.

       

      0 Comments

      Leave a comment › Posted in: Daily

    1. An Introduction To The HTML5 History API

      History is always interesting, isn't it? In older versions of HTML, we had limited control over browser history. We could go back and forth using the available methods, but that was it

      With the HTML5 History API, we have more control on playing with the browser history. For example, we have a way to add an entry in the history, or change the URL in the address bar without refreshing the page.

      Why A History API?

      In this article, we'll learn why the HTML5 History API came to be. Before this API existed, we often used hash values to change the page content especially for heavy, single page applications because changing the URL was not possible without refreshing the page. Additionally, when you change the hash value for a URL, it does not make any changes to the browser history. 

      Now, however, both of these things are available with HTML5 History API and it makes possible to develop script heavy, single-page applications without having to use hash values. It also allows us to build applications in an SEO-friendly manner. Furthermore, this technique allows us to reduce bandwidth - but how? 

      In this article, we will be developing a single-page application with this API to demonstrate exactly that. 

      That means we will load all required resources on the first page load. From there onward, the application will download only the required contents. In other words, instead of loading all resources all the time, it will load only required resources from a second content request. 

      Note that you need to perform some server-side coding to deliver only partial resources instead of full page content.

      Browser Support

      At the time of writing this article, browser support for the HTML5 History API is quite good, We can review its status here. This link will give you a glimpse of supported browsers but it is always good practice to detect support for particular feature before using it. 

      To programmatically determine if your browser supports the API, check out the following line of code:

      return !!(window.history && history.pushState);

      Additionally, I would suggest taking this article to Detect Support for Various HTML5 Features.

      If you are using Modernizr, then you should be using below code:

      if (Modernizr.history) {
          // History API Supported 
      }

      If your browser does not support history API, then you can use the history.js polyfills.

      Manipulating History

      HTML5 provides two new methods:

      1. history.pushState() 
      2. history.replaceState()

      Both of which allow us to add and update history state, respectively. Both work in the same manner and expect same number of parameters. In addition to these methods, we have popstate event. We will see later in this article for how and when to use this popstate event.

      pushState and replaceState both expect the same number of parameters which are as under:

      1. state can store a JSON string and will be available for popstate event.
      2. title is a parameter is disregarded by the majority of browsers for now, so better to set it to null for today.
      3. url can represent any URL. It will be updated with the browser's address, and it won't care if that URL exists or not. Most importantly, it won't reload your web page.

      The major differences between these methods are that the pushState will add a new entry in the history stack and replaceState will replace current the history value instead of adding new one. If you are still confused in both these methods, then let's demonstrate the same case with better example.

      Let's presume we have stacks of two blocks labeled 1 and 2 and you have block labeled 3 in your hand. Now, when we perform pushState, block 3 will be added to an existing stack so stack would have 3 blocks. 

      Now assume the same stack with two blocks and one more in your hand. When we perform replaceState, it will pick the block 2 out of stack and place block 3. So the number of history values will remain same. pushState, on the other hand, increases history count by one. 

      The below image shows the same demonstration.


      Thus far, we have covered the pushState and replaceState events in order to control the browser history, but suppose we have a variety of fake history that we have totaled in the browser. The user may or may not redirected to that page. In such a case, it will be a problem when user hits the browser back and forth button to navigate to history pages.

      Though you may expect popstate to be fired when the pushState or replaceState methods are addressed, but in reality, it is not the case. Instead, popstate will fire when you are navigating through the session history entry, either by hitting backward or forward buttons or using the history.go or history.back methods.

      In WebKit browsers, a popstate event would be triggered after document's onload event, but Firefox and IE do not have this behavior.

      The Demonstration

      The HTML

      <div class="container">
          <div class="row">
      		<ul class="nav navbar-nav">
      			<li><a href="home.html" class="historyAPI">Home</a></li>
      			<li><a href="about.html" class="historyAPI">About</a></li>
      			<li><a href="contact.html" class="historyAPI">Contact</a></li>
      		</ul>
      	</div>
      	<div class="row">
      		<div class="col-md-6">
      			<div class="well">
      				Click on Links above to see history API usage using <code>pushState</code> method.
      			</div>
      		</div>
      		<div class="row">    
      			<div class="jumbotron" id="contentHolder">
      				<h1>Home!</h1>
      				<p>Lorem Ipsum is simply dummy text of the printing and typesetting industry.</p>
      			</div>
      		</div>
      	</div>
      </div>

      The JavaScript

      <script type="text/javascript">
          jQuery('document').ready(function(){
      		
      		jQuery('.historyAPI').on('click', function(e){
      			e.preventDefault();
      			var href = $(this).attr('href');
      			
      			// Getting Content
      			getContent(href, true);
      			
      			jQuery('.historyAPI').removeClass('active');
      			$(this).addClass('active');
      		});
      		
      	});
      	
      	// Adding popstate event listener to handle browser back button  
      	window.addEventListener("popstate", function(e) {
      		
      		// Get State value using e.state
      		getContent(location.pathname, false);
      	});
      	
      	function getContent(url, addEntry) {
      		$.get(url)
      		.done(function( data ) {
      			
      			// Updating Content on Page
      			$('#contentHolder').html(data);
      			
      			if(addEntry == true) {
      				// Add History Entry using pushState
      				history.pushState(null, null, url);	
      			}
      			
      		});
      	}
      </script>

      Demo 1: HTML5 History API - pushState

      In this demo, you will experience that history entries are being counted in the browser and you can sail through it using the browser back/ forward button. View Demo

      Demo 2: HTML5 History API - replaceState

      In this demo, you will experience that history entries are being updated in the browsers and you cannot navigate through it using the browser back/ forward button. View Demo

      Conclusion

      This API has created a great impact on how our web application works. It has removed the dependency on hash values in URLs in order to make it easy to create efficient, SEO-friendly, single-page application. 

      It's a really nice API, isn't it?

       

      0 Comments

      Leave a comment › Posted in: Daily

    1. Building a Website by Progressive Enhancement

      When building a website you have a few ways to do the fancy stuff. One way is to start by creating the most advanced version you want (with all of the scripts, styles, etc.) and then make it render well in older browsers (graceful degradation). Another is just to decide you don't care about older browsers. A third is to start with a bare bones page, and add scripts and styles so it is readable and usable without them (progressive enhancement). In this series we will focus on the third option.

      Now that you know the theoretical stuff, we can create a simple page to illustrate the general approach. The site we will be creating will be just a simple information site: a few links, some text, images, and a contact form.

      We will use the widely adopted F layout (if you don't know what it is take a look at this great article on Web Design Tuts+: Understanding the F-Layout in Web Design).


      Step 1: Basic HTML

      Start by creating the index.html file with this HTML code:

      <!DOCTYPE html> 
      <html> 
          <head> 
              <title>Example Website</title> 
          </head> 
          <body>
          </body> 
      </html>

      Step 2: Heading and Menu

      Now let's create a heading for our website. To comply with the rules we will just use the <h1> tag for it:

      <h1>Our Sample Heading</h1> 

      After that we can create the menu. Usually you would use the <ul> tag for it, but since the page has to look decent without CSS, we will use the <nav> tag and put anchors in it:

      <nav>
          <a href="index.html">Home</a> 
          <a href="about.html">About</a> 
          <a href="offer.html">Offer</a> 
          <a href="contact.html">Contact</a> 
      </nav> 

      Note that even if you don't use indentation in your code (and you should to make it more readable) you have to do it here, since without CSS the tabulators (or spaces) between the links are the only thing that will separate them (the distance will be the same no matter if you use tabulators or spaces, the browser will take care of that). Of course you will not notice it since the browser has a default CSS for them.

      Here is how our page should look:

      Step 3: Example Content and Footer

      To get some sample text, you can go to http://www.lipsum.com/ and generate a few paragraphs. Now remember the rules: we will not put the content in any special container <div>. It has to be semantic, so we will use the HTML5 <main> element. Put the text in the <p> tags just below the menu.

      <main> 
          <p> Lorem ipsum dolor sit amet... </p> 
          <p> Nam aliquet tempor turpis... </p> 
      </main>

      Now add the footer using the <footer> tag:

      <footer>Copyright &copy; 2014 SomeNonExistent Company. All rights reserved.</footer> 

      The page should now look like this:

      You can create the About and Offer pages in the same way—they will not have anything special in them (you can add their names as <h2> tags just above the content).


      Step 4: The Contact Form

      The last thing to do in HTML is the contact page. Copy the contents of your index.html to contact.html and remove the contents of the <main> element.

      Now add the heading for the form (into the <main> tag):

      <h2>Contact Us</h2> 

      After that we can add a <form> element with appropriate fields for the user to fill (since the server side of things stays pretty much the same I will not cover it here, so if you want to test your form you will have to write the back-end yourself):

      <form method="POST"> 
          <p> 
      	    <label for="name">Your name:</label> 
      		<input id="name" name="name"> 
      	</p> 
      	<p> 
      		<label for="email">Your email:</label> 
      		<input id="email" name="email"> 
      	</p> 
      	<p> 
      		<label for="message">Your message:</label> 
      		<textarea id="message"></textarea> 
      	</p> 
      	<button type="submit" value="Send">Send</button> 
      	<button type="reset" value="Reset">Reset</button> 
      </form>

      The <p> tags do not break the semanticity rule because the label and input combo is actually a paragraph. The contact page should look like this:

      The CSS

      Now that our page is working, we can start to make it look a bit better. Create a file and name it style.css. Now add this line to the <head> section of your document:

      <link rel="stylesheet" href="style.css"> 

      Step 5: Base Styles

      The first thing to do would be to change the fonts and overall shape of the page:

      * { font-family: Calibri, sans-serif; } 
      body { width: 900px; margin: auto; } 

      Two lines of CSS and you can see that the page looks a bit better as it's no longer using the default fonts.


      Step 6: The Header

      Now let's add some looks to the header: space it a bit, change the font size, and add the background:

      h1 { 
          padding: 100px 10px 20px; 
          margin: 0; 
          background: #dfdfdf; 
          font-weight: normal; 
          font-size: 3em; 
      } 

      Notice how we changed the font size—we used em instead of any other unit. This is because of the last of the rules explained in the first part of this series. Users can change the base size of the font and if we had, for example, used px, their settings would not be respected by our stylesheet.


      Step 7: The Menu

      After fixing the header's look, we can get on with the menu. We will also change the font size of the anchors, remove their underline, and add a background when they are hovered over or when they have an "active" class:

      nav { background: #aed8ff } 
      nav a { text-decoration: none; font-size: 1.3em; color: #333; padding: 15px 25px; display: inline-block; } 
      nav a:hover, nav a.active { background: #dfdfdf; color: #666; } 

      Now add the "active" class to the appropriate anchors in your files so they are "pressed" when the page is visited:

      <a href="index.html" class="active">Home</a>

      Here is how it should look like now:


      Step 8: The Content

      We will not do much here, just improve the readability a bit by increasing the line height (don't forget about users' settings—we can change the size of purely visual elements like headers and buttons, but users set their default font size for a reason). We'll also change the font and add some padding:

      p { 
          font-family: Helvetica, Arial, Sans-Serif; 
          line-height: 1.6; 
          text-align: justify; 
          padding: 10px; 
      } 

      Here is the result (notice how the readability improved with such a small change):


      Step 9: The Footer

      This will also be just a little, cosmetic change: background, padding, and centered text:

      footer { padding: 10px; background: #dfdfdf; text-align: center; }

      Here is how the footer looks like now:


      Step 10: The Form

      The last thing to do is to fix the looks of our contact form. First, let's remove the padding and margin of the <p> elements:

      form p { margin: 0; padding: 0; }

      Now let's set the width of the <input> elements and <textarea> to be the same. We also set display: block on them to line them up nicely:

      form input, form textarea { width: 300px; display: block; }

      Finally we change the <button>s to take up half of the form's width:

      form button { margin: 10px 0; padding: 5px; width: 148px; } 

      This is the final result:

      Conclusion

      This is the end of this part. In the next article, we will use some JavaScript (jQuery to be more exact) to add some interactive elements to our website.

      I guess some of you will think that this tutorial didn't show anything you didn't know about HTML or CSS. But look at it this way: We created a design that is based on its content and not on the designer's fantasy. Of course, it's pretty simple and not very good looking, but I didn't wanted to throw massive amounts of CSS and/or other assets here.

      The point is easy to see if you remove the stylesheet from the document—its layout stays the same and you can still use the page without problems.

       

      0 Comments

      Leave a comment › Posted in: Daily

  • Page 3 of 33 pages  < 1 2 3 4 5 >  Last ›
  • Browse the Blog

    Syndicate

    governing-bruise