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.


How we decide what to make in a new version

How we decide what to make in a new version When we plan to make a new version of ocPortal (other than a patch release), we have to decide a few things (in roughly this order):
  • what the overarching mission for it is.
  • how big it will be.
  • the schedule for making it.
  • what will go into it.

These are all important things, and whilst subject to change, they do have to stay fairly fixed if we are to achieve our goals, and hopefully, obtain maximum satisfaction for the majority of current/future users.

There are always things that make us change our plans though. For example 'Blogging' became very popular last year, which meant that we had to change some focus and add some features, in order to avoid alienating a userbase who was now thinking in terms of 'blogs' and 'blogosphere' instead of 'website news system' and 'web links'. These changes had to be rushed through, deep into the 2.5 development cycle at a late stage, as things had changed over literally a few weeks.

A few reasons for having to rush in new features include:
  • users making us aware of a problem we were not previously aware of
  • online changes (such as the blogging example above)
  • 'eureka' features that are so good it's worth changing plans to include

Still, even though features have to be added into a version that we couldn't plan for (and thus others dropped as a consequence of meeting a schedule), the version mission never changes.
So far each new version of ocPortal had such a mission:
  • Version 2.0 was about opening up ocPortal to make it more customisable
  • Version 2.1 was about improving stability
  • Version 2.5 was about making it run standalone (with our own forum), as well as new documentation
  • Version 3.0 was about usability

We think up new features by constantly looking at the web 'climate', problems people have, other software, user suggestions, and by thinking about cool new things ourselves. All our ideas get discussed, to refine them, extend them, or chuck them out if they're junk or inappropriate. We then organise these ideas and cherry pick enough of them to fill up our schedule. Features that get picked are:
  • the most important ones (the ones that serve the needs of most our users, best)
  • ones that best match the mission of the next version
  • little ones that are easy
Features that risk disrupting current functionality, causing lots of bugs, tend to get saved for the biggest new versions. This way we don't need to re-test everything (which takes literally months of man-hours) for every new version. We also try to avoid things that could cause problems, like making features that would add a lot of new language strings and hence make translation harder.

This post is partially for people's interest, but also I felt it was important to explain our process because recently we've been getting requests from a few people to add functionality to ocPortal that definitely doesn't belong there. The following commonly requested features do not belong in ocPortal, but should rather be done as addons:
  • Dating features
  • Arcade features
  • Auction features
The reasons are numerous, including:
  • We have to make sure we don't add features that will detract from the usability of the product. If we cram inappropriate features in, the system will become an unnavigatable mess. Screens would become filled with spurious details that require understanding of dozens of irrelevant subsystems, and to customise would be very difficult. Allowing things to be disabled only goes so far, as there are any number of combinations people might want things to be disabled in, and it's impossible to create a workable system like that due to system interdependencies and a lack of a common design base.
  • We have to avoid adding features that make assumptions and hence reduce ocPortal's applicability to people.
  • We write features that appeal to enough people such that they add value to ocPortal, and hence encourage more people to use ocPortal and hence prompt more registrations. This works out nicely - it reinforces our need to create a high quality and well-designed system, and avoid implementing spurious functionality.

Addons should either be done by contracting ocProducts to do it, paying someone else to do it, or – what I really want to encourage is addon creation for ocPortal in an Open Source community fashion. We've literally spent weeks working to provide resources and a framework for third-party extension of ocPortal, and we've licenced ocPortal as Open Source to allow it. We want to empower, so that nobody needs to pay us to do custom development. I would love to see some people release an ocPortal arcade addon!

We are already thinking about the next version of ocPortal. We've a good idea what the mission will be, and we have an archive of hundreds of other features designed that we could choose to write into the release. As we're currently focusing on improving our ocPortal.com community, development has not yet begun. Right now I want to reach the 'critical mass' our community needs. You can help with that! If you're not getting involved already, please do, and get your friends involved to - then everyone will collectively benefit more than if you did no action. I'm intending to write some new addon-construction tutorials and support on-forum Q&A for them.

View all

Trackbacks

There have been no trackbacks yet