Nowadays, you’ll have a hard time finding a professional developer who doesn’t use a version control system (VCS) such as Git.

But, there are still a few among us who choose not to use a VCS due to preconceived notions they might have about version control.

Here are some myths and excuses that dissuade developers from integrating Git — and any version control system in general — into their workflow.

Myth 1: I don’t need Git because I back up my files

Creating regular backups of your work is definitely a good habit. Consider keeping this habit even when using Git.

But Git provides you a lot more benefits compared to just a system of backing up your files.

Without a VCS, you’ll run into a several of issues.

How do you name your backups? If you’re a very organized person, you might be able to stick to an actually comprehendible naming scheme like acme-inc-redesign_2013-11-12_v23.html. However, any deviance from the file-naming convention quickly leads to confusion and, quite possibly, issues with your code.

Let a system like Git worry about the minutia so that you can focus on what you do best: Writing code.

How much of your work are you saving? Only the changed files or the complete project? In the case of the former, it will be tough to see a full picture of a version/variant of your project at any given time. In the case of the latter, where you are backing up the entire codebase at regular intervals, you’ll have huge amounts of redundant files lying around on your hard drive, and more files mean more complications.

The most important issue that can be solved with Git is probably this one:

How do you know what’s different in these backups? Very few people actually take the time to carefully document each and every change they make. On the other hand, Git acknowledges that there is only one project. Everything else — all the past versions and variants — are neatly tucked away in the back-end of the version control system, ready for you whenever you need it. And when you do need it, you can request any version at any time and you’ll have a snapshot of the complete project right at hand.

In addition, you can determine with great precision what has changed in each file. You can tell which lines have been added, which lines have been removed, and which ones have been modified — which means that bug-tracing, emergency rollbacks to stable versions of the project and partial-version rollbacks are much easier processes.

Myth 2: Git is too complicated. It’s not worth the hassle.

People often overestimate how deeply they need to dive into Git to get its main benefits.

It’s true that you can spend a whole lot of time trying to wrap your head around all the fanciest, edge-case Git commands — Git is indeed an extremely powerful and flexible system.

But, it’s also true that you can work productively and reap Git’s major perks with just a handful of commands.

Yes, learning a new skill means more additional work — no one can spare you from that — but the benefits you’ll gain when you start using Git vastly outweighs the time and effort required to learn it.

Learning Git will improve your projects’ quality, as well as your efficiency and productivity as a developer. Also, you will be able to collaborate with other developers in a more systematic and reliable way, delivering even more development-productivity improvements to you and your team.

Myth 3: Git is only for development teams

Distributed version control systems like Git or Mercurial allow you to work completely on your local computer. Should you have projects where you don’t collaborate with anyone else, it’s perfectly valid to perform all tasks on your machine. Git provides as much benefit to the solo developer as it does to dev teams.

You don’t need a remote server or code-hosting service to use Git and to reap its usefulness.

But, it’s worth pointing out that using a remote code-hosting service like GitHub makes sense even as a solo developer, so that you can have external backups of your code in case your computer breaks down or gets lost, or to sync your projects safely across multiple computers (perhaps you have a work laptop and a personal computer at home that you use to develop code with). However, this isn’t necessarily something you need to do; it’s only an optional advantage.

The benefits that Git brings you remain the same, no matter if you’re working in a team or on your own.

Myth 4: The command-line interface is too complicated

You don’t need to be a command-line interface (CLI) expert to use Git. In fact, a handful of commands is all most developers will ever need.

You can learn Git’s important commands in less than an afternoon: We created a guide called Command Line 101 that you can read to learn about the CLI as it pertains to Git — it’s part of our free online book called Learn Version Control with Git: A step-by-step course for the complete beginner.

But let’s just say a handful of basic commands is still too much contact with the CLI for you. Or maybe you made a strange, unbreakable blood pact with a friend never to use the command-line interface ever again, or, for some reason, you simply cannot use a CLI. You can still use Git through an application that has a graphical user interface (GUI). If you’re on Windows, I recommend you take a look at Tortoise Git. On Mac OS, you should give Tower — an app that my company, fournova, has developed — a look-see.

Even for users that are comfortable with the command line, a GUI could still improve productivity by making complex Git tasks easier.

Myth 5: I’m afraid I’ll break something

It should be the other way around: You should be afraid to break things if you don’t use a version control system because it’s hard to retrace your steps and your code-base changes without one.

Version control is our safety net. When things catastrophically break down, we can easily roll back to a previous version that’s stable.

Using Git, you will be able to:

  • undo your local changes (partially or completely)
  • restore any historic version in case something goes wrong
  • revert the effect of any change you made in the past

And I would also like to point out what is in my opinion Git’s most important feature: branches.

Branches provide us with a secure ecosystem for trying out new features, completely separated from other parts of our development project. This encourages us to experiment with new code and to see and test the effects of any code changes while giving us the confidence that we won’t be affecting anything outside of the current branch.

Myth 6: Git is all hype. It’s just a popular trend that will later fade away.

First, Git is definitely not the one and only version control system out there. There are many other great VCS options to consider, each one with its own unique merits.

But it’s not simply by chance that major projects such as jQuery, Rails and the Linux Kernel, just to name a few, rely on Git for version control and code-collaboration.

For coding projects, Git is currently one of the best systems out there. Here are several reasons why Git is a great choice.

Feature Set

Of course, Git’s feature set and philosophy are its biggest value propositions to its users: A great branching model, offline capability, and its "staging area" concept are just some of the prime features that help with the productivity, creativity and efficiency of developers.

Popularity and Staying Power

Being popular and widely available is important for any system. Popularity means there’s a community out there ready to help you get started with the system.

And when you find yourself coding collaboratively, there’s a greater chance your teammates will already know how to use Git.

In addition, being a popular VCS also makes Git attractive for third parties to develop and provide supporting tools and services (e.g. GitHub) that could further enhance your experience with Git.

Popularity also ensures that the Git open source project won’t disappear any time soon — which is an important factor for developers thinking about committing to an open source project for the long-haul.

Official Git website home page (2014).Official Git website home page (2014)

Availability of Quality Educational Materials

It has never been easier to start learning Git. Today, there are tons of documentation, tutorials, videos and how-tos available about the VCS.

Here are a few resources to help you get started with Git.

Why Aren’t You Using Git Yet?

Now over to you: What’s holding you back from using version control with Git? Let us know in the comments!

Related Content

About the Author

Tobias Günther is CEO and founder of fournova. In 2010, he set out to make Git easier to use: Together with his team, he develops the Git desktop client, Tower for Mac.

The post 6 Myths Preventing Developers from Using Git appeared first on Six Revisions.

Several years ago, researchers at MIT confirmed through a study that fonts can impact how we feel: A bad font can make us frown unconsciously, while a good font can make us feel happy.

If fonts can influence our emotions, then they can certainly impact the user experience.

A few weeks ago, I decided to find out how much of an impact fonts have on UX.

Through a series of split test experiments, I managed to improve my site’s engagement by 38%. I did this by changing nothing but the font styling of the site.

Before I go into the details of my experiment, I want to first explain why fonts can have a surprisingly large power over how our users interpret our content.

How fonts impact our emotions

Fonts affect our emotions in two ways.

Cognitive bias

Firstly, we associate certain connotations to specific fonts and font styles. This, like many other things in our world, is often influenced by our cognitive biases and the culture we grow up in. For instance, sans serif fonts are commonly used on official U.S. government forms. But, in England, sans serif fonts are more commonly used by tabloids.

The context in which different fonts are used changes how we feel when we see them.

Take a look at the two screenshots below from my company’s blog, featuring a guide on building a WordPress site, set using two very different fonts.

Notice how the same content can convey a vastly different message depending on the font you use to present it.

Version 1: The site’s normal fonts

Version 2: Comic Sans font

The second version comes across as far less trustworthy and professional. This is not due to the curvature and spacing of the letters or any other typographic characteristic of the font. It’s due to the fact we’ve learned to associate comic sans with childishness.

