We love web design resources, and we love them even more when they’re absolutely free. so each month we scour the Internet to bring you the very best free resources for web designers and developers.

This month we’ve included PSD resources, social network buttons, ribbons, mockups, guis of music players, app concepts, icons, plugins, fonts, templates, and much much more for you to amuse yourself creating everything you want, from personal blogs and experiments, to professional projects for your clients.

PSD ribbons

15 ribbons for all your projects.

High Tide

Unique linear font family.

600 Twitter buttons

Fully editable vector psd.

Time graph UI

Simple dashboard UI with all kinds of design elements.

Seasons ribbons

Realistic PSD graphic ribbons.

Play music player

Innovative music application interface.

Free flat devices PSD

A collection of different devices in flat style.

Norwester

Condensed geometric sans serif font with uppercase, small caps, numbers & symbols.

Freebee

Free PSD app concept.

Nauman regular

A modern humanist sans serif made for the screen.

Chooko

Theme for pages about cooking.

Svgeneration

Generate SVG backgrounds for web projects.

Silverleaf

A handdrawn serif web font.

Ikons

250+ scalable vector icons for developers.

Weather icons

40+ line weather icons for GUIs and mobile projects.

Mission Gothic

Retro styled typeface.

gmail.js

Javascript API for gmail.

36 tiny icons

Useful package of 32×32 icons for office apps.

Seomarketing

SEO enhanced WordPress theme.

Penthouse

Wide and clean theme for personal web pages.

48 rounded icons

Useful pack of line icons for dark backgrounds.

Zebrasil font

An elegant serif font.

50 glyphs

Icons for all kinds of purposes.

Wireframe kit

AI file with elements portraying web, tablet and mobile devices.

Flat admin template

Awesome looking interface with several types of visual statistics.

Baron

Decorative sans serif family of three completely different weights.

iconmelon

A library of animated SVG icons for the web.

Feather icon set

100 simple yet beautiful line icons.

Flozo

Theme for small and medium businesses.

iPhone 5s & iPad air mockups

A set of various mockups for presentations.

Calm

Flat portfolio template PSD.

Nice things

A set of daily icons.

Mohave

All caps typeface for large point settings.

Social subscribe widget

Widget with animated buttons.

Smallicons

50+ small flat and colorful icons.

Echo.js

Image lazy loading.

Vintage grunge textures

6 high resolution textures for all your projects.

Canaro

20th century geometric font.

Timeline menu

Modern timeline slider made in CSS3.

Tipue search

Site search engine plugin.

Flagship

Slab rounded font.

Touch gesture icons

Cool set of mobile gesture icons.

Moose

Minimal homepage PSD.

AC big serif

Font made combining big, thick serifs.

Social media badges

Package of 20 brilliant social media badges.

jQuery serial scroll

Versatile plugin that has several uses.

5 o’clock shadow icon set

Textured set of icons with a 5 o’clock long shadow.

Oridomi

Plugin to flex images like paper.

Stationery mockup

Essential elements to showcase your brand.

Which of these freebies is your favourite? Have we missed a resource you rely on? Let us know in the comments.

Become a Successful eBook Author with ‘Authority’ – only $19!

A while back, I wrote a post about starting an open-source project. The focus of that article was on starting an open-source project as an individual. I received a lot of positive feedback and also some questions about how the process changes when you’re open-sourcing a project at work.

Open source projects are always a team effort, and they always require a dedicated commitment to the project. Image credit: open source way

Many companies are starting to investigate and participate in the open-source community, and yet few guides for doing so exist. This article focuses primarily on the process of open-sourcing a project at work, which brings with it other concerns and decisions.

Why Open Source?

Before delving into the how, it’s useful to step back and talk about the why. Why is it that so many companies have or are starting to establish an open-source presence? There are actually a number of reasons:

• Technical brand
  Companies want to be known as a place where smart people work. One excellent way to show this is by releasing code that has been written at the company. Doing so creates mindshare in the community, familiarity with the company and its contributions, and fodder for future technical brand initiatives (such as giving talks at meetups and conferences).
• Recruiting
  Time and again, you’ll see contributors joining companies that sponsor open-source projects. I saw this happen frequently while at Yahoo, where YUI contributors would sometimes end up as Yahoo employees after having contributed to the project on an ongoing basis. Similar hires have occurred in the Node.js community. The reason is pretty clear: If you work on an open-source project in your spare time, imagine how great it would be to turn that hobby into a job. Additionally, allowing job candidates to see some of the company’s code gives some good insight into what working at the company would be like.
• Giving back
  A lot of companies benefit from open-source software, and contributing open-source software back into the world is a way of giving back. These days, it’s part of what it means to be involved in the technical community. When you receive, find a way to give back. A lot of companies are embracing this philosophy.

There are many more reasons why companies are choosing to open-source, but these are the primary drivers. Therefore, the process of open-sourcing a project must be aligned with these goals while protecting the company’s interests.

Getting Started

Suppose someone at your company wants to open-source something. This has never happened before and you’re not sure what to do. Do you just put it up on GitHub? Announce it in a press release or blog post? How do you know that the code is OK to open-source? There is a lot of planning to do, and it all starts (unfortunately) with the legal department.

Giving away company assets is as much a legal issue as anything else. The very first conversation should be with an appropriate member of your company’s legal team to discuss the ins and outs of open-sourcing. In larger companies, one or more intellectual property (IP) attorneys are likely on staff or on retainer; in smaller companies, this conversation might start with the general counsel. In either case, it’s important to lay out exactly what you want to do and to clarify that you’d like to formalize a repeatable process for open-sourcing projects.

The primary legal concerns tend to be around licensing, code ownership and trade secrets. These are all important to discuss openly. Because many companies have done this already, you should have a fair amount of evidence of how other companies have established their processes. The most important thing is to engage the legal department early in the process and to have a champion on the legal team who you can work with should any issues arise.

Choose A Default License

One of the first topics of discussion should be which open-source license the company will use as its standard. Leaving the team for each project to decide for itself which license to use is a bad idea, because a lack of awareness could quite possibly lead to two projects from the same company having incompatible licenses. Decide up front exactly which license to use, and use it for all open-source projects in your company.

I touched on the different types of licenses in my previous article (also, see “Understanding Copyright and Licenses”). In general, companies tend to standardize either the three-clause BSD license or the Apache license. Very rarely will a company standardize the MIT license, because the standard MIT license doesn’t contain a clause that prevents use of the company’s name in advertisements for software that makes use of the project. The Apache license has additional clauses related to patent protection, which some companies prefer.

The ultimate choice of a license typically comes down to legal considerations on the nature of the code being released. The philosophical implications of which license you choose are not important; using the same license for all projects in your company is important.

Outgoing Review

The next topic of discussion should be to define an outgoing review process. Just putting code out in the public without some sort of review is neither safe nor sane. In general, a request to open-source a project should be reviewed by the following:

• Legal
  As mentioned, the legal department needs to be kept in the loop during this process. They will likely not review the code, but rather will want to understand what the code does and whether it could be considered a company secret.
• Security
  Someone with a security mindset should actually look at the code to make sure it doesn’t reveal any security issues or contain code that should not be made public. This process could be manual or automated, depending on the complexity of the code.
• Executive
  Someone on the executive team needs to approve the request, basically saying that they believe this code is safe to share and that they are aware that the code is being published.

Exactly how an outgoing review gets started tends to be company-specific. It could be done by submitting a request to a mailing list, filling out a form or just setting up a meeting. How it’s implemented isn’t as important as the fact that the review occurs and is done quickly. So, setting a deadline for a response is a good idea. Depending on the size of the company, this could range from a few days to a few weeks, but setting up the expectation ahead of time helps to alleviate any scheduling issues.

Accepting Contributions

