Design and development community, Forrst, has announced a completely new and improved website experience.

Originally created by Kyle Bragger, the site was acquired by Zurb at the beginning of this year and the company has wasted no time building on and improving Forrst’s unique social feedback systems.

Forrst is similar to sites like Dribbble, which allow designers to post ideas and ask for feedback. What makes it stand out is that, in addition to visual concepts, members can also post code. A less tangible, but probably more important difference is the site’s commitment to facilitating detailed feedback and fostering an active community of web design and development peers.

Zurb has been transparent about their ideas for Forrst, posting plans for site updates and new features on their blog. About a month ago, they began a private release to iron out final details before making the changes public.

To make good on their promise to “turn Forrst into a place of active learning so that Forrsters can get actionable and contextual feedback,” the team has introduced:

• annotations (incorporating Notable, Zurb’s own feedback app);
• a new, less vertical design for the site;
• mobile-first functionality.

Annotations allow members to give detailed contextual feedback by highlighting areas of a post and adding sticky-like notes. For now, annotations can only be added from a desktop browser, but you will be able to read them from your mobile device.

The focus of the site design changes has been improving readability and discovery of posts. If you’re a longtime Forrst member, you’ll see the difference as soon as you land.

The mobile-first functionality is off to a good start, relying on Zurb’s existing Foundation 4 framework. At the moment, this means members can browse posts and leave feedback from just about anywhere.

More features are in the pipeline, including increased functionality for annotations, a re-think of the Forrst Leaderboard and a significant update to perks for Pro supporters.

If you are new to Forrst, you can sign up as a Scout. You become a full-fledged member once a Forrster has voted you in.

Do you use Forrst? Is Zurb acquiring Forrst a positive move for the community? Let us know in the comments.

MacDojo’s Mac Shortcuts Pro Course – only $27!

Welcome to the second part of my IndexedDB article. I strongly recommend reading the first article in this series, as I’ll be assuming you are familiar with all the concepts covered so far. In this article, we’re going to wrap up the CRUD aspects we didn’t finish before (specifically updating and deleting content), and then demonstrate a real world application that we will use to demonstrate other concepts in the final article.

Updating Records

Let’s start off by discussing how to update a record with IndexedDB. If you remember, adding data was pretty simple:

//Define a person
    var person = {
        name:name,
        email:email,
        created:new Date()
    }
    
    //Perform the add
    var request = store.add(person);
    

Updating a record is just as simple. Assuming that you have defined a property called id as your key for your object store, you can simply use the put method instead of add.

var person = {
        name:name,
        email:email,
        created:new Date(),
        id:someId
    }
    
    //Perform the update
    var request = store.put(person);
    

Like the add method, you can assign methods to handle the asynchronous results of the operation.

Deleting Records

Deleting records is done via the delete method. (Big surprise there.) You simply pass in the unique identifer of the record you want to remove. Here is a simple example:

var t = db.transaction(["people"], "readwrite");
    var request = t.objectStore("people").delete(thisId);
    

And like every other aspect of IndexedDB, you can add your handles for the asynchronous results.

So, as I said, not terribly exciting, which is probably good. You want your APIs simple, boring, and unsurprising. Now let’s take what we’ve learned and bring it together to create a real, if simple, application.

The Note App

Ok, finally we have all (well, most) of the parts we need to build a real application. Since it hasn’t been done before (ahem), we are going to build a simple note taking application. Let’s look at a few screen shots and then I’ll show you the code behind it. On launch, the application initializes an IndexedDB for the application and renders an empty table. Initially, all you can do with the application is add a new note. (We could make this a bit more user friendly perhaps.)

Clicking the Add Note button opens a form:

After entering some data in the form, you can then save the note:

As you can see, you have the option to edit and delete notes. Finally, if you click the row itself, you can read the note:

So not exactly rocket science, but a full working example of the IndexedDB specification. The notes written here will persist. You can close your browser, restart your machine, take a few years off to contemplate life and poetry, and when you open the browser again your data will still be there. Let’s take a look at the code now.

First – a disclaimer. This application would have been a perfect candidate for one of the many JavaScript frameworks. I’m sure those of you who use Backbone or Angular can already imagine how you would set this up. However – I made the bold decision here to not use a framework. I was worried both about the people who may use a different framework and those who use none. I wanted our focus here to be on the IndexedDB aspects alone. I fully expect some people to disagree with that decision, but let’s hash it out in the comments.

