Skip to content

Latest commit

 

History

History
167 lines (90 loc) · 5.76 KB

scratch.md

File metadata and controls

167 lines (90 loc) · 5.76 KB

#What is it?

Michal Bluma

https://isotrope.net https://michalbluma.com https://blamebluma.com

##Q & eh!

Hi, I'm Michal Bluma. Today, we'll be looking at content planning. As you can imagine, there's no way that we'll be able to dive deeplyinto the subject. Today is mainly going to be about questions, questionis that you should ve asking yourself whe you'Re starting a new project and kgathering information about the site's content.

##Posts, Pages & CPTs

Yes, we'll often work on sites that require using posts, like blogs We'll often have pages that present information.

Often, though, that's not enough and that's what we'll talk about today.

alIf you're working on a band's website, you'll probably be dealing with "albums", "songs", "merch", "band members", ... Those aren't posts nor are they pages.

You might bve working with a book editor and dealing with ..."yes, books" buyt also authors, "points of sale", ...

Those aren't posts or pages either because you will want an "archive view of band members". You will want to be able to sort "books" by publication date.

If you just dive into the project with a simple diragram, trust me, you will have very unpleasant surprises later on. My magic eightball tells me that you will run into weird obstacles and feel like you're trying to fit square pegs into round holes.

##darn good coffee

I've chosen a diner as today's example. Our customer, "darn good coffee", is a little (fictive) place out in the State of Washington.

Their coffee is amazing and their cherry pie is, litterally, to die for.

##Let the content planning begin!

As you can imagine, they're REALLY proud of their coffee. So much so, that we'll have a special section of the site dedicated to said caffeinated gold.

What is coffee? It's a liquid, it's brown, it comes in various forms; it can be hot, cold. Do we care that it's brown or liquid? No.

Do we care if it's decaf? Yes! Do we care where the beans were sourced? maybe Do we care about the flavour? definitely!

##A question of filters When you're planning the attributes, you don't want to start going encyoclepic with the information. We're not doing our version of Encyclopedia Britannica, here.

Rather, you want to think in terms of "which properties could we use to sort the data?", "could this be a property that might serve to filter a view?"

You want to figure out which properties can simply be "dumb content". Dumb content would be something that isn't necessary for the project's scope.

##Diane, you've gotta try this pie the Darn Fine Coffee diner is also well-know for their pie. They actually have a variety of them.

Let's think about pies for a second... ....

....

What's a pie? [ pause for suggestionsv ]

It's round, it's warm. It can be strawberry, cherry, apple, ... You can serve it à la mode.

Too many pies can also go straight to your stomache ....as you can see by the result of doing research for this presentation [ point to beer belly ... hilarity ensues ]

Let's get back to our website. We definitely want a "pie archive", a place where we can have an overview of all the pies. We'll then have individual pages for each pie.

Sound good? Sounds delicious!

Do we need to know what type of crust the pie has? Maybe Do we need to know the flavour? Definitely! Is it gluten-free? Celiacs be nodding

Being a food, and us being nice, polite, health-minded Canadians, we might think of the pie's nutritional info. We're so used to seeing the labels on packaging, we might want to present some of them to the customer.

Could we want to be able to view the calories-count AND be able to sort by calory count? Could happen!

Will our date want to see only the vegan options? Could happen.

Do we need to start listing individual ingredients or the sodium count? That might be taking a bit far. That could definitely fit within our "dumb content" section.

When I say "dumb content", I mean content that can go into a dumb editor field.

The ones we mentioned above that we do want to present will become individual content fields. They could be postmeta fields or custom taxonomies.

Being developers, you never make your webmasters write HTML, right?

If the webmaster has to write even a single

tag in the editor, you're doing it wrong. Our job is to gather the information and present it.

##Shelly and Norma and laura, oh my! The last "object" we'll look at is the employees.

If you're building an intranet site, you're going to have A LOT of properties to handle for each employee.

If you're trying to show off a diner's staff, you might need only a few pieces of specific information.

We'll want a name, maybe a photo. Want to show how long they've worked there? Let's have an "employee started on" field.

###Gallery Since we're so proud of our staff, let's also add a gallery for each person.

A Gallery isn't la property that "describes" someone. It's not a book's page count. But it's definitely a group of "content" that is related to each individual.

We'll probablt need a gallery field (please don't make your users do this within the content). We'll also need to display these pictures on the front-end. That means some work for the back-end developer (fields) as well as the front-end developer and designer. Those pictures might end up in a lightbox or a carousel. We definitely want to decide on the tech we'll be using, like "Which JS library?" before actually starting work on the project.

##Think before you act Remember to think about your content, what is it really? Think of books and their page count, their authors, their ISBN number, their release date,

Think of a band's discography, when each album came out, what the tracks are, which formats is it available in, the links to the various distribution channels,...

Think https://knowyourmeme.com/memes/roll-safe

#Thank you