Empathy for internal users: Build and train for real content admins

- [Lily] Hi everybody.

- [Audience] Hello.

- [Lily] Thanks for coming to
hear some more about empathy.

I'm so excited that we're
speaking right after Fatima,

because that was such an
amazing sort of primer

to getting in other people's worlds

and that's exactly what
we're here to talk about.

And so, really quickly,
to get in your world,

can everyone, by show of
hands, tell me what you do?

Are you a developer, raise your hand.

Okay.

Do you work in Drupal but
more in the periphery?

Are you a project manager,
designer, business development?

Okay.

And then, are you a little
further on the periphery?

Maybe you're a content
admin, maybe your company's

considering building a site using Drupal.

Okay, good mix, sounds good.

So this talk is really empathy lessons

from the center and the periphery.

Nick is a developer,

he's going to be talking
primarily to developers,

but if you're not a developer,

take notes for the developers
that you work with.

Really good tools that your
agency or company can be using,

and I, I guess we can go to
the next slide, introducing us.

Oh, there we go.

I'm an account manager and at our agency,

that's sort of, it's between the roles

of client coordination and
more of a project manager role,

so the second half of the presentation

will be a little wider of an audience.

If you're not directly
involved in training,

same lesson to the
non-developers at the beginning

take notes for the people
around you who are.

And so, with that, I'm gonna pass it over

to Nick for the first half.

- [Nick] All right, cool.

- [Lily] And get out of your way.

(Laughing)

- [Nick] Alright, so yeah,
thanks for coming everybody.

It's awesome to see you all here.

Like Lily mentioned, I am
kind of by trade a developer.

I am in the weeds less,

I manage our development
team at Elevated Third,

but I've been working in the Drupal phase

for about ten years now, so,

definitely been doing it a while.

And then, I think just to
lay a little more groundwork

from what Lily talked
about, why are we here?

And I think this is sort
of our thesis statement

I guess, for our talk,
so, we truly believe that

when you're building a
complex digital platform,

like the admin experience and the training

are both really crucial
to setting that site off

on a path to success.

And I think for me, I
really connected with this

personally a lot in the past few years.

I've gotten involved in an organizer role

with our camp in Denver,
Drupal Camp Colorado,

and have kind of made a conscious effort

to separate myself from the
development of this site

to really get a better perspective.

And I have been the content
admin in that situation,

and I think that's really
opened my eyes a lot

to the pains of a site that

is maybe not well-built.

Or even just the small
things that you can tweak

that can cause you a lot of problems

that could be pretty easily
avoided with some simple work.

So like Lily said, I'm gonna talk a bit

about the build side.

Obviously, this is just
a 30 minute session,

so it'll be pretty high level.

Like I won't get into the weeds,

just kind of some general recommendations

that we found worked pretty well.

In building, planning,
building, contrib stuff

you can look at, maybe a
little bit of custom stuff.

We'll hang out afterwards.

I'll be here through the day today

and some tomorrow morning
so I'm happy to talk

about this stuff in more detail

for anybody who's interested.

So the first part of
the build that I think

maybe it gets skipped more often

than it should is planning.

So the key here is you want to

plan and build for real people.

Using the word empathy in the
title was very intentional

in the sense that I think that's what

we really try to encourage in this process

and would encourage
everyone else in the room

to consider in the
process is be empathetic.

Think about the people using the site,

from the admin perspective
on the front end, everybody.

And take a few minutes
as a developer especially

to really put yourself
in the shoes of someone

who's interacting with
your site day to day

and think about the little details.

Like if you can't select
a target for a link

that you're adding in the WYSIWYG;

what kind of chaos does that
cause for your marketing team

when they realize that links
can only open in the same page

and they're trying to link off-site.

So I guess just a real quick overview

of how we approach this.

We adopted a doc that Palantir posted

in a blog post years ago
that I imagine a few people

in this room have seen.

We call it the build spec I can't remember

exactly what they called it
in their original blog post

but it's basically like a
big Google sheets document

with multiple tabs where we define

what are our content types,

what are our paragraph
types, media entities.

Kind of like all of the foundational

architecture of the site.

And I think the actual
format is less important

than the fact that we're
fleshing this stuff out

in a much faster format than
actually building fields

in Drupal and exporting configuration

and importing configuration
on the dev environment.

Where I think a lot of
things with just like

naming conventions and
stuff become really obvious

at this point and you can catch those

in a situation where it's a lot easier

to maybe fix some obvious issues

than when you're actually changing stuff

in a live Drupal site.

