Tag Archives: WordCamp St. Louis

WordCamp St. Louis: It’s about time. It’s about type!

Mary Baum was one of the last sessions of the afternoon and was talking about typography on the web. Mary has a long history in design and typography and believes it’s about damn time we have full access to type on the web.

The web-type drought

Up to recently we have all be frustrated by the limited typographical options we’ve had for 15 long years. 5 choices is not enough, it’s time we had more.

Mary pinpoints the web-type drought ending on the day Paul Irish posted his work on @font-face in September of 2009. He saved us. :)

We came from a time of Times, Georgia, Verdana, Trebuchet, and Tahoma. Now we thankfully have tons of options with different typefaces. Embedded OpenType has been around since 2004 but it’s only till recently that type foundries have opened up licenses for use on the web.

Background with WordPress

Mary just got started with WordPress within the last year but in that time has put hundreds of hours into learning WordPress themes and just enough PHP to be dangerous. She got started with the Thematic framework but is now working with the Genesis framework but also uses Elegant themes for some sites.

Type options

Cuf√≥n, sIFR, Typekit, fonts.com, Google web fonts are all options that we have now for using typefaces in our sites. There’s plenty more but those are the ones Mary pointed to as worth using and, in some cases, paying for.

All those hosted solutions are good but Mary still prefers going the route of using your own fonts on your own server using @font-face. One thing to be careful of though is uploading the license information to your own server as well so that it’s clear you have the rights to use that font on the web.

When using @font-face you want to be careful to make sure you have a bulletproof CSS set up for your font. Fontspring posted an updated version of bulletproof CSS to use that will cover all the way back to IE6.

WordCamp St. Louis: The Anatomy of a Premium WordPress Theme

Brian Fegter gave a talk in the afternoon discussing WordPress premium themes. Brian runs Mister Nifty where he works with churches of all sizes on their tech needs.

He got started by covering the truth about commercial themes. As he says:

There is not one single theme that does not require support. You must build a support system

Brian also believes that software development needs to be for the customer. This is why support and documentation are so important. As he pointed out, a purchased theme rarely stays in its original condition.

Having a solid template architecture is also fundamental to creating a good premium theme. Brian pointed to the WordPress Codex for information on theme development and template hierarchy.

Brian set down a credo for properly developing a theme. He believed that you should:

  • follow template hierarchy patterns
  • clearly name supporting files and folders
  • never, never, ever, never, ever nest a plugin inside a theme
  • clarity over cleverness

WordPress assets are your friend when coding a theme. There’s a lot that is built in to WordPress which will let you easily enhance a commercial theme without a large code footprint. The main things discussed were:

  • clearly named sidebars
  • custom post types only when necessary
  • define theme locations for menus
  • localize your strings
  • set WP image sizes vs image resizing scripts
  • leverage the power of CSS with body_class() and post_class()

He also showed off some cool functionality in the UpThemes framework that’s available on Github. There’s lots of sweet stuff built in there for Google fonts and more.

In some ways code is narrative. Your theme tells a story and has an intended result. The back-end code should clearly narrate the story of the front-end display. All this helps because clean code leverages the brain to quickly identify and associate words with functions.

Functions though need to use prefixes and should only try to accomplish one thing. If any function includes things that can be spun out into a separate function then they should be spun out that way. For code comments with functions Brian says that:

If it’s necessary to comment about how a function works, your code stinketh.

It’s also a good idea to use built in functionality for things like browser detection and content filtering. This keeps you from having to add lots of server overhead and user frustration. In other words, we should be creating useful code, not duplicate code.

WordCamp St. Louis: WordPress for Writers and More

Shawntelle Madison gave a talk at WordCamp St. Louis titled “WordPress for Writers, Publishers, and other Content Providers.” Shawntelle is an urban fantasy writer with a new book coming out. She also works with design firms in St. Louis and has been working with WordPress for over 5 years.

With her book coming out Shawntelle has seen both sides of the coin with what publishers require from author websites.

WP in the publishing community

It’s a lot more prevalent than you first think. Shawntelle polled 47 authors from various genres and 85% were using WordPress. The user-friendly Dashboard, ease of theme changes, and flexibility with widgets and plugins were favorites.

They also like it because it’s far easier than coding a site from scratch. When your job is writing content you don’t want to be spending all the time coding and designing your site.

Branding

Shawntelle said that “branding is very important for authors.” The design is what readers first see and it should really fit with the genre of your writing.

A great example is Scott Westerfeld who has a site which fits his steampunk style writing quite well.

What’s common

Authors expect a few key features for almost every site. They like having things like:

  • Newsletter integration
  • The ability to add a backlist of books
  • Integration with social media
  • Other basics like ad management, contact forms, and a well-designed blog

Most authors Shawntelle works with already have had some experience with WordPress. They don’t want a complex front-end layout and prefer to keep things simple.

Determining who is responsible for site maintenance is key to any project you work with an author on. Many won’t keep the site updated so figuring out who will be responsible for that going forward is crucial.

Shawntelle also mentioned some of her favorite and most useful plugins from projects with authors.

Publishers

Out of the 6 big publishers 2 are running WordPress in their work.1 Random House and Hachette use WordPress to power parts of their imprint on the web.

For example, Random House uses WordPress to power their At Random site. There’s tons of reader guides, audio and video, as well as links to the books in the Random House catalog.

Data from the existing Random House catalog was used to power things like the New Releases slider and more on the site. They also link up to services like Goodreads, Shelfari, and LibraryThing.

  1. The big 6 are Macmillan, Random House, Penguin, Simon and Schuster, Hachette Books, and HarperCollins.