Using wordpress mobile plugins

Its no secret that I like WordPress.  I use it everyday and I teach it occastionally to nonprofit folks at Compasspoint.  I’m especially smitten since the Happy Cog redesign, the recent spate of leaps and bounds  upgrades and closest to my heart – the Dreamweaver CS5 integration with it and other CMS systems.  So much of my work in the last year or so has been about building WordPress sites.

Custom themed, like:

• peninsulafamilyservice.com
• techwomen.org
• mycaninecountryclub.com
• esquaredlawgroup.com
• onqsf.com

Or modifying an existing theme to taste (and with a lower budget) like:

• offyourplatesf.com
• kindercycle.org
• childrensmedaid.org
• bnisf.com

Being someone who appreciates the WordPress core and the vast array of plugins / functionality that one can add to WordPress, it is natural that I would turn to that system for mobile solutions.  There are several that are pretty popular: WPtouch, WPtap, WordPress Mobile Pack, and MobilePress among them.  I’ve taken each of them for a test drive, and they all have really engaging features.    The each have free versions, some of them have customizable themes, and Mobile Pack has a mobile interface for the WordPress dashboard.  Cool.

Aside from having a free version and custom themeing, one of the features that I look for is home page customization.  I have been using WPTouch because it includes a great feature where you can choose a page other than your desktop home page for the mobile home.  This allows me to create a page of content that I feel will be most useful to users on-the-go, including address, directions, phone list, etc.  After creating this special home page, its easy to use the exclude pages plugin to hide the mobile home page from desktop users, and set for that page to serve as the home in WPTouch.  Cool.  One of the other features of WPTouch that not all of the others have is the ability to add cust0m CSS.  Yes, its a bit clunky the way you do it – adding an embedded style tag in a dialog box in the WPTouch administrative interface, but its doable and that’s within the free version.

If you have a WordPress site that’s just a blog, where you want posts to show up on the home page – any of these solutions will pretty much work out of the box.  And if you want to create a completely custom theme (and don’t want to upgrade to a paid version) MobilePress may be the way to go, but if you need to get something up super quick with a custom home page and some basic css modifcations, WPtouch is a good way to go!

Everyone (who doesn’t mind a little racy humor and some cursing) should check out Louis Katz tomorrow night (3/11/11) on Comedy Central. He is friend of mine, he was a student, and now he is a client. He is hilarious, as evidenced by Comedy Central doing a whole show of his stuff.  We launched a site for him last week. Check out Louis Katz Comedy.  Be warned, some of his stuff isn’t for the faint of heart.

I’m getting very excited about the weekend!  I’ll be flying out on Friday 3/11 to attend South by Southwest interactive, and I’m lucky enough to be invited to discuss mobile web site development with some pretty fantastic folks.  If you are coming to the conference, drop me a note and I will see you there!

Using jQuery Mobile

jQuery is cool – super cool actually – but jQuery Mobile is like Fonzie.  That dates me, I know, and it dates you too if you know who Fonzie is. In fact John Resig might not even get that reference, as the original run of Happy Days went off the air  THE DAY HE WAS BORN.  Ok, that’s weird, I just learned that on Wikipedia researching my Fonzie analogy.

At any rate, jQuery Mobile is super cool, so I used it to  a little website for the mobile side of MIGHTYminnow, called MOBILEminnow.  That site is basically mobile only at this point – not so hot in your desktop browser, but is that a fun role reversal as most sites are just the opposite.  After having completed that, I wanted to share a few thoughts about jQuery Mobile.

First, it couldn’t be more easy to use.  jQuery mobile comes with 5 themes and you can pick and choose different components from different themes and apply them to elements on your page using classes.  In addition to the included themes, its fairly easy to custom theme it.  Because a jQuery mobile site is only *one* page – consisting of divs masquerading as pages, I used an embedded style sheet for theming – why not when a site is only one page? – and the single page nature of the jQuery Mobile site makes it really easy to edit, upload and refresh to test.  Awesome.

Dreamweaver also came in really handy when working with a jQuery Mobile site as the “live view” feature allows me to interact with all of the states, and the “inspect” tool helps me to see exactly what the rules are that I need to overrule in my embedded / custom style sheet.  Go CS5.

jQuery Mobile

Creating a WordPress Theme using jQuery Mobile

Shape Shifting with CSS Media Queries

This little note is about making your website layout more friendly for folks on mobile devices using CSS3 to serve a different layout depending on the width of the user agent or browser. This is a fun method of changing your site for mobile, for a few reasons, and challenging for a few others.

