Okay, so next up we have Emily O'Mear with Project Websites that don't suck.
Okay, hi everyone.
Thank you for coming to the talk.
I'm going to talk about Project Websites that don't suck, at least from a content perspective.
So my specialty is the words that you put on the website, not how it looks, as you will
discover from my slides, which honestly kind of suck from a design perspective.
But anyway, the words on your website, the content really matter, and a lot of projects
get this wrong.
So that's what I'm going to talk about.
Before I dive in too much, a little tiny bit about me.
I am a positioning consultant, and I work with open source startups.
And what this means is that a lot of the things that are relevant to positioning is
about determining what kind of content, what ideas you need to get across on your website.
The first thing, once you've determined your positioning, whether we're talking about something
that's commercial or an open source project, the first thing you want to do is put that
information or translate that information into something you're going to put on your website.
I also host a podcast that's called The Business of Open Source.
So there you go.
Now you know a little bit about me.
And now let's talk a little bit about the goal of a homepage.
And I'm going to focus most of this talk on the homepage, because honestly that's the
most important part of your website.
The goal of a homepage is to help people understand very quickly what your project does and whether
or not this project is worth investing another five minutes or another 30 minutes of their
time into figuring out if this project is going to work for their needs or not.
People make these decisions like they come to your website, they look at it for 20 seconds,
and then they're like, okay, am I going to invest another five minutes in this?
You want people to accurately self-select both in and out.
So if you have somebody come to your website, stay on it for 20 seconds and be like, oh,
this is not for me because it's not appropriate for whatever my use case is, and they go away.
This is a success, provided that they actually made an accurate evaluation of the fact that
this is not an appropriate fit for them.
There's a third thing that I think is really important to call out here, which is that
a good website that communicates clearly what your project does, and it doesn't have any
major screw-ups in terms of content, is going to improve your credibility.
It makes you look like you know what you're doing.
So keeping in mind, these are the things that your homepage should do.
A couple of random notes about homepages.
A lot of people can get really caught up on bounce rates, and bounce rates are not a
super great evaluation of whether or not your homepage sucks, because again, the goal is
to repel people who are bad fits.
When you repel a bad fit, you are doing them a favor because they did not have to invest
five minutes or 30 minutes, or particularly in the case of open source projects, half
of a day in order to discover that your project just doesn't work for them.
You're also doing yourself a favor because these are dumb questions that don't get asked,
or almost, I would say, off-topic discussions.
We like to say there's no dumb questions, which is sort of true, but when you get a lot
of questions that are clearly off-topic from what the goal of your project is in your community,
this is a sign that you're not doing a good job of repelling bad fits.
Moving beyond the homepage conversation, when you think about how people usually navigate
through a website of a project, if your main audience is developers, which is not the case
for every single open source project, usually they'll go directly to the docs from the homepage,
and if there isn't a prominent docs link, the other really important page is your about
page.
I'm going to talk about about pages at the end of this talk.
Okay, so let's talk about the anatomy of a homepage.
The first thing that's really important that you want people to see as soon as they come
onto your homepage before they scroll anywhere is your market category.
What that means is basically how do you describe this project?
What is it?
Usually, that's a noun, by the way.
You want people to understand also why should anyone use this project, which is to say what's
the outcome that somebody can expect from using this project.
You need to make it really clear who is an ideal fit and who is a bad fit.
Again, you want to make it as easy as possible for people to understand which bucket they
fit into.
Then last, absolutely not least, is what differentiated value do you provide?
In any market category, you're going to have a number of different options.
Every project has competitors that are other projects.
They have competitors that are closed source software.
They have competitors that are the status quo.
You want to communicate why somebody should use this particular project.
What is unique about it in terms of what they're going to get as an outcome?
Those are the really important things to communicate in a homepage.
Let me give a little bit of a couple of examples.
This is the homepage from OpenTelemetry.
What is OpenTelemetry?
Boom, it's obvious.
It's telemetry.
Success right there.
We understand what this project is all about.
What kind of telemetry is it?
High quality, ubiquitous, and portable.
Ideally, those three adjectives also describe the differentiation of what makes OpenTelemetry
different from all the other options.
Why should I use it?
What am I going to get out?
What's the outcome that I would get from using OpenTelemetry?
Because I want observability.
I want effective observability.
I really like this except for the word effective.
The reason is ideally when you're describing the outcome that somebody is going to get,
you are describing it in a way that makes it clear who is a good fit and who is not
a good fit.
Effective is the kind of word that nobody is going to self-select out of.
Nobody is like, yes, this is not going to, or yes, I'm not looking for effective observability.
I'm looking for ineffective observability.
Nobody is going to say that.
What they could say, for example, is observability at scale.
There's going to be some people in that case who would say, I don't operate at scale.
I have relatively small needs, small scale, so I don't need something that's built for
scale.
Keeping in mind, again, that idea of repelling bad fits.
Who is this for?
Here's a couple of examples.
The first one is from the Go website.
It's great for teams.
That is an indication that if you are not a team, you're not an ideal fit and that you're
not who this programming language is built for.
The second example is actually my favorite one.
This is from Glue, which is maintained by solo.io.
You can see how they're described as networking for applications, not infrastructure.
If you come to their website and you're looking for a networking solution for infrastructure,
you go away.
This is from the Apache Cassandra website.
You notice that in that first bit, they're describing what the heck Cassandra is.
They have three differentiated values here.
Runs in hybrid environments.
It's very fault tolerant and it's reliable and stable.
The good thing about that is it's really clear.
The other good thing about it is there's three things.
The bad thing about this website that you do not see on my slide is that if you scroll
down, there's another row.
If you scroll down, there's another row.
They actually chose nine differentiated values.
The problem is we're actually writing a website for humans and not robots.
Websites also have robot visitors, but you don't care about them for this part of the
exercise.
Humans tend to have trouble remembering nine things.
Three or four is where we max out.
You want to choose the three, maybe four maximum, but ideally three things that really make
your project unique and highlight them on your website.
All that other stuff, you can put it somewhere in a comparison chart that has Xs and checks
on it.
You can make it discoverable on a project page or a use case page, but don't put it
on your homepage because your homepage is really for focusing on making people understand
really quickly and getting the things that people are going to be able to stick in people's
heads.
All right.
Now, let's talk about about pages.
I mentioned that about pages are one of the most important pages on a website.
Quite frankly, most of them are garbage and the ones that are not garbage usually don't
exist.
The reason that I say that they're garbage is, first of all, they'll say things like,
we believe in kindness.
Great.
Not that everyone believes in kindness.
This does not make your project unique and it does not tell me anything about what outcome
I'm going to expect.
It doesn't build your credibility either.
Nobody is going to self-select out of we believe in kindness.
Or a lot of about pages are not human.
This can be especially the case when there's a solo maintainer of a project that doesn't
want to appear like they're a solo maintainer or wants to appear bigger than they are.
But about pages are a place to talk about the team behind this project, the humans.
They're a place to talk about your point of view, why you thought that this project was
worth creating in the first place.
And they're also a place to build credibility.
Credibility in terms of showing what sort of credentials you have.
I took this example from a company called TestifySec.
They build a couple of open source projects, one of them is called Witness, the other one
is Archivista.
And you notice on their website they talk about how their team has contributed to all
these publications that are about software supply chain security.
Basically they're taking the opportunity to really showcase why you should trust them,
why you should trust their team with your software supply chain security.
If you scroll down on their website, in fact you will see the human beings that are on
the team.
That is really important about pages are really about being human.
Last thing, it is unfortunate that I have to mention this, but it is really important,
don't screw up the basics.
You're probably not an English major, still use consistent capitalization, try not to
have really glaring punctuation errors, really glaring grammar errors.
I see this all the time.
And the thing, the way that it comes off to visitors is that if you're not careful enough
to get these sort of basics right on your website, are you getting it right in your project?
Are you getting the details right in your project?
It just looks sort of unprofessional.
You should get someone to proofread your website.
And if your website isn't a language that you do not speak natively, try to get a native
speaker of that language to proofread your website too.
Just so you can make sure that you're actually getting your point across that you're not
screwing up the basics.
Okay.
So I'm sure everyone is out here thinking like, oh no, does my website suck?
How do I figure out if my website sucks?
It's really hard to tell from just metrics.
Because like I said, a bounce rate is, it could mean that you're repelling a bunch of
bad fits and that's okay.
What you can do to determine if your website sucks is have conversations with people or
even ask people like in a Slack or a Discord group.
This doesn't require massive interviews.
It doesn't have to be super qualitative interviews.
Just asking questions like, when you came to our homepage, did you understand what our
project was?
How well did your expectations that were set by visiting our website match your experience
of actually using our project once you got up and running?
Okay.
So I'm going to do a quick recap to remind everybody what I've talked about.
Websites exist to help people self-select in or self-select out further evaluation of your
project.
They're making that decision.
Am I going to invest another five minutes?
Is this worth like reading through the docs?
You want people to understand your project quickly and you do not want to neglect your
about page and you don't want to get the basics wrong either.
Okay.
So that's about it.
I will be outside if you want to chat.
If you have questions, if you want an e-book that is about positioning for free open source
projects, you can use a QR code to get it.
And positioning is if you do not know what the differentiated value of your project is,
if that's a question you cannot answer, you need to figure that out before you start thinking
about what goes on your website.
Anyway, I'm Emily O'Mear and thank you so much.