So the second piece is actually
building the site, right?

There's three areas here that

I wanna focus on pretty briefly,

out of the box tools,
the contrib ecosystem,

and then custom and
site-specific improvements.

And we'll just talk through
a few basic concepts

and high-level ideas here.

And like I said, we won't
get super deep into it

but I'm more than happy to talk
about implementation details

or any questions you all have afterwards.

So, first area, out of the box tools.

There's three of these
that we'll run through.

The first is fields.

If you've worked with
Drupal in any capacity

you're probably pretty
familiar with fields.

They're everywhere,

it's like the foundation
building blocks of Drupal

and I think there's a few
things to keep in mind

even when you're just
putting fields together.

I think those three words on the screen

are where I really try to keep my head,

which is you want
everything about your fields

to be simple, clear, and focused.

You wanna name them for real people

so kind of get your head out
of the developer space I guess

when you're naming these and think about

what the fields actually do,
who's interacting with them,

what kind of content are they accepting,

what are they outputting on
the front end of the site.

Write help text that's actually helpful

or help text that exists at all.

I think this is something
that is easy to skip

'cause it's not required in
the field creation process

and nobody necessarily
misses it if it's not there.

But I think when good help text is there

that can be something really impactful

for people interacting with those fields

on the back end of your site.

Field requirements,
this is another one that

speaking from the developer perspective

these things make it
kind of a pain sometimes

to test content 'cause
you just want to blast

through your content
creation form really quickly

and not take the time because
you just wanna sort of test

the very specific thing
and field requirements

don't always allow you to do that.

But, I think sort of making
an intentional decision

to do that early really forces you to do

what I mentioned earlier and put yourself

in the shoes of someone
who's actually interacting

with this content on the back end.

And then finally, this is
one that really came to me

acting as a content admin,

that character limits and field sizes

should make sense in the editor's context.

If you want a seven word headline,

don't give them a long text
field with a WYSIWIG on it.

I think that's the type of thing,

especially for people who
maybe aren't as familiar

with CMS conventions and how Drupal works,

I think that can really throw you off.

So, the second area, out
of the box references,

again super prominent in
the Drupal space I'm sure.

I would guess that maybe
everyone in this room

has kinda heard a little bit about 'em.

There's a lot that they can do do

and I think there's
kind of three big things

to think about adding reference fields.

Limit them thoughtfully.

If you want to reference a blog post,

don't open that reference field up

to everything on the site.

Maybe take that a step further with views,

and that's one thing that's
kind of hiding under the hood

I guess you could say
with reference fields,

is you can build custom lists of content

that you can reference
from those using views.

So to continue with the blog example

maybe you only want to allow them

to reference specific categories of posts

or something like that.

I think that's quick, easy payoff.

And then finally the
right widget for the job.

Auto complete fields are not always

the most friendly for content admins

if you don't know the name of the content

that you're trying to reference.

So I think just think about
it as a multi-select write.

Does a select make more sense,

do I want to put chosen on top of that.

You can kind of see in
the screen shot there

and give them just a little bit more

to make that easier to select.

And then permissions.

Again, not only for security,

I think these are a great opportunity

to really tune up user roles

and if a user doesn't need
access to configuration,

don't give them access to configuration.

Which is obviously great for security,

but also great in not overwhelming people

who are interacting with the site

and maybe spending time browsing
through a bunch of stuff

that is totally irrelevant to tasks

that you can accomplish on the site.

Part two, the contrib ecosystem.

There is a ton of great stuff out there.

I'm sure there's a ton of great stuff

I've never even heard
of so I'd love to hear

everybody's ideas if there's
stuff I don't mention here

that works well for anyone in the room.

I picked my favorite 10 and then found

that it took way too long
to talk through my top 10

so I'll just talk real briefly
about five that I really like

then I have an honorable mention slide.

And we'll post our slides
afterwards so everyone

can check those out in a
little more detail if you want.

First one is field group.

This one's been around
forever to the point where

I kind of forgot it was a contrib module

when I was initially doing
the research for this.

I think the point here is just to take

the field naming stuff a step further.

When you have big, complicated
structured content types

like Drupal is good at creating,

field group does a really good job

of breaking that stuff down
in a way that can make it

just a lot more accessible for

content administrators to interact with.

And then media.

Again, kind of on the fence about this one

'cause media is in core
now, but it's great.

And I think it really adds a lot to

the media management experience
and Drupal in general.

This was obviously a huge, huge pain point

for Drupal for a really long time.

One-off file upload fields are not as nice

