We are right in the middle of rolling out Responsive Design in Affino and this post outlines many of the key decisions we have made, and why.
When researching approaches to implementing Responsive Design in Affino, we have been looking at existing tools such as Adobe Reflow and Webflow.
They have taken two opposite lines of approach. Adobe Reflow allows you to manipulate everything to the nth degree but makes the process very manual. It displays a grid, but it’s purely for visual guide purposes, nothing snaps to it.
Webflow has a much more restricted approach, as do all fixed grid systems, in that you have 4 fixed breakpoints and things essentially can be set to be stacked or side-by side. There is a very rigid approach to the grid implementation but it does make assembling purely designed pages a fast and efficient process.
Affino has different challenges, firstly Affino is an application suite which allows layout and styling, as opposed to a purely static framework. It has content and media libraries as well as dozens of functioning applications that can be styled but have to work in certain ways to be effective.
Affino also works with millions of pages, these aren’t designed individually, instead we have re-usable page designs (Skins) which work across many different functional and content pages.
In practice we’re going to be keeping all the key productive features of Affino 7, whilst making them Responsive and lightweight. We’re also going to be providing much improved interfaces for designing and laying out pages in Affino.
Key Principles for Affino Responsive Design:
Affino will still have Design Objects and Design Elements as the basis for designing your pages. It means you will create your page elements individually and then re-use them throughout your page designs, e.g. button bars, header, footer, navigation panels etc. These are then assembled to create your page designs.
It means a bit more work for the first page design, but a great deal less for all subsequent ones.
Breakpoints define where one page layout, e.g. PC changes to another, e.g. Tablet. These things change over time, for examples mobile phones are getting bigger, whilst tablets are increasing resolution.
Affino will therefore allow you to have Breakpoint Profiles, but these are universal to all the Design Objects used in a Skin. That way all the changes in page layout will be triggered at the same specific points so as to be manageable.
You can have up to 10 different Breakpoints on your page design. Each breakpoint allows you to change the element widths and whether or not an element is displayed. Update - also height, margin, padding and alignment, even the background image.
This is much more than the conventional 3 Breakpoints, but not too many to become un-manageable. In means you can cater for landscape and portrait layouts for multiple mobile / phablet / tablet and PC combinations.
We’ve spent a long time looking at Grid Systems and in practice they do not apply for the vast majority of the real world implementation scenarios we foresee. Where Grid Systems are useful are in limited-capability systems.
There are solid productivity benefits when designing a page layout, and when working with single-page designs. However there are also very significant limitations, especially when working with dynamic pages where elements can be displayed or hidden dynamically based on content / user security access.
To allow the dynamic display of content we can’t impose a fixed, rigid grid since in any scenario you might design it twice or three times as many elements as would fit on the grid, but only 1/2 or 1/3 would be displayed at a time.
For that reason we’ll display a grid overlay, but it will be purely for layout alignment and preview purposes and will have no functionality.
Almost all fixed or percentage based grid systems also have the concept of ’folding’, i.e. from 16 cols to 8 cols to 4 cols then 2. Affino allows you to specify on each element whether or not it is displayed at any given breakpoint so offers far more flexibility than this rather limited approach.
Affino Design Elements will be in containers, essentially Divs. These can have their dimensional properties adjusted easily e.g. for padding and margin (all direction), percentage width with optional max and min widths, or even with a fixed width.
Affino will automatically create all the structural coding so you don’t have to worry about it, so for example drag a cell into a new row and Affino creates all the coding for that for you.
As a matter of principle it will be far easier to customise CSS because the overall page structure will be much simpler, with no structural Table code at all.
Each Design Element Container can be moved in the new Skins. This means that when writing custom CSS you no longer have to worry about Div IDs changing.
Nothing specifically to do with design, but the same time all about design, is that the new Object Designer will have multi-level Undo and Redo. This will give you plenty of opportunity to experiment. It will also be our most solid Object Designer yet.
Since we’re not going to be using a static framework, Affino won’t have gutters, however these can easily be created when required simply by setting margins on the containers. These can be done either using pixels or Ems, and will be functionally the same.
So if you wanted to create a 4 col structure you could easily have 4 Containers with appropriate margins in between.
We’re working hard to give the best preview possible so you can instantly see what the finished live page looks like instantly on any change made in the object designer. This is still a work in progress.
Broadly speaking though you will have a design screen where you can see the design you’re working on, with all live content along with the embedded design objects. You can then drill down and back up as before.
We’ve already got code compression in place, and the shift to full CSS will mean much lighter code. It will also allow for much simpler customisation.
The move to more pure CSS for styling and layout also means we’ll be evolving our interfaces to work more purely with the underlying CSS, so that styling properties in Affino increasingly will simply be CSS properties which can be manipulated easily without having to write or maintain code.
Affino 7.5 is a big leap forward in terms of Affino’s front end design and coding. It is over 10 years since we defined the existing design and layout framework, and although there have been hundreds of improvements since, the fundamentals have remained much the same.
It is quite literally all change now. Every line of display code is being reworked, and we’re setting a baseline for the next 10 years. It means we’re making decisions based on how the web will evolve over that period. One fundamental decision is that we will be migrating to JQuery 2.x and TinyMCE 4.x. This means that Affino will no longer be 100% compatible with older browsers, rather it is focused on working with the most recent generations of PC browsers, as well as Mobile and Tablet browsers.
This means Affino will no longer support Internet Explorer 8, 7 or earlier fully. In terms of market share these are now approximately 10% of the market, and steadily declining. They’re a much smaller part of the consumer market. In practice we aim to support the latest 2 generations of all the major browsers, and with the release of IE 11 imminent, these browsers are already out of scope for Affino support.
You will have ample time to move to the new way of designing in Affino, up to 6 months. Even after the transition to the new Design Centre you will have the option of running the old Skins on your existing pages for longer, however new Channels will require you to use new Responsive Skins.
There will be a Design Transition screen which lets you take existing Design Styles, Design Objects, Form Styles etc. and allows you to transition them to being Responsive.
All of this is still somewhat subject to change as we work through the new Design interfaces, however expect things to be 90% as outlined above. We’ll keep you posted with more developments as they occur.