“Just”

Brad Frost’s “Just” article from a few years ago has struck a fresh nerve with folks. It’s a simple word that can slip out easily, that might be invoked to keep text casual-feeling, but the result can be damaging. Brad:

The amount of available knowledge in our field (or any field really) is growing larger, more complex, and more segmented all the time. That everyone has downloaded the same fundamental knowledge on any topic is becoming less and less probable. Because of this, we have to be careful not to make too many assumptions in our documentation, blog posts, tutorials, wikis, and communications.

Imagine yourself explaining a particular task to an earlier version of yourself. Once upon a time, you didn’t know what you know now. Provide context. The beauty of hypertext is that we’re able to quickly add much-needed context helpful for n00bs but easy enough for those already in-the-know to scan over. And making documentation more human-readable benefits everyone.

Ethan Marcotte takes this one step further:

I’ve noticed a rhetorical trope in our industry. It’s not, like, widespread, but I see it in enough blog entries and conference talks that I think it’s a pretty common pattern: namely, the author’s sharing some advice with the reader and, if the reader’s boss or stakeholders won’t support a given course of action, suggests the reader “just do the thing anyway.”

I think this is a bad, harmful trope. And I also think we should avoid using it.

“Just” is more insidious than the more overtly painful “Obviously” or “Simply”. In fact, there is a whole list of words that could go. The result of not using words like this? Cleaner sentences and more inclusive writing. Wanna make a difference? Be like Jeremy Keith and submit Pull Requests when you see the opportunity.

The best teachers I’ve had were ones that were cautious not to make me feel dumb.

Direct Link to Article — Permalink

The post “Just” appeared first on CSS-Tricks.

Methods, Computed, and Watchers in Vue.js

One of the reasons I love working with Vue is because of how useful methods, computed, and watchers are, and the legibility of their distinction. Until understanding all three, it’s difficult to leverage the functionality of Vue to its full potential. Still, the majority of people I see confused about this framework tend to also be confused about the differences here, so let’s dig in.

In case you need a quick answer and don’t have time to read through the entire article, here’s a small TL;DR:

  • Methods: These are exactly what they sound like they might be (yay, naming!). They’re functions that hang off of an object—typically the Vue instance itself or a Vue component.
  • Computed: These properties may at first look like they’d be used like a method, but are not. In Vue, we use data to track changes to a particular property that we’d like to be reactive. Computed properties allow us to define a property that is used the same way as data, but can also have some custom logic that is cached based on its dependencies. You can consider computed properties another view into your data.
  • Watchers: These are allowing you a peek into the reactivity system. We’re offered some hooks with which to observe any properties that are stored by Vue. If we want to add a bit of functionality each time something changes, or respond to a particular change, we could watch a property and apply some logic. This means that the name of the watcher has to match what we’re trying to observe.

If any of this sounds confusing, don’t worry! We’ll dive in further below and hopefully address any confusion. If you’re familiar with vanilla JavaScript already, methods may be pretty obvious to you, aside from one or two caveats. It might then behoove you (I love that phrase) to skip to the Computed and Watchers sections.

Methods

Methods are likely something you’re going to use a lot while working with Vue. They’re aptly named as, in essence, we’re hanging a function off of an object. They’re incredibly useful for connecting functionality to directives for events, or even just creating a small bit of logic to be reused like any other function. You can call a method within another method, for example. You can also call a method inside a lifecycle hook. They’re very versatile.

Here’s a simple demo to demonstrate:

See the Pen Slim example of methods by Sarah Drasner (@sdras) on CodePen.

<code class="language-css"><div id="app"> <button @click="tryme">Try Me</button> <p>{{ message }}</p>
</div>
new Vue({ el: '#app', data() { return { message: null } }, methods: { tryme() { this.message = Date() } }
})

We could have also executed the logic in the directive itself like <button @click="message = Date()">Try Me</button>, which works very well for this small example. However, as the complexity of our application grows, it’s more common to do as we see above to break it out to keep it legible. There’s also a limit to the logic that Vue will allow you to express in a directive—for instance, expressions are allowed but statements are not.

You may notice that we’re be able to access this method within that component or Vue instance, and we can call any piece of our data here, in this case, this.message. You don’t have to call a method like you’d call a function within a directive. For example, @click=”methodName()” is unnecessary. You can reference it with @click=”methodName”, unless you need to pass a parameter, such as @click=”methodName(param)”.