Our first template is the HTML file. We’ve only got one and most of it is boilerplate Bootstrap:

<!DOCTYPE html>
    <html lang="en">
      <head>
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
    
        <title>Note Database</title>
    
        <link href="bootstrap/css/bootstrap.css" rel="stylesheet">
        <link href="css/app.css" rel="stylesheet">
    
      </head>
    
      <body>
    
        <div class="navbar navbar-inverse navbar-fixed-top">
          <div class="container">
            <div class="navbar-header">
              <a class="navbar-brand" href="#">Note Database</a>
            </div>
          </div>
        </div>
    
        <div class="container">
    
            <div id="noteList"></div>
            <div class="pull-right"><button id="addNoteButton" class="btn btn-success">Add Note</button></div>
            <div id="noteDetail"></div>
    
            <div id="noteForm">
                <h2>Edit Note</h2>
                <form role="form" class="form-horizontal">
                <input type="hidden" id="key">
                <div class="form-group">
                    <label for="title" class="col-lg-2 control-label">Title</label>
                    <div class="col-lg-10">
                    <input type="text" id="title" required class="form-control">
                    </div>
                </div>
                <div class="form-group">
                    <label for="body" class="col-lg-2 control-label">Body</label>   
                    <div class="col-lg-10">
                    <textarea id="body" required class="form-control"></textarea>
                    </div>
                </div>
                <div class="form-group">
                    <div class="col-lg-offset-2 col-lg-10">
                        <button id="saveNoteButton" class="btn btn-default">Save Note</button>
                    </div>
                </div>
                </form>
            </div>
    
        </div>
    
        <script src="js/jquery-2.0.0.min.js"></script>
        <script src="bootstrap/js/bootstrap.min.js"></script>
        <script src="js/app.js"></script>
      </body>
    </html>
    

As mentioned above, a good size portion of this file is template code for Bootstrap. The parts we care about are the noteList div, the noteDetail div, and the noteForm. You can probably guess that these are the DIVs we’ll be updating as the user clicks around in the application.

Coding Our Core App File

Now let’s take a look at app.js, the core file that handles the logic for our application.

/* global console,$,document,window,alert */
    var db;
    
    function dtFormat(input) {
        if(!input) return "";
        var res = (input.getMonth()+1) + "/" + input.getDate() + "/" + input.getFullYear() + " ";
        var hour = input.getHours();
        var ampm = "AM";
        if(hour === 12) ampm = "PM";
        if(hour > 12){
            hour-=12;
            ampm = "PM";
        }
        var minute = input.getMinutes()+1;
        if(minute < 10) minute = "0" + minute;
        res += hour + ":" + minute + " " + ampm;
        return res;
    }
    

You can ignore the first function as it is simply a format utility for dates. Let’s skip ahead to the jQuery document ready block.

Checking for Browser Support

