Cloud Four Blog

Technical notes, War stories and anecdotes

Fantastic intro to new srcset and sizes

I normally don’t write a post simply to link to another article, but if you’ve enjoyed the things I’ve written about responsive images, you really should read what Eric Portis wrote about Srcset and Sizes.

Eric describes the logic behind srcset and sizes, how they are part of the new picture proposed standard, and how to use them.

Easy. Peas.

What’s New in hideShowPassword 2

Last June, we released our hideShowPassword plugin for improving the experience of password-entry (particularly on mobile devices). As of this writing, it’s our most-starred and most-forked project on GitHub.

We’ve released a handful of incremental and bug-fix updates since then, but today we’re shipping a full-fledged Version 2 with several noteworthy improvements.

Simpler Usage

The plugin’s “inner toggle” feature tended to steal the show, yet its syntax was verbose:

$(selector).hideShowPassword(true, { innerToggle: true });

We now support a simpler, shorthand syntax for enabling the inner toggle:

$(selector).hideShowPassword(true, true);
 
// enable toggle but hide till input focus:
$(selector).hideShowPassword(true, 'focus');
 
// using shorthand method:
$(selector).showPassword('focus');

Improved Accessibility

My personal favorite feature is the improved accessibility of the inner toggle button. Some changes we made based on real-world feedback:

  • The toggle button element is now a <button> by default (it was previously a <div>).

  • Several accessibility attributes have been added to better communicate the purpose and state of the button to assistive devices.

  • The toggle should now be keyboard-accessible, with space and enter key events attached where necessary.

We understand every project’s different, and you may need to tweak some of these new properties. Luckily, Version 2 also includes…

Overhauled Options

Just about anything we could make an option, we have. There are so many new options, we had to re-organize the options object to accommodate them all. See the full list here.

Built For jQuery and Zepto

Version 1 of hideShowPassword supported Zepto, but we’ve decided to simplify the plugin’s dependencies by only supporting jQuery from here on out. This makes sense to us for a few reasons:

  • Zepto’s data module was required, necessitating a custom build of Zepto to work at all.

  • The plugin’s inner toggle features could be unpredictable given Zepto’s simpler width and height calculation methods.

  • Zepto does not support AMD, and likely never will. We introduced AMD support to hideShowPassword in our first minor update based on developer feedback.

  • While Zepto’s modest file size remains an attractive feature, its performance once loaded may not be so competitive.

Get It Now!

All the aforementioned improvements (plus more fixes and tweaks) are available right now on GitHub (which is also a great place to report issues or request features). Check out the live demo if you remain unconvinced.

If you use the plugin in a project, please drop us a line and let us know. We’d love to hear about it!

SimpleSlideView: Controlling Flow With JavaScript

In July we released SimpleSlideView, a jQuery and Zepto plugin for simple, responsive sliding views (here’s a demo). In the last few months, I’ve noticed an uptick in developers emailing to ask a variation of this question:

How do I change or stop a view transition based on user input?

It’s a great question, and one that may not be immediately apparent from the demo alone.

When using SimpleSlideView, there are two ways to navigate between views. The simplest way is with HTML, which is great for predictable, non-dynamic interactions or prototyping:

<button data-pushview="#result">See Result</button>

The straightforwardness of this technique is a double-edged sword. It’s easy to use, but it’s also kind of static. What if we want to change the destination? Or prevent the transition altogether? For that, we’ll want to use JavaScript instead.

We can remove the data-pushview attribute from the button, but we’ll need some way to select it via JS, so let’s give it an ID:

<button id="result-btn">See Result</button>

And here’s the scripty part:

// Save the simpleSlideView instance to a variable
var slideView = $('#container').simpleSlideView();
// Add a click event handler to the button
$('#result-btn').click(function(){
  // On click, push the view with an ID of 'result'
  slideView.pushView('#result');
});

Right now this probably feels like a step backward. It’s more verbose. But we’ve gained the freedom to define the sliding-view behavior any way we like.

Suppose you only want to transition when certain criteria are met:

if (isValid) {
  slideView.pushView('#thanks');
} else {
  alert('Oops! Something seems off.');
}

Or maybe you’d like the next view to depend on the value of something else:

if (age < 21) {
  slideView.pushView('#soda');
} else {
  slideView.pushView('#beer');
}

Here’s a working example that uses Moment.js and your browser to determine the weekday of a date you provide. The result is populated before the view transitions, and only if Moment.isValid() returns true:

See the Pen Weekday (SimpleSlideView Demo) by Tyler Sticka (@tylersticka) on CodePen.

For more info on what you can do with SimpleSlideView and JavaScript, refer to the documentation on GitHub. If you’re using SimpleSlideView in your own projects, we’d love to hear about it!

Retooling

GitHub introduced a new text editor called Atom last week, and reactions (at least in my Twitter feed) seem divided between fervent desire and snide disregard. For every few people shamelessly begging for invites, you’ll find one or two bemoaning how fickle we all are, how crowded this software category has become, or how our obsession with the “latest and greatest” distracts us from what really matters (what we make).

