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

Mary Baum was one of the last ses­sions of the after­noon and was talk­ing about typog­ra­phy on the web. Mary has a long his­tory in design and typog­ra­phy 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 frus­trated by the lim­ited typo­graph­i­cal options we’ve had for 15 long years. 5 choices is not enough, it’s time we had more.

Mary pin­points the web-type drought end­ing 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 thank­fully have tons of options with dif­fer­ent type­faces. 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 hun­dreds of hours into learn­ing WordPress themes and just enough PHP to be dan­ger­ous. She got started with the Thematic frame­work but is now work­ing with the Genesis frame­work 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 type­faces in our sites. There’s plenty more but those are the ones Mary pointed to as worth using and, in some cases, pay­ing for.

All those hosted solu­tions 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 care­ful of though is upload­ing the license infor­ma­tion 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 care­ful to make sure you have a bul­let­proof CSS set up for your font. Fontspring posted an updated ver­sion of bul­let­proof 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 after­noon dis­cussing WordPress pre­mium themes. Brian runs Mister Nifty where he works with churches of all sizes on their tech needs.

He got started by cov­er­ing the truth about com­mer­cial themes. As he says:

There is not one sin­gle theme that does not require sup­port. You must build a sup­port system

Brian also believes that soft­ware devel­op­ment needs to be for the cus­tomer. This is why sup­port and doc­u­men­ta­tion are so impor­tant. As he pointed out, a pur­chased theme rarely stays in its orig­i­nal condition.

Having a solid tem­plate archi­tec­ture is also fun­da­men­tal to cre­at­ing a good pre­mium theme. Brian pointed to the WordPress Codex for infor­ma­tion on theme devel­op­ment and tem­plate hierarchy.

Brian set down a credo for prop­erly devel­op­ing a theme. He believed that you should:

  • fol­low tem­plate hier­ar­chy patterns
  • clearly name sup­port­ing files and folders
  • never, never, ever, never, ever nest a plu­gin inside a theme
  • clar­ity over cleverness

WordPress assets are your friend when cod­ing a theme. There’s a lot that is built in to WordPress which will let you eas­ily enhance a com­mer­cial theme with­out a large code foot­print. The main things dis­cussed were:

  • clearly named sidebars
  • cus­tom post types only when necessary
  • define theme loca­tions for menus
  • local­ize your strings
  • set WP image sizes vs image resiz­ing scripts
  • lever­age the power of CSS with body_class() and post_class()

He also showed off some cool func­tion­al­ity in the UpThemes frame­work that’s avail­able on Github. There’s lots of sweet stuff built in there for Google fonts and more.

In some ways code is nar­ra­tive. Your theme tells a story and has an intended result. The back-end code should clearly nar­rate the story of the front-end dis­play. All this helps because clean code lever­ages the brain to quickly iden­tify and asso­ciate words with functions.

Functions though need to use pre­fixes and should only try to accom­plish one thing. If any func­tion includes things that can be spun out into a sep­a­rate func­tion then they should be spun out that way. For code com­ments with func­tions Brian says that:

If it’s nec­es­sary to com­ment about how a func­tion works, your code stinketh.

It’s also a good idea to use built in func­tion­al­ity for things like browser detec­tion and con­tent fil­ter­ing. This keeps you from hav­ing to add lots of server over­head and user frus­tra­tion. In other words, we should be cre­at­ing use­ful code, not dupli­cate 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 fan­tasy writer with a new book com­ing out. She also works with design firms in St. Louis and has been work­ing with WordPress for over 5 years.

With her book com­ing out Shawntelle has seen both sides of the coin with what pub­lish­ers require from author websites.

WP in the pub­lish­ing community

It’s a lot more preva­lent than you first think. Shawntelle polled 47 authors from var­i­ous gen­res and 85% were using WordPress. The user-friendly Dashboard, ease of theme changes, and flex­i­bil­ity with wid­gets and plu­g­ins were favorites.

They also like it because it’s far eas­ier than cod­ing a site from scratch. When your job is writ­ing con­tent you don’t want to be spend­ing all the time cod­ing and design­ing your site.

Branding

Shawntelle said that “brand­ing is very impor­tant for authors.” The design is what read­ers first see and it should really fit with the genre of your writing.

A great exam­ple is Scott Westerfeld who has a site which fits his steam­punk style writ­ing quite well.

What’s com­mon

Authors expect a few key fea­tures for almost every site. They like hav­ing things like:

  • Newsletter inte­gra­tion
  • The abil­ity to add a back­list of books
  • Integration with social media
  • Other basics like ad man­age­ment, con­tact forms, and a well-designed blog

Most authors Shawntelle works with already have had some expe­ri­ence with WordPress. They don’t want a com­plex front-end lay­out and pre­fer to keep things simple.

Determining who is respon­si­ble for site main­te­nance is key to any project you work with an author on. Many won’t keep the site updated so fig­ur­ing out who will be respon­si­ble for that going for­ward is crucial.

Shawntelle also men­tioned some of her favorite and most use­ful plu­g­ins from projects with authors.

Publishers

Out of the 6 big pub­lish­ers 2 are run­ning WordPress in their work.1 Random House and Hachette use WordPress to power parts of their imprint on the web.

For exam­ple, 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 exist­ing Random House cat­a­log was used to power things like the New Releases slider and more on the site. They also link up to ser­vices like Goodreads, Shelfari, and LibraryThing.

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