$(document).ready(function() {
    
        if(!("indexedDB" in window)) {
            alert("IndexedDB support required for this demo!");
            return;
        }
    
        var $noteDetail = $("#noteDetail");
        var $noteForm = $("#noteForm");
    
        var openRequest = window.indexedDB.open("nettuts_notes_1",1);
    
        openRequest.onerror = function(e) {
            console.log("Error opening db");
            console.dir(e);
        };
    
        openRequest.onupgradeneeded = function(e) {
    
            var thisDb = e.target.result;
            var objectStore;
    
            //Create Note OS
            if(!thisDb.objectStoreNames.contains("note")) {
                console.log("I need to make the note objectstore");
                objectStore = thisDb.createObjectStore("note", { keyPath: "id", autoIncrement:true });  
            }
    
        };
    
        openRequest.onsuccess = function(e) {
            db = e.target.result;
    
            db.onerror = function(event) {
              // Generic error handler for all errors targeted at this database's
              // requests!
              alert("Database error: " + event.target.errorCode);
              console.dir(event.target);
            };
    
            displayNotes();
    
        };
    

Our very first action is to check for IndexedDB support. If the user’s browser isn’t compatible, we use an alert and abort the function. It would probably be better to relocate them to a page that fully explains why they can’t use the application. (And to be clear, we could also build an application that made use of WebSQL as a backup. But again – my focus here is on simplicity.)

After caching a few jQuery selectors, that we’ll use throughout the app, we then open up our IndexedDB database. The database is fairly simple. In the onupgradeneeded handler you can see one object store called notes being created. Once everything is done, the onsuccess handler will fire off a call to displayNotes.

The displayNotes Function

    function displayNotes() {
    
            var transaction = db.transaction(["note"], "readonly");  
            var content="<table class='table table-bordered table-striped'><thead><tr><th>Title</th><th>Updated</th><th>&amp;nbsp;</td></thead><tbody>";
    
            transaction.oncomplete = function(event) {
                $("#noteList").html(content);
            };
    
            var handleResult = function(event) {  
              var cursor = event.target.result;  
              if (cursor) {  
                content += "<tr data-key=\""+cursor.key+"\"><td class=\"notetitle\">"+cursor.value.title+"</td>";
                content += "<td>"+dtFormat(cursor.value.updated)+"</td>";
    
                content += "<td><a class=\"btn btn-primary edit\">Edit</a> <a class=\"btn btn-danger delete\">Delete</a></td>";
                content +="</tr>";
                cursor.continue();  
              }  
              else {  
                content += "</tbody></table>";
              }  
            };
    
            var objectStore = transaction.objectStore("note");
    
            objectStore.openCursor().onsuccess = handleResult;
    
        }
    

The displayNotes function does what you expect – get all the data and display it. We discussed how to get all rows of data in the previous entry, but I want to point out something slightly different about this example. Note that we have a new event handler, oncomplete, that we’ve tied to the transaction itself. Previously, we’ve used events just within the actions, inside the transaction, but IndexedDB lets us do it at the top level as well. This becomes especially useful in a case like this. We have a giant string, our HTML table, that we build up over each iteration of our data. We can use the transaction’s oncomplete handler to wrap up the display portion and write it out using a simple jQuery call.

The Delete, Edit, and Add Functions

    $("#noteList").on("click", "a.delete", function(e) {
            var thisId = $(this).parent().parent().data("key");
    
            var t = db.transaction(["note"], "readwrite");
            var request = t.objectStore("note").delete(thisId);
            t.oncomplete = function(event) {
                displayNotes();
                $noteDetail.hide();
                $noteForm.hide();
            };
            return false;
        });
    
        $("#noteList").on("click", "a.edit", function(e) {
            var thisId = $(this).parent().parent().data("key");
    
            var request = db.transaction(["note"], "readwrite")  
                            .objectStore("note")  
                            .get(thisId);  
            request.onsuccess = function(event) {  
                var note = request.result;
                $("#key").val(note.id);
                $("#title").val(note.title);
                $("#body").val(note.body);
                $noteDetail.hide();
                $noteForm.show();
            };
    
            return false;
        });
    
        $("#noteList").on("click", "td", function() {
            var thisId = $(this).parent().data("key");
            var transaction = db.transaction(["note"]);  
            var objectStore = transaction.objectStore("note");  
            var request = objectStore.get(thisId);
    
            request.onsuccess = function(event) {  
                var note = request.result;
                $noteDetail.html("<h2>"+note.title+"</h2><p>"+note.body+"</p>").show();
                $noteForm.hide();
            };  
        });
    
        $("#addNoteButton").on("click", function(e) {
            $("#title").val("");
            $("#body").val("");
            $("#key").val("");
            $noteDetail.hide();
            $noteForm.show();       
        });
    

Our next two methods (delete and edit) is another example of this same principal. Since none of the IndexedDB calls here are new, we won’t bother going over them. Most of the “meat” here ends up being simple DOM manipulation to handle the particular actions. The handler for clicking the add button is exactly that, so we’ll skip over that as well.

The Save Function

    $("#saveNoteButton").on("click",function() {
    
            var title = $("#title").val();
            var body = $("#body").val();
            var key = $("#key").val();
    
            var t = db.transaction(["note"], "readwrite");
    
            if(key === "") {
                t.objectStore("note")
                                .add({title:title,body:body,updated:new Date()});
            } else {
                t.objectStore("note")
                                .put({title:title,body:body,updated:new Date(),id:Number(key)});
            }
    
            t.oncomplete = function(event) {
                $("#key").val("");
                $("#title").val("");
                $("#body").val("");
                displayNotes();
                $noteForm.hide();           
            };
    
            return false;
        });
    
    });
    

The next interesting tidbit is the save method. It has to use a bit of logic to determine if we are adding or updating, but even that is rather simple. And that’s it! A complete, if simple, IndexedDB application. You can play around with this demo yourself by downloading the attached source code.

In Conclusion

That’s it for part two! The third article will take this application and begin adding additional features including search and array based properties.

