Post pobrano z: Telling the Story of Graphic Design

Let me just frame this for you: we’re going to take a piece of production UI from a Sketch file, break it down into pieces of information and then build it up into a story we tell our friends. Our friends might be hearing, or seeing, or touching the story so we are going to interpret and translate the same information for different people. We’re going to interpret the colors and the typography and even the sizes, and express them in different ways. And we really want everyone to pay attention. This story mustn’t be boring or frustrating; it’s got to be easy to follow, understand and remember. And it’s got to, got to, make sense, from beginning to end.

I’ve asked my colleague Katie to choose a component she has designed in Sketch. I’ll go through and mark it up (we mainly use SCSS, Twig and Craft but the templating language is not very important), then she will respond briefly. Hopefully I’ll get most of it right, and then one or two things wrong, so we can look at how things get lost during handoff.

In white label or framework type front-end, the focus is on building pieces that are as flexible and adaptable as possible, as content and style-agnostic as possible (within the scope of the product), because you simply will never know where the code is going and for what, ultimately it is being used. But recently I moved to a web design agency, which has a complete inversion of this focus. It is particular. It is bespoke. It’s all about really deeply engaging with the particular client you have and the particular clients they have, and designing something that suits them, as a tailor would.

Working so closely with a graphic designer like Katie, with highly finished pixel-spaced UI, instead of directly from wireframes or stories is an adjustment and an education, but there are still lots of things I can bring to the table. Chiefly: document design.

Document design, which admittedly is just the old semantic web with an accessibility hat on, is really looking at graphic design, engaging with it as a system of communication, and translating the underlying purpose of the colors/type/layout into an accessible, linearizable, and traversable DOM. It’s HTML, kids. It’s just HTML. You’d think we all knew it by now… but look around you. You’d be wrong!

Katie has slung me a Sketch file chock full of artboards, and she’s pretty great at writing out what she wants so I don’t have to think too hard:

First I look through the whole UI file and figure out what is actually a card on this site — it turns out there are six or seven components that use this paradigm. Let’s make some observations:

• A card is a block of meta data about a page on the site.
• It has an image/media and metadata — it’s a media object.
• It’s shown in a group of objects.
• That group is always typed (there’s no view where there are search results and news articles and classes are all mixed up).
• Each object has a single link to a page and no other actions.
• Each object has a call to action (Book, etc.).
• Each object may have times, categories, badges, and calls to action.
• Each object must have media, title, and link.

So a card is the major way my user is going to find their way around this site. They are going to be clicking through guided pathways where they get a set of cards they can choose from, based on top pages like „what’s on” or „classes.” They’re not getting options on this card. It’s not really an interactive element — it’s a guide, an index card, that sets her onto her path: in this case a purchase path where she books a ticket for a show at this arts centre.

Before going on, let me just frame this for you:

Imagine you were looking at a flyer for a show and discussing it on the phone. If you actually wanted to go to this show in real life. What would you do? You wouldn’t just read the flyer out, would you? That’s the text. And it might have all kinds of random stuff on it if you started literally at the top. You wouldn’t start with „Twentieth Century Fox” or „Buy Hot Dog Get Cola Free” or „Comedy Drama Musical Family Friendly.” (I would actually hang up on you if you did!) And you wouldn’t simply describe the color or fonts. That’s the CSS. You’d talk through the information on the flyer. You’d say, „It’s The Greatest Showman and it’s on Tuesday, starts at 7:30. It’s at the Odeon on Oxford Street by the tram.” Right?

This is the document. Keep that person on the phone in your mind.

Count, group, and name

So let’s say we’ll deliver a card as the inside of a list item. We want a group and that group should be countable. We’ve already named the page with an <h1> so we’ll introduce and describe the group with a heading, an <h2>. First we’ll name it, then we’ll deliver it, so someone using a screen reader can:

1. Get the list signaled in the headings overview.
2. Get a count up front of the number of items on a page.
3. Know they can skip to the next list item to get the next card.
4. Know they can skip the group at any point and go to the next page — the pagination is the very next element and it will be labelled as a landmark.

