Using CSS Transitions on Auto Dimensions

March 10th, 2017 No comments

We’ve all been there. You’ve got an element you want to be able to collapse and expand smoothly using CSS transitions, but its expanded size needs to be content-dependent. You’ve set transition: height 0.2s ease-out. You’ve created a collapsed CSS class that applies height: 0. You try it out, and… the height doesn’t transition. It snaps between the two sizes as if transition had never been set. After some fiddling, you figure out that this problem only happens when the height starts out or ends up as auto. Percentages, pixel values, any absolute units work as expected. But all of those require hard coding a specific height beforehand, rather than allowing it to naturally result from the size of the element content.

Nikita Vasilyev documented this well.
In this article I mostly speak in terms of height for simplicity, but everything here also applies to width.

If you were hoping I had a magical, complete solution to this problem, I’m sorry to disappoint you. There’s no one solution that achieves the desired effect without downsides. There are, however, multiple workarounds that each come with a different set of advantages and disadvantages, and in most use cases at least one of them will get the job done in an acceptable manner. I’ll outline the major ones, and list out their ups and downs so you can hopefully pick the best one for your situation.

Why hasn’t this problem been fixed at the browser level?

According to the Mozilla Developer Network docs, auto values have been intentionally excluded from the CSS transitions spec. It looks like it’s been requested by a few people, but when you think about it, it makes at least a little sense that it hasn’t been included. The browser process that re-calculates the sizes and positions of all elements based on their content and the way they interact with each other (known as “reflow”) is expensive. If you were to transition an element into a height of auto, the browser would have to perform a reflow for every stage of that animation, to determine how all the other elements should move. This couldn’t be cached or calculated in a simple way, since it doesn’t know the starting and/or ending values until the moment the transition happens. This would significantly complicate the math that has to be done under the hood and probably degrade performance in a way that might not be obvious to the developer.

Technique 1: max-height

If you web search this problem, the max-height approach will probably be mentioned in all of the first five to ten results. It’s actually pretty unideal, but I thought it was worth including here for the sake of comparison.

It works like this: CSS values can only be transitioned to and from fixed unit values. But imagine we have an element whose height is set to auto, but whose max-height is set to a fixed value; say, 1000px. We can’t transition height, but we can transition max-height, since it has an explicit value. At any given moment, the actual height of the element will be the maximum of the height and the max-height. So as long as max-height‘s value is greater than what auto comes out to, we can just transition max-height and achieve a version of the desired effect.

See the Pen Smooth Collapsing div with max-height by Brandon (@brundolf) on CodePen.

There are two crucial downsides to this

One is obvious, and one is subtle. The obvious disadvantage is that we still have to hard-code a maximum height for the element, even if we don’t have to hard-code the height itself. Depending on your situation, maybe you can guarantee that you won’t need more height than that. But if not, it’s a pretty big compromise. The second, less obvious downside, is that the transition length will not actually be what you specify unless the content height works out to be exactly the same as max-height. For example, say your content is 600px tall, and your max-height is transitioning from 0px to 1000px with a duration of 1 second. How long will it take the element to get to 600px? 0.6 seconds! The max-height will continue transitioning, but the real height will stop changing once it reaches the end of its content. This will be even more pronounced if your transition is using a nonlinear timing function. If the transition is fast at the beginning and slow at the end, your section will expand quickly and collapse slowly. Not ideal. Still, transitions are relatively subjective, so in cases where this technique is otherwise appropriate, it could be an acceptable tradeoff.

Technique 2: transform: scaleY()

If you aren’t familiar with the transform property, it allows you to apply GPU-driven transformations (translate, scale, rotate, etc.) to an element. It’s important to note a couple of things about the nature of these transformations:

  1. They operate on the element’s visual representation as if it were simply an image, rather than a DOM element. This means, for example, that an element scaled up too far will look pixellated, since its DOM was originally rendered onto fewer pixels than it now spans.
  2. They do not trigger reflows. Again, the transform doesn’t know or care about the element’s DOM structure, only about the “picture” the browser drew of it. This is both the reason this technique works and its biggest downside.

Implementation works like this: we set a transition for the element’s transform property, then toggle between transform: scaleY(1) and transform: scaleY(0). These mean, respectively, “render this element at the same scale (on the y axis) that it starts out at” and “render this element at a scale of 0 (on the y axis)”. Transitioning between these two states will neatly “squish” the element to and from its natural, content-based size. As a bonus, even the letters and/or images inside will visually “squish” themselves, rather than sliding behind the element’s boundary. The downside? Since no reflow is triggered, the elements around this element will be completely unaffected. They will neither move nor resize to fill in the empty space.

