Console design 1

last modified: 01 June 2015

Introduction

Composite C1 is the perfect developer oriented CMS. And it has a long history of/for supporting all kinds of browser versions. As a result its frontend (console) is lacking some design and modification options that in the current browser eco system, with great script and css support, are fairly easy to implement.
There are a number of steps to be taken before we have a fully skinnable console, so while I'm working on this (epic) 'tour de force' I'll keep you posted on the progress and the steps i've taken thus far.
I will be 'eating my own dog food', i.e. I'll implement it on this (live) version of the CMS, the only viable test scenario.

On a sidenote...

Working my way through the front end system I'm getting the impression that the work to be done is (a little bit...) more complicated than I anticipated. I started with the premiss that all could be solved with script and styles but apparently it cannot.
A lot of the frontend is also generated from the server so replacing controls with simpler ones is not an easy task. Though I think it should be done. We all know where Composite comes from but a lot of the controls are just too verbose for the current capable browser landscape. Simpler html will improve styling capabilities and foremost it will improve performance.
Still going for it though...

Roadmap

The starting point is the current release version (4.3) and I'll try to touch the core system as little as possible. This will make it easier to integrate in the current system - and easier for developers to implement.

What am I about to do (and have already done).

  • Using grunt; configure 'Task Runner Explorer' in Visual Studio
    Working with Sass and Autoprefixer is a breeze with grunt. And with the 'Task Runner Explorer' we can use it within Visual Studio.
  • Convert all styles to sass
    Using sass (with variables and mixins) will make creating an (easy) skin solution far more feasable.
  • Implement AutoPrefixer
    Autoprefixer parses CSS and adds vendor-prefixed CSS properties using the Can I Use database. No more need for post processing from within Composite (see below).
  • Configure Uglify
    Render/bundle top.js and sub.js from the source files (following CompileScripts.xml). With one switch in the grunt file we can optimize/compress the result.
  • Using the latest TinyMCE with the modern theme
    tinymce modern style image This means that we also can remove the, in my opinion, awkward way to configure buttons and classes for the visual editor. The TinyMCE configuration is clear, simple and well documented and there's no difference in editing a xml file or a javascript file.
  • Combining all styles into one stylesheet
    Combine the skin, styles and the console root stylesheets (app, default, postback, top, unsecure, updated and welcome) into one.
  • Refactor all styles
    The current styles can be optimized by combining and nesting relevant selectors. Using the pattern lab system will result in easier to maintain styles and skins.
  • Phase out the CssRequestHandler, StyleCompiler and StyleLoader classes.
    In these classes the stylesheet(s) are parsed for browser specific settings that are perfectly applicable from the styleheets themselves, especially with the use of Autoprefixer. It also contains a developmode switch that we no longer need as our build system will output source maps which give us full access to all source files from the browser developer tools.
    The same applies to the JsRequestHandler.
  • Replace the fieldgroup with a standard fieldset (with legend)
    This will be something of a challenge as the field group is used from the backend to render dynamic forms - maybe the core team can be of help here. What I can (and will) do however is replace the 'ui|fieldgroup' html elements with a standard fieldset and legend.
  • Replace the fieldhelp buttons with something that's easier to style
    For this I'm thinking about 'Hint.css' a library that I've used before and quite like, especially as it is pure css based.
  • Removing the table based control building, i.e. remove the table.matrix classes.
    This is, in my opinion, the most ancient left-over from former browser support and when removed will improve render speed a lot. It's almost solely used for rounded borders and requires a lot of html and images which can be solved by css with support for all browser that the console is to support.
  • Refactor the icon system.
    Every icon is an image - each requiring a connection - that we can solve by using an icon font or base64 embedding. That also will improve styling (and scaling) options.

Refactor styles

Before digging in we need to set some ground rules:

  • We prepare for responsiveness, that means using ems for sizes that can be related to font settings
  • Colors should be sass variables to prepare for skinning
  • Images should be avoided; use css, an icon font or embed them as base64 when that fits. WebEssentials in VS gives us hints about that.
  • Do not use prefixed properties, Autoprefixer should solve that

When refactoring the styles I started at the beginning (duh), i.e. the start page of the console (default.aspx, develop.aspx and/or top.aspx).
First I removed the reference to default.css.aspx as those styles are in our major stylesheet and added that stylesheet with a relative path. We need relative paths as the styles are currently littered with '${root}', '${folder}' and '${skin}' parameters that need parsing somehow. As we do want to remove the CssRequestHandler from the equation we need to structure the styles in such a way that these references are not needed and the parent Composite folder can be anywhere.

Refactoring the styles for these pages are basically following the structure of the pages and adding the selectors accordingly. Some styles in the current structure would reflect on the cascading styles for the entire console so we need to keep that in mind and try to use as much of the id's used.
The startpages (including the login box) are using a backdrop placeholder with an image for the box. This is the actual first image we are going to replace with styles. We will be needing an image though as we want the logo of Composite C1 there. We will be using the composite.png from the images folder (base64) and ideally it needs to be converted to svg so we can use the same image for every size.
The default page also contains a 'backdrop' placeholder that's not needed. Also, when you're using html that is looking like a button and behaving like a button, you better use the button element.
The data input binding adds a 'ui|box' container around an input, i could not find out where it's used for other than for style so I removed it (DataInputBinding.js). If somebody knows otherwise please let me know. So far I have found no errors on the missing box container.

So this is the current result for the start (root) pages at 100%:

Waterfall

And did it amount to something better, i.e. was there any improvement?
Well, see for yourself...below are two simple waterfall diagrams from the Chrome development tools. Both clean rendered, no cache, just the login screen.
Just look at the number of requests ;), first the rendering from a clean Composite version, second this (improved) version. This version is somewhat bigger in size as I have some extra scripts in there.


published on: 26 May 2015