Original Source: http://feedproxy.google.com/~r/CreativeBloq/~3/2tklqxlfueg/best-ipad-stylus

If you want to use one of the many fantastic iPads available now as a tool for drawing, you're going to need a stylus. Your impulse may well be to simply pick up the Apple Pencil, and while this is a great buy and you won't go wrong with it, we'd recommend taking a moment to consider some of the alternative options out there. 

There are many iPad-compatible styluses available from other manufacturers, and many of them are extra-attractive by virtue of the fact that they cost considerably less than Apple's version. We've picked out the best of the best styluses available right now, for all iPad users and all budgets, so you can find which one is right for you and get to drawing.

The best tablets with a stylus for drawing and note-taking

In the following guide, we'll walk you through the best iPad styluses with integrated buttons that you can customise for different functions, and we'll help you decide whether an iPad stylus with a hard nib or soft nib is likely to be better for your requirements. Read on to find out exactly what stylus for your iPad you should buy – and where to buy it for the best price.

The new Apple Pencil (2018) works with the third-generation 12.9-inch iPad Pro or the 11-inch iPad Pro. The original Apple Pencil works with iPad Pro 12.9-inch (second and first generation), iPad Pro 10.5-inch, iPad Pro 9.7-inch and iPad (6th generation).

The Apple Pencil is, of course, the natural choice of stylus for iPad – but only if you own one of the two iPad models that are compatible with it: an iPad Pro or sixth-generation iPad (2018). If you do, there isn't a better stylus to write and draw with on the market. Not only is it exceptionally comfortable to use, Apple has eliminated many of the issues that can dog other styluses – such as inadequate palm rejection and clear lag that instantly makes you feel disconnected to what you're producing on the screen. The astonishing pressure levels mean that the Apple Pencil reproduces your movements perfectly, at even the most acute angles, and it enhances all your favourite creative iOS apps. The bottom line is that if you've forked out the cash for an iPad Pro, you'd be daft not to swallow the extra expense and go straight for an Apple Pencil.

Also read: Apple Pencil review

Wacom boasts an industry-leading reputation thanks to its fabulous range of dedicated drawing tablets. So it's only natural that the company produces an attractive line of styluses as well. As well as being our favourite iPad stylus for artists, the Wacom Bamboo Sketch also takes the plaudits for general use on the iPad Air and iPad Mini series thanks to its compatibility with iOS devices. Rather than trying to exactly mimic a traditional rounded pen, the Bamboo Sketch favours an ergonomic triangular design for better grip. It's an excellent all-rounder, but its fine tip and pressure-sensitive nibs make it just about as close an experience to sketching on paper as you can get. With an epic battery life (recharged via USB) it uses Bluetooth to connect to your iPad, which brings the integrated shortcut buttons into play, too, enabling you to set up handy shortcuts within your chosen iOS apps.

Despite the fact that you can snag one for less than £30, the Hahakee iPad stylus does a good job of feeling like a premium product, thanks to an aluminium alloy build with a polished finish. It's pleasant to hold and use, and thanks to the healthy forty-hour battery life, you'll find yourself easily getting lost in your projects before it needs a charge. Charging is accomplished via the micro-USB port concealed in the top. With a fine tip, the Hahakee stylus is pleasingly precise, and spare nibs in the box ensure it'll keep on being usable for a long time (indeed, probably considerably longer than the iPad you're drawing on). It's no Apple Pencil, but for the money, it's a great buy.

Adonit has been refining its stylii for more than eight years now, and the Pixel is still one of its best for drawing on iPad. Bluetooth enabled and compatible with many of the sorts of apps creatives will likely be using on their tablets, the Pixel boasts 2048 levels of pressure sensitivity and a range of function buttons on its body that can be assigned to the user's preferred tools (though be warned these can be easy to knock accidentally if you're not paying attention). The battery should last for about 15 hours of use, allowing you to get really stuck into your projects, and the sleek design makes the Pixel stylus genuinely enjoyable to use.