As many of you know, UMBC has had a large number of phishing attacks in the past few weeks.  This has resulted in a number of compromised accounts which the attackers are using to setup fake web pages and send out large volumes of spam.  In an attempt to better protect accounts from fake web pages, DoIT will be removing permissions from user AFS web volumes for accounts not currently using their web space (http://userpages.umbc.edu/~username).  

This will not affect anyone who currently has a web page or stop anyone from creating a web page, but will stop automated attacks and make it more difficult for attackers to setup web pages on people’s accounts.  The permission change is minor, and can be easily reversed by anyone wishing to use their web space moving forward.  

Directions for how to re-enable your web directory, as well as general information regarding using userpages, can be found at https://wiki.umbc.edu/pages/viewpage.action?pageId=31195980.  If you have questions or concerns please contact the Technology Support Center (x53838) and they will be happy to assist you.

As you know, there is a lot more to building responsive websites than width. You need sensors that give you feedback to adjust sites based on other factors.

The best way to improve our feedback from your user’s sensor, or browser, is by using a JavaScript library called Modernizr. In this article I’ll explain why, when you go beyond width, Modernizr is such an invaluable tool.

In front-end development, developers used to adjust a site to fit the constraints of the layout engine used by a particular browser. In 2003, there were only three browsers: Netscape, Internet Explorer, and Opera. Firefox, Safari, and the first mobile browser, Opera Mini, were released by 2005. Chrome wasn’t released until 2008.

Currently there are five major browsers, each with its own mobile version. Across that array of browsers, there are also older versions that users haven’t upgraded. In the same way that creating multiple layouts for multiple screen sizes eventually becomes a zero sum game, so does building multiple front-ends for multiple browsers.

We’re using responsive web design to accommodate new, cutting edge mobile browsers. But, while accommodating new browsers, it’s important not to do so at the expense of older browsers.

Historically, optimization has come as a product of building a site for the most popular browsers and then tweaking to ensure the site looks the same on a set of popular browsers. Designs would have to accommodate the capabilities of all browsers.

Progressive enhancement is one strategy to cope with browsers’ failure to support modern features. There is a temptation to build for the most up-to-date features, but, in a responsive web, the design of a site is contextual to the frame that it’s being viewed through. Responsive web design has become popular because it resolves the most obvious changing context — the size of the frame — but the context of a browser runs much deeper than it’s viewport size.

SVG makes for a great solution for high-resolution displays, but what about its support in older browsers? It’s not supported in IE 8 or older, so you have to build in a fallback if you support that browser. You could identify the browser and serve alternative styles against that browser but then you would have to serve those same alternative styles for every browser that doesn’t support SVG.

Wouldn’t it be easier if you could just write a style that would be used against every browser that didn’t support SVG? That way, you wouldn’t have to keep up with bug reports from the users of older versions. You could just set the fallback once and forget it.

Traditionally, feature detection has been accomplished by detecting the browser’s user agent. This is done through JavaScript, using the navigator object. The navigator object dates back to the Netscape days and used to be a developer’s best tool in cross-browser compatibility.

If you have Chrome and have enabled DevTools, open your browser’s web inspector by right-clicking on a page and selecting Inspect Element. Then, click on Console and, after the caret, type “navigator.userAgent” and hit Enter. This will return your current browser’s user-agent, which is a string of text used to identify the browser in use. Chrome returns the following:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.35 (KHTML, like Gecko) Chrome/27.0.1443.2 Safari/537.35

In a lot of ways, the navigator object is the one of the best sensors we have available to us to inform our system about what our user is capable of; however, it’s not very future friendly. It bases your site’s actuators on a lot of assumptions about what the browser does and does not support. It also is unreliable because users can configure it to access sites that the browser might not be able to support.

What Modernizr does

Modernizr is a JavaScript library used to detect features in the browser. It’s loaded in the head of your page and runs during a page load. Adding it to your site is as simple as adding any other JavaScript library, such as jQuery, but, once added, Modernizer gives you an incredible amount of control in rendering your page and ensuring that every user is served a quality experience.

Having been loaded, Modernizr runs a series of checks against the user’s browser to determine what features the browser supports and creates a JavaScript object that you can use to test against. Modernizr doesn’t create support for these features; it simply gives you a way to provide fallback support for modern features. For example, in the case of SVG, Modernizr enables us to provide a fallback image for browsers that lack SVG support.

Modernizr also applies a set of classes to the HTML tag, giving you the ability to modify the page’s CSS using the corresponding CSS classes. These CSS classes allow you to use CSS systems to build actuators that will adjust your pages to allow the progressive enhancements available for a page.

As opposed to using the User Agent, Modernizr detects features directly by running a series of JavaScript tests that return boolean (true or false) values. This dictates the classes that are set to the html tag and gives you the ability to use JavaScript to detect whether a feature is available.

Installing Modernizr

Installing Modernizr is as simple as linking to the JavaScript library in the head of your page, but where the installation process gets complicated is creating the version that you need. Modernizr is available for download in two versions, the development version and the production version.

The development version is a full 42 KB, uncompressed file. This version is great if you’re well versed in JavaScript and want to make some tweaks to the tests it performs. Because it’s uncompressed, it’s easy to read and augment but it’s best left to developers with a firm understanding of JavaScript.

For those of you who might not be completely adept at JavaScript, or would like to quickly build a customized version of Modernizr, this is where the production version of the library comes into play. The production version building tool on the site gives you the ability to create a version with only the tests you require.

This comes in handy when you know you only need a certain set of tests. For instance, your site might not take advantage of CSS box-shadows, but it might need to support CSS gradients. Using the build tool, you can include the tests you need and exclude the ones you don’t need, keeping the source code trim and your user’s total load time down.

For our example, I’ll be working of the development version. I find that when I’m building a site, it’s best to work with the full version and then once you know what features you’ll be using in your site, trim the version down.

Using Modernizr for cross-browser CSS

Let’s do some simple feature detection with Modernizr. We’ll start with a raw sample site.

<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<script type="text/javascript" src="js/modernizr.min.js"></script>
</head>
<body>
</body>
</html>

Let’s use this small test to detect whether or not our browser is capable of supporting SVG. For the sake of simplicity we’ll just add two span tags to the page to detect support.

<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<script type="text/javascript" src="js/modernizr.min.js"></script>
<style type="text/css">
.yes{color:green;}
.no{color:red;}
span{display:none;}
.svg .yes{display:inline;}
.no-svg .no{display:inline;}
</style>
</head>
<body>
<div>
<span class='yes'>Huzzah! You have SVG support.</span>
<span class='no'>BOO! You don't have SVG support.</span>
</div>
</body>
</html>

If you test this in a browser that supports SVG, you’ll see the message “Huzzah! You have SVG support.” whereas if you have a browser that fails to support SVG, you’ll find the “BOO! You don’t have SVG support.” message.

This example is pretty rudimentary, but it displays the core idea of using Modernizr to fix cross browser issues. If we were doing this same fix using the old user agent method, we would have to have a style sheet for each browser that doesn’t support SVG and change our CSS for each one. (For anyone interested, the only major browsers lacking SVG support are Internet Explorer 7 and under.)

By adding the svg/no-svg class to the html on the page, your CSS now has a selector that can be used to override existing CSS rules. Because it’s on the parent-most tag, it can used to override other classes on the page.

So, in this case, both span tags are given display:none;. If there is no SVG support, the display:inline declaration on the span tag with the .no class overrides the display:hidden thanks to the no-svg rule on the html tag.

Let’s try a more useful example of the same idea. We might want to have an SVG background image on the page, which falls back to a PNG if the browser doesn’t support SVG. By default we’ll use the PNG image. This way, the SVG isn’t served unless it’s needed and becomes a progressive enhancement.

<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<script type="text/javascript" src="js/modernizr.min.js"></script>
<style type="text/css">
.skull{
width:300px;
height:300px;
background-image:url(images/skull.png);
background-size:100% auto;
background-repeat: no-repeat;
}
.svg .skull{background-image:url(images/skull.svg);}
</style>
</head>
<body>
<div class='skull'></div>
</body>
</html>

Now we have an awesome SVG skull that will look awesome and crisp for users with high-resolution displays, and still look good for users with older browsers.

Summary

There is a great wealth of information to be learned about Modernizr. We showed you how it does the work of cross-browser capability without having to remember or maintain a running list of which browsers support SVG.

It functions exceptionally as a system with which to serve your user actuators to create speedy and highly functional websites.

Do you use Modernizr in your projects? What other methods have you used for serving responsive content? Let us know in the comments.

Featured image/thumbnail, divergent lines image via Shutterstock.

MacDojo’s Mac Shortcuts Pro Course – only $27!