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 Sep­tem­ber of 2009. He saved us. :)

We came from a time of Times, Geor­gia, Ver­dana, Tre­buchet, and Tahoma. Now we thank­fully have tons of options with dif­fer­ent type­faces. Embed­ded Open­Type has been around since 2004 but it’s only till recently that type foundries have opened up licenses for use on the web.

Back­ground with WordPress

Mary just got started with Word­Press within the last year but in that time has put hun­dreds of hours into learn­ing Word­Press themes and just enough PHP to be dan­ger­ous. She got started with the The­matic frame­work but is now work­ing with the Gen­e­sis frame­work but also uses Ele­gant themes for some sites.

Type options

Cufón, sIFR, Type­kit, 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 Word­Press pre­mium themes. Brian runs Mis­ter 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.

Hav­ing 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 Word­Press 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

Word­Press assets are your friend when cod­ing a theme. There’s a lot that is built in to Word­Press 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.

Func­tions 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

Shawn­telle Madi­son gave a talk at Word­Camp St. Louis titled “Word­Press for Writ­ers, Pub­lish­ers, and other Con­tent Providers.” Shawn­telle 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 Word­Press for over 5 years.

With her book com­ing out Shawn­telle 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. Shawn­telle polled 47 authors from var­i­ous gen­res and 85% were using Word­Press. The user-friendly Dash­board, 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.

Brand­ing

Shawn­telle 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 West­er­feld 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:

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

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

Deter­min­ing 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.

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

Pub­lish­ers

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

For exam­ple, Ran­dom House uses Word­Press to power their At Ran­dom site. There’s tons of reader guides, audio and video, as well as links to the books in the Ran­dom House catalog.

Data from the exist­ing Ran­dom 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, Shel­fari, and LibraryThing.

  1. The big 6 are Macmil­lan, Ran­dom House, Pen­guin, Simon and Schus­ter, Hachette Books, and HarperCollins.