IMGRID – jQuery Image Selection Plugin

IMGRID is a jQuery plugin to select images from grid layouts. It's responsive and has nice layout powered with css.

by via jQuery-Plugins.net RSS Feed

Processing Payments with Gravity Forms

This tutorial will outline how to use the Gravity Forms plugin combined with the Gravity Forms - PayPal Payments Standard Add-On plugin to create custom forms that handle payments in your WordPress website.

We will briefly look at how Gravity Forms works, and how using its additional payment add-on can let you take payments and capture information at the same time. We will not be focusing on the design of the forms or how feature rich they are. What I intend to showcase is how to use this plugin to create quick and simple forms to capture data for manipulation (leaving the plugin to do the heavy lifting of payment processing).

Continue reading %Processing Payments with Gravity Forms%

by Simon Codrington via SitePoint

Choosing Your Usability Tests and Participants

In my last article, we talked about ways to really nail down your usability goals before you even think about testing.

Once your goals are clear, you’re ready to hone your test planning to meet those specific goals. There are many tests to choose from, and many types of people to recruit, so narrowing your focus really helps get you closer to the result you're looking for.

Depending on your hypothesis and what you want to learn, sometimes your usability test might not even require testing the actual product.

Source: Usability Testing

Let’s take a look at the different categories of usability tests, how to find the appropriate testing audience, and how to make it digestible with a simple usability plan.

Types of Test

Deciding which style of test to administer is a pivotal decision in the entire process of usability testing, so don’t take it lightly. On the bright side, the more concrete your usability goals are, the more smoothly the selection process will go.

But no matter what type of test you choose, you should always start with a pilot test. Many people like to gloss over this, but sacrificing a little extra time for a pilot test almost always pays off.

What's a Pilot Test?

"A test!? No-one mentioned a test to me "

Photo: The Library of Congress

Don't worry, you won't need make friends with aviators.

Pilot testing is a test run of your greater user test. In A Practical Guide to Usability Testing, Joseph S. Dumas and Janice C. Redish call pilot tests a "dress rehearsal for the usability test to follow."

You will conduct the test and collect the data in the same way you would a real test, but the difference is that you won’t analyze or include this data. You are, quite literally, testing your test.

This may seem like a waste of time — and you will likely be tempted to just jump head-long into the actual tests — but pilot tests are highly recommended. This is because in most cases, something WILL go wrong with your first test. Whether it is technical problems, human error, or a situational occurrence, it’s rare that a first test session goes well – or even adequately.

However, the idea is that these tests should be as scientific and precise as possible. If you want the most reliable data, run a pilot test or two until you feel you understand all the variables thoroughly, and have ironed out all the kinks.

The Types of Tests

I've written a Usability Testing Guide, that delves more deeply into the specifics of each type of user testing method if you're interested. But for this article, we’ll give you an overview so you know what the landscape looks like.

Source: Nielsen Norman Group

Christian Rohrer, McAfee's Chief Design Officer, explains in an article for the Nielsen Norman Group the distinctions between the types of tests. While Christian uses a complex three-dimensional framework to explain the their differences, for simplicity’s sake we’re going to focus on his division based on how the product is used.

1. Scripted use of the product : These tests focus on specific usage aspects. The degree of scripting varies, with more scripting generating more controlled data.


2. Decontextualized use of the product : Tests that don’t use the product — at least in the actual testing phase — are designed for broader understanding of topics like UX or generating ideas.


3. Natural (and near-natural) use of the product : These tests seek to understand common usage behaviors and trends with the product, prioritizing real user data at the cost of control. This tests fundamental assumptions of how a product is being used.


4. Hybrid : Hybrid tests are creative and non-traditional tests. Geared towards understanding the users’ mentality, these tests vary in what they can accomplish.

Continue reading %Choosing Your Usability Tests and Participants%

by Jerry Cao via SitePoint

Holubar

One Pager promoting an American outdoor clothing brand called 'Holubar'. Talk about an impressive "splash page" that creates real depth as you fly through the clouds towards the mountains. I've noticed the overall responsive design doesn't agree with all resolutions but it's almost there. Some good product imagery in the long Collection section and good to know they are using Lazy Load.

by Rob Hope via One Page Love

Listen to This

Simple but clear launching soon page for upcoming iOS app 'Listen to This' that streams the Top 20 new music posts on the /ListenToThis SubReddit. Really like how the device changes angle on smaller screens.

by Rob Hope via One Page Love

Bouncy Navigation

Bouncy Navigation is a full-screen navigation, with floating menu items. CSS animations and jQuery used to animate navigation items, and let them bounce in and out the screen.

by via jQuery-Plugins.net RSS Feed

SassDoc 2 – Shiny Streamy Octopus is Out!

A few months ago, I announced the first draft of SassDoc, a documentation tool for Sass. What a long road it has come since then. A couple of days a back, we finally released the second major version of SassDoc, entitled Shiny Streamy Octopus. We have been working on version 2 for months and spent a few weeks in beta, letting talented people test our product only to discover it was good enough to be released. Yay!

There are two reasons behind this second version of SassDoc: the first one was to clean the code base. I wrote the first draft of SassDoc mid-2014, and we've been working on some code of mine until then. While the code was not bad in itself, it was certainly not very scalable so we needed a much more robust base for the future. Fortunately, Valérian, Fabrice and Pascal are three very talented JavaScript developers who turned my old crappy code into a magnificent beast.

The second reason to push SassDoc v2, and the most important one, is to set up a rock solid base for us to build new features. In that way, this version does not bring many new features. It mostly consists of refactoring the whole code base, fixing bugs, improving APIs, deprecating obsolete features and all that crap that you can only do on major releases because of API breaks.

So what if I gave you a quick tour as well as some hints on how to upgrade from SassDoc v1 to Shiny Streamy Octopus?

New branding

SassDoc started as an experiment. At the very beginning, it was a playground for me to try Node.js. Soon enough, it was not an experiment anymore and actual people were using it on actual projects, such as the folks at ThoughtBot for Neat and Bourbon, as well as the front-end teams at The Guardian and Financial Times.

So we decided to give branding some love for this new version. I redesigned the whole site to have beautiful docs. We had Reda Lemeden design a logo for us, and Alix Lucas create an illustration to give SassDoc some visual strength.

That being said, we are well aware that not everybody will like the new branding. That's fair enough. The site contains nothing but documentation, and the default theme can be customized. If you really don't like the default theme, we have set everything up so you can build your own theme in a couple of minutes.

Now, if you feel like you can improve the default theme, we would gladly merge any thorough pull request so feel free to go nuts and suggest us any change!

API breaks

Let's start with the real thing™: API breaks. Surprisingly enough, there are not as many major API changes as I first thought it would be. Depending on your project, you might have very little to nothing to change in your Sass files to transition to the new version.

C-style no more

I think the biggest change we made for the end user (a.k.a you) at this point was to deprecate C-style comments altogether. You know how I use to sell SassDoc by saying both C-style comments (/** ... */) and inline comments (///) were supported? Well this is no longer true. We decided that providing two ways to write docs was confusing and did not help much at the end of the day. Also, library writers using C-style comments would pollute users' code with massive comment blocks, which is really not that cool.

To help moving from C-style to inline comments, our own Valérian wrote a little script. However pay attention! This is a raw find and replace that cannot be 100% bullet proof (actually this script cannot successfully convert file-level comments from C-style to inline). Be sure to carefully review your code to make sure everything is right.

For GNU sed:

Continue reading %SassDoc 2 – Shiny Streamy Octopus is Out!%

by Hugo Giraudel via SitePoint