See the Pen Smooth Collapsing div with scaleY() by Brandon (@brundolf) on CodePen.

The advantages and disadvantages of this approach are stark

It will either work very well for your use-case or won’t be appropriate at all.

This mainly depends on whether or not any elements follow the one in question in the flow of the document. For example, something that floats over the main document like a modal or a tooltip will work perfectly this way. It would also work for an element that’s at the bottom of the document. But unfortunately, in many situations, this one won’t do.

Technique 3: JavaScript

Managing a CSS transition in CSS would be ideal, but as we’re learning, sometimes it just isn’t entirely possible.

If you absolutely have to have smoothly collapsing sections, whose expanded size is completely driven by their content, and which other elements on the page will flow around as they transition, you can achieve that with some JavaScript.

The basic strategy is to manually do what the browser refuses to: calculate the full size of the element’s contents, then CSS transition the element to that explicit pixel size.

See the Pen dvoGyw by Brandon (@brundolf) on CodePen.

Let’s deconstruct this a little bit. The first thing to note is that we keep track of whether or not the section is currently collapsed using the data-collapsed attribute. This is necessary so we know what to “do” to the element each time its expansion is toggled. If this were a React or Angular app, this would be a state variable.

The next thing that might stand out is the use of requestAnimationFrame(). This allows you to run a callback the next time the browser re-renders. In this case, we use it to wait to do something until the style we just set has taken effect. This is important where we change the element’s height from auto to the equivalent explicit pixels value because we don’t want to wait on a transition there. So we must clear the value of transition, then set height, then restore transition. If these were sequential lines in the code, the result would be as if they’d all been set simultaneously since the browser doesn’t re-render in parallel to Javascript execution (at least, for our purposes).

The other idiosyncrasy is where we set height back to auto once the expansion has finished happening. We register an event listener with transitionend, which fires whenever a CSS transition concludes. Inside of that event listener, we remove it (since we only want it to respond to the immediately following transition), then remove height from the inline styles. This way, the element size is back to being defined however the normal styles for the page define it. We don’t want to assume that it should remain the same pixel size, or even that it should remain auto sized. We want our JavaScript to perform the transition, and then get out of the way and not interfere more than necessary.

The rest is fairly straightforward. And, as you can see, this achieves exactly the desired result. That said, despite best efforts, there are quite a few ways in which this makes our code more brittle and potentially bug-prone:

  • We’ve added 27 lines of code instead of 3
  • Changes to things like padding or border-box in our section element could require changes to this code
  • CSS transitions on the section, that happen to end while the height transition is still going, could cause height not to be returned to its default value
  • Disabling transition for one frame could disrupt other transitions on that element which happen to be going at the same time
  • If a bug ever caused the element’s height style to get out of sync with its data-collapsed attribute, its behavior could have problems

On top of all that, the code we’ve written is procedural instead of declarative, which inherently makes it more error-prone and complex. All that said, sometimes our code just needs to do waht it needs to do, and if it’s worth the tradeoffs then it’s worth the tradeoffs.

Bonus Technique: Flexbox

I call this technique a bonus because it doesn’t technically achieve the desired behavior. It offers an alternate way of determining your elements’ sizes which in many cases may be a reasonable replacement, and which does fully support transitions.

You may want to read about flexbox and flex-grow before reading this section, if you’re not familiar with them already.

Flexbox is an extremely powerful system for managing the way your interface’s sizing adapts to different situations. Many articles have been written about this, and I won’t go into it in detail. What I will go into, is the lesser-mentioned fact that the flex property and others related to it fully support transitions!

See the Pen Smooth Collapsing div with Flexbox by Brandon (@brundolf) on CodePen.

What this means, is that if your use case allows you to determine sizing using flexbox instead of your content size, making a section smoothly collapse is as simple as setting transition: flex 0.3s ease-out and toggling flex: 0. Still not as good as being content-based, but more flexible (I know, I know, I’m sorry) than going to and from pixel sizes.


Using CSS Transitions on Auto Dimensions is a post from CSS-Tricks

Categories: Designing, Others Tags:

Browser Watch, March 2017

March 10th, 2017 No comments