1. No programming or CMS are required. You only need to know CSS. So, if you think CSS is programming (I often have people tell me they need an HTML programmer – ?) this method probably isn’t the right one for you.
2. It serves the layout depending on display size, so you can experiment with changing your browser window size (not in IE, surprise!) to see the layout change.
3. For  Dreamweaver users – Adobe has built in a very cool mutliscreen preview tool  CS5 that allows you to see your site at various screen resolutions you choose. It even allows you to pick the stylesheet for each of three display sizes, as well as setting the minimum and maximum width for each display. The only rub is, you actually have to write the stylesheets.

I would say that the media queries method of changing up your site’s layout for mobile is a good choice in a few circumstances.

• Your site is pretty light weight and you are cool serving the same HTML to everyone and just hiding elements you don’t want for small screens with display:none; without worrying about performance issues from loading big files
• Your site is static and you can’t tap into the CMS plugin community for a potentially slicker/easier solution to going mobile
• You don’t want to build a mobile only version of your site – you want the same site you see on desktop to work on mobile, you just want it to look different
• You have the resources and wherewithall to test in many devices

The basic premise with using media queries is that the browser chooses the stylesheet for you based on criteria you add to the page. The most frequently used of these would be size (specifically width), but you could also use criteria like whether the output supports color (as 0pposed to B/W), what the aspect ratio of the display is, whether the device is in portrait or landscape mode, and what medium is – print, projection, screen, handheld, etc.

I recently used this method to update kristinlong.com (a domain I mostly keep for historical purposes) and I wanted to talk a bit about the experience. I am not going to write a whole tutorial here – I have linked to several good ones below – but I do want to share a few tips and thoughts with you.

First, the media queries tool in Dreamweaver is a good starting point. But one of the more important things they don’t do, is encourage / inform you that you need to add some meta data re: the size of the size of the viewport – stating that it is the same sizes as the device. If you don’t do this, the iPhone / iPad can show the page with an initially zoomed out display. You need this meta data, though depending on your specific layouts, you may want to add more attributes.  <meta name=”viewport” content=”width=device-width” />  Another thing to note – this is less about media queries and more about showing your site on ipad – the iPad doesn’t like tall background images.  Keep your backgrounds under 1024×1024 and you should be ok, otherwise you are gonna get some weird results on your iPad display.

Wilderness in the cloud

Now for the challenges.  After having tried out this media queries method for making a site display differently in different devices, I will say I had a bit of a flashback to the days of IE 5.5 Mac, Netscape 4.7 and the browser we all love to hate, IE6 (which despite my utter dismay, lives on for one of my favorite clients). And of course, I’m also talking about the days before BrowserLab. In the flashback I saw myself sitting between a Mac and a PC, 8 or so browsers/versions open, furiously tweaking, spinning in my chair, and refreshing the various displays. Overheating from the warmth emanating from multiple machines, and holding an Eric Meyer on CSS on one knee, a first edition of Designing with Web Standards on the other one, and a O’Reilly Definitive guide to CSS open on my desk.

Using CSS media queries for mobile development  felt a bit like this, but even more challenging than those bad old days, because you have tons more actual *hardware* to test (which i don’t have), and an ever expanding list of devices / screen sizes, criteria. For me in the last couple of years, Browserlab has picked up a lot of the heavy lifting regarding testing for desktop browsers, but right now I have an Evo, iPod Touch and iPad out on my desk, as well a few emulators on my desktop, and as far as mobile is concerned, that doesn’t seem like near enough help for using media queries. I don’t know about you, but I don’t have an unlimited budget for phones and plans, and we all know you are only as good as the browsers you test, and testing for mobile means testing a LOT of browsers, so for the moment and in this economy, it doesn’t seem very easy.

One thing that did help in testing, though, is ProtoFluid which allows you to test various display sizes, portrait and landscape, and switch between them. It took me a minute to get used to the interface but is pretty cool. Especially awesome is that you can use Firebug with it, and also that you can pop out the various displays and sizes – having many open and refresh as you go.  It doesn’t have as many phone types/sizes as i would like, but beggars can’t be choosers, or so they say.  One problem I still have yet to solve is setting the display size for my Evo in landscape.  That thing is so high res, it wants the tablet CSS, but I want it to want the mobile.  If anyone has an idea for me on this, it would be much appreciated.

And while I’m making requests, another tool I would really like to see is a BrowserLab type tool for mobile. Hint, hint, Adobe!

Resources

• Adobe Dreamweaver CS5 Media Queries Tutorial
• Tutorial: CSS Media Queries: Make your site mobile-friendly
• Tutorial: CSS Media Queries & Using Available Space
• Emulator: ProtoFluid
• HTML5 meta tag – viewport
• Considerations for Mobile Design: Dimensions