One part of the process that is often forgotten is figuring out rules for accepting external contributions. Open-sourcing a project is basically a way of saying, “Hey, we’d love to have you fix our bugs!” Part of the point is to get people interested enough to want to contribute to the project. Establish a process so that you know how and from whom external contributions may be made.

When building something, accepting external contributions can significantly benefit the project, but you need to establish a process for contributions first. Image credit: open source way.

The company should require a contributor license agreement (CLA) to be signed before accepting contributions from external developers. A CLA is a legal document that typically states a few things:

• The contributor asserts that they are the original author of the code they are submitting.
• The contributor grants the project the right to use and distribute the code they are submitting.
• The contributor has the right to grant the previous two points.
• Any code submitted by a contributor is not guaranteed to be accepted or used.

Take the Node.js CLA. It’s a pretty straightforward form that defines the expectations for contributors and asks for the contributor’s name and other information. These days, asking for someone’s GitHub user name as well is quite common (to help automate the process of checking CLAs for commits).

The CLA will be important should any legal action be taken against your company as a result of the code contained in the project. Because the company is the maintainer of the project, any legal action would likely be directed at the company itself, rather than any individual contributor.

CLAs are sometimes controversial, and some developers refuse to sign them. That’s an acceptable loss to protect yourself and your company from the legal risks of open-source projects. Those who are familiar with the open-source community and the reason behind CLAs will be more than happy to sign on and contribute to your project.

Maintaining The Project

An overlooked part of the open-source process is maintaining the project once it’s been published. Many developers (and some companies) view the step of open-sourcing a project as the end of the process — they’ve already spent considerable time creating software that they now want to share with the world. In truth, open-sourcing a project is the beginning of a journey. The act of sharing now makes it, effectively, communal software, and you can now expect the project to be discussed and to evolve as a whole.

Once a new project is open-sourced, eventually you’ll start receiving suggestions, requests and pull-requests. Maintenance is a task that is often overlooked in open-source projects. Image credit.

Many companies that are new to the open-source community make the mistake of publishing their code and leaving it behind. Issues are left unresolved and unanswered, road maps are not shared, pull requests are ignored, and there is no way to get in contact with the people behind the project. As much as open-source projects can enhance your technical brand, leaving projects in this state can hurt it.

Once you’ve open-sourced a project, you must commit to maintain it. Even stable software will have bugs, and some of those bugs could be found by people outside of your company. If you have no intention of interacting with anyone outside of the company on this project, then you might want to consider simply distributing the compiled binary or library freely, and not actually open-sourcing the code.

While there are no established rules for maintaining a project, here are some guidelines I follow:

1. The public repo is the source of truth.
   Once you’ve published your source code to a public repository (or repo), all development should happen in that repository. The public repo shouldn’t simply be a clone of an internal one. If the project is being actively developed, then that development should happen exclusively in the public repo in order to be as transparent as possible. Developing in private and then updating periodically prevents the use of pull requests and makes forking your project extremely difficult and frustrating.
2. Plan in public.
   Use a public bug tracker to track all issues, so that others can see what’s being worked on and what’s already been reported. Post a road map somewhere public that shows plans for development. Be as transparent about the development process as possible. In short, open-source the way your project will grow and evolve.
3. Dedicate company time.
   If you are the primary author of the project and you’ve open-sourced the code, then you (or a delegate) should set aside time to interact with external contributors. That means making timely responses to pull requests and issues, which in turn means setting aside time daily or weekly. This has now become part of your full-time job, not just a hobby.
4. Open channels of communication.
   Give external contributors a way to interact directly with the maintainers. This could be through a forum, mailing list, IRC chat or another channel. Make sure that these systems are public; for example, an IRC chat should not be on your company’s chat server. Plenty of free communication services exist to make use of. The simplest and least disruptive method is to create a free mailing list using Google Groups or Yahoo Groups.