See the Pen
Cards delivered as a countable list with descriptive heading by limograf (@Sally_McGrath)
on CodePen.

Anchor

In this particular case, I’m gonna wrap this whole card in an anchor element (<a>). There’s only one link on the card and I want to front load that information so someone can click as soon as they know it’s the right card, instead of having to search forward for the action. A big clickable area is nice too, though of course that can be taken too far and make an interface a sort of booby trap! But these cards are not too enormous and I can see they have a nice gutter around them, so there’s a rest space that will reduce accidental clicking for people with more limited dexterity.

Title

Then we’ll jump down a heading level and mark up the name of each show as a heading, an <h3>. The designer has made this type the focus and we will too. Some people browse super fast by jumping to the next heading, then next heading, so I’m not going to put any important information before the heading — they’ll jump right over it. I will put the image there, though, as I know in this case, I can’t get meaningful image descriptions from the API so those images are hidden and have empty alt attributes. Now the user can guess (correctly in my case) that the developer is actually describing the content in some meaningful way and might flip back to headings overview (list headings level 3) and just get a list of the shows.

Now let’s deliver our metadata. Let’s list it:

• Badge
• Date/Time
• Categories

Badge

This seems to be something the venue adds to a card to highlight it. As a developer, I can’t immediately see why a user would look for this, but it’s emphasized strongly by the designer, so I’ll make sure it stays in. Katie has moved the badge up out of the flow, but I know that with a headings jump our user could miss it. So I’ll just put the wording directly after the title, I think. I’ll either put it first or last, so make it easier to account for in a non-visual browse and not be too crazy paving in a tabbing, visual browse.

<p class="c-card__badge"><abbr title="Harrow Arts Centre">HAC</abbr> Highlight.</p>

…But on second thought, I won’t put an <abbr> after all. It’s the brand color, so it’s really a statement of ownership by this venue, and we’ve already said HAC a million times by now, so the user knows where they are.

<p class="c-card__badge">HAC Highlight </p>

See the Pen
Badge by limograf (@Sally_McGrath)
on CodePen.

Date/Time

Now date and time. Katie is keying me in to this decision point by styling the dates in bold. Dates are important. I’m going to pop it in an <h4>, because I’m thinking it looks like someone might be quickly scanning a page of events looking for the matinee, for example, or looking for a news article published on a particular day. I don’t always put dates into headings, especially if there are millions on a page, but I do always make sure they’re in a <time> element with a complete value so the <time>Thu</time> or <time>Mon</time> Katie has specified is read out as comprehensible English words „Thursday” instead of garblage. I could also have used hidden completion or <abbr> with a title.

Categories/ Tags

Next come the categories, and I’m putting them after badge and date. This section is next in the visual order reading top-to-bottom, left-to-right, of course, but it also seems to be deprioritized: it’s been pushed down on the left and the type is smaller. This works for our linear storytelling. As a rule, we don’t want people to sit through repeated or more general content (cinema, cinema, cinema) to get to unique or more specific content (Monday, Tuesday, Wednesday). Remember, we are inside our card: we know it has already been sorted in a few general ways (news, show, class, etc), so it’s likely to have a lot of repeated pieces. We want to ensure that the user will go from specific to general if we can.

There is a primary category that is sorted first and then some other categories sometimes. I won’t deliver this as a countable list as there’s mostly just one category, and loads of lists of one item is not much use. But I will put a little tag beforehand because otherwise, it’s a slightly impenetrable announcement. MOVEMENT! SPOKEN WORD! (I mean, you can work it out retrospectively, but we always try to name things first and then show them, in linear order. This isn’t Memento.) I used to use title="" fairly heavily but I’ve gotten complaints about the tooltip so I route around. Note the use of colon or full stop to give us a „breath.” That’s a nice bit of polish.