Welcome to another edition of Browser Watch, the regular feature that runs down the latest news and developments among all the most popular and up-and-coming browsers available. Whether you’re a designer, developer or both, you’ll always be kept up to date on everything that’s going in the browser world.

Material Design Extensions Page Part of Latest Chrome Development Release

Google Chrome’s extensions page hasn’t been altered in a while, but that’s recently changed. In essence, the extensions page received a grid-based redesign, so users have an easier time being able to spot at a glance what the extensions have been enabled. Tabs on the left side are for Chrome apps and extensions; the items inside can now be either enabled or disabled courtesy of a Material Design-inspired on/off toggle. To see the extensions page, users will have to activate a flag to see it inside the development build.

Apple Increasing Malware Protection on Chrome for macOS

In a bid to improve security, Apple is improving protection against malware in Chrome; this malware preys on macOS devices on the web. Apple has a two-part plan to combat this malware against macOS users. First, the company recently released the Chrome Settings API for Mac, which came with Chrome 56. Second, Apple is relying on Google’s Safe Browsing Technology to show in-browser alerts when a user wants to visit a known website with questionable security.

Safari Technology Preview 25 Released

Apple has released Safari Technology Preview 25 that comes with bug fixes and improvements to known features. At the one-year anniversary mark, Safari Technology Preview’s latest version includes improvements to:

  • Resource Timing
  • Rendering
  • Media
  • CSS
  • WebCrypto
  • User Timing
  • Web API
  • Web Inspector

One of the biggest changes is that Resource Timing is now going to be available by default.

(Safari Technology Preview was intended by Apple to be a place where it could experiment with and test certain features that could eventually be introduced in future, wide releases of Safari.)

Komando.com Says Unheard of Dolphin Browser Rivals Chrome and Firefox

Even if you’re using popular browsers’ mobile versions, chances are that they still take a backseat to their desktop versions when it comes to performance. According to a piece on Komando.com, the Dolphin browser gives both Chrome and Firefox a run for their money when it comes to a mobile-browsing experience. Unlike all other browsers, the Dolphin was specifically designed from its inception to tweak the user experience during mobile browsing.

Apple Safari…Going the Way of Internet Explorer?

While Apple still supports its browser—unlike Internet Explorer, on which Microsoft pulled the plug on a few years ago—reports indicate that Safari is shedding users at an alarming rate. According to a recent report, Safari has lost a significant 19% of its users in only the past two years, which isn’t good if Apple wants Safari to remain competitive with Chrome, Firefox and even upstarts like Vivaldi.

Firefox Debuts Support for WebAssembly

Mozilla’s latest update, Firefox 52, is a one-of-a-kind browser: It is the first browser to support something called WebAssembly, an burgeoning standard that saw its roots in a Mozilla research project. WebAssembly should please video-game fans, as it allows sophisticated apps, such as games, to run faster than ever before inside a web browser. WebAssembly is expected to enable apps that have typically been too complicated to properly run in browsers. That would include 3D video games and scientific visualization, among others.

Brave, the Ad-Blocking Browser, Now Syncs Between Desktops

The new browser from ex-Mozilla CEO Brendan Eich is known for ad-blocking, but now, it’s also one step closer to having another feature that virtually all browsers offer as standard: the ability to sync between computers. Note that users still won’t be able to sync between all devices (read: mobile)—just between desktops. This should help drive a few more users to Brave, as sync support is at least a promising step in the right direction (mobile sync is apparently in the works).

Opera Browser and Instant Page Loading

Instant page loading sounds intriguing, you have to admit. That’s just what’s new in Opera’s latest release, Opera 43. Here’s how instant page loading works: It uses predictive technology to start to load a site in the background prior to the user finishing putting the entire URL into the address bar. This version of Opera is also the fastest yet. This is all part of Opera’s goal to make the browser smarter over time by understanding what sites are attached to URL inputs.

Security Flaw in Microsoft Edge and Internet Explorer?

This time, it’s Google warning users about a serious security flaw in both Edge and Internet Explorer. The security problem pertains to how both of the browsers end up formatting webpages. Ivan Fratric, a well-known Google researcher, initially discovered the flaw late last year, but, unfortunately, Microsoft has not yet patched it. Further, the company hasn’t announced when it’s going to patch the flaw (if at all), thereby leaving millions of users around the globe vulnerable.

Chrome Is Going to Support Virtual Reality

