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').