If you're not sold on the idea of spending upwards of $20/£20 on a simple pointing device, and don't need the specialised functioning of the iPad styluses above, then Adonit's budget option – the Adonit Mark – is worth considering. Despite its cheap price tag, this stylus has been designed to feel as comfortable as possible in your hand, with its triangular anti-roll design. It retains the precision you'd expect from the sole-purpose stylus manufacturer, largely thanks to its smudge-free mesh tip. The Adonit Mark won't win any innovation awards, but if you just want a stylus for navigating around your iPad, you won't find a better cheaper iPad stylus than this. 

Related articles:

The best tablets with styluses10 top new best tools for traditional artists Best cheap Wacom tablets you can buy

Original Source: https://www.smashingmagazine.com/2019/04/z-index-component-based-web-application/

Managing Z-Index In A Component-Based Web Application

Managing Z-Index In A Component-Based Web Application

Pavel Pomerantsev

2019-04-03T14:00:08+02:00
2019-04-03T16:05:46+00:00

If you’ve done any complex web UI development, you must have at least once furiously tried driving an element’s z-index up to thousands, only to see that it’s not helping position it on top of some other element, whose z-index is lower or even not defined at all.

Why does that happen? And more importantly, how to avoid such issues?

In this article, I’ll recap what z-index actually is and how you can stop guessing whether it might work in any specific case and start treating it just like any other convenient tool.

The Hierarchy Of Stacking Contexts

If you imagine the webpage as having three dimensions, then z-index is a property that defines the z coordinate of an element (also called its “stacking order”): the larger the value, the closer the element is to the observer. You can also think of it as a property affecting paint order, and this will in fact be more correct since the screen is a two-dimensional grid of pixels. So, the larger the z-index value, the later the element is painted on the page.

There is, however, one major complication. The z-index value space is not flat — it’s hierarchical. An element can create a stacking context which becomes the root for z-index values of its descendants. It would be best to explain the concept of stacking contexts by using an example.

The document body has five div descendants: div1, div2, div3, div1-1, and div2-1. They’re all absolutely positioned and overlap with each other. div1-1 is a child of div1, and div2-1 is a child of div2.

See the Pen stacking-contexts by Pavel Pomerantsev.

Let’s try to understand why we see what we see. There are quite elaborate rules to determine paint order, but here we only need to compare two things:

z-index Values
If an element has a higher z-index, it’s painted later.
Source Order
If z-index values are the same, then the later it’s in the source, the later it’s painted.

So if we don’t take stacking contexts into account, the order should be as follows:

div1
div2
div3
div1-1
div2-1

Note that div2-1 is in fact overlapped by div3. Why is that happening?

If an element is said to create a stacking context, it creates a basis for its children’s z-index values, so they’re never compared with anything outside the stacking context when determining paint order. To put it another way, when an element creating a stacking context is painted, all its children are painted right after it and before any of its siblings.

Going back to the example, the actual paint order of body’s descendant divs is:

div1
div2
div3
div1-1

Notice the absence of div2-1 in the list — it’s a child of div2 which creates a stacking context (because it’s an absolutely positioned element with a z-index other than the default value of auto), so it’s painted after div2, but before div3.

div1 doesn’t create a stacking context, because its implicit z-index value is auto, so div1-1 (its child) is painted after div2 and div3 (since its z-index, 10, is larger than that of div2 and div3).

Don’t worry if you didn’t fully grasp this on first reading. There’s a bunch of online resources that do a great job in explaining these concepts in more detail:

“The Stacking Context,” MDN web docs, Mozilla
“What No One Told You About Z-Index,” Philip Walton

Note: It’s also great to be familiar with general paint order rules (which are actually quite complex).

The main point of this piece, however, is how to deal with z-index when your page is composed of dozens and hundreds of components, each potentially having children with z-index defined.

One of the most popular articles on z-index proposes grouping all z-index values in one place, but comparing those values doesn’t make sense if they don’t belong to the same stacking context (which might not be easy to achieve in a large application).