Using directives to call methods is also nice because we have some existing modifiers. One such example that’s very useful is .prevent, which will keep a submit event from reloading the page, used like this:

<form v-on:submit.prevent="onSubmit"></form>

There are many more, here are just a few.

Computed

Computed properties are very valuable for manipulating data that already exists. Anytime you’re building something where you need to sort through a large group of data and you don’t want to rerun those calculations on every keystroke, think about using a computed value.

Some good candidates include, but are not limited to:

  • Updating a large amount of information while a user is typing, such as filtering a list
  • Gathering information from your Vuex store
  • Form validation
  • Data visualizations that change depending on what the user needs to see

Computed properties are a vital part of Vue to understand. They are calculations that will be cached based on their dependencies and will only update when needed. They’re extremely performant when used well and extraordinarily useful. There are many large libraries that handle this kind of logic that you can now eliminate with only a few lines of code.

Computed properties aren’t used like methods, though at first, they might look similar- you’re stating some logic in a function and returning- but the name of that function becomes a property that you’d then use in your application like data.

If we needed to filter this big list of names of heroes based on what the user was typing, here’s how we would do it. We’re keeping this really simple so you can get the base concepts down. Originally our list would output in our template using names, which we store in data:

new Vue({ el: '#app', data() { return { names: [ 'Evan You', 'John Lindquist', 'Jen Looper', 'Miriam Suzanne', ... ] } }
})
<div id="app"> <h1>Heroes</h1> <ul> <li v-for="name in names"> {{ name }} </li> </ul>
</div>

Now let’s create a filter for those names. We’ll start by creating an input with v-model that will originally be an empty string, but we’ll eventually use to match and filter through our list. We’ll call this property findName and you can see it referenced both on the input and in the data.

<label for="filtername">Find your hero:</label>
<input v-model="findName" id="filtername" type="text" />
data() { return { findName: '', names: [ 'Evan You', 'John Lindquist', ... ] }
}

Now, we can create the computed property that will filter all of the names based on what the user has typed into the input, so anything in our findName property. You’ll note that I’m using regex here to make sure that mismatched capitalization doesn’t matter, as users will typically not capitalize as they type.

computed: { filteredNames() { let filter = new RegExp(this.findName, 'i') return this.names.filter(el => el.match(filter)) }
}

And now we’ll update what we’re using in the template to output from this:

<ul> <li v-for="name in names"> {{ name }} </li>
</ul>

…to this:

<ul> <li v-for="name in filteredNames"> {{ name }} </li>
</ul>

And it filters for us on every keystroke! We only had to add a couple of lines of code to make this work, and didn’t have to load any additional libraries.

See the Pen Filter a list with Computed- end by Sarah Drasner (@sdras) on CodePen.

I can’t tell you how much time I save by using them. If you’re using Vue and haven’t explored them yet, please do, you’ll thank yourself.

Watchers

Vue has nice abstractions, and anyone who has been a programmer for a while will usually tell you that abstractions can be a pain because you’ll eventually get to a use case they can’t solve. However, this situation is accounted for, because Vue grants us some deeper access to into the reactivity system, which we can leverage as hooks to observe anything that’s changing. This can be incredibly useful because, as application developers, most of what we’re responsible for are things that change.

Watchers also allow us to write much more declarative code. You’re no longer tracking everything yourself. Vue is already doing it under the hood, so you can also have access to changes made to any properties it’s tracking, in data, computed, or props, for example.

Watchers are incredibly good for executing logic that applies to something else when a change on a property occurs (I first heard this way of putting it from Chris Fritz, but he says he might have also heard it from someone else ☺️). This isn’t a hard rule- you can absolutely use watchers for logic that refers to the property itself, but it’s a nice way of looking at how watchers are immediately different from computed properties, where the change will be in reference to the property we intend to use.

Let’s run through the most simple example possible so you get a taste of what’s happening here.

new Vue({ el: '#app', data() { return { counter: 0 } }, watch: { counter() { console.log('The counter has changed!') } }
})

As you can see in the code above, we’re storing counter in data, and by using the name of the property as the function name, we’re able to watch it. When we reference that counter in watch, we can observe any change to that property.

Transitioning State With Watchers

