Setting up JavaScript-based functionality to work across multiple devices can be tricky. When is the right time to load which script? Do your media queries matches tests, your geolocation popups tests and your viewport orientation tests provide the best possible results for your website? ConditionerJS will help you combine all of this contextual information to pinpoint the right moment to load the functionality you need.

Before we jump into the ConditionerJS demo, let’s quickly take a look at the Web and how it’s changing, because it’s this change that drove the development of ConditionerJS in the first place. In the meantime, think of it as a shampoo but also as an orchestra conductor; instead of giving cues to musicians, ConditionerJS tells your JavaScript when to act up and when to tune down a bit.

As you can clearly see, applying conditioner to guinea pigs results in very smooth fur. Take a moment and imagine what this could mean for your codebase.

The Origin Of ConditionerJS

You know, obviously, that the way we access the Web has changed a lot in the last couple of years. We no longer rely solely on our desktop computers to navigate the Web. Rather, we use a wide and quickly growing array of devices to get our daily dose of information. With the device landscape going all fuzzy, the time of building fixed width desktop sites has definitely come to an end. The fixed canvas is breaking apart around us and needs to be replaced with something flexible — maybe even something organic.

What’s a Web Developer to Do?

Interestingly enough, most of the time, our content already is flexible. The styles, visuals and interaction patterns classically are rigid and are what create challenging to downright impossible situations. Turns out HTML (the contents container) has always been perfectly suited for a broad device landscape; the way we present it is what’s causing us headaches.

We should be striving to present our content, cross-device, in the best possible way. But let’s be honest, this “best possible way” is not three-width based static views, one for each familiar device group. That’s just a knee-jerk reaction, where we try to hang on to our old habits.

The device landscape is too broad and is changing too fast to be captured in groups. Right this moment people are making phone calls holding tablets to their heads while others are playing Grand Theft Auto on their phones until their fingers bleed. There’s phones that are tablets and tablets that are phones, there’s no way to determine where a phone ends a tablet starts and what device might fall in between, so let’s not even try.

Grouping devices is like grouping guinea pigs; while it’s certainly possible, eventually you will run into trouble.

To determine the perfect presentation and interaction patterns for each device, we need more granularity than device groups can give us. We can achieve a sufficient level of detail by looking at contextual information and measuring how it changes over time.

Context On The Web

The Free Dictionary defines “context” as follows:

“The circumstances in which an event occurs; a setting.”

The user’s context contains information about the environment in which that user is interacting with your functionality. Unlike feature detection, context is not static. You could be rotating your device right now, which would change the context in which you’re reading this article.

Measuring context is not only about testing hardware features and changes (such as viewport size and connection speed). Context can (and is) also influenced by the user’s actions. For instance, by now you’ve scrolled down this article a bit and might have moved your mouse a few pixels. This tells us something about the way you are interacting with the page. Collecting and combining all of this information will create a detailed picture of the context in which you’re currently reading this content.

Correctly measuring and responding to changes in context will enable us to present the right content in the right way at the right moment.

Note: If you’re interested in a more detailed analysis of context, I advise you to read Designing With Context by Cennydd Bowles.

Where And How To Measure Changes In Context

Measuring changes in context can easily be done by adding various tests to your JavaScript modules. You could, for example, listen to the resize and scroll events on the window or, a bit more advanced, watch for media query changes.

Let’s set up a small Google Maps module together. Because the map will feature urban areas and contain a lot of information, it should render only on viewports wider than 700 pixels. On smaller screens, we’ll show a link to Google Maps. We’ll write a bit of code to measure the window’s width to determine whether the window is wide enough to activate the map; if not, then no map. Perfect! What’s for dinner?

Don’t order that pizza just yet!

Your client has just called and would like to duplicate the map on another page. On this page, the map will show a less crowded area of the planet and so could still be rendered on viewports narrower than 700 pixels.

You could add another test to the map module, perhaps basing your measurement of width on some className? But what happens if a third condition is introduced, and a fourth. No pizza for you any time soon.

Clearly, measuring the available screen space is not this module’s main concern; the module should instead mostly be blowing the user’s mind with fantastic interaction patterns and dazzling maps.

This is where Conditioner comes into play. ConditionerJS will keep an eye on context-related parameters (such as window width) so that you can keep all of those measurements out of your modules. Specify the environment-related conditions for your module, and Conditioner will load your module once these conditions have been met. This separation of concerns will make your modules more flexible, reusable and maintainable — all favorable characteristics of code.

Setting Up A Conditioner Module

