I installed MobilePress and it appears to working very well. My impetus was that I was sick of trying to access my blog on my Nokia E71 which, although it has a fairly full-featured browser, is still a small screen making it an utter pain to scroll around. Not to mention the pointless download of many superfluous kilobytes of data. So hopefully, if you happen to be looking at this on a mobile browser, it will be that much easier to read.

While I was at it I also had a go at WPhone and Wordmobi. WPhone is similar to MobilePress in that it presents a different interface for mobile browsers but, in the case, does it for the Wordpress administration area. I haven’t used it too much so far but it seems functional enough. Wordmobi is functionality the same as WPhone but is an S60 (Symbian) application so I don’t even have to worry about downloading unnecessary data or how the interface is rendered – only the data I need is retrieved and sent. Interestingly it runs on Python, which I didn’t even know was available for Symbian. That in itself may require further investigation in future as it could seriously lower the barrier to entry for programming mobile applications.

One final thing to note is that I installed the two extensions via the Wordpress plugin system available through the admin panel. It was stupidly simple and meant I didn’t have to mess around with FTP clients and the like. I’d say it was a very positive experience and practically worth an upgrade to 2.7 in itself! I’m hoping that having better mobile access to my blog will help me carry through on my new year’s resolution to post more frequently.

So I upped the memory limit for PHP to 16Mb and all is now well. I hope.

Installation of the plugin is as simple as you can get: upload to your Wordpress plugins directory and then activate from the admin area. Done! Configuration is pretty simple as well and you’ll probably find you don’t need to adjust anything from the defaults.

Actually using the plugin is, of course, simple as well. When you type into the Tags field below the post editor an auto-suggest box will be brought up with tags that you’ve already added to previous posts, which lets you quickly and easily make sure you’re using the same tags across different posts. If you save the post and then edit it you are also presented with a list of suggested tags that you can just click on to add to the list of tags. These things fit in with the existing system very well and don’t get in your way.

Simple Tags also provides some other handy features, such as managing the tags for you blog and allowing mass editing of the tags for your posts. Mass editing is excellent when converting to a tagged blog as you can change the tags for numerous posts all on one page, complete with the auto-suggest feature found in the post editor.

If you are using the tagging feature of Wordpress 2.3 I highly recommend using this plugin – it will make your life a whole lot easier.

I have also started work on a completely revised theme for the site which I hope to get finished in the next week or so. I’m using The Morning After as a base and making some pretty heavy customisations as well as a bunch of cosmetic changes. The interesting thing is that many aspects of the theme are a step backwards for me in some ways, such as the CSS being far more complex than it needs to be and the semantics of the markup being all out of wack. Still, it’s a good base visually and structurally.

I think having offline access to your blog’s post writing would be a great feature to have for blog authors. It means, for example, that you’d be able to take a laptop on holiday with you and know that you can at least write your blog posts when they’re in your head and you can upload them to your server when you have an internet connection.

It also means that you wouldn’t need to have Wordpress connected to the internet to be able to save posts. This means that clicking save has no chance of losing your work since it is saved to a local database. Another side effect is that periodically saving the post can occur much more frequently since local access is much faster and lower latency than accessing a remote server.

The problem, naturally, is how to implement this new functionality.

I think that offline access to the entire blog administration area is going to be practically impossible. This is mostly because of Wordpress’s extremely flexible plugin system which means no two blogs can never be assumed to contain the same features. In fact, most blogs would have quite a number of modifications to the admin area such as SEO optimisations for posts and pages, comment filters, related posts and so on. This is, of course, to say nothing of the options for all of those plugins, as well as the themes used for the blog. So, overall, I believe true offline functionality would need to be limited to the “write” pages and, even then, the functionality of the system would need to be limited to the bare essentials: title, post content, optional excerpt, categories, trackbacks, and the post options such as post slug, post status, etc. Other pages could still be shown from a cached version with “disabled in offline mode” in a lightbox or something.

So if we just want to enable offline post editing then a plugin needs to be created that loads the required offline access API (I thinking Google Gears) and all the client-side JavaScript to handle it. Presumably the plugin itself is not hard. The client-side logic would be more difficult. There is first the question of whether or not to allow “modal” or “modeless” offline access, which basically asks the question of whether or not to make offline “transparent” to the end user. If they lose their internet connection does everything keep working with reduced functionality (modeless) or do you require the user to switch into offline mode (modal)? To solve the initial problem I was discussing you would ideally want modeless access but then you have great problems reconciling the full functionality of the Wordpress system when connected with the reduced functionality when there is no connection. For example, when connected you would naturally allow any and all plugins but what do you do when the connection is lost? The user will have had access to extra fields that the client-side code did not know about and so would not save. Hardly a great solution!

Some of my programmer intuition (is there such a thing?) tells me that there might be room for a devious system design that could read the code of the rendered writing page, pick out all the extra fields that are placed in there by plugins and add these dynamically to the local database store. This would effectively get around the reconciliation issue. I’m not how easy that would be to implement but my brief foray into jQuery makes me think it shouldn’t be that hard to detect “new” input fields.

There are still synchronisation issues but these are present in any web application wishing to provide offline functionality.

Overall, I’d say an offline Wordpress system is definitely possible but how much work involved to get around some of the issue may be another matter entirely. I shall endeavour to look into the creation of a “Wordpress Offline” plugin once I have time.