Google is looking to push and surpass the limits of its leading browser by making the newest version of its browser support virtual reality on the web. As a result, it’ll be possible for users to look at virtual reality on any device as well as over any platform. Of course, at the moment, only a handful of sites actually provide virtual-reality content for users. Google, unsurprisingly, is working hard to up this number, just in time for its support of VR on the web.

2-Year Subscription to Vectorstate – Download 2400 Illustrations – 75% off!

Source

Categories: Designing, Others Tags:

“Serverless”

March 10th, 2017 No comments

Every time I use the word “serverless”, which is somewhat regularly lately, as we’ve had a few articles using the term lately and use the concept at CodePen for a variety of things, I get some version of:

CMON BRAH YOU’RE STILL USING “SERVERS”.

And they aren’t wrong. Yes, when you build things on the web, there are always servers involved. Always. Whether it’s some old computer in a church basement, a computer in a rack at some big hosting company, or “The Cloud”, it’s a server.


Chris Wattersons’s classic sticker.

I rolled my eyes at the term the first few times I heard it too. But now I’m hesitant to call it a bad term, in part because it’s really stuck, and there is something to be said for new terms that catch on so strongly. Also in part because it signifies a dramatic change in how you can use servers. It’s different economically, different devops-wise, and different in how you code for them.

To many of us, we’re aware a server is a computer. There are various ways to buy them, but you buy them. Here’s some money, here’s your server. It might be virtual, but it’s still something you’re responsible for. You put software on it. You spin them up and spin them down. You load balance them. You make choices about how much memory and disk space they have. You’re in charge of provisioning and managing them.

What serverless is trying to mean, it seems to me, is a new way to manage and pay for servers. You don’t buy individual servers. You don’t manage them. You don’t scale them. You don’t balance them. You aren’t really responsible for them.

You just pay for what you use. For example, AWS Lambda is free for 1,000,000 requests and then costs $0.0000002 per request after that. Cheap. Just this week Firebase launched “functions” which are essentially a serverless concept, and their $25 a month plan has 2,000,000 requests (along with all the rest of the stuff Firebase gets you).

That doesn’t work for all applications. It works for things in which you can write some code that is designed to take some stuff, do some work, and return some new stuff. You write an API.

You don’t have to go all in with the “serverless” idea. You can, and I imagine most people do, use it for things that make sense to use it for, and use traditional servers for the rest.


“Serverless” is a post from CSS-Tricks

Categories: Designing, Others Tags:

“Severless”

March 10th, 2017 No comments

Every time I use the word “serverless”, which is somewhat regularly lately, as we’ve had a few articles using the term lately and use the concept at CodePen for a variety of things, I get some version of:

CMON BRAH YOU’RE STILL USING “SERVERS”.

And they aren’t wrong. Yes, when you build things on the web, there are always servers involved. Always. Whether it’s some old computer in a church basement, a computer in a rack at some big hosting company, or “The Cloud”, it’s a server.


Chris Wattersons’s classic sticker.

I rolled my eyes at the term the first few times I heard it too. But now I’m hesitant to call it a bad term, in part because it’s really stuck, and there is something to be said for new terms that catch on so strongly. Also in part because it signifies a dramatic change in how you can use servers. It’s different economically, different devops-wise, and different in how you code for them.

To many of us, we’re aware a server is a computer. There are various ways to buy them, but you buy them. Here’s some money, here’s your server. It might be virtual, but it’s still something you’re responsible for. You put software on it. You spin them up and spin them down. You load balance them. You make choices about how much memory and disk space they have. You’re in charge of provisioning and managing them.

What serverless is trying to mean, it seems to me, is a new way to manage and pay for servers. You don’t buy individual servers. You don’t manage them. You don’t scale them. You don’t balance them. You aren’t really responsible for them.

You just pay for what you use. For example, AWS Lambda is free for 1,000,000 requests and then costs $0.0000002 per request after that. Cheap. Just this week Firebase launched “functions” which are essentially a serverless concept, and their $25 a month plan has 2,000,000 requests (along with all the rest of the stuff Firebase gets you).

That doesn’t work for all applications. It works for things in which you can write some code that is designed to take some stuff, do some work, and return some new stuff. You write an API.

You don’t have to go all in with the “serverless” idea. You can, and I imagine most people do, use it for things that make sense to use it for, and use traditional servers for the rest.


“Severless” is a post from CSS-Tricks

Categories: Designing, Others Tags:

Web Development Reading List #173: CSS Grid Support, A Virtual DOM Alternative, And Designing Better Cards

March 10th, 2017 No comments

This week was a big week in terms of web development news. We got much broader support for CSS Grids and Web Assembly, for example, but I also stumbled across some great resources that teach us a lot of valuable things.

With this Web Development Reading List, we’ll dive deep into security and privacy issues, take a look at a lightweight virtual DOM alternative, and get insights into how we can overcome our biases (or at least how we can better deal with them). So without further ado, let’s dive right in!

The post Web Development Reading List #173: CSS Grid Support, A Virtual DOM Alternative, And Designing Better Cards appeared first on Smashing Magazine.

Categories: Others Tags:

Password Rules Are Bullshit

March 10th, 2017 No comments
entropy visualized

Of the many, many, many bad things about passwords, you know what the worst is? Password rules.

If we don’t solve the password problem for users in my lifetime I am gonna haunt you from beyond the grave as a ghost pic.twitter.com/Tf9EnwgoZv

— Jeff Atwood (@codinghorror) August 11, 2015

Let this pledge be duly noted on the permanent record of the Internet. I don’t know if there’s an afterlife, but I’ll be finding out soon enough, and I plan to go out mad as hell.

The world is absolutely awash in terrible password rules:

But I don’t need to tell you this. The more likely you are to use a truly random password generation tool, like us über-geeks are supposed to, the more likely you have suffered mightily – and daily – under this regime.

Have you seen the classic XKCD about passwords?

We can certainly debate whether “correct horse battery staple” is a viable password strategy or not, but the argument here is mostly that length matters.

That's What She Said

No, seriously, it does. I’ll go so far as to say your password is too damn short. These days, given the state of cloud computing and GPU password hash cracking, any password of 8 characters or less is perilously close to no password at all.

So then perhaps we have one rule, that passwords must not be short. A long password is much more likely to be secure than a short one … right?

What about this four character password?

?????

What about this eight character password?

????????

Or this (hypothetical, but all too real) seven character password?

@codinghorror I’m sorry but your password must contain 1 char each from: Arabic, Chinese, Thai, Korean, Klingon, Wingdings and an emoji

— Finley Creative (@FinleyCreative) March 3, 2016

You may also be surprised, if you paste the above four Unicode emojis into your favorite login dialog (go ahead – try it), to discover that it … isn’t in fact four characters.

Oh dear.

"💩".length === 2

Our old pal Unicode strikes again.

As it turns out, even the simple rule that “your password must be of reasonable length” … ain’t necessarily so. Particularly if we stop thinking like Ugly ASCII Americans.

And what of those nice, long passwords? Are they always secure?

aaaaaaaaaaaaaaaaaaa
0123456789012345689
passwordpassword
usernamepassword

Of course not, because have you met any users lately?

I changed all my passwords to

They consistently ruin every piece of software I’ve ever written. Yes, yes, I know you, Mr. or Ms. über-geek, know all about the concept of entropy. But expressing your love of entropy as terrible, idiosyncratic password rules …

  • must contain uppercase
  • must contain lowercase
  • must contain a number
  • must contain a special character

… is a spectacular failure of imagination in a world of Unicode and Emoji.

As we built Discourse, I discovered that the login dialog was a remarkably complex piece of software, despite its surface simplicity. The primary password rule we used was also the simplest one: length. Since I wrote that, we’ve already increased our minimum password default length from 8 to 10 characters. And if you happen to be an admin or moderator, we decided the minimum has to be even more, 12 characters.

I also advocated checking passwords against the 100,000 most common passwords. If you look at 10 million passwords from data breaches in 2016, you’ll find the top 25 most used passwords are:

123456
123456789
qwerty
12345678
111111
1234567890
1234567
password
123123
987654321
qwertyuiop
mynoob
123321
666666
18atcskd2w
7777777
1q2w3e4r
654321
555555
3rjs1la7qe
google
1q2w3e4r5t
123qwe
zxcvbnm
1q2w3e

Even this data betrays some ASCII-centrism. The numbers are the same in any culture I suppose, but I find it hard to believe the average Chinese person will ever choose the passwords “password”, “quertyuiop”, or “mynoob”. So this list has to be customizable, localizable.

(One interesting idea is to search for common shorter password matches inside longer passwords, but I think this would cause too many false positives.)