as having a single collected media library

that you can interact with
as a content administrator.

Entity browser, again I think
a fairly new one in the group.

Entity browser is great
because it lets you do exactly

what the title says: create
custom entity browsers.

You can see the example here is for videos

so it lets you do things like
you can add multiple tabs

to it where you can view videos
or you can add a new one.

It's all powered by views
so everything down there

is all just like a searchable,
totally customizable view

that you can use to allow
the person interacting

with this field to know
exactly what they're getting at

and then to take the
organization provided by media

a step further so you can
actually filter and search

by the terms or whatever
you might be adding

to your media entities.

Sorry about all the Drupalisms;

Lily's totally going to call me that out,

call me out on that in a minute.

- [Lily] Spoiler alert.

- [Nick] Yeah.

Focal point, this is a great one that

integrates really well with
image styles in Drupal.

It's not quite as
customizable as something like

manual crop was in Drupal

a very specific part of every
single image you upload.

But I think it's nice in the
sense that it lets you choose,

like it says, a focal point on the image

it's kind of like what that
cross is defining up there.

And then any place that
that image is used,

you can put this in an
image style and then Drupal

will sort of automatically do its best

to crop around that point.

I think it works great for high volume.

It's not always gonna make
art directors totally happy,

but I think it's a really
good starting point

for general content
administrators in Drupal.

And then the last one that I'll talk about

in a bit of detail is paragraphs browser.

Obviously if you don't use paragraphs

this won't do much for you.

At Elevated Third we use it a ton

and this basically does

the same thing that entity browser does

except for paragraphs.

It'll let you filter and search

by your different paragraph types.

And then what I really
like about it that I think

helps us connect to
content administrators is

it lets us provide a preview
of what the component

you're adding to the site is
actually going to look like

on the front end, or hopefully look like

once you've created it.

So it gives people an idea of what type

of assets they'll need
when they're creating that.

So definitely check that one out.

And we actually maintain
that as a company too

so if you use it already
and have suggestions

I would absolutely love
to hear them afterwards.

And then five honorable mentions.

I'm running a little short on time

and I don't want to
take too much of Lily's

so I won't talk too much about these ones

but I think these are all great.

If you see one up here
you're curious about

let's talk afterwards and I'd be happy

to give you a little more information.

And yeah, again, we'll post
the link to the slide deck

so don't feel like you need to furiously

write them all down or
you'll never get it.

And then finally just real briefly,

I think custom and
site-specific improvements

get overlooked a lot on the admin side.

At the end of the day an
admin theme is a theme;

you can customize it, modify it

the same way you would any other part

of the front end ThemeWare

that you might think about on Drupal.

I think the big thing here
is just really considering

the payoff that you get
from the customizations

'cause obviously not
every client is gonna want

to put money into this,

or if there's no immediate
return it might not feel right.

So I think the big thing is
just focus the custom time

on what provides the most value
and the best way to do that

is talk to your admins.

Send out user surveys or
maybe do some user tests

on your administrative side of it.

It's pretty cool what kind
of stuff you will learn.

We'll do user testing on
the admin side of our sites

with our current clients
to get feedback about

what we can change moving forward

and how we can do a better
job with that stuff.

The screenshot up here
is just how we customize

the paragraph's UI to make
it a little more approachable

and sort of collapse
things down a little bit.

We actually swapped out
the dragable library too

to make it a little smoother

when you're actually
interacting with them.

And then the second part of
that is views one more time.

Views is great for administrative
stuff on the backend.

In Drupal 8 basically everything
is already built into views

so customize things that
you get out of the box,

take the opportunity to build,

put your more focused
content overview page

if you have really specific
types of structured content

it's a great opportunity
to give your administrators

a way to maybe filter or view information

about that content that
wouldn't make sense

in an overall content overview screen.

And then, real quick honorable mention for

content moderation dashboards
and custom reports.

Very powerful, I won't
go into too much detail

'cause I don't wanna hog
up all Lily's time, but

Now she'll tell you a
little bit about training.

- [Lily] Thanks. Alright. So,
let's talk about training.

Now that we have this amazing site

that the dev team built it
doesn't matter unless the person

who's actually going to be admining it

understands how to do that.

So let's talk about effectively
having that conversation.

And before I talk about training

I want to talk really briefly about me.

Nick has been working in Drupal for what?

Eight years, something like that?

I'm much newer to it.

I've done a lot of random
stuff, as you can see here.

A lot of it is very communication based

and I bring that sort of
non-profit spokesperson kind of