Objective readability

On top of all that, some fonts are inherently easier to read than others. And the harder our eyes and brains have to work to interpret a piece of text, the worse we report feeling afterwards.

Serif fonts were originally used by the print press, as serifs are proven to help the eye move from letter to letter faster.

When computers were first used, computer screens had low resolutions. Serif fonts had to be created using vectors, which just didn’t look right with the low pixel-density available back in the days. So, early designers defaulted to using sans serif fonts, which were created as bitmaps.

Screen resolutions have come along way over the past few decades. We’re at a point where pixels are barely recognizable up close. As such, serif fonts liked Georgia are becoming more and more popular.

Experimenting with fonts

When experimenting with fonts, the first question I wanted to answer was, of course, which font is best for our website?

I ran an initial split test on one of our articles where I tested three different fonts: Georgia, Arial, and Verdana.

We measured the performance of each font by the number of clicks on the article, in combination with behavioral metrics like bounce rate and time-on-page.

Here are text-block snippets of the fonts we tested so that you may get a visual idea about the variants we tested.

Georgia

Georgia font being tested for UX.

Arial

Arial font being tested for UX.

Verdana

Verdana font being tested for UX.

I anticipated that Georgia would win (because of objective readability) and Verdana would lose.

While I was right in guessing that Georgia would be the winner, I was wrong about Verdana. In fact, the variation using Verdana generated 29.1% more clicks than our original font (Arial).

We also noticed that the variation using Georgia had a much better average time-on-page, indicating that our users were reading more of the article. This was also confirmed using heat maps.

Experimenting on font size

After confirming that Georgia was the best performing font for our site, I wanted to know what size the font should be to provide the best readability and engagement possible.

Reasonably, I expected the larger the font, the more readable it would be.

Wrong again.

First I tested 14px vs. 15px vs. 16px.

Using the same methods outlined above, it turned out that 14px generated the highest level of engagement.

Note: I also increased the line height by one pixel for every pixel increase in font size.

This was surprising, as I’d previously read studies such as this one on how larger fonts can increase the amount of attention a reader gives to the text she’s reading.  And, anecdotally, many websites that are considered highly readable are using fonts over 20px in size.

To double-check the accuracy of my results, I ran an identical experiment testing 10px, 14px, 18px and 21px.

Again, 14px won.

To me, this only suggests what every experienced A/B tester will tell you: What works for one person may not work for someone else. For our blog’s design, and the font we’re using, and perhaps even for the content we post, 14px seems to be the sweet spot.

How changing our font affected user experience

So, what impact did all of this work have on our website’s user experience?

After rolling out the 14px Georgia font across the whole website, we noticed that our website’s average bounce rate decreased from 88.0% to 80.9% — a 7.1% improvement.

Our average pages viewed per session also increased from 1.21 to 1.43, an 18.18% improvement, and our average time-on-site improved by about 10 seconds.

As with all things related to split testing, don’t take my word for it. Use a split testing tool like VWO or Optimizely to work out which font resonates best with your readers, and which one generates the most engagement for you.

Related Content

About the Author

Marcus Taylor is the founder and CEO of Venture Harbour, a digital marketing studio that develops and grows a portfolio of online businesses.

The post How Fonts Affect the User Experience appeared first on Six Revisions.

“No shows” stink. A few startups recently complained to the author that after diligently planning UX studies and recruiting a great batch of customers, some of their participants just didn’t show up. That’s incredibly frustrating, can be embarrassing in front of the team, and wastes everyone’s time.

Here are a few habits that have dramatically reduced “no shows” at the author’s studies:

  1. Avoid scheduling interviews on Mondays or immediately before or after holidays
  2. Offer an incentive that’s big enough to motivate people to show up
  3. Don’t start recruiting too far in advance
  4. Send recruits clearly written confirmation emails
  5. If parking is difficult in your neighborhood, give them specific instructions and assistance
  6. Ensure all communication (phone calls, emails, etc.) to your participants is respectful, professional, and organized
  7. Warn recruits ahead of time that the sessions will be 1-on-1 interviews
  8. Call participants to remind them about their appointments the day before
  9. Elicit several responses from your recruits in the days leading up to the study

No More “No Shows” — How to Make Sure Your Research Participants Actually Show Up

“No shows” stink. A few startups recently complained to the author that after diligently planning UX studies and recruiting a great batch of customers, some of their participants just didn’t show up. That’s incredibly frustrating, can be embarrassing in front of the team, and wastes everyone’s time.

Here are a few habits that have dramatically reduced “no shows” at the author’s studies:

  1. Avoid scheduling interviews on Mondays or immediately before or after holidays
  2. Offer an incentive that’s big enough to motivate people to show up
  3. Don’t start recruiting too far in advance
  4. Send recruits clearly written confirmation emails
  5. If parking is difficult in your neighborhood, give them specific instructions and assistance
  6. Ensure all communication (phone calls, emails, etc.) to your participants is respectful, professional, and organized
  7. Warn recruits ahead of time that the sessions will be 1-on-1 interviews
  8. Call participants to remind them about their appointments the day before
  9. Elicit several responses from your recruits in the days leading up to the study

No More “No Shows” — How to Make Sure Your Research Participants Actually Show Up

Date manipulation is one of those development hurdles that we all must jump at one point in our career, and great tools go a long way in taming the beast.

The Moment.js library is that tool for JavaScript developers.

Since discovering Moment.js, an open source project, I’ve used it religiously to simplify validation, parsing and manipulation of dates on the client-side.

In this tutorial, I’ll help you get up and running with this ultra-useful JavaScript date library.

What is Moment.js?

Moment.js is a free and open source JavaScript library that removes the need to use the native JavaScript Date object directly. The library is a wrapper for the Date object (in the same way that jQuery is a wrapper for JavaScript) making the object a whole lot easier to work with.

The problem with JavaScript’s Date object isn’t the functionality it brings; it’s just extremely cumbersome to use as a developer. If you want to do complex parsing, validation and displaying of dates, you’ll end up writing a lot of code.

Moment.js also extends native JavaScript date capabilities with a variety of features, such as relative time, calendar time, durations and multi-language support. It has a seemingly endless list of plugins that allow for additional features like time-zone support, recurrence and Twitter integration.

Tutorial Information

In this tutorial, we’re going to take a look at Moment.js. The following are the things we’ll tackle.

  • Referencing Moment.js and displaying basic date outputs
  • Displaying formatted dates
  • Parsing dates
  • Detecting invalid dates
  • Correcting invalid dates
  • Adding and subtracting dates

There are demo pages for almost all the sections of this tutorial that demonstrate the code being discussed.

Alternatively, you can download all the demo files associated with this tutorial as a ZIP archive.

Download All Demo Files

Let’s dive in.

Referencing Moment.js and Displaying Basic Outputs

To get started, you’ll need to download Moment.js and reference it in your HTML document. You can also find the library at cdnjs.com (a public CDN for open source projects). Just search for the library using the term "moment.js".

The first thing we’re going to do in this tutorial is to reference the Moment.js library.

Then, to make sure it’s working properly, we’re going to instantiate a moment object and a JavaScript Date object, and then output their values.

The following shows you how to reference the Moment.js library in your HTML documents, as well as how to instantiate and display the values of the moment object and the JavaScript Date object.

<!DOCTYPE html>
<html>
<head>
  <!-- reference Moment.js library -->
  <script src="//cdnjs.cloudflare.com/ajax/libs/moment.js/2.7.0/moment.min.js" type="text/javascript"></script>
</head>
<body>

<h2>Moment Date</h2>
<!-- container for Moment.js output -->
<div id="displayMoment"></div>

<h2>JavaScript Date</h2>
<!-- container for JavaScript Date output -->
<div id="displayJsDate"></div>

