Backend design

Hello there,

Just out of curiosity does anyone know who designs the backend of Contao? Is it Leo himself?

Cheers,
Robert & Ingemann

You mean the functionality or the look (styles classes etc)?

I mean the look ...

I'm pretty sure its Leo, although I'm sure you can change it by altering the css - i have also seen (but not used) a module that changes the backend radically, both in look and functionality.
There may even be backend themes available, but I'm not sure.
(i'm not much help really - i should have just shut up! ;) )

Alright ... I know its possible to change the look and feel of the backend, but I was just wondering who was designing the default backend theme. And also, is this in someway also an open source kind of thing where you can share and discuss new ideas/designs of certain elements etc. like the functionality is discussed on GitHub. Maybe a strange question - I know - but it seems like the design has very little focus compared to the functionality - where I think it should go more hand in hand ... isch ... :)

It's LGPL and initially designed by Leo, yes.

I don't know why but I think the back end is one of the KEY features that convince people of using Contao. So whenever you want to change something, don't forget about that fact (it is a fact, I can name you hundreds of people if you want to :) )

Yeah, that was of the things I was definitely surprised about at CeBIT / CMSgarden this year: while I personally think of the backed as one of the weaker points in Contao (being some sort of old school style), most people told me that they adore Contao for its clean and well structured back end.

Anyway ...

It is clean and well structured. But also consistent throughout both the core and extensions. This differs from Wordpress and Joomla!, where any developer may design forms and lists as one pleases. Contao offers the option to change input elements, but it is harder to do.

I would like some more graphical improvements, but then most people would have to agree it is an improvement. What about larger checkboxes (or make it Yes/No options iOS stylish) so that the backend can be better accessed through a telephone. Or icons for dropdown lists so users recognize the options they want. (This has been in user interfaces for ages because it is a good idea). I don't want to make the backend a carnival of images and large buttons, nor a candyland alike windows XP, but it may positively affect usability?

@lucina; I changed the header of the backend to reflect our company style. With little changes the backend looks quite different. Visually customers get less confused because the header now clearly is different and only the menu and content area are looked at. Many customers did not see top right links in the main area because the header just above contains links as well. With a changed header that hasn't happened yet...

Sounds interesting @ Ruud, could you provide a screenshot for me?

BTW, next thing to come for me should be a backend with more contrast. We discussed that a couple of weeks ago in our usability workgroup since we think that Contao should provide better readability for users with visual imparments. For some people the difference between light green and gray is hard to tell.

I attached a screenshot. The difference isn't that spectacular, but I seem to experience less searching for the action links since using the darker header (perhaps because it is in the header color?). For Contao a different design will probably be chosen. While at the subject I have some suggestions/questions that I think you are the right person for to ask:

1. Better contrast would also be good for me; my laptop switches to some lower contrast display mode when on battery and the light grays are no longer visible. So that also has my vote.[/*:m:24j1ngel]
2. What do you think about larger inputs for mobile? More and more is done using mobile devices and I find myself on the phone to customers more often then before and immediately changing what they ask for on [/*:m:24j1ngel]
3. I like to use icons in some of the inputs (for example form field type so the correct field type is clear to less experienced users). Though using icons for input creates an image consistency problem in extensions, so I would opt to making the sources available so developers can create similar icons (or not do this right now at all)[/*:m:24j1ngel]
4. Why is the backend still in the old TYPOlight color green?[/*:m:24j1ngel]
5. When selecting the location for a new item the arrows are not always the rightmost elements like they always used to be. Now the drag and drop icon is. During a paste operation the drag and drop is less important. Don't you agree the arrows should always be the rightmost?[/*:m:24j1ngel]
6. The drag and drop icon looks a lot like the increasingly popular menu button (3 dots/lines) for mobile devices. Might become confusing?[/*:m:24j1ngel]
7. Is there still no change planned for the separated page and article structure? It is a hard thing to present in a different way, I know. The only solution to the problem I've ever seen came from the extension extcontao https://contao.org/files/repository/ext ... icture.jpg (but the extension makes the entire system look more complicated)[/*:m:24j1ngel]

Thanks a lot for sharing your thoughts, Ruud. I think, getting a high contrast backend will only be a matter of time, and after playing around a little bit with your header I personally think that it would be wise to make the functional zones appear more clearly.

I'm not sure about the inputs since I think that we should use native inputs whenever possible.

Regarding the icons I'm still a huge fan of some sort of icon font, making a full scalable backend possible. Otherwise, every developer would have to create a full icon set in several scales. I don't think that this will happen for all extensions, so vectors are my favourite on this topic.

On the icons; it doesn't really matter what system you go for. As soon as you start using images you will not have an image for everything. (Unless you have your own design department designing for every new feature) That's why I agree you should be careful when starting to use icons, but to assist in things like input types it can be done because no matter what there is a limited amount of input types that you already know of.

There is still the issue of perhaps needing icons in several sizes. But is that already needed anywhere? Would that become an issue for an icon-input field?