I recently learned Drupal
and it's really confusing

when you're new, especially
when you're working in it

and people expect you to know
it perspective to my job.

And so right before I worked in Drupal

I worked part time in French.

I worked at the Alliance
Francaise in Denver.

If you live in Chicago,

it's a really beautiful building here.

You should check it out,
they're all over the world

and it's a French language
and cultural center.

And since I worked with French teachers

and I'm moderately good at French,

they thought it would be fun
to make me work in French.

So I had this experience of
working part time in French.

And then I got a job at a Drupal agency

having no idea about
anything the digital world,

anything about what Drupal was,

and I had a developer come to me and say,

Oh, I can't believe this client

doesn't know what a field is.

And I had that moment of thinking

you mean like a field, right,
out there in the pasture?

And I told them out loud I
don't know what a field is.

And so I immediately thought about Drupal

like this is the second language.

This is this new language
for me to learn and I still,

as I work with the periphery of it,

think about it in that way.

And so just like when you're building

and you start with a build
tech before the training,

prepare well.

And start with thinking about
who is going to lead it.

And this is a controversial
opinion, maybe,

but I think the person who
should lead your training

is the person who knows the
least about your website.

So not the developer, maybe.

I like to leave them in sort
of a project manager role,

but someone who knows
the least about Drupal

will know all of that
jargon and will explain

what needs to be explained
in order for these people

to understand, and maybe not explain

some of the fun guts of the site

customization that a
developer might go into

that might just overwhelm
and confuse the client.

And then also know why your
clients are in the room

and then plan your training so that

the correct people are in the room.

So if you have a big
complex site with tons

of different things and
all of these different

content admins for different pieces of it,

you might have a specialized
training and invite

only this team who's admining
this part of the site

to learn about their piece,

and only this other team for their piece.

Whereas if it's just a small site

you might have everyone in the room.

Understand where they're coming from

and make really good use of their time

and you'll keep their attention

and they'll learn better in your training.

And make sure you know
what you're going to say

and also the why of what
you're going to say.

I think that's really important.

Here's an example of one
of these training outlines

that I put together.

And so you can see on a basic page

we're learning what a content type is,

we're learning what a field is.

You can do a survey of
the room and ask people

what familiarity they have with Drupal

but make sure that you're training

to the person who knows the least.

You can kind of apologize, you know

oh hey, people who know, I
know you know what a field is

but we're just gonna go through this

really quick at the beginning.

And you'll see sort of the whys

and you'll have that
with you as go through

and make sure you're always explaining

why you're teaching them these things.

Otherwise they'll be wondering

and they may stop paying attention to you.

So now that we've
prepared for our training

we're going to start leading it.

So, I already hinted at this a little bit,

but know your audience.

Start at the beginning and
understand who's in the room,

understand their experience level,

understand what they do with this website

and what they're here to learn.

The more you know about them,

like I did at the beginning
of this presentation,

the more you can target things to them.

So that thing about hey non-developers,

this part might be
technical at the beginning,

I wouldn't have said had this
room been 100% developers.

So, things like that.

The next piece is road
mapping and signposting.

So this is something that I
learned from competitive debate,

it's something that debaters do.

Your slide deck will do it automatically

so this thing at the top, at
the training, is a signpost.

But you won't have a deck
when you're training someone

how to use a Drupal site,
so at the beginning you say

I will roadmap where we are
in the development process.

So we had a discovery
meeting and we figured out

what we were going to build.

And then we did some user
testing and we did some design.

We built the thing and we tested it

and here we are at the training.

And right here, what's
going to happen next is,

you're going to test the site,

you're going to put your
content in, things like that.

And that will help them remember,

oh yeah, here's this
thing that's been going on

for however long and this is
why this meeting is happening

and this is what I'm
expected to do next from it.

But even at the training, you know

we're going to start
with structured content

and then we're going to talk about

more flexible landing page content types.

And as you go, signpost where
you are so that they know

in the slide deck where you are

and the flow of that conversation.

And I always recommend starting simple.

So, this is a friendly, easy, basic page.

If you don't know Drupal,

this thing is not so scary looking, right?

And so you can say
look, here's this thing,

that title thing, that's a field.

When I ask you to write
something in somewhere,

when I ask you to put
an image in somewhere,

I'll be calling those a field.

And you see that thing that looks like

a kind of Word Document customization,

that's a WYSIWIG.

That means what you see is what you get.

And you can do things like bolding,

and I don't know that I would
advise you to strike through,

but you have some different options there

