The List of Photo-Editing Tricks that You Must Know

If you are new to photography, photo editing may seem challenging and daunting, to say the least. However, with many tools available for editing your photos, it can be very easy for you to retouch or enhance your photographs and completely transform the way they look. With constant advances in...

[ This is a content summary only. Visit our website http://ift.tt/1b4YgHQ for full links, other content, and more! ]

by Guest Author via Digital Information World

Ask the UXperts: What Stakeholders Need to Know About Psychology — with Susan Weinschenk

Every day we make design decisions based on what we know about people – how they think, work, play.

You may not have a degree in psychology, but you’ve probably learned (unconsciously and intuitively) about people just from your experience with what does and doesn’t work in design. But do your stakeholders know what you know? What do the stakeholders need to understand about human psychology in order to understand why you are making the design decisions you are making?

In this session Susan will give us the tools to manage the expectations of our stakeholders and to make sure they have the information they need to make the right decisions for your target audience.

The Details

• Where: Our dedicated ‘Ask the UXperts’ Slack channel (You’ll need to request an invitation if you haven’t yet joined our Slack channel)
• When: 2pm Wednesday 15 March PST or 8am Thursday 16 March AEDT (or find out what time that is for you)

Meet Susan  Weinschenk

Susan Weinschenk has a Ph.D. in Psychology, is Chief Behavioral Scientist and CEO at The Team W, Inc, and an Adjunct Professor at the University of Wisconsin.

She consults with Fortune 1000 companies, start-ups, governments and non-profits. Dr. Weinschenk is the author of several books, including 100 Things Every Designer Needs To Know About People, and How To Get People To Do Stuff. Clients include Medtronic. Walmart, Disney, Amazon, and the European Union Commission.

 

How to Ask Your Questions

If you can’t make the live session but have questions, we’d love to collect them ahead of time and we’ll ask Susan on your behalf. You can ask them in the comments below. We’ll publish the responses (along with the full transcript) in the days following the session.

Here are a few questions to get you started:

1. How can we convince stakeholders that what they think is a good idea might not be a good idea for our target audience?
2. How much information do stakeholders need in order to understand our design decisions? Is there a tipping point?
3. Can you recommend any resources that will support me in talking with my stakeholders?

How does Ask the UXperts work?

These sessions run for approximately an hour and best of all, they don’t cost a cent. We use a dedicated public Slack channel. That means that there is no audio or video, but a full transcript will be posted up on here in the days following the session.

The post Ask the UXperts: What Stakeholders Need to Know About Psychology — with Susan Weinschenk appeared first on UX Mastery.

by Sarah Hawk via UX Mastery

New Code eBooks Available for Subscribers

Create Offline Web Apps Using Service Workers & PouchDB

Offline web applications are becoming more and more popular. Offline support is so important that it's now common to talk about the 'Offline First' approach, where it becomes a primary consideration. It's also gathering popularity with the rise of Progressive Web Apps.

In this post, we will look at how to add offline support to a basic contact list web app by implementing asset caching, client-side data storage and synchronization with a remote data store.

The source code of the app is available on GitHub.

Why Support Offline?

Why should we care about offline support?

I myself spend more than one hour on a train every day. I don't want to waste this time, so I take my laptop to work a bit along the way. I use the cell network to be online. The connection is not reliable, so I lose it from time to time. My user experience is up to the web app I'm using. Only a few apps, with good offline support, behave as expected and connection loss is transparent. Some behave weirdly, so when I refresh the page, I lose data. Most don't support offline at all, and I have to wait for a stable connection to be able to use them.

An unreliable connection is not the only use case. We can also talk about situations where you might be offline for several hours, for example, while on an airplane.

Another important advantage of offline support is the performance boost. Indeed, the browser doesn't need to wait for assets to be loaded from the server. The same for data, once stored on the client.

Thus we need offline:

1. to be able to use apps even with flaky connection (cell network in a train)
2. to be able to work without network connection (on an airplane)
3. to boost the performance

Progressive Web Apps

Google's Progressive Web Apps (PWA) concept is a methodology aimed at delivering web apps that provide the UX of native mobile apps. PWA includes offline support, but it also covers a lot more:

• Responsiveness - support for different form factors: mobile, tablet, desktop
• Web App Manifest - to install an app on the home screen
• App Shell - a design pattern in which the basic UI app shell is separated from the content loaded afterward
• Push notifications - to get "instant" updates from the server

Addy Osmani wrote a great intro post about PWA.

In this article, we are going to focus only on a single aspect: offline support.

Defining Offline Support

Let's clarify what it takes to support offline. We need to take care of two aspects:

1. app assets - caching HTML, JS scripts, CSS style sheets, images
2. app data - storing data on client-side

App assets

The first solution in HTML5 to cache offline assets was AppCache. The idea is to provide an app manifest describing which resources should be stored in the browser cache. Thus, the next time an app is loaded, these assets will be taken from the browser cache.

Important: While being simple, there are quite a lot of pitfalls with using AppCache. The standard is now deprecated, although it's still widely supported by browsers.

Service Workers were introduced to replace AppCache. They provide a flexible solution for the offline support. Service Workers give control over outgoing requests, allowing a script intercept them and return the necessary responses. The caching logic is entirely on the developer's shoulders. The app code itself can check if an asset is saved in the cache and requests it from the server only if needed.

It's important to note that Service Workers are supported only via HTTPS (HTTP is allowed for localhost) connections. We will look at how to use Service Workers shortly.

App data

App data can be stored in the offline storage provided by browsers.

There are several options introduced by HTML5:

• WebStorage - key-value storage
• IndexedDB - NoSQL database
• WebSQL - built-in SQLite database

WebStorage is a key-value storage. This is the simplest cross-browser storage, but there are several pitfalls to be aware of. You have to take care of serialization and deserialization of data that you put inside because the values must be plain strings. You may run up against size limits with larger data sets. Also, it's possible to get into a race condition, meaning if you have two tabs opened at the same time in the browser you could end up with unexpected behavior.

IndexedDB is much more powerful and seems to be the best way to go with offline storage. It has plenty of space available. It supports transactions and can be safely used in several browser tabs at the same time. It's also supported by all modern browsers.

WebSQL is literally SQLite in the browser. Full-featured relational DB with ACID on the client. Unfortunately, WebSQL has been deprecated by the standards committee and was never supported in non-Blink/Webkit browsers.

There are several libraries out there which provide an abstraction over offline storage:

• localForage - simple localStorage-like API
• IDBWrapper - cross-browser IndexedDB wrapper
• PouchDB - client-side storage solution inspired by CouchDB. It supports automatic sync with the backend if CouchDB is being used.

The ContactBook App

Now, let's see how to add offline support to a web application. Our sample app is a basic contact book:

We have the list of contacts on the left and a details form on the right used for editing contacts. A contact has three fields: first name, last name, and phone.

You can find the app source code on GitHub. To run the app you'll need Node.js installed. If you're not sure about this step, you can follow our beginner's guide to npm.

Start by downloading the sources and running the following commands from the project folder:

$ npm install
$ npm run serve

What about backend? We are using pouchdb-server to provide a REST API over CouchDB storage, and http-server to serve frontend assets.

Continue reading %Create Offline Web Apps Using Service Workers & PouchDB%

by Artem Tabalin via SitePoint

Restive.js – Designer Friendly jQuery Toolkit for Responsive Web Design

Restive.js is a designer-friendly jQuery toolkit for building mobile-friendly websites.

Using a combination of smart device detection, advanced breakpoints management, and timely CSS class additions, restive.js will make it easier for you to build mobile-friendly and/or responsive Web pages.

by via jQuery-Plugins.net RSS Feed

How We Built EQCSS & Why You Should Try Building Your Own Polyfills Too

The Backstory

In 2013, I was creating the frontend of a responsive web app that had a lot of data to display. I had done a lot of responsive design using @media queries, but as I found myself trying to re-use components from one layout in another layout, I wished I could make my responsive breakpoints correspond to the width of the elements instead of the width of the browser.

This is something CSS can't currently do, so I was copying and pasting a lot of styles from template to template, changing mostly just the breakpoints. I searched for existing workarounds, mainly tools and JavaScript plugins, to help me automate this process or output the duplicate code for me — but these all seemed like imperfect solutions to the problem.

I had heard about Less, a CSS preprocessor that lets you author CSS that includes extra features like variables and functions that aren't part of standard CSS. You can add a small JavaScript plugin on your website that will allow the browser to read this non-standard CSS, and all your non-standard code would magically translate to styles that the browser understood. I started to wonder if there was a way I could extend CSS in the same way to solve my problem!

The Birth of a Plugin

Somewhere along the way, my paths crossed with an amazing and creative coder named Maxime. I had been a big fan of some of Maxime's past projects, and he had knowledge and understanding of CSS and JavaScript far beyond mine. One day, when I was thinking about my challenges with CSS, I sent him the following message:

I need a way of writing CSS styles that lets me:

• specify different styles based on the current width of an element
• specify different styles based on the current height of an element
• keep an element vertically centered within its parent element at all times
• keep an element horizontally centered within its parent element at all times
• specify different styles based on the text length of an element
• specify different styles based on number of child elements an element contains
• Bonus: to allow me to navigate up the DOM using the < selector

If I had a library like this I believe I could design layouts that would be truly bulletproof and unbreakable. I need @element queries!

Is it possible to write these styles in a way that looks familiar to people who write CSS, but gets read and executed by JavaScript?

Is JavaScript able to parse text (maybe called .jss file or <script type="text/jss"> where I could write CSS blocks, but wrap them with special @element queries, which could be read by JavaScript, and have the computed styles applied to the page?

[code language="css"]
@element('.widget-box', min-height: 500px) {
.widget-box {
background: red;
}
.widget-box a {
font-size: 18pt;
}
}
[/code]

or

[code language="css"]
@element('#username', min-length: 20) {
#username {
font-size: 8pt;
}
#username < label {
border: 1px solid red;
}
}
[/code]