Also of note: only 5 of the top 25 passwords are 10 characters, so if we require 10 character passwords, we’ve already reduced our exposure to the most common passwords by 80%. I saw this originally when I gathered millions and millions of leaked passwords for Discourse research, then filtered the list down to just those passwords reflecting our new minimum requirement of 10 characters or more. It suddenly became a tiny list. (If you’ve done similar common password research, please do share your results in the comments.)

I’d like to offer the following common sense advice to my fellow developers:

1. Password rules are bullshit

  • They don’t work.
  • They heavily penalize your ideal audience, people that use real random password generators. Hey guess what, that password randomly didn’t have a number or symbol in it. I just double checked my math textbook, and yep, it’s possible. I’m pretty sure.
  • They frustrate average users, who then become uncooperative and use “creative” workarounds that make their passwords less secure.
  • Are often wrong, in the sense that they are grossly incomplete and/or insane, per the many shaming links I’ve shared above.
  • Seriously, for the love of God, stop with this arbitrary password rule nonsense already. If you won’t take my word for it, read this 2016 NIST password rules recommendation. It’s right there, “no composition rules”. However, I do see one error, it should have said “no bullshit composition rules”.

2. Enforce a minimum Unicode password length

One rule is at least easy to remember, understand, and enforce. This is the proverbial one rule to bring them all, and in the darkness bind them.

  • It’s simple. Users can count. Most of them, anyway.
  • It works. The data shows us it works; just download any common password list of your choice and group by password length.
  • The math doesn’t lie. All other things being equal, a longer password will be more random – and thus more secure – than a short password.
  • Accept that even this one rule isn’t inviolate. A minimum password length of 6 on a Chinese site might be perfectly reasonable.
  • If you don’t allow (almost) every single unicode character in the password input field, you are probably doing it wrong.
  • It’s a bit of an implementation detail, but make sure maximum password length is reasonable as well.

3. Check for common passwords

As I’ve already noted, the definition of “common” depends on your audience, and language, but it is a terrible disservice to users when you let them choose passwords that exist in the list of 10k, 100k, or million most common known passwords from data breaches. There’s no question that a hacker will submit these common passwords in a hack attempt – and it’s shocking how far you can get, even with aggressive password attempt rate limiting, using just the 1,000 most common passwords.

  • 1.6% have a password from the top 10 passwords
  • 4.4% have a password from the top 100 passwords
  • 9.7% have a password from the top 500 passwords
  • 13.2% have a password from the top 1,000 passwords
  • 30% have a password from the top 10,000 passwords

Lucky you, there are millions and millions of real breached password lists out there to sift through. It is sort of fun to do data forensics, because these aren’t hypothetical synthetic Jack the Ripper password rules some bored programmer dreamed up, these are real passwords used by real users.

Do the research. Collect the data. Protect your users from themselves.

4. Check for basic entropy

No need to get fancy here; pick the measure of entropy that satisfies you deep in the truthiness of your gut. But remember you have to be able to explain it to users when they fail the check, too.

In my opinion, the simplest way to do this is to ensure that there are at least (x) unique characters out of (y) total characters. And that’s what we do as of the current beta version of Discourse. But I’d love your ideas in the comments, too. The simpler and clearer the better!

5. Reject special case passwords

I’m embarrassed to admit that when building the Discourse login, as I discussed in The God Login, we missed two common cases that you really have to block:

  • password equal to username
  • password equal to email address

? If you are using Discourse versions earlier than 1.4, I’m so sorry and please upgrade immediately.

Similarly, you might also want to block other special cases like

  • password equal to URL or domain of website
  • password equal to app name

In short, try to think outside the password input box, like a user would.

[advertisement] Building out your tech team? Stack Overflow Careers helps you hire from the largest community for programmers on the planet. We built our site with developers like you in mind.
Categories: Others, Programming Tags:

Free Sparkly Icons To (Literally) Make Your Designs Shine (30 Icons, EPS, SVG)

March 10th, 2017 No comments

What would life be without surprises? Pretty plain, wouldn’t you agree? Today, we are happy to announce a freebie that bubbles over with its friendly optimistic spirit, bound to sprinkle some unexpected sparks of delight into your projects: Ballicons 3. If that name rings a bell, well, it’s the third iteration of the previous Ballicons icon set created by the folks at Pixel Buddha.

This icon set covers a vibrant potpourri of subjects, 30 icons ranging from nature, travel and leisure motifs to tech and office. All icons are available in five formats (AI, EPS, PSD, SVG, and PNG) so you can resize and customize them until they match your project’s visual style perfectly. No matter if you like it bright and bubbly or rather sleek and simple — the set has the makings to become a real allrounder in your digital tool belt.

