Intridea - Company Blog

Forming A Design Team, Part II: Process

2015-10-06T00:00:00Z

Here it is peeps, the second post in our journey to create a killer design team…PROCESS. EEEK,*GASP*...I know, firsthand, that process can be a “dirty” word, the bane of creation, and something most companies don’t effectively use. But in this post we’re not going to talk about traditional process, the one where X person get’s a job then hands over some requirements to another person and so on and so on. No...no, here we’re going to be talking about the design process, and yes the two go hand in hand and a lot of the same people are involved (or should be), but in this post I’m going to discuss the parts that make a design team stronger, more efficient, and produce better work.

So where do we start with our design process, especially in the ever changing landscape that is the web? Clark Wimberly from Invision has some great ideas in his post Reimagining The Web Design Process, most notably is that of an agile team. One that is able to easily adapt to changes, and make rapid adjustments as needed. No longer do we work (and live for that matter) in a world that has static or fixed content, so it’s only right that as a team we should be able to rapidly shift to match this.

He goes on to say that we need to stop using mobile first as a buzzword and actually start to approach our design process with smaller screens, using an “Atomic” approach, as Brad Frost would say (more on this in a minute). Clark couldn’t be more correct, especially since Google has recently (May 5th) said they are now getting more search queries on mobile than on desktop.

So, back to that Atomic Design thing...what is it? How does is play into our design process? It’s an amazingly simple, but complex, ideology on how to handle the design and layout of websites. Breaking it down to it’s most basic idea is that you start with a single “brick”, something like a font, or a few color options.Then take those pieces and make a small UI element, like a form or menu, you keep adding small “bricks”, bit by bit, until you’re left with an assembled page. From there it’s rinse, wash, repeat on the other sections of your site. So, how does this work into our process? Quite naturally, by taking our mobile first approach and combining it with this bit by bit assembly we can very quickly and early in the game start to target the areas of our layout that need adjustment, and make the necessary corrections before we’ve gone too far.

Methodology is just one aspect of the design process, there are actual steps, hence the process part, that should accompany that. What those steps are will vary from team to team, but loosely they should be: planning, research, design/development, iterate. What do these mean though?

PLANNING: figuring out what the project timeline is, when it starts and ends, when milestones need to be met, etc. This is also the phase when we need to determine who will be involved throughout the project, making sure the right people are brought in at the right time.

RESEARCH: Make sure that the problem we’re solving is the right one, ask questions WHY, HOW...dig deep to understand the project. Determine who our target is, establish restrictions and needs, to help eliminate questions that may arise later.

DESIGN/DEVELOPMENT(and prototype): Start to layout the concept, get ideas down into something more solid. Simultaneously development can begin with prototypes to test ideas.

ITERATE: Today a design is never truly finished, even after handoff things are bound to come up, so take feedback, comments, etc, and adjust your product to match the needs of it’s users.

A good process, much like a good team, needs to be agile in it’s execution. Not every project will have a need for every step nor will it all allow for every step, so it’s ultimately up to your team lead to make sure the right parts are followed at the right time. Remember that establishing or adjusting a current process can’t happen overnight, it’s a gradual shift, much like our Atomic Design theory, an effective design process should be built upon, bit by bit and allow for rapid adjustment.

Want to learn more? Check out Intridea's post on Forming A Design Team, Part I: Structure

Writing Code for Your Future Self

2015-09-29T00:00:00Z

One of the greatest things about the web industry is the respect and generosity developers have for one another to share knowledge in this ever-changing atmosphere. Whether you're on a small or large team, solo coder or open-source hero, arguably the most important pieces of your code aren't code at all. Commenting and writing readable code can save yourself and teammates valuable time by quickly understanding what your code does without the countless hours you spent carefully crafting the most elegant code imaginable. Even if you're working alone, readable code can avoid those awkward situations of you having to figure out what genius (spoiler: you) wrote this awfully convoluted code. Other benefits include auto-generated documentation and speedier code reviews. So, next time you write the "one function to rule them all", take the time to rename it from doesSomething to addTaxToSubTotal and comment the hell out of it - your teammates and future self will thank you.

What is “Readable” Code?

JavaScript: it was the best of languages, it was the worst of languages. Because of JavaScript’s flexible nature, we can sometimes write code that looks very strange and hard to read. Here are a few guidelines you can follow to ensure you are writing readable code:

Describe: Use descriptive variable and function names, even if they take longer to type. In six month from now, you’ll have a much better chance of understanding what a function does if it’s called getAllCustomerNames rather than getData.

Simplify: Don’t over-engineer your logic to the point of unreadable complexity. Saving a few lines of code while giving up readability is not worth it in the long-run.

Comment: Complex logic is sometimes unavoidable. When it’s not abundantly clear what your code does just by looking at it, comments can lend a helping hand in plain english. Don’t shy away from lots of comments either. Techniques like minification will strip out all comments for production code, so you don’t waste any precious bytes.

Refactoring for Readability

Let’s take a look at some code that could use help to make it more readable. Below we have a function that performs some actions on product information. I will refactor the function so that it performs the same actions, but is much easier to maintain and collaborate on.

function changeData (data) {
  if (data.price > 100) {
    data.label = "expensive";
  } else {
    data.label = "cheap";
  }

  return data;
}

This function is pretty simple, it takes a data object and sets the label property to “expensive” if its price property is greater than 100, otherwise sets it to “cheap”. Although this logic is simple, there are a number of changes that could be made to make this function much easier to read and maintain.

Function name: “changeData” is not a very descriptive name. Since this function is changing product data in a very specific way, we can name the function as such. This will also help developers understand what the function does when it is called elsewhere in the application.

Function parameters: “data” is obviously not descriptive at all. We should rename this to best reflect what piece of data is being brought into the function. Verbose logic: The if statement could be simplified into a ternary statement since there are only two possible outcomes for the label property.

Commenting: We are missing comments for this function, which could provide some great context to the maintainer.

Let’s see what the refactored function would look like:

function setProductLabel (product) {
  /**
   * Set the Product label based on its price.
   *
   * @param {object} product The Product object to update
   * @param {int} product.price The total price of the Product
   * @param {string} product.label The current label of the Product
   * @return {object} product
   */
  product.label = (product.price > 100) ? "expensive" : "cheap";

  return product;
}

ProTip: Put the comment block inside the function so that if you print the function in a console log, the comments print with it.

Conclusion

Writing clean, readable and well-commented code is a skill that needs to be honed and valued. Many developers overlook this, but it’s really what can set you apart from others in your field. And remember any little bit helps, so use the guidelines above to gradually improve your code today!

Any questions, thoughts, ideas? Let us know!

Forming A Design Team, Part I: Structure

2015-08-18T00:00:00Z

For the last eight years, I’ve been doing the design thang, working with companies ranging from a two person team to a large open floor creative group. Adjusting to these various structures was second nature, and not something I ever gave much thought to until now.

With the recent merger of our two design teams - Intridea and Mobomo - a unique opportunity to assist in the restructure and building of our teams was brought to the table. I know this isn’t an isolated situation and the process is in no way easy!

Thus, for the greater of mankind, I will chronicle our journey; the highs, the lows, and everything in between! I’m shooting for a four part series, breaking each post into specific topics: structure, process, tools, and culture.

Structure

I went bananas scouring articles on best practices, must haves, and shit you never do! Everyone has their own “right way” to structure a team - some work, most don’t. And while the ways to structure a team are extensive, the golden ticket wasn’t really structure but specific traits that differentiated a successful from a “meh” team.

Now, like anything, if you don’t establish a solid platform - that jenga tower is gonna fall! So let’s ask a few questions:

What are the key roles?
What kind of team do you want? Singular focus, multi disciplined, elusive unicorn?
What is the goal of your team?

What Are the Key Roles?

As mentioned above, I’ve worked in an array of team structures, but what’s been most effective, not only in my career, but in my research, was that of a “traditional” formation. One involving directors at the top, followed by senior leaders who then oversee the junior level folks. Why does this approach work? There’s a funnel, a singular route of communication, and a cascading approach to mentorship.

Directors drive their team to ask the tough questions; pushing them to think in a different direction, from a different angle. You know never know if the problem you’re solving is the right one, until you ask “why”.

Senior designers are your battle hardened troops, the ones who can articulate and defend their position on a specific choice with facts and rationale. They’ll choose right, over right now, and will fight for what’s correct. They’ll also help mentor and develop junior designers, guiding them to make smart choices and back up their own decisions.

Junior designers will eventually take over the reigns for their senior counterparts, so it’s vital that they learn and develop the key attributes that will make them good mentors one day. Find people with the qualities your company values: hire slowly - fire quickly.

What Kind of Team Do You Want?

Now that we’ve figured out who to hire, we need to establish what kind of team we want. Should our team of designers also know code? Eat and breath exceptional design, and only design? Or should we focus on a strictly UI design team?

What I’ve seen, and what I’ve read, all seem to point to the same thing, diversity! Find folks who bring different strengths to the table and push one another to do amazing things. Though, I should say, there are some must have skills each designer needs:

Be a problem solver, and enjoy it

Possess a great sense of visual design

Able to identify great work

Able to take creative feedback without taking it personally (still a struggle for me)

Most of the other attributes can be taught or learned as they progress.

What is the Goal of Your Team?

Finally, what’s the goal of your team? What are you trying to achieve? For fear of sounding like a cop out, I’d like to revisit this question in the next post. This is a new venture for all of us, and seeing as we don’t really have a team yet, I can’t say what our goal is. I do know that it will involve creating amazing work, with amazing people, but as for concrete and tangible goals: TBD.

Got any insight on team restructures? Let us know!

Setup ngCordova in Ionic

