Archive

Setting the meta description in the All in One SEO plugin

January 10th, 2012


A little tip to save you the time it took me to work out what was going on with the All in One SEO plugin for WordPress, and why a site I recently converted from static to WordPress lost its Google ranking for a while. Each page had an optimised title and meta description, yet when I googled the site, the meta description wasn’t showing up in Google.

With the All in One SEO plugin, you are able to set an optimised page title, and a meta description. This is done from the Edit page screen for the pages in question. I’d set this information for the Home page (which was a static page), so why wasn’t it shown up?

It turns out that the All in One SEO plugin doesn’t use the title and description set on the ‘Home’ page’s Edit page screen, even if it’s been set. Instead it looks at the Settings -> All in One SEO page instead, which has two fields: ‘Home Title’ and ‘Home Description’. I would argue that this is not an obvious place to store this information, and that the plugin should be implemented to look at the Home page’s ‘Edit page screen’ details, if it’s not set here.

Mobile Applications vs Mobile websites

December 5th, 2011


 

A common request from clients is for a mobile application to partner their website (“I’d like an iPhone/iPad app”). This is not a bad request in itself, but I often will discuss with them their reasons for wanting an app, so that they are not spending unnecessary budget on development. Quite often, a mobile website will do the same job or even a better job, than an application.

Strengths and Weaknesses

It’s important to consider the strengths of a mobile application versus a mobile website:

  • A mobile app can access all/most hardware capabilities (e.g. camera, geo location, offline data storage, compass, standard interface elements like tabs and list views). A mobile app can be hardware optimised.
  • A mobile website can access some but not all hardware capabilities (e.g. geo location, offline data storage). A mobile website is limited to the browser’s capabilities and Javascript engine speed, but there is a lot that a browser can do.

 

  • A mobile app can generate income via the App Store or Android Marketplace. This means that the developer doesn’t have to add a sales mechanism (e.g. merchant banking, PayPal, etc).
  • A mobile website can generate income only through online payment engines (e.g. PayPal, etc).

 

  • A mobile app (on iPhone/iPad) can only sell subscriptions to content through the App Store, giving 30% to Apple. Apple owns the relationship with the consumer, rather than the client.
  • A mobile website can completely own the relationship with the client, which can be leveraged for other sales opportunities.

 

  • A mobile app can be launched via a URL, but managing this URL cross-device is challenging. This is an issue when sending emails with links to content.
  • A mobile website can be integrated with an email strategy or other linking. A mobile website URL is cross-browser compatible.
  • A mobile app has to be found via the App Store / Android Marketplace – searching for and getting found by users is haphazard to say the least. A mobile app launch should be accompanied by multiple marketing strategies including the web, to point users to the App Store / Android Marketplace.
  • A mobile website can be found by Google, and standard web marketing strategies and SEO can be used to bring users to your website. In addition, existing users of your website do not have to download a separate application; they can instead be switched automatically to your mobile website and brought online to the mobile experience.

Case Study: The Financial Times

A good example of an organisation choosing a mobile website over a mobile application is the Financial Times. They chose to remove all their mobile applications from the App Store  / Android MarketPlace, and developed a feature rich mobile website. See the following article: http://www.mobile-ent.biz/news/read/ft-s-html5-app-has-1m-users/016218. Some of the standout figures include:

  • 20% of all online page views are via the mobile website
  • 15% of all new digital subscriptions come via the mobile website.

The lesson is that we should consider the requirements of the mobile experience for the user, and then choose a platform (website or application) following this. Don’t assume that an application is always the solution.

Why Responsive Design Actually Begins on the Server

December 1st, 2011


There is a very interesting presentation at http://www.slideshare.net/yiibu/adaptation-why-responsive-design-actually-begins-on-the-server . It covers the challenges in responsive mobile site creation, and proposes a hybrid solution of device profiles to solve it.

The first half of the presentation is worth showing anyone who does not understand the challenge of developing a mobile website that works well on multiple mobile devices, not just on the latest and greatest iPhone / Samsung / HTC.

It’s strongest point is that many people (especially in this current financial climate) will not have the latest leading edge device. In fact, your cutting edge, state of the art device from 2 years ago (read iPhone 3/3G) is now old and destined for the mobile device rubbish heap. However many people will not automatically upgrade, but will keep them, and thus there is a great proliferation of devices which don’t support the latest HTML5, slower Javascript, etc.

Added to this is that the word ‘smartphone’ retains a nebulous definition, and in fact today’s ‘cheap’ devices contain most of the features that a smartphone has (e.g. touch screen, browser), however their ability to serve the web may not be as perfect as Apple’s Mobile Safari.

This is the reason that content adaptation has had a number of solutions, via examples such responsive design, server-side detection and adaption, etc.

The solution proposed in this system is not a simple solution. It proposes an aggregation of device information (e.g. from DeviceAtlas) on top of a default device profile, stored in cookies, sent via Javascript to the server to analyse. To implement it for a client, I for one would hope to see a library to help achieve this without the larger development cost, so I will be watching closely.

