HTML Logo by World Wide Web Consortium (www.w3.org). Click to learn more about our commitment to accessibility and standards.

Moving forward with Composr

ocPortal has been relaunched as Composr CMS, which is now in beta. ocPortal 9 will be superseded by Composr 10.

Head over to compo.sr for our new site, and to our migration roadmap. Existing ocPortal member accounts have been mirrored.


ocPortal 3, Panels

ocPortal 3, Panels Today is the first day of ocPortal 3 development - we've made a roadmap, and designed all the new features, and now it's time to code/draw it all.

As we've said in our news post, this new version is all about user friendliness - we want people to be able to just dive into making sophisticated ocPortal websites, without having to read the documentation. The last thing we want to do is to 'dum down' the product, so we're doing this by correcting design mistakes, packing away functionality so that the only people exposed to it are the ones who'd want to use it, and creating interfaces that imply the concepts themselves via visual aids (a picture speaks a thousand works, plus the picture is the interface… so it's win win).

The first thing on the table this morning was correction of a design problem at the centre of ocPortal - the menu pages. This part of ocPortal was designed a long time before ocPortal even existed, and was never at that time intended to be flexible or even to be understood by the user; as a developer, usability design problems are often invisible, because we aren't ourselves capable of going through the same processes that our users have (due to our existing understanding of the system, and our more technical thought process). Thanks to our users, we've become aware of the design problem, and now it is a very simple matter for us to correct it.

So what's the problem? Well actually there are three problems:
  • The word 'menu' has been used in two different ways since 2, and to an even greater extent since 2.5. There are "menus" (collections of links) and "menus" (pages that fit around the site, that may themselves contain the other kind of menu). Whilst this isn't particularly complex once the relationship 'sets in', it is very confusing at first.
  • ocPortal assumes that there are no more than 4 menu pages, and that each may be identified as 'left', 'right', 'top' or 'bottom'. We haven't actually come across a site that doesn't fit this pattern, but we always try and make sure ocPortal doesn't make these kind of assumptions about how a site is layed out.
  • Menu pages can't easily be reused on different zones. The user could add redirect pages, but that's not easy enough in our opinion.

So today I've solved this… 'menu pages' are now 'panel pages'. For example, the page menu_left in current versions of ocPortal, would now be panel_left. We prefer the term 'panel', because it seems more appropriate regardless of the design problem.

To fix the second and third problems, users now have complete control over what panels are used. Any template can now load up a panel, using any name they wish - and they can also specify what zone it is to be loaded from. Using tempcode directives, panels could be arranged in different ways in different zones. This simple change really adds flexibility to the system.

I think that many readers of this blog won't quite understand what I've explained there - but the aim with 3.0 is that these kind of technical details won't need to be understood. Only those who need the most customised sites need to understand the most complex terms (such as 'tempcode directive').

View all
Edited