Jump to Navigation

Smashing Magazine

Syndicate content
Recent content in Articles on Smashing Magazine — For Web Designers And Developers
Updated: 1 hour 17 min ago

Monthly Web Development Update 10/2018: The Hurricane Web, End-To-End-Integrity, And RAIL

Fri, 10/19/2018 - 9:19am
Monthly Web Development Update 10/2018: The Hurricane Web, End-To-End-Integrity, And RAIL Monthly Web Development Update 10/2018: The Hurricane Web, End-To-End-Integrity, And RAIL Anselm Hannemann 2018-10-19T15:19:58+02:00 2018-10-21T14:20:03+00:00

With the latest studies and official reports out this week, it seems that to avoid an irreversible climate change on Planet Earth, we need to act drastically within the next ten years. This rose a couple of doubts and assumptions that I find worth writing about.

One of the arguments I hear often is that we as individuals cannot make an impact and that climate change is “the big companies’ fault”. However, we as the consumers are the ones who make the decisions what we buy and from whom, whose products we use and which ones we avoid. And by choosing wisely, we can make a change. By talking to other people around you, by convincing your company owner to switch to renewable energy, for example, we can transform our society and economy to a more sustainable one that doesn’t harm the planet as much. It will be a hard task, of course, but we can’t deny our individual responsibility.

Maybe we should take this as an occasion to rethink how much we really need. Maybe going out into nature helps us reconnect with our environment. Maybe building something from hand and with slow methods, trying to understand the materials and their properties, helps us grasp how valuable the resources we currently have are — and what we would lose if we don’t care about our planet now.

News
  • Chrome 70 is here with Desktop Progressive Web Apps on Windows and Linux, public key credentials in the Credential Management API, and named Workers.
  • Postgres 11 is out and brings more robustness and performance for partitioning, enhanced capabilities for query parallelism, Just-in-Time (JIT) compilation for expressions, and a couple of other useful and convenient changes.
  • As the new macOS Mojave and iOS 12 are out now, Safari 12 is as well. What’s new in this version? A built-in password generator, a 3D and AR model viewer, icons in tabs, web pages on the latest watch OS, new form field attribute values, the Fullscreen API for iOS on iPads, font collection support in WOFF2, the font-display loading CSS property, Intelligent Tracking Prevention 2.0, and a couple of security enhancements.
  • Google’s decision to force users to log into their Google account in the browser to be able to access services like Gmail caused a lot of discussions. Due to the negative feedback, Google promptly announced changes for v70. Nevertheless, this clearly shows the interests of the company and in which direction they’re pushing the app. This is unfortunate as Chrome and the people working on that project shaped the web a lot in the past years and brought the ecosystem “web” to an entirely new level.
  • Microsoft Edge 18 is out and brings along the Web Authentication API, new autoplay policies, Service Worker updates, as well as CSS masking, background blend, and overscroll.

Meet SmashingConf New York 2018 (Oct 23–24), focused on real challenges and real front-end solutions in the real world. From progressive web apps, Webpack and HTTP/2 to serverless, Vue.js and Nuxt — all the way to inclusive design, branding and machine learning. With Sarah Drasner, Sara Soueidan and many other speakers.

Check all topics and speakers ↬ General
  • Max Böck wrote about the Hurricane Web and what we can do to keep users up-to-date even when bandwidth and battery are limited. Interestingly, CNN and NPR provided text-only pages during Hurricane Florence to serve low traffic that doesn’t drain batteries. It would be amazing if we could move the default websites towards these goals — saving power and bandwidth — to improve not only performance and load times but also help the environment and make users happier.
UI/UX Shawn Parks shares the lessons he learned from redesigning his portfolio every year. (Image credit) Accessibility Tooling Privacy
  • Guess what? Our simple privacy-enhancing tools that delete cookies are useless as this article shows. There are smarter ways to track a user via TLS session tracking, and we don’t have much power to do anything against it. So be aware that someone might be able to track you regardless of how many countermeasures you have enabled in your browser.
  • Josh Clark’s comment on university research about Google’s data collection is highlighting the most important parts about how important Android phone data is to Google’s business model and what type of information they collect even when your smartphone is idle and not moving location.
Security Cloudflare’s IPFS gateway allows a website to be end-to-end secure while maintaining the performance and reliability benefits of being served from their edge network. (Image credit) Web Performance The four parts of the RAIL performance model: Response, Animation, Idle, Load. (Image credit) HTML & SVG JavaScript
  • Willian Martins shares the secrets of JavaScript’s bind() function, a widely unknown operator that is so powerful and allows us to invoke this from somewhere else into named, non-anonymous functions. A different way to write JavaScript.
  • Everyone knows what the “9am rush hour” means. Paul Lewis uses the term to rethink how we build for the web and why we should try to avoid traffic jams on the main thread of the browser and outsource everything that doesn’t belong to the UI into separate traffic lanes instead.
CSS Did you know you can use negative grid line numbers to position Grid items with CSS? (Image credit) Work & Life Going Beyond…
  • In the Netherlands, there’s now a legal basis that prescribes CO2 emissions to be cut by 25% by 2020 (that’s just a bit more than one year from now). I love the idea and hope other countries will be inspired by it — Germany, for example, which currently moves its emission cut goals farther and farther into the future.
  • David Wolpert explains why computers use so much energy and how we could make them vastly more efficient. But for that to happen, we need to understand the thermodynamics of computing better.
  • Turning down twenty billion dollars is cool. Of course, it is. But the interesting point in this article about the Whatsapp founder who just told the world how unhappy he is having sold his service to Facebook is that it seems that he believed he could keep the control over his product.

One more thing: I’m very grateful for all of you who helped raise my funding level for the Web Development Reading List to 100% this month. I never got so much feedback from you and so much support. Thank you! Have a great month!

—Anselm

(cm)

Categories: Around The Web

Reasons Your Mobile App Retention Rate Might Be So Low

Thu, 10/18/2018 - 8:00am
Reasons Your Mobile App Retention Rate Might Be So Low Reasons Your Mobile App Retention Rate Might Be So Low Suzanne Scacca 2018-10-18T14:00:01+02:00 2018-10-21T14:20:03+00:00

In business, there’s a lot of talk about generating customer loyalty and retaining the business of good customers. Mobile apps aren’t all that different when you think about it.

While the number of installs may signal that an app is popular with users initially, it doesn’t tell the whole story. In order for an app to be successful, it must have loyal subscribers that make use of the app as it was intended. Which is where the retention rate enters the picture.

In this article, I want to explore what a good retention rate looks like for mobile apps. I’ll dig into the more common reasons why mobile apps have low retention rates and how those issues can be fixed.

Let’s start with the basics.

Checking The Facts: What Is A Good Mobile App Retention Rate?

A retention rate is the percentage of users that remain active on your mobile app after a certain period of time. It doesn’t necessarily pertain to how many people have uninstalled the app either. A sustained lack of activity is generally accepted as a sign that a user has lost interest in an app.

To calculate a good retention rate for your mobile app, be sure to take into account the frequency of logins you expect users to make. Some apps realistically should see daily logins, especially for gaming, dating, and social networking. Others, though, may only need weekly logins, like for ride-sharing apps, Google Authenticator or local business apps.

When calculating the retention rate for anticipated daily usage, you should run the calculation for at least a week, if not more. For weekly or monthly usage, adjust your calculation accordingly.

Recommended reading: Driving App Engagement With Personalization Techniques

Front-end is messy and complicated these days. That's why we publish articles, printed books and webinars with useful techniques to improve your work. Even better: Smashing Membership with a growing selection of front-end & UX goodies. So you get your work done, better and faster.

Explore Smashing Membership ↬

For daily usage, divide the following like so:

Users Logged into the App on Day 0 Users Logged into the App on Day 1 Users Logged into the App on Day 2 Users Logged into the App on Day 3 Users Logged into the App on Day 4 Users Logged into the App on Day 5 Users Logged into the App on Day 6 Users Logged into the App on Day 7

This will give you a curve that demonstrates how well your mobile app is able to sustain users. Here is an example of how you would calculate this:

Number of New Users Acquired Day 0 100 Day 1 91 (91% ) Day 2 85 (85%) Day 3 70 (70%) Day 4 60 (60%) Day 5 49 (49%) Day 6 32 (32%) Day 7 31 (31%)

If you can, add the data into a line graph format. It’ll be much easier to spot trends in downward momentum or plateauing:

An example of how to calculate and chart your app’s retention rate (Image source: Google Docs) (Large preview)

This is just a basic example of how a retention rate calculation works. Curious to see what the average (Android) mobile app’s retention curve looks like?

A Quettra study (with Andrew Chen) charted the following:

Average retention rates for Android apps (Image source: Andrew Chen) (Large preview)

According to this data, the average app loses 77% of users within just three days. By the time the first-month wraps, 90% of those original new users are gone.

Recent data shows that the average cost per installation of a mobile app (globally) breaks down to the following:

Average cost of each mobile app installation (Image source: Statista) (Large preview)

Basically, this is the average cost to build and market an app — a number you should aim to recuperate per user once the app has been installed. However, if your app loses about 90% of its users within a month’s time, think about what the loss actually translates to for your business.

Ankit Jain of Gradient Ventures summarized the key lesson to take away from these findings:

“Users try out a lot of apps but decide which ones they want to ‘stop using’ within the first 3-7 days. For ‘decent’ apps, the majority of users retained for 7 days stick around much longer. The key to success is to get the users hooked during that critical first 3-7 day period.”

As you can see from the charting of the top Android apps, Jain’s argument holds water:

Average retention rates for top Android apps (Image source: Andrew Chen) (Large preview)

Top Android apps still see a sharp decline in active users after about three days, but then the numbers plateau. They also don’t bleed as many new users upfront, which allows them to sustain a larger percentage of users.

This is exactly what you should be aiming for.

A Retention Recovery Guide For Mobile Apps

So, we know what makes for a good and bad retention rate. We also understand that it’s not about how many people have uninstalled or deleted the app from their devices. Letting an app sit in isolation, untouched on a mobile device, is just as bad.

As you can imagine, increasing your retention rate will lead to other big wins for your mobile app:

  • More engagement
  • More meaningful engagement
  • Greater loyalty
  • Increased conversions (if your app is monetized, that is)

Now you need to ask yourself:

“When are users dropping off? And why?”

You can draw your own hypotheses about this based on the retention rate alone, though it might be helpful to make use of tools like heat maps to spot problem areas in the mobile app. Once you know what’s going on, you can take action to remove the friction from the user experience.

To get you started, I’ve included a number of issues that commonly plague mobile apps with low retention rates. If your app is guilty of any of these, get to work on fixing the design or functionality ASAP!

1. Difficult Onboarding

Aside from the app store description and screenshots users encounter, onboarding is the first real experience they have with a mobile app. As you can imagine, a frustrating sign-in or onboarding procedure could easily turn off those who take that as a signal the rest of the app will be as difficult to use.

Let’s use the OkCupid dating app as an example. The initial splash screen looks great and is well-designed. It has a clear value proposition, and an easy-to-find call-to-action:

The first screen new OkCupid users encounter (Image source: OkCupid) (Large preview)

On the next page, users are given two options for joining the app. It’s free to use, but still requires users to create an account:

Account creation for OkCupid gives two options (Image source: OkCupid) (Large preview)

The first option is a Facebook sign-in. The other is to use a personal email address. Since Facebook logins can streamline not just signup, but the setup of dating mobile apps (since users can automatically import details, photos, and connections), this option is probably one many users’ choose.

But there’s a problem with it: After seven clicks to connect to Facebook and confirm one’s identity, here is what the user sees (or, at least, this is what I encountered the last couple of times I tried):

After connecting to Facebook, users still encounter an error signing in. (Image source: OkCupid) (Large preview)

One of the main reasons why users choose a Facebook sign-in is because of how quick and easy it’s supposed to be. In these attempts of mine, however, my OkCupid app wouldn’t connect to Facebook. So, after 14 total clicks (7 for each time I tried to sign up), I ended up having to provide an email anyway.

This is obviously not a great first impression OkCupid has left on me (or any of its users). What makes it worse is that we know there’s a lot more work to get onboarded with the app. Unlike competitors like Bumble that have greatly simplified signup, OkCupid forces users into a buggy onboarding experience as well as a more lengthy profile configuration.

Needless to say, this is probably a bit too much for some users.

2. Slow or Sloppy Navigation

Here’s another example of a time-waster for mobile app users.

Let’s say getting inside the new app is easy. There’s no real onboarding required. Maybe you just ask if it’s okay to use their location for personalization purposes or if you can send push notifications. Otherwise, users are able to start using the app right away.

That’s great — until they realize how clunky the experience is.

To start, navigation of a mobile app should be easy and ever-present. It’s not like a browser window where users can hit that “Back” button in order to get out of an unwanted page. On a mobile app, they need a clear and intuitive exit strategy. Also, navigation of an app should never take more than two or three steps to get to a desired outcome.

One example of this comes from Wendy’s. Specifically, I want to look at the “Offers” user journey:

The home page of the Wendy’s app promises “Offers” (Image source: Wendy's) (Large preview)

As you can see, the navigation at the bottom of the app is as clear as day. Users have three areas of the app they can explore — each of which makes sense for a business like Wendy’s. There are three additional navigation options in the top-right corner of the app, too.

When “Offers” is clicked, users are taken to a sort of full-screen pop-up containing all current special deals:

The Wendy’s Offers pop-up screen (Image source: Wendy's) (Large preview)

As you can see, the navigation is no longer there. The “X” for the Offers pop-up also sits in the top-left corner (instead of the right, which is the more intuitive choice). This is already a problem. It also persists throughout the entire Offers redemption experience.

Let’s say that users aren’t turned off by the poor navigational choices and still want to redeem one of these offers. This is what they encounter next:

Wendy’s Offers can be used at the restaurant. (Image source: Wendy's) (Large preview)

Now, this is pretty cool. Users can redeem the offer at that very moment while they’re in a Wendy’s or they can place the order through the app and pick it up. Either way, this is a great way to integrate the mobile app and in-store experiences.

Except…

The Wendy’s offer code takes a while to populate. (Image source: Wendy's) (Large preview)

Imagine standing in line at a Wendy’s or going through a drive-thru that isn’t particularly busy. That image above is not one you’d want to see.

They call it “fast food” for a reason and if your app isn’t working or it takes just a few seconds too long to load the offer code, imagine what that will do for everyone else’s experience at Wendy’s. The cashiers will be annoyed that they’ve held up the flow of traffic and everyone waiting in line will be frustrated in having to wait longer.

While mobile apps generally are designed to cater to the single user experience, you do have to consider how something like this could affect the experience of others.

Recommended reading: How To Improve Your Billing Form’s UX In One Day

3. Overwhelming Navigation

A poorly constructed or non-visible navigation is one thing. But a navigation that gives way too many options can be just as problematic. While a mega menu on something like an e-commerce website certainly makes sense, an oversized menu in mobile apps doesn’t.

It pains me to do this since I love the BBC, but its news app is guilty of this crime:

The top of the BBC News navigation (Image source: BBC News) (Large preview)

This looks like a standard news navigation at first glance. Top (popular) stories sit at the top; my News (customized) stories below it. But then it appears there’s more, so users are apt to scroll downwards and see what others options there are:

More of the BBC News navigation bar (Image source: BBC News) (Large preview)

The next scroll down gives users a choice of stories by geography, by subject:

Even more BBC News pages to choose from. (Image source: BBC News) (Large preview)

And then there are even more options for sports as well as specific BBC News channels. It’s a lot to take in.

If that weren’t bad enough, the personalization choices mirror the depth of the navigation:

BBC News personalization choices (Image source: BBC News) (Large preview)

Now, there’s nothing wrong with personalizing the mobile app experience. I think it’s something every app — especially those that deliver global news — should allow for. However, BBC News gives an overwhelming amount of options.

What’s worse is that many of the stories overlap categories, which means users could realistically see the same headlines over and over again as they scroll through the personalized categories they’ve chosen.

If BBC News (or any other app that does this) wants to allow for such deep personalization, the app should be programmed to hide stories that have already been seen or scrolled past — much like how Feedly handles its stream of news. That way, all that personalization really is valuable.

Recommended reading: How BBC Interactive Content Works Across AMP, Apps, And The Web

4. Outdated or Incomplete Experience

Anything a mobile app does that makes users unwillingly stop or slow down is bad. And this could be caused by a number of flaws in the experience:

  • Slow-loading pages,
  • Intrusive pop-ups,
  • Dated design choices,
  • Broken links or images,
  • Incomplete information,
  • And so on.

If you expect users to take time to download and at least give your app a try, make sure it’s worth their while.

One such example of this is the USHUD mobile app. It’s supposed to provide the same exact experience to users as the website counterpart. However, the app doesn’t work all that well:

A slow-loading page on the USHUD app (Image source: USHUD) (Large preview)

In the example above, you can see that search results are slow to load. Now, if they were chock full of images and videos, I could see why that might occur (though it’s still not really acceptable).

That said, many of the properties listed on the app don’t have corresponding visual content:

USHUD is missing images in search. (Image source: USHUD) (Large preview)

Real estate apps or, really, any apps that deal in the transaction of purchasing or renting of property or products should include images with each listing. It’s the whole reason why consumers are able to rent and buy online (or at least use it in the decisionmaking process).

But this app seems to be missing many images, which can lead to an unhelpful and unpleasant experience for users who hope to get information from the more convenient mobile app option.

If you’re going to build a mobile app that’s supposed to inform and compel users to engage, make sure it’s running in tip-top shape. All information is available. All tabs are accessible. And pages load in a reasonable timeframe.

5. Complicated or Impossible Gestures

We’ve already seen what a poorly made navigation can do to the user experience as well as the problem with pages that just don’t load. But sometimes friction can come from intentionally complicated gestures and engagements.

This is something I personally encountered with Sinemia recently. Sinemia is a competitor of the revolutionary yet failing MoviePass mobile app. Sinemia seems like a reasonable deal and one that could possibly sustain a lot longer than the unrealistic MoviePass model that promises entry to one movie every single day. However, Sinemia has had many issues with meeting the demand of its users.

To start, it delayed the sending of cards by a week. When I signed up in May, I was told I would have to wait at least 60 days to receive my card in the mail, even though my subscription had already kicked in. So, there was already a disparity there.

Sinemia’s response to that was to create a “Cardless” feature. This would enable those users who hadn’t yet received their cards to begin using their accounts. As you can see here, the FAQ included a dedicated section to Sinemia Cardless:

Questions about Sinemia Cardless (Image source: Sinemia) (Large preview)

See that point that says “I can confirm I have the latest Sinemia release installed…”? The reason why that point is there is because many Sinemia Cardless users (myself included) couldn’t actually activate the Cardless feature. When attempting to do so, the app would display an error.

The Sinemia FAQ then goes on to provide this answer to the complaint/question:

Sinemia Cardless issues with app version (Image source: Sinemia) (Large preview)

Here’s the problem: there were never any updates available for the mobile app. So, I and many others reached out to Sinemia for support. The answer repeatedly given was that Cardless could not work if your app ran on an old version. Support asked users to delete the app from their devices and reinstall from the app store to ensure they had the correct version — to no avail.

For me, this was a big problem. I was paying for a service that I had no way of using, and I was spending way too much time uninstalling and installing an app that should work straight out the gate.

I gave up after 48 hours of futile attempts. I went to my Profile to delete my account and get a refund on the subscription I had yet to use. But the app told me it was impossible to cancel my account through it. I tried to ask support for help, but no one responded. So, after Googling similar issues with account cancellations, I found that the only channel through which Sinemia would handle these requests was Facebook Messenger.

Needless to say, the whole experience left me quite jaded about apps that can’t do something as simple as activating or deactivating an account. While I recognize an urge to get a better solution on the mobile app market, rushing out an app and functionality that’s not ready to reach the public isn’t the solution.

Recommended reading: What You Need To Know About OAuth2 And Logging In With Facebook

6. Gated Content Keeps App from Being Valuable

For those of you who notice your retention rate remaining high for the first week or so from installation, the problem may more have to do with the mobile app’s limitations.

Recolor is a coloring book app I discovered in the app store. There’s nothing in the description that would lead me to believe that the app requires payment in order to enjoy the calming benefits of coloring pictures, but that’s indeed what I encountered:

Free drawings users can color with the Recolor app. (Image source: Recolor) (Large preview)

Above, you can see there are a number of free drawings available. Some of the more complex drawings will take some time to fill in, but not as much as a physical coloring book would by hand, which means users are apt to get through this quickly.

Inevitably, mobile app users will go searching for more options and this is what they will encounter:

Recolor’s more popular options are for Premium users. (Image source: Recolor) (Large preview)

When users look into some of the more popular drawings from Recolor, you’d hope they would encounter at least a few free drawings, right? After all, how many users could possibly be paying for a subscription to this app that’s not outrightly advertised as premium?

But it’s not just the Popular choices that require a fee to access (that’s what the yellow symbol in the bottom-right means). So, too, do most of the other categories:

Premium account needed to access more drawings on Recolor. (Image source: Recolor) (Large preview)

It’s a shame that so much of the content is gated off. Coloring books have proven to be good for managing anxiety and stress, so leaving users with only a few dozen options doesn’t seem right. Plus, the weekly membership to the app is pretty expensive, even if users try to earn coins by watching videos.

A mobile app such as this one should make its intentions clear from the start: “Consider this a free trial. If you want more, you’ll have to pay.”

While I’m sure the developer didn’t intend to deceive with this app model, I can see how the retention rate might suffer and prevent this app from becoming a long-term staple on many users’ devices.

When making a promise to users (even if it’s implied), design and manage your app in a way that lives up to those expectations.

As I noted earlier, those initial signups might make you hopeful of the app’s long-term potential, but a forced pay-to-play scenario could easily disrupt that after just a few weeks.

7. Impossible to Convert in-App

Why do we create mobile apps? For many developers, it’s because the mobile web experience is insufficient. And because many users want a more convenient way to connect with your brand. A mobile app sits on the home screen of devices and requires just a single click to get inside.

So, why would someone build an app that forces users to leave it in order to convert? It seems pointless to even go through the trouble of creating the app in the first place (which is usually no easy task).

Here’s the Megabus app:

The Megabus mobile app for searching and buying tickets (Image source: Megabus) (Large preview)

Megabus is a low-cost transportation service that operates in Canada, the United States and the United Kingdom. There are a number of reasons why users would gravitate to the mobile app counterpart for the website; namely, the convenience of logging in and purchasing tickets while they’re traveling.

The image above shows the search I did for Megabus tickets through the mobile app. I entered all pertinent details, found tickets available for my destination and got ready to “Buy Tickets” right then and there.

However, you can’t actually buy tickets from the mobile app:

Megabus tickets are only available online. (Image source: Megabus) (Large preview)

Upon clicking “Buy Tickets”, the app pushes users out and into their browser. They then are asked to reinput all those details from the mobile app to search for open trips and make a purchase.

For a service that’s supposed to make travel over long distances convenient, its mobile app has done anything but reinforce that experience.

For those of you considering building an app (whether on your own accord or because a client asked) solely so you can land a spot in app store search results, don’t waste users’ time. If they can’t have a complete experience within the app, you’re likely to see your retention rate tank fairly quickly.

Wrapping Up

Clearly, there are a number of ways in which a mobile app may suffer a misstep in terms of the user experience. And I’m sure that there are times when mobile app developers don’t even realize there’s something off in the experience.

This is why your mobile app retention rate is such a critical data point to pay attention to. It’s not enough to just know what that rate is. You should watch for when those major dropoffs occur; not just in terms of the timeline, but also in terms of which pages lead to a stoppage in activity or an uninstall altogether.

With this data in hand, you can refine the in-app experience and make it one that users want to stay inside of for the long run.

(ra, yk, il)
Categories: Around The Web

Live Accessibility And Performance Audits At SmashingConf Toronto

Wed, 10/17/2018 - 7:20am
Live Accessibility And Performance Audits At SmashingConf Toronto Live Accessibility And Performance Audits At SmashingConf Toronto Markus Seyfferth 2018-10-17T13:20:35+02:00 2018-10-21T14:20:03+00:00

Earlier this year, many of your favorite speakers were featured at SmashingConf Toronto, however, things were quite different this time. The speakers had been asked to present without slides. It was interesting to see the different ways our speakers approached the challenge.

Two of our speakers chose to demonstrate how they audit a site or application live on stage: Marcy Sutton on accessibility, and Tim Kadlec on performance. Watch the videos to see an expert perform these audits, and see if there is anything you can take back to your own testing processes.

To watch all of the videos recorded in Toronto, head on over to our SmashingConf Vimeo channel.

Accessibility: Marcy Sutton

Marcy took two example components, built using React, and walked us through how these components could be made more accessible with some straightforward changes.

Performance: Tim Kadlec

Tim demonstrates how to test the performance of a site, and find bottlenecks leading to poor experiences for visitors. If you have ever wondered how to get started testing for performance, this is a talk you will find incredibly useful.

Enjoyed watching these talks? There are many more videos from SmashingConf Toronto on Vimeo. We’re also getting ready for SmashingConf New York next week — see you there? ;-)

(ra, il)
Categories: Around The Web

Photoshop Workflows And Shortcuts For Digital Artists

Tue, 10/16/2018 - 9:30am
Photoshop Workflows And Shortcuts For Digital Artists Photoshop Workflows And Shortcuts For Digital Artists Yoanna Victorova 2018-10-16T15:30:51+02:00 2018-10-21T14:20:03+00:00

Adobe Photoshop plays a role in almost every digital creator’s life. Photoshop is what many digital artists, photographers, graphic designers, and even some web developers have in common. The tool is so flexible that often you can achieve the same results in several different ways. What sets us all apart is our personal workflows and our preferences on how we use it to achieve the desired outcome.

I use Photoshop every day and shortcuts are a vital part of my workflow. They allow me to save time and to focus better on what I am doing: digital illustration. In this article, I am going to share the Photoshop shortcuts I use frequently — some of its features that help me be more productive, and a few key parts of my creative process.

To profit the most from this tutorial, some familiarity with Photoshop would be required but no matter if you are a complete beginner or an advanced user, you should be able to follow along because every technique will be explained in detail.

For this article, I've decided to use one of my most famous Photoshop artworks named “Regret”:

Author’s illustration (Large preview) Table of Contents
  1. Introduction To Shortcuts: The Path To Boosting Your Productivity
  2. The Keyboard Shortcuts Window
  3. How To Increase And Decrease The Brush Size
  4. How To Increase And Decrease The Brush Softness
  5. Quick Color Picker (HUD Color Picker)
  6. Working With Layers
  7. Working With Curves
  8. Actions: Recording Everything You Need For Your Project
  9. Conclusion
  10. Further Reading

Getting workflow just right ain’t an easy task. So are proper estimates. Or alignment among different departments. That’s why we’ve set up “this-is-how-I-work”-sessions — with smart cookies sharing what works well for them. A part of the Smashing Membership, of course.

Explore Smashing Membership ↬ 1. Introduction To Shortcuts: The Path To Boosting Your Productivity

Every single designer, artist, photographer or web developer has probably once opened Photoshop and has pointed and clicked on an icon to select the Brush tool, the Move tool, and so on. We’ve all been there, but those days are long gone for most of us who use Photoshop every day. Some might still do it today, however, what I would like to talk about before getting into the details, is the importance of shortcuts.

When you think about it, you’re saving perhaps half a second by using a keyboard shortcut instead of moving your mouse (or stylus) over to the Tools bar and selecting the tool you need by clicking on the tool’s little icon. To some that may seem petty, however, do consider that every digital creator does thousands of selections per project and these half-seconds add up to become hours in the end!

Now, before we continue, please note the following:

  1. Shortcuts Notation
    I use Photoshop on Windows but all of the shortcuts should work the same on Mac OS; the only thing worth mentioning is that the Ctrl (Control) key on Windows corresponds to the Cmd (Command) key on the Mac, so I’ll be using Ctrl/Cmd throughout this tutorial.
  2. Photoshop CS6+
    All the features and shortcuts mentioned here should work in Photoshop CS6 and later — including the latest Photoshop CC 2018.
2. The Keyboard Shortcuts Window

To start off, I would like to show you where you can find the Keyboard Shortcuts window where you could modify the already existing shortcuts, and learn which key is bound to which feature or tool:

Open Photoshop, go to Edit and select Keyboard Shortcuts. Alternatively, you can access the same from here: Window → Workspace → Keyboard Shortcuts & Menus.

Photoshop’s edit (Large preview)

Now you will be greeted by the Keyboard Shortcuts and Menus window (dialog box), where you can pick a category you would like to check out. There are a ton of options in there, so it could get a bit intimidating at first, but that feeling will pass soon. The main three options (accessible through the Shortcuts for:... dropdown list) are:

  • Application Menus
  • Panel Menus
  • Tools

Typically the Application Menus will be the first thing you’ll see. These are the shortcuts for the menu options you see on the top of Photoshop’s window (File, Edit, Image, Layer, Type, and so on).

Applications menu (Large preview)

So for example if you’re using the Brightness/Contrast option often, instead of having to click on Image (in the menu), then Adjustments and finally find and click on Brightness/Contrast item, you can simply assign a key combination and Brightness/Contrast will show right up after you press the keys assigned.

The second section, Panel Menus, is an interesting one as well, especially in its Layers portion. You get to see several options that could be of use to you depending on the type of work you need to do. That’s where the standard New Layer shortcut lies (Ctrl/Cmd + Shift + N) but also you can set up a shortcut for Delete Hidden Layers. Deleting unnecessary layers helps in lowering the size of the Photoshop file and helps improving performance because your computer will not have to cache in on those extra layers that you’re actually not using.

Panel menu (Large preview)

The third section is Tools where you can see the shortcuts assigned to all the tools found in the left panel of Photoshop.

Pro Tip: To cycle between any of the tools that have sub-tools (example: the Eraser tool has a Background Eraser and a Magic Eraser) you just need to hold your Shift key and the appropriate shortcut button. In case of the Eraser example, press Shift + E a few times until you reach the desired sub-tool.

One last thing I would like to mention before wrapping up this section is that the Keyboard Shortcuts and Menus allows you to set up different Profiles (Photoshop calls them “sets” but I think that “profiles” better suits the purpose), so that if you don’t really want to mess with the Photoshop Defaults one, you can simply create a new personalized profile. It’s worth mentioning that when you create a new Profile, you get the Default set of Photoshop Shortcuts in it until you start modifying them.

Keyboard shortcuts and menus profile section (Large preview)

The Keyboard Shortcuts menu can take a bit of time to get around to, however, if you invest the time in the beginning (best if you do it in your own time rather than during a project), you will benefit later.

Focusing On The Shortcuts On The Left Side Of Your Keyboard

After people acknowledged the usefulness of using shortcuts, eventually they agreed that time is being wasted moving your hand from one side of the keyboard to the opposite one. Sounds a bit petty again, however, remember those half-seconds? They still add up, but this time it can even fatigue your arm if you’re constantly switching tools and have to move your arm around. So this probably led to Adobe adding a few more shortcut features focused on the left side of the keyboard.

Now let me show you the shortcuts that I most often use (and why).

3. How To Increase And Decrease The Brush Size

In order to increase or decrease the size of your brush, you need to:

  1. Click and hold the Alt key. (On Mac, this would be the Ctrl and Alt keys),
  2. Click and hold the right mouse button,
  3. Then drag horizontally from left to right to increase, and from right to left to decrease the size.

If you’re using anything from Photoshop CC 2017 and above, try pressing Fn + Ctrl + Alt while dragging. Looks like Adobe has changed this specific shortcut and haven’t document it just yet.

Brush size increase preview (Large preview)

The moment I learned about this shortcut, I literally couldn’t stop using it!

If you’re a digital artist, I believe you will particularly love it as well. Sketching, painting, erasing, just about everything you need to do with a brush becomes a whole lot easier and fluent because you wouldn’t need to reach for the all too familiar [ and ] keys which are the default ones for increasing and decreasing the brush size. Going for those keys can disrupt your workflow, especially if you need to take your eyes off your project or put the stylus aside.

4. How To Increase And Decrease The Brush Softness

It’s actually the same key combination but with a slight twist: increasing and decreasing the softness of your Brush will work only for Photoshop’s default Round brushes. Unfortunately, if you have any custom made brushes that have a custom form, this wouldn’t work for those.

  1. Click and hold the Alt key. (On the Mac this would be Ctrl and Alt keys),
  2. Click and hold the right mouse button,
  3. Then drag upwards to harden the edge of your brush and drag downwards to make it softer.
Brush softness increase preview (Large preview)

Again, this shortcut doesn’t work for custom shaped brushes, although it would have been a really nice feature to have. Hopefully, we’ll be able to see that in a future update to Photoshop.

5. Quick Color Picker (HUD Color Picker)

You may or may not be aware that Photoshop offers a quick color picker (HUD Color Picker). And no, this is not the color picker that is located in the Tools section.

Quick color picker (Large preview)

I am referring to what Adobe calls “HUD Color Picker” that pops up right where your cursor is located on the canvas.

This so-called HUD Color Picker is a built-in version and I believe it’s been around since at least Photoshop CS6 (which was released back in 2012). If you’re learning about this now, probably you’re as surprised as I was when I first came across it a few months ago. Yes, it took me a while to get used to, too! Well, to be fair, I do also have some reservations about this color picker, but I’ll get to them in a second.

Photoshop’s HUD color picker (Large preview)

Here’s how to pull up the HUD Color Picker:

On Windows
  1. Click and hold Alt + Shift,
  2. Click and hold the right mouse button.
On Mac
  1. Click and hold Ctrl ⌃ + Alt ⌥ + Cmd ⌘,
  2. Click and hold the right mouse button.

If you’ve followed the key combinations above, you should see this colorful square. However, you’ve probably noticed that it’s a bit awkward to work with it. For example, you need to continue holding all of the keys, and while you do that, you need to hover over to the right rectangle to pick a color gamut and then hover back to the square to pick the shade. With all of the hovering that’s going on, it’s somewhat easy to miss the color that you’ve actually set your heart to pick, which could get a little annoying.

Nevertheless, I do believe that with a little practice you will be able to master the Quick Color Picker and get your desired results. If you’re not too keen on using that built-in version, there are always third-party extensions that you can strap to your Photoshop, for example, Coolorus 2 Color Wheel or Painters Wheel (works with PS CS4, CS5, CS6).

6. Working With Layers

One of the advantages of working digitally is undisputedly the ability to work with layers. They are quite versatile, and there’s a lot of things that you could do with them. You could say that one could write a book just on Layers alone. However, I’m going to do the next best thing, and that would be to share with you the options I most commonly use when working on my projects.

As you may have guessed, the Layer section is a pretty important one for any type of digital creative. In this section, I’m going to share the simpler but very useful shortcuts that could be some real lifesavers.

Clipping Mask Layer

A Clipping Mask Layer is what I most often use when I’m drawing. For those of you who do not know what that is, it’s basically a layer which you clip on to the layer below. The layer below defines what’s visible on the clipped on layer.

For example, let’s say that you have a circle on the base layer and then you add a Clipping Mask Layer to that circle. When you start drawing on your Clipping Mask Layer, you will be restricted only to the shapes in the Base Layer.

Red circle shape on transparent background (Large preview) Drawing inserted into circle shape (Large preview)

Take notice of the layers on the right side of the screen. Layer 0 is the Clipping Mask Layer of the Base Layer — Layer 1.

This option allows you to really easily create frames and the best part is that they’re non-destructive. The more shapes you add (in this case it’s Layer 1), the more visible parts of the image can be seen.

Drawly’s artwork added into various shapes as a clipping mask (Large preview)

The most common use for Clipping Mask Layers in digital art/painting is to add shadows and highlights to a base color. For example, let’s say that you’ve completed your character’s line-art and you’ve added their base skin tone. You can use Clipping Mask Layers to add non-destructive shadows and highlights.

Note: I’m using the term “non-destructive” because you cannot erase away something from the base layers — they will be safe and sound.)

So, how do you create those Clipping Mask Layers? Well, each one starts off as a regular “Layer”.

To create a regular Layer, you can use this shortcut:

Action Keyboard Shortcut Creates a new regular Layer Ctrl/Cmd + Shift + N Makes the newly created Layer into a Clipping Mask to the Layer below it Ctrl/Cmd + Alt + G

An alternative way to make a regular layer into a Clipping Mask is to press and hold the Alt key, and click between the two Layers. The upper layer will then become the Clipping Mask of the layer below.

Selecting All Layers

Every once in a while, you may want to select all of the layers, and group them together so that you can continue building on top of them or a number of other reasons. Typically, what I used to do is simply hold the Ctrl/Cmd key and then start clicking away at all of the layers. Needless to say, that was a bit time-consuming, especially if I’m working on a big project. So here’s a better way:

What you would need to do is simply press: Ctrl/Cmd + Alt + A.

Now that should’ve selected all of your layers and you will be able to do anything you want with them.

Flattening Visible Layers

Clipping Mask Layers may be totally awesome, however, they don’t always work well if you want to modify something in the general image you’re doing. Sometimes you just need everything (e.g. base color, highlights and shadows) to stop being on different layers and just be combined into one. Sometimes you just need to merge all currently visible layers into one, in a non-destructive way.

Here’s how:

Press and hold Ctrl/Cmd + Alt + Shift + E.

Et voilà! Now you should be seeing an extra layer on the top that has all other visible layers in it. The beauty of this shortcut is that you still have your other layers below — untouched and safe. If you mess up something with the newly created layer, you can still bring things back to the way they were before and start afresh.

Copying Multiple Layers

Every now and then we’re faced with the need to copy stuff from multiple layers. Typically what most people do is duplicate the two given layers they need, merge them and then start erasing away the unnecessary parts of the image.

What you need to do instead is to make a selection and then press:

Ctrl/Cmd + Shift + C

Here’s an example:

Three different colored circles (Large preview)

As you can see, each color dot is on a separate layer. Let’s say that we need to copy a straight rectangle through the center of the dots and copy it on a layer at the top.

Three different colored circles with a selection box inside them (Large preview)

We’ve made a selection and once you press Ctrl/Cmd + Shift + C, Photoshop will copy everything you have in your selection to the clipboard. Then all you have to do is simply paste (Ctrl/Cmd + V) anywhere, and a new layer will appear on the top of the page.

Selection box with three different colors (Large preview)

This shortcut can come really handy especially when you’re working with multiple layers, and you need just a portion of the image to be together in a single layer.

7. Working With Curves

In this section of the article, I would like to cover the importance of values as well as Curves which are generally a big topic to cover.

Starting off with the shortcut: Ctrl/Cmd + M.

Pretty simple, right? The best things in life are (almost) always simple! However, don’t let this talk about simplicity fool you, the Curves setting is one of the most powerful tools you have in Photoshop. Especially when it comes to tweaking brightness, contrast, colors, tones, and so on.

Now some of you may be feeling a bit of intimidated by the previous sentence: colors, tones, contrast,... say what now? Don’t worry, because the Curves tool is pretty simple to understand and it will do marvelous things for you. Let’s dig into the details.

Curves histogram highlighted in red square (Large preview)

This is what the Curves tool basically looks like. As you can see, there’s a moderate amount of options available. What we’re interested in, however, is the area I’ve captured inside the red square. It is actually a simple Histogram with a diagonal line across. The Histogram’s purpose is to show the values of the given image (or painting), left being the darkest points and right being the lightest ones.

Curves histogram with one anchor point added (Large preview) Curves histogram with two anchor points added (Large preview)

Using the mouse, we can put points on the diagonal line and drag it up and down. We typically decide what we want to darken or lighten. If, for example, we want to have the light parts of our image be just a bit darker, we need to click somewhere on the right side and drag down (just like in the first image).

Here’s an example. First, take a look at the normal image:

Drawly’s artwork, original colors and values. (Large preview)

Now, using Curves with the light parts toned down:

Curves histogram with one anchor point (Large preview)

AIn addition, just for demonstration purposes, here’s what would happen if we have the lighter parts darkened and the darker parts lightened:

Curves histogram with two anchor points making the ‘S’ shape (Large preview)

You see, basically the linework is the darkest part, which stayed and the other darks have been lightened to a grayish type of value.

Now let me quickly elaborate on values and why they matter: by “values,” especially in the art world, we’re referring to the amount of lightness or darkness in a drawing (painting). With values, we create depth in our painting which on its part helps with creating the illusion which element is closer to the viewer and which one is in the distance (further back).

8. Actions: Recording Everything You Need For Your Project

Every so often we all need to deal with repetitive processes which could range from adding a filter over our image to creating certain types of layers with blending modes. Does this sound familiar? If so, keep reading.

Did you know that Photoshop supports programming languages such as JavaScript, AppleScript, and VBScript to automate certain processes? I didn’t, as programming has never been my cup of tea. The good thing is that instead, I came across the Actions panel, which offers a lot of functionality and options for automating some repetitive tasks and workflows. In my opinion, this is the best automation tool that Photoshop has to offer if you don’t know how to code.

The Actions panel basically can record every process you’re doing (e.g. adding a layer, cropping the image, changing its hue, and so on); then you can assign a function key to this process and easily re-use it later at any time.

By using the Actions panel, you can capture just about anything that you do in Photoshop and then save it as a process.

Let me give you an example. Let’s say that you want to automate the process of Create a new Layer, set it as a Clipping Mask, and then set its blending mode to Multiply (or anything else). You can record this whole process which would then be available to you for re-use by the press of a button.

Here’s how it works:

Pressing Alt + F9 will open this panel:

The actions panel displaying all the default options (Large preview)

As you can probably see, there are some default (pre-recorded) processes on there. What we’re interested in, however, is creating our own action, which is done by clicking on the “Create new action” icon.

The actions panel with the “New Action” button highlighted (Large preview)

Now just like when you create a new layer in the Layers panel, once you click on the “Create new action” icon, a pop-up window opens with a few options in it.

New Action window (Large preview)

You can choose any given name for the Action you want to create and assign a Function key for it. So, for this demonstration purpose, I’ll create an action that will do the following:

  • Create a new transparent Layer;
  • Add it as a Clipping Mask to the Layer below;
  • Set its blending mode to Multiply.

I’ll set its Function key to Shift + F2.

Custom name added and function key assigned in New Action box (Large preview)

Once you’re ready with these settings, what you need to do is press the Record button. Once you’ve done that, you’ll notice that the Actions panel now has a red button to show you it’s recording.

Recording the new Action (Large preview)

Now you just have to go about the regular process of creating a new layer, set it as a clipping mask and change its blending mode to Multiply.

Heart shape layer added (Large preview) New layer added on top of the heart shape (Large preview) New layer made in to a clipping mask to the heart shape (Large preview) Blending mode drop-down menu open, Multiply highlighted. (Large preview)

Once you’re done, you have to hit the Stop icon on the Actions panel.

Actions panel open with the red recording button (Large preview)

Your automation process is now ready to go! When you press Shift + F2, you’ll get a new Layer set as a Clipping Mask to the layer below and its blending mode set to Multiply.

I would also like to mention that the Actions automation process is not limited to just creating layers and setting blending modes. Here are some examples of some pretty handy other uses and options for actions:

  • You can set up to save images as certain types of files to certain folders on your computer;
  • Using File → Automate → Batch for processing lots of images;
  • The Allow Tool Recording option in the flyout Actions panel menu allows actions to include painting, and so on;
  • The Insert Conditional option in the flyout Actions panel menu allows actions to change their behavior, based on the state of the document;
  • File → Scripts → Script Events Manager lets actions run based on events, like when a document is opened or a new document is created.

Let me give you another example, I’ll create another Action that will change the size of my image and save it as a PNG file in a certain folder on my desktop.

So after we hit the New Action button on the Actions panel, we’ll proceed with picking the shortcut that we want, set a name for it, and I’ll take it a step further and assign a color to the Action (I’ll explain why this is a helpful feature in a bit).

New Action box open (Large preview) Selecting the Function key (Large preview) Checking the Shift checkbox (Large preview) Picking a color for the Action (Large preview) Blue color picked for the new Action (Large preview)

Now about that color, you may notice that when you assign a color, it doesn’t really reflect in the Actions Panel. Instead, everything stays monochrome. The reason is because when you typically open that panel, you’re in the Edit view, where you’re able to modify the Actions, record new ones, and so on. In order to see all of the available actions in a simpler interface, do this:

  • On the upper-right hand corner of the panel you will see four horizontal lines. Click on those.
  • You’ll get a drop-down menu, where you have different Actions options. On the top, you’ll notice a Button Mode.
  • Actions’ drop-down menu open, highlighted 'Button Mode'. (Large preview)
  • Clicking on that will change the Actions Panel interface, where you will see your available Actions as colorful buttons.
The Actions’ button mode (Large preview)

If you haven’t guessed it already, coloring your Actions will help you distinguish them more easily at a glance. In Button mode, when you take a glance at the panel, you will be able to navigate quickly to the Action that you want to apply to your image/drawing (if you don’t really remember the shortcut you’ve assigned for it).

Okay, so what we have so far is the following:

  1. We’ve created a new action;
  2. Set the shortcut for it;
  3. Changed its color;
  4. Named it.

Let’s proceed with recording the process that we need.

To open the Image Size menu, you can either go to Image → Image Size or simply hit Ctrl + Alt + I and you’ll get this window:

Image size menu open (Large preview)

What you would want to do is set the desired size for your image and once you’re happy with that hit “OK” to apply the changes.

Image size values changed (Large preview)

Next, what we want to do is use the Save As option in order to get the option to choose the type of file, destination folder, and so on. You can either go to File → Save As... or you could simply press Ctrl + Shift + S and you will get the following window:

Saving dialogue box open (Large preview)

Navigate to the dedicated folder in which you want to save the current project in and actually save it there. An additional Action you can do is to close the image/project you’re working on (don’t worry, the Actions won’t stop recording unless you close down Photoshop).

PNG options displayed (Large preview)

Once all of that is done, you can hit the Stop icon on the Actions Panel to stop recording your movement in Photoshop.

If you need to resize a bunch of files and save them in a dedicated folder, you just have to load them up in Photoshop and continue hitting the Action shortcut that you’ve created for Resizing and Saving.

If you take the time to get accustomed to the Actions tool in Photoshop and utilize it, you can say “Goodbye” to the bothersome repetitive work that usually eats up most of your time. You will be able to fly through these tasks with such speed that even the Flash could get jealous of.

9. Conclusion

In this article, I’ve shared some of the shortcuts I mostly use. I sincerely hope that they will help you boost up your productivity and make your workflow better as well.

Special Thanks

I would like to mention that this tutorial was made possible with the help of Angel (a.k.a. ArcanumEX). You can check out his artwork on his Facebook page, on Instagram, and on his YouTube channel.

Further Reading

In addition to everything I’ve talked about so far, I’ll include more resources that I believe you might find helpful. Be sure to check out:

What are your favorite shortcuts? Feel free to share them in the comments below!

(mb, ra, yk, il)
Categories: Around The Web

Smart Bundling: How To Serve Legacy Code Only To Legacy Browsers

Mon, 10/15/2018 - 8:30am
Smart Bundling: How To Serve Legacy Code Only To Legacy Browsers Smart Bundling: How To Serve Legacy Code Only To Legacy Browsers Shubham Kanodia 2018-10-15T14:30:13+02:00 2018-10-21T14:20:03+00:00

A website today receives a large chunk of its traffic from evergreen browsers — most of which have good support for ES6+, new JavaScript standards, new web platform APIs and CSS attributes. However, legacy browsers still need to be supported for the near future — their usage share is large enough not to be ignored, depending on your user base.

A quick look at caniuse.com’s usage table reveals that evergreen browsers occupy a lion’s share of the browser market — more than 75%. In spite of this, the norm is to prefix CSS, transpile all of our JavaScript to ES5, and include polyfills to support every user we care about.

While this is understandable from a historical context — the web has always been about progressive enhancement — the question remains: Are we slowing down the web for the majority of our users in order to support a diminishing set of legacy browsers?

The different compatibility layers of a web app. (View large version) The Cost Of Supporting Legacy Browsers

Let’s try to understand how different steps in a typical build pipeline can add weight to our front-end resources:

Transpiling To ES5

To estimate how much weight transpiling can add to a JavaScript bundle, I took a few popular JavaScript libraries originally written in ES6+ and compared their bundle sizes before and after transpilation:

Library Size
(minified ES6) Size
(minified ES5) Difference TodoMVC 8.4 KB 11 KB 24.5% Draggable 77.9 KB 53.5 KB 31.3% Luxon 75.4 KB 100.3 KB 24.8% Video.js 237.2 KB 335.8 KB 29.4% PixiJS 370.8 KB 452 KB 18%

On average, untranspiled bundles are about 25% smaller than those that have been transpiled down to ES5. This isn’t surprising given that ES6+ provides a more compact and expressive way to represent the equivalent logic and that transpilation of some of these features to ES5 can require a lot of code.

ES6+ Polyfills

While Babel does a good job of applying syntactical transforms to our ES6+ code, built-in features introduced in ES6+ — such as Promise, Map and Set, and new array and string methods — still need to be polyfilled. Dropping in babel-polyfill as is can add close to 90 KB to your minified bundle.

Front-end is messy and complicated these days. That's why we publish articles, printed books and webinars with useful techniques to improve your work. Even better: Smashing Membership with a growing selection of front-end & UX goodies. So you get your work done, better and faster.

Explore Smashing Membership ↬ Web Platform Polyfills

Modern web application development has been simplified due to the availability of a plethora of new browser APIs. Commonly used ones are fetch, for requesting for resources, IntersectionObserver, for efficiently observing the visibility of elements, and the URL specification, which makes reading and manipulation of URLs on the web easier.

Adding a spec-compliant polyfill for each of these features can have a noticeable impact on bundle size.

CSS Prefixing

Lastly, let’s look at the impact of CSS prefixing. While prefixes aren’t going to add as much dead weight to bundles as other build transforms do — especially because they compress well when Gzip’d — there are still some savings to be achieved here.

Library Size
(minified, prefixed for last 5 browser versions) Size
(minified, prefixed for last browser version) Difference Bootstrap 159 KB 132 KB 17% Bulma 184 KB 164 KB 10.9% Foundation 139 KB 118 KB 15.1% Semantic UI 622 KB 569 KB 8.5%

A Practical Guide To Shipping Efficient Code

It’s probably evident where I’m going with this. If we leverage existing build pipelines to ship these compatibility layers only to browsers that require it, we can deliver a lighter experience to the rest of our users — those who form a rising majority — while maintaining compatibility for older browsers.

Forking our bundles. (View large version)

This idea isn’t entirely new. Services such as Polyfill.io are attempts to dynamically polyfill browser environments at runtime. But approaches such as this suffer from a few shortcomings:

  • The selection of polyfills is limited to those listed by the service — unless you host and maintain the service yourself.
  • Because the polyfilling happens at runtime and is a blocking operation, page-loading time can be significantly higher for users on old browsers.
  • Serving a custom-made polyfill file to every user introduces entropy to the system, which makes troubleshooting harder when things go wrong.

Also, this doesn’t solve the problem of weight added by transpilation of the application code, which at times can be larger than the polyfills themselves.

Let see how we can solve for all of the sources of bloat we’ve identified till now.

Tools We’ll Need
  • Webpack
    This will be our build tool, although the process will remain similar to that of other build tools, like Parcel and Rollup.
  • Browserslist
    With this, we’ll manage and define the browsers we’d like to support.
  • And we’ll use some Browserslist support plugins.
1. Defining Modern And Legacy Browsers

First, we’ll want to make clear what we mean by “modern” and “legacy” browsers. For ease of maintenance and testing, it helps to divide browsers into two discrete groups: adding browsers that require little to no polyfilling or transpilation to our modern list, and putting the rest on our legacy list.

Browsers that support ES6+, new CSS attributes, and browser APIs like Promises and Fetch. (View large version)

A Browserslist configuration at the root of your project can store this information. “Environment” subsections can be used to document the two browser groups, like so:

[modern] Firefox >= 53 Edge >= 15 Chrome >= 58 iOS >= 10.1 [legacy] > 1%

The list given here is only an example and can be customized and updated based on your website’s requirements and the time available. This configuration will act as the source of truth for the two sets of front-end bundles that we will create next: one for the modern browsers and one for all other users.

2. ES6+ Transpiling And Polyfilling

To transpile our JavaScript in an environment-aware manner, we’re going to use babel-preset-env.

Let’s initialize a .babelrc file at our project’s root with this:

{ "presets": [ ["env", { "useBuiltIns": "entry"}] ] }

Enabling the useBuiltIns flag allows Babel to selectively polyfill built-in features that were introduced as part of ES6+. Because it filters polyfills to include only the ones required by the environment, we mitigate the cost of shipping with babel-polyfill in its entirety.

For this flag to work, we will also need to import babel-polyfill in our entry point.

// In import "babel-polyfill";

Doing so will replace the large babel-polyfill import with granular imports, filtered by the browser environment that we’re targeting.

// Transformed output import "core-js/modules/es7.string.pad-start"; import "core-js/modules/es7.string.pad-end"; import "core-js/modules/web.timers"; … 3. Polyfilling Web Platform Features

To ship polyfills for web platform features to our users, we will need to create two entry points for both environments:

require('whatwg-fetch'); require('es6-promise').polyfill(); // … other polyfills

And this:

// polyfills for modern browsers (if any) require('intersection-observer');

This is the only step in our flow that requires some degree of manual maintenance. We can make this process less error-prone by adding eslint-plugin-compat to the project. This plugin warns us when we use a browser feature that hasn’t been polyfilled yet.

4. CSS Prefixing

Finally, let’s see how we can cut down on CSS prefixes for browsers that don’t require it. Because autoprefixer was one of the first tools in the ecosystem to support reading from a browserslist configuration file, we don’t have much to do here.

Creating a simple PostCSS configuration file at the project’s root should suffice:

module.exports = { plugins: [ require('autoprefixer') ], } Putting It All Together

Now that we’ve defined all of the required plugin configurations, we can put together a webpack configuration that reads these and outputs two separate builds in dist/modern and dist/legacy folders.

const MiniCssExtractPlugin = require('mini-css-extract-plugin') const isModern = process.env.BROWSERSLIST_ENV === 'modern' const buildRoot = path.resolve(__dirname, "dist") module.exports = { entry: [ isModern ? './polyfills.modern.js' : './polyfills.legacy.js', "./main.js" ], output: { path: path.join(buildRoot, isModern ? 'modern' : 'legacy'), filename: 'bundle.[hash].js', }, module: { rules: [ { test: /\.jsx?$/, use: "babel-loader" }, { test: /\.css$/, use: [MiniCssExtractPlugin.loader, 'css-loader', 'postcss-loader'] } ]}, plugins: { new MiniCssExtractPlugin(), new HtmlWebpackPlugin({ template: 'index.hbs', filename: 'index.html', }), }, };

To finish up, we’ll create a few build commands in our package.json file:

"scripts": { "build": "yarn build:legacy && yarn build:modern", "build:legacy": "BROWSERSLIST_ENV=legacy webpack -p --config webpack.config.js", "build:modern": "BROWSERSLIST_ENV=modern webpack -p --config webpack.config.js" }

That’s it. Running yarn build should now give us two builds, which are equivalent in functionality.

Serving The Right Bundle To Users

Creating separate builds helps us achieve only the first half of our goal. We still need to identify and serve the right bundle to users.

Remember the Browserslist configuration we defined earlier? Wouldn’t it be nice if we could use the same configuration to determine which category the user falls into?

Enter browserslist-useragent. As the name suggests, browserslist-useragent can read our browserslist configuration and then match a user agent to the relevant environment. The following example demonstrates this with a Koa server:

const Koa = require('koa') const app = new Koa() const send = require('koa-send') const { matchesUA } = require('browserslist-useragent') var router = new Router() app.use(router.routes()) router.get('/', async (ctx, next) => { const useragent = ctx.get('User-Agent') const isModernUser = matchesUA(useragent, { env: 'modern', allowHigherVersions: true, }) const index = isModernUser ? 'dist/modern/index.html', 'dist/legacy/index.html' await send(ctx, index); });

Here, setting the allowHigherVersions flag ensures that if newer versions of a browser are released — ones that are not yet a part of Can I Use’s database — they will still report as truthy for modern browsers.

One of browserslist-useragent’s functions is to ensure that platform quirks are taken into account while matching user agents. For example, all browsers on iOS (including Chrome) use WebKit as the underlying engine and will be matched to the respective Safari-specific Browserslist query.

It might not be prudent to rely solely on the correctness of user-agent parsing in production. By falling back to the legacy bundle for browsers that aren’t defined in the modern list or that have unknown or unparseable user-agent strings, we ensure that our website still works.

Conclusion: Is It Worth It?

We have managed to cover an end-to-end flow for shipping bloat-free bundles to our clients. But it’s only reasonable to wonder whether the maintenance overhead this adds to a project is worth its benefits. Let’s evaluate the pros and cons of this approach:

1. Maintenance And Testing

One is required to maintain only a single Browserslist configuration that powers all of the tools in this pipeline. Updating the definitions of modern and legacy browsers can be done anytime in the future without having to refactor supporting configurations or code. I’d argue that this makes the maintenance overhead almost negligible.

There is, however, a small theoretical risk associated with relying on Babel to produce two different code bundles, each of which needs to work fine in its respective environment.

While errors due to differences in bundles might be rare, monitoring these variants for errors should help to identify and effectively mitigate any issues.

2. Build Time vs. Runtime

Unlike other techniques prevalent today, all of these optimizations occur at build time and are invisible to the client.

3. Progressively Enhanced Speed

The experience of users on modern browsers becomes significantly faster, while users on legacy browsers continue to get served the same bundle as before, without any negative consequences.

4. Using Modern Browser Features With Ease

We often avoid using new browser features due to the size of polyfills required to use them. At times, we even choose smaller non-spec-compliant polyfills to save on size. This new approach allows us to use spec-compliant polyfills without worrying much about affecting all users.

Differential Bundle Serving In Production

Given the significant advantages, we adopted this build pipeline when creating a new mobile checkout experience for customers of Urban Ladder, one of India’s largest furniture and decor retailers.

In our already optimized bundle, we were able to squeeze savings of approximately 20% on the Gzip’d CSS and JavaScript resources sent down the wire to modern mobile users. Because more than 80% of our daily visitors were on these evergreen browsers, the effort put in was well worth the impact.

Further Resources (dm, ra, yk, il, al)
Categories: Around The Web

Designing Experiences To Improve Mental Health

Fri, 10/12/2018 - 8:00am
Designing Experiences To Improve Mental Health Designing Experiences To Improve Mental Health Marli Mesibov 2018-10-12T14:00:30+02:00 2018-10-21T14:20:03+00:00

Did you know that a simple search for “depression” on the iPhone App Store brings up 198 results? In the Android Play Store, it brings up 239. The categories range from “Medical” to “Health & Fitness” to “Lifestyle.” The apps themselves offer everything from “depressing wallpaper” to “mood tracker” to “life coach.” We are approaching a golden age of digital therapeutics and design for mental health — if we as UX practitioners do our jobs well.

Given the plethora of apps available, you might assume that there are already dozens of wonderful digital therapies available for people struggling with mental health disorders. But — according to initial studies by clinical psychologists — you would be wrong. Most apps are useless at best, and harmful at worst, due primarily to a disconnect between the designers building the apps and the patients and providers in the field of mental health.

As of July 2017, 28% of digital health apps on the App Store were focused on mental health and behavioral disorders. (Large preview)

Some apps (mostly within the Lifestyle category) are harmless but useless. Emo Wallpaper, for example, is appropriately named and makes no claims to treat mental illness. It is intended as entertainment for people who are having a tough day. But there are more dangerous examples. One of the worst (since removed from the App Store) was iBipolar, which recommended that people in the middle of a manic episode drink hard liquor to help them sleep. Not only is this bad advice — alcohol does not lead to healthy sleep — but alcoholism is a problem for many people with bipolar disorder. The app was actively harmful.

Prescription drugs are regulated by the FDA, while mobile apps are not. How can we as UX designers create better apps to improve mental health treatment?

Are Apps The Answer?

Approximately one in five American adults experience mental illness each year. For some people, this can refer to a temporary depressive episode brought on by grief, such as the death of a loved one, or severe anxiety caused by external factors like a stressful job. For nearly 1 in 25 Americans (about 10 million people) it’s a chronic condition, such as bipolar disorder, chronic depression, or schizophrenia. Yet only about 40% of people experiencing mental illness are receiving treatment.

Recommended reading: Mental Health: Let’s Talk About It

Meet SmashingConf New York 2018 (Oct 23–24), focused on real challenges and real front-end solutions in the real world. From progressive web apps, Webpack and HTTP/2 to serverless, Vue.js and Nuxt — all the way to inclusive design, branding and machine learning. With Sarah Drasner, Sara Soueidan and many other speakers.

Check all topics and speakers ↬

The reasons vary. For some, they are undiagnosed or may refuse treatment. They may struggle with the stigma attached to mental illness. But for many, there is a lack of access. The association Mental Health America has studied and reported on what “limited access” means, and identified four systemic barriers:

  1. Lack of insurance or inadequate insurance;
  2. Lack of available treatment providers:
  3. Lack of available treatment types (inpatient treatment, individual therapy, intensive community services);
  4. Insufficient finances to cover costs — including, copays, uncovered treatment types, or when providers do not take insurance.
Access to Care Map, from Mental Health America (Large preview)

With that in mind, it would appear that a mobile-based solution is the obvious answer. And yet there are plenty of inherent challenges. Key among them is the gap between the clinicians treating patients and the UX practitioners working on mental health design.

Bridge The Gap Between Clinicians And Designers

About two years ago, I began research in the mental health design space. As a UX practitioner who focuses in health care, I wanted to learn how people struggling with mental health issues differed from people struggling with other chronic illnesses. I thought the work would entail an audit of the App Store and Play Store, a few weeks of interviewing clinicians to learn about the space, and then perhaps building an app with my team.

Instead, the work has continued ever since. At the time I interviewed ten clinicians, four behavior change designers, and five UX designers who had designed apps in the mental health space. But from these interviews I learned that there are two reasons why the design for mental health is lagging behind design for other healthcare needs. Those two reasons have changed my entire perspective on what we need to do to improve design in the space. It resulted in the creation of a few guidelines which I now hope to popularize.

Here is an overview of the research I conducted, and the two themes that emerged.

The Research

I initially assumed there were no apps available. And yet my audit of the App Store and Play Store uncovered hundreds of existing apps. Obviously, building an app was not the problem. But I began to wonder: why aren’t these apps used? (Few were downloaded, and I had never heard of any of them — for all that I work in the healthcare space!) And why are those that are used unsuccessful? To find that out, I needed more research.

Over the course of a few months, I interviewed therapists, psychiatrists, psychologists, and social workers. On the design side, I interviewed behavior change analysts, UX designers, and anyone I could find who had been involved in designing an app to improve mental health.

Some questions I asked the designers included:

  • What do you feel is missing from the field of mental health, if anything?
  • What are some of the top challenges you face when designing for people with mental health challenges?
  • What examples exist of poorly designed interventions for mental health? What examples exist of well-designed interventions?
  • If they had designed an app: What was the goal of the intervention you designed?
    • How did you test it?
    • Who did you test it with?
    • Was it successful? Why/why not?

Meanwhile, some of the questions I asked clinicians were:

  • How do you diagnose a patient’s mental health?
  • What barriers exist to patients’ improving their mental health?
  • What technology currently helps patients improve or deal with their mental health/illness?
  • How can technology benefit your patients?
  • What are one or two important pieces of advice you wish more people knew when creating applications/tools to help improve mental health from afar?

After the interviews, I came away with two new understandings:

Problem #1: Designers Don’t Know What Clinicians Know

Many designers told me they were starting from scratch. They did research with patients and learned what patients thought they needed from an app. But very few spoke with healthcare providers. As a result, the designers were missing the clinical expertise.

For example, a clinician shared with me that:

“What people say they want is not often what they want.”

Broadly, patients want to feel better. In a user interview, they might say they want to take their medication, or follow a meal plan, or meet some other goal. So the designer builds an app that allows them to set goals and deadlines. But as the clinician explained it:

“Change is scary, so when [patients] find out that feeling better requires change, that is a barrier.”

The app was designed to meet what patients said they needed, not what clinical expertise shows they will respond to.

When I asked one psychiatrist what apps she might recommend to her patients, she said:

“I wish I knew what I could recommend. Nothing is clearly safe, evidence-based, and tested.”

She explained to me that she once recommended a suicide hotline, but that it made people wait on hold for 20 minutes. After that experience, she said, “never again.”

When it comes to mobile apps, the risk is even greater — she worries that an app may have good intentions, but it might not be right for a particular patient. Or it may have the right elements, but the language could be inadvertently guilt-inducing or triggering.

In short, the mental health world does not need more apps, or more technology. As psychiatrist and Digital Psychiatry Director John Torous said in a recent article:

“Digital tools like fitness trackers present great opportunity to improve care [...but…] they need to be utilized in the right way.”

In other words, patients need apps their providers have helped to build, and validate as useful.

Recommended reading: Dealing With Loud And Silent Burnout

Problem #2: Design Moves Fast

I already knew that designers move fast. It’s part of the tech world’s MO — just think of Facebook’s motto, “move fast and break things.” The catch is that second part: when we move fast, we break things. This is great when we’re breaking through assumptions, or breaking features that would otherwise cause issues post-launch. But it’s very bad when the things we might break are people.

To quote Sara Holoubek, founder and CEO of Luminary Labs:

“[I]t’s one thing to move fast and break things with a consumer internet app. It’s another thing when tech is used to improve human life.”

Designers are often up against deadlines. Some work for large healthcare companies that want to launch in time for a specific trade show, or before a competitor gets to market. This is very different from the world of health care, which tends to move very slowly, waiting for compliance or FDA approval, clinical trials, and multiple rounds of validation.

The challenge is adding the clinical expertise and knowledge to the design process, without hampering designers’ ability to move quickly.

Mental Health Design Guidelines

To that end, my team determined that we did not need to build a new app. After all, the mental health field is broad, and there is no one app that will reach everyone. What we need is to popularize the guidelines and communication methodologies that health providers know and use. We need to share that knowledge with designers.

During our clinical interviews, I noticed patterns. For example, though not every therapist said it the same way, they all mentioned how important friends, family, or community are for someone struggling with mental health issues. From this, we created a guideline called “Human.”

Thus, we created a set of six guidelines. Clinicians, researchers, behavior change analysts, and health writers have weighed in on the guidelines, and continue to refine them. They draw attention to six steps that any designer needs to follow in order to create an app that will live up to any provider’s standards.

Are you building a mental health app? Focus on HEALTH. (Large preview) 1. Human

As I noted above, there are systemic barriers to mental health care. For the many people who can’t afford or can’t find a therapist, mobile apps seem like a magical solution. 95% of Americans now own a cell phone! That means mobile apps could ostensibly make mental health care accessible to 95% of the population.

But technology is not the same as a human therapist, family member, or friend. As one behavior change specialist I interviewed shared, “The human-to-human connection is very important. In mental health, it is important to have a person who you can talk to and understand the other person is there for you.” Social support increases motivation, and people are vital for crises — although algorithms are working to identify a risk of suicide, the device alone is not enough to overcome the urge.

With that in mind, our first guideline is to be human. Encourage connection to external supports in addition to providing value in the app. And provide the ability to connect to a therapist or 9-1-1, as MY3 does.

The MY3 app encourages human connections. Having a therapist, friend, family member, or other human support correlates to lower rates of suicide and depression. (Large preview) 2. Evidence-Based

Mental health professionals spend years training to treat mental health illnesses. Many professionals specialize in one or two specific types of treatment, such as talk therapy, Cognitive Behavioral Therapy (CBT), Dialectical Behavioral Therapy (DBT), or other treatment frameworks.

These therapies have specific activities associated with them; they encourage patients to develop certain skills, and they even make specific language choices. Any designer building a mental health app needs to begin by choosing one of these evidence-based therapy styles to follow. What’s more, other designers and users can help evaluate UI and short-term efficacy, but make sure to also bring in clinicians to ensure the app is properly representing the therapy.

Our second guideline is: to be evidence-based. Keep problem #1 in mind: the clinicians know how to treat their patients. We as designers can’t simply replace clinical knowledge with effective UI. The two need to work hand in hand, as Pear Therapeutics THRIVETM app does.

Pear Therapeutics app is undergoing extensive research, including clinical trials with mental health professionals, and applying for FDA clearance. (Large preview) 3. Accepting

I frequently hear people talk about a favorite coach or friend who gave them “tough love.” Many people seem to see tough love as a way of accusing someone of failure, and thus prompting them to do better. (Perhaps our fictional film coaches are to blame.)

In reality, fear of failure is exactly what stops many people from trying something new. This includes seeking mental health treatment. To make matters worse, low motivation is a core symptom of many mental health illnesses. Thus, angry or accusatory language can truly harm people. Instead, our third guideline is to be accepting. Reinforce how capable a person is, and show empathy in how you communicate.

Sanofi’s RA Digital Companion is designed for people with Rheumatoid Arthritis (RA). The app understands that many people with RA suffer from depression, and focuses on acceptance.

Sanofi’s RA Digital Companion app focuses on helpful resources and uses encouraging language. (Large preview) 4. Lasting

When Pokémon Go launched, it became a nationwide craze just seven days later with an estimate of more than 65 million users. Yet the craze passed in only two months. The problem? Pokémon Go focused on short-term motivators, such as badges and gamification (as many apps do). To create a successful app that people use consistently, the motivation needs to become internal.

What does that mean? External motivators come from outside sources. Internal motivators connect to core values, such as “I want to succeed in my career” or “I care about my children.” These motivators can’t be taken away by another person, but they are not always clear. Our fourth guideline is to be lasting. This means that you should connect to an individual’s internal motivations, and help them feel responsible and in control, as Truth Initiative’s BecomeAnEX program does.

The BecomeAnEX app helps people quitting smoking to focus on their goals and internal motivators. It looks at the lasting benefits as well as how someone is feeling today, so that quitting becomes more than an impulse. (Large preview) 5. Tested

This should come as no surprise to any UX practitioner: testing is key! Clinicians and patients can and should be a part of the design process. Usability testing will help identify things you may not have considered, for example, someone having an anxiety attack may have trouble pressing small buttons. Or someone with schizophrenia having an auditory hallucination may struggle to focus on a busy page of text.

Obviously, our fifth guideline is: Be Tested. Ideally, clinical testing can become a part of more mental health apps, but even if it’s not an option usability testing should be. As noted above, design moves fast. Don’t let design move so fast that you make poor assumptions.

Recommended reading: How To Deliver A Successful UX Project In The Healthcare Sector

6. Holistic

Lastly, we found that many apps are isolated to accomplishing a single task. And that’s fine for something like Instagram — you post photos, or you look at photos. But mental health is intrinsically linked to how people see themselves. With that in mind, a successful intervention has to fit into a person’s daily life.

This is our sixth and final guideline: be holistic. One example of this is the app Happify. While it’s far from perfect, it does an excellent job of offering options. A gratitude journal may help for one time, and the community is helpful at other times.

For any designer working on an app, it’s important to note how an app becomes holistic: the key is to learn about the target audience. Be specific: gender, age, culture, and diagnoses all impact the way a person deals with a mental illness. That’s why researchers like Dr. Michael Addis focus on specific segments of the population, as he does in his book Invisible Men: Men’s Inner Lives and Consequences of Silence.

Happify learns a lot about you as an individual before recommending anything. They ask about things that may not seem important, because they understand the holistic nature of mental health. (Large preview) Moving Forward

There is an overarching theme to these guidelines: what works for you as a designer may not work for your end-user. Of course, that’s the tenant of UX! Yet somehow, when it comes to health care, we as UX professionals tend to forget this. We are not healthcare providers. And even those of us who have experience as patients have only our own experiences to draw on.

These guidelines are not perfect, but they are a start. Over time I hope to finesse them with additional insight from providers, as well as from the designers beginning to use them. We are on the cusp of a new world of digital health care, where designers and providers and patients must work hand-in-hand to create seamless experiences to promote health and well being.

For anyone interested in getting involved, I am continuing to work on new initiatives to continually improve design for mental health. Feel free to share your experiences in the comments, or learn more at Mad*Pow.

(cc, ra, il)
Categories: Around The Web

Saving Grandma’s Recipes With Xamarin.Forms

Thu, 10/11/2018 - 8:10am
Saving Grandma’s Recipes With Xamarin.Forms Saving Grandma’s Recipes With Xamarin.Forms Matthew Soucoup 2018-10-11T14:10:38+02:00 2018-10-21T14:20:03+00:00

My grandma makes the best, most fluffiest, go weak-in-your-knees buns that anybody has ever tasted. The problem is, there’s a ton of secret ingredients (and I’m not just talking love) that go into those buns, and those ingredients and directions are all stored in my grandma’s head.

We all have family recipes like that, and instead of possibly forgetting them, in this article we’re going to create a mobile app for iOS and Android using Xamarin.Forms that will save them for myself and future generations of my family!

Delicious warm buns (Large preview)

So if you’re interested in writing mobile applications, but don’t have the time to write the same app over and over again for each platform, this article is for you! Don’t worry if you don’t know C# from a Strawberry Pretzel Salad; I’ve been writing Xamarin apps for over 8 years, and this article is a tour through Xamarin.Forms that intends to give you enough information to start learning on your own.

What Is This Xamarin Stuff?

More than just a fun word to say, Xamarin allows developers to create native iOS and Android applications using the exact same SDKs and UI controls available as in Swift and XCode for iOS or Java and Android Studio for Android.

Front-end is messy and complicated these days. That's why we publish articles, printed books and webinars with useful techniques to improve your work. Even better: Smashing Membership with a growing selection of front-end & UX goodies. So you get your work done, better and faster.

Explore Smashing Membership ↬ Which platform should I develop for? (Large preview)

The difference is that the apps are developed with C# using the .NET Framework and Visual Studio or Visual Studio for Mac. The apps that result, however, are exactly the same. They look, feel, and behave just like native apps written in Objective-C, Swift, or Java.

Xamarin shines when it comes to code sharing. A developer can create and tailor their UI for each platform using native controls and SDKs, but then write a library of shared app logic that’s shared across platforms.

Aha! I’ll pick Xamarin! (Large preview)

It’s this code sharing where tremendous time savings can be realized.

And like the delicious buns my grandma bakes, once given the taste of sharing code — it’s hard not to crave more — and that’s where Xamarin.Forms comes in.

Xamarin.Forms

Xamarin.Forms takes the concept of traditional Xamarin development and adds a layer of abstraction to it.

Instead of developing the user interface for iOS and Android separately, Xamarin.Forms introduces a UI toolkit that enables you to write native mobile apps from a single code base.

Think of it this way: You have an app that needs a button. Each platform has the concept of a button. Why should you have to write the user interface a bunch of different times when you know all the user of your app needs to do is tap a button?

That’s one of the problems Xamarin.Forms solves.

It provides a toolkit of the most commonly used controls and user interaction events for them, so we only have to write the user interfaces for our apps once. It’s worth noting though that you’re not limited to the controls Xamarin.Forms provides either — you still can use controls found in only a single platform within a Xamarin.Forms app. Also, we can share the application logic between platforms as before.

The code sharing stats for apps developed with Xamarin.Forms can be off the charts. A conference organizing app has 93% of its code shared on iOS and 91% on Android. The app is open sourced. Take a peek at the code.

Xamarin.Forms provides more than UI controls. It also contains a MVVM framework, a pub/sub messaging service, an animation API, and a dependency service, plus others.

But today, we’re going to focus on the UI capabilities for building our recipe manager app.

The App We’ll Build

The recipe manager app will have a straightforward user interface. We will be working in the kitchen, so it needs to be easy to use!

It will consist of 3 screens. The first will show a list of all the recipes currently loaded in the app.

(Large preview)

Then, by tapping on one of those recipes, you’ll be able to see its details on a second screen:

The recipe detail screen on iOS (Large preview)

From there you can tap an edit button to make changes to the recipe on the third screen:

The recipe edit screen on iOS (Large preview)

You can also get to this screen by tapping the add button from the recipe list screen.

The Development Environment

Xamarin apps are built with C# and .NET, using Visual Studio on Windows or Visual Studio for Mac on the Mac, but you need to have the iOS or Android SDKs and tooling installed, too. Getting everything installed, in the correct order could be a bit of an issue, however, the Visual Studio installers will take care of note only getting the IDE installed, but also the platform tooling.

Although a Mac is always required to build iOS apps, with Xamarin you can still develop and debug those apps from Visual Studio on Windows! So if Windows is your jam, there’s no need to change your environments altogether.

Now let’s see how Xamarin.Forms can help us save some family recipes from one code base!

Recipe List Page: Laying Out the UI

Let’s start with talking about how we’re going to layout the UI for our recipe saving app!

Overall each screen in Xamarin.Forms is comprised of 3 elements. A Page. At least one element called a Layout. And at least one Control.

The Page

The Page is the thing that hosts everything displayed on the screen at one time. The Page is also central in navigation within an app.

The page (Large preview)

We tell Xamarin.Forms which Page to display via a Navigation Service. That service then will take care of displaying whatever page in a way that’s appropriate and native for the operating system.

In other words, the code to navigate between screens has been abstracted too!

Finally, although not the only way to do it, I code the UI of my Page’s in XAML. (The other way would be to use C#.) XAML is a markup language that describes how a page looks. And for now, suffice it to say, it’s kinda sorta similar to HTML.

The Layout

All the controls on a page are arranged by something called a Layout.

The layouts (Large preview)

One or more layouts can be added to a page.

Layouts on the page (Large preview)

There are several different types of Layouts in Forms. Some of the most common ones include Stack, Absolute, Relative, Grid, Scroll, and Flex layouts.

Common Xamarin.Forms layouts (Large preview)

The Controls

Then finally there are the controls. These are the widgets of your app that the user interacts with.

Some of the controls (Large preview)

Forms come with many controls that will be used no matter what type of app you’re building. Things like labels, buttons, entry boxes, images, and of course, list views.

When adding a control to a screen, you add it to a layout. It’s the layout that takes care of figuring where exactly on the screen the control should appear.

Everything fits together! (Large preview)

So to generate the following screens on iOS and Android respectively:

Recipe lists on iOS (left) and Android (right) (Large preview)

I used this XAML:

<?xml version="1.0" encoding="UTF-8"?> <ContentPage xmlns="http://xamarin.com/schemas/2014/forms" xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml" x:Class="SmashingRecipe.RecipeListPage" Title="Recipes"> <ContentPage.Content> <StackLayout> <ListView x:Name="recipesList"> <ListView.ItemTemplate> <DataTemplate> <TextCell Text="{Binding Name}"/> </DataTemplate> </ListView.ItemTemplate> </ListView> </StackLayout> </ContentPage.Content> <ContentPage.ToolbarItems> <ToolbarItem Text="Add" /> </ContentPage.ToolbarItems> </ContentPage>

There’s a couple of important things going on here.

The first is the <StackLayout>. This is telling Forms to arrange all the controls that follow in a stack.

There happens to only be a single control in the layout, and that’s a <ListView>, and we’re going to give it a name so we can reference it later.

Then there’s a little bit of boilerplate ceremony to the ListView before we get to what we’re after: the <TextCell>. This is telling Forms to display simple text in each cell of the list.

We tell the <TextCell> the text we want it to display through a technique called Data Binding. The syntax looks like Text="{Binding Name}". Where Name is a property of a Recipe class that models… well, Recipes.

So how do the recipes get added to the list?

Along with every XAML file, there is a “code-behind” file. This code-behind allows us to do things like handle user interaction events, or perform setup, or do other app logic.

There’s a function that can be overridden in every Page called OnAppearing — which as I’m sure you guessed — gets called when the Page appears.

protected override void OnAppearing() { base.OnAppearing(); recipesList.ItemsSource = null; recipesList.ItemsSource = App.AllRecipes; }

Notice the recipesList.ItemsSource = AllRecipes;

This is telling the ListView — “Hey! All of your data is found in the enumerable App.AllRecipes (an application-wide variable) and you can use any of its child object’s properties to bind off of!”.

A list of recipes is all well and fine — but you can’t bake anything without first seeing the recipe’s details — and we’re going to take care of that next.

Event Handling

Without responding to user touches our app is nothing more than a list of delicious sounding recipes. They sound good, but without knowing how to cook them, it’s not of much use!

Let’s make each cell in the ListView respond to taps so we can see how to make the recipe!

In the RecipeListPage code-behind file, we can add event handlers to controls to listen and react to user interaction events.

Handling tap events on the list view then:

recipesList.ItemSelected += async (sender, eventArgs) => { if (eventArgs.SelectedItem != null) { var detailPage = new RecipeDetailPage(eventArgs.SelectedItem as Recipe); await Navigation.PushAsync(detailPage); recipesList.SelectedItem = null; } };

There’s some neat stuff going on there.

Whenever somebody selects a row, ItemSelected is fired on the ListView.

Of the arguments that get passed into the handler, the eventArgs object has a SelectedItem property that happens to be whatever is bound to the ListView from before.

In our case, that’s the Recipe class. (So we don’t have to search for the object in the master source - it gets passed to us.)

Recipe Detail Page

Of course, there’s a page that shows us the secret ingredients and directions of how to make each recipe, but how does that page get displayed?

Let’s get cooking! (Large preview)

Notice the await Navigation.PushAsync(detailPage); line from above. The Navigation object is a platform-independent object that handles page transitions in a native fashion for each platform.

Now let’s take a peek at the recipe details page:

Recipe detail screens on iOS (left) and Android (right) (Large preview)

This page is built with XAML as well. However, the Layout used (FlexLayout) is quite cool as it’s inspired by the CSS Flexbox.

<ContentPage.Content> <ScrollView> <FlexLayout AlignItems="Start" AlignContent="Start" Wrap="Wrap"> <Image Source="buns.png" FlexLayout.Basis="100%" /> <Label Text="{Binding Name}" HorizontalTextAlignment="Center" TextColor="#01487E" FontAttributes="Bold" FontSize="Large" Margin="10, 10" /> <BoxView FlexLayout.Basis="100%" HeightRequest="0" /> <Label Text="Ingredients" FontAttributes="Bold" FontSize="Medium" TextColor="#EE3F60" Margin="10,10" HorizontalOptions="FillAndExpand" /> <BoxView FlexLayout.Basis="100%" HeightRequest="0" /> <Label Text="{Binding Ingredients}" Margin="10,10" FontSize="Small" /> <BoxView FlexLayout.Basis="100%" HeightRequest="0" /> <Label Text="Directions" FontAttributes="Bold" FontSize="Medium" TextColor="#EE3F60" Margin="10,10" HorizontalOptions="FillAndExpand" /> <BoxView FlexLayout.Basis="100%" HeightRequest="0" /> <Label Text="{Binding Directions}" Margin="10,10" FontSize="Small" /> </FlexLayout> </ScrollView> </ContentPage.Content>

The FlexLayout will arrange its controls in either rows or columns. The big benefit comes though with the fact that it can automatically detect how much room there is left on the screen to place a control, and if there’s not enough, then it can automatically create a new row or column to accommodate it!

This helps greatly when dealing with various screen sizes, which there are plenty of in mobile development.

Well, with the FlexLayout helping us keep the details screen looking good, we still need to edit those recipes, right?

You probably noticed this:

<ToolbarItem Text="Edit" Clicked="Edit_Clicked" />

That line is responsible for putting a button in the app’s toolbar. The Clicked="Edit_Clicked" tells the button that when it’s clicked, look in the code behind for a function of that name, and then execute its code.

Which in this case, would be instantiating the Recipe Edit Page, and pushing that onto our navigation stack using the Navigation object mentioned previously.

Recipe Edit Page

A page with a list of recipes: check! A page with all the details to make the recipes: check! All that’s now left is to create the page that we use to enter or change a recipe while we watch grandma work her magic!

First, check out the screens:

Recipe edit screens on iOS (left) and Android (right) (Large preview)

And now the code:

<ContentPage.Content> <Grid> <Grid.RowDefinitions> <RowDefinition Height="*" /> <RowDefinition Height="Auto" /> </Grid.RowDefinitions> <Grid.ColumnDefinitions> <ColumnDefinition Width="*" /> <ColumnDefinition Width="*" /> </Grid.ColumnDefinitions> <TableView Grid.Row="0" Grid.Column="0" Grid.ColumnSpan="2" Intent="Form" HasUnevenRows="true"> <TableSection Title="General"> <EntryCell x:Name="recipeNameCell" Label="Name" /> </TableSection> <TableSection Title="Ingredients"> <ViewCell> <StackLayout Padding="15"> <Editor x:Name="ingredientsCell" /> </StackLayout> </ViewCell> </TableSection> <TableSection Title="Directions"> <ViewCell> <StackLayout Padding="15"> <Editor x:Name="directionsCell" /> </StackLayout> </ViewCell> </TableSection> </TableView> <Button Text="Save" Grid.Row="1" Grid.Column="0" BackgroundColor="#EE3F60" TextColor="White" x:Name="saveButton" /> <Button Text="Cancel" Grid.Row="1" Grid.Column="1" BackgroundColor="#4CC7F2" TextColor="White" x:Name="cancelButton" /> </Grid> </ContentPage.Content>

There’s a little more code here, and that’s because I’m using the Grid layout to specify how everything should lay out in a 2-Dimensional pattern.

And also notice no data binding here. Because I wanted to give an example of how one would populate the controls purely from the code behind file:

void InitializePage() { Title = TheRecipe.Name ?? "New Recipe"; recipeNameCell.Text = TheRecipe.Name; ingredientsCell.Text = TheRecipe.Ingredients; directionsCell.Text = TheRecipe.Directions; saveButton.Clicked += async (sender, args) => { SaveRecipe(); await CloseWindow(); }; cancelButton.Clicked += async (sender, args) => { await CloseWindow(); }; }

See that TheRecipe property? It’s page level, holds all the data for a particular recipe, and gets set in the constructor of the page.

Secondly, the Clicked event handlers for the saveButton and cancelButton are totally .NET-ified (and yes, I do make my own words up quite often.)

I say they’re .NET-ified because the syntax to handle that event is not native to Java nor Objective-C. When the app runs on Android or iOS, the behavior will be exactly like an Android Click or an iOS TouchUpInside.

And as you can see, each of those click event handlers are invoking appropriate functions that either save the recipe and dismiss the page, or only dismiss the page.

There it is — we have the UI down to save the recipes from now until the end of time!

CSS Wha?!? Or Making The App Pretty

Saving the best for last: Xamarin.Forms 3.0 gives us — among other things — the ability to style controls using CSS!

The Xamarin.Forms CSS isn’t 100% what you may be used to from web development. But it’s close enough that anyone familiar with CSS will feel right at home. Just like me at grandma’s!

So let’s take the Recipe Details page and refactor it, so it uses Cascading Style Sheets to set the visual elements instead of setting everything directly inline in the XAML.

First step is to create the CSS doc! In this case it will look like the following:

.flexContent { align-items: flex-start; align-content: flex-start; flex-wrap: wrap; } image { flex-basis: 100%; } .spacer { flex-basis: 100%; height: 0; } .foodHeader { font-size: large; font-weight: bold; color: #01487E; margin: 10 10; } .dataLabel { font-size: medium; font-weight: bold; color: #EE3F60; margin: 10 10; } .data { font-size: small; margin: 10 10; }

For the most part, it looks like CSS. There are classes in there. There is a single selector for a class type, Image. And then a bunch of property setters.

Some of those property setters, such as flex-wrap or flex-basis are specific to Xamarin.Forms. Going forward, the team will prefix those with xf- to follow standard practices.

Next up will be to apply it to XAML controls.

<ContentPage.Resources> <StyleSheet Source="../Styles/RecipeDetailStyle.css" /> </ContentPage.Resources> <ContentPage.Content> <ScrollView> <FlexLayout StyleClass="flexContent"> <Image Source="buns.png" /> <Label Text="{Binding Name}" StyleClass="foodHeader" /> <BoxView StyleClass="spacer" /> <Label Text="Ingredients" StyleClass="dataLabel" HorizontalOptions="FillAndExpand" /> <BoxView StyleClass="spacer" /> <Label Text="{Binding Ingredients}" StyleClass="data" /> <BoxView StyleClass="spacer" /> <Label Text="Directions" StyleClass="dataLabel" HorizontalOptions="FillAndExpand" /> <BoxView StyleClass="spacer" /> <Label Text="{Binding Directions}" StyleClass="data" /> </FlexLayout> </ScrollView> </ContentPage.Content>

Here’s what it looked like before.

In Xamarin.Forms, to reference the CSS document, add a <StyleSheet Source="YOUR DOC PATH" />. Then you can reference the classes in each control via the StyleClass property.

It definitely cleans up the XAML, and it makes the intention of the control clearer too. For example, now it’s pretty obvious what those <BoxView StyleClass="spacer" /> are up to!

And the Image gets itself styled all because it’s an Image and the way we defined the selector in the CSS.

To be sure, CSS in Xamarin.Forms isn’t as fully implemented as its web cousin, but it’s still pretty cool. You have selectors, classes, can set properties and, of course, that whole cascading thing going on!

Summary

Three screens, two platforms, one article, and endless recipes saved! And you know what else? You can build apps with Xamarin.Forms for more than Android and iOS. You can build UWP, macOS, and even Samsung Tizen platforms!

Delicious! (Large preview)

Xamarin.Forms is a UI toolkit that allows you to create apps by writing the user interface once and having the UI rendered natively across the major platforms.

It does this by providing an SDK that’s an abstraction to the most commonly used controls across the platforms. In addition to the UI goodness, Xamarin.Forms also provides a full-featured MVVM framework, a pub/sub messaging service, an animation API, and a dependency service.

Xamarin.Forms also gives you all the same code benefits that traditional Xamarin development does. Any application logic is shared across all the platforms. And you get to develop all your apps with a single IDE using a single language — that’s pretty cool!

Where to next? Download the source code for this Xamarin.Forms app to give it a spin yourself. Then to learn more about Xamarin.Forms, including the ability to create an app all within your browser, check out this online tutorial!

(dm, ra, yk, il)
Categories: Around The Web

Meet “Form Design Patterns,” Our New Book On Accessible Web Forms — Now Shipping!

Wed, 10/10/2018 - 7:45am
Meet “Form Design Patterns,” Our New Book On Accessible Web Forms — Now Shipping! Meet “Form Design Patterns,” Our New Book On Accessible Web Forms — Now Shipping! Markus Seyfferth 2018-10-10T13:45:00+02:00 2018-10-21T14:20:03+00:00

Forms. It’s no coincidence that the word rhymes with “yawns” — web forms are dull to code and even duller for your visitors to fill in. But without forms, the web would just be a library. They let us comment, collect, book, buy, share, and a host of other verbs. And mostly they enable us to do these things in an awkward, opaque, confusing, odd, frustrating, alarming, or alienating way. Forms are such an important part of the web, but we design them poorly all the time. When they’re not over-engineered they’re usually not engineered at all.

With the new Form Design Patterns book we want to tackle this problem. By going through common real-world problems step by step, you’ll learn how to design simple, robust, lightweight, responsive, accessible, progressively enhanced, interoperable and intuitive forms that let users get stuff done no matter what. And by the end of the book you’ll have a close-to exhaustive list of components delivered as a design system that you can use immediately in your own projects. (Jump to table of contents.)

  • eBook
  • Hardcover
eBook$19 Get the eBook

PDF, ePUB, Kindle. Free for Smashing Members.

Hardcover$39 Get the Print (incl. eBook)

Printed, quality hardcover. Free airmail shipping worldwide.

About The Book *Form Design Patterns* contains ten chapters ([↓ Table of Contents](#toc)). Each one represents a common real-world problem that we’ll solve together step by step. Design is just as much about asking (and understanding) questions, as it is about creating solutions. So we’ll spend time doing just that: discussing the problem, weighing up the options, and **creating technical solutions that are simple and inclusive**. Ultimately, the book is about understanding what users need. Users are people and people are different. So we’ll be considering multiple interaction modalities and how to help users work under situational (temporary or permanent) and environmental circumstances. We’ll be looking at every problem through an inclusive design lens. Because good design is inclusive. --> Table Of Contents

Each chapter revolves around a specific problem — after all, that’s how we solve problems in real life. But don’t be concerned, many of the styles, components and patterns born out of each chapter are reusable and applicable well beyond the specifics and you’ll see examples of this as we move through the book.

Download the PDF excerpt for free (0.7 MB) to get a feeling what the book is like inside.

  1. A Registration Form
    We’ll start looking at the foundational qualities of a well-designed form and how to think about them. By applying something called a question protocol, we’ll look at how to reduce friction without even touching the interface. Then we’ll look at some crucial patterns, including validation, that we’ll want to use for every form.
  2. A Checkout Form
    We’ll consider checkout flows and look at several input types and how they affect the user experience on mobile and desktop browsers, all the while looking at ways to help both first-time and returning customers order quickly and simply.
  3. A Flight Booking Form
    We’ll dive into the world of progressively enhanced, custom form components using ARIA. We’ll do this by exploring the best way to let users select destinations, pick dates, add passengers, and choose seats. We’ll analyze native form controls, and look at breaking away from convention when it becomes necessary.
  4. A Login Form
    We’ll look at the ubiquitous login form. Despite its simple appearance, there’s a bunch of usability failures that so many sites suffer from.
  5. An Inbox
    We’ll design ways to manage email in bulk, our first look at administrative interfaces. As such, this comes with its own set of challenges and patterns, including a responsive ARIA-described action menu, multiple selection, and same-page messaging.
  6. A Search Form
    We’ll create a responsive search form that is readily available to users on all pages, and we’ll also consider the importance of the search mechanism that powers it.
  7. A Filter Form
    Users often need to filter a large set of unwieldy search results. Without a well-designed filter, users are bound to give up. Filters pose a number of interesting and unique design problems that may force us to challenge best practice to give users a better experience.
  8. An Upload Form
    Many services, like photo sharing, messaging, and many back-office applications, let users upload images and documents. We’ll study the file input and how we can use it to upload multiple files at once. Then we’ll look at the intricacies of a drag-and-drop, Ajax-enhanced interface that is inclusive of keyboard and screen reader users.
  9. An Expense Form
    We’ll investigate the special problem of needing to create and add lots of expenses (or anything else) into a system. This is really an excuse to cover the add another pattern, which is often useful in administrative interfaces.
  10. A Really Long and Complicated Form
    Some forms are very long and take hours to complete. We’ll look at some of the patterns we can use to make long forms easier to manage.
About The Author

Adam Silver is an interaction designer with over 15 years experience working on the web for a range of companies including Tesco, BBC, Just Eat, Financial Times, the Department for Work and Pensions and others.

He’s particularly interested in inclusive design and design systems and writes about this on his blog and popular design publications such as A List Apart. This isn’t his first book either: he previously wrote Maintainable CSS, a book about crafting maintainable UIs with CSS.

Technical Details
  • 384 pages, 14 × 21 cm (5.5 × 8.25 inches),
  • ISBN: 978-3-945749-73-9 (print),
  • Quality hardcover with stitched binding and a ribbon page marker,
  • The eBook is available in PDF, EPUB, and Amazon Kindle.
  • Free worldwide airmail shipping from Germany. Delivery times.
  • Available as printed, quality hardcover and eBook.
Testimonials

It has been our goal to make the book as practical and useful as possible. We’ve been honored to receive very positive reviews from people making websites on small and large scale.

  • “I have been writing forms in HTML for over 20 years. This book captures the essence of what it is to embrace standards, progressively enhance and deliver simple, accessible forms. By formalising design patterns we can all use and implement, developers and designers can focus on their website and product. I wish this was available 20 years ago!”
    — Paul Duncan, Design Technologists and Accessibility Teacher
  • “In a world of horribly marked up forms, this book is a beacon of light illuminating the way to more accessible user experiences. I highly recommend it to anyone designing or developing user interfaces to avoid the common form accessibility pitfalls we see all too often.”
    — Marcy Sutton, Accessibility Advocate
  • “Forms. It’s no coincidence that the word rhymes with “yawns” - forms are dull to code and even duller for your visitors to fill in. So make them work better for everyone, using the concrete tips, code and microcopy in this book. And take away your own yawns, as Adam Silver has done all the research and coding for you.”
    — Bruce Lawson, Web standards Advocate
  • “Form Design Patterns is setting out common sense and inclusive solutions for forms both simple and potentially complex. It’s your companion as you strive to create a simpler and easier interactive web.”
    — Heydon Pickering, UX and accessibility consultant
Why This Book Is For You

This book is a practical guide for anyone who needs to design, prototype and build all sorts of forms for digital services, products and websites. You’ll learn:

  1. Available native form elements and their powers, limitations and constraints.
  2. When and how to create accessible custom form components that can give users a better experience in comparison to their native equivalents.
  3. How to significantly reduce friction in forms with careful use of language, flow and order.
  4. Ways (and ways not) to help users fix form errors easily.
  5. How to deal with complex interfaces that let users upload files and add multiple items of any sort.
  6. Ways to let users search and filter a large set of results according to their own mental model.
  7. How to help customers fill out especially long and complex forms that may take weeks to fill out.
Form Design Patterns is a practical guide for anyone who needs to design, prototype and build all sorts of forms for digital services, products and websites. (View large image)
  • eBook
  • Hardcover
eBook$19 Get the eBook

PDF, ePUB, Kindle. Free for Smashing Members.

Hardcover$39 Get the Print (incl. eBook)

Printed, quality hardcover. Free airmail shipping worldwide.

We can’t wait to hear your thoughts about the book! Happy reading, and we hope that you’ll find the book as useful as we do. Just have a cup of coffee (or tea) ready before you start reading, of course. Stay smashing and... meow!

(bl, hp)
Categories: Around The Web

Form Design Patterns Book Excerpt: A Registration Form

Wed, 10/10/2018 - 6:25am
Form Design Patterns Book Excerpt: A Registration Form Form Design Patterns Book Excerpt: A Registration Form Adam Silver 2018-10-10T12:25:00+02:00 2018-10-21T14:20:03+00:00

Let’s start with a registration form. Most companies want long-term relationships with their users. To do that they need users to sign up. And to do that, they need to give users value in return. Nobody wants to sign up to your service — they just want to access whatever it is you offer, or the promise of a faster experience next time they visit.

Despite the registration form’s basic appearance, there are many things to consider: the primitive elements that make up a form (labels, buttons, and inputs), ways to reduce effort (even on small forms like this), all the way through to form validation.

In choosing such a simple form, we can zoom in on the foundational qualities found in well-designed forms.

How It Might Look

The form is made up of four fields and a submit button. Each field is made up of a control (the input) and its associated label.

Registration form with four fields: first name, last name, email address, and password.

Here’s the HTML:

<form> <label for="firstName">First name</label> <input type="text" id="firstName" name="firstName"> <label for="lastName">Last name</label> <input type="text" id="lastName" name="lastName"> <label for="email">Email address</label> <input type="email" id="email" name="email"> <label for="password">Create password</label> <input type="password" id="password" name="password" placeholder="Must be at least 8 characters"> <input type="submit" value="Register"> </form>

Labels are where our discussion begins.

Labels

In Accessibility For Everyone, Laura Kalbag sets out four broad parameters that improve the user experience for everyone:

  • Visual: make it easy to see.
  • Auditory: make it easy to hear.
  • Motor: make it easy to interact with.
  • Cognitive: make it easy to understand.

By looking at labels from each of these standpoints, we can see just how important labels are. Sighted users can read them, visually-impaired users can hear them by using a screen reader, and motor-impaired users can more easily set focus to the field thanks to the larger hit area. That’s because clicking a label sets focus to the associated form element.

The label increases the hit area of the field.

For these reasons, every control that accepts input should have an auxiliary <label>. Submit buttons don’t accept input, so they don’t need an auxiliary label — the value attribute, which renders the text inside the button, acts as the accessible label.

To connect an input to a label, the input’s id and label’s for attribute should match and be unique to the page. In the case of the email field, the value is “email”:

html <label for="email">Email address</label> <input id="email">

Failing to include a label means ignoring the needs of many users, including those with physical and cognitive impairments. By focusing on the recognized barriers to people with disabilities, we can make our forms easier and more robust for everyone.

For example, a larger hit area is crucial for motor-impaired users, but is easier to hit for those without impairments too.

Placeholders

The placeholder attribute is intended to store a hint. It gives users extra guidance when filling out a field — particularly useful for fields that have complex rules such as a password field.

As placeholder text is not a real value, it’s grayed out so that it can be differentiated from user-entered values.

The placeholder’s low-contrast, gray text is hard to read.

Unlike labels, hints are optional and shouldn’t be used as a matter of course. Just because the placeholder attribute exists doesn’t mean we have to use it. You don’t need a placeholder of “Enter your first name” when the label is “First name” — that’s needless duplication.

The label and placeholder text have similar content, making the placeholder unnecessary.

Placeholders are appealing because of their minimal, space-saving aesthetic. This is because placeholder text is placed inside the field. But this is a problematic way to give users a hint.

First, they disappear when the user types. Disappearing text is hard to remember, which can cause errors if, for example, the user forgets to satisfy one of the password rules. Users often mistake placeholder text for a value, causing the field to be skipped, which again would cause errors later on. Gray-on-white text lacks sufficient contrast, making it generally hard-to-read. And to top it off, some browsers don’t support placeholders, some screen readers don’t announce them, and long hint text may get cut off.

The placeholder text is cut off as it’s wider than the text box.

That’s a lot of problems for what is essentially just text. All content, especially a form hint, shouldn’t be considered as nice to have. So instead of using placeholders, it’s better to position hint text above the control like this:

Hint text placed above the text box instead of placeholder text inside it.<div class="field"> <label for="password"> <span class="field-label">Password</span> <span class="field-hint">Must contain 8+ characters with at least 1 number and 1 uppercase letter.</span> </label> <input type="password" id="password" name="password"> </div>

The hint is placed within the label and inside a <span> so it can be styled differently. By placing it inside the label it will be read out by screen readers, and further enlarges the hit area.

As with most things in design, this isn’t the only way to achieve this functionality. We could use ARIA attributes to associate the hint with the input:

<div class="field"> <label for="password">Password</label> <p class="field-hint" id="passwordhint">Must contain 8+ characters with at least 1 number and 1 uppercase letter.</p> <input type="password" id="password" name="password" aria-describedby="passwordhint"> </div>

The aria-describedby attribute is used to connect the hint by its id — just like the for attribute for labels, but in reverse. It’s appended to the control’s label and read out after a short pause. In this example, “password [pause] must contain eight plus characters with at least one number and one uppercase letter.”

There are other differences too. First, clicking the hint (a <p> in this case) won’t focus the control, which reduces the hit area. Second, despite ARIA’s growing support, it’s never going to be as well supported as native elements. In this particular case, Internet Explorer 11 doesn’t support aria-describedby. This is why the first rule of ARIA is not to use ARIA:

“If you can use a native HTML element or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.”

Float Labels

The float label pattern by Matt Smith is a technique that uses the label as a placeholder. The label starts inside the control, but floats above the control as the user types, hence the name. This technique is often lauded for its quirky, minimalist, and space-saving qualities.

The float label pattern. On the left, an unfocused text field shows the label inside; on the right, when the text field receives focus, the label moves above the field.

Unfortunately, there are several problems with this approach. First, there is no space for a hint because the label and hint are one and the same. Second, they’re hard to read, due to their poor contrast and small text, as they’re typically designed. (Lower contrast is necessary so that users have a chance to differentiate between a real value and a placeholder.) Third, like placeholders, they may be mistaken for a value and could get cropped.

And float labels don’t actually save space. The label needs space to move into in the first place. Even if they did save space, that’s hardly a good reason to diminish the usability of forms.

“Seems like a lot of effort when you could simply put labels above inputs & get all the benefits/none of the issues.”
Luke Wroblewski on float labels

Quirky and minimalist interfaces don’t make users feel awesome — obvious, inclusive, and robust interfaces do. Artificially reducing the height of forms like this is both uncompelling and problematic.

Instead, you should prioritize making room for an ever-present, readily available label (and hint if necessary) at the start of the design process. This way you won’t have to squeeze content into a small space.

We’ll be discussing several, less artificial techniques to reduce the size of forms shortly.

The Question Protocol

One powerful and natural way to reduce the size of a form is to use a question protocol. It helps ensure you know why you are asking every question or including a form field.

Does the registration form need to collect first name, last name, email address and password? Are there better or alternative ways to ask for this information that simplify the experience?

In all likelihood, you don’t need to ask for the user’s first and last name for them to register. If you need that information later, for whatever reason, ask for it then. By removing these fields, we can halve the size of the form. All without resorting to novel and problematic patterns.

No Password Sign-In

One way to avoid asking users for a password is to use the no password sign-in pattern. It works by making use of the security of email (which already needs a password). Users enter only their email address, and the service sends a special link to their inbox. Following it logs the user into the service immediately.

Medium’s passwordless sign-in screen.

Not only does this reduce the size of the form to just one field, but it also saves users having to remember another password. While this simplifies the form in isolation, in other ways it adds some extra complexity for the user.

First, users might be less familiar with this approach, and many people are worried about online security. Second, having to move away from the app to your email account is long-winded, especially for users who know their password, or use a password manager.

It’s not that one technique is always better than the other. It’s that a question protocol urges us to think about this as part of the design process. Otherwise, you’d mindlessly add a password field on the form and be done with it.

Passphrases

Passwords are generally short, hard to remember, and easy to crack. Users often have to create a password of more than eight characters, made up of at least one uppercase and one lowercase letter, and a number. This micro-interaction is hardly ideal.

“Sorry but your password must contain an uppercase letter, a number, a haiku, a gang sign, a hieroglyph, and the blood of a virgin.”
— Anonymous internet meme

Instead of a password, we could ask users for a passphrase. A passphrase is a series of words such as “monkeysinmygarden” (sorry, that’s the first thing that comes to mind). They are generally easier to remember than passwords, and they are more secure owing to their length — passphrases must be at least 16 characters long.

The downside is that passphrases are less commonly used and, therefore, unfamiliar. This may cause anxiety for users who are already worried about online security.

Whether it’s the no password sign-in pattern or passphrases, we should only move away from convention once we’ve conducted thorough and diverse user research. You don’t want to exchange one set of problems for another unknowingly.

Field Styling

The way you style your form components will, at least in part, be determined by your product or company’s brand. Still, label position and focus styles are important considerations.

Label Position

Matteo Penzo’s eye-tracking tests showed that positioning the label above (as opposed to beside) the form control works best.

“Placing a label right over its input field permitted users to capture both elements with a single eye movement.”

But there are other reasons to put the label above the field. On small viewports there’s no room beside the control. And on large viewports, zooming in increases the chance of the text disappearing off screen.

Also, some labels contain a lot of text, which causes it to wrap onto multiple lines, which would disrupt the visual rhythm if placed next to the control.

While you should aim to keep labels terse, it’s not always possible. Using a pattern that accommodates varying content — by positioning labels above the control — is a good strategy.

Look, Size, and Space

Form fields should look like form fields. But what does that mean exactly?

It means that a text box should look like a text box. Empty boxes signify “fill me in” by virtue of being empty, like a coloring-in book. This happens to be part of the reason placeholders are unhelpful. They remove the perceived affordance an empty text box would otherwise provide.

This also means that the empty space should be boxed in (bordered). Removing the border, or having only a bottom border, for example, removes the perceived affordances. A bottom border might at first appear to be a separator. Even if you know you have to fill something in, does the value go above the line or below it?

Spatially, the label should be closest to its form control, not the previous field’s control. Things that appear close together suggest they belong together. Having equal spacing might improve aesthetics, but it would be at the cost of usability.

Finally, the label and the text box itself should be large enough to read and tap. This probably means a font size of at least 16 pixels, and ideally an overall tap target of at least 44px.

Focus Styles

Focus styles are a simpler prospect. By default, browsers put an outline around the element in focus so users, especially those who use a keyboard, know where they are. The problem with the default styling is that it is often faint and hard to see, and somewhat ugly.

While this is the case, don’t be tempted to remove it, because doing so will diminish the user experience greatly for those traversing the screen by keyboard. We can override the default styling to make it clearer and more aesthetically pleasing.

input:focus { outline: 4px solid #ffbf47; } The Email Field

Despite its simple appearance there are some important details that have gone into the field’s construction which affect the experience.

The email field.

As noted earlier, some fields have a hint in addition to the label, which is why the label is inside a child span. The field-label class lets us style it through CSS.

<div class="field"> <label for="email"> <span class="field-label">Email address</span> </label> <input type="email" id="email" name="email"> </div>

The label itself is “Email address” and uses sentence case. In “Making a case for letter case,” John Saito explains that sentence case (as opposed to title case) is generally easier to read, friendlier, and makes it easier to spot nouns. Whether you heed this advice is up to you, but whatever style you choose, be sure to use it consistently.

The input’s type attribute is set to email, which triggers an email-specific onscreen keyboard on mobile devices. This gives users easy access to the @ and . (dot) symbols which every email address must contain.

Android’s onscreen keyboard for the email field.

People using a non-supporting browser will see a standard text input (<input type="text">). This is a form of progressive enhancement, which is a cornerstone of designing inclusive experiences.

Progressive Enhancement

Progressive enhancement is about users. It just happens to make our lives as designers and developers easier too. Instead of keeping up with a set of browsers and devices (which is impossible!) we can just focus on features.

First and foremost, progressive enhancement is about always giving users a reasonable experience, no matter their browser, device, or quality of connection. When things go wrong — and they will — users won’t suffer in that they can still get things done.

There are a lot of ways an experience can go wrong. Perhaps the style sheet or script fails to load. Maybe everything loads, but the user’s browser doesn’t recognize some HTML, CSS, or JavaScript. Whatever happens, using progressive enhancement when designing experiences stops users having an especially bad time.

It starts with HTML for structure and content. If CSS or JavaScript don’t load, it’s fine because the content is there.

If everything loads OK, perhaps various HTML elements aren’t recognized. For example, some browsers don’t understand <input type="email">. That’s fine, though, because users will get a text box (<input type="text">) instead. Users can still enter an email address; they just don’t get an email-specific keyboard on mobile.

Maybe the browser doesn’t understand some fancy CSS, and it will just ignore it. In most cases, this isn’t a problem. Let’s say you have a button with border-radius: 10px. Browsers that don’t recognize this rule will show a button with angled corners. Arguably, the button’s perceived affordance is reduced, but users are left unharmed. In other cases it might be helpful to use feature queries.

Then there is JavaScript, which is more complicated. When the browser tries to parse methods it doesn’t recognize, it will throw a hissy fit. This can cause your other (valid and supported) scripts to fail. If your script doesn’t first check that the methods exist (feature detection) and work (feature testing) before using them, then users may get a broken interface. For example, if a button’s click handler calls a method that’s not recognized, the button won’t work. That’s bad.

That’s how you enhance. But what’s better is not needing an enhancement at all. HTML with a little CSS can give users an excellent experience. It’s the content that counts and you don’t need JavaScript for that. The more you can rely on content (HTML) and style (CSS), the better. I can’t emphasize this enough: so often, the basic experience is the best and most performant one. There’s no point in enhancing something if it doesn’t add value (see inclusive design principle 7).

Of course, there are times when the basic experience isn’t as good as it could be — that’s when it’s time to enhance. But if we follow the approach above, when a piece of CSS or JavaScript isn’t recognized or executed, things will still work.

Progressive enhancement makes us think about what happens when things fail. It allows us to build experiences with resilience baked in. But equally, it makes us think about whether an enhancement is needed at all; and if it is, how best to go about it.

The Password Field

We’re using the same markup as the email field discussed earlier. If you’re using a template language, you’ll be able to create a component that accommodates both types of field. This helps to enforce inclusive design principle 3, be consistent.

The password field using the hint text pattern. <div class="field"> <label for="password"> <span class="field-label">Choose password</span> <span class="field-hint">Must contain 8+ characters with at least 1 number and 1 uppercase letter.</span> </label> <input type="password" id="password" name="password"> </div>

The password field contains a hint. Without one, users won’t understand the requirements, which is likely to cause an error once they try to proceed.

The type="password" attribute masks the input’s value by replacing what the user types with small black dots. This is a security measure that stops people seeing what you typed if they happen to be close by.

A Password Reveal

Obscuring the value as the user types makes it hard to fix typos. So when one is made, it’s often easier to delete the whole entry and start again. This is frustrating as most users aren’t using a computer with a person looking over their shoulder.

Owing to the increased risk of typos, some registration forms include an additional “Confirm password” field. This is a precautionary measure that requires the user to type the same password twice, doubling the effort and degrading the user experience. Instead, it’s better to let users reveal their password, which speaks to principles 4 and 5, give control and offer choice respectively. This way users can choose to reveal their password when they know nobody is looking, reducing the risk of typos.

Recent versions of Internet Explorer and Microsoft Edge provide this behavior natively. As we’ll be creating our own solution, we should suppress this feature using CSS like this:

input[type=password]::-ms-reveal { display: none; } The password field with a “Show password” button beside it.

First, we need to inject a button next to the input. The <button> element should be your go-to element for changing anything with JavaScript — except, that is, for changing location, which is what links are for. When clicked, it should toggle the type attribute between password and text; and the button’s label between “Show” and “Hide.”

function PasswordReveal(input) { // store input as a property of the instance // so that it can be referenced in methods // on the prototype this.input = input; this.createButton(); }; PasswordReveal.prototype.createButton = function() { // create a button this.button = $('<button type="button">Show password</button>'); // inject button $(this.input).parent().append(this.button); // listen to the button’s click event this.button.on('click', $.proxy(this, 'onButtonClick')); }; PasswordReveal.prototype.onButtonClick = function(e) { // Toggle input type and button text if(this.input.type === 'password') { this.input.type = 'text'; this.button.text('Hide password'); } else { this.input.type = 'password'; this.button.text('Show password'); } }; JavaScript Syntax and Architectural Notes

As there are many flavors of JavaScript, and different ways in which to architect components, we’re going to walk through the choices used to construct the password reveal component, and all the upcoming components in the book.

First, we’re using a constructor. A constructor is a function conventionally written in upper camel case — PasswordReveal, not passwordReveal. It’s initialized using the new keyword, which lets us use the same code to create several instances of the component:

var passwordReveal1 = new PasswordReveal(document.getElementById('input1')); var passwordReveal2 = new PasswordReveal(document.getElementById('input2'));

Second, the component’s methods are defined on the prototype — for example, PasswordReveal.prototype.onButtonClick. The prototype is the most performant way to share methods across multiple instances of the same component.

Third, jQuery is being used to create and retrieve elements, and listen to events. While jQuery may not be necessary or preferred, using it means that this book can focus on forms and not on the complexities of cross-browser components.

If you’re a designer who codes a little bit, then jQuery’s ubiquity and low-barrier to entry should be helpful. By the same token, if you prefer not to use jQuery, you’ll have no trouble refactoring the components to suit your preference.

You may have also noticed the use of the $.proxy function. This is jQuery’s implementation of Function.prototype.bind. If we didn’t use this function to listen to events, then the event handler would be called in the element’s context (this). In the example above, this.button would be undefined. But we want this to be the password reveal object instead, so that we can access its properties and methods.

Alternative Interface Options

The password reveal interface we constructed above toggles the button’s label between “Show password” and “Hide password.” Some screen reader users can get confused when the button’s label is changed; once a user encounters a button, they expect that button to persist. Even though the button is persistent, changing the label makes it appear not to be.

If your research shows this to be a problem, you could try two alternative approaches.

First, use a checkbox with a persistent label of “Show password.” The state will be signaled by the checked attribute. Screen reader users will hear “Show password, checkbox, checked” (or similar). Sighted users will see the checkbox tick mark. The problem with this approach is that checkboxes are for inputting data, not controlling the interface. Some users might think their password will be revealed to the system.

Or, second, change the button’s state — not the label. To convey the state to screen reader users, you can switch the aria-pressed attribute between true (pressed) and false (unpressed).

<button type="button" aria-pressed="true"> Show password </button>

When focusing the button, screen readers will announce, “Show password, toggle button, pressed” (or similar). For sighted users, you can style the button to look pressed or unpressed accordingly using the attribute selector like this:

[aria-pressed="true"] { box-shadow: inset 0 0 0 0.15rem #000, inset 0.25em 0.25em 0 #fff; }

Just be sure that the unpressed and pressed styles are obvious and differentiated, otherwise sighted users may struggle to tell the difference between them.

Microcopy

The label is set to “Choose password” rather than “Password.” The latter is somewhat confusing and could prompt the user to type a password they already possess, which could be a security issue. More subtly, it might suggest the user is already registered, causing users with cognitive impairments to think they are logging in instead.

Where “Password” is ambiguous, “Choose password” provides clarity.

Button Styles

What’s a button? We refer to many different types of components on a web page as a button. In fact, I’ve already covered two different types of button without calling them out. Let’s do that now.

Buttons that submit forms are “submit buttons” and they are coded typically as either <input type="submit"> or <button type="submit">. The <button> element is more malleable in that you can nest other elements inside it. But there’s rarely a need for that. Most submit buttons contain just text.

Note: In older versions of Internet Explorer, if you have multiple <button type="submit">s, the form will submit the value of all the buttons to the server, regardless of which was clicked. You’ll need to know which button was clicked so you can determine the right course of action to take, which is why this element should be avoided.

Other buttons are injected into the interface to enhance the experience with JavaScript — much like we did with the password reveal component discussed earlier. That was also a <button> but its type was set to button (not submit).

In both cases, the first thing to know about buttons is that they aren’t links. Links are typically underlined (by user agent styles) or specially positioned (in a navigation bar) so they are distinguishable among regular text. When hovering over a link, the cursor will change to a pointer. This is because, unlike buttons, links have weak perceived affordance.

In Resilient Web Design, Jeremy Keith discusses the idea of material honesty. He says: “One material should not be used as a substitute for another. Otherwise the end result is deceptive.” Making a link look like a button is materially dishonest. It tells users that links and buttons are the same when they’re not.

Links can do things buttons can’t do. Links can be opened in a new tab or bookmarked for later, for example. Therefore, buttons shouldn’t look like links, nor should they have a pointer cursor. Instead, we should make buttons look like buttons, which have naturally strong perceived affordance. Whether they have rounded corners, drop shadows, and borders is up to you, but they should look like buttons regardless.

Buttons can still give feedback on hover (and on focus) by changing the background colour, for example.

Placement

Submit buttons are typically placed at the bottom of the form: with most forms, users fill out the fields from top to bottom, and then submit. But should the button be aligned left, right or center? To answer this question, we need to think about where users will naturally look for it.

Field labels and form controls are aligned left (in left-to-right reading languages) and run from top to bottom. Users are going to look for the next field below the last one. Naturally, then, the submit button should also be positioned in that location: to the left and directly below the last field. This also helps users who zoom in, as a right-aligned button could more easily disappear off-screen.

Text

The button’s text is just as important as its styling. The text should explicitly describe the action being taken. And because it’s an action, it should be a verb. We should aim to use as few words as possible because it’s quicker to read. But we shouldn’t remove words at the cost of clarity.

The exact words can match your brand’s tone of voice, but don’t exchange clarity for quirkiness.

Simple and plain language is easy for everyone to understand. The exact words will depend on the type of service. For our registration form “Register” is fine, but depending on your service “Join” or “Sign up” might be more appropriate.

Validation

Despite our efforts to create an inclusive, simple, and friction-free registration experience, we can’t eliminate human error. People make mistakes and when they do, we should make fixing them as easy as possible.

When it comes to form validation, there are a number of important details to consider. From choosing when to give feedback, through to how to display that feedback, down to the formulation of a good error message — all of these things need to be taken into account.

HTML5 Validation

HTML5 validation has been around for a while now. By adding just a few HTML attributes, supporting browsers will mark erroneous fields when the form is submitted. Non-supporting browsers fall back to server-side validation.

Normally I would recommend using functionality that the browser provides for free because it’s often more performant, robust, and accessible. Not to mention, it becomes more familiar to users as more sites start to use the standard functionality.

While HTML5 validation support is quite good, it’s not implemented uniformly. For example, the required attribute can mark fields as invalid from the outset, which isn’t desirable. Some browsers, such as Firefox 45.7, will show an error of “Please enter an email address” even if the user entered something in the box, whereas Chrome, for example, says “Please include an ‘@’ in the email address,” which is more helpful.

We also want to give users the same interface whether errors are caught on the server or the client. For these reasons we’ll design our own solution. The first thing to do is turn off HTML5 validation: <form novalidate>

Handling Submission

When the user submits the form, we need to check if there are errors. If there are, we need to prevent the form from submitting the details to the server.

function FormValidator(form) { form.on('submit', $.proxy(this, 'onSubmit')); } FormValidator.prototype.onSubmit = function(e) { if(!this.validate()) { e.preventDefault(); // show errors } };

Note that we are listening to the form’s submit event, not the button’s click event. The latter will stop users being able to submit the form by pressing Enter when focus is within one of the fields. This is also known as implicit form submission.

Displaying Feedback

It’s all very well detecting the presence of errors, but at this point users are none the wiser. There are three disparate parts of the interface that need to be updated. We’ll talk about each of those now.

Document Title

The document’s <title> is the first part of a web page to be read out by screen readers. As such, we can use it to quickly inform users that something has gone wrong with their submission. This is especially useful when the page reloads after a server request.

Even though we’re enhancing the user experience by catching errors on the client with JavaScript, not all errors can be caught this way. For example, checking that an email address hasn’t already been taken can only be checked on the server. And in any case, JavaScript is prone to failure so we can’t solely rely on its availability.

Where the original page title might read “Register for [service],” on error it should read “(2 errors) Register for [service]” (or similar). The exact wording is somewhat down to opinion.

The following JavaScript updates the title:

document.title = "(" + this.errors.length + ")" + document.title;

As noted above, this is primarily for screen reader users, but as is often the case with inclusive design, what helps one set of users helps everyone else too. This time, the updated title acts as a notification in the tab.

The browser tab title prefixed with “(2 errors)” acting as a quasi notification.Error Summary

In comparison with the title element, the error summary is more prominent, which tells sighted users that something has gone wrong. But it’s also responsible for letting users understand what’s gone wrong and how to fix it.

It’s positioned at the top of the page so users don’t have to scroll down to see it after a page refresh (should an error get caught on the server). Conventionally, errors are colored red. However, relying on color alone could exclude colorblind users. To draw attention to the summary, consider also using position, size, text, and iconography.

Error summary panel positioned toward the top of the screen.

The panel includes a heading, “There’s a problem,” to indicate the issue. Notice it doesn’t say the word “Error,” which isn’t very friendly. Imagine you were filling out your details to purchase a car in a showroom and made a mistake. The salesperson wouldn’t say “Error” — in fact it would be odd if they did say that.

<div class="errorSummary" role="group" tabindex="-1" aria-labelledby="errorSummary-heading"> <h2 id="errorSummary-heading">There’s a problem</h2> <ul> <li><a href="#emailaddress">Enter an email address</a></li> <li><a href="#password">The password must contain an uppercase letter</a></li> </ul> </div>

The container has a role of group, which is used to group a set of interface elements: in this case, the heading and the error links. The tabindex attribute is set to -1, so it can be focused programmatically with JavaScript (when the form is submitted with mistakes). This ensures the error summary panel is scrolled into view. Otherwise, the interface would appear unresponsive and broken when submitted.

Note: Using tabindex="0" means it will be permanently focusable by way of the Tab key, which is a 2.4.3 Focus Order WCAG fail. If users can tab to something, they expect it will actually do something.

FormValidator.prototype.showSummary = function () { // ... this.summary.focus(); };

Underneath, there’s a list of error links. Clicking a link will set focus to the erroneous field, which lets users jump into the form quickly. The link’s href attribute is set to the control’s id, which in some browsers is enough to set focus to it. However, in other browsers, clicking the link will just scroll the input into view, without focusing it. To fix this we can focus the input explicitly.

FormValidator.prototype.onErrorClick = function(e) { e.preventDefault(); var href = e.target.href; var id = href.substring(href.indexOf("#"), href.length); $(id).focus(); };

When there aren’t any errors, the summary panel should be hidden. This ensures that there is only ever one summary panel on the page, and that it appears consistently in the same location whether errors are rendered by the client or the server. To hide the panel we need to add a class of hidden.

<div class="errorSummary hidden" ...></div> .hidden { display: none; }

Note: You could use the hidden attribute/property to toggle an element’s visibility, but there’s less support for it. Inclusive design is about making decisions that you know are unlikely to exclude people. Using a class aligns with this philosophy.

Inline Errors

We need to put the relevant error message just above the field. This saves users scrolling up and down the page to check the error message, and keeps them moving down the form. If the message was placed below the field, we’d increase the chance of it being obscured by the browser autocomplete panel or by the onscreen keyboard.

Inline error pattern with red error text and warning icon just above the field. <div class="field"> <label for="blah"> <span class="field-error"> <svg width="1.5em" height="1.5em"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#warning-icon"></use></svg> Enter your email address. </span> <span class="field-error">Enter an email address</span> </label> </div>

Like the hint pattern mentioned earlier, the error message is injected inside the label. When the field is focused, screen reader users will hear the message in context, so they can freely move through the form without having to refer to the summary.

The error message is red and uses an SVG warning icon to draw users’ attention. If we’d used only a color change to denote an error, this would exclude color-blind users. So this works really well for sighted users — but what about screen reader users?

To give both sighted and non-sighted users an equivalent experience, we can use the well-supported aria-invalid attribute. When the user focuses the input, it will now announce “Invalid” (or similar) in screen readers.

<input aria-invalid="false">

Note: The registration form only consists of text inputs. In chapter 3, “A Flight Booking Form,” we’ll look at how to inject errors accessibly for groups of fields such as radio buttons.

Submitting the Form Again

When submitting the form for a second time, we need to clear the existing errors from view. Otherwise, users may see duplicate errors.

FormValidator.prototype.onSubmit = function(e) { this.resetPageTitle(); this.resetSummaryPanel(); this.removeInlineErrors(); if(!this.validate()) { e.preventDefault(); this.updatePageTitle(); this.showSummaryPanel(); this.showInlineErrors(); } }; Initialization

Having finished defining the FormValidator component, we’re now ready to initialize it. To create an instance of FormValidator, you need to pass the form element as the first parameter.

var validator = new FormValidator(document.getElementById('registration'));

To validate the email field, for example, call the addValidator() method:

validator.addValidator('email', [{ method: function(field) { return field.value.trim().length > 0; }, message: 'Enter your email address.' },{ method: function(field) { return (field.value.indexOf('@') > -1); }, message: 'Enter the ‘at’ symbol in the email address.' }]);

The first parameter is the control’s name, and the second is an array of rule objects. Each rule contains two properties: method and message. The method is a function that tests various conditions to return either true or false. False puts the field into an error state, which is used to populate the interface with errors as discussed earlier.

Forgiving Trivial Mistakes

In The Design of Everyday Things, Don Norman talks about designing for error. He talks about the way people converse:

“If a person says something that we believe to be false, we question and debate. We don’t issue a warning signal. We don’t beep. We don’t give error messages. […] In normal conversations between two friends, misstatements are taken as normal, as approximations to what was really meant.”

Unlike humans, machines are not intelligent enough to determine the meaning of most actions, but they are often far less forgiving of mistakes than they need to be. Jared Spool makes a joke about this in “Is Design Metrically Opposed?” (about 42 minutes in):

“It takes one line of code to take a phone number and strip out all the dashes and parentheses and spaces, and it takes ten lines of code to write an error message that you left them in.”

The addValidator method (shown above) demonstrates how to design validation rules so they forgive trivial mistakes. The first rule, for example, trims the value before checking its length, reducing the burden on the user.

Live Inline Validation

Live inline validation gives users feedback as they type or when they leave the field (onblur). There’s some evidence to show that live inline validation improves accuracy and decreases completion times in long forms. This is partially to do with giving users feedback when the field’s requirements are fresh in users’ minds. But live inline validation (or live validation for short) poses several problems.

For entries that require a certain number of characters, the first keystroke will always constitute an invalid entry. This means users will be interrupted early, which can cause them to switch mental contexts, from entering information to fixing it.

Alternatively, we could wait until the user enters enough characters before showing an error. But this means users only get feedback after they have entered a correct value, which is somewhat pointless.

We could wait until the user leaves the field (onblur), but this is too late as the user has mentally prepared for (and often started to type in) the next field. Moreover, some users switch windows or use a password manager when using a form. Doing so will trigger the blur event, causing an error to show before the user is finished. All very frustrating.

Remember, there’s no problem with giving users feedback without a page refresh. Nor is there a problem with putting the error messages inline (next to fields) — we’ve done this already. The problem with live feedback is that it interrupts users either too early or too late, which often results in a jarring experience.

If users are seeing errors often, there’s probably something wrong elsewhere. Focus on shortening your form and providing better guidance (good labeling and hint text). This way users shouldn’t see more than the odd error. We’ll look at longer forms in the next chapter.

Checklist Affirmation Pattern

A variation of live validation involves ticking off rules (marking them as complete) as the user types. This is less invasive than live validation but isn’t suited to every type of field. Here’s an example of MailChimp’s sign-up form, which employs this technique for the password field.

MailChimp’s password field with instructions that get marked as the user meets the requirements.

You should put the rules above the field. Otherwise the onscreen keyboard could obscure the feedback. As a result, users may stop typing and hide the keyboard to then check the feedback.

A Note on Disabling Submit Buttons

Some forms are designed to disable the submit button until all the fields become valid. There are several problems with this.

First, users are left wondering what’s actually wrong with their entries. Second, disabled buttons are not focusable, which makes it hard for the button to be discovered by blind users navigating using the Tab key. Third, disabled buttons are hard to read as they are grayed out.

As we’re providing users with clear feedback, when the user expects it, there’s no good reason to take control away from the user by disabling the button anyway.

Crafting a Good Error Message

There’s nothing more important than content. Users don’t come to your website to enjoy the design. They come to enjoy the content or the outcome of using a service.

Even the most thought out, inclusive and beautifully designed experience counts for nothing if we ignore the words used to craft error messages. One study showed that showing custom error messages increased conversions by 0.5% which equated to more than £250,000 in yearly revenue.

“Content is the user experience.”
— Ginny Redish

Like labels, hints, and any other content, a good error message provides clarity in as few words as possible. Normally, we should drive the design of an interface based on the content — not the other way around. But in this case, understanding how and why you show error messages influences the design of the words. This is why Jared Spool says “content and design are inseparable work partners.”

We’re showing messages in the summary at the top of the screen and next to the fields. Maintaining two versions of the same message is a hard sell for an unconvincing gain. Instead, design an error message that works in both places. “Enter an ‘at’ symbol” needs context from the field label to make sense. “Your email address needs an ‘at’ symbol” works well in both places.

Avoid pleasantries, like starting each error message with “Please.” On the one hand, this seems polite; on the other, it gets in the way and implies a choice.

Whatever approach you take, there’s going to be some repetition due to the nature of the content. And testing usually involves submitting the form without entering any information at all. This makes the repetition glaringly obvious, which may cause us to flip out. But how often is this the case? Most users aren’t trying to break the interface.

An error summary containing a wall of error messages makes the beginning of the words seem too repetitive.

Different errors require different formatting. Instructions like “Enter your first name” are natural. But “Enter a first name that is 35 characters or less” is longer, wordier, and less natural than a description like “First name must be 35 characters or less.”

Here’s a checklist:

  • Be concise. Don’t use more words than are necessary, but don’t omit words at the cost of clarity.
  • Be consistent. Use the same tone, the same words, and the same punctuation throughout.
  • Be specific. If you know why something has gone wrong, say so. “The email is invalid.” is ambiguous and puts the burden on the user. “The email needs an ‘at’ symbol” is clear.
  • Be human, avoid jargon. Don’t use words like invalid, forbidden, and mandatory.
  • Use plain language. Error messages are not an opportunity to promote your brand’s humorous tone of voice.
  • Use the active voice. When an error is an instruction and you tell the user what to do. For example, “Enter your name,” not “First name must be entered.”
  • Don’t blame the user. Let them know what’s gone wrong and how to fix it.
Summary

In this chapter we solved several fundamental form design challenges that are applicable well beyond a simple registration form. In many respects, this chapter has been as much about what not to do, as it has about what we should. By avoiding novel and artificial space-saving patterns to focus on reducing the number of fields we include, we avoid several usability failures while simultaneously making forms more pleasant.

Things to Avoid
  • Using the placeholder attribute as a mechanism for storing label and hint text.
  • Using incorrect input types.
  • Styling buttons and links the same.
  • Validating fields as users type.
  • Disabling submit buttons.
  • Using complex jargon and brand-influenced microcopy.

And that’s it. If you liked this first chapter of the Form Design Patterns, you can get the book right away. Happy reading!

  • eBook
  • Hardcover
eBook$19 Get the eBook

PDF, ePUB, Kindle. Free for Smashing Members.

Hardcover$39 Get the Print (incl. eBook)

Printed, quality hardcover. Free airmail shipping worldwide.

(cm)

Categories: Around The Web

Practical Suggestions To Improve Usability Of Landing Pages With Animation From Slides

Tue, 10/09/2018 - 8:00am
Practical Suggestions To Improve Usability Of Landing Pages With Animation From Slides Practical Suggestions To Improve Usability Of Landing Pages With Animation From Slides Nick Babich 2018-10-09T14:00:09+02:00 2018-10-21T14:20:03+00:00

(This is a sponsored post.) For a long time, UI animation was an afterthought for designers. Even today, many designers think of animation as something that brings delight but does not necessarily improve usability. If you share this point of view, then this article is for you. I will discuss how animation can improve the user experience of landing pages, and I’ll provide the best examples of animation created using the Slides framework.

The Slides framework is an easy-to-use tool for creating websites. It allows anyone to create a sleek landing page in a few minutes. All you need to do is choose an appropriate design from the list of predefined slides.

A collection of predefined designs in Slides. Four Ways Animation Supports Usability Of Landing Pages

Landing page design is more than just about visual presentation; it’s about interaction. Details of interaction design make a fundamental difference on modern websites. And animated effects can reinforce interactions. To improve the usability of a landing page, an animation must be a functional element, not just decoration. It should serve a clear functional purpose. Below are a few common ways that animation can improve usability.

1. Create A Narrative

Every designer is a storyteller. When we create a website, we are telling a story to our visitors. And it’s possible to tell a much more engaging story by using animation.

Animation can help bring content to life. One good example of such animation can be found on Ikonet. The animation there keeps users engaged as they scroll the page and learn about the company.

Animation can also be used to call the visitor’s attention to something they should notice and act upon. For example, if you have an important text section or a call to action, sliding them in (instead of having them just appear) can help visitors understand where they should focus. Take a look at the Preston Zeller example below. The way elements appear on the pages drives the user’s focus to those areas. The great thing about this animation is that it draws attention to important information without being disruptive.

When visitors scroll on Preston Zeller, elements gradually appear on the page. As a result, attention is drawn to vital information. 2. Provide Feedback

Human-computer interaction is based on two fundamentals: user input and system feedback. All interactive objects should react to user input with appropriate visual or audio feedback.

Below you can see the Custom Checkbox effect created using the Slides framework. The subtle bouncing animation the user sees when they change the state of the toggle reinforces the feeling of interactivity.

With Slides, you can create nice hover animations and encourage users to interact with objects. Take a look at Berry Visual. When you hover the mouse on “Send Message” or on the hamburger menu in the top-right corner, a nice animated effect occurs. It creates a sense that these elements are interactive.

Buf Antwerp is another excellent example of how on-hover animated feedback can improve the user experience. When visitors hover over a tile, a semi-transparent overlay appears, and text provides additional information about the item.

3. Create Relationships

A great place to add animation to a landing page is at moments of change. All too often, moments of change are abrupt &mdahs; for example, when users click on a link, a new screen suddenly appears. Because sudden changes are hard for users to process, such changes usually result in a loss of context — the brain has to scan the new page to understand how the new context is connected to the previous one.

Consider this example of an abrupt change:

This abrupt change feels unnatural and leads to unnecessary brain work (the brain has to scan entire layout to understand what has just happened). (Image: Adrian Zumbrunnen via Smashing Magazine)

Compare that to the following example, in which a smooth animated transition guides the user to the different parts of the screen:

A simple animated transition maintains context, making it easy to understand what has changed about a screen. (Image: Adrian Zumbrunnen via Smashing Magazine)

It’s clear that in the second example, animation prevents abrupt change — it fills the gap and connects two stages. As a result, visitors understand that the two stages belong together. This principle applies equally when you have a parent-to-child relationship between two objects:

Animated transition between preview and details. (Image: Tympanus)

It also applies when you create a transition between stages. The smooth transitions between slides in the example below create a sense of sequence, rather than separate unrelated parts of the page.

Using animation, it’s possible to define object relationships and hierarchies when introducing new elements. 4. Making Boring Tasks Fun

It might be difficult to imagine how to introduce playful elements into everyday experiences. But by adding a bit of surprise where it’s most unexpected, we can turn a familiar interaction into something unexpected and, thus, memorable.

When you visit Tympanus’ 3D Room Exhibition, it looks like any other gallery website that you’ve visited before. But your impression of the website changes immediately once you interact with a page. As you move the cursor, the page moves, and this effect creates a sense of 3D space. This feeling is reinforced when you go from one page to another; it looks like you’re traveling from one room to another within a 3D space.

Large preview

Now let’s talk about something much more familiar than 3D effects: web forms. Who loves filling out forms? Probably nobody. Still, filling out forms is one of the most common tasks on the web. And it is possible to turn this dull activity into a fun exercise. Take a look Darin Senneff’s Yeti character, which is used in a form. When the user starts typing their password, the mascot covers its eyes. Such an animated effect brings a lot of delight when you see it for the first time.

The Yeti character responds to user input.

Last but not least, it’s possible to make the scrolling experience not just more visually interesting, but also helpful for readers. Below is Storytelling Map, an interactive journey in which a path along a map is animated according to the content being scrolled through on the page. The idea ties the text, visuals and locations together; visitors read the information and see it in the context of the map).

Large preview Six Best Practices For Landing Page Animation

Identifying the places where animation has utility is only half the story. Designers also need to implement animation properly. In this section, we’ll find out how to animate like a pro.

1. Don’t Animate Several Elements At Once

When a few objects are animated simultaneously, it becomes distracting for users. Because the human brain and eye are hardwired to pay attention to moving objects, the user’s focus will jump from one element to another, and the brain will need extra time to figure out what just happened (especially if the movement happens very quickly). Thus, it’s important to schedule animations properly.

It’s vital to understand the concept of transition choreography: the coordinated sequence of motions that maintain the visitor’s focus as the interface changes. Minimize the number of elements that move independently; only a few things should happen at the same time (typically, no more than two or three). Thus, if you want to move more than three objects, group some objects together and transform them as a single unit, rather than animating them independently.

Don’t animate everything at the same time. It will make the objects compete for attention and divide focus. (Image: Google)

Slides offers an excellent benefit to web designers: It prevents them from overusing motion in design. Each animated effect available in Slides has been carefully designed to deliver content in the best possible way.

2. Animation Shouldn't Conflict With Landing Page’s Personality

Each time you add animation to a design, you introduce personality. This personality will largely depend on the animated effect you choose to use.

When people interact with a product, they have certain expectations. Imagine designing a landing page for a banking service, and you decide to use a bouncing animation to introduce a form that collects the user’s personal information. Many users will hesitate to provide their details because the form conflicts with their expectations.

An example of bouncing animation. Avoid bouncing animation in forms that collect bank account details. Users might hesitate to provide their data. (Image: Joel Besada)

The Slides framework allows you to choose from 10 animated styles, such as Stack, Zen, Film, Cards and Zoom. Experiment with different effects, and choose what’s best for your case.

Large preview 3. Watch The Time

When it comes to designing animation, timing is everything. The timing of your animation can mean the difference between a good interaction and a bad one. When working on animation, you’ll usually spend a third of your time finding the right animated effects and the other two thirds finding the right timing to make the animation feel smooth.

Generally, keep the animation short. Animation should never get in the way of the user completing a task, because even the most beautifully executed animation would be really annoying if it slows down users. The optimal speed for a UI animation is between 200 and 500 milliseconds. An animation that lasts less than 1 second is considered as instant, whereas an animation longer than 5 seconds can convey a feeling of delay.

When it comes to creating an animated effect, one parameter has a direct impact on how the animation is perceived: easing, or timing function in CSS terms. Easing helps designers make movement more natural.

The Slides framework enables web designers to customize easing. You’ll find easing along with other effects in the section “Effect Settings”.

Large preview 4. Think About Accessibility

Animation is a double-edged sword. It can improve usability for one group of users, while causing problems for another group. Apple’s release of iOS 7 was a recent example of the latter. iOS 7 was full of animated effects, and shortly after its release, iPhone users reported that the animated transitions were making them feel dizzy.

Your responsibility as a designer is to think about how people with visual disorders will interact with your design. Check the WCAG’s guidelines on animation, and be sure that your design aligns with them. Track whether a user wants to minimize the amount of animation or motion. A special CSS media feature, "prefers-reduced-motion", detects whether the user has requested that the system minimize the amount of animation or motion used. When it is set to "reduce", then it’s better to minimize the amount of movement and animation (for example, by removing all non-essential movement).

Also, conduct usability testing to check that users will all abilities, including people with visual disorders, won’t have any problem interacting with your design.

5. Prototype And Test Your Design Decisions

Animation is fun to play with. It’s easy to go overboard and end up with a design that overwhelms users with too much motion. Unfortunately, there is no silver bullet for great animation; it’s hard to set clear criteria of what is “just enough”. Be ready to spend time on prototyping, testing and optimizing animated effects.

Here are a few tips worth taking into account during testing:

  • Test on different hardware.
    Many hardware factors can drastically affect animation performance: screen size, screen density, GPU performance, to name just a few. As a result, a user on a high-definition screen might have a completely different experience than a user on an older screen. Consider such factors when designing animation to prevent performance bottlenecks. Don’t blame slow hardware; optimize your animation to work great on all sort of devices.
  • Test on mobile.
    Most websites are built and tested on a desktop; the mobile experience and animation performance is often treated as an afterthought. Lack of testing on mobile could cause a lot of problems for mobile users, because some animated techniques work great on desktop but not as well on mobile. To avoid a negative experience, confirm that your design works fine on both desktop and mobile. Test on mobile early and often.
  • Watch animation at a slow speed.
    It might be hard to notice problems when an animation (especially a complex one) runs at full speed. When you slow the animation down (say, at one tenth the speed), such issues become evident. You can also record slow-motion video of your animations and show them to other people to get other perspectives.

With the Slides framework, you can create a high-fidelity interactive prototype in minutes. You can use a WYSIWYG editor to create animated effects, publish the design, and see how it works on both desktop and mobile devices.

6. Animation Shouldn’t Be An Afterthought

There’s a reason why so many designers think of animation as an unnecessary feature that overloads the user interface and makes it more complicated. In most cases, that’s true when designers introduce animation at the end of the design process, as lipstick for the design — in other words, animation for the sake of animation. Random motion without any purpose won’t benefit visitors much, and it can easily distract and annoy.

To make meaningful animation, take time at the beginning of the project to think about areas where animation would naturally fit. Only in this way will animation be natural to the user flow.

Conclusion

Good functional animation makes a landing page not just more appealing, but also more usable. When done correctly, animation can turn a landing page from a sequence of sections into a carefully choreographed, memorable experience. The Slides framework helps web designers use animation to communicate clearly.

(ms, ra, al, yk, il)
Categories: Around The Web

Getting Started With Gutenberg By Creating Your Own Block

Mon, 10/08/2018 - 7:50am
Getting Started With Gutenberg By Creating Your Own Block Getting Started With Gutenberg By Creating Your Own Block Muhammad Muhsin 2018-10-08T13:50:00+02:00 2018-10-21T14:20:03+00:00

WordPress is the most popular Content Management System (CMS) by far —powering more than 30% of the web. It has undergone a huge metamorphosis during its 15 years of existence. Its latest addition is Gutenberg which is to be released in version 5.0.

Named after Johannes Gutenberg (the inventor of the printing press), Gutenberg is going to fundamentally change WordPress, further helping reach its goal to democratize publishing.

WordPress usually releases its major features as a plugin to test the waters before baking them into the core. Gutenberg is no exception. In this article, we will learn how to go about building your first Gutenberg block. We will be building a Testimonials Slider Block while dwelling on the basics of Gutenberg.

Here is an outline for this article:

  1. Installing The Gutenberg Plugin
  2. Installing The Testimonials Slider Block
  3. Getting Started With The Configuration
  4. Registering A Block
  5. Introducing Gutenberg Specific Syntax
  6. The attributes Object
  7. The edit And save Functions
  8. Continuing Development
  9. Starting A New Gutenberg Block
  10. Conclusion

This article assumes the following:

  • Some knowledge of WordPress such as how content is saved and basic plugin development;
  • Basic understanding of React and ES6;
  • Knowledge of both npm and webpack.

Recommended reading: The Complete Anatomy Of The Gutenberg WordPress Editor

Front-end is messy and complicated these days. That's why we publish articles, printed books and webinars with useful techniques to improve your work. Even better: Smashing Membership with a growing selection of front-end & UX goodies. So you get your work done, better and faster.

Explore Smashing Membership ↬ Installing The Gutenberg Plugin

If you are a WordPress user, just go ahead and install the Gutenberg plugin from the WordPress.org plugin repository. This is what one should use in a production site.

However, if you’re developing a Gutenberg block, I recommend that you clone the development version of Gutenberg which is hosted at GitHub. For help with setting up a local environment, please read the contribution guide.

You get the latest development version of Gutenberg this way but the primary reason to do this is to be able to use the development version of React.js that comes bundled with Gutenberg. The development version has more verbose error reporting which helps greatly with debugging.

Now when you go and create a page or a post, you will be able to edit using the Gutenberg Editor.

Gutenberg Editor Demo (Large preview)

Since this article is about creating a Gutenberg Block, we will not go into the introduction to the Editor, For a complete understanding of what is Gutenberg and how to use it, please refer to Manish Dudharejia’s article on Smashing Magazine.

Installing The Testimonials Slider Block

The plugin in question — the one we are going to go through is already published to the WordPress repository.

Please install the Testimonials Slider Block plugin to your local WordPress instance so that you have a feel for how the plugin works.

You can also fork or clone the project from GitHub.

After activating the plugin, you can go to your Gutenberg Editor and add a Testimonials Slider to your content:

Selecting the Testimonials Slider Block (Large preview) Adding content to the Testimonials Slider Block (Large preview) Testimonials Slider Block in the frontend (Large preview)

Now I will go through how I built the plugin and how you too can build a similar one. To keep the article concise, I will not share the entire code in here. However, after reading this you should be able to create your own Gutenberg block.

Getting Started With The Configuration

A Gutenberg block is generally created as part of a plugin. Our plugin is not going to be any different.

Navigate to the plugins directory in your local WordPress instance. Move to the testimonials-slider-block. Notice the following files and folders:

  1. gutenberg-testimonials-slider.php is the main file which has details of the plugin, such as name, description, author details and license. These details will be used in the plugin description in the Plugins menu in the dashboard. You will see that this file calls the init.php file.
  2. The init.php file enqueues the different JavaScript and CSS files. This includes both the external libraries like Bootstrap and Font Awesome and our build files.
  3. The .babelrc file instructs webpack what kind of JavaScript files we are writing.
  4. The package.json file contains all the npm modules that are used in the plugin. You will use the npm install command to install all those packages.
  5. webpack.config.js file contains the configuration for webpack to build our JavaScript and CSS. if you did not know, webpack is a package bundler mainly used for bundling our JavaScript modules and putting them into one file that is then enqueued by WordPress.

That was a lot of configuration files. Now we can go about actually building our Gutenberg block.

Registering A Block

Within the src folder you will see the index.js file. This is the fle that webpack looks for, to bundle the JavaScript. You can see that this file imports the slider.js file within the block folder.

The block folder has the following styles:

  • slider.js: contains the actual code for the block
  • editor.scss: the styles file describing the block within the Gutenberg Editor
  • style.scss: contains styles pertaining to how the block is displayed in the frontend.

Please open the slider.js file in your editor.

This file first imports both the editor and style scss files. Then it imports internationalization component, registerBlockType and the MediaUpload and PlainText components. The last two components will be used to upload the author image and to take in the different text inputs to save in the database.

Next you will see how a block is registered.

It takes in a name as the first parameter. The name must be prefixed with a namespace specific to your plugin in order to avoid any conflicts with another block with the same name.

The second parameter is an array with the following properties and functions:

  • Title
    The name of the block which will appear when you add a new block in the Gutenberg Editor.
  • Icon
    The block’s icon which will be picked up from dashicons. You can also specify your own SVG icons if you want to.
  • Category
    Under which category of blocks will the block appear. Some of the categories are: common, formatting, layout widgets and embed.
  • Keywords
    An array of strings that describe the block, similar to tags.
  • Attributes
    A JavaScript object which contains a description of the data that is saved by the block.
  • Edit
    The function that provides an interface for the block within the Gutenberg Editor.
  • Save
    The function that describes how the block will be rendered in the frontend.

To learn more, please refer to this documentation. Introducing Gutenberg Specific Syntax

Gutenberg is built with React and the blocks that we build for Gutenberg use a similar syntax.

It certainly helps to know a bit of React to build custom Gutenberg blocks though you don’t have to be an expert.

The following things are useful to know before starting the block development:

  • The HTML class is replaced with className like in React.
  • The edit and save methods return JSX, which stands for JavaScript XML. If you are wondering, JSX is syntax exactly like HTML, except you can use HTML tags and other components like PlainText and RichText within it.
  • The setAttributes method works similar to React’s setState. What it does is, when you call setAttributes the data in the block is updated and the block within the editor is refreshed.
  • The block uses props in the edit and save functions, just like React. The props object contains the attributes object, the setAttributes function and a ton of other data.
The attributes Object

The attributes object that was mentioned previously define the data within the Gutenberg block. The WordPress Gutenberg Handbook says:

Attribute sources are used to define the strategy by which block attribute values are extracted from saved post content. They provide a mechanism to map from the saved markup to a JavaScript representation of a block.

Each source accepts an optional selector as the first argument. If a selector is specified, the source behavior will be run against the corresponding element(s) contained within the block. Otherwise, it will be run against the block’s root node.

For more details on how to use attributes, please refer to this guide.

The following is the attributes object that is used in the Testimonials Slider Block:

attributes: { id: { source: "attribute", selector: ".carousel.slide", attribute: "id" }, testimonials: { source: "query", default: [], selector: "blockquote.testimonial", query: { image: { source: "attribute", selector: "img", attribute: "src" }, index: { source: "text", selector: "span.testimonial-index" }, content: { source: "text", selector: "span.testimonial-text" }, author: { source: "text", selector: "span.testimonial-author span" }, link: { source: "text", selector: ".testimonial-author-link" } } } },

The source tells Gutenberg where to look for data within the markup.

Use attribute to extract the value of an attribute from markup, such as the src from img element. The selector and attribute tell what element to look for and what exact attribute to pick the data from respectively. Notice that the selector string picks up an HTML element from the save function.

Use text to extract the inner text from markup and html to extract the inner HTML from markup.

Use query to extract an array of values from markup. Entries of the array are determined by the selector argument, where each matched element within the block will have an entry structured corresponding to the query argument, an object of attribute and text sources.

You can access the attributes in the edit and save functions through props.attributes.

When you use console.log(props.attributes.testimonials) in the edit function, you get the following result:

(2) [{...}, {...}] ▼0: author:"Muhammad" content: "This is a testimonial" image: "http://localhost/react-gutenberg/wp-content/uploads/2018/08/0.jpg" index: 0 link: "https://twitter.com/muhsinlk" ▶__proto__: Object ▼1: author: "Matt" content: "This is another testimonial" image: "http://localhost/react-gutenberg/wp-content/uploads/2018/08/767fc115a1b989744c755db47feb60.jpeg" index: 1 link: "https://twitter.com/photomatt" ▶__proto__: Object length: 2 ▶__proto__: Array (0)

Therefore, in the above code, id is a text that uniquely describes each testimonial block whereas testimonials is an array of objects where each object has the properties as shown in the above screenshot.

The edit And save Functions

As mentioned above, these two functions describe how the block is rendered in the editor as well as in the frontend respectively.

Please read the full description here.

The edit Function

If you look at the edit function, you will notice the following:

  1. I first get the props.attributes.testimonials array to a const variable. Notice the ES6 Object Destructuring to set the const value.
  2. Then generate an id for the block which will be used to make each block unique when you add more than one Testimonials Slider Block to your content.
  3. Then the testimonialsList is generated, which is got from sorting then mapping the testimonials array that we got in step 1.
  4. Then, the return function gives out JSX, which we discussed earlier. The testimonialsList, which we constructed in step 3 is rendered. The + button is also rendered, pressing which will create a new testimonial inside the block.

If you dig into testimonialsList, you will see that it contains the PlainText and MediaUpload components. These provide the interface for entering the different texts and uploading the author image respectively.

The PlainText component looks like this:

<PlainText className="content-plain-text" style={{ height: 58 }} placeholder="Testimonial Text" value={testimonial.content} autoFocus onChange={content => { const newObject = Object.assign({}, testimonial, { content: content }); props.setAttributes({ testimonials: [ ...testimonials.filter( item => item.index != testimonial.index ), newObject ] }); }} />

The attributes I have used for the PlainText component are:

  • className
    The CSS class of the component in order to style it.
  • style
    To give a minimum height so that the content does not look like a one-line text. Specifying the height using the class selector did not work.
  • placeholder
    The text that will be displayed when no content is added.
  • value
    The value of the component from the object within the testimonials array.
  • autoFocus
    To tell the browser to focus on this component (input field) as soon as the user adds a new testimonial by clicking the + button.
  • onChange
    What looks like the most complex attribute in this list. This function first gets a copy of the current testimonial and assigns the changed content to newObject. Then it spreads the array of objects, filters out the current object using index and then replaces the newObject within the array. This is set using the the props.setAttributes function to the testimonials array.
The save Function

This function does the following:

  1. I first get the props.attributes.testimonials array and props.attributes.id string to const variables. Again, notice the ES6 Object Destructuring being used to set the values for the two const variables id and testimonials.
  2. Then I create the carouselIndicators variable, which is essentially JSX constructed from the testimonials array.
  3. Then the testimonialsList is created from the testimonials array. The snippet below is from the mapped function callback return. {testimonial.content && ( <p className="testimonial-text-container"> <i className="fa fa-quote-left pull-left" aria-hidden="true" /> <span className="testimonial-text">{testimonial.content}</span> <i class="fa fa-quote-right pull-right" aria-hidden="true" /> </p> )} Notice the conditional rendering. The markup will not be rendered for content if the content is not set.
  4. Next, if the testimonials array has objects within it, the HTML is rendered. This is what will be serialized and saved to the database, and this is what will be shown in the frontend (not verbatim).
Continuing Development

I’m sure you want to tinker around this plugin and see what happens. You can continue developing the plugin:

  1. Open up the terminal
  2. Navigate to the plugin’s root directory
  3. npm install
  4. npm start

This will install all the packages, build the files and watch for changes. Every time you make a change to the files, webpack will rebuild the JS and CSS files.

Please note: Markup changes to the blocks will mess up the block in the Gutenberg Editor if you had added it before. Don’t be alarmed — you simply have to remove the block and add it again.

If you are done with developing you can npm run build to minify the files to make it ready for production!

Hopefully, you are now convinced Gutenberg block development is more approachable than it sounds.

I have the following plans in mind for this plugin:

  • Allow users to select color of text, background and accent.
  • Allow users to select the size of slider and font.
  • Avoid depending on libraries like Bootstrap and Font Awesome.

I encourage you to make a pull request with your improvements and extra features.

Starting A New Gutenberg Block

There are many ways to develop a Gutenberg block. One of the recommended ways is to use create-guten-block created by Ahmad Awais. In fact, this project was built based on guten-testimonial-block which was bootstrapped from create-guten-block.

You can also check out Zac Gordon’s repository where he shows how to use the different Gutenberg components in your new block.

Conclusion

We covered the following in today’s article:

  • Installing and using Gutenberg and Testimonials Slider Block plugins
  • Configuration for a typical Gutenberg block plugin
  • Registering a Gutenberg block
  • How to use the attributes object
  • The edit and save functions and how to use them.

I hope this article was useful for you. I can’t wait to see what you will build with and for Gutenberg!

(dm, ra, yk, il)
Categories: Around The Web

SmashingConf Toronto Videos

Fri, 10/05/2018 - 12:00pm
SmashingConf Toronto Videos SmashingConf Toronto Videos The Smashing Editorial 2018-10-05T18:00:35+02:00 2018-10-21T14:20:03+00:00

This year, many of your favorite speakers were featured at our conference in Toronto, however, things were quite different this time. The speakers had been asked to present without slides. Yep, and it was brilliant!

In this pairing of videos from SmashingConf Toronto, discover sketching with Eva-Lotta Lamm and SVG Animation with Sarah Drasner, but if you fancy watching all of them then head on over to our SmashingConf Vimeo channel anytime.

How I Think When I Think Visually: Eva-Lotta Lamm

Sketching is something which lends itself perfectly to the no-slides format. In this talk, Eva-Lotta demonstrates her process for visual thinking. A method which helps her order her thoughts, create sketchnotes, and visualize processes such as user journeys.

SVG And Vue Together From Start To Finish: Sarah Drasner

In this talk, Sarah starts with only an Illustrator document and by the end, makes it move! In this talk, which has an included GitHub repository to help you follow along, Sarah uses animation and Vue.js to create the final piece.

Enjoyed watching these talks? There are many more videos from SmashingConf Toronto on Vimeo. We’re also getting ready for the upcoming SmashingConf in New York — see you there? ;-)

(ra, il)
Categories: Around The Web

Taming <code>this</code> In JavaScript With Bind Operator

Fri, 10/05/2018 - 8:20am
Taming <code>this</code> In JavaScript With Bind Operator Taming <code>this</code> In JavaScript With Bind Operator Willian Martins 2018-10-05T14:20:22+02:00 2018-10-21T14:20:03+00:00

Do you want to discover the next exciting JavaScript features that you didn’t even know you needed? In this article, I will introduce one of these proposals that if accepted may change the way you write code the same way the spread operator did.

However, here’s a small disclaimer: This feature is under development and discussion. The goal here is to add some hype around it and create awareness of the hard work that TC39 is doing to find consensus, fix all the syntax and semantics issues and have it shipped with the next releases of ECMAScript. If you have any concerns, comments or desire to express your support, please go to the TC39 proposals repository, add a star to this feature to show your support, open an issue to voice your concerns and get involved.

But before, I want to ask a simple (but tricky) question:

What is this?

In ECMAScript, this has a different semantic than this in many other programming languages, where this often refers to the lexical scope. In general, this behaves differently in the global scope, within a function, in non-strict mode and strict mode. Let’s break this behavior down into small examples.

Getting workflow just right ain’t an easy task. So are proper estimates. Or alignment among different departments. That’s why we’ve set up “this-is-how-I-work”-sessions — with smart cookies sharing what works well for them. A part of the Smashing Membership, of course.

Explore Smashing Membership ↬ this In The Global Scope

What is the value of this in this example?

console.info(this);

At the global scope, this refers to the global object, like the window in the browser, self on web workers and the module.exports object in NodeJS.

this In The Function Scope

At the function scope, this behaves depending on how the function is called, and this aspect makes it tricky to predict its value. We can understand it better by checking the following examples:

What Is The Value Of this Here? function foo() { return this; } console.info(this);

Inside a function, this starts to have an interesting behavior since its value depends on how the function is called. In the example above, this still refers to the global scope, with one difference. In NodeJs, this will point to the global object instead of module.exports.

Setting A Value Into this: function foo() { this.bar = 'baz'; return this; } console.info(foo()); console.info(new foo());

Setting a value into this sets the value into the current context. The example above logs the global scope with the property bar with the value baz in the first console.info, but it logs only { bar: ‘baz’ } in the second console.info. It happens because the new operator among other things bounds the value of this to the newly created object.

This Keyword In The Strict Mode

In strict mode, the this variable doesn’t carry the value of the context implicitly, this means if its context isn’t set, the value of this is default to undefined as shown in the following snippet.

function foo() { "use strict"; return this; } console.info(foo()); //undefined

To set the context of this in strict mode you can set the function as member of an object, use new operator, Function.prototype.call(), Function.prototype.apply() or Function.prototype.bind() methods for example.

function foo() { "use strict"; return this; } var a = { foo }; foo(); // undefined a.foo(); // { foo: ƒunction } new foo(); // Object foo {} foo.call(this); // Window / Global Object foo.apply(this); // Window / Global Object foo.bind(this)(); // Window / Global Object Making this Variable Predictable

At this point, you may realize that the value of this in ECMAScript is quite tricky to predict. To demonstrate the available techniques to make it predictable, I’d like to present the following example that mimics a common use case of this.

<button id="button">
Categories: Around The Web

Use Cases For Flexbox

Thu, 10/04/2018 - 7:50am
Use Cases For Flexbox Use Cases For Flexbox Rachel Andrew 2018-10-04T13:50:30+02:00 2018-10-21T14:20:03+00:00

We come to the final part in my Flexbox series here at Smashing Magazine. In this post, I am going to spend some time thinking about what the use cases for Flexbox really are, given that we now have CSS Grid Layout, giving some suggestions for what you might use when and a way to decide.

Earlier In This Series

If you haven’t picked up the other articles yet, this is essentially a concluding post so check those out first. I began by describing exactly what happens when you create a flex container. In the second article in the series, I took a look at alignment, and how we align items on the main and cross axis in flexbox. In the third article, I unpack how sizing works in Flexbox, and how the browser figures out how big a flex item should be. Now that we know exactly how Flexbox works, we can wrap up by thinking about the use cases it is best for.

Should I Use Grid Or Flexbox?

This is still the top question that I’m asked when teaching layout, and in general, I find that as people become more used to working with newer layout methods, it becomes a question you need to ask yourself less. As you build more components you will get a feel for which layout method to use.

If you are just getting to grips with the idea, however, the thing to remember is that both CSS Grid Layout and Flexbox are both CSS. Whether you have specified display: grid or display: flex, you often use more that is common than is different. Both Grid and Flexbox use the properties which are part of the Box Alignment specification; they both draw on concepts detailed in CSS Intrinsic and Extrinsic Sizing.

Asking whether your design should use Grid or Flexbox is a bit like asking if your design should use font-size or color. You should probably use both, as required. And, no-one is going to come to chase you if you use the wrong one.

Meet SmashingConf New York 2018 (Oct 23–24), focused on real challenges and real front-end solutions in the real world. From progressive web apps, Webpack and HTTP/2 to serverless, Vue.js and Nuxt — all the way to inclusive design, branding and machine learning. With Sarah Drasner, Sara Soueidan and many other speakers.

Check all topics and speakers ↬

So, we are not picking between Vue.js and React, Bootstrap or Foundation. We are using CSS to do layout, and we need to use the bits of CSS which make most sense for the particular bit of our design that we are working on. Consider each component, and decide what is best for it, or what combination of things are best for it.

That might be Grid, or it might be Flexbox. It might be a grid outer container with some of your grid items becoming flex items or the reverse. There is no issue in nesting a grid inside a flex item if that is what your design calls for.

What Is Flexbox Really For?

The Flexbox specification describes the layout method like this,

“Flex layout is superficially similar to block layout. It lacks many of the more complex text- or document-centric properties that can be used in block layout, such as floats and columns. In return, it gains simple and powerful tools for distributing space and aligning content in ways that web apps and complex web pages often need.”

I think the key phrase here is “distributing space and aligning content”. Flexbox is all about taking a bunch of things (which have varying sizes) and fitting them into a container (which itself has a varying size). Flexbox is squishy. Flexbox tries to create the best possible layout for our items, giving bigger items more space and smaller items less space, thus preserving readability of content.

When people find Flexbox hard and weird, it is often because they are trying to use Flexbox as a grid system — trying to take back control over sizing and space distribution. When you do this, Flexbox can seem weird and hard as you are fighting against the very thing that makes it Flexbox, i.e. that inherent flexibility.

Therefore, patterns which suit flex layout very well are those where we are not so interested in having a pixel-perfect size for each item. We just want those items to display well alongside each other.

See the Pen Smashing Flexbox Series 4: Items Sharing Space by Rachel Andrew (@rachelandrew) on CodePen.

There are also patterns where you want to have wrapped lines, however, you do not want a strict grid. If we take the seminal grid versus the Flexbox example where we use the repeat auto-fill syntax in grid, and then a flex container with wrapped flex lines. Here we immediately see the difference between the two methods.

In the grid example, the grid items line up in rows and columns. While the number of column tracks changes (depending on space), the items always go into the next grid cell that is available. In fact, there is no way to ask a grid item to span tracks if there are some empty cells to fill in that auto-flow scenario.

See the Pen Smashing Flexbox Series 4: Grid Example by Rachel Andrew (@rachelandrew) on CodePen.

In the flex example, the final items share any space left over between them; this way, we do not have alignment horizontally and vertically.

See the Pen Smashing Flexbox Series 4: Wrapped Items flex-basis: auto by Rachel Andrew (@rachelandrew) on CodePen.

If we have a flex-basis of auto and any of the flex items are larger, they will also be given more space so that the alignment could be quite different line by line.

See the Pen Smashing Flexbox Series 4: Wrapped Items by Rachel Andrew (@rachelandrew) on CodePen.

This then is a very clear example of where we would want to use Flexbox over Grid Layout. If we want the items to wrap but to take up the space they need on a line-by-line basis. That is a very different kind of layout to a grid. Patterns like this might be a set of tags (one or two-word elements that you wish to display nicely as a set of items), taking up the space they need and not rigidly being forced into a strict grid.

See the Pen Smashing Flexbox Series 4: Tags example by Rachel Andrew (@rachelandrew) on CodePen.

At the present time, Flexbox is also the best way to perform vertical and horizontal centering of an item inside a container.

See the Pen Smashing Flexbox Series 4: Center an Item by Rachel Andrew (@rachelandrew) on CodePen.

In the future (when there is browser support for the Box Alignment properties outside of flex layout), we may be able to do this without needing to add display: flex to the container. For now, however, that is what you need to do — that extra line of CSS is really not an issue.

Flexbox is very good at dealing with small, one-dimensional components. Sets of form fields, icons, or other information can be easily laid out and allowed to be flexible without needing to carefully set the sizing on each item.

See the Pen Smashing Flexbox Series 4: Simple Row of Form Elements by Rachel Andrew (@rachelandrew) on CodePen.

You might also choose Flexbox in a scenario where all you need to do is cause content at the bottom of a layout to stick to the bottom of a container rather than popping up. In this example, I make the container a flex container by displaying the contents as a column, then allowing the middle to grow by pushing the footer to the bottom of the component.

See the Pen Smashing Flexbox Series 4: Sticky Footer Card by Rachel Andrew (@rachelandrew) on CodePen.

In production, I am finding that Flexbox is useful for lots of little jobs, making sure that things align properly, that space is shared out nicely between items. You could absolutely use a one-dimensional grid container for some of those things, and don’t worry about it if that is what you decide to do.

What I think Flexbox does very well, however, is to cope with the situation where extra items might need to be added that I didn’t expect in my design. For example, if I have a navigation component using Grid I would be creating enough tracks for all items, as I wouldn’t want a new row to be created if I had “too many” items. With flexbox, as long as I was allowing the items to be flexible from a flex-basis of 0 (or auto) then the items would allow their new companion into the row and make space for it.

When Should I Not Use Flexbox?

We have looked at some of the reasons that I think you should choose Flexbox over Grid Layout, so we can now look at some of the places where Flexbox might not be the best choice. We have already looked at our Flexbox versus grid example with items aligned horizontally and vertically versus items which take up space line by line. And, that distinction is the first thing to consider.

The grid example is of two-dimensional layout. Layout in rows and columns at the same time. The Flexbox example is one-dimensional layout. We have wrapped flex lines but space distribution is happening on a line by line basis. Each line is essentially acting as a new flex container in the flex-direction.

Therefore, if your component needs two-dimensional layout, you would be better placed to use Grid over Flexbox. It doesn’t matter whether your component is large or small. If you take one thing from this article, it is to remove the idea from your brain that Grid is somehow only meant for main page layout, and Flexbox for components. You can have a tiny component that requires two-dimensional layout, and main page structures which better suit one-dimensional layout.

Another good point at which Grid may be considered the better solution is if you are applying a width, or a flex-basis set as a length unit to your flex items in order to line them up with another row of flex items, or just to restrict the flexibility in some way. Quite often that indicates either than you really need a two-dimensional layout method or that the control from the container of grid would suit your layout better.

For example, we could make our flex layout display more like a grid, by restricting the flexibility of our items. Setting flex-grow to 0 and sizing the items with percentages, in a similar way to the way we would size items in a floated “grid”. If you find that you are doing that, I would suggest that Grid Layout is a much better approach as it is designed for this type of layout.

See the Pen Smashing Flexbox Series 4: Wrapped Flex Items with Percentage Widths by Rachel Andrew (@rachelandrew) on CodePen.

With all that said, remember that there is very often not a clear right or wrong answer. Sometimes the only thing you can do is to try different ways and see what suits the component best. Remember that you can also switch layout methods, using Flexbox at one breakpoint and Grid at another.

And That’s A (Flex) Wrap!

I hope this series on Flexbox has been helpful and demonstrated how understanding some of the logic behind alignment and sizing of flex items, makes life easier when working with it. If you are left with any outstanding questions or have a pattern which seems not to have an obvious answer in terms of the layout method to use, post a comment.

(il)
Categories: Around The Web

How To Build A News Application With Angular 6 And Material Design

Wed, 10/03/2018 - 6:00am
How To Build A News Application With Angular 6 And Material Design How To Build A News Application With Angular 6 And Material Design Rachid Sakara 2018-10-03T12:00:26+02:00 2018-10-21T14:20:03+00:00

Are you looking to combine Google’s material design with Angular applications? Well, look no further!

In this tutorial, we’re going to build a news application using two of the most powerful and popular resources out there, Angular 6 and material design. You’ll learn how to incorporate Google’s material design components into Angular application templates to change and style your application in a professional way. The tutorial also serves as a reminder of how to make HTTP requests to bring live news articles to an application using the News API.

Before we get started building the app, let’s quickly review the resources we’re going to use, Angular and material design, and see why we’ve paired them to build this application?

A news application with Angular 6 and Material Design. (Large preview) What Is Angular?

Angular — according to the official documentation — is described as follows:

“Angular is a platform that makes it easy to build applications with the web. Angular combines declarative templates, dependency injection, end-to-end tooling, and integrated best practices to solve development challenges. Angular empowers developers to build applications that live on the web, mobile, or the desktop.”

In short, it’s the most powerful JavaScript framework for building highly interactive and dynamic web applications.

“As mentioned, Angular is powerful, but also popular, which is why companies such as Upwork, Freelancer, Udemy, YouTube, Paypal, Nike, Google, Telegram, Weather, iStockphoto, AWS, Crunchbase are using it.”

Front-end is messy and complicated these days. That's why we publish articles, printed books and webinars with useful techniques to improve your work. Even better: Smashing Membership with a growing selection of front-end & UX goodies. So you get your work done, better and faster.

Explore Smashing Membership ↬ What Is Google’s Material Design?

Material design is a design language introduced by Google in the summer of 2014 for Android’s new OS. Although its initial focus was touch-based mobile apps, now its functionality has been extended to reach the web design world.

It’s an adaptable system of guidelines, components, and tools that support the best practices of user interface design. It’s also backed by open-source code and supported by a large community of designers and developers who are collaborating together to build beautiful products.

Why Angular And Google’s Material Design Specifically?

It’s a matter of choice. No JavaScript framework is better than another. It’s all about what your project needs. The same goes for programming languages.

Now, I’m not going to outline the benefits and features of Angular. Instead, I’m going to share with you why I’ve picked Angular specifically to build a news application.

As is always the case with any news application, communicating with back-end services over the HTTP protocol is a crucial part. This is where the newer Angular HttpClient module, which is an improved version of the old Http, can help us easily interact with the service API.

The model-view-viewmodel (MVVM) of Angular will be handy when it comes to binding the remote data that will be stored in objects into our application template, where the component plays the part of the controller/viewmodel and where the template represents the view. This is what we call the Angular template language.

The two-way binding system, which means that any changes in the application’s state will be automatically reflected into the view, and vice versa. You’ll notice that when selecting the news resources from the side menu, that will change the state of our news article.

What I like most about Angular is the SPA technology. Loading only the part of the page that needs to be changed will definitely help our application load and perform more quickly and smoothly.

Of course, there are many other benefits and features of Angular, which you can look up with a quick online search.

What About The Visual Aspect?

We’ve chosen material design because its language is a suitable fit for Angular, and it’s easy to implement.

It’s also a very popular visual language; it’s responsive, and most Google apps are built with it. We want our app to look as much like a Google app as possible.

As an introduction, that’s all we need. It’s time to look at the project overview and then jump into the build process.

Project Overview “Getting the latest live news articles from a range of sources, including BBC News, CNN, TechCrunch, Huffington Post and more, along with different categories, like technology, sports, business, science and entertainment.”

This is how your application will look when you finish it:

Project overview. (Large preview)

That should get you excited, shouldn’t it? Let’s start by building the app.

Prerequisites

This is what you’re going to need in order to follow along with this tutorial:

  • Node.js and npm installed on your machine;
  • Angular CLI installed on your machine;
  • A basic understanding of Angular.

Once that stuff is out of the way, we can proceed.

Setting Up The Angular Project

In this section, we’re going to use the Angular command line interface (CLI) to generate a new Angular project. To do so, head over to the CLI and run this:

ng new news-app

Next, point your command line to the project’s root folder by running the following:

cd news-app Installing Dependencies

To set up our dependencies, we’re going to install, with just one command, all of the dependencies necessary for this tutorial. Don’t worry, I’ll explain this in a second:

npm install --save @angular/material @angular/animations @angular/cdk

We have three packages being installed with this command.

@angular/material

This is the official material design package for the Angular framework.

@angular/animations

Installing the Angular animation package separately from the Angular core library is necessary. Certain material components need access to the animation libraries, which is why we’re installing it here.

@angular/cdk

The CDK part stands for “component dev kit”, which provides us with high-quality predefined behaviors for your components, since modern web development is all about components.

It is recommended to include the Angular CDK any time you want to link Google’s material design to an Angular application.

To find out more about Angular CDK, check out this article.

Let’s run our app to see that everything works just fine. You can start a development server by running the following command:

ng serve

Now, if you visit http://localhost:4200/ in a browser, you should see the following page:

Running the Angular project on development server. (Large preview)

Now, in your code editor, navigate to the file /src/app/app.module.ts, and add the following packages that we’ve just installed:

… Other imports … import { BrowserAnimationsModule } from '@angular/platform-browser/animations'; import { MatButtonModule, MatCardModule, MatMenuModule, MatToolbarModule, MatIconModule, MatSidenavModule, MatListModule } from '@angular/material';

It is important to understand what’s going on here. First, we’re importing the animations package to animate our application a bit.

The next import is what’s unique to Angular material. Before, we just included a single material module. Now, we have to import each material component that we intend to use.

As you can see, we’ve added seven different modules here for material buttons, cards, menus, lists toolbars, side navigation, and icons.

After adding those packages to your app.module.ts file, make sure that your file matches the following:

import { BrowserModule } from '@angular/platform-browser'; import { NgModule } from '@angular/core'; import { HttpClientModule } from '@angular/common/http'; import { NewsApiService } from './news-api.service'; import { BrowserAnimationsModule } from '@angular/platform-browser/animations'; import { MatButtonModule, MatCardModule, MatMenuModule, MatToolbarModule, MatIconModule, MatSidenavModule, MatListModule } from '@angular/material'; import { AppComponent } from './app.component'; @NgModule({ declarations: [ AppComponent ], imports: [ BrowserModule, BrowserAnimationsModule, HttpClientModule, MatButtonModule, MatMenuModule, MatCardModule, MatToolbarModule, MatIconModule, MatSidenavModule, MatListModule, ], providers: [NewsApiService], bootstrap: [AppComponent] }) export class AppModule { }

Note: The statement import { HttpClientModule } from @angular/common/http in the file above wasn’t generated automatically, but rather added manually. So, make sure you do that, too. And don’t worry about the NewsApiService service provider because we’re going to take care of that later on.

You might be wondering, though, how did I know the names of the modules to import? The official Angular material documentation gives you the exact code needed to import each module.

If you click on any of the components in the left menu and then click on the “API” tab, it provides you with the exact import line that you need to use.

API reference for Angular Material Component. (Large preview)

In terms of setup, that’s all we need to do before we actually begin using and integrating material components in our templates.

You just have to remember to import each unique component that you plan to use.

Acquiring Free API Key

We’re going to use the News API to feed us some news headlines as JSON data, which we’ll implement in the application template.

What is the News API service?

The News API is a simple HTTP REST API for searching and retrieving live articles from all over the web.

Now that you know what the News API is, the next step is to get a free API Key, which will help us make some call requests to the server and grab the news articles.

You can sign up for just 30 seconds. You’ll only need to provide your first name, email address, and password. That’s all.

After signing up, you’ll find the API key already generated for you in the dashboard. Just save it in a text file somewhere on your desktop; because we’ll use it in the next chapter.

Working On The Components

To start working on the components, you need to create a service provider to manage the interaction with the News API service.

Creating The Service Provider

Enter this command to generate a new service provider:

ng generate service NewsApi

After that, go to the generated /src/app/news-api.service.ts file, and add the following code to it:

import { Injectable } from '@angular/core'; import { HttpClient } from '@angular/common/http'; @Injectable({ providedIn: 'root' }) export class NewsApiService { api_key = 'PUT_YOUR_API_KEY_HERE'; constructor(private http:HttpClient) { } initSources(){ return this.http.get('https://newsapi.org/v2/sources?language=en&apiKey='+this.api_key); } initArticles(){ return this.http.get('https://newsapi.org/v2/top-headlines?sources=techcrunch&apiKey='+this.api_key); } getArticlesByID(source: String){ return this.http.get('https://newsapi.org/v2/top-headlines?sources='+source+'&apiKey='+this.api_key); } }

It’s time to use our API Key. Just paste it where it says, “Put_YOUR_API_KEY_HERE”.

We’ve imported HttpClient, which will be responsible for making API calls to our endpoints and fetching news headlines for us.

Now, for the initSources function, we simply prepare our left-side menu with some news resources. After that, we’ve created another function, initArticles which retrieves the first articles from TechCrunch once the application gets started.

As for the last function, getArticlesByID, it’s going to simply bring some articles for the passing parameter.

The Main Component

The service provider is done. Let’s move to the /src/app/app.component.ts file and add this code:

import { Component } from '@angular/core'; import { NewsApiService } from './news-api.service'; @Component({ selector: 'app-root', templateUrl: './app.component.html', styleUrls: ['./app.component.css'] }) export class AppComponent { mArticles:Array<any>; mSources:Array<any>; constructor(private newsapi:NewsApiService){ console.log('app component constructor called'); } ngOnInit() { //load articles this.newsapi.initArticles().subscribe(data => this.mArticles = data['articles']); //load news sources this.newsapi.initSources().subscribe(data=> this.mSources = data['sources']); } searchArticles(source){ console.log("selected source is: "+source); this.newsapi.getArticlesByID(source).subscribe(data => this.mArticles = data['articles']); } }

We’re defining two properties here: mArticles, for holding news articles, and mSources, for holding news resources. Both are defined as an array.

In the constructor, we’re simply creating a NewsAPIService instance.

Next, we’re using that instance on the ngOnInit() function to initialize our two properties.

For the searchArticles function, it will be triggered whenever the user selects a specific resource from the left-side menu. Then we’re passing this parameter to the getArticlesByID service provider function to retrieves articles for it.

Defining Material’s Default Style

In our /src/styles.css file, which is generated by the Angular CLI, let’s add the following:

@import '~@angular/material/prebuilt-themes/indigo-pink.css'; body { padding: 2em 23em; background:lightgray; }

Based on your preference, you can change indigo-pink.css to:

  • deeppurple-amber.css
  • indigo-pink.css
  • pink-bluegrey.css
  • purple-green.css

I'm also adding some CSS to the body tag, only to demonstrate this layout. This helps it look more like an app, even on desktop.

Let’s also add two lines to our /src/index.html file just before the closing head tag:

<link href="https://fonts.googleapis.com/icon?family=Material+Icons" rel="stylesheet"> <link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Roboto:300,400,500,700,400italic">

The first line imports the material design icon font, and the second one is the Roboto font, which is used by the material design team.

Defining A Template

Let’s start off by adding the following template in the /src/app/app.component.html file:

<mat-toolbar color="primary"> <button mat-button (click)="sidenav.open ()" ><mat-icon>menu</mat-icon></button> <span>News Headlines</span> <span class="example-spacer"></span> <button mat-button [matMenuTriggerFor]="appMenu"><mat-icon>settings</mat-icon></button> </mat-toolbar> <mat-menu #appMenu="matMenu"> <button mat-menu-item> Settings </button> <button mat-menu-item> Help </button> </mat-menu> <mat-sidenav-container class="example-container"> <mat-sidenav #sidenav class="example-sidenav"> <mat-list class="list-nav"> <mat-list-item class="list-item" *ngFor="let source of mSources" (click)="searchArticles(source.id);sidenav.close();"> <div mat-card-avatar [ngStyle]="{'background-image': 'url(../assets/images/'+ source.id +'.png)'}" class="example-header-image"></div> <span class="source-name"> {{source.name}}</span> </mat-list-item> </mat-list> </mat-sidenav> <mat-card class="example-card" *ngFor="let article of mArticles"> <mat-card-header> <div mat-card-avatar [ngStyle]="{'background-image': 'url(../assets/images/'+ article.source.id +'.png)'}" class="example-header-image"></div> <mat-card-title class="title">{{article.title}}</mat-card-title> <mat-card-subtitle>{{article.source.name}}</mat-card-subtitle> </mat-card-header> <img mat-card-image class="img-article" src={{article.urlToImage}} alt=""> <mat-card-content> <p> {{article.description}} </p> </mat-card-content> <mat-card-actions class="action-buttons"> <button mat-button color="primary"><mat-icon>thumb_up_alt</mat-icon> 12 Likes</button> <button mat-button color="primary"><mat-icon>comment</mat-icon> Comments</button> <button mat-button color="primary"><mat-icon>share</mat-icon> Share</button> <a mat-button color="primary" href={{article.url}} target="_blank" ><mat-icon>visibility</mat-icon> More</a> </mat-card-actions> </mat-card> </mat-sidenav-container>

So, what have we done here?

First, we define a toolbar with a left-side menu, along with the application’s main title and the settings’ right menu.

Next, we’re using *ngFor for both sources and articles, and in doing so, our left-side menu will hold the news resources, and the main contents will hold the news articles.

One thing to notice is that on the click event of our list items, we’ve added two functions because that event executes any JavaScript code. The first function is searchArticles, which we’ve already explain, and the second one is sidenav.close() which will automatically close our left-side menu once the user has selected a resource.

Styling Our Component

The last thing to do with the components is to visit the /src/app.component.css file and paste the following code in it:

.example-spacer { flex: 1 1 auto; } .example-card{ margin-top: 4px; } .example-header-image { background-size: cover; } .title{ font-weight: bold; } .img-article{ height: 350px; } .action-buttons{ text-align: center; } .example-container { width: 100%; height: auto; border: 1px solid rgba(111, 111, 111, 0.50); } .example-sidenav-content { display: flex; height: 75%; align-items: center; justify-content: center; } .example-sidenav { padding: 20px; } .source-name { margin-left:5px; } .list-item:hover{ cursor: pointer; background-color: #3f51b5; color: white; } Set Up Images For News Resources

Move to the /src/assets directory, and create a new folder named images. Then, download these images either from a Google Drive link or the GitHub repository.

They are the logos of our news resources. Once you download them, copy and paste all of the image files into the images folder that you just created.

Once everything is complete, run this:

ng serve

Now, your app should look like the screenshot below. Pretty awesome, huh!

Launching the app after everything is complete. (Large preview)

Note that when the news snippets are loaded on the main page, a “More” button (as you can see in the picture above) takes the user to read the whole story.

Conclusion

There you have it! I hope this tutorial was useful and that you’ve enjoyed building this application. If so, feel free to leave your feedback and comments below. In the meantime, the Angular Material documentation is pretty cool. It provides you with an overview of each component, an API and an example.

The entire source code of this app is available on GitHub. You can also check out this website, which already implements the service API used in this tutorial.

(ra, al, yk, il)
Categories: Around The Web

How To Build A Website With The WP Page Builder Plugin

Tue, 10/02/2018 - 7:30am
How To Build A Website With The WP Page Builder Plugin How To Build A Website With The WP Page Builder Plugin Jakub Mikita 2018-10-02T13:30:17+02:00 2018-10-19T07:16:51+00:00

(This is a sponsored post.) WordPress page builders are the first choice for creating a perfect website without any help from a developer. And a new one is on the market that we are going to test in this article. It’s WP Page Builder. We’ll learn how to use this page builder plugin to create a website.

WP Page Builder is a free plugin that integrates with any WordPress theme. You can easily drag and drop elements onto the pages you are building, and you don’t need any coding skills to do so.

At least, that is the developer Themeum’s point of view, which I’ll put to the test in this article. Does the plugin really help us build a website so easily? Are we able to achieve our goals for a website with it? We’re about to find out.

Let’s go through the process of building a real website using the WP Page Builder plugin. We’ll build a website of a few simple pages related to the fictional Rockhedge Park. We’ll learn about the plugin from installation to website launch.

Our goals are to:

  • quickly create the website,
  • create a home page with the park’s features and highlights,
  • create a page to help visitors find the park,
  • create a contact page.

Let’s start with a blank WordPress website, with the Twenty Seventeen theme installed.

(Large preview) Installing The Plugin

WP Page Builder is free, and you can download it from Themeum’s website. It’s also easy to install via WordPress’ admin panel, but because the plugin is new, you’ll have to scroll down the list to find it.

Look for the one with the cool blue “P” icon with a square inside.

(Large preview)

After installation, you will not be bugged with any splash screen, and the only new thing in the admin area you might notice is a new item in the menu. This is the plugin’s general settings page, where you can control a few things such as which post types the plugin should support and who should be able to edit a page with the page builder.

I like that the plugin does not take over the whole admin panel. It’s discreet, and you are not even forced to use it to create pages or posts:

(Large preview)

After clicking the button, you are taken to a new screen where the page builder really makes an appearance.

(Large preview)

The overall look and feel are very good. I particularly like the way the responsive options work; the whole website shrinks with a nice animation when you click the tablet or mobile icon.

All of the content and options you can tweak are on the left side, which is pretty convenient because the editing panels are not mixed up with the actual page content.

What I find not so great are the row and addon toolbar icons. They are just too small, and you cannot really distinguish them from each other without getting closer to the monitor. Also, I had to think a while about the menu items on the left, because the name “Addons” was a bit confusing to me. In this plugin, addons are the pieces of content you place on your website, not premium addons that you can install to make your website even cooler.

Another thing needed is support. There is none. It would be very nice to have some help text, even though the page builder seems to be very easy to use. For example, the “Library” tab doesn’t have any content, and I don’t really know what it is or what I can do with it.

Aside from these small things, I like this editor. Let’s proceed to set up our first page!

Creating The Home Page

By default, you can put the content created with WP Page Builder in one spot, where standard content would appear. While this would be the expected behavior with most themes, it’s not in my case. I don’t want my content to be squished together in the default template:

(Large preview)

This is probably why the plugin comes bundled with a page template called WP Page Builder Template. It spreads the content you build across the whole page, and only the header and footer of the theme are used.

The content looks way better now. I think this page builder could fit into any theme using this page template.

(Large preview)

OK, the theme is installed, the page builder is installed, and the page is prepared. What do we do next? I’m sure you’ve been in this position when using page builders before; you just don’t know what to do with the page. You don’t even know what you can do with the page. It’s the standard “blank canvas” problem.

However, I discovered something called “Layouts” in the plugin’s sidebar. And the way it works impressed me.

Page Layouts

Page layouts are complete pages, ready to be imported in your WordPress website. Sounds cool, doesn’t it? Watch this:

(Large preview)

As you can see, there are many templates, and most of them are paid. A few are free, though, and you can use them to get some inspiration.

The best part with this importing is that it doesn’t bloat WordPress. You can wipe out the page content with two clicks, and nothing is left. Even the images are not loaded to WordPress’ library.

You can test many concepts and options, and adjust everything to your needs without ending up with a ton of unused things imported into your WordPress installation. I really like that.

Composing The Home Page

My initial idea for the home page was a few images of the park and some features highlighted.

After getting inspired by the layouts prepared by Themeum, I started with a header image, and I created my other pages, as well as the main navigation.

I decided not to use any layouts because the blocks and addons are very simple to use, and they come with default content.

I started with a big image section just beneath the header, with a fixed background and a generic title.

(Large preview)

Configuring this section was very easy, but I had some trouble with the custom font for the headings. I figured out that I have to remove my previous selection, and then I’m able to pick a new font family.

One thing I like is the way you can adjust the addon’s padding live on the screen:

(Large preview)

For the next section, I decided to use a predefined content block, which looks perfect for me. Adding it to the page is also very simple: Just drop it in the desired spot, and adjust the sample content.

(Large preview)

Filling in the content was a breeze, and I quickly reached the last section, the call to action. There, I used the call-to-action block with very simple content.

(Large preview)

Et voilà! The process of creating the page was very simple, and I enjoyed it.

Creating The “Find Us” Page

The next page is the one where people can easily find our park. This involved the use of more advanced sections, like a map.

Unfortunately, the map addon isn’t available in the free version of the plugin, so I decided to write that one myself and see how the plugin’s code base looks.

The code is not bad at all. It’s clear and easy to read, despite the fact that there are almost no inline comments. I haven’t found any documentation whatsoever, so I had to dig in to see how I could extend the plugin. And it didn’t look like I needed much — just an addon class and filter.

Custom Google Map Addon

When you don’t have any documentation, the best approach is to copy and adjust existing code.

A lot of configuration options seem to be available, some of which really need strong documentation. But for our case, we’ll make a simple Google Map iframe using a Google API key, with a place to query and the iframe’s height.

This is what our class looks like:

class JakubMikita_Addon_GoogleMap{ public function get_name(){ return 'jakubmikita_googlemap_block'; } public function get_title(){ return 'Google Map'; } public function get_icon() { return 'wppb-font-location-map'; } // Google Map block Settings Fields public function get_settings() { $settings = array( 'apikey' => array( 'type' => 'text', 'title' => __('Google Maps API key','wp-pagebuilder'), ), 'place' => array( 'type' => 'text', 'title' => __('Map place','wp-pagebuilder'), ), 'height' => array( 'type' => 'number', 'title' => 'Height', 'unit' => array( 'px','em','%' ), 'responsive' => true, 'std' => array( 'md' => '500px', 'sm' => '500px', 'xs' => '500px', ), 'tab' => 'style', 'selector' => '{{SELECTOR}} iframe { height: {{data.height}}; }', ), ); return $settings; } // Google Map Render HTML public function render($data = null){ $settings = $data['settings']; $apikey = isset($settings['apikey']) ? $settings['apikey'] : false; $place = isset($settings['place']) ? $settings['place'] : false; $output = ''; return $output; } // Google Map Template public function getTemplate(){ $output = ''; return $output; } }

Looks simple, right? At the top, we have three methods that identify the addon: name, title and icon.

The next method, get_settings(), is where we define all of the user inputs. We define them as an array; I just looked at other addons to figure out the fields I can add. Pretty simple and easy to implement.

I figured out that the next method, render(), is used on the front end. It gets all of the user settings and returns the map iframe.

The last method, getTemplate(), is used on the page builder screen. Having two methods render the same code is not great, but I suppose the reason for it is that the second one has to be parsed with JavaScript.

Another thing that would work better is the method of registering an addon. If this were a more advanced addon, I’d want to include the CSS and JavaScript in separate files. Not very convenient, but also not the end of the world.

The last thing we have to do to register the addon is include it in the array, which we can do with a simple filter:

add_filter('wppb_available_addons', function( $addons) { $addons[] = 'JakubMikita_Addon_GoogleMap'; return $addons; } );

That’s all. The process is quick and simple. Here is our custom addon:

We’ve now got an awesome full-page map on this page.

Creating The “Contact Us” Page

For the last page, let’s put a contact form. I was about to install one of the popular contact form plugins when I noticed the “Form” addon. I gave it a try.

Surprisingly, when I dropped the addon onto the page, I saw all of the fields I wanted already configured and aligned nicely.

(Large preview)

The most interesting part is that WP Page Builder integrates with the Contact Form 7 and weForms plugins. You can even add a simple CAPTCHA or use Google’s reCAPTCHA after providing the website’s keys.

Very cool addon. Submissions to the form come to my inbox without any problem, including all of the fields, and the user sees a nice confirmation message upon submitting the form.

Summary

I must say that WP Page Builder is a solid plugin. Obviously, it have some flaws, but it’s still a young product, and I’m sure Themeum will fix all of the bugs and implement the improvements mentioned in this article.

The overall feel of the plugin is great. The plugin does most of the heavy lifting, and you don’t have to think about how to do what you want because it’s mostly already done. The default content does a really good job and speeds up the work.

Themeum is right: Building a page with its plugin is simple, but not because the plugin is basic. The plugin is intuitive, yet packed with cool addons.

I used only a few of the addons, but the plugin comes with a lot more. Blocks you’d normally spend hours trying to figure how to implement are a drag-and-drop away when using the WP Page Builder plugin.

For example, progress bars, social icons, testimonials and flipping content boxes are ready and waiting to be used. It’s hard to convey the experience in writing. You just have to install the plugin and see for yourself.

(ms, ra, al, il)
Categories: Around The Web

The New Framer X: Initial Impressions

Mon, 10/01/2018 - 7:30am
The New Framer X: Initial Impressions The New Framer X: Initial Impressions Lachezar Petkov 2018-10-01T13:30:03+02:00 2018-10-18T07:57:13+00:00

The Framer team recently released a new prototyping tool, Framer X, and I was lucky enough to be able to test it during the beta phase. In this article, I’d like to share my thoughts about this new tool and its features. I’ll make a comparison with the “legacy” Framer app as well as other tools, and I’ll discuss its brand new features such as Stacks and Scroll, and its new Code and Design components.

This article is intended for UI and UX designers who would like to learn more about Framer X’s prototyping abilities. Since it is (in many ways) a brand new product, you don’t need to be familiar with the older Framer application to read along. However, a little bit of familiarity with HTML, CSS, React, JavaScript and Node.js are beneficial.

For the purpose of this tutorial, I have also created a prototype which is a Material exploration of the Khan Academy’s app for Android.

Note: I’m in no way affiliated with Khan Academy; I just thought this would make a cool experiment — I hope you’ll agree.

Intro To Framer X

Framer X goes a few steps further than its predecessor in trying to bridge the gap between interface design and software development. Here’s how:

Dear Designers, Meet React

The key difference between the old and the new applications in this regard is the introduction of React and JavaScript / TypeScript, as opposed to using CoffeeScript for programming microinteractions and animations, loading data, and so on.

Framer X’s most important feature: It integrates tightly with ReactJS. (Large preview)

During the beta phase, people wrote some React components that I think show us the potential of how far the tool can take us. For example, you can embed actual media players (that actually stream and play music and video) within your prototypes. Or, you can embed graphs with real-time stock market data. Or how about a component that can translate your prototype’s UI into other languages. And that’s not all: Things are just getting started.

Meet SmashingConf New York 2018 (Oct 23–24), focused on real challenges and real front-end solutions in the real world. From progressive web apps, Webpack and HTTP/2 to serverless, Vue.js and Nuxt — all the way to inclusive design, branding and machine learning. With Sarah Drasner, Sara Soueidan and many other speakers.

Check all topics and speakers ↬

The same React code you write for a Framer X prototype could — at least hypothetically — be used in a production environment after the design phase. This can be especially useful for teams that do a lot of web development in React (and perhaps for teams who write mobile apps in React Native). Personally, I shudder at the thought of me, a designer, writing any code that goes into production, but that might work for others.

“Framer X is more like Unity than like Photoshop. An IDE for design, if you will.”

—The Framer X documentation The Framer X Interface

If you are already a Framer user, the first thing you’d notice is that the integrated code editor is gone. Instead, if you want to write any code, you can use an editor of your choice. Most people (including myself) seem to go with VS Code.

Framer X (Large preview)

There are four tabs in the sidebar:

  • Tools
    Opens all the layout and drawing tools everyone’s familiar with (shapes, path, text, frames) as well as three new toys we’ll discuss a little later: Stacks, Link, and Scroll.
  • Layers
    Contains, well, the layers of the selected frame, as well as its properties (color, position, border, shadow and so on). This bit is essentially the same as in the old Framer, and very similar to Sketch and Figma.
The Framer X Layers panel. (Large preview)
  • Components
    This is for any Design or Code components you may have in the file you’ve opened.
  • Store
    A new, huge feature in Framer X. It allows users to publish their creations — be it icons and illustrations or interactive code components for others to use. Currently, all components are free of charge, but I’d imagine people will be able to sell their stuff at the store in the future.
The Framer X Store (Large preview)

The Preview and Live Preview buttons are up at the top right corner. As with legacy Framer, you can preview your prototypes within a device picture for more realism, or preview them directly on an actual device, or in a browser.

Recommended reading: Learning Framer By Creating A Mobile App Prototype

Prototyping With Framer X A Few Thoughts On The Prototype We’ll Create

The Khan Academy Android app isn’t a Material app, so let’s explore how it might look and behave if it was. I want to think of this as if it were a real-world project, so here are a couple of considerations that we’ll see how to handle in Framer X:

  1. The product’s goal is to provide free education for everyone, thus it must be able to run on old and cheap devices. What this means for the design of the prototype is, it has to work on 320dp wide screens.
  2. The design must adapt well when the app is translated into a language more verbose than English.

The first thing I’m going to do is mock up the Home screen. There are four things I want to be prominent:

  • A search input;
  • Something that will show me my most recent activity;
  • Something that will show me my Missions;
  • Something to notify me if there’s a new Mastery Challenge.

Let’s begin.

Installing Components From The Store

The first two elements I want to have here are the Android status bar and navigation bar. Instead of drawing them myself, I’ll quickly install a component bundle from the store called “Android Kit”. It contains all sorts of (static, not programmed in this case) elements like buttons, cards, switches, bars, keyboards and so on. I got my status bar and my nav bar in seconds:

Adding a component from the Store

Note: Each component is installed per-project.

The Interactive Scroll Tool

Now, if I were doing this in Sketch, I’d continue mocking up the rest of the elements on the same artboard, and if it can’t fit all elements, I’d make it taller. In Framer X, however, things work a little differently. I’ll have the content of the Home screen within a separate frame (screen/artboard) and link that frame so it scrolls beneath the navigation and status bars of the home screen:

Using the Scroll tool

Now when I run a preview, my content is scrollable:

The Scroll tool in action

Awesome! With the underlying work out of the way, I’m ready to increase the fidelity a little bit. First, I want the general style of the app to be soft and welcoming, so I’ll use 4dp (display points) border-radius for my cards and buttons, and the rounded Material icons.

Since having an actual search input is super important for this screen, I don’t want the regular Android App bar and search icon experience. I’ll go for an actual input with a CTA message along with a hamburger icon ala Google Maps.

The app bar and search input for this prototype (Large preview)

If I were to go deeper here, I’d make this bar a code component and write it so it expands to full width on scroll, like this:

The app bar, expanded on scroll (Large preview)

I won’t do that for the purpose of this article, but I have to say I think something as simple would be easier to do in legacy Framer compared to Framer X — at least in this first version.

Linking

Let’s add some basic interactivity to this thing! When I tap on the search input, I want it to pull out a keyboard from the bottom. When I tap on the menu icon, however, I want to pull out a Navigation drawer from the left side.

Whereas in legacy Framer I’d have to write a FlowComponent for this type of thing, it’s now super easy in Framer X and with its new Link tool! It’s similar to other prototyping applications in which I’d select a UI element, link it to a frame, and choose the type of transition I want. I imported the keyboard from the Android Kit component and linked to it from the search input. I set the transition to Overlay and the direction to bottom.

Once you link two frames, you can configure the link through the Links panel. (Large preview)

Because I have too many items in the navigation drawer to fit on a screen, I had to split it into two frames just like the Home screen: one container with a scroll layer linked to a frame with the actual content inside. Here’s how that looks:

The 'Birdseye' view of all linked frames in the prototype so far (Large preview)

Interacting with the prototype

Neat! There is a problem with this approach, though, that the Framer team will hopefully fix. When the transition of a frame is set to Overlay, it covers and dims everything beneath it. This isn’t quite what we want when we prototype for Android: The nav bar and status bar have to be above all other screen elements — including the overlays.

Same goes for the Search interface: I don’t want any screen dimming if I want to have filtering options and/or a list of recent queries when the keyboard is pulled out. Hopefully, we’ll see some fixes for these issues in future Framer X versions.

Pinning, Positioning, And Responsiveness

Back to the Home screen of the prototype. Below the search input, I want a list with my recent activity. Just as in legacy Framer and other design tools, you can pin elements within frames so they move and scale exactly as you want them to. Framer X also shows you distances and gaps between elements, snaps them together for you, and so on. Have a look:

Once my frames are pinned appropriately, designing responsively is very easy. Design Components

I want to add a few more things to the prototype home screen: A Mastery Challenge prompt, a streak counter, list of missions, bookmarks and some UI that allows the user to explore content they might find cool or useful.

Since the recent missions and the bookmarks are going to be cards with very similar content, the best solution Framer X has for me is to use design components. I already mentioned them above (the Material Kit component bundle). Framer X’s design components work similarly to Sketch’s symbols and Figma’s components.

To convert a frame to a component, simply press Cmd + K. This creates a Master from which you can create as many instances as you want:

A Master component and its instance: Any changes applied to the Master are applied to the Instance, but not the other way around.

Anything you do to a Master component will affect its instances, but whatever you do to the instances won’t affect the Master. You can also nest Master components and go as crazy as you like.

So, here are my Recent missions and Explore sections:

Recent missions and Explore sections as horizontally scrollable frames. (Large preview)

Each section is a frame, connected to its own scroll component, and populated with components. The text strings (as well as the bitmap images in the instances) are overrides.

Stacks

Now, what if I’m not sure how to position and distribute all these cards? Well, Framer X’s Stacks feature comes into play here:

I only had to make sure that all items I wanted into a Stack are organized into frames. It works surprisingly well, and you can have components within a stack, as well as a stack within another stack, and so on. It’s huge for anyone mocking up and prototyping lists often!

Drawing Icons And Illustrations

The drawing tools in Framer X are pretty much the same as in legacy Framer. They’re good enough to do a lot, but still somewhat lagging behind Sketch’s: There are no rulers; you can’t convert strokes to outlines; you can’t flatten shapes; there’s no scissors tool.

Code Components Creating A Simple Code Component

Finally, let’s take a closer look at the code components. Again, these are regular React components (both Stateless and Class) that can be written in either JavaScript or TypeScript (up to you). You can also install third-party libraries to use within your components in Framer.

Let’s try and use the popular styled-components library. This will allow us to style our component using actual CSS syntax within the .tsx file.

First, go to the Components tab → New Component → from Code. After you name your component and confirm, your default system editor (in my case, VS Code) will open an example Framer X component file.

Now go to File → Show project folder, open a terminal in that same folder, install yarn if you haven’t already and add styled-components to your Framer project: $>yarn add styled-components

The library and its dependencies will be added to your package.json and you’re ready to go.

Here’s the source for my styled-components button, after I replaced the default code in my component’s .tsx file:

The Go button as a code component and its source (Large preview)

Note that the button label is customizable directly through the Framer X interface (because of the Framer library’s PropertyControls feature). Having my button written in code obviously has many advantages. It is customizable, responsive, and interactive. Along with the responsive paddings, it’s super easy to test if the design breaks in other languages.

The responsive Go button, translated quickly by changing the Text property directly in the Framer X UI. (Large preview) Importing A Code Component From The Store

There’s a lot of video content on Khan Academy, so for my prototype, I want to open a video lesson. Instead of mocking up a ‘fake’ video player, I can directly embed an actual YouTube player in my prototype. There’s already a component in the Store for this purpose:

Playing a Khan Academy video in a Khan Academy prototype

You can fork the code of any Store component and edit it as you like. For now, the only way to do this is to right-click on it in the sidebar, copy its code and paste it in a newly created components’ file.

You can copy every Store component’s code and play with it. (Large preview) Code Overrides And The Framer library

The Framer JavaScript library has now been ported to work with Framer X and React. As with the legacy Framer library, it provides us with tools (helper functions) to animate our designs and to listen to events (simple things like onClick and onMove, but also advanced events like pinch, whether the device has been rotated or whether an animation has ended, and more).

Code Overrides are bits of code (JS functions) that allow you to change any frame’s or component’s properties. Static changes such as color are applied before you run the preview, directly within the Framer app, and the animations/interactions can be seen in the Preview window or on your preview device.

Let’s have a quick look at one of the simplest and default examples. I drew this simple champions cup illustration for one of the prototype cards, and I decided to animate it:

The static Mastery Challenge card (Large preview)

To add an override, I have to select my target frame (in this case the illustration) and click on the Code menu item in the right sidebar. Now I need to select the override I want from Exampels (selected by default in the drop down):

The Scale code override will provide me with a fun scale animation. I can edit it’s code and adjust as I like.

Remember, overrides are just blocks of code, therefore, they can live in any file within your project. What I just selected was the Examples.tsx file which contains multiple functions for Scale, Rotation, Fade, and so on. I can create my own file and write my own Override functions, or include them in my code components source code — just as long as I keep in mind to use the Override type specifier when I export them.

Here’s the source code for the Scale override I chose:

export const Scale: Override = () => { return { scale: data.scale, onTap() { data.scale.set(0.6) animate.spring(data.scale, 1) }, } }

In plain English: Set the initial scale value of the frame down to 0.6, then animate the scale to 1 with spring curve. Finally, export it with name Scale and specify that it is an Override.

Once applied, this is the result:

The Mastery Challenge card with some animation Design Responsiveness

As I mentioned in the beginning, it is essential for this particular prototype to work on small device screens (320dp). This is very easy to test in Framer X (considering you’ve pinned your UI elements properly, as described above). Simply set the Preview mode to Canvas - Responsive:

Framer X makes it easy to test my designs for different screens.

This is super helpful — I am now aware of what problems my designs have on smaller screens, and I’m ready to come up with fixes for the next iteration!

Day And Night Modes

Finally, in Framer you have two themes: Light, called “Day” mode:

Framer X during the day (Large preview)

And dark, called “Night” mode:

Framer X at night (Large preview)

You can switch the two from the Window menu.

Protoype: Final Result

Here are all my frames linked together:

All my frames linked together (Large preview)

And here’s the prototype in action:

What I Like About Framer X

The application performs fast (though the beta choked a little with large project files) and it feels well designed. It’s a new tool, yet at the same time, it feels familiar. It also does give me that sense of it being a ‘design IDE’ and I think the Framer team is taking things in a very interesting direction.

Framer X makes mundane things like linking screens and scrolling fast and easy, as they should be. Though I hope to see even more of that type of thing in the future: prototyping is supposed to be a quick and dirty process, after all. To spend too many hours on a prototype is to miss the point of prototyping.

Having a Components Store is a great idea, and will certainly speed up my design process. I no longer have to spend time hunting down the plugins I need. I can imagine a couple of years from now there will be thousands of components with basically everything I need to put something relatively advanced together — relatively quickly. It may need some moderation in the future, though. I can see people uploading too many simple buttons, each a fork of the other, just because they can.

I like the focus on design systems through the components and the Private Store features. We all know, many teams struggle to collaborate meaningfully and tools like these are an immense help.

What I’m Not Sure I Like About Framer X

What worries me a little is that part of the “super easy playground for experimentation” experience of the original Framer tool is somewhat gone. The new features in X make it very easy to quickly prototype any “standard” feature or screen: you have all you need in the Store. But it is arguably more difficult to explore crazy and weird ideas for custom interactions — at least with this initial product release.

Learning React will be more intimidating to a lot of us, math and logic-impaired designers. For me personally, code reuse is not an option, since none of the projects I’m currently working on are built using web technologies. But even if it was an option, I’m thinking about programming in terms of it being a tool to express my design ideas. I’m not an engineer; using my code for anything but a prototype is not exactly a terrific idea.

Having said that, there’s a lot more documentation on JavaScript and React than on CoffeeScript. There’re also more people to help out, and the React community seems pretty welcoming. I’m very curious to see how Framer X will help designers and engineers collaborate more — if at all.

Framer X In My Toolset

I’ll definitely be using Framer X in production, but I can’t see it completely replacing Sketch for me just yet. In my organization, each designer is allowed to use their favorite tool, as long as it integrates with Zeplin, and Framer X doesn’t. Other things it lacks compared to Sketch (for now) are the pages, the crazy amount of plugins, and the more powerful drawing tools.

I will continue to use the original Framer for custom interactions — at least for the foreseeable future. When prototyping, things need to be done fast, and I also still have much to learn about React.

(mb, ra, yk, il)
Categories: Around The Web

October Magic For Your Desktop (2018 Edition)

Sun, 09/30/2018 - 3:00am
October Magic For Your Desktop (2018 Edition) October Magic For Your Desktop (2018 Edition) Cosima Mielke 2018-09-30T09:00:00+02:00 2018-10-17T07:01:06+00:00

The leaves are shining in the most beautiful colors and pumpkins are taking over the front porches. Time to welcome the spookiest of all months: October! To get your desktop ready for fall and the upcoming Halloween season, artists and designers from across the globe once again challenged their creative skills and designed inspiring desktop wallpapers for you to indulge in.

As usual, the wallpapers come in versions with and without a calendar for October 2018 and can be downloaded for free. And since so many inspiring, beautiful, and unique artworks evolve around our little wallpapers challenge every month, we once again dived into our archives to find some timeless October classics from past years to add to this collection. Because, well, some things are just too good to be forgotten, right? Enjoy!

Please note that:

  • All images can be clicked on and lead to the preview of the wallpaper,
  • You can feature your work in our magazine by taking part in our Desktop Wallpaper Calendar series. We are regularly looking for creative designers and artists to be featured on Smashing Magazine. Are you one of them?
Further Reading on SmashingMag:

Meet Smashing Book 6 — our brand new book focused on real challenges and real front-end solutions in the real world: from design systems and accessible single-page apps to CSS Custom Properties, CSS Grid, Service Workers, performance, AR/VR and responsive art direction. With Marcy Sutton, Yoav Weiss, Lyza D. Gardner, Laura Elizabeth and many others.

Table of Contents → Shades Of Gold

“We are about to experience the magical imagery of nature, with all the yellows, ochers, oranges, and reds coming our way this fall. With all the subtle sunrises and the burning sunsets before us, we feel so joyful that we are going to shout it out to the world from the top of the mountains.” — Designed by PopArt Studio from Serbia.

Flying Home For Halloween

“You can only fully master the sky wearing an aviator hat and goggles. Like this little bat, flying home to celebrate Halloween with his family and friends.” — Designed by Franke Margrete from the Netherlands.

Strange October Journey

“October makes the leaves fall to cover the land with lovely auburn colors and brings out all types of weird with them.” — Designed by Mi Ni Studio from Serbia.

Ghostbusters

Designed by Ricardo Gimenes from Sweden.

Trick Or Treat

Designed by Mad Fish Digital from the USA.

Hello Fall

“Leaves are falling from the trees in all kinds of beautiful colors.” — Designed by Melissa Bogemans from Belgium.

Halloween Candy

Designed by Ilse van den Boogaart from the Netherlands.

The Pleasure In Travelling

“Travel makes you humble by letting you see the tiny place you occupy in the world. An individual with ordinary talent will always be ordinary, whether he or she travels or not; but a person with superior talent will go to pieces if they remain forever in the same place.” — Designed by Mindster from India.

Love And Life

“Mahatma Gandhi is remembered for all his great deeds and words of wisdom. Though he never lived his life peacefully, he always remained proactive in removing the social evils of our society. So let’s devote this month in the memory of this great man and recall all his good deeds as well as learning which he left behind for the world to follow.” — Designed by Aufait Technologies from India.

That New Car Smell

Designed by Luka Dadiani from the United Kingdom.

Experience The Magical Mirage

Designed by Sweans from London.

Exclusively Fall

“When I think of October the real beginning of the fall season comes to mind. It was difficult to narrow down what symbols I wanted to use to represent the season and how to sort out which ones would work into a collective theme. I decided using textures and objects found in nature itself would make the most sense for my theme. By ‘carving’ symbols into the natural texture of wood and showing the change of season with the coloured leaves I hope I was able to capture the essence of fall.” — Designed by Sarah Stevens from Canada.

Oldies But Goodies

Creepy Halloween fellows, a nice cup of tea on a rainy day, and the magic of the fall forest — October has its very own charm. And, well, the treasures we rediscovered in our Wallpapers archives pay tribute to all those big and small October moments. Please note that these wallpapers don’t come with a calendar.

Haunted House

“Love all the Halloween costumes and decorations!” — Designed by Tazi from Australia.

A Very Pug-o-ween

“The best part of October is undoubtedly Halloween. And the best part of Halloween is dog owners who never pass up an o-paw-tunity to dress up their pups as something a-dog-able. Why design pugs specifically in costumes? Because no matter how you look at it, pugs are cute in whatever costume you put them in for trick or treating. There’s something about their wrinkly snorting snoots that makes us giggle, and we hope our backgrounds make you smile all month. Happy Pug-o-ween from the punsters at Trillion!” — Designed by Trillion from Summit, NJ.

Tea And Cookies

“As it gets colder outside, all I want to do is stay inside with a big pot of tea, eat cookies and read or watch a movie, wrapped in a blanket. Is it just me?” — Designed by Miruna Sfia from Romania.

Hello, Autumn, I’m Glad to See You Again

Designed by Lívi from Hungary.

Omnomnomtober

“I’m just a sucker for Halloween, candy, tiny witches and giant kittens. And you can’t tell me that October is not Halloween, because I’ve waited the whole year for this. I thought that I would make illustration central to this calendar so I started with the idea of a tiny witch who’s stolen a ton of candy along with her cat — who’s gotten herself in trouble and can’t unstick the bubble gum from her giant teeth. A typical Halloween scene, right?” — Designed by Kalashniköv from Spain.

Dope Code

“October is the month, when the weather in Poland starts to get colder, and it gets very rainy, too. You can’t always spend your free time outside, so it’s the perfect opportunity to get some hot coffee and work on your next cool web project!” — Designed by Robert Brodziak from Poland.

Summer, Don’t Go!

“It would be nice if we could bring summer back, wouldn’t it?” — Designed by Terezija Katona from Serbia.

Boodoni

“This wallpaper was inspired by the creepy crawlies of Halloween, animation concept art, and hand-drawn type.” — Designed by Todd Marcinkiewicz from the United States.

My Spooky Love

“Halloween can be a season of love too. This undead bunny is a combination of different inspiration from sugar skulls, cute characters and patterns that I have been drawing in my “Year of Creative Habit” project.” — Designed by Morningmobi from Brunei.

A Positive Fall

“October is the month when fall truly begins, and many people feel tired and depressed in this season. The jumping fox wants you to be happy! Also, foxes always have reminded me of fall because of their beautiful fur colors.” — Designed by Elena Sanchez from Spain.

Autumn In The Forest

“Autumn is a wonderful time to go for walks in the forest!” — Designed by Hilda Rytteke from Sweden.

October Gifts

“I was inspired by autumn and those gifts it presents to us in the form of beautiful colors, unusual shapes and mysterious weather. So enjoy October!” — Designed by Juliagav from Ukraine.

Autumn Is The New Spring

“Who says Autumn isn’t fun? It’s the new Spring, after all!” Designed by Marina Zhukov from the USA.

Watercolor Autumn

“There is nothing like being surrounded by beautiful, fiery, natural art for 2.5 months every year. This piece was inspired by the Falls I remember back in my New England hometown.” Designed by Rachel Ladew from the USA.

Autumn Deer

Designed by Amy Hamilton from Canada.

Roger That Rogue Rover

“The story is a mash-up of retro science fiction and zombie infection. What would happen if a Mars rover came into contact with an unknown Martian material and got infected with a virus? What if it reversed its intended purpose of research and exploration? Instead choosing a life of chaos and evil. What if they all ran rogue on Mars? Would humans ever dare to voyage to the red planet?” Designed by Frank Candamil from the USA.

Limbostyle

“This is my tribute to the awesome and beautifully designed videogame ‘Limbo’. Enjoy and share if you like this drawing.” Designed by Jonas Duri.

Spooky Town

Designed by Xenia Latii from Germany.

Halloween Cat

Designed by Mohamad Khatib from Lebanon.

Crow

Designed by Rumake Web Agency from Russia.

Ghostober

Designed by Ricardo Delgado from México City.

Join In Next Month!

Please note that we respect and carefully consider the ideas and motivation behind each and every artist’s work. This is why we give all artists the full freedom to explore their creativity and express emotions and experience throughout their works. This is also why the themes of the wallpapers weren’t anyhow influenced by us, but rather designed from scratch by the artists themselves.

Thank you to all designers for their participation. Join in next month!

Categories: Around The Web

Privacy By Design: How To Sell Privacy And Make Change

Fri, 09/28/2018 - 7:50am
Privacy By Design: How To Sell Privacy And Make Change Privacy By Design: How To Sell Privacy And Make Change Joe Toscano 2018-09-28T13:50:13+02:00 2018-10-16T10:09:16+00:00

Privacy is a fundamental human right that allows us to be our true selves. It’s what allows us to be weirdos without shame. It allows us to have dissenting opinions without consequence. And, ultimately, it’s what allows us to be free. This is why many nations have strict laws concerning privacy. However, in spite of this common understanding, privacy on the Internet is one of the least understood and poorly defined topics to date because it spans a vast array of issues, taking shape in many different forms, which makes it incredibly difficult to identify and discuss. However, I’d like to try to resolve this ambiguity.

In the United States, it is a federal offense to open someone’s mail. This is considered a criminal breach of privacy that could land someone in prison for up to five years. Metaphorically speaking, each piece of data we create on the Internet — whether photo, video, text, or something else — can be thought of as parcel of mail. However, unlike opening our mail in real life, Internet companies can legally open every piece of mail that gets delivered through their system without legal consequence. Moreover, they can make copies of it as well. What these companies are doing would be comparable to someone opening our mail, copying it at Kinkos, then storing it in a file cabinet with our name on it and sharing it with anyone willing to pay for it. Want to open that file cabinet or delete some of the copies? Too bad. Our mail is currently considered their property, and we have almost no control over how it gets used.

Could you imagine the outrage the public would experience if they found out that the postal service was holding their mail hostage and selling it to whoever was willing to pay? What’s happening with data on the Internet is no different, and it’s time this changes.

It’s more than just a matter of ethics that this happens, it’s a matter of basic human rights.

The problem with making the changes that need to be made (without changes being forced into place by regulation) is putting dollar signs to the issues. What is the financial return on a 20,000-hour engineering investment to improve consumer privacy standards? Are consumers demanding these changes? Because if it doesn’t make a fiscal return and consumers aren’t demanding it, then why should change be made? And even if they are and there is a return, what does 20,000 hours of investment even look like? What is going to be put on the product roadmap and when? These are all valid concerns that need to be addressed in order to help us move forward effectively. So, let’s discuss.

Recommended reading: Using Ethics In Web Design

Meet SmashingConf New York 2018 (Oct 23–24), focused on real challenges and real front-end solutions in the real world. From progressive web apps, Webpack and HTTP/2 to serverless, Vue.js and Nuxt — all the way to inclusive design, branding and machine learning. With Sarah Drasner, Sara Soueidan and many other speakers.

Check all topics and speakers ↬ Do Consumers Want It?

The answer to this question is a hard yes. Findings by Pew Research Center show that 90 percent of adults in the United States believe it is important that they have control over what information is collected about them, 93 percent believe it’s important they can control who has access to this information, and 86 percent have taken steps to remove or mask their digital footprints. Similar numbers were discovered about Europeans in doteveryone’s 2018 Digital Attitudes report. Despite these numbers, 59 percent still feel like it is impossible to remain anonymous online, 68 percent believe current laws do not do enough to protect their privacy, and only 6 percent are “very confident” that government agencies can keep them secure.

Now, I know what you’re thinking. This is consumer demand, and until those consumers start leaving old products behind, there’s no fiscal reason to make any change. And (although I don’t agree with your logic) you’re right. Right now there is little fiscal reason to make any change. However, when consumer demand reaches a critical mass, things always change. And the businesses that lead the way before the change is demanded always win in the long run. Those who refuse to make a change until they’re forced to always feel the most pain. History shows this to be the truth. But what’s going to happen in legislation that will change business so much? Great question.

What’s about to happen to data protection and privacy standards across the world, through regulation, will not be so different than what occurred less than a decade ago when consumers demanded protection from spam emails, which resulted in the CAN-SPAM Act in the United States — but on a much greater scale, and with exponentially greater impact. This legislation, which was created because consumers were sick of getting spam emails, set the rules for commercial email, established requirements for commercial messages, gave recipients the right to have individuals and companies stop emailing them, and spelt out tough penalties for violations. As we enter a period where consumers are beginning to understand just how badly they’ve been deceived (for years, giving people intimate control of their data will undoubtedly be the future of data collection) — whether that be through free will or legislation. And those who choose to move first will win. Don’t believe me?

Consider the fact that engineers can get in legal trouble for the code they write. Apple Watch, Alexa, and FitBit data, among others have been used as evidence in court, changing consumer perception of their data. Microsoft and the Supreme Court of the United States went to court earlier this year to define where physical borders extend in cloud-based criminal activity, the beginning of what will be a long fight. These examples are just a peek into what’s coming. The people are demanding more, and we’re reaching the tipping point.

The first to take steps to respond to this demand is the EU, which established the GDPR, and now policymakers in other countries are beginning to follow suit, working on laws in their country to define our cyber future. For example, United States Senate Intelligence Committee Vice Chairman, Mark Warner recently laid out some of ideas in a summary report just a couple months ago, demonstrating where legislation may soon be headed in the States. But it’s not just the progressives who believe this to be the future; even right-wing influencers like Steve Bannon think we need regulation.

What we’re seeing is a human reaction to incredible manipulation. No matter how domesticated we may be compared to previous generations, people will always push back when they feel they’re being threatened. It’s a natural reaction that has allowed us to survive for millennia. Today, tech has become more than just a consumer-facing industry. It is now also becoming a matter of national security. And for this reason, there will be a reaction whether we like it or not. And it will be better if we come out with a strategy to prepare instead of getting swept under the rug. So, what’s the financial return you ask? Well, how much is your business worth? That’s how much.

Recommended reading: How GDPR Will Change The Way You Develop

For a simple framework of what exactly needs to be addressed and why, we can hold several truths to be foundational in the creation of digital systems:

  1. Privacy must be proactive, not reactive, and must anticipate privacy issues before they reach the user.
    These issues are not issues that we want to deal with after a problem has come to life but are instead issues we want to prevent entirely, if possible.

  2. Privacy must be the default setting.
    There is no “best for business” option in regards to privacy; this is an issue that is about what’s best for the consumer, which, in the long run, will be better for the business. We can see what happens when coercive flaws are exposed to the public through what happened to Paypal and Venmo in August 2018 when Public by Default was released to the public, bringing a smattering of bad press to the brand. More of this is sure to come to the businesses that wait for something bad to happen before making a change.

  3. Privacy must be positive sum and should avoid dichotomies.
    There is no binary relationship to be had with privacy; it is a forever malleable issue that needs constant oversight and perpetual iteration. Our work doesn’t end at the terms and service agreement, it lasts forever, and should be considered a foundational element of your product that evolves with the product and enables consumers to protect themselves — not one that takes advantage of their lack of understanding.

  4. Privacy standards must be visible, transparent, open, documented and independently verifiable.
    There’s no great way to define a litmus test for your privacy standards, but a couple of questions we should all ask ourselves as business people are: First, if the press published your privacy agreement, would it be understandable? Second, if it were understandable, would consumers enjoy what they read? And last but not least, if not, what do you need to change?


These principles will be highly valuable foundations to keep in mind as products are built and evolve. They represent quick and easy questions to ask yourself and your team that will allow you to have a good baseline of ethics, but for a lengthier piece on legal foundations you can read more from Heather Burns, who outlined several additional principles last year on Smashing. And for a full list of things to inspect during a Privacy Impact Assessment (PIA), you can also check out how assessments are done according to:

But before rushing off to make changes in your product, first let’s point out some of the current flaws out in the wild and talk about what change might look like once they are implemented properly.

How To Make Change

One of the biggest problems with US privacy practices is how hard it is to understand terms and service agreements (T&S), which play a major role in defining privacy but tend to do so very poorly. Currently, users are forced to read long documents full of legal language and technical jargon if they hope to understand what they’re agreeing to. One study actually demonstrated that it would take approximately 201 hours (nearly ten days) per year for the average person to read every privacy policy they encounter on an annual basis. The researchers estimated that the value of this lost time would amount to nearly $781 billion per year, which is beyond unacceptable considering these are the rules that are supposed to protect consumers — rules that are touted to be easy and digestible. This puts consumers in a position where they’re forced to opt-in without truly understanding what they’re getting into. And in many cases it’s not even the legal language that’s coercive, it’s the way options are given, in general, as clearly proven across various experiences:

When consent is collected this way, it is assumed. (Large preview)

The example given above is generic wireframe, but I chose to do this because we’ve all seen patterns like this and others like it that are related to collecting more specific types of data. I could list specific examples, but the list would go on forever and there’s no reason to list off specific companies demonstrating manipulative patterns because these patterns (and other, very similar patterns) can be found on nearly every single website or app on the Internet. There’s one major problem with asking for consent this way: Consumers aren’t allowed to not accept terms and services without several extra steps, lots of reading, and often much more. This is a fundamental flaw that needs to be addressed because asking for consent means there needs to be an option to say no, and in order to know whether “no” is the best option, consumers need to understand what they’re consenting to. However, products aren’t built that way. Why? Well, it’s best for business.

If we really sit and think about this, what’s easy to see but let go unrecognized is that companies spend more time creating splash pages to explain how to use the app than we do to explain what data is being collected and why. Why? Simple changes to the way T&S agreements are made would not only make consumers more aware of what they’re signing up for, but also allow them to be more responsible consumers. We can see some of these changes already being made due to the impact the GDPR has been having across the world. In many European nations, it is not uncommon for consent to be asked through modals like these:

In this image, the benefits of giving consent have been recognized. (Large preview)

This first example is a good step forward. It tells the consumer what their data will be used for, but it’s still lacking transparency about where the data will be going and giving priority to the agreement without an option to decline. It also jams everything into a single body of text, which makes the information much less digestible.

A better example of how this might be designed is something like the modal below, which is now common among many European sites:

After GDPR compliance became an issue, many more options were given but improvements could still be made. (Large preview)

This gives consumers a comprehensive understanding of what their data will be used for and does it in a digestible manner. However, it still lacks any significant information about where the data will be going after they consent. There’s not a single clue as to where their data will be shared, who it will be shared with, and what limitations exist within those agreements. While this is much better than the majority of options on the web, there are still improvements to be made.

Third-Party Login Prompt

For example, when using a third-party service to log into your platform, consumers should be made well aware of the following:

  1. What data is going to be taken from the third-party;
  2. What it’s being used for and how it might affect their experience if you don’t have access to it;
  3. Who else has or might have access to it.

To implement this in a way that gives the consumer control, this experience should also allow consumers to opt-in to individual parts of the collection, not be forced to agree to everything or nothing at all.

By forcing consumers to check off at each point, it adds friction to the process, yes, but also makes sure the content is digestible. (Large preview)

This would make the T&S digestible and allow consumers to opt into what they truly agree to, not what the company wants them to agree to. And to make sure it’s truly opt-in, the default should be set to opt-out. This would be a small change that would make a dramatic difference in the way consent is asked for. Today, most companies blanket this content in legal jargon to hide what they’re really interested in, but the days of asking for consent in this way are quickly coming to an end.

If you’re providing consumers with a meaningful service, and doing so ethically, these changes shouldn’t be an issue. If there is a true value to the service, consumers are not going to resist your ask. They just want to know who they can and cannot trust, and this is one simple step that can help your business prove its trustworthiness.

Single- And Multi-Point Data Collection Requests

Next, when it comes to creating understandable T&S agreements for your platform, we have to consider how this might play out more contextually — within the application experience. Keep in mind that if it’s all given up front, that’s not digestible. For this reason, data collection request should happen contextually, when the consumer is about to use part of your service that requires an extra layer of data to be collected.

To demonstrate how this ask may occur, here are a couple of examples of what a single- and multi-point data collection request might look like:

Single- and multi-point data requests can be designed to reduce the complexity of current terms of service agreements. (Large preview)

Breaking the T&S down into digestible interaction points within the experience instead of asking the user for everything up front allows them to get a better understanding of what’s going on and why. If you don’t need the data to improve the experience, why is it being collected? And if it’s being collected for frivolous reasons that only benefit the company, then be honest. That’s just basic honesty, which unfortunately is considered revolutionary, progressive customer service in the modern world.

The biggest key to these initial asks is that none of this should be opt-in by default. All initial triggers should give the people using the tool to opt-in if they choose and use it without opting in if they choose. The days of forced opt-in (or, worse yet, coercive opt-in) are coming to an abrupt halt, and those who lead the way will stay ahead of the pack for a long time to come.

Data Control Center

Beyond asking for consent in a meaningful way, it will also be important that we give consumers the ability to control their data post-hoc. Consumers’ access to control their data should not end at the terms and service agreement. Somewhere in their account controls, there should also be a place (or places) where consumers can control their data on the platform after they’ve invested time with the service. This area should show them what data is being collected, who it’s being shared with, how they can remove it, and much more.

While we can often download our data now, we generally have no, or very little, control over it. This needs to change. (Large preview)

The idea of full data control may seem incredibly liberal, but it is no doubt the future. And as the property of the consumer creating the data, it should be considered a basic human right. There’s no reason why this should be a debate at this point in history. Data represents the story of our lives — collectively — and combined it creates vast amounts of power against those who create it, especially if we allow the systems to remain black boxes. So, beyond giving consumers access to their data, as we’ve discussed in the previous sections, we’ll also need to make the experience more understandable so that consumers can defend themselves.

Create Explainable AI

While it is incredible to get a suggested result that shows us things we want before we even knew we wanted them, this also puts machines in a powerful position they are not yet ready to uphold alone. When machines are positioned as experts and perform at a level that is intelligent enough to pass as such, the public will generally trust them until they fail. However, if machines fail in ways the public is incapable of understanding, they will remain expert despite their failure, which is one of the greatest threats to humanity.

For example, if someone were to use a visual search tool to identify the difference between an edible mushroom and a poisonous mushroom, and they didn’t know that the machine told them a poisonous mushroom was safe, that person could die. Or what happens when a machine determines the outcome of a court case and isn’t required to provide an explanation for its decision? Or worse yet, what about when these technologies are used for military purposes and are given the right to use lethal force? That last situation might sound extreme, but it is an issue that is currently being debated within the United Nations.

To ensure the public is capable of understanding what’s happening behind the scenes we need to create what DARPA calls explainable artificial intelligence (XAI) — tools that explain how machines make their decisions and the accuracy with which these tasks have been achieved. This isn’t about giving trade secrets away but allowing consumers to feel like they can trust these machines and defend themselves if an error were to occur.

Although it is not based in artificial intelligence, a good example of what this might look like is CreditKarma, which allows people to have a better understanding of their credit score — a system that used to be hidden just like algorithms are today. This tool allows consumers to have a better understanding of what’s happening behind the scenes and debate the legitimacy of their results if they believe the system has failed. Similar tools are being created with systems like Google’s Match score on Maps and Netflix Percent Match on shows but these systems are just beginning to scratch the surface of explainable AI.

Here we see systems that attempt to explain the machine’s decision on a very superficial level. This is a good start, but we need better. (Large preview)

Despite these efforts, most algorithms today dictate our experience based on what a company thinks we want. But consumers should no longer be invisibly controlled by large, publicly traded corporations. Consumers should have the right to control their own algorithm. This could be something as simple as letting them know what variables are used for what parts of the experience and how changing the weights of each variable will impact their experience, then giving them the ability to tweak that until it fits their needs — including turning the algorithm off completely, if that’s what they prefer. Whether this would be a paid feature or a free feature is still up for debate, but what is not debatable is whether this freedom should be offered.

Algorithm controls will be the future of business. Could this be a way to generate service revenue instead of relying solely on ads? Should it be free? (Large preview)

While the example above is a generic proposal, it begins to imagine how we might make the experience in more specific situations. By giving consumers the ability to understand their data, the way it’s being used, and how that affects their lives, we will have designed a system that puts consumers in control of their own freedom.

However, no matter how well these changes are made, we must also realize that giving people better control of their privacy does not automatically imply a safer environment for consumers. In fact, it may make things worse. Studies have shown that giving people better control of their data actually makes it more likely that they’ll provide more sensitive information. And if the consumer is unaware of how that data may be used (even if they know where it's being shared), this puts them in harm’s way. In this sense, giving consumers better control of their data and expecting it to make the Internet safer is like putting a nutrition label on a Snickers and expecting it to make the candy bar less fattening. It won’t, and people are still going to eat it.

While I do believe that consumers have a fundamental right to better privacy controls and greater transparency, I also believe it is our job, as data-literate technologists to not only build better systems but also to help the public understand Internet safety. So, the last step in bringing this together is to bring awareness to the fact that control isn’t all consumers need. They also need to understand what is happening on the backend — and why. This doesn’t necessarily mean providing them with source code or giving away their IPs, but at least providing them with enough information to understand what’s going on at a base level, as a matter of safety. And in order to achieve this, we’ll need to push beyond our screens. We’ll need to extend our work into our communities and help create that future.

Recommended reading: Designing Ethics: Shifting Ethical Understanding In Design

Incentivize Change

Giving up privacy is something the population has been corralled into due to the monopolies that exist in the tech world, consumers’ misunderstanding of why this is so dangerous within, and a lack of tactical solutions associated with fiscal returns. However, this is a problem that needs to be solved. As Barack Obama noted in his administration’s summary of concerns about internet privacy:

“One thing should be clear: Even though we live in a world in which we share personal information more freely than in the past, we must reject the conclusion that privacy is an outmoded value. It has been at the heart of our democracy from its inception, and we need it now more than ever.”

Creating trustworthy and secure data-sharing experiences will be one of the biggest challenges our world will face in the coming decades.

We can look at how Facebook’s stock dropped 19 percent in one day after announcing they’re going to re-focus on privacy efforts as proof of how difficult making these changes may be. This is because investors who have recently been focused on the short-term revenue growth know how badly companies need to implement better strategies, but also realize the cost involved if the public starts to question a business — and Facebook’s public statement admitting this startled the sheep.

While the process will not be easy (and at many times may be painful), we all know that privacy is the soft underbelly of tech and it’s time to change that. The decisions being made today will pay off big in the long run; a stark difference to the short-term, quarterly mindset that has come to dominate business in the past decade or so of growth. Thus, discovering creative ways to make these issues a priority for all stakeholders should be considered essential for businesses and policymakers alike, which means our job as technologists needs to extend beyond the boardroom.

For example, a great way to incentivize these changes beyond discussing the numbers and issues brought up in this article would be through tax breaks for companies that allocate large amounts of their budget to improving their systems. Breaks could be given to companies that decide to supply regular training or workshops for their staff to help make privacy and security a priority in the company culture. They could be given to companies that hire professional hackers to find loopholes in their systems before attacks occur. They could be given to those who allocate large amounts of hours to restructuring their business practices in a way that benefits consumers. In this sense, such incentives would not be so different than tax breaks given to businesses that implement eco-friendly practices.

The idea of tax breaks may sound outrageous to some, but incentives such as these would represent a more proactive solution than the way things are handled now. While it may feel good to read a headline stating “Google fined a record $5 billion by the EU for Android antitrust violations,“ we must keep in mind that fines like this only represent a small fraction of such companies’ revenue. Combine this with the fact that most cases take several years or decades to conclude, and that percentage only gets smaller. With this for consideration, the idea of tax breaks can be approached from a different perspective, which is that they are not about rewarding previously negligent behavior but about increasing public safety in a way that is in the best interest of everyone involved. Maintaining our current system, which allows companies to string out court cases while they continue their malpractices is just as, if not more, dangerous than having no laws at all.

If you enjoyed reading this article and think others should read it as well, please help spread the word.

This article is the beginning of a series of articles I will be writing about dedicated to Internet safety, in which I will work to put fiscal numbers to ethical design patterns so that we, as technologists can change the businesses we’re building and create a better culture surrounding the development of internet-connected experiences.

(il, ra, yk)
Categories: Around The Web

Representing Web Developers In The W3C

Thu, 09/27/2018 - 8:15am
Representing Web Developers In The W3C Representing Web Developers In The W3C Rachel Andrew 2018-09-27T14:15:00+02:00 2018-10-15T10:46:00+00:00

One of the many things that I do is to be a part of the CSS Working Group as an Invited Expert. Invited Experts are people who the group wants to be part of the group, but who do not work for a member organization which would confer upon their membership. In this post, I explain a little bit about what I feel my role is in the Working Group, as a way to announce a possible change to my involvement with the support of the Dutch organization, Fronteers.

I’ve always seen my involvement in the CSS Working Group as a two-way thing. I ferry information from the Working Group to authors (folks who are web developers, designers, and people who use CSS for print or EPUB) and from authors to the Working Group. Once I understand a discussion that is happening around a specification which would benefit from author input, I can explain it to authors in a way that doesn’t require detailed knowledge of CSS specifications or browser internals.

This was the motivation behind all of the work I did to explain Grid Layout before it landed in browsers. It is work I continue, for example, my recent article here on Smashing Magazine on Grid Level 2 and subgrid. While I think that far more web developers are capable of understanding the specifications than they often give themselves credit for, I get that people have other priorities! If I can distill and share the most important points, then perhaps we can get more feedback into the group at a point when it can make a difference.

There is something I have discovered while constantly unpacking these subjects in articles and on stage. While I can directly ask people for their opinion — and sometimes I do — the answers to those direct questions are most often the obvious ones. People are put on the spot; they feel they should have an opinion and so give the first answer they think of. Even with they’re in an A or B choice about a subject (when asked to vote), they may not be in a place to fully consider all of the implications.

If I write or talk about a subject, however, I don’t get requests for CSS features. I get questions. Some of those I can answer and I make a note to perhaps better explain that point in future. Some of those questions I cannot answer because CSS doesn’t yet have an answer. I am constantly searching for those unanswered questions, for that is where the future of CSS is. By being a web developer who also happens to work on CSS, I’m in a perfect place to have those conversations and to try to take them back with me to the Working Group when relevant things are being discussed, and so we need to know what authors think.

Meet SmashingConf New York 2018 (Oct 23–24), focused on real challenges and real front-end solutions in the real world. From progressive web apps, Webpack and HTTP/2 to serverless, Vue.js and Nuxt — all the way to inclusive design, branding and machine learning. With Sarah Drasner, Sara Soueidan and many other speakers.

Check all topics and speakers ↬

To do this sort of work, you need to be able to explain things well and to have a nerdy interest in specifications. I’m not the only person on the planet who has these attributes. However, to do this sort of work as an Invited Expert to the CSS Working Group requires something else; it requires you to give up a lot of your time and be able to spend a lot of your own money. There is no funding for Invited Experts. A W3C Invited Expert is a volunteer, attending weekly meetings, traveling for in-person meetings, spending time responding to issues on GitHub, chatting to authors, or even editing specifications and writing tests. This is all volunteer work. As an independent — sat at a CSS Working Group meeting — I know that while practically every other person sat around that table is being paid to be there — as they work for a browser vendor or another company with an interest — I’m not. You have to care very deeply, and have a very understanding family for that to be at all sustainable.

It is this practical point which makes it hard for there to be more people like me involved in this kind of work — in the way that I’m involved — as an independent voice for authors. To actually be paid to work on this stuff usually means becoming employed by a browser vendor, and while there is nothing wrong with that it changes the dynamic. I would then be Rachel Andrew from Microsoft/Google/Mozilla. Who would I be speaking for? Could I remain embedded in the web community if I was no longer a web developer myself? It’s for this reason I was very interested when representatives from Fronteers approached me earlier this year.

Fronteers are an amazing organization of Dutch web developers. One of my first international speaking engagements was to go to Amsterdam to speak at one of their meetups. I was immediately struck by the hugely knowledgeable community in Amsterdam. If I am invited to speak at a front-end event in the Netherlands, I know I can take my nerdiest and most detailed talks along with me; the community there will already know the basics and be excited to hear the details.

Anneke Sinnema (Chair of Fronteers) and Peter-Paul Koch (Founder) approached me with an idea they had about their organization becoming a Member of the W3C, which would then entitle them to representation within the W3C. They wanted to know if I would be interested in becoming their first representative — a move that would make me an official representative for the web development community as well as give me a stipend in order that I would have some paid hours covered to do that work. This plan needs to be voted upon my Fronteers members, so may or may not come to fruition. However, we all hope it will, and not just for me but as a possible start to a movement which sees more people like myself involved in the work of creating the web platform.

My post is one of a few being published today to announce this as an idea. For more information on the thoughts behind this idea, read “Web Developer Representation In W3C Is Here” on A List Apart. Dutch speakers can also find a post on the Fronteers blog.

(il)
Categories: Around The Web