There are also some interesting suggestions at the end of the presentation about some potential options for the future, e.g. changing the <img> from having one source file to having multiple source files (similar to the way the <video> tag is currently done). I would be interested in this option, however the reality is that the HTML change process is long and tortuous and thus I won’t be holding my breath.

How to prevent WordPress from requesting FTP details to download themes or updates

October 11th, 2011


WordPress will by default request your FTP details when downloading any of the following:

  • Plugins (and updates)
  • WordPress core updates

This can cause problems with your site if someone changes the details by accident, or loses the FTP password. If you don’t have an FTP client on your server this will prevent you downloading such updates or plugins via the admin.
Read

How to order your custom post type edit screen by ‘menu order’

September 30th, 2011


The problem

If you’ve created a custom post type, and enabled the post_attributes meta box, to allow users to adjust the ordering of the posts within your post type, you may expect the WordPress Admin Edit screen to list the posts by the menu order you’ve set, as per the Edit Pages screen.

However, instead, it continues to display the menu items by date order, with most recent first.

How do you order your post type Edit screen?
Read

Mobile Smart reviewed on wpmods.com

September 27th, 2011


I’m pleased to see that my Mobile Smart plugin has recently been included in a review of “3 WordPress Plugins that make your site more mobile friendly“. Thanks for the coverage, much appreciated.

WordPress: How to change the Edit Category / Taxonomy admin panel

December 1st, 2010


I hunted high and low over the web to try and find a tutorial on how to modify the headings (and data) shown in the Edit Category (or Edit Taxonomy if you’re using a custom taxonomy) admin panel. This is useful if you’re using custom meta data in a category, or if you want to hide certain fields (e.g. the description).
Read

Usability: Above or below the fold

March 22nd, 2010


I’ve just read Scrolling and Attention, the results of usability research by Jakob Nielsen. It shows some interesting results that influence how web designers position content above or below the fold.

The fold and scrolling

The “fold” is the cutoff line of the bottom of your browser window, where you have to scroll down to see content “below the fold”, and any information/data/content that you do not have to scroll is “above the fold”.

He notes that although users much more willing to scroll than back in the 90′s, there is still a hierarchy of information that a user takes in above others.

He summarises that “most important for the users’ goals or your business goals should be above the fold. Users do look below the fold, but not nearly as much as they look above the fold. “. However, he also notes that the middle content tends to be viewed less than the bottom content, if there is something worth grabbing the user’s attention. This is probably due to the user looking for elements of importance.

It means that a website home page, or any key page should ensure that the most important information should be at the top, but that we shouldn’t be afraid of scrolling.

Also it means that there should be some ‘call to action’ towards the end of the page also, to keep the user’s interest.

Pagination

One interesting thing is that he notes that paginating content can help reduce the lack of focus on the middle content, however it can also turn the user off continuing to the next page, whereas just scrolling reduces the effort the user has to do. The user should be given motivation to move onto the next page.

Mobile devices

This information is relevant to mobile devices, where a user spends a lot more time scrolling than perhaps on a larger screen. The mobile site should still have the most important information at the very top, but give calls to action. The temptation with mobile devices is to paginate everything to reduce the size of the download, however that initiates another download, which requires the user to continue being interested. It seems there is a trade off between download size and keeping the user’s attention.

Any thoughts?

Released: Mobile Smart Plugin for WordPress v0.2

March 22nd, 2010


Version 0.2 has just been released of the Mobile Smart plugin, which is a plugin to help mobile site development in WordPress.

Download through the WordPress.org plugin repository: http://www.wordpress.org/extend/plugins/mobile-smart/ (note: link will open in new window/tab).

Mobile Smart currently contains the following functionality:

  • Switch your theme to a mobile-ready theme if a mobile device is detected
  • New: Manual Switcher – to allow your user to manually switch between desktop and mobile versions. Available in 3 versions: widget, option to automatically insert into footer, or template tag.
  • Template functions to help determine which tier of mobile device (touch/smartphone/other) is viewing your site, to allow conditional content inclusion.
  • Adds device and tier specific CSS selectors to the body_class, to allow conditional CSS (e.g. so in the same way you have “.single” that you can target “.iphone” or “.mobile-tier-touch”.)

Any feedback gladly welcomed.

Released: Mobile Smart Plugin for WordPress v0.1

December 9th, 2009


Updated 22/12/2009: plugin is now hosted on WordPress.org plugin repository.

I’ve just launched the first of a suite of plugins to aid mobile site development in WordPress, called Mobile Smart.

Download through the WordPress.org plugin repository: http://www.wordpress.org/extend/plugins/mobile-smart/ (note: link will open in new window/tab).

Mobile Smart currently contains the following functionality:

  • Switch your theme to a mobile-ready theme if a mobile device is detected
  • Template functions to help determine which tier of mobile device (touch/smartphone/other) is viewing your site, to allow conditional content inclusion.
  • Adds device and tier specific CSS selectors to the body_class, to allow conditional CSS (e.g. so in the same way you have “.single” that you can target “.iphone” or “.mobile-tier-touch”.)

Any feedback gladly welcomed.


Switch to mobile version