Alternative User Interfaces
January 30th 2010
In my opinion the most important change in blogging software in the near future is going to be driven by the potential for new content types. It isn't the content type itself that makes the difference though, but the need to create an infrastructure around that content type to properly deal with it.
As content types go the humble blog post is pretty flexible. You get a date, some taxonomy and a big space to put HTML into and with that you can do pretty much anything you want. That, however, is the same as saying that HTML is flexible: You can make it to do whatever you want but you are going to need some scafolding to do it.
Despite that flexibility a blog post is generally not suited for use as, say, a photoblog post, for one main reason: the UI. The UI assumes HTML content with media as an insert instead of what you really need which is a single attached photograph front and centre and some text as a footnote. You can quite easily create a photoblog post by inserting a photograph into the HTML content but really the experience could be so much more.
If however you install a plugin that creates a photoblog post content type then that plugin is also going to need to create a UI for managing these posts and it is here that the potential really gets going. Even if the underlying data is the same, the alternative UI can give you options to make the end result so much richer.
As a photoblogger myself I can't wait to see a complete photoblog solution for WordPress or Habari that gets rid of the standard blog post admin and replaces it with something custom designed for selecting photographs. I've seen photoblog plugins before but none that really sorted out the UI.
This particular example is however a prelude to a wider topic and that is whether the entire admin area of a system should be removed to a selection of plugins.
As publishing systems become less specific in their focus, for example, by adding the ability to create new types, you have to ask whether it would be better to create only the most basic admin page, and move all the controls to plugins so that the software can be downloaded as 'editions'.
A photographers edition where the administration area enforces a workflow based around media might operate very differently from controls designed for designers, bloggers, static sites, etc.
There's nothing stopping plugins from removing content and replacing it, but I can't help but think that putting most admin controls into plugins sends a message that alternative admin areas are expected, and that might kickstart the desire for developers to actually create them, instead of trying to optimise what is already there to a particular need without really changing it.
0 Comments
Mulling on themes in a variable content-type environment
January 27th 2010
A couple of posts ago I asked what the difference was between themes and plugins. Here's why:
To my mind, a theme is a collection of web pages (or template files) which may have some extra functionality bundled with it and a plugin is extra functionality which may have web pages (or template files) attached.
The key difference in real terms is that it is assumed that most template pages will exist in the same place (for a particular theme) and have certain pre-defined file names because, in a system with pre-defined content types, you can pre-judge what pages will be needed to display that content.
Taking WordPress as the example we know a home page will be needed, a page page, a single page, a category page, etc.
In a system which starts without any content types or a system that actively encourages new content types there may however be different needs that suggest alternative ways of dealing with themes. For example, even though you might not know what kind of content will be used you can still pre-define item.php, item.{type}.php, item.{type}.multiple.php, taxonomy.{type}.{name}.php and so on, but the chances of these being able to deal with even the simplest content type are remote.
The question is, in this kind of environment should themers just try their best to cope with the most likely scenario: pages, posts, images, etc, or are there ways for the system to organise theme content to make it easier for plugins that create new content?
A follow up to this is, if there are ways to organise content, would any of these things be useful in existing platforms such as WordPress?
The first step is probably to remove responsibility from the theme for assembling the actual page. There seems to be little reason for a themer to need to create any content that sits outside the body of the page. CSS and Javascript files can be registered for inclusion by the code, page titles can be set in code, you could if you wanted provide options to choose the doctype and encoding, although I think standardising these might be preferable.
Another possible option is to try and standardise as much of the HTML as possible; for example, the HTML for most menus tends to be the same. If the themer doesn't have to worry about creating a menu, instead just inserting one where he wants, then all menus can have consistent skeletons that themers can add skin to. The same might be true of the html for creating columns and other variable features.
This is not radically different from the way child themes operate, although it would have to be more flexible. In addition, WordPress already does this in a few areas such as the comment form, and some HTML that originated in the Kubrick theme.
Finally, if plugins add the ability to use new content types they should probably also specify a default HTML template and layout, using mostly standardised class names, for that type. Ideally a theme should be able to call $item->output() or similar and be presented with the appropriate HTML and CSS. Standardising on HTML 5 would make the styling issues much simpler as well as a themer would not need to worry about which level header was used for the title etc.
Whether or not these specific ideas, none of which are new, are the best way of dealing with it is one question; however, they are all generally a variation on standardisation of content with a view to removing the amount of actual HTML a themer produces. Ideally they would produce none, although in the real world it is almost certain some would be required.
This leads back to the original question about the difference between plugins and themes. If a theme can be produced without writing any HTML (or writing only a few layout pages which components slot into) and it can be skinned using the equivalent of a child theme containing nothing but CSS, then the difference between themes and plugins disapears and presentation becomes just one more thing you can write a plugin for.
0 Comments
WordPress coders have no class
January 25th 2010
A few days ago a brief Twitter conversation amongst some of the WordPress folks I follow pondered the question of whether WordPress plugin and theme authors have a tendency to use object-based techniques in their code primarily to show off the fact that they can. This started with a comment that the code was often quite difficult to decypher.
This is an interesting question as it contains a number of assumptions about the necessity of using object oriented code in a non-object oriented environment.
What do I mean by a non-object oriented environment? Well, firstly WordPress still does not require PHP5 for core code so there are limits to how many of the techniques it can use anyway. Secondly, WordPress has been around for a long time and has been developed by many contributers looking to achieve specific things with each patch without having a particular architecture imposed, except by committee.
WordPress developers tend to start as users who learn PHP in fits-and-starts when they need to acomplish something. They move from echo statements in themes, to functions, to classes, picking up ‘best practices’ as they go.
This is certainly true for me. Only recently have I graduated from using objects to organise code a little better to considering how I can use design patterns and good design to really improve the quality of testing, encapsulation, reuse, etc.
The thing is though that this transition has happened as a result of two processes: The first was learning how to develop for Habari and the second was beginning to develop my own content management system.
Habari has been developed using established and recongisable design patterns (once you know what to look for), and requires some object oriented techniques, such as extending base classes to build even simple plugins. Once you start needing to delve a little deeper into the code you have little choice but to learn what is going on.
My understanding of Habari itself was significantly improved once I started to trying to built my own system. I soon found out that what seemed like a nice way of making things work in Habari was actually something that had long existed in other languages, for example, an Active Record pattern, or a variation thereof.
What is important about these steps is that I needed to step away from WordPress to learn them. Which is another way of saying that when using WordPress I just didn't need to know. The same is probably true of almost all WordPress developers.
So, should those WordPress developers who are familiar with these techniques hold off on using them in their plugins or themes to make sure that other developers can more easily adapt their code?
If these techniques become more prevalent in themes and plugins they will certainly lead to more uninformed use of classes and object-based techniques by people who see the benefits but haven't yet learned the academics. The question is whether it is better to push developers toward this kind of thing, and deal with the intermediate steps, or to try and focus energy on other matters and keep code as understandable as possible, if that is even possible?
I am not intending to try and answer that question, but I think it takes me back to the original question about objects and classes being used as an act of self-congratulation instead of for sound architectural reasons.
I don't think classes and object-based techniques are used because they can be, or because they appear clever (on the whole), but because once you start to learn about using objects there is a certain elegance that becomes apparent. The fact that the coder may know and understand only a small fraction of those practices and the reasons for them doesn't take away from that.
It is enthusiasm for better code and better practices that leads people to use them, rightly or wrongly, and I don't think we should complain too much about that.
17 Comments
A question about blog platforms
January 20th 2010
A thought occured to me today. I was going to write it up (and still will) but I first I thought I would ask the question on which the thought is based:
What's the difference between a theme and a plugin?
1 Comment
What's the bare minimum a web publishing tool must have?
December 28th 2009
For a long time I have been arguing that WordPress should be removing features and providing them as core plugins instead of loading up the core code. That's the way I like things; however, I understand that WordPress is a tool for the masses, and so more (as opposed to less) is indeed more in this case. If it did happen though, what would be the absolute minimum feature set that the core should be left with?
I've been trying to think around this for a few days now and it isn't a simple answer. Obviously you need to be able to type in a URL and get content, but must that content contain 'pages' or 'blog' functionality or both? You can have a website without a blog but can you have a blog without any 'pages' at all?
What about media management? Is that something that every web publishing tool must have, without exception?
How about the admin interface itself? User management probably needs to be built in to the underlying API but is a visual user interface necessary when you may choose to control any number of blogs from a central point and therefore never need an indiviual admin tool?
The admin area is a good example of functionality that you might want to separate from the core so you can switch it out for something else. With a plugin admin area you can choose the most feature laden and complex setup or a simple three button fisher price version depending on your intended use.
Keep in mind now that I am not actually suggesting that any functionality would be unavailable, simply that you would need to use a plugin to get it. Anything over and above the core would be optional.
So what features and functionality should be always on because it simply cannot be done without?
10 Comments
Not Another Content Management System
December 26th 2009
When I started this website I did so because I was in need of a project. I was coming to the end of 365 days of photography and needed something else to focus on. So, instead of throwing up a WordPress or Habari install and spending my time theming I decided to build the system myself.
As it wasn't intended for public consumption it didn't need to be all signing or dancing, or even particularly extendable, it just needed to do what I though I would need it to. The basics.
So I put together a basic request handler, a way to save content and produce different types of content, some taxonomy controls and I was ready to publish.
With this site live I moved on to the next project, rebuilding photospots, and it made sense to use the same platform. I was already familiar with it and with some extra user management, flickr integration and geolocation classes I could quite easily turn it to running a membership driven site.
In doing that though I found I needed to update a lot of the original code. It didn't need to change, just handle some extra situations. So I went ahead and updated it.
So what do you do when you have two different versions of the same basic platform running? I figured my next project should be to combine the two and produce something that was a little more extensible. And that's where I'm at now.
Writing your content management system
Writing your own content management system (using the plain English definition) is a fascinating business. When you work with WordPress or Habari most of the work has been done for you; you just need to figure out how to extend it for your needs and invariably you come up with cool things that the software could do.
You also find your own gripes. Not OOP enough, too bloated, too complicated, It doesn't matter what the gripes are, there are people with opinions on both sides, they are invariably based on your own view and uses of the software.
When you start to build your own you start to think on an entirely new level. You need to start thinking about architecture, about consistency, about speed, practicality, extensibility and so much more.
One of the most interesting aspects is that there are so many ways to achieve the same thing and lots of reasons for doing things one way or another. Here's a good example:
A thread on WP Hackers last week was discussing methods for dealing with metadata for content items. As my system was built to use multiple content types by default this got me thinking about whether the way I had gone about implementing this feature was the most effective.
The model I used for storing the data was this one:
The gist of this model is that the standardised information about each item (type, name, created date, etc) is stored in one table, and all the data fields that are type specific (e.g. an image for photoblog posts) are stored in the details table in key / value fields.
This is easiy to implement and, as it doesn't require any changes to the database structure to deal with new types, is also easy to maintain.
It does however have its problems. First, it stores far more data than is needed because, instead of a single column of values it stores the name of the key every time a value is saved. This also makes it slower to query. It also means you have no control over the data types stored. They will always be stored as a string.
The key issue with it though is that it can make it hard to do even fairly simply queries. Take the situation where you want to return all the records where value A is less than X and more than Y and value B is less than Z. It is a simple enough query normally, but I couldn't say quite how to do it with SQL using this model.
So what are the alternatives?
The first is to modify the database in one direction; i.e. to add columns. When a new post type is added, new columns are added to the post (or the details table). Any columns not used by a particular type will contain null values when not used.
I don't like this option as it adds columns that may be entirely unnecessary for most of the content, and makes column changes to all of the data each time one type is changed. It feels as though it might have performance issues as well, but I'm not sure on that.
The next option is to add a new table for each post type.
This option feels much neater, but is likely to involve more code to manage it. The first option makes adding extra content a trivial matter which anyone can do. Not dissimilar to the custom fields option in WordPress. If you need a new option just add it. Adding a new column to a table to do that is a much bigger deal, so you may end up not only with a table for each type but also a generic details table as well.
The option you choose depends on what you want the system to do, or not do, whether speed or extensibility is more important, how much control you want to leave to the users, and so on.
It is these sorts of questions and decisions which using WordPress or Habari takes out of your consciousness and is exactly why writing your own CMS is so interesting. Right now I am leaning toward the third option, rather than the first but there are always reasons to change my mind.
There is also something very satisfying about typing in a URL and seeing a plugin serve up custom pages when you started with a blank file and a head full of ideas.
I don't know whether my system will or should ever be ready for public consumption; I will make it open source, and it will almost certainly be stored in a public respository; but that isn't really the point. There was something that didn't work for me when I was using WordPress. I can't say or sure what it was, but it seems to have been resolved by using something I've written myself. Long may that continue.
3 Comments
Programmatic Themes
December 12th 2009
For some time now I've been thinking about programmatic themes. That is, themes that are produced entirely in PHP and as a result can be modified entirely by code.
The concept of using objects within code which are directly representative of HTML elements is not a new one, ASP.Net uses this extensively as does Habari for form handling; however, I have yet to see a full theme handling framework produced for WordPress and the idea intrigues me a lot.
Before I go on to consider the advantages and disadvantages of this let me explain a little bit about what I mean.
WordPress themes are really just normal PHP files. Everything WordPress loads in the background is aimed at preparing the data that will be needed when the webpages that make up the theme are loaded. Once this point is reached WordPress chooses which file should be used and it runs with very little intervention, as if it had been called directly.
Some other systems use a more involved process whereby the HTML and some special codes are included within template files. The content system loads this template into a variable and replaces the special codes with content before echoing to the browser. These can be quite complex with markup for insertion, formatting and even repeating regions. Despite this complexity and control these template files are still essentially hand crafted html which is off limits to the code.
What I am interested in is a process without any template files at all. Instead of template files the theme contains a library of PHP objects that represent HTML structures. For example, you might have a menu object into which you add details of the items you want to include. When called the PHP object will output a div tag that contains an unordered list which in turn contains all of the menu items you created within your PHP script.
The concept might be difficult to imagine so let me provide a slightly more involved example using some code.
In WordPress, the functions.php file contains:
//create the page object//this handles all the doctype, header, etc.$page = new page();$page->title = the_title();//create a header object$header = new htmlcontainer();$header->width = '100%';$header->height = '200px';//create the content for the main body//use a container object which is a DIV or series of DIVs$contentContainer = new container();$contentContainer->width = '100%';//we went this container to have 2 columns, main and sidebar$contentContainer->columns = 2;$contentContainer->columns[1]->width = '70%';$contentContainer->columns[2]->width = '30%';//we want the first column to contain the post content only//so create a generic container for the content$content = new genericHTML();$content->content = the_content();//add the generic content object into the first column$contentContainer->columns[1]->add( $content );//add the content into the page$page->add( $header );$page->add( $content );
There is only one other template file, the index.php file. This file contains one line:
$page->display();
This triggers every item that has been added to the page to output its HTML in order. This creates the page.
So Why is this an interesting concept?
There are a few reasons why this concept interests me. Firstly it puts almost every aspect of the layout into the control of the coders, so you can not only create the layout with code, but easily modify it as well.
Taking the above example, converting this from a two column layout to a three column layout is a matter of modifying a couple of lines of code, or using a plugin to alter it before it is output. Similarly, if you need an extra class, or an extra DIV inserted somewhere you can modify the output of the object so that it is produced.
This concept also makes it possible to create a user interface to modify most parts of the layout instead of selecting from one of several pre-designed layouts. While it is true that a small selection of layouts is generally suitable for most users greater control is an attractive concept.
Finally, the object library can be extended to include objects that do not directly mirror HTML structures, for example, an object that outputs microformat based elements or mapping.
It isn't all good, of course.
Firstly, the additional control comes only where there is additional development to provide interfaces for it so by default this leaves, potentially, quite complex code which new users may find difficult to get a handle on.
Secondly, plugin authors are unlikely to specialise on themes that use this concept when everything else is produced in the usual style. This style is also likely to put much of the layout CSS inline, or at the top of the page, which might make it difficult for plugins that aren't written for this style to override it.
Third, all this object processing creates significant overheards. These can be managed with appropriate use of caching but this will never be as efficient as simply including a text file, which is effectively what normal templates do.
This is entirely theoretical, the amount of work involved in putting something like toghether is significant and not something I would do on a whim, but I am interested to know what people think of the idea, or if they know of somewhere that this is already a reality.
1 Comment
The Proposed Cookie Law
November 9th 2009
I've been reading a fair few posts recently about the EUs planned changes to the law relating to storing cookies on user's computers. Most of these posts suggest that the rule is moronic, prohibitive, and illustrates a complete lack of understanding on the part of the law makers. I'm not so sure though.
Now, I'm neither a lawyer, nor an expert in this field, so I can tell you only what it appears to mean to me (I have quoted the relevent part of the proposed amendment below).
As I understand it you will not be alowed to store information, or access information that has been stored, on a user's computer without their explicit consent, with the exception of cases where access to that information is strictly necessary for the provision of services that the user has explicitly requested.
So what are the instances where a web-site owner will want or need to store cookies?
Firstly there are cookies to used to identify the user during their session. If they have registered and logged on, or are using a service such as a shopping cart then I think you could argue that these are needed to perform the service they have requested.
Secondly, there are cookies used to track the user for analytics purposes. I think these are debateable. You could argue that analytical data is needed for the operation of the site that, by visiting, they have requested access to, but I don't think this holds much water really. It may be that the analytics software would have to do what it can using referrer data and IP address information instead.
Finally, you have cookies used to track which advertising a user has previously seen across one, or multiple sites. I don't think it is possible to argue that this is a service that has been requested, so consent would be required.
Are there any I've missed?
It could be that I am missing something here but, actually, I like the idea that I have to consent to being complicit in creating information about my habits and movements for the benefit of third parties. It is, perhaps, a tad hyprocritical of the EU given that the trend among government's is to try and make ISPs track our activities for their own uses, but anything that reduces the flow of information about us is a good thing isn't it? It is the reason why so many virus checkers consider advertising based cookies to be bad and so remove them isn't it?
I will be looking out for more information to find out why this is such a bad idea, but in the meantime I remain unconvinced that it is as incompetent, or ignorantly produced, as some suggest.
There is of course an irony in this post in that I am tracking your movements right now, and using cookies to do it.
The following has been quoted from: Out-Law.com: Proposed changes to cookie laws
Article 5(3) shall be replaced by the following:
Member States shall ensure that the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent, having been provided with clear and comprehensive information, in accordance with Directive 95/46/EC, inter alia about the purposes of the processing. This shall not prevent any technical storage or access for the sole purpose of carrying out the transmission of a communication over an electronic communications network, or as strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service.The Proposed Recital
(66)Third parties may wish to store information on the equipment of a user, or gain access to information already stored, for a number of purposes, ranging from the legitimate (such as certain types of cookies) to those involving unwarranted intrusion into the private sphere (such as spyware or viruses). It is therefore of paramount importance that users be provided with clear and comprehensive information when engaging in any activity which could result in such storage or gaining of access. The methods of providing information and offering the right to refuse should be as user-friendly as possible. Exceptions to the obligation to provide information and offer the right to refuse should be limited to those situations where the technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user. Where it is technically possible and effective, in accordance with the relevant provisions of Directive 95/46/EC, the user's consent to processing may be expressed by using the appropriate settings of a browser or other application. The enforcement of these requirements should be made more effective by way of enhanced powers granted to the relevant national authorities.
1 Comment
How low is too low for WordPress?
October 21st 2009
Jeff has has an interesting question over at wptavern: How low is too low?. He is talking about the barrier for entry when using WordPress and he has a very valid point.
The issue is this: As WordPress becomes closer and closer to a consumer product the user base becomes less and less knowledgable about its workings. This is not dissimilar to the way cars have changed over the years. How many people really know how to fix a modern computerised car? You really need to go a specialist and pay for it.
This is superficially great for the users as they don't need to intervene with the software. Unfortunately when they do, it costs them.
At the moment WordPress still attracts a significant number of enthusiasts who regularly help out but it is good to wonder how long this will last.
I moved on from WordPress for exactly this reason. It wasn't really interesting any more. I found newer, less developed projects, like Habari, more interesting because there was more scope to get in and make a contribution, for that contribution to be noticed, or just to be noticed within the community.
Of course Habari is also developed using much more modern methods. It can be because it was new and didn't have a mass of legacy plugins and users. This, in itself, is much more interesting than playing with the same old code.
Another problem with the low barrier to entry is that the users start much further back. I learned most of my PHP through tinkering with WordPress, but I did already know some, and I had a history with programming. The new crop of users are not only entirely new to programming, the themes are either so comprehensive they can make all the basic changes they want without needing to touch PHP, or so complex they have to reach a much higher level before they can even start.
The current state of theme development, combined with a low barrier for entry, discourages users from learning more about html, css and PHP and that is likely to significant reduce the number of enthusiasts using WordPress.
All of this is of course of little relevence to most users who just want to publish and who, honestly, would probably be served just as well with WordPress.com as .org, but it does have consequences for future development, future plugins, and future themes. Exactly what those consequences are we will have to wait and see.
0 Comments