We’ll start with an HTML snippet to illustrate how a typical module would be loaded using Conditioner. Next, we’ll look at what’s happening under the hood.

    <a href="http://maps.google.com/?ll=51.741,3.822"
       data-module="ui/Map"
       data-conditions="media:{(min-width:30em)} and element:{seen}"> … </a>
    

Codepen Example #1

We’re binding our map module using data attributes instead of classes, which makes it easier to spot where each module will be loaded. Also, binding functionality becomes a breeze. In the previous example, the map would load only if the media query (min-width:30em) is matched and the anchor tag has been seen by the user. Fantastic! How does this black magic work? Time to pop open the hood.

See the Pen ConditionerJS – Binding and Loading a Map Module by Rik Schennink (@rikschennink) on CodePen.

A Rundown of Conditioner’s Inner Workings

The following is a rundown of what happens when the DOM has finished loading. Don’t worry — it ain’t rocket surgery.

1. Conditioner first queries the DOM for nodes that have the data-module attribute. A simple querySelectorAll does the trick.
2. For each match, it tests whether the conditions set in the data-conditions attribute have been met. In the case of our map, it will test whether the media query has been matched and whether the element has scrolled into view (i.e. is seen by the user). Actually, this part could be considered rocket surgery.
3. If the conditions are met, then Conditioner will fetch the referenced module using RequireJS; that would be the ui/Map module. We use RequireJS because writing our own module loader would be madness — I’ve tried.
4. Once the module has loaded, Conditioner initializes the module at the given location in the DOM. Depending on the type of module, Conditioner will call the constructor or a predefined load method.
5. Presto! Your module takes it from there and starts up its map routine thingies.

After the initial page setup has been done, Conditioner does not stop measuring conditions. If they don’t match at first but are matched later on, perhaps the user decides to resize the window, Conditioner will still load the module. Also, if conditions suddenly become unsuitable the module will automatically be unloaded. This dynamic loading and unloading of modules will turn your static Web page into a living, growing, adaptable organism.

Available Tests And How To Use These In Expressions

Conditioner comes with basic set of tests that are all modules in themselves.

• “media” query and supported
• “element” min-width, max-width and seen
• “window” min-width and max-width
• “pointer” available

You could also write your own tests, doing all sorts of interesting stuff. For example, you could use this cookie consent test to load certain functionality only if the user has allowed you to write cookies. Also, what about unloading hefty modules if the battery falls below a certain level. Both possible. You could combine all of these tests in Conditioner’s expression language. You’ve seen this in the map tests, where we combined the seen test with the media test.

    media:{(min-width:30em)} and element:{seen}
    

Combine parenthesis with the logical operators and, or and not to quickly create complex but still human-readable conditions.

Passing Configuration Options To Your Modules

To make your modules more flexible and suitable for different projects, allow for the configuration of specific parts of your modules — think of an API key for your Google Maps service, or stuff like button labels and URLs.

Configuring guinea pig facial expression using configuration objects.

Conditioner gives you two ways to pass configuration options to your modules: page- and node-level options. On initialization of your module, it will automatically merge these two option levels and pass the resulting configuration to your module.

Setting Default Module Options

Defining a base options property on your module and setting the default options object are a good start, as in the following example. This way, some sort of default configuration is always available.

    // Map module (based on AMD module pattern)
    define(function(){
    
        // constructor
        // element: the node that the module is attached to
        // options: the merged options object
        var exports = function Map(element,options) {
    
        }
    
        // default options
        exports.options = {
            zoom:5,
            key:null
        }
    
        return exports;
    });
    

By default, the map is set to zoom level 5 and has no API key. An API key is not something you’d want as a default setting because it’s kinda personal.

Defining Page-Wide Module Options

Page-level options are useful for overriding options for all modules on a page. This is useful for something like locale-related settings. You could define page-level options using the setOptions method that is available on the conditioner object, or you could pass them directly to the init method.

    // Set default module options
    conditioner.setOptions({
        modules:{
            'ui/Map':{
                options:{
                    zoom:10,
                    key:'012345ABCDEF'
                }
            }
        }
    });
    
    // Initialize Conditioner
    conditioner.init();
    

In this case, we’ve set a default API key and increased the default zoom level to 10 for all maps on the page.

Overriding Options for a Particular Node

To alter options for one particular node on the page, use node-level options.

    <a href="http://maps.google.com/?ll=51.741,3.822"
       data-module="ui/Map"
       data-options='{"zoom":15}'> … </a>
    

Codepen Example #2