5. Commit to document.
   Lack of documentation is a huge problem with open-source projects. From the start, commit to writing good documentation that explains not only how to use the project but also how to set up a development environment, run tests and work effectively with the code as a contributor. There is no better way to discourage people from using your software than to give them no way to get up and running on their own.
6. Maintain regular outgoing communication.
   There should be a steady stream of outgoing communication about the project. At a minimum, post announcements about new releases and security issues that require immediate upgrading. Maintain changelogs that describe differences between versions, and follow a predictable and regular scheme in your versioning (such as by following semantic versioning). This will help both users and contributors understand the impact of filing issues and submitting pull requests.

An open-source project very quickly takes on a life of its own once released. If a community forms around the project, then it could take up more and more of your time. That’s why a commitment to maintain the project needs to be a part of the open-sourcing process. Letting a project languish without any attention sends a horrible message to those outside of your company and will discourage people from contributing.

Warning Signs

Most open-source projects, whether by individuals or companies, are started with the best of intentions. Typically, the goal is to share learning and code with the world. However, the Internet is littered with abandoned projects. If your project ends up like this, it could hurt your and your company’s reputation. Projects slowly decay over time and can usually be identified by one or more of the following characteristics:

• “Not enough time”
  The more frequently this phrase appears in responses to pull requests and issues, the more likely the project is headed for the graveyard. This is one of the top reasons why projects die: The maintainer runs out of time to maintain it. As should be obvious from this article, maintaining a project requires a significant amount of work, which is frequently not sustainable in the long term.
• Too few contributors
  If most contributions come from one person, then the project is likely either early in its life (on the upswing) or close to the end. You can easily tell which is the case by looking at the date of the first commit. Thriving projects tend to have a large number of commits from the maintainer and a small number of frequent commits from a few others. Another good way to measure this activity is in the number of merged pull requests in the last year.
• Too many open issues and pull requests
  A surefire sign that a project is on its way out is issues and pull requests that are left open with no comment. More than a few issues that have been open for a year means that the project isn’t being cared for.
• No way to contact the maintainer
  If you can’t find a reliable way to contact the maintainer, whether through email, a mailing list, Twitter, issues or pull requests, then there’s not much hope for the project. Maintainers aren’t maintaining if they aren’t communicating.

Keep an eye on these patterns in your own project. If you recognize the warning signs, then you’ll have to decide what to do with the project. Either someone else should become the maintainer or it’s time to end-of-life the project.

End-Of-Lifing Projects

At some point, you or your company might find that there is no longer interest in maintaining the project. This is a natural evolution of software — sometimes a project outlives its usefulness. When this happens, you need to appropriately end-of-life the project.

End-of-lifing typically starts with a public announcement that the project is no longer being actively maintained (along with a post in the project’s README file). The announcement should address the following:

• Why is the project being end-of-lifed? Has it been superseded by something else? Is it no longer in use? Do you recommend different software written by someone else?
• What will happen to outstanding issues? Will bugs still be fixed? Will all outstanding issues be closed without being fixed?
• Is there an opportunity to transfer ownership? If someone really likes the project, is your company willing to transfer ownership to them or their organization?

Ultimately, you might decide to delete the repository completely. While being able to see all of a company’s projects, even those that have been end-of-lifed, is sometimes nice, that comes at a cost, and so removing repositories from time to time might be prudent. In doing so, be certain that you have effectively communicated that the project is going away, and give at least 30 days notice to allow others to fork the project if they are so inclined.

Conclusion

Open-sourcing projects at work is a great initiative for many reasons. When done correctly, an open-source presence will do a lot to promote your company and its employees. Active open-source involvement signals your company’s willingness to interact with the technical community and to contribute back, both signs of a strong technical brand.

On the other hand, a poor open-source presence is worse than no presence at all. It signals general laziness or apathy towards a community of developers, a community that might very well want to help your project succeed. Few things are as demoralizing as trying to work on an open-source project that has been abandoned. Don’t be that company.

(al)