If the state is similar enough, you can even simply transition the state with watchers. Here’s an example I built from scratch of a chart with Vue. As the data changes, the watchers will update it and simply transition between them.

SVG is also good for a task like this because it’s built with math.

See the Pen Chart made with Vue, Transitioning State by Sarah Drasner (@sdras) on CodePen.

watch: { selected: function(newValue, oldValue) { var tweenedData = {} var update = function () { let obj = Object.values(tweenedData); obj.pop(); this.targetVal = obj; } var tweenSourceData = { onUpdate: update, onUpdateScope: this } for (let i = 0; i < oldValue.length; i++) { let key = i.toString() tweenedData[key] = oldValue[i] tweenSourceData[key] = newValue[i] } TweenMax.to(tweenedData, 1, tweenSourceData) }
}

What happened here?

  • First we created a dummy object that will get updated by our animation library.
  • Then we have an update function that is invoked on each tween step. We use this to push the data.
  • Then we create an object to hold the source data to be tweened and the function pointer for update events.
  • We create a for loop, and turn the current index into a string
  • Then we can tween over the our target dummy object, but we’ll only do this for the specific key

We could also use animation in watchers to create something like this time difference dial. I travel a bit and all my coworkers are in different areas, so I wanted a way to track what local time we were all in, as well as some signification of the change from daytime/nighttime as well.

See the Pen Vue Time Comparison by Sarah Drasner (@sdras) on CodePen.

Here we’re watching the checked property, and we’ll fire different methods that contain timeline animations that change the hue and saturation and some other elements based on the relative association to the current time. As mentioned earlier- the change occurs on the dropdown, but what we’re executing is logic that’s applied elsewhere.

watch: { checked() { let period = this.timeVal.slice(-2), hr = this.timeVal.slice(0, this.timeVal.indexOf(':')); const dayhr = 12, rpos = 115, rneg = -118; if ((period === 'AM' && hr != 12) || (period === 'PM' && hr == 12)) { this.spin(`${rneg - (rneg / dayhr) * hr}`) this.animTime(1 - hr / dayhr, period) } else { this.spin(`${(rpos / dayhr) * hr}`) this.animTime(hr / dayhr, period) } }
},

There are also a number of other interesting things about watchers, for instance: we’re given access to both the new and old versions of the property as parameters, we can specify deep if we’d like to watch a nested object. For more detailed information, there’s a lot of good information in the guide.

You can see how watchers can be incredibly useful for anything that’s updating—be it form inputs, asynchronous updates, or animations. If you’re curious how reactivity in Vue works, this part of the guide is really helpful. If you’d like to know more about reactivity in general, I really enjoyed Andre Staltz’ post and the Reactivity section of Mike Bostock’s A Better Way to Code.

Wrapping Up

I hope this was a helpful breakdown on how to use each, and speeds up your application development process by using Vue efficiently. There’s a stat out there that we spend 70% of our time as programmers reading code and 30% writing it. Personally, I love that, as a maintainer, I can look at a codebase I’ve never seen before and know immediately what the author has intended by the distinction made from methods, computed, and watchers.

The post Methods, Computed, and Watchers in Vue.js appeared first on CSS-Tricks.

Designing Button States

Tyler Sticka on the complexity of designing buttons and making sure that we’ve taken into consideration focus, hover and active states during the design process:

In truth, mouse effects are probably the least important state to design for. By accounting for more functional states early, you can lower the need for costly redesigns as your pattern library matures. Here are the fundamental states you should address early on, in approximate order of importance.

I’ve been spending a lot more time lately thinking about focus styles as being a crucial challenge when building for the web and so I particularly take Tyler’s advice to heart. He argues that we should repeat this maxim throughout the button design process:

“I do solemnly swear never to disable browser focus styles without including a thoughtfully designed replacement.”

The first step: focusing on focus styles.

On a related note, we recently did a series on CSS Basics that included a post dedicated to link styling for various link states. Also, there’s a pretty good post that’s related to this topic called Buttons in Design Systems that tackles a bunch of Direct Link to Article — Permalink

The post Designing Button States appeared first on CSS-Tricks.

Static File Hosting Doesn’t Have To Be So… Static

A huge high-five and welcome to Netlify for the sponsorship this week.