The post Free Sparkly Icons To (Literally) Make Your Designs Shine (30 Icons, EPS, SVG) appeared first on Smashing Magazine.

Categories: Others Tags:

Noupe Exclusive: 350+ Free Icons For Our Readers

March 10th, 2017 No comments

Icons are always useful. This is the same for both you and us. We got together with the vector acrobats from Vexels to create an icon collection with more than 350 pictograms that you can use completely for free, and for any purpose you want to. Enjoy!

Our icon set contains symbols for social media, general business applications, and all types of contact pictograms. For that, we have chosen the most up to date design variants. The symbols come in flat design, as line icons, in offset style, with long shadows, as well as sporting the newest material design. This should allow for the creation of all conventional designs. If you are not one hundred percent content with the pictograms, you can simply edit them yourself, as you not only get each icon as an individual PNG with the measurements 1200 x 1200 pixels but also as an individual SVG, as well as a layered Adobe Illustrator format.

This overview gives you an impression of what to expect:

An Overview of All Pictograms. (Overview: Vexels)

The download of the 18 megabytes heavy ZIP archive is not tied to any preconditions. All you have to do is attach the note “Designed by Vexels” to projects that you use the set in. After the download and unzipping of the archive, you’ll find a folder named ICONS on your local drive, in which the individual design variants are stored, divided into further subfolders.

Download the Zip archive now (18MB): 350+ Icons for Business and Contacts

Categories: Others Tags:

BetterWebType: Free Course on Web Typography

March 10th, 2017 No comments

On BetterWebType, you can attend a free email class with ten lectures on better web typography. It’s completely free and run by Matej Latin, the creator of the Gutenberg starter kit.

Better Web Typography For a Better Web

This is the slogan that Matej Latin will welcome you with on his website BetterWebType. Regular readers of Noupe already know Matej Latin. About a year ago, we gave you an in-depth introduction to his project Gutenberg here.

Matej calls Gutenberg a “Meaningful Web Typography Starter Kit,” which means that, by using Gutenberg in our projects, we are always on the safe side, without needing to put in an extra effort. Gutenberg takes care of the basics by itself. The project was created based on Sass. This allows you to work with mixins, providing your designs with a level of flexibility that would not have been possible without variable markup.

While a starter kit can definitely help the clueless to avoid the roughest mistakes, solid knowledge is undisputedly better. Latin agrees with the founder of iA, Oliver Reichenstein, who said that web design is 95 percent typography more than ten years ago already.

To account for this aspect, Latin considers it necessary for web designers and developers to upskill in this section more than ever. To make this possible, Latin offers a free class on web typography.

BetterWebType is not a disguised acquisition scheme with reduced usefulness, but a full-featured, actually free class in ten lectures. There are no charged add-ons, expansions, or other tricks either. BetterWebType is and, according to Latin, will stay free.

BetterWebType Covers the Basics and Exceeds Them

BetterWebType already has more than 3,000 subscribers. It covers all basics, including the question how fonts should be selected and combined; a problem that many people don’t put enough thought into.

Other lectures deal with ligatures, small caps, quotation marks, vertical and horizontal rhythm, and a lot more. The lectures are sent to you via email. The class takes ten days, with you receiving one lecture a day.


BetterWebType: Who Learns What? (Screenshot: Noupe)

The reading effort for each lesson is about five to ten minutes. At the end of each, you’ll also receive more in-depth tips on what you learned. These can be articles, websites, or book recommendations. From time to time, you’ll also be asked to solve a task. How much time you end up putting into the class is up to you.

BetterWebType is made to allow both designers and developers alike to profit from it. Prior knowledge generally is not required, but complete cluelessness in HTML and CSS would definitely be a problem.

For the participation, it is enough to tell Latin your first and last name, as well as an email address. Obviously, the email address should be functional, as that is where the lessons will go.

Categories: Others Tags:

Web agencies and chatbots – the race to stay relevant

March 9th, 2017 No comments
Web-agencies-and-chatbots

Mobile messaging and chatbots are here, and it looks like they are here to stay. As a web agency, you have most likely heard of the chatbot trend and are pondering whether or not you should be getting involved.

What are chatbots, exactly? Is it worth tweaking your cold pitch to include them? What upside will they (realistically) bring to your business?