© Nicholas C. Zakas for Smashing Magazine, 2013.

The tragic images of brutalized masses scar our brains.

The Holocaust has long been a sad and grotesque chapter in the world’s history.

For decades historians have struggled to find an essential missing element of the calamity: the diary of Alfred Rosenberg.

Alfred Rosenberg was the central ideologist of the Nazi Party and a top aid to Adolf Hitler. He provided the basic anti-Semitic and racial ideologies that fueled the Holocaust. 

It was assumed that Rosenberg’s diary had been permanently lost following the Nuremberg Trials. However, after an extensive investigation, the Department of Homeland Security recovered the lost artifact. 

The United States Holocaust Memorial Museum just recently released the diary to the public by publishing it online. 

Museum director Sara Bloomfield asserts that: 

“The Rosenberg diary will add to our understanding of the ideas that animated the extremist ideology of Nazism.” 

The diary will undoubtedly add to the understanding of the Holocaust, but can it do more? 

Does this diary have the ability to create a deeper understanding that will prevent future genocide?

Or is it merely a fascinating relic? 

Welcome to the final part of my IndexedDB series. When I began this series my intent was to explain a technology that is not always the most… friendly one to work with. In fact, when I first tried working with IndexedDB, last year, my initial reaction was somewhat negative (“Somewhat negative” much like the Universe is “somewhat old.”). It’s been a long journey, but I finally feel somewhat comfortable working with IndexedDB and I respect what it allows. It is still a technology that can’t be used everywhere (it sadly missed being added to iOS7), but I truly believe it is a technology folks can learn and make use of today.

In this final article, we’re going to demonstrate some additional concepts that build upon the “full” demo we built in the last article. To be clear, you must be caught up on the series or this entry will be difficult to follow, so you may also want to check out part one.

Counting Data

Let’s start with something simple. Imagine you want to add paging to your data. How would you get a count of your data so you can properly handle that feature? I’ve already shown you how you can get all your data and certainly you could use that as a way to count data, but that requires fetching everything. If your local database is huge, that could be slow. Luckily the IndexedDB spec provides a much simpler way of doing it.

The count() method, run on an objectStore, will return a count of data. Like everything else we’ve done this will be asynchronous, but you can simplify the code down to one call. For our note database, I’ve written a function called doCount() that does just this:

function doCount() {
    
        db.transaction(["note"],"readonly").objectStore("note").count().onsuccess = function(event) {
            $("#sizeSpan").text("("+event.target.result+" Notes Total)");
        };
    
    }
    

Remember – if the code above is a bit hard to follow, you can break it up into multiple blocks. See the earlier articles where I demonstrated this. The result handler is passed a result value representing the total number of objects available in the store. I modified the UI of our demo to include an empty span in the header.

<span class="navbar-brand" >Note Database <span id="sizeSpan"></span></span>
    

The final thing I need to do is simply add a call to doCount when the application starts up and after any add or delete operation. Here is one example from the success handler for opening the database.

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);
        };
    
        displayNotes();
        doCount();
    };
    

You can find the full example in the zip you downloaded as fulldemo2. (As an FYI, fulldemo1 is the application as it was at the end of the previous article.)

Filter As You Type

For our next feature, we’re going to add a basic filter to the note list. In the earlier articles in this series I covered how IndexedDB does not allow for free form search. You can’t (well, not easily) search content that contains a keyword. But with the power of ranges, it is easy to at least support matching at the beginning of a string.

If you remember, a range allows us to grab data from a store that either begins with a certain value, ends with a value, or lies in between. We can use this to implement a basic filter against the title of our note fields. First, we need to add an index for this property. Remember, this can only be done in the onupgradeneeded event.

    if(!thisDb.objectStoreNames.contains("note")) {
            console.log("I need to make the note objectstore");
            objectStore = thisDb.createObjectStore("note", { keyPath: "id", autoIncrement:true });
            objectStore.createIndex("title", "title", { unique: false });
        }
    