If you haven’t heard of Netlify, the big thing you should know is that it’s web hosting, but more than that. It’s web hosting with the developer workflow squarely at heart. You can spin up a site on Netlify in literally seconds. One way is through their robust CLI. Another way, that I find very comfortable (and just did the other day), is to log into the Netlify web interface, create a new site, and connect a Git repo to it. Plus I can give it a command that will run my site’s build process when I push to master. Now anything I push up goes live on my website, which is HTTPS and on a CDN. Uh, wow. Of course, I can also point a custom domain name at Netlify and now we’re cooking with gas.

The JAMstack is at the heart of Netlify. It’s static file hosting, because static file hosting is super fast and secure. It means you can build your site with all kinds of fun, powerful, modern site generators like Hugo, Gatsby, Metalsmith, or 11ty. The site I spun up myself was my own custom thing with a Gulp build process that ran Sass and Nunjucks.

Try spinning up a Gatsby site right now!

Static sites aren’t just HTML-only zero-interactivity stone statues.

In fact, I think static sites are one of the ingredients to the larger world of serverless technology, in which functionality is handled by services that are perfect for the job.

Netlify knows this, of course, so they’ve released has some brand spanking new features that allow you to add interactivity and functionality to your site:

Form Handling

Just add a netlify attribute to the <form>, configure where you want the redirection and email notifications to go, and you’re set. You don’t have to write any server-side code or JavaScript. Even blast that data over to Zapier to integrate with a million other web services. They don’t inject JavaScript to make this work – it’s handled at the CDN level.

You can also receive and manage submissions in your Netlify dashboard, so this can be yet another thing that brings together site management under one roof.

Built-in AWS Lambda Functions

JavaScript functions are designed to handle requests. Does your site need to trigger a Slack message? Send an SMS through Twilio? Process data? Now you can host your cloud functions right in the same repo as your site and Netlify will handle pushing them over to AWS Lambda for you. You don’t have to configure anything or even bother setting up your own AWS account.

Plus, your functions benefit from the power of Deploy Previews and rollbacks. As in, your functions live in your version control along with the rest of your site, so they are easy to manage and come with all the comfort and advantages of working with Netlify. Wanna dig in? Here’s a tutorial by Alex MacArthur that goes deep.

Identity

Do you need to log in to your website for admin purposes? Or have users log in? With Identity, Netlify gives you a really easy way to make that happen. Imagine a feature like a gym website offering a food log for members. The member could log in with Google/Twitter/etc and save/view/edit their food data (via cloud functions of course!).

Social login is a handy feature, but it’s not required. You can manage and authenticate users that aren’t Netlify users or users of any other service. You’ll be able to handle log in, sign up, password recovery and all that. Very useful for gated content, site administration, and integrating with any service that understands JSON Web Tokens.

All on Netlify

All those things without having to go out, evaluate and purchase tools or customize open source tools, integrate them into your project, and then manage multiple disparate accounts/services.

How much does it all cost? There’s a good chance it doesn’t cost you anything. Small projects probably fit within Netlify’s free tier. If you grow up and build something big, they you might get into a paid tier, but still good news, you only pay for what you use.

Go check out Netlify right now.

The post Static File Hosting Doesn’t Have To Be So… Static appeared first on CSS-Tricks.

Creating Themeable Design Systems

Brad frost picks up the ongoing conversation about design systems. Where many posts seem to center on how to create one and how to enforce it, the big takeaway here is that design systems are not synonymous with constraints. They’re only as strict as we make them and new CSS features like custom properties actually open up new creative possibilities—something Andres Galante and Cliff Pyles recently pitched right here on CSS-Tricks.

Brad:

The aesthetic layer is often the most malleable layer of the frontend stack, which means that we can create systems that allow for a lot of aesthetic flexibility while still retaining a solid underlying structural foundation.

This not only sounds right, but puts a strong punctuation on why we love CSS: it’s a set of styles that can be applied an infinite number of ways to the same HTML markup. A new layer of paint can be slapped on at any time, but the beams, walls and ceiling of the building can remain constant. Dave Rupert’s personal site is a prime example of this and he details his approach to theming.

Ah, CSS Zen Garden…

Direct Link to Article — Permalink

The post Creating Themeable Design Systems appeared first on CSS-Tricks.

A Quick Way to Remember the Difference Between `justify-content` and `align-items`

