This talk by Matt Vanderpol, given at this year’s WordCamp Sacramento, is an overview of how to incorporate Sass into your theme building practices. The talk will cover:
- What is Sass and why should you use it
- File organization, including WordPress-specific considerations
- Sass best practices, including WordPress-specific considerations
- Using a task runner (grunt/gulp) and development best practices
- Thoughts and considerations for parent/child themes
- Incorporating 3rd party libraries and frameworks
- Exposing styles to WP Admin for better WYSIWYG display
- Thoughts and considerations for development vs production CSS
-
- Debugging CSS issues in the Sass
- Mention of PostCSS and how it can complement Sass
Slides for this talk are also available in downloadable form from this link.
WordPress has supported custom page templates for over 12 years, allowing developers to create various layouts for specific pages, and allowing users to select a specific template for each page they create.
While this feature is very helpful, it has always been limited to the ‘page’ post type and was not available to other post types.
By opening up the page template functionality to all post types, developers will be able to add more than one template for any post type available on a site, and users will then be able to choose a template for individual pieces of content.
In addition to the Template Name file header, the post types supported by a template can be specified using Template Post Type: post, foo, bar.
When at least one template exists for a post type, the ‘Post Attributes’ meta box will be displayed in the back end, without the need to add post type support for ‘page-attributes’. ‘Post Attributes’ can be customized per post type using the ‘attributes’ label when registering a post type.
As someone who builds websites, I come across the following scenario all too often.
Someone contacts me, and tells me that they either need to update an existing website, or build a new one, and they want that website to do things like sell their products or get newsletter subscribers or any other call to action. They’ve got ideas about the visuals, or they’ve got ideas about how much profit they’re expecting the site to generate, and they’ve even got a few ideas about how they want their site to generate all this abundance. They usually involve the notion that their website will do magical things for them while they sleep, with very little effort on their part, and with the idea of content as an afterthought.
It doesn’t work like that.
You cannot half-ass content. It is the driving force behind your website. Your content, more than your visual design or the code that forms your website, is what does all that magic for you. Good content takes time to write and it takes strategy. Hope is not that strategy. Content can’t just be thrown together. It needs to be informed by the overall goals of your website, and it needs to speak to your audience. Yes, you have to define an audience, and it’s not anyone with a pulse and a checkbook. Good content takes research and planning. It takes hard work, and it has to be consistently updated. Websites are not brochures or advertisements or online business cards or fliers that you stick on someone’s windshield, hoping that whoever owns that car will call you wanting to buy what you’re selling. Websites are complex pieces of application software. They are living and breathing things that need to be fed and cared for. You feed them by crafting content that is useful to your audience both before and after the sale or newsletter sign-up. You care for them by keeping their underlying code up-to-date. But most importantly, you feed them. By feeding your website good, quality content, you feed your audience. Your audience then gives back by responding to your call to action, which is also content, and needs to be crafted to suit the overall goals of your website.
As if that wasn’t enough, your content should also inform the visual design of your website. A website that is not designed around the content it will contain is nothing more than an empty shell and the culmination of a lot of wasted time and effort, and any responses to your calls to action will happen for no other reason than sheer luck.
There are lots of moving parts that make up a well-performing website, and they’re all important. But content is the most important. If you don’t have that figured out, you may as well not even have a website.
When websites and applications are badly designed, they create barriers that exclude people from using the web as it was intended. Poor accessibility creates a disabling environment where the design does not consider the wide variation in human ability and experience. In other words, disability is a conflict between someone’s functional capability and the world we have constructed. In this social view of disability, it is the product that creates the barrier, not the person , just as design is at fault when a site has poor usability.
–Sarah Horton & Whitney Quesenbery, A Web for Everyone
Finally, a three hundred and sixty degree view on transcription.
BobWP, (otherwise known as Bob Dunn), has written down his thoughts on podcast transcription specifically, but I think they also apply to transcription in general. You should go read his post, because my thoughts spring from his.
The part of the post that struck me the most was the brief discussion of possible revenue loss. Not only is there a cost for the transcription itself, (which Bob has determined is the cost of doing business), but sponsors are also hesitant to cover transcription costs for fear of losing revenue from podcast listeners. And if we’re totally honest, businesses don’t sponsor podcasts for exposure, they do so for possible revenue from listeners. To be honest again, the reason non-hobby podcasts exist is to drive revenue to the businesses putting them on. If a podcast or podcast network can’t produce at least revenue, and ideally profit, then it goes away because it’s an unnecessary expense. For an illustration of this, see what happened to the Serotalk Podcast Network.
Podcasts specifically are very difficult to monetize in the first place, unless you have a metric ton of listeners. So I’m glad to see that, despite the failed crowd funding campaign Bob ran to get his podcast episodes transcribed, he’s chalking it up to the cost of business and going ahead with it anyway. While I’m glad Bob is doing the right thing, I think advocacy for podcast transcription specifically needs to take the cost/sponsorship part into account. Podcasts that are raking in enough to pay for expenses and make a profit have no excuse to leave it out. But for smaller podcasts, I think a pragmatic approach is going to be more productive than activism.
For accessibility advocates appearing on podcasts, offering to cover the transcription cost of at least that episode could be one way to handle transcription, and for podcast creators, reassuring sponsors that they will have an ad more appropriate to text content could also work. These are just ideas, but I think both of these could serve as possible solutions to the lack of transcription in the podcast realm.