for formatting without knowing code.

And you can talk to them about the hazards

of putting things in from
Word and things like that.

And then once you get to
a much more complex thing,

they have these friendly things

that they already know about that you

don't have to then explain in the context

of a much scarier looking content type.

Like the one I'm about to show you.

And I always recommend showing

these scarier ones side by side.

So pull up the frontend
an pull up the backend

next to one another like this.

So if you just looked at that right piece

and you didn't know anything about Drupal

and maybe some of you are less familiar,

that looks really scary.

Because there's all of
these different pieces

coming together, there's all of, you know,

the ad content button, what does that do?

The setting things with
the scary asterisks.

But when you have them
side by side like that

you can see look, here's our mountain.

That's where we put our
mountain over there.

We could change that to
something else if we wanted to.

And when you see down
this why attend section

you can see oh, the subhead
is that little green thing.

And then the heading, learn,

oh that's underneath right there.

And you start to learn what those mean.

And I'll even tell clients
hey, if this is scary for you,

pick this page that we
built you as a sample page,

open up its backend and
have that side by side

with a fresh, new backend
page so that you can just

copy these pull up call
out content thing over

because you want it to look that same way.

And so they can transcribe side by side

from that demo page that you built them.

The next one, and this is where
I tease Nick a little bit,

is to check your jargon at the door.

So he came in and he was
already views and fields and

all this Drupal jargon
that is so familiar to us

is not familiar to our
clients necessarily.

And so, and sortie means exit in French,

so in case you didn't know,

just a door joke bringing
you back to French.

But, I really advise
picking one simple way

to explain Drupal jargon.

Have that be your way of explaining it

and then explain it
that way once every time

at the beginning of training

or whenever you use it with clients.

So we use a lot of
paragraphs and components

I call them puzzle pieces.

And so I'll say oh hey clients,

imagine that you're building a fresh page

and you have all these
different cool puzzle pieces

that you can arrange however you'd like.

Those are called components or paragraphs.

Or you might say taxonomy,

these are just lists of vocabulary terms.

And so I'll just say
taxonomy means vocabulary

and then people say okay, I get it.

And then you can use
that jargon from then on

and they'll understand
where you're coming from.

And then I think it's really important

to ask the right questions
at your training.

So there's a lot of do
you understand this or

that kind of thing and
imagine if you were sitting

in a room with your peers or
people who work under you,

or even worse your boss, and someone said

do you understand this?

My answer would be yes.

It doesn't matter if I
understand it or not.

And so think about those people

and what their motivations
of being in that training

and just like Fatima talked about earlier,

asking the right questions.

Ask them something a little friendlier

like how is this different
than the way that

you're structuring your content
on your website right now?

Or you might ask something like

what do you think is going
to be most challenging

about this new website
and you can really get at

where they're coming from
without giving them a question

that's really difficult
to answer honestly.

So we've prepared, we've
had our whole training,

and we're done, right?

Not quite. So, a couple things
to do after your training.

You definitely want to send
them training documentation.

And just like how many trainings you have

and how many groups of people

you bucket your audience in to,

the training documentation
that you put together

should be specific for the
site you're working on.

So if this is a really
small, easy, marketing site

you might just have a
screen share recording

of the training that you put together

and send that out to them.

Even that's a really nice reference.

But then as you get bigger and bigger

in your site and in its complexity,

you can expand out what you do.

So if there's a section
of the site that's complex

and you know that there's going to be

all this turnover of content admins

because of how the company is structured,

you might put together
a specific PDF document

with screenshots, do
this, do that, do this.

I really like screen
share videos because often

trainings can be
interrupted by conversation

and so have whoever's
leading your training say

this is how you do feature A
and just have this feature A

screen share that people can reference.

And so there's all different
sorts of complexity

and just understand what the
needs of that company are

and make sure you build that into your,

into the scope of your project.

And then, also make sure you're
building in touch points.

So even if you've asked these
really friendly questions

and people feel really
open to asking questions,

trainings can be really
intimidating and overwhelming

especially if you're new at Drupal.

Drupal can be really hard
to, it can be really scary.

I'm seeing some nods.

And so just make sure you say
okay, here's your training.

Take a week to digest it.

In a week, we're gonna have
just a Q and A session.

And so give them the
space, make sure you have

time in your budget and your
timeline to take that space.

So, I ended early. I hope
I didn't talk too fast,

it's a hazard of being a debater.

But we have a little time for questions

and we also really wanna
hear your feedback.

So we're giving this session again