<p class="c-card__tags h-text--label>
  <span class="h-accessibility">Categories: </span>
{% for category in categories.all() %}
  <span class="c-card__tag c-tag">{{category}}{% if not loop.last %} / {% endif %}</span>
{% endfor %}</p>

Also I’m hard-coding in my spaces to make sure the categories never run together into complete garblage even with text compression or spaceless rendering turned on somewhere down the pipeline. (This can happen with screen readers and spans and it’s rather alarming!)

There’s a piece of this design I will do in the CSS but haven’t really pulled into the document design: the color-coding on primary category. I am not describing the color to the reader as it seems arbitrary, not evocative. If there were some subtextual element to the color coding beyond tagging categories (if horticultural classes were green, say), then I might bring it through, but in this case it’s a non-verbal key to a category, so we don’t want it in our verbal key.

I’m sorting the primary category to the front of the category paragraph, but I’m not labeling it as primary. This is because there’s a sorting filter before this list that sorts on primary category, and it’s my surmise that it would be easier and less annoying to select a category from that dropdown than to read through each card saying Categories Primary Category Music Secondary Categories Dance. I could be wrong about that! Striking a balance between useful and too much labeling is sometimes a bit tricky. You have to consider the page context. We may be building components but our user is on a page.

See the Pen
Dummies in page context by limograf (@Sally_McGrath)
on CodePen.

Action

Last, the action. The direction to the user, to Book, or Learn More, or whatever it is, has been styled as a button. It’s not actually a button, it’s just a direction, so I’ll mark it up as a span in this case. I definitely want this to come last in the linear document. It’s a call to action and also a signal that we’ve reached the end of this card. The action is the exit point in both cases: if the user acts, we go to the target entry; if they do not, we go to the next card. We definitely never want any data to come after the action, as they might have left by then.

See the Pen
Card by limograf (@Sally_McGrath)
on CodePen.

My conclusion

This markup, which counts, groups, and names data, delivers linear and non-linear interactions. The page makes sense if you read it top to bottom, makes sense if you read parts of it out of context, and helps you jump around.

Katie, over to you…

What an ace article! Really interesting. (I particularly like that „Mon,” „Tue,” etc. on cards are read as „Monday,” „Tuesday”… smart!)

One thing that struck me is that using assistive tech means users get information served to them in a „set” order that we’ve decided. So, unless there’s a filter, someone browsing for dance events, for example, has to sit/tab through a title, badge, dates, and maybe several other categories to find out whether an event’s for them or not. Bit tiresome. But that’s not something you’ve got wrong — it’s just how the internet works. Something for me to think about in the future.

Most of our clients are arts and cultural venues that need to sell tickets for events so I design a lot of event cards. They’re one of the very first things I’ll work on when designing a site. (Before even settling on a type hierarchy for the rest of the site.)

Thinking visually, here’s how I’d describe the general conventions of an event card:

• It must look like a list – so people understand how to use it.
• It needs to provide enough information for folks to decide if they’re interested or not. (The minimum information is likely an image, title, date, and link.)
• It needs to include a clear call to action — usually a link to find out more information.
• It needs to be easily scannable, visually.

Making information visually scannable is a pretty straightforward case of ensuring every information type (e.g. image, title, date, category, link) is sitting in the same place on every card and follows a clear hierarchy.

I focus a lot on typography in my work anyway but clearly: titles are styled to be highly prominent; dates are styled the same as each other but are different from titles; categories look different again – so that folks can easily pick-out the information they’re interested in from simply scanning the page. I’m composing the card for the user, saying, „Hey, look here’s the event’s name, this is when it’s on — and here’s where you go to get your tickets!”

The type styles – and particularly the spacing between them – are doing a lot of work, so I will point out here that the spacings are not quite right in the code sample:

This is important. Users need to be able to scan information quickly as they aren’t all looking for the same thing in order to make the decision to go to an event. Too much or too little space between elements can be distracting.

Perfect!

