Developer forum

Hi Adrian

The idea is that you create 2 row definitions - and not 2 layouts for the same row definition. If we also added layouts the user would get 2 options - a bit messy and confusing.

Row definitions can have an item type - and you can add as many settings as you want. But I would recommend not to do it - and provide additional row definitions instead - this way the user will not be given a lot of options they do not understand. 

Rows and paragraphs are considered content in Swift 2 - we have very specifically made this approach to keep the editing experience for regular editors more intuitive - and not floting the UI with css and html lingo that only frontend developers understand.

BR Nicolai

Hi Nicolai,

If I duplicate the row definitions, it may become more confusing for the user if they need to choose from 3-4 row definitions for the same number of columns. Not to mention that you cannot change your mind after selecting a row. The option of having "selectable" layouts provides more flexibility to choose a (say) 2-column row and then decide which layout works best.
I can see your point about simplifying the options in the UI, but we've noticed that the alternative is complicating things a lot more since the CSS rules would have to be applied based on the ID of the element instead of a reusable class.
And I don't see any reason why adding 2 more options to the list of supported features would complicate the interface more than it is right now.
If it's possible to make the row features extendable, we can handle the consequences.
I am aware that I can use whatever ItemType I want for the rows, but I was hoping to see some of these features as standard instead of a customization.
If you decide this is not relevant for your target audience, we will handle it with ItemTypes properties.

Thank you,

Adrian

You can change your mind - and change the row settings including number of columns at any given time - so you can switch from a 2 column to a 3 column row after the content was created.

I understand there are different approaches and opinions - and as I said, you can add as many options to row items you want - including a layout selector if you want - but currently it will not be part of Swift - Swift 1 was 1000s of checkboxes - Swift 2 is not - you have to do CSS and templates for the last mile. Also You do not need a lot of CSS. You need to think it differently - avoid complexity at all costs - focus on content and business and relatively small branding tricks you can sprinkle with CSS.

It is a matter of how to go about things - we have had many implementations (e.g. Rapido and Swift 1) with 1000s of settings and it always ends up being impossible for editors and maintainers over time. This time we have chosen simplicity and if you plan few strong content components and scenarios, content can easily be put into a that content framework and do its job of selliing something. You can also persuade a customer into it if you explain the consequence of designing all pages from scratch using 100s of settings and they have to call you to get things changed. I have yet to meet a customer that prefers complexity and one offs over simplicity and efficiency.

I do not see things like you see it - "why adding 2 more options" would complicate things. It will - the rows already have plenty of settings. It will add an exponential amount of potential outputs of a template and it will significantly increase complexity and potential bugs. And then there will be requests for 2 html options here and there and it explodes into something unmanagable. Again. And I guarentee that none of our customers would sell more with those options.

BR Nicolai

Hi Nicolai,

I believe that we are on the same page for most of the comments.
Ultimately, it comes down to deciding whether to adopt a developer-first or an editor-first approach when customizing design.
I am inclined towards the first, but I am still not confident that the current setup is enough.
For now, I will try to explore the current options further and see if I can find any solid cases for the topic.
We can close the subject. For now :)

Thank you very much,

Adrian

Hi Adrian

I agree. Content is editor first and also described here as a base for Swift 2: https://doc.dynamicweb.dev/swift/getting-started/s1-vs-s2.html

I am happy to get on a call and discuss specific implementations - and explore how we to address a specific design implementation.

We are currently writing a new and very elaborate guide on how to move the look and feel from a design - and discussing this compared to the 'pixel-perfect' approach which will require coding.