at Drupalcon in a few weeks
so if there's something

you really love, if there's
something especially

that you didn't love,
please come and find us,

like Nick said, we'll be around

for the rest of the camp.

And also just a shout out
which I'm sure you'll see

all day today and tomorrow
for the Contribution Day

on Saturday that's coming up.

You don't have to know code to give back.

Says me, who doesn't know code.

So thank you so much
everyone for your time.

(audience applause)

And we do have a couple
minutes for questions

if anyone has any for right now.

Yeah.

- [Woman] How would
you say the best way of

going about being a project
manager and trying to give

this kind of information to
a developer who may be more

not as willing to kind of take those steps

to help your end user?

How do you make that,
how do you bring up that,

and how do you ...?

- [Lily] In the build or
in the training or both?

- [Woman] In the build.

Like during the build
when you're starting out.

Or maybe you've already
built and you're kind of

jumping in midway, how do
you make it more accessible?

- [Lily] I think for me, what I do,

and I'll let you answer too,
but I like to build pages

and flag everything that's
confusing and if the

help text or the field name isn't good

then I'll just say not good.

But if it's not clear, I might say

how do you feel about changing
the field name to this?

Because I don't know a lot about Drupal,

but I know that you can build
the backend GUTS field name

and then change what people see later

and it doesn't mess with
the structure of the site.

So I do a lot of rewrites,
those sort of things,

and then I would say even just imagine,

if they know who these people are, right

hey imagine that you're Steve right now

and you're trying to do this.

Do you think Steve would
be able to figure this out

and invite them to write for Steve.

- [Nick] Yeah, and I
think what I would say is

try to frame it objectively
as much as possible

because, you know, it
can tend to be kind of

like a personal thing I
guess, for the developer.

Like oh well I thought about it

and I built it this way for a
reason, why don't you like it?

I think getting real feedback
from the people using the site

like Lily said, I mean like if you have

the time and resources to do it

I've been blown away by how
helpful user testing is.

Even if it's just with
like one or two people,

to be able to come to them and say

this is what real people are saying.

What do you think, is
there a way to fix this?

- [Man] What do you use for user testing?

- [Nick] We've actually been
doing it entirely manually

so we're doing smaller sets of users,

typically like five to ten.

Not at once, but sort
of like per test group.

And then we work with
our UX and strategy team

and we'll put together
a mockup in InVision.

It's just sort of like a clickable mockup

and put together usually five
to seven questions around that

and then give them tasks and then ask

follow-up questions about that.

So no software that's
really managing it for us

so that wouldn't scale to
like if you wanted to do it

with like 50 to 100 people
but I know we've used

usertesting.com in the past
for non admin user tests

and that's worked well for us too.

- [male audience member] Comment and then

an unrelated question.

The comment when you mentioned
on the fields making them

the right size, one of the things that

we've learned from experience,

especially for text fields,
for short text fields,

is go ahead and make the
size of the text field

on the backend, the 255.

And use the widget to limit the size.

Because invariably we found
they'd come back and say

we told you 10 characters but now it's 14

characters or something like that.

Once you've got data
in there you can't grow

the size of the field.

So if you initially just go
ahead and make the backend

waste some database space,
it's cheap these days anyways,

make that the full size
then you can adjust

to the client's needs later on

and that gives you a lot more flexibility.

- [Nick] Yeah, that's a great point.

- [male audience member] The question.

On one of your also modules or

one of your bonus ones, chosen.

That one I'm not familiar with.

Can you give a five second
run down of what it is.

- [Nick] Yeah, of course.

It's a Drupal wrapper
for a JavaScripts library

that basically formats select lists,

multi selects, I always forget the

full scope of what it does.

I'll mainly use it for those two.`

And it just formats them
in a friendlier way.

So like a select list that
has a bunch of options in it,

it'll put a search bar in that
so you can do a text search

within that select list and
it'll dynamically limit it.

And for like multi select fields

it was in the references
slide in the presentation.

It'll do sort of the format

almost like you might see in tagged things

on other websites where
it'll put the tags in there

with like an X next to them and

you can mark them off to remove them.

So, really easy to configure like

you could probably get it up and running

in five or ten minutes, it's
definitely worth checking out.

And it works outside of Drupal too

and on the frontend, so.

- [Lily] And we're just out of time,

I hear the rustling, so,

thanks so much again, everybody

and I hope you have a really
valuable time at camp.

- [Nick] Yeah, thank you everyone.

(applause)
 

Captions made possible by ClarityPartners.com. Chicago area Drupal consultants