<script type="text/javascript">
(function()
{
  // instantiate a moment object
  var NowMoment = moment();
  
  // instantiate a JavaScript Date object
  var NowDate = new Date();
  
  // display value of moment object in #displayMoment div
  var eDisplayMoment = document.getElementById('displayMoment');
  eDisplayMoment.innerHTML = NowMoment;
  
  // display value of Date object in #displayJsDate div
  var eDisplayDate = document.getElementById('displayJsDate');
  eDisplayDate.innerHTML = NowDate;
})();
</script>

</body>
</html>

View Demo 1

At this point, the code-lengths of both the moment and native Date object look on par.

Displaying Formatted Dates

Things between moment and JavaScript Date quickly change, however, when we want to output even a simple, human-readable date display with the format of ‘Y-m-d’ (e.g. ’2014-7-1′).

Using JavaScript Date, this would be our code.

// use JavaScript Date to display current date in a div (#displayJsDate)
var NowDate = new Date();
var months = ['January', 'February', 'March', 'April', 'May', 'June', 'July', 'August', 'September', 'October', 'November', 'December'];
var sDay = NowDate.getDate();
var sMonth = NowDate.getMonth() + 1;
var sYear = NowDate.getFullYear();
var eDisplayDate = document.getElementById('displayJsDate');
eDisplayDate.innerHTML = sYear+'-'+sMonth+'-'+sDay;

Moment.js makes our code terser.

// use Moment.js to display current date in a div (#displayMoment)
var NowMoment = moment();
var eDisplayMoment = document.getElementById('displayMoment');
eDisplayMoment.innerHTML = NowMoment.format('YYYY-M-D');

View Demo 2

You’ll notice we had to add a lot of set-up code for our specific date format output in the native solution, and only a simple method called .format() in the Moment solution.

The string argument that we passed into .format(), which is 'YYYY-M-D', is the format that we’re asking the Moment.js library to return the date in. The Moment.js website has many format options conveniently listed in a table here:

Now that we’re familiar with the process of displaying and formatting the current date, let’s move on.

Parsing Dates

The Moment initializer will take a parameter and set the Date object to that date.

<h2>Output Date</h2>
<div id="output"></div>

<script type="text/javascript">
(function()
{
  var Date = moment('July 1, 2014');
  var eDisplayMoment = document.getElementById('output');
  // display output in the preferred format
  eDisplayMoment.innerHTML = Date.format('YYYY-M-D');
})();
</script>

One detail to note is there’s no standard that browsers adhere to when parsing dates. Fortunately, the Moment.js library provides additional parameters that allow us to specify the exact pattern we’re passing in to help us avoid cross-browser inconsistencies.

For consistency across all browsers and platforms, the above code should be parsed like the fowlloing.

<h2>Input Date</h2>
<div id="input">July 1, 2014</div>

<h2>Output Date</h2>
<div id="output"></div>

<script type="text/javascript">
(function()
{
  // get the input date from #input div element
  var input = document.getElementById('input').innerHTML;
  
  // use moment() with input value and a string format pattern as arguments
  var Date = moment(input, 'MMMM D, YYYY');
  
  // display the parsed date in a div (#output)
  var eDisplayMoment = document.getElementById('output');
  eDisplayMoment.innerHTML = Date.format('YYYY-M-D');
})();
</script>

View Demo 3

The Moment.js website has another table displaying the available parameters that we can use for parsing:

As the value we’re parsing is rarely entered by hand, it’s important to know that we’re actually parsing a date value.

Consider the input '2014-14-14' — this is an impossible date. In this case the moment() function will actually return the string 'Invalid Date' if you try to parse it.

However, there are additional tools available to us for detecting and correcting an invalid date values.

Detecting Invalid Dates

To detect an invalid date, Moment.js provides us with the isValid() method. It returns a simple boolean value (true or false), enabling us to determine the next course of action in our code logic in case the date value is not a valid one.

The other detection method available is invalidAt(). This method is more specific, it will tell us where our date value is invalid. It will return an integer between 0 and 6, the meanings of which can be found in the following table.

Integer Error location
0 Years
1 Months
2 Days
3 Hours
4 Minutes
5 Seconds
6 Milliseconds

So, in the example of '2014-14-14', the invalidAt() function would return 1 because 14 is an invalid month (only 1-12 are valid month values).

Correcting Invalid Dates

When would you ever be able to correct an invalid date? If you haven’t worked with dates at length before, this one might stump you. However, there are more variables at play than just the date itself: We must also consider how we’re getting the date and who is providing it.

Often, we ask people to enter dates and, despite our best efforts and flashy tooltips asking them to input in a specific date format like "d/m/y", they ignore our instructions and provide "m/d/y" anyways.

We can go back to the date-parsing call we made earlier and add a second parsing parameter (you can have more than two options) by passing in a string array of various possible date formats as a fallback.

Let’s use the date January 1, 2014 as our input example. We’ll input 14/1/2014 and 1/14/2014 expecting an input of D/M/YYYY.

<h2>Input Dates</h2>
<div id="input1">14/1/2014</div>
<div id="input2">1/14/2014</div>

<h2>Output Dates (1 format)</h2>
<div id="output1"></div>
<div id="output2"></div>

<h2>Output (multiple formats)</h2>
<div id="output3"></div>
<div id="output4"></div>

<script type="text/javascript">
(function()
{
  var correct = document.getElementById('input1').innerHTML;
  var incorrect = document.getElementById('input2').innerHTML;
  
  var Date1 = moment(correct, 'D/M/YYYY');
  document.getElementById('output1').innerHTML = Date1.format('MMMM D, YYYY');
  
  var Date2 = moment(incorrect, 'D/M/YYYY');
  // will display 'Invalid Date' in #output2 because input format is incorrect
  document.getElementById('output2').innerHTML = Date2.format('MMMM D, YYYY');

  var Date3 = moment(correct, ['D/M/YYYY','M/D/YYYY']);
  document.getElementById('output3').innerHTML = Date3.format('MMMM D, YYYY');

  // will try to parse using two potential date formats
  var Date4 = moment(incorrect, ['D/M/YYYY','M/D/YYYY']);
  // will display correct date format
  document.getElementById('output4').innerHTML = Date4.format('MMMM D, YYYY');
})();
</script>

View Demo 4

You’ll notice that with just one string argument, if the input doesn’t match, you will output 'Invalid Date'.

However, if you provide an array of string formats as the argument, the first parsing option that works will be used. This is great for removing or anticipating possible user errors.

Adding and Subtracting Dates

One of my favorite features in the Moment.js library is it conveniently has date-manipulation methods, such as .add() and .subtract().

For example:

// current date
var Date = moment();

// add 7 days to current date
document.getElementById('currDatePlus7d').innerHTML = Date.add('days', 7);

// subtract 8 hours from current date
document.getElementById('currDateSub8h').innerHTML = Date.subtract('hours', 8);

// add 5 years and 3 months to current date
document.getElementById('currDatePlus8h').innerHTML = Date.add({years: 5, months: 3});

View Demo 5

The Moment.js library will handle edge-cases elegantly. For example, using the native JavaScript Date object, adding one month to August 31 will result in October 1. This same operation performed by Moment.js will correctly produce September 30.

Conclusion

Moment.js is an excellent tool to have if you regularly end up working with client-side date parsing, formatting and validation. It has plenty to offer in terms of speeding up JavaScript development in this area. To see the project’s source code, head over to its GitHub repository. To learn more about its features, check out the official docs.

Related Content

About the Author

Bradley Holbrook is a senior software developer for Click4Time Software Inc. He has been designing and developing web applications for over 15 years. Connect with Bradley via email.

The post Working with JavaScript Dates Using Moment.js appeared first on Six Revisions.

Date manipulation is one of those development hurdles that we all must jump at one point in our career, and great tools go a long way in taming the beast.

The Moment.js library is that tool for JavaScript developers.

Since discovering Moment.js, an open source project, I’ve used it religiously to simplify validation, parsing and manipulation of dates on the client-side.