For this single map, the zoom level will end up as 15. The API key will remain 012345ABCDEF because that’s what we set it to in the page-level options.

See the Pen ConditionerJS – Loading the Map Module and Passing Options by Rik Schennink (@rikschennink) on CodePen.

Note that the options are in JSON string format; therefore, the double quotes on the data-options attribute have been replaced by single quotes. Of course, you could also use double quotes and escape the double quotes in the JSON string.

Optimizing Your Build To Maximize Performance

As we discussed earlier, Conditioner relies on RequireJS to load modules. With your modules carefully divided into various JavaScript files, one file per module, Conditioner can now load each of your modules separately. This means that your modules will be sent over the line and parsed only once they’re required to be shown to the user.

To maximize performance (and minimize HTTP requests), merge core modules together into one package using the RequireJS Optimizer. The resulting minimized core package can then be dynamically enhanced with modules based on the state of the user’s active context.

Carefully balance what is contained in the core package and what’s loaded dynamically. Most of the time, you won’t want to include the more exotic modules or the very context-specific modules in your core package.

Try to keep your request count to a minimum — your users are known to be impatient.

Keep in mind that the more modules you activate on page load, the greater the impact on the CPU and the longer the page will take to appear. On the other hand, loading scripts conditionally will increase the CPU load needed to measure context and will add additional requests; also, this could affect page-redrawing cycles later on. There’s no silver bullet here; you’ll have to determine the best approach for each website.

The Future Of Conditioner

A lot more functionality is contained in the library than we’ve discussed so far. Going into detail would require more in-depth code samples, but because the API is still changing, the samples would not stay up to date for long. Therefore, the focus of this article has been on the concept of the framework and its basic implementation.

I’m looking for people to critically comment on the concept, to test Conditioner‘s performance and, of course, to contribute, so that we can build something together that will take the Web further!

(al, ml, il)

© Rik Schennink for Smashing Magazine, 2014.

We have capabilities in our browsers that we wouldn’t have dreamt of 5 or 10 years ago. Entire 3D game worlds can run in the browser and interactive websites can be more immersive experiences.

With a certain virtual reality company being purchased by a certain social media company, now is the perfect time to start working with 3D. Amazingly, we can now create 3D with pure JavaScript, including meshes and materials.

Of course, even though it’s possible, it does require a huge amount of code, and that’s where Three.js comes in, allowing us to build 3D environments simply and with less code.

Browser compatibility

Unfortunately, because it’s new, 3D isn’t supported by all browsers. We’re currently restricted to Chrome, Safari and Firefox.

As time goes by, support on IE will improve, but for now you’ll need a fallback for Microsoft devotees.

Getting started

The first thing we need to do is head over to the three.js website and download the latest version of the library.

Next, reference it in the head of your document like you would any other JavaScript file, and we’re ready to go.

Creating our first scene

The first thing we need to do, to render anything with three.js is to create a scene, a camera, and a renderer. Starting with a scene:

var scene = new THREE.Scene();

Next, we need a camera. Think of this as the point of view that the user is looking from. Three.js actually has a lot of options here, but for simplicity’s sake we’re going to use a perspective camera:

var camera = new THREE.PerspectiveCamera(100, window.innerWidth / window.innerHeight, 0.1, 1000);

This method takes four parameters: the first is the field of view, the second is the aspect ratio (I’d recommend always basing this on the user’s viewport), the near clipping plane, and lastly the far clipping plane. These last two parameters determine the limits of rendering, so that objects that are too close or too far away aren’t drawn, which would waste resources.

Next up, we need to set up the WebGL Renderer:

var renderer = new THREE.WebGLRenderer(); renderer.setSize( window.innerWidth, window.innerHeight ); document.body.appendChild( renderer.domElement );

As you can see, the first thing here is to create an instance of the renderer, then set its size to the user’s viewport, finally we add it to the page to create a blank canvas for us to work with.

Adding some objects

So far, all we’ve done is set up the stage, now we’ve going to create our first 3D object.

For this tutorial it’s going to be a simple cylinder:

var geometry = new THREE.CylinderGeometry( 5, 5, 20, 32 );

This method also takes 4 parameters: the first is the radius of the top of the cylinder, the second is the radius of the bottom of the cylinder, the third is the height, the last is the number of height segments.

We’ve set up the mathematics of the object, now we need to wrap it in a material so that it actually looks like something on screen:

var material = new THREE.MeshBasicMaterial( { color: 0x0000ff, wireframe: true} );

This code adds a simple material for the object, in this case a blue color. I’ve set wireframe to true because it will show the object more clearly once we get to animating it.

