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.


Giving design feedback

The ocPortal community occasionally sees feedback that we should improve the design of the default theme. Usually, however, this feedback is given in very vague terms and is hard to act on. This tutorial will explain how to give design feedback in a clear constructive way, and also give some background on the design constraints that we work within to make ocPortal.

What not to do

Here's how not to give feedback:

ocPortal's design looks dated.

ocPortal doesn't look as good as Wordpress.

ocPortal doesn't look attractive.

The problem with this kind of feedback is that it very much reflects the perspective of the person giving the feedback, yet the details behind that perspective are entirely unknown to those reading the feedback and wanting to act on it. The person behind the feedback is usually sincere, but doesn't realise it doesn't help us move towards meeting his/her needs. It's not immediately obvious, but there is a lot more behind something looking "good" or "bad", and it's very much about what you're seeing in the details. In fact, someone looking at a design can feel it look "bad" without knowing why, and only on contemplation does it become clear that it is due to a small number of things in the details being slightly wrong. This is how the brain works, it makes lots of subconscious evaluations on your behalf.

It takes a great deal of self-control for developers to not see very vague negative feedback as something from a lazy "style over substance" person who wants everything delivered on a plate for them. Fortunately, with just a little bit of work you can ensure that developers will not be under that false impression, that developers will be happy in their work, and give some actionable feedback that will have a positive effect on the future of ocPortal as a product.

Feedback types, in detail