I was talking with a pal the other day and moaning about flexbox for the millionth time because I had momentarily forgotten the difference between the justify-content and align-items properties.

“How do I center an element horizontally with flex again?” I wondered. Well, that was when she gave me what I think is the best shorthand way of remembering how the two work together.

She said that justify-content positions elements across the horizontal axis because the word itself is longer than align-items. At first I thought this was a really silly idea but now this is how I remember it. I even used it five minutes ago when I needed to make these two quick demos:

See the Pen justify-content: center by Robin Rendle (@robinrendle) on CodePen.

See the Pen align-items: center by Robin Rendle (@robinrendle) on CodePen.

So, to summarize:

  • justify-content: longer word: horizontal alignment
  • align-items: shorter word: vertical alignment

This had me thinking if there are there any other mnemonic devices or ways that to remember complex things in CSS? Are there any other tricks you’d recommend? It sort of reminds me of the way kids are taught to remember the names of planets with things like, “My Very Educated Mother Just Showed Us Nine” where the first letter in each word represents the first letter of each planet: Mercury, Venus, Earth, Mars, Jupiter, Saturn, Uranus and Neptune.

The post A Quick Way to Remember the Difference Between `justify-content` and `align-items` appeared first on CSS-Tricks.

A DevTools for Designers

There has long been an unfortunate disconnect between visual design for the web and web design and development. We’re over here designing pictures of websites, not websites – so the sentiment goes.

A.J. Kandy puts a point on all this. We’re seeing a proliferation of design tools these days, all with their own leaps forward. Yet…

But, critically, the majority of them aren’t web-centric. None really integrate with a modern web development workflow, not without converters or plugins anyway; and their output is not websites, but clickable simulations of websites.

Still, these prototypes are, inevitably, one-way artifacts that have to be first analyzed by developers, then recreated in code.

That’s just a part of what A.J. has to say, so I’d encourage you to read the whole thing.

Do y’all get Clearletter, the Clearleft newsletter? It’s a good one. They made some connections here to nearly a decade of similar thinking:

  • Jason Santa Maria: A Real Web Design Application
  • Jeffrey Zeldman: An Indesign for HTML and CSS?
  • Jon Gold: The Evolution of Tools

I suspect the reason that nobody has knocked a solution out of the park is that it’s a really hard problem to solve. There might not be a solution that is universally loved across lines. Like A.J., I hope it happens in the browser.

Direct Link to Article — Permalink

The post A DevTools for Designers appeared first on CSS-Tricks.

Tracking Uncertainty of Work

Ryan Singer writes about project and time management issues that I’ve been experiencing lately. He describes two states of every project: uncertainty and certainty, or “figuring things out” and “making it happen.”

Ryan describes it like this:

Work is like a hill with two sides. There’s an uphill phase of figuring out what to do and how to approach the problem. That’s the climb. After you reach the top, there aren’t anybody [sic] ruinous unknowns. You can see down to the other side and finish executing. It’s straightforward to estimate and finish the work from that point.

As far as I see it, the hardest thing about the first half of every project is making sure that everyone on a team is communicating constantly as tiny design decisions can have enormous, cascading effects on an engineer. I think that’s something I’ve always struggled with since I just want to get to the “making it happen” part as soon as humanly possible. It also goes back to something Geoff wrote a little while back about setting good expectations before and during the project process.

Direct Link to Article — Permalink

The post Tracking Uncertainty of Work appeared first on CSS-Tricks.

Vue Design System

We talk a lot about Vue around here, including some practical applications of it, but haven’t gotten deep into designing for it. In this post, Viljami Salminen describes his Vue design process and the thinking that led him to build the Vue Design System:

A design system can help establish a common vocabulary between everyone in an organization and ease the collabo­ration between different disciplines. I’ve seen it go the other way around too when important decisions have been made in a rush. To avoid that, Vue Design System introduces the following framework for naming that I’ve found working well in the past…

Viljami lists Design Principles, Tokens, Elements, Patterns, and Templates as the way in which he structures a system and I think it’s a pretty interesting approach and a parallel to Lucas Lemonnier’s post on creating design systems in Sketch, using Atomic Design as the structure. I particularly like how Viljami fits everything together in the example style guide that’s provided.

Direct Link to Article — Permalink

The post Vue Design System appeared first on CSS-Tricks.