2015-08-11T00:00:00Z

I’ve previously written about the power of the Ionic CLI, which offers some great tools to developers building mobile apps using web technologies. While Ionic offers a CLI and mobile-optimized UI components, it doesn’t handle native level integration, for example accessing a user’s camera, or contacts. Since Ionic is built on top of AngularJS, we can use Angular to access native plugins, and this is where ngCordova comes in.

ngCordova is a framework that makes the native Cordova API available as AngularJS services. In this post, I’ll walk through setting up ngCordova, and accessing the contacts on a user’s device. First, a few prerequisites. You must have the following installed on your machine:

Git (If you want to follow along, or create your own repo)
NodeJS (Installing NodeJS installs its package manager, NPM)
Bower (You can use NPM to install both Bower and Ionic)
Ionic (The Ionic install instructions also have you install Cordova)

I’ve created a Git repository that you can checkout and follow along with, or you can create a new repo and progress through the steps on your own.

First, you’ll want to create a new Ionic app by running this command in Terminal:

ionic start ionic-ngcordova

This starts a new Ionic project, in a folder titled “ionic-ngcordova”. That last bit is arbitrary; you can name it whatever you’d like. Also, this will by default use Ionic’s “tabs” app template (there are others, like “blank”, or “sidemenu” available).

Next, a few housecleaning items I tackle with any new Ionic project. In Terminal, change directories (cd ionic-ngcordova) so you’re in the folder Ionic just created, and enable Sass:

ionic setup sass

Next we’re going to add a few directories to the Git ignore list that shouldn’t be included in our repo. To do this, open the project directory in your favorite text editor. For me, that’s Sublime, so I can open the current directory, with the folder structure visible using:

subl ./

With the project open in your text editor, locate the .gitignore file in the root directory. We’re going to add the following lines to the bottom of this file:

hooks/
www/css/
www/lib/

The hooks directory includes native Cordova JS that’s managed by Ionic, the www/css directory contains your compiled CSS (generated by Sass), and the www/lib directory is where Bower places all its assets (check out the .bowerrc file in the root directory for more info here).

With these steps complete, we have a nice clean repo, and you can run the app in a browser or the iOS Simulator via the command line to make sure everything is working:

// Browser 
ionic serve

// OS Simulator 
ionic emulate ios

Now for the fun stuff. Back in Terminal, in the project root, let’s install ngCordova:

bower install ngCordova --save-dev

This installs the ngCordova package (specifically, in www/lib/ngCordova), and saves it as a dependency in the bower.json file in the app root (The --save-dev flag, a good habit to get into).

Back in your text editor, open up the index.html file, located at www/index.html. This is the root HTML file that your app runs on. Now that Bower has placed the ngCordova library in www/lib/ngCordova, we need to reference ngCordova’s JavaScript file in our app’s index.html file. Include this line after the line that includes the bundled Ionic/AngularJS file:

<script src="lib/ngCordova/dist/ng-cordova.js"></script>

Next, we need to inject ngCordova as a dependency into our AngularJS app. This is done in the app’s primary JS file, located at www/js/app.js. Following the other default controllers and services injected by Ionic, add ‘ngCordova’:

angular.module('starter', ['ionic', 'starter.controllers', 'starter.services', 'ngCordova'])

ngCordova is now available to our app, and we can install and start using any of the native Cordova plugins listed in the ngCordova docs. Let’s see how we’d access the user’s contacts using the $cordovaContacts plugin.

First, we need to install the plugin using Ionic:

ionic plugin add cordova-plugin-contacts

This installs the Cordova Contacts plugin in the plugins directory in the app root. The ‘ionic plugin add’ command is essentially the same as Cordova’s ‘cordova plugin add’. Check out the Cordova docs for more info here.

Now that we have our native plugin installed, let’s emulate using the iOS Simulator, also using the livereload feature of Ionic’s CLI:

ionic emulate ios -l

This will launch the app in the iOS Simulator, and reload in real time as you make code changes in your text editor.

With the app running in the iOS Simulator, we’re only a few steps away from accessing the user’s contacts. First, we need to inject the $cordovaContacts service into the controller where we want to access the contacts from. I think a user would probably access contacts from their Account tab, so let’s open up www/js/controllers.js, and inject $cordovaContacts into the Account controller:

.controller('AccountCtrl', function($scope, $cordovaContacts) {

With the service available to our controller, we’ll add two buttons that will allow the user to select a single contact, or multiple contacts, respectively. Open up www/templates/tab-account.html, and add this markup following the closing tag. This will use the standard Ionic button markup:

<button class="button button-positive button-block">
  Get Contact
</button>

<button class="button button-positive button-block">
  Get Contacts
</button>

Now for the magic. Our last step is setting up a function to be called when the user touches a button, and calling the $cordovaContacts appropriately based on which button they’ve touched.

First, let’s add the click handlers using Angular’s ng-click directive:

<button class="button button-positive button-block" ng-click="getContact()">
  Get Contact
</button>

<button class="button button-positive button-block" ng-click="getContacts()">
  Get Contacts
</button>

At this point, your app should look like this:

Lastly, let’s create the functions in www/js/controllers.js. In the AccountCtrl controller, add the following lines after the $scope.settings object:

$scope.getContact = function() {
    $cordovaContacts.pickContact().then(function(result) {
        console.log(result);
    });
}

$scope.getContacts = function() {
    $cordovaContacts.find({multiple: true}).then(function(result) {
        console.log(result);
    });
}

If you hit ‘c’ in Terminal, this will enable Ionic’s console logs feature, and you’ll see the contact objects being logged as you touch the buttons. Alternatively, you can launch Safari, then go to Develop > iOS Simulator and visit the full Safari console there.

You’ll notice that touching the “Get Contact” button launches the native iOS contact picker component:

The “Get Contacts” button simply grabs all the contacts on the device and dumps them to the console, in all their gory detail. Creepy:

While ngCordova is the bridge that allows easy access to Cordova plugins via AngularJS, all the Cordova plugins available have more documentation than is found on the ngCordova site. You’ll notice an “Official Docs” link on each ngCordova docs detail page, which points to the original Apache/Cordova documentation, for example the official Cordova Contacts documentation.

Hopefully you can see how in just a few steps, we’re able to setup a new mobile app using Cordova, leverage Ionic’s tools and UI components, and further layer in ngCordova to access Cordova plugins via AngularJS.

Any questions, thoughts, ideas? Let us know!

Want to learn more? Check out Intridea's posts on Ionic CLI and Ionic Experiments

Ionic Experiments: Ionic Material, Angular Material, and Polymer

2015-08-04T01:10:00Z

There’s been a lot of buzz around Google’s Material Design recently, from Material Design Lite (Google’s non-JS implementation of Material Design), to Angular Material (Google’s Angular port of the Material Design library), to Ionic Material (a non-Google project that builds on top of Ionic’s UI), and even Google’s Material Design implementation with Polymer’s Paper Elements.

Envisioning a scenario where a client has heard of Google’s Material Design, and requests it as the UI basis for a mobile project, I set out to see what would happen when we start to implement some of these new front-end options in an Ionic/Cordova app.

Angular Material

Angular Material is an implementation of Material Design in AngularJS, that’s supported internally by Google. It provides UI components from the Material Design library as easy-to-implement AngularJS directives, and has a strong focus on accessibility, which is a big concern with AngularJS apps.

The demos for Angular Material are very well fleshed out, and it looks promising. I was able to integrate into Ionic easily, as both run on AngularJS. I spent almost zero time on CSS, but I was able to achieve comparable results.

Here’s what the Angular Material md-card directive looks like (Ionic on the left, Angular Material on the right):

Here’s what it looks like when you swap out the Ionic list directive with the Angular Material list directive:

I’ve created a demo repo if you’d like to see the changes I made, and download, run and play with the implementation yourself.

Ionic Material

Ionic Material is not maintained by Google, but has some pretty slick demos. It’s designed to be layered on top of Ionic, and enhance the existing directives, meaning it’s even less of a switch than implementing Angular Material.

Upon setting it up in the app, I didn’t really have to change much other than adding Ionic Material to the project, and already the “material” design impact is felt:

I’ve also created a repo showing the implementation of Ionic Material in an Ionic app.

Polymer

Is implementing Polymer in an Ionic app a good idea? Who knows. Probably not. I wanted to see how far I would get before running into issues.

Implementing Polymer in Ionic was fun, and the bonus here is that you’re using web components which are on track to be standardized in browsers, so you have to love the compatibility forecast. I was able to replace Ionic’s header with Polymer’s paper toolbar, I added Polymer’s iron-pages and paper-tabs in place of Ionic’s tabs, and converted the layout to use the paper-scroll-header-panel web component.

This screenshot is taken as the touch animation is firing on one of the tabs:

I’ve created a repo for the Ionic Polymer experiment, so you can check out how that looks locally.

Summary

Angular Material is currently at 0.10.0, so I ran into components that didn’t work pretty quickly. That FAB Speed Dial component sure does look snazzy, though. It’s an internal Google project, so I expect we’ll see a lot coming soon. Since it’s so early in the development, I’m going to put this one on my watch list and kick the tires again once a bit of time has passed.

Ionic Material is even earlier in its development, currently at a 0.0.1 release. It will probably be the easiest to implement, once its ready. While not an official Google project, this is also one to put on your watch list.

Polymer starts to clash with AngularJS pretty quickly. For example, I ran into issues with data binding, and I really was just scratching the surface. It’s probably best to implement Polymer as a Cordova app, without Ionic, so you avoid these conflicts. Of course, you also lose a lot of value if you remove Ionic from the equation, so there’s room for discussion, depending on the project.

Hopefully this has given you some insight into the recent developments surrounding Google’s Material Design library, and how they might fit into your Ionic mobile app development cycles.

Any questions, thoughts, ideas? Let us know!

Want to learn more? Check out Intridea's post on Ionic CLI.

Don't Abandon CSS Just Yet

2015-07-28T00:00:00Z

There's been a tremendous push in recent months to move all of the components used for building anything for the web in to JavaScript, and only JavaScript (abandoning the use of HTML for templates and CSS for styling). While I can understand how we've gotten to this point, I think we're at risk of ignoring potentially more robust solutions. Rather than build up your application (or site) using a single monolithic JavaScript framework, I implore you to consider something that's a bit more open-web and future friendly: continuing to build with component-based architecture using all of the current tools available to you, and looking forward to use web components.

Before we get into why I think component-based architecture is the correct way for now, and web components are the way of the future, let's explore how we've gotten to where we are today.

It starts out innocently enough: you apply an ng-click attribute to a link or a button in your template. Then you add a couple of additional lines of markup to handle an if/else pattern to that template (<span ng-if="truthy"></span><span ng-if="falsy"></span> seem familiar?). Before you know it, you're applying ng-mouseover and writing custom directives to handle events specific to your markup.

Others might be looking at this and decide that it's lunacy to have all of that written by you, in-line in your template (and they're probably right -- if you're adding a lot of logic to your template, you probably need to reconsider what you're doing and approach the problem from a different angle). It's difficult to maintain, tightly couples your template to the controller logic behind it, and it's really not the template's job to manage complex logic.

However, rather than refactor to use unobtrusive JavaScript patterns or to extract out difficult logic so it's not present in the template, there's a push (primarily from the React project) to build everything up using JavaScript. Your logic (controllers, models, etc), your templates, and even your CSS. The thinking is, for the most part, that if you are doing these complicated decision trees in the code, then it should be handled by something designed to handle said complicated decision making.

For those who've been building websites and applications for long enough, seeing something that looks like this:

<div
  onMouseOver="{() => this.setState({ hover: true })}
  onMouseLeave="{() => this.setState({ hover: false })}"
  style={{borderColor: this.state.hover ? 'red' : 'transparent' }} />

...should remind you of nightmares of years past. This largely disregards the efforts of WASP (Zeldman, Meyer, Holzschlag, et al) and, more recently, the Web Standards Sherpa that lead the charge on making the web more maintainable (proper HTML markup, separation of style, content, and behavior) and future friendly. Additionally, we return to a state where the separation of concerns is being tossed out altogether and we're being asked to ignore years of learning in the favor or writing everything in JavaScript.

A typical React component would look something like this:

var buttonBase = {
  padding: 5,
  border: "1px solid #aaa",
  borderRadius: 5,
  backgroundColor: "#eee",
};

var buttonBaseHover = _.defaults({
  backgroundColor: "cyan",
  borderColor: "magenta",
  cursor: "pointer",
}, buttonBase);

var BasicButton = React.createClass({
  getDefaultProps: function() {
    return {
      type: "button",
      label: "Click me",
    };
  },
  getInitialState: function() {
    return {
      isHovering: false,
    };
  },
  propTypes: {
    type: React.PropTypes.string.isRequired,
    label: React.PropTypes.string,
  },
  handleMouseOver: function() {
    this.setState({isHovering: true });
  },
  handleMouseOut: function() {
    this.setState({isHovering: false });
  },
  render: function() {
    return (
      <button
       type={this.props.type}
       style={this.state.isHovering ? buttonBaseHover : buttonBase}
       onMouseOver={this.handleMouseOver}
       onMouseOut={this.handleMouseOut}
      >
        {this.props.label}
      </button>
    );
  }
});

React.render(<BasicButton label="Demo Button" />, document.getElementById('container'));

See the Pen React Button Component by Mike Tierney (@miketierney) on CodePen.

While this has the merits of being transportable (one of the better arguments for this style of development), it lends itself to higher maintenance issues. Like the common complaint of CSS, this is the sort of thing that quickly ends up creating bloat - it's easy to envision a scenario where a "BasicButton1" gets added because a developer is uncertain about making changes to it. While conditionals could be added to the render method, you then have added processing impact on whether or how to render the button. Many developers will make the same mistake here that they do with CSS: "I don't know where this is used, so I'll just make a copy of it, modify it, and use that in my implementation." Both are signs of maintenance issues, and both can be addressed with proper processes and practices (like code reviews).

One Tool For All Jobs

If we move towards using One Tool For All Jobs (in this instance, JavaScript), we neglect the fact that the tools we're abandoning are actually quite good at doing what they need to do. CSS does a great many of the things that are related to styles far better than JavaScript and it has the added benefit of being cacheable, leveraging readily available resources (rather than littering your JS scope with event handlers for every element that needs to support interactivity; that can impact performance pretty heavily), and with proper use of the cascade you can more easily create variant styles as needed (site theming as a whole, for example).

To handle that hover effect from earlier in the post, you'd need to do this:

<div class="hover-div"/>

.hover-div:hover,
.hover-div:focus {
  border-color: red;
}

I've also added the :focus pseudo-class so we also have keyboard support. It'd take more than that to add that same support into that inline sample, and you're providing better support for your users. :focus is a relatively small thing by itself, but think about the broader implications. A natural byproduct of this is to rebuild native components. As an example, we're already rebuilding the select menu (because it's too hard to style natively), and that's just the start of a slippery slope. This should not be the norm - rebuilding existing browser components and behaviors in pure JavaScript might seem appealing (because you have total control over what it does, more or less), but the overhead of creating it in the first place is inevitably going to be greater than anticipated, and then you have to take into consideration the fact that you now have to maintain that. Furthermore, you now have to accommodate all current and future interaction patterns, UX experiences, and many other OS-level features that users are already familiar with in order to make your fancy widget not seem out of place. Is it really worth that? Do you really need (or have) that level of control? Why would you want to abandon future improvements that will roll out as browsers and standards improve? Finally, on this particular point, you'll also need to factor in support for assistive technologies. Just because you're building a "web app" doesn't mean you get a free pass to just ignore those users.

Many of the proponents of using this all-in-javascript approach are focused solely on making sure that everything is managed locally (as opposed to globally, which is how CSS operates). They neatly solve this "pollution" of the global space by injecting all of the styles directly on the element being styled, which is truly the only way to avoid that issue. However, this comes at a cost -- more complex elements can potentially have a significant number of style selectors (and let's be honest here, we're still using CSS whether it's in the DOM or in a dedicated stylesheet). This leads to greater DOM bloat, and more re-draws of elements within a page when states change, content is updated, or the initial view is rendered. While these things may not impact the immediate load time of the page, there's an overall impact on page rendering because of this. CSS isn't free of this, certainly, but one advantage of loading those files once is that this is minimized. Additionally, for things like layout and global styles, you want to have a more global take on things. For re-usable components (buttons, form elements, links) - why make the browser evaluate and render style for every element one at a time when you can pre-load the styles into memory and when a node appears that matches the selector, the styles will be applied.

Component-based Architecture

My counter-proposal would be to use one of the better trends we've seen lately: component based architecture. Build small to large - much like the members of the React team who are advocating for using CSS in the JavaScript application want to do. This can be done with traditional techniques, however, and diligence to fending off entropy and bad practices. With tools like Sass and Less, we have the ability to create small files that are focused purely on building out a single component, which can then be stitched into the larger application as whole. When building a single page application, we can even start using an approach where our JS, HTML, and CSS all live together in the same directory, to later be concatenated,minified, and then moved into the appropriate locations. With a reasonable application of namespacing in CSS (pick your poison; I'm partial to SMACSS), we can accomplish the same goals - re-usable, easy to maintain, components - without jamming everything in to JavaScript.

Right now, I think a compromise is a mix of global and local styling. I still think styles added directly to DOM nodes is a mistake (with some exceptions -- an argument can be made for inlining styles on canvas/svg-based charts, for example, and I'm sure there are other situations, but those should be the exception and not the rule). We should think about making our components themable as much as possible, re-using tools that are available to us (the Cascade naturally supports this sort of behavior), and embrace the fact that we never have 100% control over the way our web-based application will look and behave. There are simply too many variables that are out of our control.

If you're concerned that your team is too large and you cannot communicate some of these practices widely, there are plenty of tools available to look for unused CSS, duplicate CSS, "bad" CSS, and inefficient selectors. These can be integrated in to your build process or development flow, depending on your preference.

One final point to make here is that we need to ensure that we are optimizing for our users. When we make the browser do all of the work for us because it makes maintaining a code-base easier, that's fine up to a point, but we need to be mindful of the overall impact that that has on the experience of the end-user. This also means, rather uncomfortably, that we (as developers) need to embrace that there are a great many things that are out of our control, and we should build our solutions to be as flexible as possible. Otherwise, we'd still just be building it all using Flash.

Additional recommended reading:

The Debate Around "Do We Even Need CSS Anymore?" (Chris Coyier)
JS Dominance Over the Presentation Layer (Dale Sande)
React is a Terrible Idea (Dan Yoder); note that I don't necessarily agree with the title, but the overall premise is solid
Practical Questions Around Web Components (Ian Feather); a thorough, if harsh, look at some of the Web Components spec's short-comings

Intridea joins team Mobomo

2015-06-16T00:00:00Z

I'm thrilled to announce that Mobomo has acquired Intridea.

Our teams are a perfect fit of complementary skills:

Mobomo focuses on Rails web development and mobile expertise, especially in the government space. Mobomo is the team behind NASA.gov, the official Navy mobile apps, and USASearch—the search engine that will eventually power every single query for the United States Government.
Intridea has evolved into a product development, user experience, and AngularJS consultancy with a focus on startups and the enterprise. If you've read business news, received a paycheck, opened an email, had a baby, or attended a wedding, you've encountered Intridea's work. Our designs are viable, useful, and engage tens of millions of users.

Few agencies offer a best-in-class combination of user centered software design and engineering services. By bringing together Mobomo and Intridea, our teams will ship mission critical applications to our Fortune 500 clients.

We share a common DNA in Barg Upender, who co-founded Intridea in 2007 and founded Mobomo in 2009. Joining Mobomo feels like coming home.

Angular & Promises: Taming the Async

2015-05-26T00:00:00Z

What is Async?

Async (aka asynchronous) JavaScript refers to the execution of more than one piece of code at the same time. This is great because it prevents your application from freezing up when certain code takes a long time to execute, but it can also cause issues in your code if you are expecting something to be complete when it may not be. These situations are called race conditions. Here is an example of when a function is performing asyc code and we don’t get the result we are expecting: http://codepen.io/dganoff/pen/oXLNeb. Notice the name variable isn’t returned as “Bob”, but is instead returned as it’s initial value.

Enter: Promises

Promises allow developers to detect when asynchronous code finishes and then act on it. Instead of a function returning a value we expect, we can have it return a Promise, and then let the Promise tell us when the value is ready to use. Now let’s take a look at how Promises can fix our issue in the original example: http://codepen.io/dganoff/pen/QbNxJq. Using the built-in promise library $q that ships with Angular, we can return a Promise instead of just the name variable. The Promise is “resolved” after the timeout finishes, which tells the promise to execute its then method to finally return the value we originally wanted.

Real-world GitHub API Example

One of the most common uses for Promises is within a Service that makes a HTTP call and returns the response to a controller. Since HTTP calls take some time to finish, they are a prime candidate for Promises. Here’s an example of how we can use a Promise to return the HTTP response to a controller when it’s ready: http://codepen.io/dganoff/pen/zGKpzv

Advanced Promises

Let’s say you need to make a number of consecutive HTTP calls within your Service before returning the result back to the controller. The $q library has a very useful method call $q.all. This allows you to pass an array of Promises to the method and it will only execute its ‘then’ method once all Promises have been resolved. This prevents any race conditions when executing multiple HTTP calls before performing another action.

Another case where we can use multiple Promises is a technique called ‘Chaining Promises’. Sometimes within a controller, we’ll need to call one HTTP Service before another HTTP Service can be called, in case we need information from the first Service. The nice thing about $q Promises is that the Promise itself returns a Promise. This way we can have a function return one of our Services that returns a Promise and then act on that once it’s ready. If we take our GitHub API example, I can chain the ‘getGithubUserInfo’ function with another function by returning a Promise. This is what that might look like: http://codepen.io/dganoff/pen/aOmEVZ

Conclusion

Promises are a powerful tool in software development. Any web developer should have at least a basic understanding of Promises, if not a thorough grasp of the concepts discussed in this article. Please feel free to fork and edit these codepen examples to test our your own skills with Promises so you can master this critical technique.

The Ionic CLI

2015-05-19T00:00:00Z

With the release of Ionic 1.0, we’ve reached a new level in building hybrid mobile applications via web technologies. While Ionic is probably more well known for its CSS components and JavaScript/AngularJS extensions, I’d like to highlight a few tools that have really improved my ability to develop applications rapidly, which are included with the Ionic CLI.

The first, and probably most time-saving tool in the Ionic CLI, is the ability to live reload your app as you make code changes. Prior to being able to live reload, if you wanted to preview/test changes in a simulator or on an actual device, you would have to “build” (or compile) your app’s package, and then “run” (or install on the device, and launch). Web developers familiar with using live reload in Chrome to debug web apps will be very familiar with the Ionic CLI live reload process. Each time you save an HTML, CSS, or JS file that’s being “watched” in your app, the app will refresh while running on your device, so you don’t have to build & run each time (which is a very slow process). You can also change the files being watched by editing the watchPatterns in your ionic.project file. Read more about the live reload tool on the Ionic blog, or in the CLI documentation.

One of the great features of developing hybrid apps is leveraging the same code base for building iOS and Android apps. Ionic’s CSS components and JS extensions appear differently on iOS and Android, as they’re geared to mimic each native platform closely. The Ionic Lab tool allows developers to launch a browser window displaying how the app would look and behave on both iOS and Android. Since its running in a browser, it’s not going to allow you to preview native-level functionality, like if the ngCordova $cordovaCamera service performs differently on each platform, but it is very handy for monitoring CSS changes, and whether a change you made breaks something on one platform, but not the other. It also comes with the aforementioned live reload tool built in, so you’ll see both the iOS and Android version of your app refreshing in real time. Read more about Ionic Lab on the Ionic blog, or in the CLI documentation.

The last tool I really appreciate is the ability to print your app’s console logs to the Terminal tab you’re running the app from. There was a time when, before Safari allowed debugging of an iPhone connected to a Mac, developers had to hack together a solution in order to gain visibility into the JS running in their hybrid app running on a device. This consisted of Xcode logs and a tool called WEINRE (“WEb INspector REmote”). It was not pretty. Suffice to say that the ability to access the console logs of your app running on a device by simply passing the “-c” flag when running the “ionic serve” command is nothing short of a godsend. Read more about the command line flags available with the Ionic CLI.

While using live reload, Ionic Lab, and a combination of console logs and other tools available with the Ionic CLI have vastly improved the speed with which I can build hybrid mobile apps, the Ionic CLI currently has many additional features. You can emulate or run your app on a simulator or actual device, automatically generate the icons and splash screens required for both iOS and Android, or share your app with others using Ionic View. There are also many more exciting things in the pipeline, like Ionic Deploy (update your app without having to resubmit to app stores), Ionic Analytics (track all activity in your app), and Ionic Creator (prototype Ionic apps using drag-and-drop components).

Its an exciting time to be a hybrid mobile app developer, and Ionic is leading the pack when it comes to modern hybrid frameworks. Start building your own apps today!

Extending AngularJS's $log

2015-05-12T00:00:00Z

Have you ever been working with a particularly complicated web application and found that the output you were getting back from $log was difficult to wade through? Perhaps it's a complex XML response (because you're working with a SOAP API), or it's a particularly dense JSON response. Maybe the browser you use as your primary workhorse is working fine, but you found a gnarly bug in handling the response you're getting back from an API and it's failing in one of the other browsers you’re testing?

I recently ran into an issue similar to this; for me, it was while working with a SOAP API. And while the browser I'm using has all of the necessary development tools, emitting the responses I was looking for in an easy-to-read way was just not happening for me. No matter how I went about logging it all out, the response was coming back as a single line of text when emitted to the JavaScript console, and because it was a string I was having trouble easily inspecting it. While I wasn't having browser-specific issues (in this case), needing to add the extra effort of moving over to a view in my debugger was costing me precious turn-around time in trying to debug this response. If I was having this sort of issue with these responses, then the other developers on my team likely were as well.

After doing some research, I came across a fairly light-weight library called vkbeautify, which handles beautifying (as well as minifying) strings that are passed in to the appropriate method. This solved part of my problem: I now had a way to programmatically re-format my XML strings. Now, I could have stopped with simply injecting the library into the application, then just emitting out the formatted strings while I was debugging the issue I was trying to resolve. However, as I mentioned earlier, I'm working as part of a larger team, and I wanted the rest of the team to have this ability as well. Furthermore, I wanted us to be able to selectively emit data into the console in a consistent manner with some sane defaults.

The next logical step was to look at the $log service. Since this is an abstraction of the global console interface (log, info, warn, debug, etc) and it had the benefit of being stubbed so it wouldn’t display in unit tests, it made sense that I should simply extend that service. That way, any developer could call a method of the $log service to emit these nicely formatted strings.

To accomplish this, I created a provider decorator for $log and made it available from within the application. One of the nice things about provider decorators is that you can leverage a reference parent service and then call that service’s methods, which was nice because I wanted to leverage the existing infrastructure as much as possible – truly extending the $log service. So, I added a new method (called pretty, a nod to the concept of "pretty printing," which is common in most programming languages), and had that piggy-back on one of the other methods in the service. It looks a bit like this:

angular.module("myApp").config(["$provide", function ($provide) {
  $provide.decorator("$log", ["$delegate", function ($delegate) { // $delegate, here, is an internal       reference to $log
    $delegate.pretty = function (input, opts) {
      var output;
      opts = opts || {};
      output = vkbeautify[(opts.type || "json")]](input); // use the correct vkbeautify for beautifying the        string - vkbeautify.json, vkbeautify.xml, vkbeautify.sql, etc; defaults to json
      $delegate[(opts.output || "log")].call(null, output); // leverage one of the other $log methods to    actually emit the output; defaults to log
    };
    return $delegate;
  }]);
}]);

Now, in our application, when a developer makes a call to $log.pretty(), the input they pass to it is run through vkbeautify with the given data type and output method (defaulting to json and $log.log, respectively). These values can be changed by passing in an Object as the second parameter with a property of type or output set to the desired value. Here are a few examples:

$log.pretty("<div><h1>Hello world</h1></div>", {type: “xml”);
//
// <div>
//   <h1>Hello world</h1>
// </div>

$log.pretty("body:{background:#fff;}.rounded_box:{border-radius:20px;}", {type: "css"});
//
// body: {
//   background: #fff;
// }
// .rounded_box {
//   border-radius: 20px;
// }

$log.pretty({jsonObj: {childAry: [1,2,3], childObj: {someProp: "prop"}}}, {output: "info"}); // this would    emit using $log.info; leveraging that type is defaulted to json
//
// {
//   jsonObj: {
//     childAry: [
//       1,
//       2,
//       3,
//     ],
//     childObj: {
//       someProp: "prop"
//     }
//   }
// }

While I lose the ability to log out multiple items with this method (console.log(var1, var2, var3), for example), I gain the far more important ability to emit nicely formatted output that is easier to scan and understand. The big take-away here is that you can leverage the ability to extend $log to create output necessary to make debugging your code simpler. Think of the existing API as a starting point, and go from there. Chances are good that most use cases are already covered, but there's always something that isn't.

Finally, to help anyone else that finds themselves in this specific situation, I’ve released this as a package that’s available on bower. Just run bower install ng-log-pretty and include both vkbeautify and the library itself in your application and you’ll be off and running. You can also check out the code on GitHub.

7 Tips for Rockin' Autonomy Work Life

2015-05-05T00:00:00Z

Sticking to a schedule, writing out your daily goals, and keeping yourself motivated are crucial to a healthy and effective remote position. Here are a few tips from a seasoned remote veteran:

1. Sticky Notes

Write down your tasks. The physical act of writing down, crossing out, and throwing away a sticky note is amazing! Scientifically speaking, this is more than just writing on a piece of paper. It’s a way to calm your mind, focus on the task at hand, and see through a project vs. aimlessly wandering through your day.

2. Breaks

Know that busy does not equate to productivity. If you’re feeling burned out at 10 am after an hour of research - TAKE A BREAK. Go for a walk, grab a coffee, or give someone a call. Step back from your computer and let your mind recharge. Some of the best musicians work in 90 min intervals and are consistent about 15-20 minute breaks.

3. Routine

Stick to a schedule. Wake up at the same time, exercise, eat breakfast, journal, and most importantly SHOWER. Just because you work from home doesn’t mean you should roll out of bed and go straight to working. Developing the habit of routine will help you work at optimal times and have a sense of accomplishment at the end of the day.

4. #standup updates

This is a strategy @Intridea uses for most projects and day to day operations. It’s a way of building accountability and awareness with our peers in regards to individual to-do lists. Working remotely can often feel like a silo and keeping everyone informed of your “work list” not only helps you to stay on task, but keeps others from derailing you with “emergency, last minute” requests.

5. Plan the Night Before

Create tomorrow’s to-do list the night before; it’s at the forefront of your mind and writing them down will keep you from dwelling on them throughout the night. Empty your brain and save valuable morning time by utilizing those last 15 minutes of your day to set tomorrow up for success.

6. Know When to Stop

Fight the urge to check work email after a certain time. Make it a point to shut down and be present with your family and friends. Traditional employees have the luxury of separating home life from work life, you however will need to be intentional with your personal time and designated “work” hours.

7. Social Media fasting

Block out times in the day for social media and honor your schedule. Facebook and Twitter can easily destroy productivity and suck hours away from your day! Know yourself and know when you work best - avoid these distractors and use them as rewards for getting stuff done vs. wasting your valuable time and energy on it.

Got any remote working hacks? Share them with us on Twitter!

Reduce Your AngularJS Code and Improve its Readability Using ECMAScript 6

2015-04-28T00:00:00Z

If you’re reasonably up-to-date with front-end app development then there’s a good chance you’ve heard the buzz flying around about ECMAScript 6. For those unfamiliar, ECMAScript 6, also known as Harmony, is the next major version of JavaScript programming language. In this post, I’ll utilize new ECMAScript 6 features to reduce and improve readability of code in a sample AngularJS application.

Our sample application is a simple baseball card auction app that serves as a platform for users to sell rather valuable baseball cards and consists of three Controllers (BaseballCardsCtrl, BaseModalCtrl, and ConfirmModalCtrl) and three Services (UserService, CardService, and NotificationService).

Block-scoped bindings and arrow functions

The very first thing our application needs to do is fetch the current user’s profile, so we’ll start by taking a look at the getUserInfo function of our UserService which is responsible for retrieving the user’s information.

function getUserInfo() {
    if (user) {
        return $q.when(user);
    } else {
        let handleSuccess = (response) => {
            user = response.data;

            return user;
        };

        let handleError = (error) => {
            NotificationService.logError('Unable to retrieve user info', error);

            return null;
        };

        return $http.get('/dist/data/get_user_info_response.json').then(handleSuccess, handleError);
    }
}

This function uses two of the new features of ECMAScript 6, namely block-scoped bindings, and arrow, or lambda functions. The handleSuccess and handleError functions above are declared using the let keyword, which restricts them to only being accessible by code in the same block; in this case, the else block of our if-else statement. This increases the overall readability of our code by moving variable or function declarations and assignments into the block where they’re intended to be used. Both handlers make use of arrow functions which provide a shorthand, expressive syntax for defining functions. In addition to providing a more compact syntax for defining functions, arrow functions also lexically bind the “this” keyword value, eliminating the need to manually bind object context when registering event handlers and such.

Generators and paused execution

Next, let’s take a look at an excerpt from our BaseballCardsCtrl that uses the UserService’s getUserInfo and CardService’s getCards methods to retrieve and store a reference to the user’s profile and baseball card data.

var it;

initialize();

function initialize() {
    vm.notifications = NotificationService.getNotifications();

    it = fetchData();

    it.next();
}

function *fetchData() {
    vm.user = yield getUserInfo();

    vm.cards = yield getCards(vm.user);
}

function getUserInfo() {
    UserService.getUserInfo().then((user) => { it.next(user); });
}

function getCards(user) {
    CardService.getCards(user).then((cards) => { it.next(cards); });
}

The most interesting thing to note about the above code is the *fetchData function declaration. The function name is prefixed with an asterisk which is a new, special naming convention that results in the function returning a Generator object, another new feature of ECMAScript 6.

Generators are special Iterators that can pause their execution when the yield keyword is encountered. The ability to pause function execution allows us to control the order of asynchronous operations without need to use a series of nested callbacks. In our initialize function above, we store a reference to the Generator object on which we immediately invoke it’s next method to instruct *fetchData to begin executing its function body. The *fetchData function calls getUserInfo then pauses due to the presence of the yield keyword. The getUserInfo function is responsible for registering a callback function to be executed once the user’s information is retrieved from the server. Once the user’s information is retrieved, the callback invokes the Generator’s next function with the user data, which is returned by the first yield statement in *fetchData. The *fetchData function then releases the pause allowing execution to continue and the getCards function to be invoked with the necessary user data.

Object destructuring and string templates

Now that our application has been wired up to retrieve the necessary user and baseball card data, it needs a way to allow our user to actually sell his cards. The following snippet is from our CardService.

function sellCard(card, index) {
    return $http.get('/dist/data/sell_card_response.json').then(handleSuccess, handleError);

    function handleError(error) {
        NotificationService.logError('Unable to sell card', error);

        return null;
    }

    function handleSuccess() {
        var { year, firstName, lastName, value } = card,
            dollars = $filter('currency')(value);

        cards.splice(index, 1);

        UserService.updateBalance(value);

        NotificationService.logSuccess(`Sold ${year} ${firstName} ${lastName} for ${dollars}`);

        return card;
    }
}

The majority of this code looks similar to what you’ve seen in other AngularJS applications with one exception, the first line within the nested handleSuccess method. This particular line uses what’s called Object Destructuring, another one of our new ECMAScript 6 features. Object Destructuring provides a shorthand syntax for declaring one or more variables with their values being initialized as property values of a target object. This is only a very basic example of how one might use Object Destructuring to consolidate multiple variable declarations into a single statement; it does support more complex mappings to nested object properties as well.

Another difference you may have noticed is our use of a string template to build a success message to be used as a “successful sale” notification. Traditionally, this would have been accomplished by concatenating multiple string literals with variables, but now we can achieve the same result using much more concise, readable syntax using variable interpolation with template strings.

Classes and prototypal inheritance

One requirement of our application is to prompt our users to confirm that they would like to proceed, after clicking a button to sell a particular baseball card. For this demo we use the UI-Bootstrap modal for our confirmation prompt. In real world applications there is often the need to utilize many different modals that implement a common subset of functions to handle repetitive tasks such as closing the modal when the user clicks a Cancel button. Implementing these functions for each modal leads to redundant code. Fortunately, ECMAScript 6 introduces a new way to approach prototypal inheritance in JavaScript using a more concise, readable syntax.

function BaseModalCtrl($modalInstance) {
    'use strict';

    var vm = this;

    vm.dismiss = $modalInstance.dismiss;
    vm.close = $modalInstance.close;
}

First we define an ordinary constructor function that creates dismiss and close members that reference the $modalInstance service’s dismiss and close methods. Admittedly, there’s nothing new or interesting to see here but in our next code excerpt, we will see how we can easily extend this functionality when we create our ConfirmModalCtrl.

class ConfirmModalCtrl extends BaseModalCtrl {
    constructor(data, $modalInstance) {
        super($modalInstance);

        this.data = data;
    }
}

While this feature isn't a new concept in JavaScript language, it does provide syntactic sugar, and achieve prototypal inheritance using a more concise, intuitive syntax. ECMAScript 6 classes and inheritance offer a standardized way to define JavaScript class constructors, public and private members, and make superclass methods calls. Of course, this is all possible today using native ECMAScript 5 code, but the syntax is not as elegant or intuitive. We now have an easy, readable way to extend functionality and eliminate code redundancy in our JavaScript classes.

Structure through modules

Lastly, let’s learn how to import various application components and register them with AngularJS. Historically, JavaScript has lacked a native way to structure applications and manage component dependencies. However while AngularJS does have its own dependency injection mechanism, it does not support importing external dependencies and requires components be available from within the current scope before registering with Angular.

ECMAScript aims to provide a native, standardized way to handle importing external dependencies with the introduction of modules. Lets take a look at how we can utilize the new module syntax to import external file dependencies and register our different components with Angular.

 import BaseballCardsCtrl from './controllers/baseball_cards.ctrl.js';
     import ConfirmModalCtrl from './controllers/confirm_modal.ctrl.js';
     import UserService from './services/user.service.js';
     import CardService from './services/card.service.js';
     import NotificationService from './services/notification.service.js';

 angular.module('demo', ['ui.bootstrap'])
  .controller('ConfirmModalCtrl', ConfirmModalCtrl)
  .controller('BaseballCardsCtrl', BaseballCardsCtrl)
  .service('UserService', UserService)
  .service('CardService', CardService)
  .service('NotificationService', NotificationService);

As you can see in our above example, ECMAScript 6 modules introduce the new import keyword, allowing you to reference application components defined in external files. Here, we import each of our AngularJS application components (BaseballCardsCtrl, ConfirmModalCtrl, UserService, CardService, and NotificationService) and register them with our demo application. Each of our components uses an export statement, another new keyword in ECMAScript 6, to selectively make internal components available for import and use in other files..

 export default NotificationService;

  function NotificationService($log, $timeout) {
  ...
  }

The import and export statements support different syntax giving you flexibility over how components are referenced throughout your application. Note: We’ve only used the most basic, as it fulfills our application’s current needs.

Conclusion

ECMAScript 6 is still in draft mode and its specification isn’t expected to be officially published until later this year. For this reason, modern browsers currently have varying or incomplete support for many of the new language features. Fortunately though, there are quite a few tools to integrate support for ECMAScript 6 into your workflows and translate the code to ECMAScript 5 compatible syntax. As the release of the new ECMAScript 6 specification approaches, its new features are being integrated into more and more applications.

JavaScript is one of the most popular and widely used programming languages today; it’s not going anywhere any time soon and as it continues to evolve, so should our applications to harness it’s full potential and expressiveness. Our sample application uses one subset of the new features available in ECMAScript 6; there’s a lot more to it than what we’ve seen in this short example. For more complete information on ECMAScript 6 and how to integrate support for it in your workflow, check out the following resources.

Application

Demo: http://embed.plnkr.co/dLK1ruytvNSljXz5L3CV/preview

Repository: https://github.com/rjw209/angular-es6-demo

Resources

Draft EMCA 262

EMCAScript 6 Tools

EMCAScript Compatibility Table

JSRocks

3 Things I Learned While Working Remote

2015-04-21T11:20:00Z

Working remote is great; autonomy, flexibility, work/life balance, you name it! However, while the benefits severely outweigh the costs, working from home does present its own set of challenges. Below are the findings of a veteran to remote working.

1. You get to work from home, but you shouldn’t always.

Working remote is the freedom to work from anywhere. Often times we get fixated on remote equaling home office, but it so much more than that! Perhaps you enjoy working out in the sun, or maybe a little structure at a co-working space is your thing? Whatever it is - the point is you get to choose and that’s a beautiful thing.

Some of my best connections, ideas, and productivity have occurred outside the home office, so just because you can work from your kitchen, doesn’t mean you always should.

2. Autonomy is amazing, but also requires intentional discipline.

When describing my job, I often equate it to being your own boss w/o the usual entrepreneurial stressors. However, while there’s tons of freedom, with that freedom comes great responsibility (Spiderman plug). Sticking to a schedule, writing out your daily goals, and keeping yourself motivated are crucial to a healthy and effective work life. If you’re someone who thrives under constant supervision, be wary of remote jobs, this may not be for you. Self motivation and discipline are key to success in this arena.

3. Effective communication is a requirement, not a nice to have.

With the subtraction of body language, tone of voice, and physical proximity, the written word, emoticons, and timely responses become crucial. This is why utilizing GIFs, emoticons, and #status updates are important. If you think you’re being redundant, you’re probably doing just the right amount. Never underestimate the importance of emotional intelligence in the virtual world.

Think you can hack it? Intridea is hiring! :) Learn more about our AngularJS Engineer position.

Guerilla UX: UX in the Analog World

2015-04-14T11:35:00Z

As a UX designer, improving the end user experience is my passion. When an interface or interaction seems confusing, I often find myself asking “What would I tell the user if I was there?” And immediately picture myself as a bystander, brainstorming every possible solution.

When you eat and breath this on a daily basis, it can quickly spill into the analog world. Suddenly, you have a heightened awareness of places and things where designers have built with the user in mind. And it’s in those instances, you can almost sense the designer looking over your shoulder, giving you a helping hand.

My first observation of this was the gas pump. We’ve all experienced “gas cap confusion” or the internal debate as to which side that dang cap is on! No matter how long you’ve been driving your car, this situation occurs more often than we’d like to admit. If you know where to look though, there’s a bit of user experience design making life a little easier. For years auto manufacturers have included a tiny arrow next to the gas pump icon indicating which side it's on.

It’s such a simple touch. Just a tiny little arrow. But if you know about it, it can save you a world of frustration when heading to the pump.

Which got me thinking, are there other ways to simplify daily life via user experience design? And so began my pursuit and practice of Guerilla UX.

When we moved into our house, a point of frequent confusion was our garage doors, or more specifically the control panels that opened them. There’s a garage door on the left and another on the right, but with the panels stacked vertically (poor user interface design) it was impossible to remember! With a bit of Guerilla UX though, determining which pad opened which door was quickly resolved. Arrows now clearly indicate the side the control panels open.

Another place with some added UX love is my printer. It’s a common hurdle; which side of the paper will the printer print on? And it’s of special concern when printing on special paper or making labels! Pre-UX, I’d always make a mark at the bottom of a plain sheet of paper and print a test page to avoid wasted time and paper. My Guerilla solution? A simple label with an arrow showing which direction to load the paper and a smiley face to indicate the top as well as what side it will print on. Tada!

These are just a few places I’ve added Guerilla UX to my daily life, but I have a feeling other designers (and non-designers) may use a bit of Guerilla UX to make their lives easier too.

Got some good examples? Tweet them to us with the hashtag #GuerillaUX and we’ll share the best ones!

Tidal: Misses the Boat

2015-04-07T00:00:00Z

With "The ruler’s back” kicking off one of Jay-Z's greatest albums to date and the recent (re)launch of his streaming service Tidal, my hopes of a Jay-Z disruption were extremely high.

With claims to revolutionize streaming and pay artists what they deserve, Tidal depicted the utopian ideal of edgy design, quality, and fairness. I was pumped to check it out, not merely as an H.O.V. fan, but as a UX/UI junkie craving to experience music streaming in a new way. With creds for shaping one of the most popular music genres, you'd think Tidal would bleed the Jay-Z innovation as well. Yet, what I discovered was anything but revolutionary.

The interface is the same grid layout we’ve all come to know (and love) from our other player, cough Spotify. Not that there is a problem with the way big “S” handles their layout, in my opinion, it does some pretty amazing things, especially in regards with how it handles an incredible library of content.

I just expected more with Tidal, especially coming from J-HOVA, someone who’s built his career by straying from the beaten path. I wanted something that would blow my mind, something that made me NEED Tidal, but it just wasn’t there.

There were glimpses of what Tidal could have been, with slick transitions that make sense to a user and don’t remove them from the moment.

There were literally two instances when this level of detail was applied. And the look of the app is super sharp, black on black with pops of neon blue that scream for you to click.

Also, there’s no denying that Tidal has a very trendy look, but it’s the details that make a truly immersive and engaging experience. Unfortunately, with Tidal's design inconsistencies and jarring page transitions, it was difficult to convince myself I needed this new platform for music streaming. And with a price tag of $19.99 for premium membership, Tidal, missed the boat (pun intended) on this user.

Let me clarify though, this is in no way a put down to the team of incredible designers who obviously spent countless nights away from their families. This is merely my take on a, now, very traditional service from someone who has made a name for themselves by rising above, not floating amongst his peers.

What are your thoughts? Would you make the switch from Spotify to Tidal? Let us know.

Learn Thou Editor

2015-03-31T11:35:00Z

When it comes to learning your editor, most of us avoid it like the plague. It’s time consuming, opinions run rampant, and quite frankly, we’ve got better things to do!

Yet this avoidance isn't effective (and we know it). Simple tasks such as performing “find and replace” become much more difficult when we don't understand how our editor operates...

So why do we still refuse to eat our vegetables? For a few reasons:

It’s overwhelming.

Reviewing an editor, like emacs (or vim, or sublime text) is overwhelming. Not only can the editor accomplish many tasks, but there are multiple ways of doing them! For instance, when performing a “find and replace” on a file in emacs, you can use a regular expression (now you have two problems) or a keyboard macro. All these options can quickly lead you down a rabbit hole and wondering (three hours later) “what did I just do with my time?!”

Getting sidetracked by editor holy wars

When asking a co-worker for advice, if that co-worker doesn't use your editor of choice the discussion can devolve into: "Emacs is awful. You should use Vim and do it this way." Then instead of learning your editor, the conversation continues into the merits of one editor versus another, when both could do the job adequately. Avoid this at all costs.

Deadlines

We have work to do. When working on a bugfix or a feature with a tight deadline, you can't afford to spend time learning your editor. But then, not learning your editor makes your text editing less efficient, which makes development work take longer than it should. Soooo...

A Better Approach

Despite all these variables though, learning your editor is worth it. You just have to get strategic. Here’s my suggestion: while doing your everyday work, keep a notepad with an ongoing “need to learn” list for your editor. Then, when you find yourself wanting to perform a particular task (search across project files) and don't know how to do it, you can come back to it later vs. stopping everything to figure it out right then and there.

Then once a week, for thirty minutes, take one item on your list and look up how do it. For the coming week, keep in your mind (or a post-it note on your monitor) how to perform this task in your editor, and use it when necessary. This will help you remember the task and how to do it. Next week, you can cross off another item on your list.

This approach requires a small time commitment each week and avoids going down the rabbit hole of configuring your editor during your normal work day.

AngularJS 2.0: Crazy Like A Fox?

2015-03-24T00:00:00Z

_{This article originally appeared on the Divshot blog. Divshot is a developer-focused platform for deploying modern front-end applications. It was also started with Intridea's support by Michael Bleigh!}

If you follow the front-end world even a little bit, you've probably seen the internet explode over the massively incompatible rewrite that is AngularJS 2.0. Some think the Angular team has lost their marbles. I'm not so sure.

Angular is dominating the story for modern front-end frameworks right now. Even if it's not your personal favorite, you have to admire its meteoric rise. It's a rare case of a library achieving massive adoption from both the startup and enterprise set in a very short timeframe (it took Rails years to get buy-in from bigger businesses). The Angular team is sitting on top of the world, and what do they decide to do? Rewrite the whole thing from scratch.

Are. They. Insane? Rewrites-as-new-versions have horror stories right out in the open! Python 3.0 was released nearly six years ago and still has a puny fraction of code being written for it. Enterprise developers have only just convinced their bosses to let them build with modern web tech, and now they have to sell them on either a massive rewrite of existing code or an 18-month support death clock. The hubris of the Angular team is unmatched since the times of Marie Antoinette!

Except, that's not what's really going on. The Angular team isn't squandering their community goodwill out of sheer capriciousness. Instead they're doing something risky: they're pro-actively disrupting their own product before it's rendered irrelevant by external competition.

But Michael, I hear you thinking, you just talked about how dominant AngularJS is. Shouldn't they be taking steps to reinforce their leading position rather than putting the whole project in jeopardy?

That's certainly an approach they could take, but I believe it would ultimately lead to Angular falling by the wayside two to three years from now.

The Innovator's Dilemma

An oft-referenced issue in the tech world is the Innovator's Dilemma, as described in a 1997 book by Clayton Christensen. Wikipedia summarizes it thusly: "successful companies can put too much emphasis on customers' current needs, and fail to adopt new technology or business models that will meet customers' unstated or future needs...such companies will eventually fall behind."

I'll admit that I hadn't been following the progress of the Angular 2.0 design docs very closely. I had heard with interest about the new persistence layer, but hadn't done much other investigating. Today I spent a bit of time perusing some of the content, and the real purpose of the rewrite started to make sense to me.

AngularJS 2.0 is a concerted effort to make sure that Angular remains relevant in the coming front-end world dominated by Web Components.

Sea Change Is Coming

I've written before about how Web Components are revolutionary. I strongly believe that in a few years they will become the dominant paradigm for front-end development. Web Components are not, however, in direct competition with modern front-end frameworks like Angular, Ember, or React. Instead, they are a new set of foundational technologies that will enable radically different and more powerful ways of building applications in the browser.

How is this related to Angular 2.0? The evidence is plain. As I browse through the design docs, I see at least six that reference Web Components directly or allude to related subjects. The Angular team is taking everything they've learned about building an application framework and building a brand new one for the Web Components world.

This is a brave and risky decision, but one that I think has a greater chance to protect Angular's market leadership than threaten it. There is not (yet) an accepted set of best practices for using Web Components to build applications. Polymer works at a lower level than an application framework; in fact, it's quite likely that application frameworks will emerge that are built on top of Polymer.

If Angular 2.0 arrives on the scene as the first comprehensive application framework for Web Components, and it's also good at that job, it could see massive adoption, and not just from the existing Angular userbase.

What's Next?

There's no doubt that the recent firestorm will tarnish Angular's reputation a bit. Someone who is researching which framework to use today might see the uproar and decide to turn elsewhere. Open source projects are just as vulnerable to brand perception as companies, and I think the Angular team needs to get out in front of it. Firmly establish the basis and need for change while reassuring developers that 1.X users won't be abandoned wholesale. Acknowledge that incompatibility is a massive pain and demonstrate awesome new stuff that makes the pain worth it.

It's an exciting time to be building apps in the browser, but it's also a turbulent one. Angular has done a great job of introducing a huge audience to sophisticated front-end development, but the last couple years are just a warm-up act to the true front-end revolution. Angular 2.0 seems a bit crazy now. Looking at the bigger picture, however, it might just be crazy like a fox.

Update: Two Roads Diverged

Since I finished writing this post, two interesting and relevant bits of content have been published. Tom Dale wrote about The Road To Ember 2.0. The Ember team is taking a gradual, migration-focused approach to integrating new technologies like Web Components, DOM-based templating, and other new tech. They call this "Stability Without Stagnation." Henrik Joretag of Ampersand wrote to Optimize for change. It's the only constant about how they are taking the "lots of little modules" instead of an all-in framework approach.

These are both smart, valid, and potentially wildly successful approaches. The fact that there are different teams of smart people building software to make the front-end better, and that those teams have different and directly conflicting philosophies is fantastic.

Maintaining large, popular open source projects is really damn hard. It's even harder when that project is a framework, because they are so deeply intertwined with users' application code. If you move forward gradually, you risk stagnation. If you move forward in great leaps, you risk leaving behind those who don't have the time and energy to leap with you. Like most things, it's not a question of good and bad, it's a question of risk and reward, of tradeoffs.

It seems we're all cursed to live in interesting times.

Polymer 0.8 Sneak Peek

2015-03-10T00:00:00Z

The next release of Polymer, 0.8, is going to be a doozy. It's the first release on the "heading towards production" track and it's going to have some pretty massive differences from previous versions. So what exactly is new, and what's changing?

Note: This data was gathered primarily from reading the Polymer 0.8 Primer which is very, very extensive. I'm just hitting the highlights. Also note that any of this could change before the final release is cut.

A Tale of Three Polymers

One of the biggest changes in 0.8 is that there is no longer a single Polymer library. Instead, it's been broken into the three "layers" of polymer-micro, polymer-mini, and polymer. Why the change?

Remember, Polymer is really just a layer on top of the Web Components standards. Web Components are meant to be inter-operable with each other regardless of things like which framework was used to build them. Creating lighter-weight versions of Polymer makes it an easier choice for authors of reusable components by being less of an install burden. So which library should you use when?

polymer-micro has only a bare layer of sugar on top of the raw DOM APIs and a few niceties. You don't get any DOM template stamping facilities, so this is really meant for reusable elements with little to no DOM interaction (e.g. core-ajax).
polymer-mini layers some DOM control on top of micro and lets you do template stamping (but not template binding). Also gives you access to <content> and the new lightDOM and localDOM properties.
polymer is the closest thing to 0.5 (but still quite a bit different). It adds on attribute and property observation, template data binding, layout attributes, and more. This is what you're going to want to use if you're building a Polymer application.

Things You Can't Do Anymore

When you first look at 0.8 you may be a bit surprised. There's actually many things from 0.5 that are gone, vanished, kaput. It all has to do with production readiness. Polymer 0.8 is built to be lean, mean, and a foundation for shipping production code. Some of the more expensive (computationally and/or filesize-wise) features have been nixed. Watch the Polymer State of the Union talk for more detail there.

Elements can't inherit from custom elements anymore, only native. It's marked as a todo, but it's unclear if it's a before-0.8-launches todo.
Template binding is substantially less powerful than it was in Polymer 0.5, as is property observation. Everything's more explicit, and more is expected to happen in JS vs declared in templates.
Polymer will no longer ship with a spec-complete Shadow DOM polyfill. This was one of the biggest performance bottlenecks in non-Chrome browsers. The new polyfill implementation will be "Shady DOM" (details TBD).
Property observation does a bit less magic, you'll have to manually debounce some things.

Things That Are Different

In addition to removing some of the heavier features, there are also lots of structural changes to how you build custom elements. Here's a non-comprehensive list:

<polymer-element> is gone. Now you use the Polymer JS function to register your element, and the new dom-module element to specify templates.
You use the is property to declare the element name in a Polymer registration, e.g. Polymer({is: 'my-element'}).
Attribute bindings now work based on dash-case instead of camel-case (i.e. <my-element first-name="{{name}}"> binds to the firstName property. I am super happy about this, camel-case attributes are hideous.
You should now use the lightDOM and localDOM APIs to manipulate element DOM so that they are maintained properly.

Here, Bite Down on This

I'm not going to lie, if you're building stuff with Polymer the transition to 0.8 is going to hurt, bad. There's very little that won't need to be rewritten significantly (if not from scratch). That being said, this is a totally necessary transition.

As Matt McNulty said in his Polymer State of the Union, Polymer started as an experiment, and with 0.8 that experiment is over. It's time for Polymer to transition from a fun future-facing toy that we can dream about into a serious, performance-oriented tool we can use to ship real code.

By focusing on performance and footprint, the Polymer team is laying a practical foundation upon which much can be built. And yes, the changes are pretty drastic, but they're throwing them at us all at once. The plan is for the API to change minimally between 0.8 and 1.0, so (fingers crossed) this will be the biggest rewrite you ever have to do for Polymer.

Lingering Questions

I've been drinking the Web Components Kool-Aid since Polymer was first announced at Google I/O in 2013. The encapsulation and composability of custom elements is revolutionary for web apps. As we start looking at the road to production-ready Web Components, however, I still have a few questions:

How will module loading shake out? With Mozilla backing away from HTML Imports and ES6 gaining popularity, it seems like there's a growing rift in how to do this properly. This is a key issue that needs to be sorted out; you shouldn't need a build step to do basic module loading for a web app.
The DOM is big and unwieldy. Can we incorporate some of the gains of Virtual DOM tech into Polymer and/or the Web Components specs themselves? The concept of "Local DOM" or "Shadow DOM" gives us a clean encapsulation point, maybe soon we can get some of the benefits of React and its kin.
When are Apple and Microsoft going to get fully on board with Web Components? The true promise of Polymer can't be realized until we have native browser support for the standards in all browsers.

Questions aside, I'm excited for Polymer 0.8 and we will continue to champion Web Components here at Divshot. Latest estimates put 0.8 landing sometime in March; I can't wait!

AngularJS Any Loader Module

2015-03-03T00:00:00Z

At one point or another, AngularJS applications will rely on loading data. And when that moment arrives, it's nice to let your users know about it. The most common practice is some variation of a loading indicator. You’ve seen them; the spinning circle of patience, that only disappears when whatever you were waiting for finally arrives - hooray!

Any Loader To the Rescue

Wouldn’t it be great if you could add these loading indicators to your app by dropping a simple directive into your markup? At Intridea we've developed any-loader-ng, a module to easily display a loading indicator anywhere in your app. The module has two highly customizable directives for a stand-alone loading spinner (<any-loader>) and a button with multiple loading state configurations (<loader-button>). Both directives can accept a simple configuration object that determine the loading behavior. We’ve also used Font Awesome as the icon font with the default spinner icon being fa-spinner, but that can be customized.

Examples:

Here we have the <any-loader> directive in its simplest form:

Controller:

var loaderConfig = {
  "isLoading": false
};

Markup:

<any-loader cfg=”loaderConfig”></any-loader>

By changing the controller’s loaderConfig.isLoading value to true, perhaps while you are loading some data over HTTP, it will enable the loading indicator to be displayed. There are other optional properties you can add to the configuration object to further customize the directive. The size property takes a string to change the css font-size of the icon (i.e. ‘3em’) to suit your visual needs. The iconClass property allows you to override the default icon class with whichever you choose. These customizations make the directive versatile enough for almost any app.

This time, let’s take a look at using all the optional configurations for the <loader-button> directive.

Controller:

var buttonConfig = {
  "label": "Load Something",
  "isLoading": false,
  "isSuccess": false,
  "isFail": false,
  "successMsg": "Success!",
  "failMsg": "Failed :("
};

Markup:

<loader-button cfg="buttonConfig"></loader-button>

With this configuration, there are four separate states of the button:

the default state uses the `label` as the button text
the loading state uses the loading indicator as the button text
the successful state uses the `successMsg` as the button text
the failed state uses the `failMsg` as the button text

The button is also disabled while loading and after it finishes (regardless if it succeeds or fails).

Installing the Module

The module can be added to your project through Bower. Simply install the package using this line in your terminal:

bower install any-loader-ng --save-dev

Once downloaded, the module requires AngularJS and Font Awesome to work properly, so be sure to have those downloaded and added to your project. To include the module to your project, just add the <bower directory>/any-loader-ng/dist/any-loader-ng.min.js file. We’ve distributed a non-minified version for development as well.

Adding the module to your AngularJS application is the same as any other module dependency:

angular.module(‘myApp’, [‘anyLoader’]);

Go Load Stuff!

Thanks to Any Loader, there’s one less thing you have to worry about in your next AngularJS project! Check out this demo created to show off all the wonderful ways to use Any Loader.

Let's Kill Semantic HTML

2015-02-12T00:00:00Z

I'm going to say something that (even in my own head) seems downright heretical. It's time to move past rigid separation of presentation and markup in web applications.

Many of us have been building things for the web long enough to remember the dark times, in the long-long-ago. Back when tables were used for layout, and the whole web looked, well, something like this.

As the web matured, we developers realized that six-deep nested tables weren't, perhaps, the best way to build things. And so began the age of the <div>. CSS allowed us to do everything (sort of, with a lot of hacky workarounds) we had done with tables, but now our markup could be gloriously free of style information. Gone were the <font> tags. Use of the style attribute became taboo, a sign of semantic weakness. And it was, if not good, at least better.

Somewhere around this time, however, a second important trend was brewing: the birth of the web application. Web sites that weren't just ways to display one's intense fandom for Doom II, but were ways to actually do things. As it turns out, browsers are quite the distribution mechanism.

Give and Take

True Fact: Square pegs do go in round holes if you hammer hard enough. That's how we used to get rounded corners.

As web applications grew more and more sophisticated, the contortions we applied using CSS to maintain semantics grew ever more bizarre. Floats within floats within relative-positioned negative-margin containers. Triple-nested <div> tags for that perfect sliding door rounded corner tab effect. The poor browsers, created to scroll top-to-bottom through a document's content, were being vigorously abused for the sake of better, more interactive applications.

Fortunately, browser standards change over time. Under the flag of HTML5 we got rounded corners, gradients, background image sizing, new tags like <section> and <header>. We even got stuff we didn't have to think about before, like media queries to make sites work on fast-growing mobile device categories. Our semantics were more semantic than ever, our buttons as glossy and round as we could ever care for them to be.

Building a proper interface or application layout, however, had scarcely gotten easier. Why is that? Because the semantics of HTML don't match those of application interfaces. Paragraphs, sections, articles, and lists are semantics that make sense in the context of a document, not an application.

Quibbling the Semantics of Semantic HTML

The document/application disconnect has given rise to frameworks like Bootstrap that provide much-desired UI widgets and layout constructs for building applications, not documents. You'll often see developers cringe at the inherent "wrongness" of "polluting" markup with Bootstrap classes. I posit that this is a reflexive and inappropriate reaction to what's really taking place.

Bootstrap, Foundation, and other similar projects are doing their best to equip developers with new semantics to describe interfaces. Interfaces are inherently visual; positioning, size, relative placement, and alignment are central semantic considerations for an interface's structure. There is no bright line between content and presentation because the presentation is the content.

Just look at modern JavaScript applications. Oftentimes the "document" content, the bit that was once central to the "semanticity" of a site, is JSON data loaded after the page loads and rendered to the interface using any of a number of client-side technologies. The HTML in these applications describes something fundamentally different from a rich text document.

Semantics are Dead, Long Live Semantics

UI and JavaScript frameworks provide stopgap measures to increase "app semanticity" in HTML, but they still function largely as hacks grafted onto an old, creaking system. Luckily for all of us, native solutions are finally beginning to arrive.

Flexbox solves many (if not most) of the fundamentally difficult aspects of building proper application layouts with HTML and CSS. It is a standard that gives us the power to do, and do it right.

Web Components offer us a real solution to the issue of app vs. content semantics. Namely, they let us define our own. If paragraphs and blockquotes don't suit your semantic requirements, how about user-profile or google-map? By freeing us from a set of predetermined tags, Web Components allow us to construct our own semantic context. They are going to change everything about how we build web applications.

The web is and will continue to be the best content distribution platform in existence. Nothing can rival its reach and simplicity. Now, after an extended awkward phase, the web seems finally ready to fight to ensure its spot as the best app distribution platform as well.

A Taste of the Future

What exactly does interface-semantic HTML look like? We can glimpse one possible future in Polymer, Google's Web Components polyfill and oh-so-much-more. It ships with a collection of layout attributes that allow developers to leverage Flexbox almost effortlessly.

Let's say I want my page to flow with a fixed header, then some content, then a footer at the bottom. Using layout attributes, it looks like this:

<body fullbleed vertical layout>
  <header>My Header content here</header>
  <section flex id="main">My main content</section>
  <footer>
</body>

With no custom CSS and a declarative syntax that reads almost like English, the layout attributes offer simple semantics with a kind of "it just works" magic to them. Memorize a few keywords and you can build complex application layouts just about as fast as you can type.

I don't know whether Polymer's layout attributes are the best way forward. What I do know is that using them feels natural, almost addictive. HTML is remarkable for its ability to be declarative and compositional. Polymer offers one potential solution, but the biggest potential lies in the ability of developers everywhere to strike out in new directions, ignoring the constraints of the past. We're going to make some mistakes, we're going to take things too far; that's how progress is made!

What to Take Away

When building applications (as opposed to authoring documents), the structure of HTML should be judged not on how closely it adheres to semantics of content but to those of interface. Don't sacrifice the future on the altar of semantic purity. The next time that vein in your forehead starts throbbing at some "non-semantic" HTML, ask yourself: what are the true semantics at play?

It's early days for the next HTML revolution. I strongly encourage everyone to start learning, start experimenting, and start questioning the status quo. The best practices of the future haven't been discovered yet. Now's your chance to play a part in writing them. My suggestions:

Play with Web Components. The Polymer site is probably the most comprehensive starting point for practical use today.
Challenge your assumptions. Pretend you aren't scarred by years of battling HTML. What would your HTML look like if you defined the semantics?
Share your results! No one has invented the best way to do just about anything with Web Components yet. The more people there are thinking, doing, and sharing, the faster we'll discover those as a community.

Let's all go forth and define the semantics of a new generation. The web platform, despite being more than 20 years old, is still in its infancy.

Update: Let's NOT Kill Accessibility

As was pointed out in the comments, many users of the web have needs other than just looking at things and clicking on them. This post was aimed at the dogmatism of "pure" markup and was in no way intended to encourage making the web less accessible. Here are a couple great links about keeping accessibility while building Web Components:

Thanks to @stommepoes, @aardrian, and @marcysutton for pointing out the omission and supplying the links! We should remember that putting users first isn't just a good idea, it's the standard!

Any questions, thoughts, ideas? Send 'em our way!