Next, I added a simple form field to the UI:

Then I added a “keyup” handler to the field so I’d see immediate updates while I type.

$("#filterField").on("keyup", function(e) {
        var filter = $(this).val();
        displayNotes(filter);
    });
    

Notice how I’m calling displayNotes. This is the same function I used before to display everything. I’m going to update it to support both a “get everything” action as well as a “get filtered” type action. Let’s take a look at it.

function displayNotes(filter) {
    
        var transaction = db.transaction(["note"], "readonly");  
        var content="<table class='table table-bordered table-striped'><thead><tr><th>Title</th><th>Updated</th><th>& </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");
    
        if(filter) {
            //Credit: http://stackoverflow.com/a/8961462/52160
            var range = IDBKeyRange.bound(filter, filter + "\uffff");
            var index = objectStore.index("title");
            index.openCursor(range).onsuccess = handleResult;
        } else {
            objectStore.openCursor().onsuccess = handleResult;
        }
    
    }
    

To be clear, the only change here is at the bottom. Opening a cursor with or without a range gives us the same type of event handler result. That’s handy then as it makes this update so trivial. The only complex aspect is in actually building the range. Notice what I’ve done here. The input, filter, is what the user typed. So imagine this is “The”. We want to find notes with a title that begins with “The” and ends in any character. This can be done by simply setting the far end of the range to a high ASCII character. I can’t take credit for this idea. See the StackOverflow link in the code for attribution.

You can find this demo in the fulldemo3 folder. Note that this is using a new database so if you’ve run the previous examples, this one will be empty when you first run it.

While this works, it has one small problem. Imagine a note titled, “Saints Rule.” (Because they do. Just saying.) Most likely you will try to search for this by typing “saints”. If you do this, the filter won’t work because it is case sensitive. How do we get around it?

One way is to simply store a copy of our title in lowercase. This is relatively easy to do. First, I modified the index to use a new property called titlelc.

        objectStore.createIndex("titlelc", "titlelc", { unique: false });
    

Then I modified the code that stores notes to create a copy of the field:

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

Finally, I modified the search to simply lowercase user input. That way if you enter “Saints” it will work just as well as entering “saints.”

        filter = filter.toLowerCase();
            var range = IDBKeyRange.bound(filter, filter + "\uffff");
            var index = objectStore.index("titlelc");
    

That’s it. You can find this version as fulldemo4.

Working With Array Properties

For our final improvement, I’m going to add a new feature to our Note application – tagging. This will
let you add any number of tags (think keywords that describe the note) so that you can later find other
notes with the same tag. Tags will be stored as an array. That by itself isn’t such a big deal. I mentioned in the beginning of this series that you could easily store arrays as properties. What is a bit more complex is handling the search. Let’s begin by making it so you can add tags to a note.

First, I modified my note form to have a new input field. This will allow the user to enter tags separated by a comma:

I can save this by simply updating my code that handles Note creation/updating.

    var tags = [];
        var tagString = $("#tags").val();
        if(tagString.length) tags = tagString.split(",");
    

Notice that I’m defaulting the value to an empty array. I only populate it if you typed something in. Saving this is as simple as appending it to the object we pass to IndexedDB:

    if(key === "") {
            t.objectStore("note")
                            .add({title:title,body:body,updated:new Date(),titlelc:titlelc,tags:tags});
        } else {
            t.objectStore("note")
                            .put({title:title,body:body,updated:new Date(),id:Number(key),titlelc:titlelc,tags:tags});
        }
    

That’s it. If you write a few notes and open up Chrome’s Resources tab, you can actually see the data being stored.

Now let’s add tags to the view when you display a note. For my application, I decided on a simple use case for this. When a note is displayed, if there are tags I’ll list them out. Each tag will be a link. If you click that link, I’ll show you a list of related notes using the same tag. Let’s look at that logic first.