Solved With CSS! Colorizing SVG Backgrounds

CSS is getting increasingly powerful, and with features like CSS grid and custom properties (also known as CSS variables), we’re seeing some really creative solutions emerging. The possibilities are still being explored on what CSS can do to make writing UI’s simpler, and that’s exciting!

One of those is now one of my favorite CSS features: filters. Let’s look at how we can use filters to solve a problem you may have encountered when working with SVG as a background image on an element.

CSS Filters

First, let’s start by with an overview of filters. They include the following functions:

  • blur()
  • brightness()
  • contrast()
  • drop-shadow()
  • grayscale()
  • hue-rotate()
  • invert()
  • opacity()
  • saturate()
  • sepia()

These effects can also be achieved with SVG filters or WebGL shaders, but CSS filters are the easiest way to implement basic transformations in the most browser-efficient manner. Because they are shortcuts of SVG filter effects, you can also use filter: url() and specify a filter effect ID onto any element. If you want to play around with custom filters, I recommend checking out cssfilters.co.

The Problem: Editing SVG Backgrounds

I love using the SVG (scalable vector graphics) format for web design. SVG is a great image format for the web, and since it’s based on code, it allows for high-quality responsive and interactive content. When you inject SVG onto the page, you have access to each of its internal elements and their properties, allowing you to animate them, update values (such as color), and dynamically inject additional information. SVG is also a great icon format, especially instead of icon fonts, and in smaller UI elements due to its high quality (think: retina screens) and small image size (think: performance).

I find that often, when SVG is used for these smaller elements, or as a large area of illustration, it’s included as a background image for simplicity. The drawback to this is that the SVG is no longer under your control as a developer. You can’t adjust individual properties, like fill color, of an SVG background because it is treated just like any image. This color conundrum can be solved with CSS! Filters to the rescue!

Adjusting Brightness

The first time I discovered the SVG background challenge was when I was working on a website that had white SVG icons for social share icons that lived on a background determined to match that application. When these icons were moved onto a white background, they were no longer visible. Instead of creating a new icon, or changing the markup to inject inline SVG, you can use filter: brightness().

With the brightness filter, any value greater than 1 makes the element brighter, and any value less than 1 makes it darker. So, we can make those light SVG’s dark, and vice versa!

What I did above was create a dark class with filter: brightness(0.1). You can also do the opposite for darker icons. You can lighten icons by creating a light class with something like filter: brightness(100) or whatever is suitable to your needs.

Icons with a fill color of #000, or rgb(0,0,0) will not brighten. You need to have a value greater than 0 in any of the rgb channels. fill: rgb(1,1,1) works great with a high brightness value such as brightness(1000), but even brightness(1000) will not work on pure black. This is not an issue with light colors and white.

Adjusting Color

We’ve now seen how to adjust light and dark values with a brightness() filter, but that doesn’t always get us the desired effect. What if we want to inject some color into those icons? With CSS filters, we can do that. One little hack is to use the sepia filter along with hue-rotate, brightness, and saturation to create any color we want.

From white, you can use the following mixtures to get the navy, blue, and pink colors above:

.colorize-pink { filter: brightness(0.5) sepia(1) hue-rotate(-70deg) saturate(5);
} .colorize-navy { filter: brightness(0.2) sepia(1) hue-rotate(180deg) saturate(5);
} .colorize-blue { filter: brightness(0.5) sepia(1) hue-rotate(140deg) saturate(6);
}

The world is your oyster here. SVG is just one use case for multiple filters. You can apply this to any media type—images, gifs, video, iframes, etc., and support is pretty good, too:

This browser support data is from Caniuse, which has more detail. A number indicates that browser supports the feature at that version and up.

Desktop

Chrome Opera Firefox IE Edge Safari
18* 15* 35 No 17 6*

Mobile / Tablet

iOS Safari Opera Mobile Opera Mini Android Android Chrome Android Firefox
6.0-6.1* 37* No 4.4* 64 57

One final note here is to remember your user! Filters will not work in Internet Explorer, so please send a visible image to all of your users (i.e. don’t use a white SVG with an applied filter on a white background, because your IE users will not see anything). Also, remember to use alternative text for icon accessibility, and you’ll be golden to use this technique in your own applications!

The post Solved With CSS! Colorizing SVG Backgrounds appeared first on CSS-Tricks.