In this tutorial, I’ll help you get up and running with this ultra-useful JavaScript date library.

What is Moment.js?

Moment.js is a free and open source JavaScript library that removes the need to use the native JavaScript Date object directly. The library is a wrapper for the Date object (in the same way that jQuery is a wrapper for JavaScript) making the object a whole lot easier to work with.

The problem with JavaScript’s Date object isn’t the functionality it brings; it’s just extremely cumbersome to use as a developer. If you want to do complex parsing, validation and displaying of dates, you’ll end up writing a lot of code.

Moment.js also extends native JavaScript date capabilities with a variety of features, such as relative time, calendar time, durations and multi-language support. It has a seemingly endless list of plugins that allow for additional features like time-zone support, recurrence and Twitter integration.

Tutorial Information

In this tutorial, we’re going to take a look at Moment.js. The following are the things we’ll tackle.

  • Referencing Moment.js and displaying basic date outputs
  • Displaying formatted dates
  • Parsing dates
  • Detecting invalid dates
  • Correcting invalid dates
  • Adding and subtracting dates

There are demo pages for almost all the sections of this tutorial that demonstrate the code being discussed.

Alternatively, you can download all the demo files associated with this tutorial as a ZIP archive.

Download All Demo Files

Let’s dive in.

Referencing Moment.js and Displaying Basic Outputs

To get started, you’ll need to download Moment.js and reference it in your HTML document. You can also find the library at cdnjs.com (a public CDN for open source projects). Just search for the library using the term "moment.js".

The first thing we’re going to do in this tutorial is to reference the Moment.js library.

Then, to make sure it’s working properly, we’re going to instantiate a moment object and a JavaScript Date object, and then output their values.

The following shows you how to reference the Moment.js library in your HTML documents, as well as how to instantiate and display the values of the moment object and the JavaScript Date object.

<!DOCTYPE html>
<html>
<head>
  <!-- reference Moment.js library -->
  <script src="//cdnjs.cloudflare.com/ajax/libs/moment.js/2.7.0/moment.min.js" type="text/javascript"></script>
</head>
<body>

<h2>Moment Date</h2>
<!-- container for Moment.js output -->
<div id="displayMoment"></div>

<h2>JavaScript Date</h2>
<!-- container for JavaScript Date output -->
<div id="displayJsDate"></div>

<script type="text/javascript">
(function()
{
  // instantiate a moment object
  var NowMoment = moment();
  
  // instantiate a JavaScript Date object
  var NowDate = new Date();
  
  // display value of moment object in #displayMoment div
  var eDisplayMoment = document.getElementById('displayMoment');
  eDisplayMoment.innerHTML = NowMoment;
  
  // display value of Date object in #displayJsDate div
  var eDisplayDate = document.getElementById('displayJsDate');
  eDisplayDate.innerHTML = NowDate;
})();
</script>

</body>
</html>

View Demo 1

At this point, the code-lengths of both the moment and native Date object look on par.

Displaying Formatted Dates

Things between moment and JavaScript Date quickly change, however, when we want to output even a simple, human-readable date display with the format of ‘Y-m-d’ (e.g. ’2014-7-1′).

Using JavaScript Date, this would be our code.

// use JavaScript Date to display current date in a div (#displayJsDate)
var NowDate = new Date();
var months = ['January', 'February', 'March', 'April', 'May', 'June', 'July', 'August', 'September', 'October', 'November', 'December'];
var sDay = NowDate.getDate();
var sMonth = NowDate.getMonth() + 1;
var sYear = NowDate.getFullYear();
var eDisplayDate = document.getElementById('displayJsDate');
eDisplayDate.innerHTML = sYear+'-'+sMonth+'-'+sDay;

Moment.js makes our code terser.

// use Moment.js to display current date in a div (#displayMoment)
var NowMoment = moment();
var eDisplayMoment = document.getElementById('displayMoment');
eDisplayMoment.innerHTML = NowMoment.format('YYYY-M-D');

View Demo 2

You’ll notice we had to add a lot of set-up code for our specific date format output in the native solution, and only a simple method called .format() in the Moment solution.

The string argument that we passed into .format(), which is 'YYYY-M-D', is the format that we’re asking the Moment.js library to return the date in. The Moment.js website has many format options conveniently listed in a table here:

Now that we’re familiar with the process of displaying and formatting the current date, let’s move on.

Parsing Dates

The Moment initializer will take a parameter and set the Date object to that date.

<h2>Output Date</h2>
<div id="output"></div>

<script type="text/javascript">
(function()
{
  var Date = moment('July 1, 2014');
  var eDisplayMoment = document.getElementById('output');
  // display output in the preferred format
  eDisplayMoment.innerHTML = Date.format('YYYY-M-D');
})();
</script>

One detail to note is there’s no standard that browsers adhere to when parsing dates. Fortunately, the Moment.js library provides additional parameters that allow us to specify the exact pattern we’re passing in to help us avoid cross-browser inconsistencies.

For consistency across all browsers and platforms, the above code should be parsed like the fowlloing.

<h2>Input Date</h2>
<div id="input">July 1, 2014</div>

<h2>Output Date</h2>
<div id="output"></div>

<script type="text/javascript">
(function()
{
  // get the input date from #input div element
  var input = document.getElementById('input').innerHTML;
  
  // use moment() with input value and a string format pattern as arguments
  var Date = moment(input, 'MMMM D, YYYY');
  
  // display the parsed date in a div (#output)
  var eDisplayMoment = document.getElementById('output');
  eDisplayMoment.innerHTML = Date.format('YYYY-M-D');
})();
</script>

View Demo 3

The Moment.js website has another table displaying the available parameters that we can use for parsing:

As the value we’re parsing is rarely entered by hand, it’s important to know that we’re actually parsing a date value.

Consider the input '2014-14-14' — this is an impossible date. In this case the moment() function will actually return the string 'Invalid Date' if you try to parse it.

However, there are additional tools available to us for detecting and correcting an invalid date values.

Detecting Invalid Dates

To detect an invalid date, Moment.js provides us with the isValid() method. It returns a simple boolean value (true or false), enabling us to determine the next course of action in our code logic in case the date value is not a valid one.

The other detection method available is invalidAt(). This method is more specific, it will tell us where our date value is invalid. It will return an integer between 0 and 6, the meanings of which can be found in the following table.

Integer Error location
0 Years
1 Months
2 Days
3 Hours
4 Minutes
5 Seconds
6 Milliseconds

So, in the example of '2014-14-14', the invalidAt() function would return 1 because 14 is an invalid month (only 1-12 are valid month values).

Correcting Invalid Dates

When would you ever be able to correct an invalid date? If you haven’t worked with dates at length before, this one might stump you. However, there are more variables at play than just the date itself: We must also consider how we’re getting the date and who is providing it.

Often, we ask people to enter dates and, despite our best efforts and flashy tooltips asking them to input in a specific date format like "d/m/y", they ignore our instructions and provide "m/d/y" anyways.

We can go back to the date-parsing call we made earlier and add a second parsing parameter (you can have more than two options) by passing in a string array of various possible date formats as a fallback.

Let’s use the date January 1, 2014 as our input example. We’ll input 14/1/2014 and 1/14/2014 expecting an input of D/M/YYYY.

<h2>Input Dates</h2>
<div id="input1">14/1/2014</div>
<div id="input2">1/14/2014</div>

<h2>Output Dates (1 format)</h2>
<div id="output1"></div>
<div id="output2"></div>

<h2>Output (multiple formats)</h2>
<div id="output3"></div>
<div id="output4"></div>