Some of these emotions are likely the result of the unspoken assumption that everyone in our industry must always know everything (Lyza called this the knowledge burden). But I also believe, regardless of industry, that a natural friction exists between makers and their tools.

We’ve yet to invent a device capable of directly converting our thoughts into physical manifestations. Until we do, tools can only approximate our intent. This means that the distance between idea and execution is often defined by the capability of our tools and our mastery thereof. They tell us what we can and can’t do.

It’s a complicated relationship.

 Some remain faithful to a specific toolset for as long as possible, cultivating an intense and focused knowledge of every feature, quirk and workaround. Peanuts creator Charles Schulz was so fond of Esterbrook & Co.’s Radio Pen No. 914 that he bought all of their remaining stock when they stopped producing it. The pens lasted him through the remainder of the strip’s nearly fifty-year run.

Others transition quickly, abandoning their previous workflow as soon as they feel it may be working against them. English post-punk band The Fall have remained vital and prolific for nearly four decades, in part because of frontman Mark E. Smith’s infamous propensity for changing the band’s lineup with little or no warning.

We’ve yet to discover that magic “one size fits all” process. Until we do, we should encourage the accelerating expansion of available tools while remaining skeptical of any that claim to be everything to everyone. Choice encourages diversity in the types of thought processes our medium supports.

In other words, tools are important. Not for their own sake, but for those they empower to create. Welcome!

PhoneGap makes mobile app development more accessible

Editor’s note: This is a guest post from our friend Dan Moore. He recently wrote a book about PhoneGap’s new command line tools. I asked him to share what it was about these new tools got him so excited that he would do the most insane thing I can think of and become an author. Hope you enjoy. —Jason

Use of applications that run on your phone or tablet (aka apps) is growing rapidly. Building apps typically requires a specialized skill set–developers have to know languages like Objective C and Android Java. In addition, they need to have a design sense as well, because they are building user interfaces. Few developers have this combination of skills, and so those who do can charge for it.

But PhoneGap, a four year old project, now lets developers leverage standard web technologies such as CSS, HTML and JavaScript to build mobile applications. Designers who know CSS and HTML can create fantastic mobile friendly user interfaces (leveraging frameworks like Topcoat and Junior) and developers can focus on functionality and performance.

PhoneGap lab illustration

PhoneGap, and its open source foundation project Cordova, democratize the development of mobile applications.  (PhoneGap is built on top of Cordova the same way Safari is built on WebKit, so there are many similarities between the projects.)

For end users, applications built using PhoneGap are indistinguishable from those built using native technologies.  PhoneGap applications can access the camera, GPS and other device specific functionality. There is even a way (called ‘plugins’) for independent developers can write native code and access it from JavaScript.

PhoneGap Challenges

For most of the past four years, developers using PhoneGap faced a few problems when developing or maintaining PhoneGap applications. Among them:

  • The PhoneGap framework moves fast, typically releasing a new version every month.  Upgrades require understanding exactly what components beyond the standard JavaScript, HTML and CSS had changed.
  • Plugins were not separate from look and feel or business logic.
  • Every plugin had its own set of instructions for installation and/or upgrading.
  •  Supporting multiple device platforms with one set of JavaScript, HTML and CSS was a goal for PhoneGap development, but required either homegrown scripts or manual syncing between directories. Platform feature drift was difficult to avoid.
  • Specific IDEs had to be set up for each supported platform.

All of these problems are tough enough for small applications, but for apps maintained for more than one release, the issues add up quickly.

CLI to the Rescue

Version 2.9 of PhoneGap, released in June of 2013, included a command line interface to manage applications. Instead of plugins being manually installed according to a README, standardized installation procedures are available. There’s a nascent plugin directory so that discovering a needed plugin no longer requires hunting through Google search results.

Instead of having to choose how to sync JavaScript, HTML and CSS, there is one location in a project for platform independent code, and one for platform specific code. Developers can develop outside of an IDE, in the web browser, using the web development technologies they are familiar with. There even is a system for calling scripts at various points of the application’s build cycle, so the CLI can be extended.

Developers still have to install and maintain device specific platform SDKs, but once they’ve done that once, they can add or remove a platform for a given project with a single command.  And if a developer is just doing a quick prototype or can live with the (considerable) constraints, there is PhoneGap Build, a cloud service, which can build PhoneGap applications without requiring platform SDK installation.

With the PhoneGap/Cordova CLI, a developer can code and test a mobile application without running the device specific tools (like an IDE or ant script) even once. Of course, if an IDE makes a developer happier or more productive, they can use one for developing application code as well.

The CLI makes coping with change easier

The breakneck pace of PhoneGap development hasn’t changed, but the cost of upgrading has dramatically decreased. Instead of having to recreate platform environments entirely manually, or (more likely) simply not upgrading, most configuration has been pushed into standardized files. In some cases, upgrading can be as simple as running a few commands.

The command line interface opens up new worlds of automation, and continues PhoneGap’s march to democratize the mobile application development world.


Dan Moore is Director of Technology for 8z Real Estate, a Colorado and California real estate brokerage, and the author of “Developing Cross Platform Mobile Applications with Cordova CLI”