Here’s an example. Let’s say we have a page with header and main sections. The main section for some reason has to have position: relative and z-index: 1.

See the Pen z-index-step1 by Pavel Pomerantsev.

We’re using a component architecture here, so CSS for the root component and every child component is defined in dedicated sections. In practice, components would live in separate files, and the markup would be generated using a JavaScript library of your choice, like React, but for demonstration purposes it’s fine to have everything together.

Now, imagine we’re tasked with creating a dropdown menu in the header. It has to be stacked on top of the main section, of course, so we’ll give it a z-index of 10:

See the Pen z-index-step2 by Pavel Pomerantsev.

Now, a few months later, in order to make something unrelated work better, we apply the translateZ hack to the header.

See the Pen z-index-step3 by Pavel Pomerantsev.

As you can see, the layout is now broken. An element with z-index: 1 sits on top of an element with z-index: 10, in the absence of any other z-index rules. The reason is that the header now creates a stacking context — it’s an element with a transform property whose value is anything other than none (see full rules) and its own z-index (0 by default) is lower than that of the main section (1).

The solution is straightforward: give the header a z-index value of 2, and it’ll be fixed.

See the Pen z-index-step4 by Pavel Pomerantsev.

The question is, how are we supposed to come to this solution if we have components within components within components, each having elements with different z-indices? How can we be sure that changing z-index of the header won’t break anything else?

The answer is a convention that eliminates the need for guesswork, and it’s the following: changing z-indices within a component should only affect that component, and nothing else. To put it differently, when dealing with z-index values in a certain CSS file, we should ideally only concern ourselves with other values in that same file.

Achieving it is easy. We should simply make sure that the root of every component creates a stacking context. The easiest way to do it is to give it position and z-index values other than the default ones (which are static and auto, respectively).

Here’s one of the ways to structure the application. It uses more elements than the previous one, but computation associated with extra DOM elements is cheap whereas developer’s time (a lot of which can sometimes be spent on debugging stacking issues) is definitely not.

See the Pen z-index-step5 by Pavel Pomerantsev.

header__container and main__container both have position: relative and z-index: 0;
header__overlay now has z-index: 1 (we don’t need a large value since it’s only going to compete for stacking order with other elements within the header);
root__header now has z-index: 2, whereas root__main keeps its z-index: 1, and this is what makes the two siblings stack correctly.

(Note also that both have position: relative since z-index doesn’t apply to statically positioned elements.)

If we look at the header code now, we’ll notice that we can remove the z-index property from both the container and the overlay altogether because the overlay is the only positioned element there. Likewise, the z-index is not required on the main container. This is the biggest benefit of the proposed approach: when looking at z-indices, it’s only the component itself that matters, not its context.

See the Pen z-index-step6 by Pavel Pomerantsev.

Such an architecture is not without its drawbacks. It makes the application more predictable at the expense of some flexibility. For example, you won’t be able to create such overlays inside both the header and the main section:

See the Pen z-index-step7 by Pavel Pomerantsev.

In my experience, however, this is rarely a problem. You could make the overlay in the main section go down instead of up, in order for it to not intersect with the header. Or, if you really needed it to go up, you could inject the overlay HTML at the end of the body and give it a large z-index (“large” being whatever’s larger than those of other sections at the top level). In any case, if you’re not in a competition to build the most complicated layout, you should be fine.

To recap:

Isolate components in terms of z-index values of elements by making the root of each component a stacking context;
You don’t have to do it if no element within a component needs a z-index value other than auto;
Within a component’s CSS file, maintain z-index values any way you like. It might be consecutive values, or you could give them a step of 10, or you can use variables — it all depends on your project’s conventions and the size of the component (although making components smaller is never a bad thing). Preferably, only assign z-index to sibling elements. Otherwise, you may inadvertently introduce more stacking contexts within a component, and you’re faced with the same issue again, luckily on a smaller scale;
Debugging becomes easy. Find the first ancestor component of the two elements that are not stacked correctly, and change z-indices within that component as necessary.