<script type="text/javascript">
(function()
{
  var correct = document.getElementById('input1').innerHTML;
  var incorrect = document.getElementById('input2').innerHTML;
  
  var Date1 = moment(correct, 'D/M/YYYY');
  document.getElementById('output1').innerHTML = Date1.format('MMMM D, YYYY');
  
  var Date2 = moment(incorrect, 'D/M/YYYY');
  // will display 'Invalid Date' in #output2 because input format is incorrect
  document.getElementById('output2').innerHTML = Date2.format('MMMM D, YYYY');

  var Date3 = moment(correct, ['D/M/YYYY','M/D/YYYY']);
  document.getElementById('output3').innerHTML = Date3.format('MMMM D, YYYY');

  // will try to parse using two potential date formats
  var Date4 = moment(incorrect, ['D/M/YYYY','M/D/YYYY']);
  // will display correct date format
  document.getElementById('output4').innerHTML = Date4.format('MMMM D, YYYY');
})();
</script>

View Demo 4

You’ll notice that with just one string argument, if the input doesn’t match, you will output 'Invalid Date'.

However, if you provide an array of string formats as the argument, the first parsing option that works will be used. This is great for removing or anticipating possible user errors.

Adding and Subtracting Dates

One of my favorite features in the Moment.js library is it conveniently has date-manipulation methods, such as .add() and .subtract().

For example:

// current date
var Date = moment();

// add 7 days to current date
document.getElementById('currDatePlus7d').innerHTML = Date.add('days', 7);

// subtract 8 hours from current date
document.getElementById('currDateSub8h').innerHTML = Date.subtract('hours', 8);

// add 5 years and 3 months to current date
document.getElementById('currDatePlus8h').innerHTML = Date.add({years: 5, months: 3});

View Demo 5

The Moment.js library will handle edge-cases elegantly. For example, using the native JavaScript Date object, adding one month to August 31 will result in October 1. This same operation performed by Moment.js will correctly produce September 30.

Conclusion

Moment.js is an excellent tool to have if you regularly end up working with client-side date parsing, formatting and validation. It has plenty to offer in terms of speeding up JavaScript development in this area. To see the project’s source code, head over to its GitHub repository. To learn more about its features, check out the official docs.

Related Content

About the Author

Bradley Holbrook is a senior software developer for Click4Time Software Inc. He has been designing and developing web applications for over 15 years. Connect with Bradley via email.

The post Working with JavaScript Dates Using Moment.js appeared first on Six Revisions.

Meteor is a full-stack development platform that makes it easier than ever before to build real-time web applications. This tutorial will get you up and running with Meteor in no time.

What is Meteor?

Meteor will enable you to build web applications much faster — even ambitious ones that seem like they were developed by big teams with big budgets — using nothing but JavaScript, CSS and HTML. And, what’s more, with Meteor, you’ll simply have more fun because it’s optimized for developer-happiness.

Originally known as "Skybreak" back in 2011, Meteor has since raised $11.2 million in venture capital, grown an active and dedicated community and has become "the hot new thing" in the world of web development.

Meteor did all that even before reaching its version 1.0 release (currently, it’s at 0.8.2, but the releases are coming big and quick).

There’s a lot to love about this web development platform, here are a few of them:

  • You don’t have to be a seasoned developer to make a start. If you’ve never made a web application before, Meteor is one of the easiest introductions to the craft, while still being incredibly powerful enough to be the only platform you’ll ever want to use.
  • Your web applications are real-time by default. In the majority of cases, you don’t even have to think about making your applications real-time. You work as you normally would, and the real-time features just happen. This means less code and shorter development cycles.
  • The community is extremely helpful. You won’t be left alone if you embark on your journey into Meteor. There’s blogs and books and screencasts and all the other sort of help you could possibly want.
  • Meteor is open source. A GitHub repo is available if you want to dive into its inner workings (or even contribute to its development).

If you’re not quite sold on the Meteor JavaScript framework yet, check out the official Meteor site and this popular tutorial screencast from the creators of Meteor.

Screenshot of Meteor front page.

A Meteor Tutorial for Beginners

In this tutorial, I’ll share an introduction to Meteor that anyone with a basic understanding of JavaScript can follow. If you know what "variables" and "functions" are, you’re good to go. If not, read this free online book first.

Especially if you’re a web designer looking to add "and developer" to your job title, this tutorial should act as a fun little nudge in the right direction.

In this tutorial, we’ll build a very rudimentary blogging app together. Doing this will allow us to explore the most powerful features of Meteor by way of a functional web app example.

Preview of the results of this Meteor tutorial.

View Demo

Let’s get started.

Step 1: Install Meteor

Note: The following installation instructions are for Mac OS X and Linux. If you’re on Windows, visit win.meteor.com to learn how to install Meteor. If you’re already familiar with command line interfaces (CLI), the following are just basic commands that you probably already know regardless of the operating system you currently use.

To begin, open the command line. On Mac OS X, this is the Terminal application. If you’re on Linux, the name of the command line interface can vary, but since you’re using Linux, I’ll assume you know what it is.

Issue this command:

curl https://install.meteor.com/ | sh

The command above will start the installation process. It’ll only take a few seconds and, just like that, Meteor is installed and ready to use.

Step 2: Create a Project

For every web application we develop, we’ll need to create a project.

But before we create a project, to keep things nice and tidy, let’s create a folder that will store all of our Meteor web applications.

Use the following command to create a directory named "Meteor" in your computer that will store all of your Meteor projects:

mkdir Meteor

Let’s navigate into the "Meteor" directory with the change directory command:

cd Meteor

Now we’ll create our first Meteor project. We’ll name our first project HelloWorld. Just use the following command:

meteor create HelloWorld

The command above will create a "HelloWorld" folder that contains three base files:

  1. HelloWorld.html
  2. HelloWorld.js
  3. HelloWorld.css

A Meteor app can grow beyond these first three files, but they’ll be enough for this tutorial.

Step 3: Launch Your Local Server

By default, our project contains some code for a demo application.

To see this demo application, move into our project’s directory:

cd HelloWorld

Once you’re in the HelloWorld project directory, launch the local server by issuing the following command:

meteor run

That command will now let us see our app through a browser simply by navigating it to the following URL:


http://localhost:3000

You can use whatever browser you prefer, though I recommend Google Chrome because of the browser’s built-in developer and debugging tools, such as its JavaScript console which we’ll be using in this tutorial.

The default app template should resemble the following:

If you click the button that says "Click" it doesn’t seem to do anything. But something is happening though.

Chrome’s JavaScript console

Whenever you click on the "Click" button something is happening. To see it, in Google Chrome, go ahead and do the following:

  1. Click on the Menu icon (located at the top-right of the window)
  2. Hover over to the Tools option
  3. Select the JavaScript console option

Alternatively, you can press Option+Command+J (Windows: Ctrl+Shift+J) to open up the JavaScript console.

The JavaScript console is the client-side equivalent of the command line. This will be a powerful tool as you’re developing your Meteor apps.

The command line runs on the server (where the application is hosted) while the JavaScript console runs on the client (in the user’s browser).

With the JavaScript console open, press on the "Click" button again. You’ll see a message appear in the console with each press of the button:

JavaScript console showing a click event recorded by Meteor.

That’s the extent of what’s happening, you pressed the button, so it’s not so exciting.

We’ll be using the console again in this tutorial, so please leave it open.

Step 4: Create a Collection

Usually, this is where most tutorials would show how to create a user interface with Meteor, but I think it’s easier to start by talking about the database. It’s not as sexy of a subject compared to the UI, but it’s a more pragmatic one.

Meteor uses MongoDB by default, but there will be more RDMS options coming in the future.

MongoDB in itself is a huge topic, but it’s one of the easier databases to use as a beginner because there’s a lot of things you don’t have to think about (for example, it’s good at avoiding injection attacks by itself, unlike SQL).

We’re now going to use the database by creating a collection.

A collection is equivalent to an SQL table. For example, if we were making a WordPress clone, we’d create a collection for posts, a collection for pages, a collection for comments, a collection for users, and so forth. There’d be a collection for each type of data.

Let’s create our first collection: Open the HelloWorld.js file in your favorite code editor, delete everything in it and replace it with:

new Meteor.Collection('posts');