In this section we'll analyse each of the above positions. Much of this will read as if it is a rebuttal, but that's not our true aim here. By explaining why things are as they are, and the process we work within, we can then explain how real design issues (which we won't deny) can be fed back to us. It also gives you the insight required to challenge our processes or assumptions, should you feel we're doing things wrong.

ocPortal's design looks dated.

Often this largely is to do with how blocks look. A lot of modern designs will try and minimise the number of borders and separate shaded areas, and instead use white-space and more subtle dividing lines to lay stuff out. ocPortal may be thought of as "boxy".

ocPortal has a modular design because it is not a hard-coded system. ocPortal is constructed so that you may make many different kinds of website with it, and have full control of the layout. Therefore you construct a layout by putting together a number of components ("blocks" in ocPortal jargon). By default these blocks will look self-contained, because it's the best way we can make things work out of the box, without you needing to be an expert designer. Things are also quite close together by default because we need to support large numbers of features displaying at once, which is a very common configuration on community websites.

We provide a Comcode feature to "de-boxify" the appearance of blocks which helps a great deal. Designers can fully customise the appearance and we fully embrace the design process.

So, largely this feedback comes down to the fact that if you're creating a website you probably will want to do some amount of design to get things look great for your site. Design is a very human process. It's not truly a situation of ocPortal being dated, it's more of a situation that modern design quality really is driven by expert designers spending a lot of time and energy to perfect the design for individual websites. Because ocPortal is not a tool to clone out a standardised kind of website, great design cannot be fully automated.

ocPortal doesn't look as good as Wordpress.

The default Wordpress look is pretty dry and basic, so chances are this feedback more relates to comparing a Wordpress theme to the default ocPortal look. Or, considering the ocPortal Theme Wizard as comparable to installing a theme for Wordpress (it isn't – the Theme Wizard creates a colour scheme, which is pretty different). People do release themes for ocPortal, and you can get one made for you also. There have been many themes released for previous ocPortal versions, and they're not always upgraded, but if you find one you like you may be able to arrange with the author to have it tuned up to your needs.

It is true that you may need to invest more in getting an ocPortal theme than a Wordpress theme, assuming you don't want a website as simple as a Wordpress website. This is because ocPortal solves more sophisticated requirements; themes are going to require more work because there is a lot more within an ocPortal website to design against.

ocPortal doesn't look attractive.

Usually this is more of an issue of a specific configuration of ocPortal looking a mess for some reason, or some kind of design mistake(s) in the default theme. In other words, it's not ocPortal as such, it is something specific – and thus, something we can resolve. This is where constructive criticism is useful.

How to give constructive criticism

This is best shown by example. Recently (at the time of writing) we got some very vague feedback, mentioned in passing in our chat room. It was not mentioned, but we were able to guess that this related to some display issues on the ocPortal demo, and analysis (read: second guessing) led to some bug reports, that we could then resolve:

This is exactly what we would like people to directly. Isolate specific issues, then report them to us. We can then expedite the fixing of such issues very easily.

Beyond bug fixing

The spirit of the above section is much of one of treating design issues as bugs. That takes us a long way, but it is not the whole story. An overall design vision, and a sense of style/taste, is also a big part of the equation.

We need designers to get on board. You could actually redesign ocPortal interfaces yourself (e.g. in Photoshop) and submit them to the tracker for implementation by a developer as HTML/CSS (or make direct patches if you are so inclined). If you're a designer, you could certainly show non-designers how things could look a lot better.

People sometimes suggest that we take on designers to continuously iterate on ocPortal designs, but it is a lot easier said than done. Finding designers who truly understand how to design for CMSs (described in our "Designer Themes" tutorial), for user interfaces, for a wide range of considerations and constraints, and to truly be passionate about ocPortal as a system that serves non-designers, is difficult. Most designers design for specific contexts, which is in stark contrast to how software features are developed. 99 times out of 100, any designer we take on is going to have far too much a limited perspective to truly take the ocPortal design up a notch.

So, if you're a designer reading this, there's a very good chance you could make an excellent contribution to the project!

Further product design reflection

This is not directly related to the process of reporting design issues, but may result in further insight into the ocPortal design process.

Fashion: there is a saying that "good design is timeless". This is largely true, but it is of course undeniable that:
  • there are trends;
  • the context we work within changes;
  • the nature of how products behave or are used changes;
  • improved technology allows better results.
We are unlikely to chase fashions with ocPortal, i.e. we will try and make the design as timeless as possible. To that end, the concept of it being 'dated' from a fashion point of view would likely be a null one. If your particular website is chasing fashion trends, you should invest in it, but ocPortal isn't likely to be redesigned only for trends, because the cost/disruption to do so would be very high compared to the benefit. Most really good designers understand that design is a lot more about solving problems, learning the best approaches, and optimisation, than it is at getting the latest look. However, what people think of as fashion trends, quite often are things we could treat more objectively, and therefore tackle within ocPortal's existing design framework without having to keep throwing everything out. For example, once curved borders were renderable by web browsers, we updated ocPortal to use them in many more places.

Modularity: This is discussed above, under "Feedback types, in detail"

Generality: ocPortal's default design has to be fairly conservative, suited for many different kinds of website. Design elements on a property retail website, may also be used on a community website, and a small business website.

Feature-density: ocPortal sites are often feature-filled. This means the default theme is unlikely to have much in common with very minimalistic designs, such as those on a portfolio website.

Back-compatibility: We have to avoid breaking people's themes too much across releases. We therefore have to choose compatibility break-points carefully.

Browser-compatibility: We have to make ocPortal work across a range of web browsers, not just Webkit.

Low-weight: Often designers working on custom websites will pick a lot of the very latest design frameworks and Javascript libraries. However, with ocPortal we have to support a great number of features, without pulling in dependencies for them all. We can't have lots of different libraries with overlapping functionality, and different coding styles – ocPortal would suffer major performance problems, but also become a nightmare to design themes for. In recent years there has been an incredible churn in front-end libraries – what is hot one year, is outdated the next. It's very important that we isolate ocPortal from all this and try and make the default theme simple, consistent, and performant.

Opinion: It has to be noted that design is very personal, and not everyone is going to agree on what is good design. Different people have different taste.

Context: Something may look great in one context, but it may look messy in others. For example, a design element may look good with 10 words of text, but terrible with 1 word of text or with 30 words of text. A block may look great in a panel, but poorly spaced on a page, and not line up correctly in a page column. We will try and make things look good in all situations within ocPortal where we can, and make things adapt automatically, but it is just worth noting that people often don't realise that often nobody has seen things the way you are seeing them before, and this can be a very common cause for things looking bad. What you are doing on your own site will usually feel natural to you, but it's surprising just how many different kinds of visual configuration ocPortal can have and how much that can make a difference to how good things may look.

Pace of change: The state of the art in web design changes very quickly. Be aware that ocPortal will have release cycles, and that means we cannot always be on the cutting edge in the default theme.

Scope: ocPortal is a huge system, so not every interface will have received the highest level of design yet. This is a great area to give feedback in.

Conclusion

Things can always be improved.

Feedback. Tell us what looks wrong.
Feedback. Show us how you think things could look better.
Feedback. Be as specific, detailed, and clear as possible.

Feedback feedback feedback feedback.

There are no pages beneath this page

There are no posts yet

CEDI change-log Post