Original Source: https://www.smashingmagazine.com/2019/10/editorial-design-patterns-css-grid-subgrid-naming/

Editorial Design Patterns With CSS Grid And Named Columns

Editorial Design Patterns With CSS Grid And Named Columns

Rachel Andrew

2019-10-04T12:30:00+02:00
2019-10-04T12:35:51+00:00

Many websites, in particular those which display long-form content, have a fairly straightforward repeating pattern of components: a full-width area for images, a central content area, and perhaps a split view of two half-width blocks. These components repeat to display an article, images and other related content — with content editors selecting the right component as they create articles for publication.

In this article, I’m going to demonstrate an approach to this kind of editorial design, which builds on a few techniques some of which are discussed in the following articles:

“Breaking Out With CSS Grid Layout”
“Breaking Out With CSS Grid Explained”
“Naming Things In CSS Grid Layout”

In addition to this being a nice way to name sections of your layout, this technique exposes a whole bunch of interesting things about Grid Layout which you may find useful in creating your own layout patterns. It also demonstrates more of the promise of subgrid (a part of the upcoming Level 2 of the grid specification and being implemented in Firefox).

Naming Things In CSS Grid Layout

When using CSS Grid Layout, you can name lines and areas. Both of these things can make working with Grid — especially complex grids — more straightforward. Defining naming conventions for things in your layout can be useful when working with your team; it is much easier to understand where anything placed with grid-area: content will end up than having something placed from column-line: 3 / 9.

When using the grid-template-areas approach, you give the items that you want to place on the grid a name by using the grid-area property and then placing them around the grid. In the following example, the item with grid-area: content goes into the grid area defined by the grid-template-areas property:

See the Pen [Layout With Named Area](https://codepen.io/rachelandrew/pen/zYOQBba) by Rachel Andrew.

See the Pen Layout With Named Area by Rachel Andrew.

This works well for components where you have one item to go into one area; however, if you want to place multiple things into the content area (one below the other), using grid-area is the wrong approach. Instead, you might define names for the column lines and place the item from the start to end line.

See the Pen [Layout With Named Columns](https://codepen.io/rachelandrew/pen/xxKNONQ) by Rachel Andrew.

See the Pen Layout With Named Columns by Rachel Andrew.

This isn’t as neat, however, when using the grid-area approach we have to know both the start and end line when placing an item using grid-column or grid-row — or do we?

Take a look at this next CodePen example. My items are placed using a single name or ident by using the grid-column property, even though some of the grid areas being targeted cross a number of columns:

See the Pen [Layout with Named Columns](https://codepen.io/rachelandrew/pen/mdbYEod) by Rachel Andrew.

See the Pen Layout with Named Columns by Rachel Andrew.

My aim here is to abstract away the complexity of the grid setup when actually using the grid. I can put a lot of work into creating the initial grid, but then place things without thinking too much about it as I populate my pages. I also want to make sure that we can repeat the components as often as we need to as we build up the article. What I have in mind is a content creator using a CMS, and creating blocks of content using the different patterns whilst knowing that they will be placed correctly one below the other on the overall grid.

In order to understand how I got to this point requires an understanding of a few things about CSS Grid Layout as well as named lines and areas.

We Can Name Lines

As you’ve already seen in my second example above, we can name lines on the grid that can be pretty much anything we like — other than the word span. The name is an ident rather than a string which is why it is not quoted.

However, you will see many examples where the naming conventions name-start and name-end are used that append -start onto the name of the start line and -end on the name of the end line. This is not purely convention and for the technique I am going to show you why we need to name our lines this way. So you should pick a name for the area you are describing, and then add the -start and -end suffixes — which need to match, of course!

We name our lines inside square brackets. Lines can (and often need to) have multiple names. In this case, space separates the names. When placing the items using line-based positioning, you can pick any name for the line to do the placement.

With our named lines in place, we could place our items using grid-column by specifying the start and end line name. This pattern is just the same as using line numbers, so the name before the slash is the start line and the name after is the end line.

See the Pen [Example using start and end lines](https://codepen.io/rachelandrew/pen/VwZOPgO) by Rachel Andrew.

See the Pen Example using start and end lines by Rachel Andrew.

This places the items but isn’t the neat single name per item that I used in the example. However, we now have everything in place due to the special way that Grid handles named areas and lines.

Line Names Give Us A Named Area

Assuming you have named your lines with -start and -end as I have, Grid will give you a named area of the main name you used. Therefore, in my case, I have areas named content, start-half, end-half, full and center. Each of these areas is a single row (as I don’t have named rows), however, it will span the column tracks from the -start to the -end line.

Named Areas Give Us A Named Line Of The Main Name Used

If we want to be able to place our items as if we have a column name, we also need to make use of the fact that when we create a grid area, we get a line name of the main name used; that is, the main name being the name with -start and -end removed. This line name resolves to the start or end of the area depending on whether we are targeting grid-column-start or grid-column-end.

So, we have an area named content, because we have column lines named content-start and content-end. The area named content also gives us the ability to use grid-column-start: content which will resolve to the start line of that content area, while grid-column-end: content will resolve to the end line of the content area.

This, therefore, means that we can place an item into the content area by using the following:

.content {
grid-column: content / content;
}

Next, we can now tidy up this technique further due to the fact that if you use a named line for grid-column-start and omit the end line (rather than spanning one track as would be the case if you used line numbers), grid copies the name over to the end line. Therefore, grid-column: content is exactly the same as grid-column: content / content;

This is then all we need to be able to place items using grid-column with a simple, single name. This behavior is all exactly as specified and not some kind of “hack”. It demonstrates the depth of thinking that went into the creation of the Grid Layout specification, and the amount of careful work that has gone into making it so straightforward to lay items out in our designs.

Giving This Technique Superpowers With Subgrid

I think this technique is a nice one that enables a very straightforward way of declaring where elements should be placed on the grid. However, if we add subgrid support to the mix, it becomes very powerful indeed.

Currently, subgrid is being implemented in Firefox, and so these next examples require Firefox Nightly to run. You can download Nightly here.

The subgrid value of grid-template-columns and grid-template-rows means that sizing created on a parent grid can be opted into by an item which is a child of the grid (assuming it is also using grid layout) by having display: grid applied.

Note: You can read more about the features of subgrid in my articles here on Smashing Magazine “CSS Grid Level 2: Here Comes Subgrid” and “Digging Into The Display Property: Grids All The Way Down”.

Line Names From The Parent Are Passed Into Subgrids

In addition to the track sizing information being passed into the child grid, any line names set on the parent will be passed in. This means that we can use our “column names” within subgridded components, making this solution very useful in a world where subgrid exists. An item placed in content — even if nested down inside subgrids — will line up with one placed as a direct child of the main grid.

In this next example, I have nested two elements directly inside the div with a class of full-2. I have also placed a ul inside .content. If we look at the items inside full-2, in order to place these on the parent grid, we need to make the selector full-2 a grid with display: grid then use the grid-template-columns property with a value of subgrid.

This causes the grid on .full-2 to use the tracks defined on the parent grid, and have access to the named lines defined there. As this is a full-width item, this really will behave just like the parent grid in terms of placing our items. We can then use any of the names we defined for the different columns to place the items. In this case, I have set both child elements to grid-column: center and they display one after the other in that center area.

.full-2 {
grid-row: 4;
grid-column: full;
display: grid;
row-gap: 10px;
grid-template-columns: subgrid;
}

.full-2 > div {
background-color: rgb(124,222,220);
grid-column: center;
}

The nested elements line up with the grid on the parent (Large preview)

If we take a look at our nested ul inside .content, we will need to create a subgrid on the selector .content just as with the last example; when we do this, the ul falls into the first track of the subgrid. If we want to lay out the listen items on the subgrid, we need to do two things: cause the ul to take up the same area as its parent by placing it with grid-column: content, and then making it a grid which is a subgrid.

Having done this the list items will lay out using auto-placement into the column tracks of the subgrid:

.content {
grid-row: 1;
grid-column: content;
display: grid;
grid-template-columns: subgrid;
}

.content ul {
grid-column: content;
display: grid;
row-gap: 10px;
grid-template-columns: subgrid;
}

With auto-placement the items fall into the tracks of the parent (Large preview)

Once you have your grid, you can use the names from the parent in exactly the same way as before.

.content li:nth-child(1) {
grid-column: center;
}

.content li:nth-child(2) {
grid-column: start-half;
}

.content li:nth-child(3) {
grid-column: end-half;
}

.content li:nth-child(4) {
grid-column: content;
}

The completed subgrid layout (Large preview)

If you have Firefox Nightly, you can see the full demo in this CodePen example:

See the Pen [Naming Column and Subgrid](https://codepen.io/rachelandrew/pen/OJLYRRb) by Rachel Andrew.

See the Pen Naming Column and Subgrid by Rachel Andrew.

You can keep “nesting’ subgrids into your markup structure like this, and each time the line names will be passed through. This is a feature that I think will be particularly useful.

When you create a subgrid, the line numbers correspond to the lines of the subgrid and not the parent grid. Therefore, if you do want to ensure that elements in the subgrid line up with the parent grid, then using line names or named areas (as shown in this example) will make that straightforward and logical.

Wrapping Up

You now know how to use this technique for your main grid, and hopefully, it won’t take too long before we start seeing support for subgrid in all browsers. It’ll enable techniques such as this one and make it incredibly powerful for us to use.

(il)

Original Source: http://feedproxy.google.com/~r/CreativeBloq/~3/Tg4dQJayu-A/10-steps-engaging-user-experience-3156607

Gathering UX tips from the experts could be the key to the success of your website. Over the last 20 years, I’ve worked with some great brands across multi-discipline experiences. When doing this, you tend to pick up a heap of knowledge along the way that you use on a daily basis without even thinking about. The sort of things that become ingrained. Whether you are new to user experience and UI design or an all-rounded design veteran, I hope this is a small insight into my top 20 pro tips for creating the best possible experiences for your users.

If you're designing all-new UX, you'll want to see how it fares with the user. Check out Creative Bloq's handy guide to user testing for all you'll need to know.

01. Know your users

Get to know your users, listen to them and mix up the way you test

As a designer, it’s really important to design how your users are likely to interact with a website, product or mobile application when exploring it. Don’t just use analytics and stats; get into the shoes of your users. Dig a little bit deeper. After understanding users, you will be able to make informed decisions in your design.

02. Write user profiles and user stories

When creating user profiles, ensure you actually interview a person. Time and time again I see a lot of profiling that is made up and not based on any form of research. When writing user stories, having an actual person in mind will help you to funnel those users to making the decisions you want. Never assume as a designer. It’s good practice to get into the routine of writing user stories. 

A user story is a high-level definition of a requirement, containing just enough information so that you can implement it within your UX. This not only helps to focus the hierarchy of what you are trying to get people to do, it also helps you to clearly create user goals. Point the user stories back to your user profiles within your interaction design. Ultimately, this will help with conversion and also create a testing hierarchy to work from.

03. Listen to your users

Listening is one of the most important aspects of good UX design. Always take time to listen to your customers and most importantly when collaborating with conversion rate specialists. As a UX designer it’s your responsibility to bring together all of the requirements from a wide range of stakeholders.

That's why the greatest digital projects are often those where there is a perfect equilibrium between the client's objectives and the user's needs. Sit on that fence, and balance well.

04. Get out of the lab environment when testing mobile

I’ve thought this for a long time about user testing. Why would you test a user in a lab when the majority of their time using a mobile is on the move? You can gain excellent insight by changing the way you test and where you test.

05. Use effective tools for collaborative teams

Consider tools, logic and animation

If you are an independent business you will no doubt find yourself collaborating with a number of specialist people on a project. Setting up clear communication channels is a must. I spend more time planning, collaborating and organising teams to deliver great products and design. I tend to use software such as Jira or Confluence for the more heavyweight projects and Trello or Asana for smaller projects linked with Slack. These are fantastic tools to make your life easier when delivering projects. It will also save your inbox and the off chance of losing an important email.

06. Design with UX in mind

It’s good to seek inspiration. There are a lot of great resources online and huge communities of users that share their work, research and results, so seek these out. I like to find UX inspiration on Instagram and sites like awwwards.com and Behance.

07. Embrace the white space

I always use consistent typography and white space. Your clients will expect you to fill the space or certainly ‘make the logo bigger’ but white space is so important, especially designing for mobile. Ensure you follow some simple grid systems. I do this all the time with layouts. It not only makes the design process simpler but also consistent. Have fun with white space and don’t be afraid to play around with the size of typographic headers and also the fonts you use. Think of a website like a road trip: move users seamlessly from one section to the next by understanding the users’ personas, goals and needs.

08. Never put emotion before logic

Be careful not to distract the user

Users often perceive visually pleasing designs as being easy to use. However, there is a fine line between distracting a user from their task and enforcing branding/marketing. Users are more likely to notice items near the top of the page, in order of their importance.

09. Include animation

Splash screens and simple loading animations create brand intrigue. When onboarding a user for the first time, go the extra mile with simple animations, top tips or even introduce your app with some brand animations. Allow the user to skip or ‘don’t show’ if they are returning but don’t overload your animations. More than three seconds loading time results in around a 55 per cent bounce rate. Give users feedback if their waiting time is more than one second.

10. Reduce the need for carousels

Okay, I’ll raise my hand and admit using a carousel in a recent project but it was to explain a customer’s process and it wasn’t just the latest promo marketing had asked me to add into a home page. Stats do indicate that most users stop viewing carousel content after three or four slides. Don’t overload a carousel with more than four slides or even better, get into the habit of not using them at all.

11. Focus on details

Think about focusing on the other tiny details, as it will take your user experience to the next level. When was the last time you designed an interesting 404 page? Here are some great examples of how to design a 404 error page – and how not to.

12. Concentrate on content

Content is king

Copy and content rule when it comes to your interface. Make good use of headings, sub-headings and copy breaks. Create smaller paragraphs to help viewers scan your web pages quickly to make your content more user-friendly. I like to make sure copy isn’t too long. Be clear and concise with what you are saying. Users will scroll down the web page as long as it is clear that relevant information is below the fold. However, don’t make the pages too long. It’s all in the balance.

13. Design with content and not Latin text

I see this all the time when designers don’t work with the content. It does help customers ‘fill in the boxes’ but UX and UI design should never be about this. When I design I aim to write the content or collaborate with a copywriter. It gives a customer more context with your wireframes and early design stages. Even if it’s first draft content, it still enables you to make more informed decisions on how the content people are engaging with will be presented.

14. Have a conversation with your site’s users

Make online experiences conversational

Well not literally but metaphorically. Make online experiences conversational. Content can be so much more appealing when your users connect. Don’t leave users in the dark; offer simple guidance (I don’t mean waffle) about what they need to do. It makes it more engaging. Brands like Innocent Drinks are a great example of how to create good conversation with brand experience.

15. Know that less is more

Paul Rand, American art director and graphic designer born in 1914, once said: “Good design doesn’t date, bad design does”. We tend to see a lot of design trends and styles that come and go, not just in terms of UI and UX but across design in general. Find your own design style. Work hard at it, create rules, follow design practice and question why. All great design always has one thing in common and that is simplicity. So strive for simplicity and clarity in your design to ensure it is received by the audience in a single glance or interaction. Minimalist and simple designs are easy to understand and are more appreciated by your audience.

16. Learn Hick’s law

If you don’t know about Hick’s law, do some research into it, as it will change the way you approach user interface design. Hick’s law – also known as the Hick–Hyman law – takes its moniker from the British and American psychologists William Edmund Hick and Ray Hyman and establishes the time it takes for a person to make a decision based on the possible choices available. 

Hick’s law assesses the information capacity in choice reaction experiments. The amount of time it takes in order to process a certain amount of bits in the Hick–Hyman law is known as the rate of gain of information. So in essence, keep those options to a minimum. Apply this practical advice to your designs. Remove unessential noise so users have a clear journey of interaction. 

You’ve got to find the balance between creating an engaging brand experience that converts users and designing something that looks like it was straight out of the 1990s. Speed things up by reducing the chance users will get distracted and leave. Research more into Hick’s law as it no doubt will help with your end product; it certainly has helped me.

17. Never interrupt users for no reason

Don’t get me started on chatbots or instant messages. Although there are pros and cons about using chatbots, interrupting a user as they start their problem-solving journey is detrimental to their experience. For example, opening up a dialogue box without the user having done anything is a bad idea and just annoying. Many sites bombard visitors with ‘How can I help?’ or ‘I’m a chatbot… let’s get started’. A dialogue should always open on an interaction and never be intrusive.

18. Avoid 'Get Started' as a call to action

Avoid ‘Get Started’ as a call to action This is one of my pet hates. I see it a lot. In fact avoid internalised language across any call to actions but especially ‘Get Started’. Your customer may call it one thing but your user might not understand it. Language is key, so ensure it’s simple and direct. Take care to never use ambiguous language.

19. Be proactive when it comes to responsive design

Design with accessibility and responsiveness in mind

I always start with designing for mobile and then work on mobile and desktop simultaneously. There are more approaches than ‘just stacking the content’ for mobile. As a UI designer I’ve learnt to effectively design responsive user interfaces that make use of flexible layouts, images and style sheets. Having a good relationship with your coder is a must if you’re not building the site or app. 

20. Make your designs accessible

I had an experience a few years back working with a client that got extremely frustrated during the design stage. There was a huge problem trying to get colours signed off. What I hadn’t ascertained was that the customer was in fact slightly colour blind. Colour blindness (colour vision deficiency) affects approximately one in 12 men and one in 200 women in the world. In Britain, this means that there are approximately 3 million colour blind people (about 4.5 per cent of the entire population), most of whom are male. 

I highly recommend getting hold of some sim specs during your testing process. It will take your user testing to a new level. Convert your designs to greyscale to ensure all users have a unified experience. Avoid the use of blue for any text on websites other than links. Be aware of the contrast on mobile websites as well. Reserve one colour for CTAs and make sure it contrasts with the rest of the page. Cold and dark colours stay in the background and warm bright colours like orange come forward. If your client’s brand has similar colours in tone, recommend a new contrast colour. You might find conversions go up. 

Check out our guide to inclusive web design.

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

Related articles:

The best new UX books right now7 golden rules of UXHow to use colour to shape UX

Original Source: https://www.hongkiat.com/blog/100-absolutely-beautiful-nature-wallpapers-for-your-desktop/

Huge collection of high-quality and beautiful nature wallpapers.

The post 50 Beautiful Nature Wallpapers For Your Desktop appeared first on Hongkiat.

Visit hongkiat.com for full content.

Original Source: https://www.sitepoint.com/svelte-news-app-build/?utm_source=rss

Svelte is a new JavaScript UI library that’s similar in many ways to modern UI libraries like React. One important difference is that it doesn’t use the concept of a virtual DOM.

In this tutorial, we’ll be introducing Svelte by building a news application inspired by the Daily Planet, a fictional newspaper from the Superman world.

About Svelte

Svelte makes use of a new approach to building users interfaces. Instead of doing the necessary work in the browser, Svelte shifts that work to a compile-time phase that happens on the development machine when you’re building your app.

In a nutshell, this is how Svelte works (as stated in the official blog):

Svelte runs at build time, converting your components into highly efficient imperative code that surgically updates the DOM. As a result, you’re able to write ambitious applications with excellent performance characteristics.

Svelte is faster than the most powerful frameworks (React, Vue and Angular) because it doesn’t use a virtual DOM and surgically updates only the parts that change.

We’ll be learning about the basic concepts like Svelte components and how to fetch and iterate over arrays of data. We’ll also learn how to initialize a Svelte project, run a local development server and build the final bundle.

Prerequisites

You need to have a few prerequisites, so you can follow this tutorial comfortably, such as:

Familiarity with HTML, CSS, and JavaScript (ES6+),
Node.js and npm installed on your development machine.

Node.js can be easily installed from the official website or you can also use NVM for easily installing and managing multiple versions of Node in your system.

We’ll be using a JSON API as a source of the news for our app, so you need to get an API key by simply creating an account for free and taking note of your API key.

Getting Started

Now, let’s start building our Daily Planet news application by using the degit tool for generating Svelte projects.

You can either install degit globally on your system or use the npx tool to execute it from npm. Open a new terminal and run the following command:

npx degit sveltejs/template dailyplanetnews

Next, navigate inside your project’s folder and run the development server using the following commands:

cd dailyplanetnews
npm run dev

Your dev server will be listening from the http://localhost:5000 address. If you do any changes, they’ll be rebuilt and live-reloaded into your running app.

Open the main.js file of your project, and you should find the following code:

import App from ‘./App.svelte’;

const app = new App({
target: document.body,
props: {
name: ‘world’
}
});

export default app;

This is where the Svelte app is bootstrapped by creating and exporting an instance of the root component, conventionally called App. The component takes an object with a target and props attributes.

The target contains the DOM element where the component will be mounted, and props contains the properties that we want to pass to the App component. In this case, it’s just a name with the world value.

Open the App.svelte file, and you should find the following code:

<script>
export let name;
</script>

<style>
h1 {
color: purple;
}
</style>

<h1>Hello {name}!</h1>

This is the root component of our application. All the other components will be children of App.

Components in Svelte use the .svelte extension for source files, which contain all the JavaScript, styles and markup for a component.

The export let name; syntax creates a component prop called name. We use variable interpolation—{…}—to display the value passed via the name prop.

You can simply use plain old JavaScript, CSS, and HTML that you are familiar with to create Svelte components. Svelte also adds some template syntax to HTML for variable interpolation and looping through lists of data, etc.

Since this is a small app, we can simply implement the required functionality in the App component.

In the <script> tag, import the onMount() method from “svelte” and define the API_KEY, articles, and URL variables which will hold the news API key, the fetched news articles and the endpoint that provides data:

<script>
export let name;

import { onMount } from “svelte”;

const API_KEY = “<YOUR_API_KEY_HERE>”;
const URL = `https://newsapi.org/v2/everything?q=comics&sortBy=publishedAt&apiKey=${API_KEY}`;
let articles = [];

</script>

onMount is a lifecycle method. Here’s what the official tutorial says about that:

Every component has a lifecycle that starts when it is created and ends when it is destroyed. There are a handful of functions that allow you to run code at key moments during that lifecycle. The one you’ll use most frequently is onMount, which runs after the component is first rendered to the DOM.

Next, let’s use the fetch API to fetch data from the news endpoint and store the articles in the articles variable when the component is mounted in the DOM:

<script>
// […]

onMount(async function() {
const response = await fetch(URL);
const json = await response.json();
articles = json[“articles”];
});
</script>

Since the fetch() method returns a JavaScript Promise, we can use the async/await syntax to make the code look synchronous and eliminate callbacks.

The post How to Build a News App with Svelte appeared first on SitePoint.