We launched the Children’s Medical Aid Foundation recently, and they are a fantastic organization.  Primarily they help kids in Nepal who were born with serious birth defects.  They also help open and run medical facilities.  CMAF is leading a trip to Nepal in late April 2011, and proceeds from this trip will go towards reopening the Chisang Clinic in Bawanee, East Nepal, bringing needed healthcare to impoverished children and families. Eye opening and life changing trip to Nepal, helping families get healthcare.  Sounds like a win-win to me.

Making Your “Regular” / Desktop Website  Useable on a Smartphone

We are talking this week about making websites that work on phones. Smartphones in particular. Building a website that will work for someone who can be using either mouse, a keyboard, or their finger to interact with your site has a unique set of challenges and today I want to talk about some simple things you can do to make sure that your “desktop” site will also work on someone’s phone. We will explore what it means to deliver a different or “forked” version of your site to someone’s phone on another day, but today we are talking about opening the same web site, with the same content and CSS, and accessing it from the palm of your hand.

Drop the the content that requires a plugin

We all know what that means. Apple, for reasons Steve Jobs outlined in his open letter about Flash in April of 2010 does not support using Flash on iPads or iPhones. This decision is hotly contested and you can hear geeks of all sorts debate it. People who never liked or learned Flash feel vindicated, people who just want to watch a flash video clip on their iPad are dismayed. Whatever your feelings about the matter it does mean one thing. Your flash website doesn’t work on my iPad. or iPhone. Or a LOT of other places. And even though Droid does – it has not been that long. In practical terms, the lack of support for flash on Apple Mobile devices means one thing – you can’t build a website in flash and expect it to work for people on the go.  (See what Adobe is doing about this with Wallaby and Edge.)

Remember Your Standards

Web Standards [http://interact.webstandards.org/, http://www.opera.com/company/education/curriculum/] are more important than ever. Building a site that separates content from presentation, that is light weight and loads quickly, is all the more important when you are downloading over a mobile network. Following these practices will also make things MUCH simpler when you decide to serve a moblie specific stylesheet in tandem with your desktop CSS. Using HTML, CSS and JavaScript (or not) that take into account the differences in the medium is key.

Distinguish your finger from a mouse

(There may be a Phil Bronstein/Komodo Dragon joke in there somewhere.)

Apple is by no means the only player in the smarphone market, but if you read Apple’s tech note about making your site iPad and iPhone compatible you will notice their assertion:

“Additionally, Safari on iPhone OS users interact with your web content directly with their fingers, rather than using a mouse. This creates new opportunities for touch-enabled interfaces, but does not work well with hover states.”

Hover states have been a mainstay of many sites since time immemorial (originally with messily javascripted menus and more recently since jquery made it so easy to hide content and then display it on the fly “on hover”), but these states don’t work predictably (or necessarily at all) with a touch interface. What does this mean for you? In terms of navigation – it means that if I have to hover over something to read content or to find the link to the page i want, that I can’t be relied upon to find that content or  page at all on my phone. The most common example of this is dropdown menus, though other examples abound. Though Jeffery Zeldman has long panned the mainstay of webdesigners, dropdown menus are still popular. If you want to use them, go ahead, but make sure you use a local navigation scheme as well so that if your dropdown menu does not fire your users will still be able to find their way to that sub-page. If you are building a site by hand that means using those links from the dropdown over again (maybe by way of an include) elsewhere on the pages for the section you are in. If you are using a CMS it means using a plugin that spits out child pages like Simple Section Navigation.

Understand the viewport

The concept of “fixed” vs. “absolute” positioning in CSS is difficult enough to wrap your mind around when you know that the viewport to which you are wedding your page elements is always going to be onscreen. With a smart phone like the iPhone the viewport isn’t necessarily what you think. Apple says:

In Safari on the desktop, the viewport is analogous to the window — as you resize a window, you are resizing the viewport. As you scroll, you are scrolling the viewport. Hence, in Safari on Mac OS X and Windows, the element always stays on screen.

Safari on iPad and Safari on iPhone do not have resizable windows. In Safari on iPhone and iPad, the window size is set to the size of the screen (minus Safari user interface controls), and cannot be changed by the user. To move around a webpage, the user changes the zoom level and position of the viewport as they double tap or pinch to zoom in or out, or by touching and dragging to pan the page. As a user changes the zoom level and position of the viewport they are doing so within a viewable content area of fixed size (that is, the window). This means that webpage elements that have their position “fixed” to the viewport can end up outside the viewable content area, offscreen.

In other words, using “position: fixed;” fixes an element not in relationship to the device, but in relationship to the screen resolution of the device, such that zooming the page content can mean pushing those fixed elements off screen.

Beware and Test

HTML5 good, but beware and test (on desktop and on phone).

HTML5 is the new new thing. With the Apple flap of choosing standards – adopting HTML5, CSS and JavaScript over Flash, a lot of people who read the newspaper have heard about HTML5 and know that it is good (maybe even your Grandma). And you won’t get any argument from me. In most cases for desktop application, HTML5 is ready to go insofar as you can just replace your XHTML with HTML5, as long as you don’t need to support Firefox 2 (and who does?). But because support for the more interesting HTML5 features is as varied now as support for CSS was in 2003, use it carefully in ANY case where content (and/or form controls) needs to work the same across user agents.

If you have other solutions for this, please put them in the comments!

I have new lawyers, E Squared Law Group.  They are utterly fantastic and captivating people, and they were also lovely clients.    E Squared did MIGHTYminnow’s new contract and they couldn’t have been more thorough and professional.  If you (goodness forbid) need to get yourself a lawyer, I strongly recommend them.  And remember what they say – “an ounce of prevention…” and all that.

Their site is in WordPress, and is in English and Russian.  They are all set to update it themselves and they keep a very informative blog!

The Landcape

As people making websites, we have always had to deal with experiencial differences for people who visit our websites, and we have had to account for these different experiences when we develop them.

Since I started working in this medium in 1998, I have always had to work to accommodate things like:

• varying screen resolution (when i started building websites we built to 640×480)
• operating system differences (type rendering and typeface availability on mac vs. pc)
• browser differences (the biggest factor by far) that allowed/forced us to make use of different sets of HTML tags, different CSS properties, different implementations of JavaScript

Building websites has for most purposes always been a discipline with a panoply of technical considerations and best practices that shift almost faster than people can catalog them. The ink barely dries on a Peachpit or Sitepoint web developers guide before the book is obsolete.

Enter Mobile

In recent years, we have had the same problems building websites that work for everyone, but it is magnified. If building a website that works on a desktop machine in IE6-9, multiple versions of Firefox, Safari, Chrome and other “boutique” browsers poses a challenge, then making that same site work on an iMac at 2560 by 1440 pixels and a smart phone at 320×300 (if you are lucky), brings some mind-blowing additional considerations.

When mobile browsing first hit the scene, pre-smartphone, things seemed a little simpler. Dropping the tables, linerizing your content, using semantic HTML, and making sure your site was as understandable with NO stylesheet as it was with the desktop CSS made your site “useable” to the early adopters. But the folks with mobile enabled phones – yours truly included – were pretty forgiving of sites breaking in our hands (on our tiny displays) as we were early adopters and we couldn’t expect everyone to hop-to and rebuild their sites for a medium that was a) in its infancy and b) accessible to so few.

