Zoom Slider is a simple content slider with depth-like zoom functionality.
Each slide has a predefined zoom area that will be used to calculate the appropriate scale value for a fullscreen fill. Once the icon for zooming is clicked, the zoom area as well as the page get scaled, creating the illusion that the viewer is approaching the item
In high school, I ran my father’s drop store from 4 p.m. to 7 p.m. during the weekdays. I loved it because I got paid $12 per hour (which was a lot for kid who had no bills to pay) to do my homework since this was the slowest time of the day. Since before […]
Continue reading %How to Deal With Slow Times at Work%
This is the seventh and final post in the series of epic posts by Steven Bradley that focus on design principles. Sometimes it is hard to understand what makes good design, but having some fundamental principles to fallback on helps. Great reading. (smashingmagazine.com)
Use a trusted email service provider to impress your clients with kick ass email marketing. As a Vision6 partner you get instant access to wholesale rates and a free account for your own marketing. Plus get promoted to over 20,000 in the Vision6 community. Sign up for a free reseller account today. (vision6.com)
With all the hype around CSS Modules at the moment, Jon Gold decided to do a little brain dump on his thoughts about how CSS should be written. He focuses on 5 main topics which all have some very solid points. (jon.gd)
Jeff Walker does a good analysis of some of the most popular build tools. The only issue is he didn’t explore the wonderful world of Webpack. (walkercoderanger.com)
The first post in a series about CSS Grid Layout by Emil Björklund. CSS Grid Layout has been gaining a lot of attention of late due to increased browser support and its ability to handle complex layout. I’m sure we will be seeing many more CSS Grid Layout posts in the not too distant future. (thatemil.com)
A great overview by Kaelig Deloumeau-Prigent about Web Components and why they will help us build better component libraries, enabling us to deliver a refined, maintainable and consistent user experience across products. (medium.com)
Lea Verou’s latest book is now available in hard copy. For those that do any CSS and want to take their CSS to the next level this is a must read. (amazon.com)
Chris Ruppel writes about how he diagnosed some performance bottle necks within his site and how he applied the `will-change` property to make the scrolling silky smooth. (fourword.fourkitchens.com)
With the Netflix redesign the front-end team were faced with a few performance issues and this post explains how they attacked one issue in detail. (eng.wealthfront.com)
Do you want to design something that makes developers’ lives better? At Pusher we’re looking for a designer-developer who believes that design can make a meaningful difference and cares about how it is implemented. Join us! (pusher.com)
We’re looking for an extremely talented visual designer to take the aesthetic direction of Campaign Monitor to an entirely new level. This is a career defining opportunity to take a product already known for its ease of use, to one that is equally regarded for its visual beauty. (campaignmonitor.com)
The post Web Design Weekly #193 appeared first on Web Design Weekly.
As UXers we practice in exciting times.
Design is in demand, and the tech sector is at the forefront of business innovation. It is also a time where we have access to a huge number of tools and techniques that enable us to innovate and adapt our practice for a broad range of scenarios.
Usability testing is a cornerstone of UX practice. Perfect for evaluating the designs we create, flexible for collecting a range of information about customers and easy to combine with other techniques. Usability testing is a technique where representative participants undertake tasks on an interface or product. The tasks typically reflect the most common and important activities and participant’s behavior is observed to identify any issues that inhibit task completion.
Usability testing is a super flexible technique that allows for the assessment of a variety of aspects of an interface including the broad product concept, interaction design, visual design, content, labels, calls-to-action, search and information architecture. It is a proven technique for evaluating products, and in some organisations is used as a pre-launch requirement.
But traditional in-person usability testing has some drawbacks and challenges:
One of the ways these downsides can be overcome is the use of unmoderated remote usability test (URUT).
URUT is a technique that evaluates the usability of an interface or product; that is, the ease of use, efficiency and satisfaction customers have with the interface. It is similar to in-person usability testing however participants complete tasks in their own environment without a facilitator present. The tasks are pre-determined and are presented to the participant via an online testing platform.
There are two broad methods for URUT with varying ways for collecting participant behaviour and these are dictated by the technology platforms.
URUT utilising video recordings of participants interacting with interfaces. These studies are more qualitative in nature with participants thinking aloud during the recording to provide insight.
URUT where the behavior is captured via click-stream data and is run more like a survey. These studies are more quantitative in nature because larger sample sizes are practical and the systems automate tracking of user behaviour.
Both methods are designed to evaluate the usability of a product and both have strengths and weaknesses. Video based sessions require more time to identify the findings and lend themselves to smaller samples however by listening to participants and observing their behavior more information can be collected regarding the design. Click stream methods allow for larger sample sizes and tend to be faster to compete due to the automation of data collection.
Note that some tools support both methods; click stream for large samples and video is collected for a subset of the sample to be able to explore specific aspects of the design in more detail. More on the tools below.
Common scenarios where URUT is value include:
URUT tends to be less appropriate for more exploratory style usability testing because it is not possible to change tasks mid stream or ask impromptu questions. Click-stream tools tend to provide lots of data on what is happening however tend to provide less insight on why the behavior is occurring. Video based studies can be frustrating when there is a core questions that you would love to ask but hadn’t planned for. For early stage low fidelity prototypes in-person usability testing tends to be preferable because the facilitator can provide more context for participants regarding the intended functionality of the interface.
Before you start testing: You need to fully understand why the research is being conducted. Like all UX research techniques this comes back to defining the objectives of the study. All good research requires a clear understanding of:
| Research Objectives | Research Questions |
|---|---|
| Evaluate the effectiveness of the booking process | Do participants understand the field labels? |
| Do error messages support participants to progress? |
Exploring these objectives and research questions with stakeholders at the outset will help with designing the study and provide a reference point for subsequent discussions. Spending the time up front to get this right will save time down the track and help ensure a successful study.
In order to run an URUT is important to identify who will complete the study. Ideally the sample would be representative of the product audience. There are a number of options for sourcing participants:
Offering some form of incentive may be required to motivate participants to compete the study such as gift voucher prize. Audiences that are more engaged with the organization tend to require smaller incentives and those that are less engaged a greater incentive.
It is crucial to get the tasks right for URUT. It needs to be very clear to the participants what is required of them. Provide enough detail for the participant to compete the task on their own and try to include any information they would require to complete the task. For example if a task requires credit card details providing fictitious card details will be necessary.
Avoid adding extraneous information in a task, which may confuse participants. Also avoid clues and telling the participant what to do, for example avoid including the wording of a call-to-action in the task, which will give the task away.
And finally, ensure that the interface supports participants to actually complete the task and for them to be aware that they have done so. In a prototype this may require adding specific content. An example task: Imagine you have decided to stay in Cairns for the first week in September. Use this site to reserve accommodation and pay.
It is recommended that survey questions be provided as part of a study.
What are you actually testing and how will the URUT tool and participants access the interface? Consider how you are going to set-up the URUT tool and the prototype or interface being tested. The responsiveness of the interface you are testing can impact participant’s experience of the product. It is important to make sure that the participant doesn’t need any set-up from their end; barriers to people completing the study will reduce the completion rates. Try to ensure that the interface can be accessed from any computer or device the participant may be using.
Testing the study with either a subset of participants or in a preview mode will allow issues with the prototype, technology, tasks or questions to be ironed out. Piloting the study will protect against wasting sample you are paying for or using up a small limited sample.
There are a number of different tools out there and more coming onto the market all the time. It is recommend that before running a study you explore some of the different options out there. Tools that support video recordings of participants include:
Tools that track click stream data include:
A tool like User Zoom collects both video and click-stream data.
While the survey is being conducted it is important to monitor the data and be available for offering help to participants. Monitoring the data will ensure you see everything is working as planned and that you are receiving the data you need to meet your study objectives. Being available via email or phone helps manage the relationship with customers and to provide help where it is required.
Once you have collected your results it is analysis time. To begin with look at some overarching metrics such as overall task completion and customer satisfaction. These can be automatically calculated in tools that measure click-stream like UserZoom. This will provide an overall feel for the effectiveness of the product. For video based tools you will need to watch the sessions and note whether the participants have been able to complete each of the tasks.
With an overall feel for the product look into the individual tasks and identify those that are causing issues. Next you need to find out why. With video based tools, watch video of specific tasks to observe behavior to identify the elements of the interface that are causing the issues. For clickstream services focus in on a combination of the pages visited during the task to identify behavior during the tasks and where the issues have occurred (i.e. which screens). Also view open-ended feedback.
Choose the testing platform after you have identified the objectives of the study. It is crucial to select a tool that is fit for purpose and will support your study objectives. Some platforms do not support specific technologies such as flash and have limitations in the way they measure user behavior. As an example I worked on a study recently that was evaluating a single page app. In order to be able to measure user interaction we needed to get our developers to insert additional code to measure some interaction because the tool tracked the URL which did not change when users navigated a variety of content.
Set clear expectations for participants. Obtaining useful data is dependent on participants understanding what is expected of them. Setting clear expectations up front (during recruitment and at the start of the survey) about what participants are required to do and why the study is being conducted will help ensure success.
Remember that participants won’t receive any assistance during the study. It is crucial to ensure that tasks are clear, user friendly and that help is available. Consider how much assistance is available within the URUT tools for participants during the study.
Avoid bias. While all bias cannot be avoided, it is important to remove as much as possible. Randomise the order of tasks, which means that learning the interface during study will not influence performance on latter tasks. Task wording can also introduce bias. As discussed, pay attention to task wording to ensure that they effectively test the product.
Keep participants engaged: Avoid participants quitting your study. Participants are more likely to complete the study if they feel like their feedback is valuable, if the tasks are interesting and the study isn’t too long.
A large corporate was about to implement a significant change to their site. Multiple rounds of in-person usability testing had been conducted and indicated that the new design would be a success. Due to the scale of the change the organisation wanted a high degree of confidence that the new design would enhance the experience. We ran a study which involved benchmarking the task completion rates, perceived ease of use and advocacy on the live site. We then repeated these on a prototype of the new design. By utilizing larger sample sizes, we had tight confidence intervals on core metrics that provided an accurate picture of the performance of the new design in comparison to the old.
URUT is a technique that can offer quick, inexpensive and robust usability testing. Of particular value can be the ability to use the technique for benchmarking and context-sensitive studies. It is a great tool to have in your bag of research techniques and can be a great compliment to in-person methods. Exploring the different tools on offer and experimenting with the technique is the best way to learn and develop expertise.
Make it clear what is expected of participants, keep your research objectives in mind, and avoid bias. Good luck!!
The post How to Run an Unmoderated Remote Usability Test (URUT) appeared first on UX Mastery .
Creating movement is great way to provide an interesting and interactive experience for your viewers. With modern sites providing a greater deal of interactivity, it’s becoming increasingly expected that even simple websites will offer some level of animation / movement to engage their visitors.
Today I will be outlining a technique that you can adapt to your web projects - triggering animations when scrolling into a pre-defined region. These animations will be created using CSS transforms and CSS transitions. We will also use jQuery to detect when the elements are visible and to add/remove the appropriate classes.
For those who want to see examples of this in action, you can jump straight to the demos.
The main reason we would want to trigger animations on scroll, is so that they activate just as the user scrolls an element into view.
We might want to fade elements in, or provide an interesting transformation and these would only make sense when the user can actually view them.
There are pros and cons to each approach. jQuery (read JavaScript) allows you to animate things that CSS doesn’t (such as the scroll position, or an element’s attributes), whilst CSS animations can be very attractive for developers who prefer putting all of their animation and presentation logic in the CSS layer.
I will be using transformations via CSS, however there are always variables to consider depending on your situation. I would take the following factors into account:
Since our solution will be based on transformations, our browser compatibility will be limited to those that support either 2D transformations or 3D transformations.
All modern browsers will support 3D transforms and several of the older legacy browser such as Internet Explorer 9 and Opera 11.5 will support 2D transforms. Overall support for both desktop and mobile browsers is comprehensive.
jQuery’s animate method works in any (sane) browser, provided you are using the 1.X version of the library. jQuery 2.X removed support for IE8 and below, so only use this if you don’t need to support legacy browsers (lucky you!).
We want fast and smooth animations, especially when it comes to mobile devices. As such its always best to use transitions and transformations where possible.
The examples will use 3D transforms with 2D fall-backs for older browsers. We want to force hardware acceleration for speed, so a 3D transformation is a must (we will be using translate3d along with other functions that cause GPU accelerated rendering).
jQuery’s animate method is considerably slower than a GPU assisted transformation, so we will just be using jQuery for our event handling / calculations, not for our animation itself (as we want them to be as smooth as possible).
We all know that jQuery !== JavaScript, right? Well, it turns out that using vanilla JS for animations might not be such a bad an idea after all. Whilst that is beyond the scope of this tutorial, here are two excellent articles on the subject for those who are interested in finding out more:
Now back to the show …
The overall point of this technique is to look through all of our elements we marked as animatable and then determine if they are currently within the viewport. Let’s step through how we will achieve this:
Scrolling is an expensive business. If you attach an event listener to the scroll event, it will fire many times over whenever a user scrolls the page. As we will be calling our dimension / calculation functions whenever a user scrolls, it is a good idea to store the elements returned by our selectors in variables. This is known as selector caching and avoids us querying the DOM over and over again.
In our script we will be referencing both the window object and the collection of elements we want to animate.
[code language="js"]
//Cache reference to window and animation items
var $animation_elements = $('.animation-element');
var $window = $(window);
[/code]
Notice the dollar sign in front of the variables. This is a convention to indicate that they hold a jQuery object, or collection of objects.
Next, we create our event handler that listens for the scroll event. This will fire when we scroll the page. We pass it a reference to our check_if_in_view function (which we’ll get to in a minute). Every time the scroll event is fired, this function will be executed.
[code language="js"]
$window.on('scroll', check_if_in_view);
[/code]
Continue reading %Creating Scroll-based Animations using jQuery and CSS3%
Augmented reality is a neat concept. We take a view of the world around us and supplement it with images, text, sound and video. Tech companies are starting to explore the possibilities of AR with devices such as the Meta Glasses, Microsoft HoloLens and Magic Leap. These very exciting AR headsets are not quite ready for consumer release yet, so it may be a little while before every household has a pair. However, there is another way of introducing the world to augmented reality using something they may have easier access to - the mobile browser.
I have previously covered other sorts of reality creation and manipulation using JavaScript and Three.js here at SitePoint in my articles on Bringing VR to the Web with Google Cardboard and Three.js and Filtering Reality with JavaScript and Google Cardboard. In this article, I'll show how you can use a JavaScript library called awe.js to create an augmented reality experience on the mobile web. We're going to create a 3D control board that opens on top of a paper marker. We can hook it up to do pretty much anything that can be enabled via a JavaScript HTTP request, so I've set it up to change the color of my LIFX lightbulb using IFTTT.
For this demo, you'll currently need Google Chrome for Mobile. It may potentially work on Firefox for Mobile too, however I found click events didn't trigger for me when I tried it on my HTC One M9. It also works on some desktop browsers (Chrome and Opera worked quite nicely on my Mac) but definitely isn't quite the same experience as a smartphone with touch events. It could be neat on a tablet though.
You'll also need an IFTTT account and a knowledge of how to set up the the Maker Channel with rules that trigger on HTTP requests. If you're new to IFTTT, we previously went over the basics in the article on Connecting LIFX Light Bulbs to the IoT Using IFTTT. For those new to the Maker channel, we've also covered that in Connecting the IoT and Node.js to IFTTT.
Lastly, you'll need to print out a marker onto a piece of paper. The marker we'll be using is this one:
If you'd prefer to get straight into the code and try it out, it is all available on GitHub.
Awe.js is a JavaScript library that uses Three.js, your device's camera and some pretty smart techniques to create augmented reality in the browser. You can download the library and some samples on the awe.js GitHub repo. It provides four different sorts of AR experiences, each with their own example in the repo:
geo_ar - Allows you to place objects at set compass points.grift_ar - Compatible with an Oculus Rift.leap_ar - Integrates with the Leap Motion controller.marker_ar - Allows you to create an experience that is positioned on Augmented Reality markers. This is the one we'll be working with in this demo.Our demo code is over 300 lines long, but a lot of it is repeated code for similar objects. I'd recommend downloading the demo code from the demo's GitHub repo and following along with the explanations provided here. Once you've got an idea of how it all works, try tinkering away and building something of your own.
Everything starts within the load event on our window. The very first thing we include is a variable to track whether our AR control panel (I've called it a "menu" for short here) is open or not. Initially, it is closed.
[code language="js"]
window.addEventListener('load', function() {
var menu_open = false;
// Our code continues here
});
[/code]
Then, we start to use the awe.js library. Everything we do is defined within the window.awe.init() function. We start with some global settings for our AR scene.
[code language="js"]
window.awe.init({
device_type: awe.AUTO_DETECT_DEVICE_TYPE,
settings: {
container_id: 'container',
fps: 30,
default_camera_position: { x:0, y:0, z:0 },
default_lights: [{
id: 'point_light',
type: 'point',
color: 0xFFFFFF
}]
},
[/code]
device_type - All of the examples set this to awe.AUTO_DETECT_DEVICE_TYPE which requests it to detect the device automatically. So far I haven't seen a need to change this.settings - Settings we may actually want to change live within here. These include:
container_id - The ID of the element our whole experience is going to be generated inside.fps - Our desired frames per second (optional).default_camera_position - The default camera position that we will be viewing our scene from (we're starting it at (0,0,0)).default_lights - We can set up an array of different Three.js lights for our scene, giving each an ID, defining the type of light it is and its color. Our demo has only one white Three.js PointLight. There are a range of options available for the type of light, which correspond to different types of Three.js lights - 'area', 'directional', 'hemisphere', 'point' and 'spot'.Once our settings are in place, we then define what to do when awe.js has initialised. Everything is wrapped within a awe.util.require() function which defines what browser capabilities it requires before loading additional JavaScript files we'll need. Be careful to only define the browser capabilities you do need for the demo, as you can unnecessarily prevent your AR app from working in some browsers if you define these incorrectly using capabilities listed in some of their other GitHub examples. For example, in order to have elements positioned based upon compass points you need access to the 'gyro' capability. That won't work on most desktop browsers. We don't need that in this demo, so we exclude it.
[code language="js"]
ready: function() {
awe.util.require([
{
capabilities: ['gum','webgl'],
[/code]
The files that are defined pull in specific functionality for awe.js - lib/awe-standard-dependencies.js, lib/awe-standard.js and lib/awe-standard-window_resized.js each are pretty common, defining the standard bits and pieces for awe.js and handling window resizing. Our demo uses markers, which requires the other two files listed below those.
[code language="js"]
files: [
['lib/awe-standard-dependencies.js', 'lib/awe-standard.js'],
'lib/awe-standard-window_resized.js',
'lib/awe-standard-object_clicked.js',
'lib/awe-jsartoolkit-dependencies.js',
'lib/awe.marker_ar.js'
],
[/code]
Once we've got all of those files successfully loaded, we run the aptly named success() awe.js function. The first function you'll always run when you're ready to start displaying elements sets up the awe.js scene.
[code language="js"]
success: function() {
window.awe.setup_scene();
[/code]
All elements in awe.js are positioned within "Points of Interest" (POI). These are specific points in the scene marked via coordinates that objects can be positioned inside of. You can move POIs around within awe.js as well as elements themselves. We create a single POI which will be placed wherever a specific paper marker is seen. To create a POI, we use the awe.js function of awe.pois.add().
I've given it an ID of 'marker' but you could call it anything you'd like, as long as you are consistent throughout other references to this POI in the code. We set its initial position to be (0,0,10000), which positions it off into the distance a bit until we're ready to use it. We also set it to be invisible until we spot the marker.
[code language="js"]
awe.pois.add({id: 'marker', position: {x: 0, y: 0, z: 10000}, visible: false});
[/code]
Elements we add into our POIs are called "projections" within awe.js. The first projection we add into our scene I've called 'wormhole', as this is a flat black square where our menu items will magically appear out of. Just as the ID of the POI, you could name yours absolutely anything, as long as you keep it consistent with other references to it in your code. We add it into our POI using the function awe.projections.add().
[code language="js"]
awe.projections.add({
id: 'wormhole',
geometry: {shape: 'plane', height: 400, width: 400},
position: {x: 0, y: 0, z: 0},
rotation: {x: 90, z: 45},
material: {
type: 'phong',
color: 0x000000
}
}, {poi_id: 'marker'});
[/code]
There are quite a few options for the objects we can add as projections, so I'll explain them in more detail. Take note - all x, y and z values here for positioning and rotating are in relation to its POI. That POI is defined at the very end by its ID as {poi_id: 'marker'}.
geometry - This refers to the projection's Three.js geometry options. The options required for each type of geometry match those provided in awe.js. For example, SphereGeometry in Three.js would be represented as {shape: 'sphere', radius: 10} in awe.js. One thing to note for those using the latest Three.js, in the currently available version of awe.js, BoxGeometry is still using CubeGeometry. So, to create boxes, we use the format {shape: 'cube', x: 20, y: 30, z: 5} (despite the name, it does not need to be a "cube").position - You can adjust the item's x, y and z axis in relation to its POI.rotation - You can rotate the item by its x, y and z axis in relation to its POI. I rotate the wormhole 90 degrees on its x axis so that it sits flat on the table and 45 degrees by its z axis as I thought that looked more natural (it doesn't quite line up exactly with the marker at all times, so having it on a diagonal makes this less obvious).material - This defines the projection's Three.js material. I've stuck to using 'phong' (MeshPhongMaterial in Three.js), however it looks like 'lambert', 'shader', 'sprite' and 'sprite_canvas' are also potentially available as options. We can also define its color in hex.texture - This is not used in the demo but I wanted to include it in this article for completeness. To define a texture, you can include texture: {path: 'yourtexturefilename.png'}.In the demo, I add seven different boxes/cubes to the scene, each one is 30 pixels high and placed 31 pixels lower on the y axis so that it is originally hidden by the wormhole. They're all slightly different widths to make them look a bit like a lightbulb.
Continue reading %Augmented Reality in the Browser with Awe.js%