justlazy.js lightweight javascript plugin to lazy load responsive images. Most of the existing javascript plugins using extensive dependencies or supporting just the img-tag without responsive parts. This plugin is supposed to be an alternative.
The following is a short extract from our book, Jump Start Adobe XD, written by Daniel Schwarz, a highly practical tutorial on this fantastic prototyping tool. SitePoint Premium members get access with their membership, or you can buy a copy in stores worldwide.
Let's start by linking the welcome screen to the location filter screen, effectively demonstrating a user flow where the user searches for a type of cuisine, and is then asked to specify where they’d like to eat in the location filter screen. Click on the right arrow icon (inside the input field on the welcome screen), where a blue arrow-tab will appear alongside it.
Drag and drop this blue tab into the location filter screen. A user flow will have been created, and a small modal will appear where you can specify transition settings for this user flow – that is, how the screen will transition into the next one (the type of animation effect, the duration of that animation, etc).
Later on (when we learn how to preview/test our prototypes), we’ll be able to literally click on this icon and be taken to the next screen, as if we were using a real app — this is how we (and our developers, and maybe even our clients) use the prototype workspace to test our concept before committing to it.
Next, we’ll specify the transition settings for this user flow.
Animation comes with its own set of UX challenges. A slow transition can make the user feel like your app is taking too long, whereas a transition that’s too fast can leave the user wondering what even happened. And then there’s the style of the transition itself. You don’t need to do a fade-flip-slide combo to wow the user, a subtle motion is enough to illustrate the result of the user interaction. Let's explore some of the transitions and transition settings that we can use in Adobe XD.
For further reading on easings (notably, the different types of easings and their effect on user experience), check out my article on micro-interactions and easings on SitePoint.
Because we linked the welcome screen to the set location screen, the Target setting has already been defined. Slide Left is a suitable option for the Transition setting because it creates motion (the destination screen slides in from the right, implying that it was the next screen in a series of screens — this is the default setting on iOS and some areas of Android).
Ease-out is a suitable easing for this user flow because it forces the animation to be faster at the beginning, creating a seemingly swift transition that doesn’t delay the user too much, then gracefully slows down so the user has a little extra time to understand what’s happened. In most cases, the default Duration setting of 0.4 seconds is more than optimal.
Let's roll with these settings.
From the Set Location screen, create a user flow back to the Welcome Screen. Select Previous Artboard as the Target, which will automatically reverse the transition last used. For example, if you used Slide Left to enter the screen, Slide Right will be used as you return to the previous screen.
Continue reading %How to Prototype Interactions with Adobe XD%
The following is a short extract from our book, Designing UX: Prototyping, written by Dan Goodwin and Ben Coleman. It's the ultimate guide to prototyping. SitePoint Premium members get access with their membership, or you can buy a copy in stores worldwide.
In simple terms, what we might consider creating a prototype for are the kinds of things that we might we otherwise use sketches and wireframes to explore and design.
We'll now review some of the items for which prototypes are particularly helpful in the design of a website.
Presenting a site’s structure as a sitemap diagram to the project team and stakeholders is often ineffective. It's even harder to user-test structural elements with such a diagram. At a more granular level, we have the same problem testing and presenting other aspects of information architecture including structure, behavior and labelling in navigation, or taxonomies (such as the categories users can employ to segment and query products in an online shop).
It's possible to build an interactive prototype and populate it with real structural elements (for example, primary and secondary page navigation, product categories). Then we can test these structures: the page hierarchy, the behavior of the navigation, and the labels that we're proposing with real users given real tasks to perform. We can present our information architecture to stakeholders in an exciting, tangible way that they can visualize and explore.
This lends itself particularly well to the loading of real content for prototyping then being used for production. We can start at a low level of fidelity by loading the structure of a website into a content management system (CMS) database for a prototype. Then we can increase fidelity by adding placeholder content, then further still by adding in real content. This content can then potentially be used in a production implementation. We'll talk about this in detail in Chapter 7.
We can use a prototype to design, test, and communicate the overall layout and hierarchy of elements that make up a page. This is the kind of design where we’d traditionally use wireframes.
Take the example of a site presenting a range of vacuum cleaners. We might have a list of all cleaners grouped or categorized in a certain way; for example, a page for each individual cleaner showing specifications, options, and user reviews. We have to decide what content to present in the listing and what to display on a single cleaner page, as well as how to lay them out.
We can use insights from user research to help us, such as the tasks different types of users are trying to achieve, what information is needed to solve those tasks, and what’s considered important / less important. From there we can come up with a proposed layout for the listing and for the single page. Then we can implement that proposal in a prototype, ideally using some real content.
A prototype enables us to present the proposal to stakeholders and to test it with real users. Over the lifetime of our prototype, we can add, remove, and change content, as well as alter the layouts we're proposing. We can test small changes or radical alternatives to the layout. If our prototype’s implementation has a good separation of content and presentation, the process of changing the layout while maintaining the same base content is easy. That means we can test more layouts, more quickly and more easily.
All websites have at least some interactive elements (such as a link), but many have interactive elements that are more involved and complex. This requires significant amounts of user interface design.
Consider the example of an ecommerce site selling clothes and accessories. Users tend to have varying requirements in narrowing their clothing searches, whether it’s by size, color, season, garment type, fabric, brand, and so on. This often leads designers of an ecommerce store to consider a faceted navigation pattern, where users can narrow their search across several sets of criteria––for example, medium size, yellow color, and cotton fabric––and see the results promptly.
While it sounds straightforward enough, this is a remarkably complicated feature to design. The ability of a prototype to help us try out ideas for laying out categories, their method of interaction, and which categories to narrow results by will significantly improve our chances of doing it justice. We can use a decent set of representative content to quickly implement a range of ideas for presenting and interacting with that content. We can communicate our ideas with stakeholders and test them out with real users––iterating, changing, and experimenting as we go.
Without a prototype, this kind of rapid iteration could only happen once the online store had been (at least) partially implemented. Prototyping allows us to do it earlier, quicker, and cheaper.
By now, I'm hoping you have plenty of ideas for a prototype and what can be achieved by creating one. That said, it's worth addressing what we’re unlikely to achieve with a prototype.
If you're looking to try out some design ideas with a view to employing metrics to assess which is “better” (for example, more sign-ups, more conversions, highest task completion rate), a prototype is unlikely to help. For these kinds of tests, you need a large sample size––typically in the thousands or tens of thousands; however, utilizing quantitative research to make decisions such as these is beyond the scope of this book.
It's worth pointing out, though, that prototypes generally will help you test your designs with a large number of users more successfully than alternatives such as sketches or wireframes. This is because of the ease of implementing, sharing, publishing and running tests with prototypes, and iterating these tests over and above the other methods.
It’s generally a bad idea to try to measure the success of a task completion/conversion funnel (for example, how far users of an ecommerce site progress along a sales funnel) with user tests, whether it be a prototype or with a production siteQuantitative measurement of progress in goal funnels is covered in the SitePoint book Researching UX: Analytics: http://ift.tt/2oKfaNl.
This is because in an observed user-testing scenario, users are motivated to complete the tasks they're presented with purely by the nature of being a participant in a user test. We might expect to hear comments along the lines of “I'd have given up by now,” which to a degree are useful. But since what users say they do and what they actually do can be two completely different things, such comments only help up to a point. When using a site in a natural context, user behavior in reality may be very different and tolerance for poor design much lower.
Most prototyping techniques fail to match the final production implementation and, as a result, can’t be used to test the accessibility of a design; for example, measuring the ability for users of assistive technologies to access content and features.
Typically, HTML prototyping is done in a very rough-and-ready way, so coding standards and accessibility barely get a look-in.
Continue reading %UX: What Can We Prototype? What Can’t We Prototype?%
The team over at Qbootstrap have provided us with this free One Page HTML Wedding template built on the Bootstrap Framework. The long-scrolling template comes with 3 header options: parallax, video and Flexslider. Other features include a sticky header (that smooth scrolls to sections), countdown timer, love story timeline, groomsmen section, bridesmaids section, RSVP form and photo gallery. A very generous freebie, thank you!