function displayNote(id) {
        var transaction = db.transaction(["note"]);  
        var objectStore = transaction.objectStore("note");  
        var request = objectStore.get(id);
    
        request.onsuccess = function(event) {  
            var note = request.result;
            var content = "<h2>" + note.title + "</h2>"; 
            if(note.tags.length > 0) {
                content += "<strong>Tags:</strong> ";
                note.tags.forEach(function(elm,idx,arr) {
                    content += "<a class='tagLookup' title='Click for Related Notes' data-noteid='"+note.id+"'> " + elm + "</a> ";  
                });
                content += "<br/><div id='relatedNotesDisplay'></div>";
            }
            content += "<p>" + note.body + "</p>";
             I
            $noteDetail.html(content).show();
            $noteForm.hide();           
        };  
    }
    

This function (a new addition to our application) handles the note display code formally bound to the table cell click event. I needed a more abstract version of the code so this fulfills that purpose. For the most part it’s the same, but note the logic to check the length of the tags property. If the array is not empty, the content is updated to include a simple list of tags. Each one is wrapped in a link with a particular class I’ll use for lookup later. I’ve also added a div specifically to handle that search.

At this point, I’ve got the ability to add tags to a note as well as display them later. I’ve also planned to allow the user to click those tags so they can find other notes using the same tag. Now here comes the complex part.

You’ve seen how you can fetch content based on an index. But how does that work with array properties? Turns out – the spec has a specific flag for dealing with this: multiEntry. When creating an array-based index, you must set this value to true. Here is how my application handles it:

objectStore.createIndex("tags","tags", {unique:false,multiEntry:true});
    

That handles the storage aspect well. Now let’s talk about search. Here is the click handler for the tag link class:

$(document).on("click", ".tagLookup", function(e) {
        var tag = e.target.text;
        var parentNote = $(this).data("noteid");
        var doneOne = false;
        var content = "<strong>Related Notes:</strong><br/>";
    
        var transaction = db.transaction(["note"], "readonly");
        var objectStore = transaction.objectStore("note");
        var tagIndex = objectStore.index("tags");
        var range = IDBKeyRange.only(tag);
    
        transaction.oncomplete = function(event) {
            if(!doneOne) {
                content += "No other notes used this tag."; 
            }
            content += "<p/>";
            $("#relatedNotesDisplay").html(content);
        };
    
        var handleResult = function(event) {
            var cursor = event.target.result;
            if(cursor) {
                if(cursor.value.id != parentNote) {
                    doneOne = true;
                    content += "<a class='loadNote' data-noteid='"+cursor.value.id+"'>" + cursor.value.title + "</a><br/> ";
                }
                cursor.continue();
            }           
        };
    
        tagIndex.openCursor(range).onsuccess = handleResult;
    
    });
    

There’s quite a bit here – but honestly – it is very similar to what we’ve dicussed before. When you click a tag, my code begins by grabbing the text of the link for the tag value. I create my transaction, objectstore, and index objects as you’ve seen before. The range is new this time. Instead of creating a range from something and to something, we can use the only() api to specify that we want a range of only one value. And yes – that seemed weird to me as well. But it works great. You can see then we open the cursor and we can iterate over the results as before. There is a bit of additional code to handle cases where there may be no matches. I also take note of the original note, i.e. the one you are viewing now, so that I don’t display it as well. And that’s really it. I’ve got one last bit of code that handles click events on those related notes so you can view them easily:

$(document).on("click", ".loadNote", function(e) {
        var noteId = $(this).data("noteid");
        displayNote(noteId);
    });
    

You can find this demo in the folder fulldemo5.

Conclusion

I sincerely hope that this series has been helpful to you. As I said in the beginning, IndexedDB was not a technology I enjoyed using. The more I worked with it, and the more I began to wrap my head around how it did things, the more I began to appreciate how much this technology could help us as web developers. It definitely has room to grow, and I can definitely see people preferring to use wrapper libraries to simplify things, but I think the future for this feature is great!