Finally, we need to add our cylinder to our scene, like so:

var cylinder = new THREE.Mesh( geometry, material ); scene.add( cylinder );

The last thing to do before we render the scene is to set the camera position:

camera.position.z = 20;

As you can see, the JavaScript involved is extremely simple, that’s because Three.js is dealing with all the complicated stuff, so we don’t have to.

Rendering the scene

If you test the file in a browser now you’ll see that nothing is happening. That’s because we haven’t told the scene to render. To render the scene we need the following code:

function render() { requestAnimationFrame(render); renderer.render(scene, camera); } render();

If you now take a look at the file in your browser you’ll see it does indeed render a cylinder, but it’s not very exciting.

To really enhance the value of 3D you need to start animating, which we can do with a couple of small changes to our render function:

function render() { requestAnimationFrame(render); cylinder.rotation.z += 0.01; cylinder.rotation.y += 0.1; renderer.render(scene, camera); } render();

If you test in your browser now you’ll see a properly animating 3D cylinder.

Conclusion

If you want to see a demo and play around with the code you can do so here.

As you can see, creating this (admittedly very simple) scene took less than two dozen lines of code, and there’s very little math involved.

If you check out the examples on the three.js website you’ll see some incredible work that has been done.

This amazing library for JavaScript has really lowered the entry-level for coding 3D to the point that anyone who can write basic JavaScript can get involved.

Featured image/thumbnail, 3D image via Shutterstock.

Over 600 Secrets, Tips and Tricks for Marketers – only $8!

Update:

Given recent IT security threats generally, DoIT has decided to force the password change to May 23, 2014, the day after Undergraduate Commencement. Thank you in advance for your patience and understanding. 

--------------------------------------------

In an effort to improve campus security and better protect user information, DoIT is requiring that everyone with a UMBC account must change his or her password by June 9, 2014, unless this has already been done this calendar year. This will apply to all myUMBC account holders -- students, faculty, staff and alumni. We know people hate changing their account passwords, but with the rise of emails targeting people to share their account and password, called phishing, we feel it is necessary for security.

As part of this effort, everyone will also be required to provide an alternate email address and create account security questions. Once in place, all users will then be able to reset their password through a self-service page. We have had these account security questions in place for the last two years for students and the program has been very successful in reducing the number of time-consuming, manual password resets performed by our Technolgy Support Center (TSC). We expect that by expanding self-service password resets to all account holders, everyone will benefit.

A notice will appear to all faculty and staff when they login on Wednesday, April 23, informing them they need to change their password and establish their security questions, if they have not done so already in 2014. While the final date for password changes is June 9th, DoIT especially recommends that faculty make this change before they leave for the summer. We will also be sending out regular reminders.

To create your own security questions, visit the following Frequently Asked Question (FAQ):

How do I create my security questions to reset a forgotten password?

If you have any questions or need help, please submit an RT Ticket or contact the TSC at 410.455.3838.

The ALM Forum is being held in Seattle, a software development conference.

In his latest column for The Baltimore Sun, Political Science Professor Thomas Schaller writes about Maryland Governor Martin O’Malley’s political future and possible presidential bid in 2016. He argues that an O’Malley presidential campaign could benefit former Secretary of State Hillary Clinton should she decide to run.

“What possible benefit is there for Mr. O’Malley to play the role of primary sparring partner? That’s pretty obvious: the vice presidential slot on the Clinton ticket. He is ideally suited for that role, too,” Schaller writes.

He notes if chosen to be a vice presidential candidate, O’Malley would help balance the ticket and would receive support based on his record as governor.

“Progressives will also be cheered by Mr. O’Malley’s successful efforts to move Maryland leftward on issues ranging from gay marriage to college tuition to the death penalty.

To read the full column titled, “Your move, governor,” click here.

UMBC red-shirt freshman goalkeeper Connor Gordon has been named America East Conference Men’s Lacrosse Rookie of the Week for games ending March 29, the league office announced on March 31.

Gordon fell one save shy of his season high, making 15 stops against Stony Brook as the Retrievers prevailed, 12-11, in overtime.

The Retriever netminder made a one-on-one save with his team two men down midway through overtime, setting up Pat Young’s game-winning goal with 9.6 seconds to play in extra time. He has recorded more saves than goals allowed in eight of his nine starts for UMBC (5-4, 1-0 America East) this season.

Gordon is averaging 12.33 saves per game, good for sixth place in the nation through games of March 30. His save percentage is an outstanding 56.3 percent, which is 14th-best in the country.