Some people just want a general mooch at what’s coming up at their local venue. Others may have seen an advert for a specific show that tickles their fancy, and want to buy tickets. There are people who love music but don’t care for theatre who just want a list of gigs; nothing else. And some folks who feel like going out at the weekend but aren’t that fussed about what it is they go to. So, I design cards to be easy to scan — because most users aren’t at all reading from top to bottom.

Despite the conventions I just laid out, cards certainly don’t all look the same — or work in the same way — across projects.

There is always a tension in web design between making an interface familiar to the user and original to the client. Custom typefaces and color palettes do a lot here, but the other piece of it is through discovery.

I spend time reading-up about a client, including who their audience is by reading what they say on review sites and social media, as well as working directly with the client. Listening to people talk through how they work, what feedback they get from their audience/users often uncovers some interesting little nuggets which influence a design. Developers aren’t typically involved much in discovery, which is something I’d like to change, but for now, I need to make it super-clear to Sally what’s special about this event card for each new project. I write many, many (many) notes on Sketch files, but find they can tend to get lost, so sometimes we have a spreadsheet defining particular functionality.

See the Pen
Cards in page context, scraped from production by limograf (@Sally_McGrath)
on CodePen.

The post Telling the Story of Graphic Design appeared first on CSS-Tricks.

Post pobrano z: Telling the Story of Graphic Design

Let me just frame this for you: we’re going to take a piece of production UI from a Sketch file, break it down into pieces of information and then build it up into a story we tell our friends. Our friends might be hearing, or seeing, or touching the story so we are going to interpret and translate the same information for different people. We’re going to interpret the colors and the typography and even the sizes, and express them in different ways. And we really want everyone to pay attention. This story mustn’t be boring or frustrating; it’s got to be easy to follow, understand and remember. And it’s got to, got to, make sense, from beginning to end.

I’ve asked my colleague Katie to choose a component she has designed in Sketch. I’ll go through and mark it up (we mainly use SCSS, Twig and Craft but the templating language is not very important), then she will respond briefly. Hopefully I’ll get most of it right, and then one or two things wrong, so we can look at how things get lost during handoff.

In white label or framework type front-end, the focus is on building pieces that are as flexible and adaptable as possible, as content and style-agnostic as possible (within the scope of the product), because you simply will never know where the code is going and for what, ultimately it is being used. But recently I moved to a web design agency, which has a complete inversion of this focus. It is particular. It is bespoke. It’s all about really deeply engaging with the particular client you have and the particular clients they have, and designing something that suits them, as a tailor would.

Working so closely with a graphic designer like Katie, with highly finished pixel-spaced UI, instead of directly from wireframes or stories is an adjustment and an education, but there are still lots of things I can bring to the table. Chiefly: document design.

Document design, which admittedly is just the old semantic web with an accessibility hat on, is really looking at graphic design, engaging with it as a system of communication, and translating the underlying purpose of the colors/type/layout into an accessible, linearizable, and traversable DOM. It’s HTML, kids. It’s just HTML. You’d think we all knew it by now… but look around you. You’d be wrong!

Katie has slung me a Sketch file chock full of artboards, and she’s pretty great at writing out what she wants so I don’t have to think too hard:

First I look through the whole UI file and figure out what is actually a card on this site — it turns out there are six or seven components that use this paradigm. Let’s make some observations:

• A card is a block of meta data about a page on the site.
• It has an image/media and metadata — it’s a media object.
• It’s shown in a group of objects.
• That group is always typed (there’s no view where there are search results and news articles and classes are all mixed up).
• Each object has a single link to a page and no other actions.
• Each object has a call to action (Book, etc.).
• Each object may have times, categories, badges, and calls to action.
• Each object must have media, title, and link.

So a card is the major way my user is going to find their way around this site. They are going to be clicking through guided pathways where they get a set of cards they can choose from, based on top pages like „what’s on” or „classes.” They’re not getting options on this card. It’s not really an interactive element — it’s a guide, an index card, that sets her onto her path: in this case a purchase path where she books a ticket for a show at this arts centre.

Before going on, let me just frame this for you:

Imagine you were looking at a flyer for a show and discussing it on the phone. If you actually wanted to go to this show in real life. What would you do? You wouldn’t just read the flyer out, would you? That’s the text. And it might have all kinds of random stuff on it if you started literally at the top. You wouldn’t start with „Twentieth Century Fox” or „Buy Hot Dog Get Cola Free” or „Comedy Drama Musical Family Friendly.” (I would actually hang up on you if you did!) And you wouldn’t simply describe the color or fonts. That’s the CSS. You’d talk through the information on the flyer. You’d say, „It’s The Greatest Showman and it’s on Tuesday, starts at 7:30. It’s at the Odeon on Oxford Street by the tram.” Right?

This is the document. Keep that person on the phone in your mind.

Count, group, and name

So let’s say we’ll deliver a card as the inside of a list item. We want a group and that group should be countable. We’ve already named the page with an <h1> so we’ll introduce and describe the group with a heading, an <h2>. First we’ll name it, then we’ll deliver it, so someone using a screen reader can:

1. Get the list signaled in the headings overview.
2. Get a count up front of the number of items on a page.
3. Know they can skip to the next list item to get the next card.
4. Know they can skip the group at any point and go to the next page — the pagination is the very next element and it will be labelled as a landmark.

See the Pen
Cards delivered as a countable list with descriptive heading by limograf (@Sally_McGrath)
on CodePen.

Anchor

In this particular case, I’m gonna wrap this whole card in an anchor element (<a>). There’s only one link on the card and I want to front load that information so someone can click as soon as they know it’s the right card, instead of having to search forward for the action. A big clickable area is nice too, though of course that can be taken too far and make an interface a sort of booby trap! But these cards are not too enormous and I can see they have a nice gutter around them, so there’s a rest space that will reduce accidental clicking for people with more limited dexterity.

Title

Then we’ll jump down a heading level and mark up the name of each show as a heading, an <h3>. The designer has made this type the focus and we will too. Some people browse super fast by jumping to the next heading, then next heading, so I’m not going to put any important information before the heading — they’ll jump right over it. I will put the image there, though, as I know in this case, I can’t get meaningful image descriptions from the API so those images are hidden and have empty alt attributes. Now the user can guess (correctly in my case) that the developer is actually describing the content in some meaningful way and might flip back to headings overview (list headings level 3) and just get a list of the shows.

Now let’s deliver our metadata. Let’s list it:

• Badge
• Date/Time
• Categories

Badge

This seems to be something the venue adds to a card to highlight it. As a developer, I can’t immediately see why a user would look for this, but it’s emphasized strongly by the designer, so I’ll make sure it stays in. Katie has moved the badge up out of the flow, but I know that with a headings jump our user could miss it. So I’ll just put the wording directly after the title, I think. I’ll either put it first or last, so make it easier to account for in a non-visual browse and not be too crazy paving in a tabbing, visual browse.

<p class="c-card__badge"><abbr title="Harrow Arts Centre">HAC</abbr> Highlight.</p>

…But on second thought, I won’t put an <abbr> after all. It’s the brand color, so it’s really a statement of ownership by this venue, and we’ve already said HAC a million times by now, so the user knows where they are.

<p class="c-card__badge">HAC Highlight </p>

See the Pen
Badge by limograf (@Sally_McGrath)
on CodePen.

Date/Time

Now date and time. Katie is keying me in to this decision point by styling the dates in bold. Dates are important. I’m going to pop it in an <h4>, because I’m thinking it looks like someone might be quickly scanning a page of events looking for the matinee, for example, or looking for a news article published on a particular day. I don’t always put dates into headings, especially if there are millions on a page, but I do always make sure they’re in a <time> element with a complete value so the <time>Thu</time> or <time>Mon</time> Katie has specified is read out as comprehensible English words „Thursday” instead of garblage. I could also have used hidden completion or <abbr> with a title.

Categories/ Tags