This approach will hopefully bring back some sanity to your development process.

(dm, ra, il)

Original Source: http://feedproxy.google.com/~r/CreativeBloq/~3/o4K3CZxkUDc/create-perfect-user-flows

What exactly is a user flow? Visually, it's a bit like a dance mat. Right foot here. Left foot over there. Now bring them together, turn and repeat. Without knowing how to dance, you're still able to stand on this mat and move along with your feet stepping in the right places in the right order. A user flow is just that. A loose but coordinated dance with your website. It's important that you know where a user will step and in what order for that dance to go well.

Working through the expectations of users and crafting an overall positive user experience can be a complicated mixture of data points, use cases, wireframes and prototypes to connect the dots before the project is fully built out. With so many moving parts, it's easy to get tripped up or have a stakeholder misunderstand the vision. 

The 20 best wireframe tools

Unlike a design showcasing what a user will interact with after development, the role of a user flow is to set the ground rules for what the subsequent wireframes and designs will represent. It's the strategy document to design how the user flows from point to point.

What you need for a user flow

Apply user flows to work out how navigation will work in apps, as well as websites

Whether you work for an agency or directly with a client as a freelancer, you're probably no stranger to the confusion that comes with sharing early designs with a client. In your head, you understand the intricacies of how each block of content fits into the overall experience and it's glorious. Then you show someone else or, even worse, the client and they don't get it. They get hung up on the wrong details, often because they don't have the full vision in front of them yet. Which is where strategy documents that outline purpose – like a user flow – come in handy to keep things moving forward.

To do that, you'll need the following:

Business goals
Why do you want someone to visit your website? You can typically get these from your point of contact with a brief conversation. Are they launching a new service, product or trying to generate traffic for a specific area of the site? The more granular you can get the better. Goals lead to accountability from all sides and will benefit the users.

User goals
Why is someone actually visiting your website? Be hesitant to take these directly from the client unless they have done user testing or some kind of data-driven research to support it. Otherwise you'll end up with the same business goals with a different twist. 

Entry points and user types
Based on the data, where are users landing right now? Do users typically land on a blog post? On a portfolio piece or a featured product? More importantly, how are they getting there? If organic traffic is driving mostly to the blog, those users may flow between secondary or tertiary pages differently than someone coming in from a referring website, social media or an email campaign. You may need to map them out differently to properly showcase the flow.

Yellow Brick Roads (YBRs)
What is the ideal path for users to travel between pages to meet both the business and user goals? To get them from the entry point to the results-driven destination? As users flow in non-linear ways, what are the edge cases that users may flow into? For example, if your YBR is a blog post landing page that clicks through to a service page and then the contact page, where might some users get lost? Do some users end up on the about page? Where do they go from there? Map out those edge cases and how they branch off from your ideal scenarios.

A lo-fi wireframe is useful for getting a rough idea of how a page works

You can extract the last two points with Google Analytics and the User Explorer feature for individual user flow paths or the Users Flow section to see a 10,000 foot view of trending paths for all users on the site. Both are worth getting familiar with (see our top tools in Google Analytics post). 

Think of the dance mat. Where do users place their feet first (landing page)? Where does each foot go next (page two, three, four, etc)? Show that in a flow chart for each user type or goal. 

There are plenty of plugins, frameworks or software solutions that can be used to create diagrams; let's look at what the deliverable should be in a user flow.

Easily shared and printed. This may seem like a no-brainer but you'd be surprised how often people bring printouts for diagrams that are unreadable. If there are too many steps or too much text to fit clearly on an 8.5 x 11-inch printout, you're overcomplicating things.Bridge the communication gap between clients, stakeholders, designers and developers. Flows show how a user will navigate and interact with the site jumping between pages. This is important to give a framework for everyone to unify their understanding moving forward.Showcase the path(s) toward each priority business and customer goal, common entry point pathways and a streamlined YBR pathway that offers up missed opportunities for key content. For clarity, this does not happen in a single flow. This will be multiple stand-alone flows.

With buy-in from stakeholders, you can take these user flow documents and use them to inform the designers creating wireframes to ensure they follow the core user experience strategies. They can be treated like a check list to validate the project is meeting the goals at each step.

Learn more about UX and more at generate New York 2019. Click the image to book your ticket

Expand user flows into wireframes

Map out edge cases and consider how they branch off from your ideal scenarios

Most of us have experience with wireframes in some form. Wireframes are used to represent the strategy behind a website layout. Sometimes they will be handed off to developers to begin building the bones of the infrastructure. They're the blueprint to the home. They help stakeholders understand the 'why' of the strategy without getting roped into details like fonts, colours or content. 

Many times someone responsible for the user experience or design of a project will jump directly into the wireframe because they construct their own mental model of a user flow. The problem with that is they run the risk of internalising strategy, applying unforeseen bias, repurposing old ideas and may become a bottleneck between the design and the communication of the design. Clear communication is paramount.

User flows will help mitigate those risks because they pass down structured communication. It adds a layer of checkpoints.

There are various levels of visual fidelities when it comes to wireframing. Some prefer low-fidelity templated wireframes they can drop into place to represent the general information architecture of a given page. Others prefer high-fidelity wireframes that are very much designs but without the proper font, copy, colours and imagery in place. It's important to know your audience and what to use when. Realistically, if you are working from user flows you should move into a higher-fidelity wireframe that then grows into a prototype more easily. 

It’s a good idea to start on paper, whiteboard or some tablet sketching tool

It's a good idea to start on paper, whiteboard or some tablet sketching tool. This enables you to focus on the quick ideation of potential solutions to problem areas and keeping the user on the ideal pathway. 

To get started, you will need a list of each page to design and build into the website: home, about, service listing, etc. That acts as your checklist to ensure you don't miss anything. Start with rough sketches for each of those based on the goals you've uncovered previously. 

Where does the navigation go? How are you going to convey the business goals on the home page? Are you following a 12-column grid for speed of understanding the structure with a certain demographic or is it a more progressive interactive site that can exude a bit more expressive freedom? This is where you determine the best way to achieve the goals and build on top of a strong base.

User flow documents can inform the creation of wireframes , as in this example for Sullair

Once those rough sketches are complete, select one of your user flows. For example, if the ideal pathway is a blog post landing page that the user clicks through to a service page and then the contact page, test that out with your wireframes. Look at your blog post landing page: how would a user find the service page based on your structure? Is it clear? Is it truly a priority on that page's layout or is it just another link tucked away on the sidebar, footer or navigation?

The user flow becomes an auditor to your work, the unbiased fact checker to your wireframes. Even better, when you can show a client you've connected all of the dots they deemed a priority, they become very satisfied with the work at each step. It reminds them of why they hired you to do this in the first place. It's a relief and they will likely begin to settle into your full process. 

If you don't show you've provided a solution for those goals or a way to alleviate the existing pain points, each phase of your project will rely heavily on trust. Even with the best of us, that can only take you so far until comments like 'why didn't we catch that?' sneak into your conversations. The later those pop up, the more expensive they are to fix. The more often they pop up, the more that trust erodes. That's why following a process like this and supporting decisions with data and focus is so crucial.

Interactive prototypes

Showcase the path(s) toward each priority business and customer goal

Now you've validated the wireframe implementation with user flows, it's time to turn them into interactive prototypes. These are basically clickable static image files that enable you to jump to another image file to give the impression of navigating a website. Not only are these great for clients to experience, it's also very important to ensure your developers and designers are on the same page. That great layout idea may actually add 100 hours of development time and be out of scope. This kick-starts those conversations before time is wasted.

You or your design team may have a very clear vision for what this set of wireframes will evolve into in the weeks ahead. Maybe you're even taking the wireframes into a full design and prototyping that. That's not uncommon. But one problem persists. Those subtle hover states and microinteractions that support an intuitive user experience are hidden away inside of someone's mind. A stakeholder doesn't see that vision yet but prototypes can help.

Much like wireframing, prototypes can come in various fidelities. At Candorem we have used InVision for years because of the simplicity of creating sharable prototypes that focus on the user pathways between pages and key interactions or overlays. Drop in existing images and draw hot spots over links. Creating low-fidelity interactions then enables you to share a prototype within an hour, depending on complexity.

Bring out the hi-fidelity wireframes when you want to drill down into content in detail

Others may suggest using Adobe XD, which is far more robust in showcasing interactive elements of a design beyond page transitions. It's like if you combined Adobe's Creative Suite (get Adobe Creative Cloud here) with InVision as a single product. You could create your wireframes, full design concepts and prototypes in one fell swoop if you're organised enough. The important part is connecting the pages to craft an experience someone can click through and understand the vision.

It’s important to set expectations

Again, know your audience. Even with basic click-throughs in InVision, some clients confuse it with a built-out website. It's important to set expectations. Communicate exactly what it is you're showing a client with the prototype and, more importantly, what kind of feedback you are looking for at this stage. Are you looking for feedback on flow between those key pages in the user flow? Are you looking for feedback on the page transition animations in the prototype? The content that fits into the spaces and where it will come from? Communicate that. It will help you grow as a professional very quickly and the quality of your work will increase exponentially. 

You can judge the success of this process by beginning the prototype review on a key landing page like the blog from earlier. Ask someone in the review from the stakeholder team to click through to a specific page on the prototype and see what paths they take. Even in edge cases where the user travels down another path, as users travel in non-linear fashion, they should be able to locate the key pages that reflect a business goal. Your work must be accountable to that.

Your ability to showcase the critical thinking and implementation behind key decisions, as well as how you or your team have adapted your goals into an intuitive experience, is crucial. That's what enables you to reframe perspectives, move away from short-term trends and obtain support from the otherwise loudest people in the room. Strategy at every step.

This article was originally published in issue 315 of net, the world's best-selling magazine for web designers and developers. Buy issue 315 here or subscribe here.

Related articles:

10 rules for making user-friendly web formsPerformance UX: A primer10 steps to an engaging user experience

Original Source: http://feedproxy.google.com/~r/tympanus/~3/_SjP5P-Abek/

Responsible JavaScript: Part I

Jeremy Wagner plots a course to avoid the unnecessary bloat and inaccessible patterns of current JavaScript trends.

Read it

This content is sponsored via Thought Leaders
Core, a front-end feature kit by Mason, free!

Grab the free feature kit that made it to #1 on Product Hunt and start building front-end features faster than you ever thought possible!

Get Core free

Announcing CodeSandbox v3

Read all about this major CodeSandbox update that includes VSCode extensions, many design tweaks, and a new devtool pane.

Read it

Enforcing Accessibility Best Practices with Automatically-Generated IDs

Brad Frost describes a useful technique for auto-generating IDs to help with accessibility.

Read it

How To Align Things In CSS

Rachel Andrew shows different ways of aligning elements in CSS.

Read it

Name It, and They Will Come

An interesting read by Dan Abramov on the importance of telling a story when sharing a new project.

Read it

Free Font: En Garde

Andros Souza shares his first font project.

Get it

Building a dependency-free site in 2019

Michelle Barker shares how she built her site in HTML, CSS and nothing else.

Read it

JavaScript Grammar

Get the PDF version of this JavaScript book by Greg Sidelnikov for a retweet.

Check it out

codetalks.tv

Codetalks.tv puts together the best dev talks in a categorized video platform, made by developers for developers.

Check it out

Designing And Building For Systems

Daniel Eden gives some advice on building for design systems.

Read it

Generative Poster

Create a generative art poster in this demo by David A.

Check it out

code-server

Code-server is VS Code running on a remote server, accessible through the browser.

Check it out

UITerminal

UITerminal is a Terminal-style CSS framework.

Check it out

VexChords

A JavaScript guitar chord renderer.

Check it out

oneliners.js

Some useful coding one-liners put together by Mike Skowronek.

Check it out

Scroll Anchoring in Firefox 66

Ryan Hunt writes about the new scroll anchoring feature in Firefox.

Read it

How an MIT Research Group Turned Computer Code Into a Modern Design Medium

The fascinating story of how code became a design medium.

Read it

Alien Invasion by Gal Shir: Web Animation by Kono

A CSS-only implementation of the “Alien Invasion” animation by Gal Shir. Made by Kono.

Check it out

Vue.js and D3: A Chart Waiting To Happen

Simon Wuyts shares this summary of a talk he gave at the Vue.js Antwerp meetup.

Read it

Everything I know about freelancing

Andy Adams offers some valuable insights to freelancing.

Read it

Collective #504 was written by Pedro Botelho and published on Codrops.

Original Source: http://feedproxy.google.com/~r/1stwebdesigner/~3/unF2fSeq_vE/

There are a ton of ways to learn web design and development. Some people prefer video courses, while others love reading books and webpages and applying the knowledge themselves.

Another way to learn is through online games! These will test your design skills, correct you when you’re wrong, and teach you basic concepts. If you love learning through doing, make sure to try these games!

Can’t Unsee

This game walks you through various simple design choices, prompting you to pick the one that looks correct and explaining why one is wrong and one is right. You can click a button to directly compare the images, making it easy to understand the difference. This will test your eye for subtle designs. At the end, see how you rank against other players!

Kern Type

Kerning is the spacing between letters, and an important skill for typographers and designers to learn. This kerning minigame will let you drag around the letters, then compare them to the solutions of a pro designer.

Shape Type

Another one for typographers, Shape Type tests your ability to accurately and beautifully shape letters in a design. You can easily compare your work to the designer’s with fluid transition animations that show you where you might have gone wrong.

The Bezier Game

If you make vector graphics, fonts, or CSS animations, you might have encountered Bezier curves. The Bezier Game will help teach you to work with this tool by taking you through various shapes, lines, and circles to fill out with curves. By the end you should have a better understanding of how Bezier curves work.

Color

Ready to brush up on your color identification skills? This tests your ability to distinguish hues, saturation, complementary, analogous, triadic, and tetradic colors.

Pixactly

How good are you at measuring pixels by instinct? Pixactly helps you measure lengths and widths in pixels by prompting you to draw boxes of a specified height. Anyone who works with HTML and CSS will like this tool.

Hex Invaders

Do you know your hex codes? With all the online hex generator tools, many people neglect the learning their hex codes, but it’s still a good skill to have. Hex Invaders teaches you hex color codes by having you shoot the alien that corresponds to the color code shown on the screen.

Flexbox Froggy

Time to brush up on some CSS. With the justify-content property, you need to guide the frogs to their lily pads, all while learning more about CSS in real time. With twenty-four levels, you’ll come out of this with a full understanding of this CSS code.

Flexbox Defense

Still having trouble with flexboxes? Flexbox Defense is a tower defense game where you must position your towers using CSS. After playing Flexbox Froggy, reinforce your skills with this more difficult game.

Grid Garden

Here’s a relaxing game that will teach you how to use CSS Grid, specifically the grid-column-start property. Grow your own carrot garden, water plants, kill weeds, and learn new CSS tricks and tips in this unorthodox gardening game.

Flukeout

Ready to learn about CSS Selectors? Use the code window to select the correct objects and learn how to select them in all kinds of situations and unique placements. This one is great for people who are new to CSS.

Learning Design with Online Games

Whether you’re a brand-new designer/developer or just brushing up on what you’ve learned, online educational games are a great way to cement your skills. It’s always good to bring a little fun into your learning process. Let us know which game was your favorite!