Archive for month: April, 2019

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.