How long ago that seems. Yes, we live in a Tech Bubble in the Bay Area, but everyone (almost) is walking around not just with a phone, but with a computer in their pocket. Or two, or even three. Most people have an iPhone, Droid or Blackberry, and many folks carry a laptop, tablet computer and smartphone at the same time. Each of those devices have a vastly different interface, and each carry with them the ability to access the same web. Screen size and resolution is just the beginning.

In the next few days I will explore what this means to me and to other developers like me, especially is it impacts smaller projects, tighter budgets and clients and contractors with limited resources.

Contact Form 7

I have been using Contact Form 7 for a while, its a very very very easy out of the box WordPress form tool. Need a contact page? Click, click, click, voila! Contact Form 7 is free and even has an auto response feature – though they label it in such a way that it takes some figuring to discern that that is what it is.  Once you understand it though, its awesome.  This tool has saved me a LOT of time, and I have been grateful to the folks that spend their energy creating this fantastic plugin.

That said, there is a feature I would really like that isn’t there.  It doesn’t save your form field entries to a database.  It just emails you the contents – so if one goes to spam or is otherwise lost, you have no way of knowing that anyone filled out the form, and the data is lost.  Enter Gravity Forms.

Gravity Forms

Gravity forms on the contrary is a PAID plugin.  It currently costs $39 for one site and $199 for a developer license.  This tool is SUPER configurable, has support for HTML5 and is very accessible.  Its easy to add forms and the responses can be emailed, autoresponded, and saved in the DATABASE for perusal in your wordpress dashboard.  I’m as hesitant to part with my moolah as the next girl, but it was time for this tool to come into my life, so I did.  And I’m glad.

If you need help getting quality, configurable forms onto your site, check out Gravity Forms, or if you a current client and you need a form upgrade – give me a call.

And if you have better ideas for WordPress form tools, I would love to hear, and share them, so feel free to leave that in the comments.