For this to be truly useful, it needs to have a small learning curve for people who already know CSS but don’t know JavaScript. They should be able to add the JavaScript library to a site and write the custom styles and have it work without needing any custom JavaScript. I guess that makes this more like a polyfill than a plugin : )

Is something like this possible?

— Tommy, December 5, 2014

Continue reading %How We Built EQCSS & Why You Should Try Building Your Own Polyfills Too%

by Tom Hodgins via SitePoint

Pass Data with NSNotification between ViewControllers in Swift 3

This article was originally published at iOS Geek Community.

Today, let’s talk about how and why we use NSNotification to pass data and communicate/notify between classes and structs. By the way, NSNotification, unlike its name, has nothing to do with Push Notification — rookie mistake 101 (me).

Yes, there are many ways to pass data in Swift: Delegate, Key-Value Observing, Segue, and NSNotification, Target-Action, Callbacks. However, each one has its own pros and cons. They are like dining utensils. For example, I wouldn’t use chopsticks — although it’s pretty darn good — to drink soup.

Since there are many, I’m only going to cover one at a time, and I will going to mention why you should spoons instead of chopsticks along the way. It doesn’t make sense to tell the differences between chopsticks and knives before I have used both.

Continue reading %Pass Data with NSNotification between ViewControllers in Swift 3%

by Bob Lee via SitePoint