In this tutorial, we’ll pretend that we’re creating a blogging platform, so here, we’re making a collection named "posts" that will store data such as post titles, post contents and post statuses (i.e. whether the post is published or still a draft).

We do, however, need a convenient way of referencing the collection we just created, so we’ll amend our code by slapping an object name in front it. How about we call this collection, "BlogPosts"? Update the code block above so it now looks like this:

BlogPosts = new Meteor.Collection('posts');

Note: We’re intentionally not using the var keyword since we want this to be a global variable that we can access through all of our files.

Save our HelloWorld.js file, switch to your browser, and enter the name of the following code block into the JavaScript Console.

BlogPosts

You should receive a response that confirms the collection exists, which is all we need for the time being.

Step 5: Manipulate Your Collection’s Data

Inside the JavaScript Console, enter the following:

BlogPosts.insert({
  title: 'Hello World',
  content: 'Content goes here.',
  published: true
});

Note: Newlines and extra spaces in the JavaScript console are ignored, so the above can be written in one line. The formatting above is for readability.

 We just used the insert function to create a document inside our collection. A document is equivalent to a row in a SQL table. We’ll create a new document for each blog post in our web app.

It’s worth pointing out that:

  • We don’t have to design the structure of our collections. The structure is created on the fly. When we need a new field, we just define it.
  • We can mix and match data types. We have strings in the first two fields (title and content, but the third field (published) is a boolean field (i.e. it can only hold the value of either true or false).

So that we have data to work with in the next few steps of this tutorial, insert a few more documents (like 5 or so) into the BlogPosts collection via the JavaScript console using the same code block as above.Try to use different values for the title and content fields, and alternate between true and false for the published field.

Step 6: Retrieve the Data

In a moment, we’ll create a template that shows a list of blog posts.

Before we do that though, we need to create a JavaScript function that retrieves the blog posts from our collection.

In the HelloWorld.js file, add this code block below the previous one:

Template.listBlogPosts.post = function(){
  // code goes here
}

The code above might look weird and abstract to you, so let’s break it down:

The Template portion searches through all the templates in our project. We haven’t created a template yet, but we’ll get to that in a moment.

The listBlogPosts part is the name we’ll assign to our soon-to-be template. We can name our templates whatever we want.

The last part, post, is an arbitrary name for our function that we’ll soon reference.

Within the function block we created above, we write the code that will retrieve all the blog posts, like so:

Template.listBlogPosts.post = function(){
  return BlogPosts.find();
}

So now we have this function called post() and, within the post() function, we return the entirety of our BlogPosts collection.

We only want this code running on the client. Do do this, let’s wrap our code in an isClient conditional statement:

if(Meteor.isClient){
  Template.listBlogPosts.post = function(){
    return BlogPosts.find();
  }
}

All code inside this conditional will only run in the user’s browser (and the rest of the code in this tutorial will be placed inside this conditional).

That’s all the database talk for the moment.

Let’s start delving into the so-called "magic" of Meteor: Templating.

Step 7: Create a Template

To move onto the design part of this tutorial, open the HelloWorld.html file, delete all of its content and replace it the following:

<head>
  <title>My Blog</title>
</head>
<body>
  <!-- code goes here -->
</body>

Notice that we didn’t use <html> tags, nor have we manually included any CSS or JavaScript files. This is because Meteor will do all this for us.

Beneath the code block above, let’s create our first template:

<template name="listBlogPosts">

</template>

If you save the file and switch back to the browser at this point, the template won’t appear. Why? Because we have to reference it, giving us complete control over where and when the template appears.

Between the <body> tags, write:

{{> listBlogPosts}}

When we use double-curly braces ({{ and }}), we’re using the Spacebars templating syntax that comes packaged with Meteor. Spacebars allows us to make our templates dynamic. The greater than symbol (>) is specifically used when referencing a template.

Step 8: Displaying Data

Inside our listBlogPosts template, add the following block of code:

<template name="listBlogPosts">
  {{#each post}}
    {Getting Started with Meteor}
  {{/each}}
</template>

Here, we’re looping through the data returned by the post function we created earlier. It lets us display a list of blog posts from our BlogPosts collection and the fields associated with each document. (In the code above, we’re showing the "title" field.)

To make our template look a little nicer, update our code above so it now looks like this:

<template name="listBlogPosts">
<div id="content">
  {{#each post}}
    <div class="post">
      <h2>{Getting Started with Meteor}</h2>
      <div class="entry">
        {{content}}
      </div>
    </div>
  {{/each}}
</div>
</template>

Now we can open the HelloWorld.css stylesheet, write whatever styles rules we like, and they’ll all be applied to our template’s HTML elements.

Step 9: Retrieving Specific Data

At the moment, our app will display all of the blog posts from our collection, rather than just the posts that have the published parameter set to true.

To fix this, update the post() function from this:

Template.listBlogPosts.post = function(){
  return BlogPosts.find();
}

…to this:

Template.listBlogPosts.post = function(){
  return BlogPosts.find({ published: true });
}

In the above code, we’ve passed the published parameter into the find function, allowing us to retrieve only the published posts, i.e., all documents that have published: true.

Step 10: Create a Form

While we’re never going to build a complete blogging application in a single tutorial, we could at least build an Add New Post web form that will act as the interface for adding new content into our rudimentary blogging engine. Earlier, in Step 5, we added new documents in our collection through the JavaScript console, and now we’ll create an interface for this process.

First, create a new template in our HelloWorld.html file:

<template name="addPostForm">
<form>
  Title: <input type="text" id="titleField"><br />
  Content: <textarea id="contentField"></textarea><br />
  Publish? <input type="checkbox" id="publishedField"><br />
  <input type="submit">
</form>
</template>

There’s nothing remarkable about this form template. The only detail worth noting is that each field has a unique id attribute that we’ll soon reference.

Also, don’t forget to reference the following somewhere between the <body> tags so the user can see our form (just like with our listBlogPosts template in Step 8):

{{> addPostForm}}

To make this form do something, switch to our JavaScript file and, inside the isClient conditional, write the following:

Template.addPostForm.events({
  // code will go here
});

Here, we’re using the events function to attach an event listener to our addPostForm template.

Events are things like clicks, double-clicks, scrolling, mouseovers and form submissions. They’re things that occur when a user is navigating our web application, and we can write code that reacts to them.

In this example, we’ll create an event listener that is triggered when our form is submitted:

Template.addPostForm.events({
  'submit form': function(){
    console.log("Form submitted");
  }
});

This is what’s happening with the above:

  1. First, we use the submit keyword to define the event type to watch out for. There’s a range of event types available, all of which can be found in Meteor’s official docs.
  2. Second, the form keyword references all the form elements within our template, so this is where we’re simply attaching our event listener to the one and only <form> element in our web app.
  3. Third, we associate a function with our form submission event, and it’s within this function that we write the code we want to execute when the ‘submit form’ event happens. In this case, a simple message that reads "Form submitted" will appear in the JavaScript console when the form is submitted.

There’s a problem though, since whenever we submit the form, there’s a slight flicker. This is because forms have a default behavior that we need to disable so it no longer interferes with our code.

To disable the form’s default behavior, update the code block above so it now looks this:

Template.addPostForm.events({
  'submit form': function(event){
    event.preventDefault();
  }
});

Note: After updating the code block and removing the console.log() invocation, you’ll no longer see the "Form submitted" message in your console.

We’ve done two things:

  1. We’ve created a function argument named event that we can reference withing the 'submit form' function as the current instance of the event while it’s occurring.
  2. We used the preventDefault() function on the current event, which stops our form from behaving how it would usually behave.

With that housekeeping out of the way, let’s make our form do something useful.

Step 11: Getting Data from Inputs

The end goal is to have the data from our form inserted into the BlogPosts collection that we created earlier. To move us towards this goal, let’s grab the data from our form fields. This is a two-step process.

First, we pass another function argument into our 'submit form' function, which we will name template:

Template.addPostForm.events({
  'submit form': function(event, template){
    event.preventDefault();
  }
});

We’ve added the template argument to allows us to search through the template that our event is attached to. In this case, we can search through the addPostForm template from within our event.

The second step of our process is to perform three searches. We can do this like so:

Template.addPostForm.events({
  'submit form': function(event, template){
    event.preventDefault();
    var titleVar = template.find('#titleField').value;
    var contentVar = template.find('#contentField').value;
    var publishedVar = template.find('#publishedField').checked;
  }
});

The above invokes the find function that will search through our templates using their HTML IDs, i.e. #titleField, #contentField, #publishedField, as the references for the relevant input fields, and then pulling the values from them. We then store these values in some variables: titleVar, contentVar and publishedVar.

Note: For the third variable, publishedVar, the value will either be true or false based on whether or not the "Published?" checkbox is checked.

Below these statements, we use the insert function to move the data from our form and into the BlogPosts collection:

BlogPosts.insert({
  title: titleVar,
  content: contentVar,
  published: publishedVar
});

At this point, the code should resemble this:

Template.addPostForm.events({
  'submit form': function(event, template){
    event.preventDefault();
    var titleVar = template.find('#titleField').value;
    var contentVar = template.find('#contentField').value;
    var isPublishedVar = template.find('#isPublishedField').checked;
    BlogPosts.insert({
      title: titleVar,
      content: contentVar,
      published: publishedVar
    });
  }
});

Now, the form should work as expected. When you submit data through it, it will automatically appear in our app’s interface as long as the "published" option is checked.

Conclusion

We’ve only scratched the surface of Meteor, but we’ve also covered the most essential core concepts that you’ll continue to use during your career as a Meteor developer.

Our final blogging application might not be particularly grand, but:

  • We wrote very little code in a very short amount of time
  • The application functions in real-time without us doing anything special

I hope you’re now at least a little bit curious enough to explore Meteor a little further. It’s an increasingly popular web app platform that has many great years ahead of it.

Related Content

About the Author

David Turnbull is the founder of Meteor Tips, a site that publishes tutorials about the Meteor JavaScript framework, and author of Your First Meteor Application. David’s been working on the Web since he was 12 years old. Follow him on Twitter @meteortips.

The post Getting Started with Meteor appeared first on Six Revisions.


pentotype is a new drawing software that lets you create clickable wireframes on your iPad or on your desktop with a graphics tablet. Since drawing sets virtually no limits, you can create any interface that you want, be it a website, a game, or a regular application with a custom UI. You can quickly share ideas with your team and see how the user will walk through your app.

Drawing

When you start a new project in pentotype, you’ll get an empty, infinite canvas. After inserting a new screen, either by selecting it from the side bar or just by drawing a rectangle, you can go ahead and draw your design. The features are simple so as to keep it low-fidelity: 5 colors for the pen, 3 font sizes for text. All elements of your drawing can be moved, deleted, copied, or saved as a stencil, so pentotype makes it very easy to create wireframes and apply changes. Available wireframe types are phone, tablet, and website.

Screenflows

By inserting more screens to the document, you can create a whole screenflow. Along with drawing the UI of the screens, you also draw the interaction between them: Just draw a line between an element and another screen, and you have immediately created a link. The kind of transition is automatically recognized (e.g. a slide transition between neighboring screens) but can also be changed.

Simulations

After you have drawn your wireframe, it can immediately be tested with functional links, transitions, and scrolling (in website wireframes) – just hit the “simulate” button. In order to send the simulation to your phone and view it there, just scan the QR-code. To get an idea of what this can look like, try out the example appointment app.

Collaboration and Feedback

By adding team members to your account, you can work on projects together. By sharing the link of a project with people (even without a pentotype account), they can immediately give you feedback by writing comments directly in the wireframe.

Try it for 30 days

Credits: Johannes Dörr

Yesterday morning, I did the unimaginable. Something I didn’t think I was ever capable of doing.

I unsubscribed to all my RSS feeds.

An image of a RSS feed with no subscriptions.

For roughly seven years, way back when the now-defunct Google Reader was still cool, I’ve been on a relentless mission to amass, what felt like, the largest collection of RSS feeds in the entire world.

When Google shuttered their feed reader, I didn’t give up, I just moved all my babies into another service. I protected each feed like they were my children, never abandoning them even when times got lean, even when some weren’t publishing content still relevant to me.

And, in under a minute, they were all gone.

I straight-up deleted them all. No backup file that can restore them, or some list in a .txt file.

If you were to ask me now which feeds I subscribed to, I’ll only be able to recall four or five off the top of my head. And therein lies the problem.

Strangely enough, instead of the anxiety attack induced by FoMO that I was expecting, as cliché as this will sound, a sense of relief is what I got.

Why?

We all have our own purpose for RSS, here are mine:

  1. To read about topics that are currently interesting and relevant to me
  2. To keep up with news efficiently, all in one place
  3. To discover fresh ideas and opinions
  4. To habitually follow sites I enjoy
  5. To be inspired in my work as a front-end developer and Web content publisher

None of these have been happening, at least through my feed reader.

For instance, it’s difficult to keep up with relevant news if you have to wade through hundreds of non-essential feed items. Social news sites (e.g. HN and Reddit) and weekly newsletters (like Hacker Newsletter) are more convenient options because the need-to-know stuff generally bubbles up into my purview with little effort.

The discovery of fresh stuff, ideas and opinions won’t happen if my sources are the same sites and content producers – year in, year out.

Also, my tastes have changed over the years. I’ve grown up; I’m interested in new things (AngularJS), and not so much in others (I was still subscribed to Flash/AS blogs).

The signal-to-noise ratio in my feed reader was abysmal, partly because I was still subscribed to feeds I no longer found appealing, and because of the shear quantity of feeds in my collection. And the paltry amount of signal that does come through the wire is rapidly obscured and stifled by the large volume of noise.

I want to love RSS again. And, perhaps more importantly, I want it to be useful again. I still believe in the technology’s value proposition: The ability to read good articles in a quick and unembellished way, with their sources hand-picked by us.

So I’m starting back from zero.

Rules

For this to stick, I’ll need to follow a few guidelines.

Delete everything. No backups.

Whenever I go on RSS Zero mode, which I plan on doing at least once a year, it means indiscriminatingly unsubscribing to all feeds.

The first reboot takes courage and a leap of faith, especially if, like me, you’ve invested so much time and effort assembling your collection of feeds. For me, my seven-year-old list was gone within a minute. Seriously.

Being selective of which feeds stay and which ones go only belabors the process. Trust yourself that if a feed is really worth subscribing to, you’re going to remember it later on. And if you do forget, then let me make the argument that it really wasn’t all that valuable in the first place.

Flat hierarchy

I’m obsessed with organization, to the point that it starts to hinder my productivity sometimes. I had a folder named "minimalism" that had over ten blogs in it, and a folder labeled "decluttering" for sites that provide tips on the subject–information that I never applied to my feed reader.

Categorizing RSS subscriptions, I’ve realized, makes it easy to just hide feeds I’m only mildly (if at all) deriving value from. For instance, I had a category called "archived" for blogs that no longer publish content, in the off-chance that, someday, the site picks back up again. I know right? I have a problem. It’s the digital equivalent of being a hoarder: Putting junk — old newspapers, broken coffee makers, that unsightly sweater mom gave you — up in the attic where we think they’re out of sight, out of mind.

A flat hierarchy shows me all my RSS feeds in one view, making it easy to pinpoint the ones I don’t need any more.

A maximum of five RSS subscriptions in the first week

During the first week of this exercise, I’ll give myself the option to subscribe to up to five feeds. Having this ability helps kickstart the whole thing back into action. This rule is not accumulative.

Only two RSS subscriptions per week after that

After the starter week, I’ll limit the addition of new subscriptions down to just two a week. This rule is also non-cumulative: If I don’t add two subscriptions this week, I’m not going to get to add four the next.

Previous RSS subscriptions are banned for the first month

To force myself to look for new sources of information and ideas, in the next 30 days, I’ve made it a rule not to subscribe to any of my old RSS feeds.

If I want to read content on my favorite sites, I’ll have to do it the old-fashioned way: Typing their domain name in the browser and pressing Enter.

At the end of the month, I’ll review my browsing history to determine which sites I end up regularly visiting, and I’ll subscribe to their RSS feeds whenever I have subscription allotments available.

Regularly review and update RSS subscriptions

Every now and then, I’ll make a conscious effort to evaluate (and be more critical of) my current subscriptions. I’ll unsubscribe to the one I no longer want to read from. This is so we don’t find ourselves in the same situation that prompted the process in the first place. I feel monthly, or even quarterly, seems like the appropriate interval for this activity.

These guidelines will make us more discerning of our information sources, favoring quality and current relevance over quantity.

RSS Zero every year

I’ll be wiping my feed reader clean at least once a year. Saying this out loud makes it seem crazy. It seems unproductive — like building a house and tearing it down every year — but doing this puts us in the situation where we’re compelled to find fresh sources of content. In my line of work, complacency — being set in my ways — is very deadly.

You may just want to zero-out your feed reader whenever you feel overwhelmed. That could be in six months, or seven years. Trust your instincts.

Moving Forward

These are the things I expect to occur in the aftermath of this activity:

  • The discovery of new sources of content and fresh ideas
  • The ability to read relevant content in a timely and efficient way
  • It will make RSS, as a tool, useful and essential again

Under the right circumstances, there’s still a great deal of value in really simple syndication. But, sometimes, to move forward with something, we just need a minute to start back from zero.

Related Content

About the Author

Jacob Gube is the founder of Six Revisions. He’s a front-end web developer by profession. If you’d like to connect with him, head on over to the contact page or follow him on Twitter: @sixrevisions.

The post RSS Zero appeared first on Six Revisions.

Yesterday morning, I did the unimaginable. Something I didn’t think I was ever capable of doing.

I unsubscribed to all my RSS feeds.

An image of a RSS feed with no subscriptions.

For roughly seven years, way back when the now-defunct Google Reader was still cool, I’ve been on a relentless mission to amass, what felt like, the largest collection of RSS feeds in the entire world.

When Google shuttered their feed reader, I didn’t give up, I just moved all my babies into another service. I protected each feed like they were my children, never abandoning them even when times got lean, even when some weren’t publishing content still relevant to me.

And, in under a minute, they were all gone.

I straight-up deleted them all. No backup file that can restore them, or some list in a .txt file.

If you were to ask me now which feeds I subscribed to, I’ll only be able to recall four or five off the top of my head. And therein lies the problem.

Strangely enough, instead of the anxiety attack induced by FoMO that I was expecting, as cliché as this will sound, a sense of relief is what I got.

Why?

We all have our own purpose for RSS, here are mine:

  1. To read about topics that are currently interesting and relevant to me
  2. To keep up with news efficiently, all in one place
  3. To discover fresh ideas and opinions
  4. To habitually follow sites I enjoy
  5. To be inspired in my work as a front-end developer and Web content publisher

None of these have been happening, at least through my feed reader.

For instance, it’s difficult to keep up with relevant news if you have to wade through hundreds of non-essential feed items. Social news sites (e.g. HN and Reddit) and weekly newsletters (like Hacker Newsletter) are more convenient options because the need-to-know stuff generally bubbles up into my purview with little effort.

The discovery of fresh stuff, ideas and opinions won’t happen if my sources are the same sites and content producers – year in, year out.

Also, my tastes have changed over the years. I’ve grown up; I’m interested in new things (AngularJS), and not so much in others (I was still subscribed to Flash/AS blogs).

The signal-to-noise ratio in my feed reader was abysmal, partly because I was still subscribed to feeds I no longer found appealing, and because of the shear quantity of feeds in my collection. And the paltry amount of signal that does come through the wire is rapidly obscured and stifled by the large volume of noise.

I want to love RSS again. And, perhaps more importantly, I want it to be useful again. I still believe in the technology’s value proposition: The ability to read good articles in a quick and unembellished way, with their sources hand-picked by us.

So I’m starting back from zero.

Rules

For this to stick, I’ll need to follow a few guidelines.

Delete everything. No backups.

Whenever I go on RSS Zero mode, which I plan on doing at least once a year, it means indiscriminatingly unsubscribing to all feeds.

The first reboot takes courage and a leap of faith, especially if, like me, you’ve invested so much time and effort assembling your collection of feeds. For me, my seven-year-old list was gone within a minute. Seriously.

Being selective of which feeds stay and which ones go only belabors the process. Trust yourself that if a feed is really worth subscribing to, you’re going to remember it later on. And if you do forget, then let me make the argument that it really wasn’t all that valuable in the first place.

Flat hierarchy

I’m obsessed with organization, to the point that it starts to hinder my productivity sometimes. I had a folder named "minimalism" that had over ten blogs in it, and a folder labeled "decluttering" for sites that provide tips on the subject–information that I never applied to my feed reader.

Categorizing RSS subscriptions, I’ve realized, makes it easy to just hide feeds I’m only mildly (if at all) deriving value from. For instance, I had a category called "archived" for blogs that no longer publish content, in the off-chance that, someday, the site picks back up again. I know right? I have a problem. It’s the digital equivalent of being a hoarder: Putting junk — old newspapers, broken coffee makers, that unsightly sweater mom gave you — up in the attic where we think they’re out of sight, out of mind.

A flat hierarchy shows me all my RSS feeds in one view, making it easy to pinpoint the ones I don’t need any more.

A maximum of five RSS subscriptions in the first week

During the first week of this exercise, I’ll give myself the option to subscribe to up to five feeds. Having this ability helps kickstart the whole thing back into action. This rule is not accumulative.

Only two RSS subscriptions per week after that

After the starter week, I’ll limit the addition of new subscriptions down to just two a week. This rule is also non-cumulative: If I don’t add two subscriptions this week, I’m not going to get to add four the next.

Previous RSS subscriptions are banned for the first month

To force myself to look for new sources of information and ideas, in the next 30 days, I’ve made it a rule not to subscribe to any of my old RSS feeds.

If I want to read content on my favorite sites, I’ll have to do it the old-fashioned way: Typing their domain name in the browser and pressing Enter.

At the end of the month, I’ll review my browsing history to determine which sites I end up regularly visiting, and I’ll subscribe to their RSS feeds whenever I have subscription allotments available.

Regularly review and update RSS subscriptions

Every now and then, I’ll make a conscious effort to evaluate (and be more critical of) my current subscriptions. I’ll unsubscribe to the one I no longer want to read from. This is so we don’t find ourselves in the same situation that prompted the process in the first place. I feel monthly, or even quarterly, seems like the appropriate interval for this activity.

These guidelines will make us more discerning of our information sources, favoring quality and current relevance over quantity.

RSS Zero every year

I’ll be wiping my feed reader clean at least once a year. Saying this out loud makes it seem crazy. It seems unproductive — like building a house and tearing it down every year — but doing this puts us in the situation where we’re compelled to find fresh sources of content. In my line of work, complacency — being set in my ways — is very deadly.

You may just want to zero-out your feed reader whenever you feel overwhelmed. That could be in six months, or seven years. Trust your instincts.

Moving Forward

These are the things I expect to occur in the aftermath of this activity:

  • The discovery of new sources of content and fresh ideas
  • The ability to read relevant content in a timely and efficient way
  • It will make RSS, as a tool, useful and essential again

Under the right circumstances, there’s still a great deal of value in really simple syndication. But, sometimes, to move forward with something, we just need a minute to start back from zero.

Related Content

About the Author

Jacob Gube is the founder of Six Revisions. He’s a front-end web developer by profession. If you’d like to connect with him, head on over to the contact page or follow him on Twitter: @sixrevisions.

The post RSS Zero appeared first on Six Revisions.

Powered by WP Robot