Next come the categories, and I’m putting them after badge and date. This section is next in the visual order reading top-to-bottom, left-to-right, of course, but it also seems to be deprioritized: it’s been pushed down on the left and the type is smaller. This works for our linear storytelling. As a rule, we don’t want people to sit through repeated or more general content (cinema, cinema, cinema) to get to unique or more specific content (Monday, Tuesday, Wednesday). Remember, we are inside our card: we know it has already been sorted in a few general ways (news, show, class, etc), so it’s likely to have a lot of repeated pieces. We want to ensure that the user will go from specific to general if we can.

There is a primary category that is sorted first and then some other categories sometimes. I won’t deliver this as a countable list as there’s mostly just one category, and loads of lists of one item is not much use. But I will put a little tag beforehand because otherwise, it’s a slightly impenetrable announcement. MOVEMENT! SPOKEN WORD! (I mean, you can work it out retrospectively, but we always try to name things first and then show them, in linear order. This isn’t Memento.) I used to use title="" fairly heavily but I’ve gotten complaints about the tooltip so I route around. Note the use of colon or full stop to give us a „breath.” That’s a nice bit of polish.

<p class="c-card__tags h-text--label>
  <span class="h-accessibility">Categories: </span>
{% for category in categories.all() %}
  <span class="c-card__tag c-tag">{{category}}{% if not loop.last %} / {% endif %}</span>
{% endfor %}</p>

Also I’m hard-coding in my spaces to make sure the categories never run together into complete garblage even with text compression or spaceless rendering turned on somewhere down the pipeline. (This can happen with screen readers and spans and it’s rather alarming!)

There’s a piece of this design I will do in the CSS but haven’t really pulled into the document design: the color-coding on primary category. I am not describing the color to the reader as it seems arbitrary, not evocative. If there were some subtextual element to the color coding beyond tagging categories (if horticultural classes were green, say), then I might bring it through, but in this case it’s a non-verbal key to a category, so we don’t want it in our verbal key.

I’m sorting the primary category to the front of the category paragraph, but I’m not labeling it as primary. This is because there’s a sorting filter before this list that sorts on primary category, and it’s my surmise that it would be easier and less annoying to select a category from that dropdown than to read through each card saying Categories Primary Category Music Secondary Categories Dance. I could be wrong about that! Striking a balance between useful and too much labeling is sometimes a bit tricky. You have to consider the page context. We may be building components but our user is on a page.

See the Pen
Dummies in page context by limograf (@Sally_McGrath)
on CodePen.

Action

Last, the action. The direction to the user, to Book, or Learn More, or whatever it is, has been styled as a button. It’s not actually a button, it’s just a direction, so I’ll mark it up as a span in this case. I definitely want this to come last in the linear document. It’s a call to action and also a signal that we’ve reached the end of this card. The action is the exit point in both cases: if the user acts, we go to the target entry; if they do not, we go to the next card. We definitely never want any data to come after the action, as they might have left by then.

See the Pen
Card by limograf (@Sally_McGrath)
on CodePen.

My conclusion

This markup, which counts, groups, and names data, delivers linear and non-linear interactions. The page makes sense if you read it top to bottom, makes sense if you read parts of it out of context, and helps you jump around.

Katie, over to you…

What an ace article! Really interesting. (I particularly like that „Mon,” „Tue,” etc. on cards are read as „Monday,” „Tuesday”… smart!)

One thing that struck me is that using assistive tech means users get information served to them in a „set” order that we’ve decided. So, unless there’s a filter, someone browsing for dance events, for example, has to sit/tab through a title, badge, dates, and maybe several other categories to find out whether an event’s for them or not. Bit tiresome. But that’s not something you’ve got wrong — it’s just how the internet works. Something for me to think about in the future.

Most of our clients are arts and cultural venues that need to sell tickets for events so I design a lot of event cards. They’re one of the very first things I’ll work on when designing a site. (Before even settling on a type hierarchy for the rest of the site.)

Thinking visually, here’s how I’d describe the general conventions of an event card:

• It must look like a list – so people understand how to use it.
• It needs to provide enough information for folks to decide if they’re interested or not. (The minimum information is likely an image, title, date, and link.)
• It needs to include a clear call to action — usually a link to find out more information.
• It needs to be easily scannable, visually.

Making information visually scannable is a pretty straightforward case of ensuring every information type (e.g. image, title, date, category, link) is sitting in the same place on every card and follows a clear hierarchy.

I focus a lot on typography in my work anyway but clearly: titles are styled to be highly prominent; dates are styled the same as each other but are different from titles; categories look different again – so that folks can easily pick-out the information they’re interested in from simply scanning the page. I’m composing the card for the user, saying, „Hey, look here’s the event’s name, this is when it’s on — and here’s where you go to get your tickets!”

The type styles – and particularly the spacing between them – are doing a lot of work, so I will point out here that the spacings are not quite right in the code sample:

This is important. Users need to be able to scan information quickly as they aren’t all looking for the same thing in order to make the decision to go to an event. Too much or too little space between elements can be distracting.

Perfect!

Some people just want a general mooch at what’s coming up at their local venue. Others may have seen an advert for a specific show that tickles their fancy, and want to buy tickets. There are people who love music but don’t care for theatre who just want a list of gigs; nothing else. And some folks who feel like going out at the weekend but aren’t that fussed about what it is they go to. So, I design cards to be easy to scan — because most users aren’t at all reading from top to bottom.

Despite the conventions I just laid out, cards certainly don’t all look the same — or work in the same way — across projects.

There is always a tension in web design between making an interface familiar to the user and original to the client. Custom typefaces and color palettes do a lot here, but the other piece of it is through discovery.

I spend time reading-up about a client, including who their audience is by reading what they say on review sites and social media, as well as working directly with the client. Listening to people talk through how they work, what feedback they get from their audience/users often uncovers some interesting little nuggets which influence a design. Developers aren’t typically involved much in discovery, which is something I’d like to change, but for now, I need to make it super-clear to Sally what’s special about this event card for each new project. I write many, many (many) notes on Sketch files, but find they can tend to get lost, so sometimes we have a spreadsheet defining particular functionality.

See the Pen
Cards in page context, scraped from production by limograf (@Sally_McGrath)
on CodePen.

The post Telling the Story of Graphic Design appeared first on CSS-Tricks.

Post pobrano z: Datalist is for suggesting values without enforcing values

Have you ever had a form that needed to accept a short, arbitrary bit of text? Like a name or whatever. That’s exactly what <input type="text"> is for. There are lots of different input types (and modes!), and picking the right one is a great idea.

But this little story is about something else and applies to any of them.

What if the text needs to be arbitrary (like „What’s your favorite color?”) so people can type in whatever, but you also want to be helpful. Perhaps there are a handful of really popular answers. Wouldn’t it be nice if people could just select one? Not a <select>, but a hybrid between an input and a dropdown. Hold on though. Don’t make your own custom React element just yet.

That’s what <datalist> is for. I just used it successfully the other day so I figured I’d blog it because blogging is cool.

Here are the basics:

See the Pen
Basic datalist usage by Chris Coyier (@chriscoyier)
on CodePen.

The use case I was dealing with needed:

1. One <input type="text"> for a username
2. One <input type="text"> for a „flag” (an aribtrary string representing a permission)

I probably wouldn’t do a <datalist> for every username in a database. I don’t think there is a limit, but this is sitting in your HTML, so I’d say it works best at maybe 100 options or less.

But for that second one, we only had maybe 3-4 unique flags we were dealing with at the time, so a datalist for those made perfect sense. You can type in whatever you want, but this UI helps you select the most common choices. So dang useful. Maybe this could be useful for something like a gender input, where there is a list of options you can choose, but it doesn’t enforce you actually choose one of them.

Even lesser known than the fact that <datalist> exists? The fact that it works for all sorts of inputs besides just text, like date, range, and even color.

The post Datalist is for suggesting values without enforcing values appeared first on CSS-Tricks.