These are the exact questions I am going to answer in this article.

I am going to show you why, as a web professional, you need to look into chatbots today. In fact, ideally, yesterday.

A quick overview of the chatbot trend

Before we go further, we need to get you up to speed.

What is a chatbot? A chatbot is a program designed to communicate with human users through a conversational interface.

Chatbot growth has accelerated fast. It all started in 2015 when mobile messaging became a bigger channel than social media.

In 2016, a few businesses realized the potential mobile messaging could have on its bottom line. Facebook created the perfect bot-storm by opening its Messenger API, allowing geeks all over the world to build bots for free.

facebook-messenger-growth-graph

Facebook Messenger’s user base keeps growing, a fantastic opportunity for chatbots. (source)

Now 2017 has been deemed to be ‘the year of the chatbot’.

Use cases have started popping up everywhere, some simple and silly like the cat chatbot (meow?), some more advanced and AI-driven like Unilever and PG tips’ Monkey bot (tea anyone?).

Now you are caught up let’s move on.

Why should your web agency care about chatbots?

To differentiate yourself

Your industry is tough. There are a plethora of options for potential clients; competition is fierce.

Standing out from the crowd is more important than ever. Chatbots will help you do just that.

It will take the market a year or so to catch up to the chatbot trend. It will take another few years for your competitors to figure out what to do with them, how to pitch them, and how to build them. You will have the upper hand as you have already figured it all out.

Become ‘the’ agency in your neck of the woods who can talk intelligently, and effectively pitch chatbots today, not in three years.

Get ahead of the curve

As a web agency, you often are considered the ‘internet translator’ for the less tech-savvy. Your clients come to you with ideas, things they have seen or heard somewhere else and ask, “can you do that for me?”

If it has not already, this is going to happen to you with chatbots, very soon. The truth is, across the planet, it is going on right now.

When your competitors are asked: “do you know anything about chatbots?”. They reply something along the lines of “I do not, let me look into it”.

Become the agency that says “Yes”.

Chatbots are becoming an extension of websites and a brand

Web design and web development have, for many years, relied on principles of design, visuals, functionality, typography and UI.

The somewhat lesser-important parts of a brand’s identity are now front and centre.

– What is our voice?
– Do we use emojis?
– Are we fun or serious?
– What is our tone?
– How approachable are we?
– What words should we use to communicate?

As a web agency, it will become part of your role to help clients define their conversational identity and help them with everything around their project, from planning the build to benchmarking their chatbot’s user engagement and making sure it is a success.

pg-tips-monkey-chatbot

PG tips’ Monkey chatbot has a fun and approachable personality. (source)

You need to dig into chatbots, conversational commerce, conversational UI, and all the other implications of moving a brand from one-way (‘this is us’) into two-way (‘this is us, let’s chat’).

Chatbots are a powerful tool

Speaking of conversational commerce, we need to touch on what chatbots are good at.

So far, we have looked at why chatbots are beneficial to your company. For your clients, on the other hand, chatbots are an amazingly powerful tool.

It may be through content distribution via the channel consumers prefer (as opposed to good old email marketing). Alternatively, maybe assisting sales by offering a new lead gen channel or perhaps decluttering the helpdesk by automating responses to 80% of incoming enquiries. Whatever their use, your clients will treasure the chatbot you deliver.

By looking into chatbots today, you are not only giving your agency a head start on competitors; you are setting your clients up to do the same thing against theirs.

Great, where do I start?

1. Get learning

First things first, you need to get up to speed on this whole chatbot thing.

Thankfully, content from thought leaders is starting to spring up. Look for content produced by companies that build chatbots, work in AI, and deal with conversational interfaces every day.

2. Partner up

Learned enough to realise chatbots have a place in your business? Fantastic. Time to partner up.

(Good) Chatbot building is a unique and brand new industry; it may take your staff time to learn the technical skills required to develop solutions for your clients. In the meantime, you should find a chatbot building company you can rely on to help bring your clients’ project to life.

3. Start pitching

You have done some reading. You have found a partner you can count on. Now to the fun part: pitching and saying “yes, we know about chatbots”.

Go through your existing client list and think about which would benefit from automating parts of their business processes using a chatbot.

Make use of your new knowledge and help your current (and future) clients stand out from the crowd.

Become the chatbot hero your clients deserve.

Read More at Web agencies and chatbots – the race to stay relevant

Categories: Designing, Others Tags: