📣 It's time for an improved live app!

[Jessie]

Now that the dust has settled after the release of our new Builder, we’ve started shifting resources to modernizing our live app.

This work has officially begun with the recent release of our updated table design options. You can now control:

• The format, using a clean design for tables by removing borders.
• Optional row striping and hovering.
• The spacing and size of table rows.

And we’re just getting started! Some examples of future updates include:

• The ability to create a default style for links throughout your app.
• More control over the style of your app header, and a new static footer element.
• Updated elements with modern libraries such as our date picker and file uploader.

This messaging is to share our initial plans for this body of work and open the floor for feedback on the approach.

So what’s our goal for Live App improvements?

Improving the design and functionality of the live app has been in our plans for a while now. We’ve seen many of you create beautiful design solutions utilizing custom code, and we’ve collected feedback on all of the features and improvements you want to see out of the box. There’s no question that there is ample value in creating a better live app user experience.

We’re grouping these improvements into three main goals:

1. Improve the overall look and feel, following modern design and accessibility best practices.
2. Expand the options to update the design of the live app without code.
3. Add new functionality to the live app, including new views, fields, and more.

While we’re excited to get started on this work, you won’t have to wait for one big release - expect to see faster iterations with new features.

Our commitment to handling updates with care

We know how important your apps are to running your businesses, organizations, and communities. This is why any upgrades to our live app design and markup have to be done very carefully. There are a few key reasons for this:

Change isn’t always well received.

We understand that many of you have users who are very familiar with your apps and may not appreciate any design changes, even if they are obvious improvements.

You may have invested considerable resources into customizing your app

And these customizations may depend on the actual HTML and CSS that the live apps generate.

Many of the improvements we want to make will require breaking changes,

Meaning the HTML and CSS will have to change. This could break any customization that relies on that code being exactly how it currently is, and we understand that accommodating these breaking changes could be extremely painful.

All of these considerations are being factored in as we plan for what’s next.

Here’s our initial plan for improvements

In order to reduce the impact of breaking changes, the following is our current plan for releasing improvements:

Focus on non-breaking changes first

We’ll prioritize any upgrade we can make that will not require a breaking change since these will be the least disruptive.

These will likely be style updates that add CSS classes. There will be opportunities for new functionality, like a custom “footer” element, where static information about your app can live.

Make non-controversial breaking changes

Certain improvements will be worth making even if they require breaking changes. This would require the right trade-off where the functional improvement is high and the breaking change is very low.

For example, we plan to update the file upload input to allow drag-and-drop. This is a popular request that most users would be eager to have, even if it broke some minor customization.

Introduce a new theme for breaking changes

We would then start a new theme for any upgrades that would require breaking changes.

We want to make some major changes that will require completely different HTML and CSS. Something as simple as upgrading our calendar and report views to leverage modern libraries will require breaking changes. There are countless design improvements that are currently blocked until we can update the code, like using better name-spacing for CSS classes to avoid any conflicts in embedded apps.

Because these changes will be more dramatic, we believe it makes sense to move these to a new theme so each customer can choose if they want to accept these breaking changes or not.

Our priority is transparency and communication

We know the key to successfully implementing these improvements will be excellent communication. With that in mind, here are some of the processes we’re working on to ensure you can best prepare to adapt to any live app releases.

We want to provide a source of truth for upcoming releases, ensuring that you:

• Are given the opportunity to weigh in on features when they are being planned.
• Can subscribe to and be notified about specific topics that are relevant to you and your apps.
• Have ample time to prepare for breaking changes.
• Easily view the history of these product updates, expanding on our release notes which currently comprise mostly of bug fixes.

We want your feedback

A big reason for this message is to help you understand our initial plan so we can hear your feedback. Please comment here, sharing any feedback or concerns.

• What is the best way we can support you in understanding and adapting to upcoming changes to the live app?
• What are your concerns related to breaking changes and repairing them in your customized apps?
• Are you excited about modernizing the live app? We sure are!

Lastly, thank you as always, for investing your time and energy into building with Knack. We’re so lucky to have a great community and look forward to working and planning more openly, with your best interests in mind.

[CarlHolmes]

Very interesting reading and exciting news. It’s been a long journey to this point. I first heard of the new builder summer of 2018 at Knackcon London. I can only imagine how stressful and exhausting it has been for the whole Knack team, I’m so glad you stuck with it👏

I’ve always tried to keep code use to a minimum, given that it is a no/low code platform and I’m not a coder

I’m quite comfortable that there may be some bits that stop working. However, I’m sure there will be some very concerned people that have thousands of lines of code in their apps.
The approach seems to make sense and sometimes you have to demolish to build better.

If there is an opportunity to allow beta testing on some features before a roll out that may help.
I’m thinking of the hover over feature as this is useless without the ability to change the colour, it’s almost invisible. I just tried it again and put the CSS back

Exciting that we may get some customisation of buttons without having to add CSS

[Roger]

Thank you for this update Jessie - in the main it is great news.

I suspect there will be many users (including myself) who have massive amounts of customisation in both CSS and Java. Much of which is used to dress up the current outputs.

For me, of critical importance / concern regarding “breaking apps” would be:

Sensible notification and implementation timescales for proposed changes and what you expect to break and the likely changes it will create.

To keep existing apps on the old theme forever? I have apps that are just happy as they are, usually just a minor tweak or new page on occasion and really would not benefit from massive change (nevermind the hours of coding to correct). I seem to recall last time the theme was changed we were ultimately forced into the new theme.

It would be ideal to allow us to sandbox during the updating period.

As Carl has suggested, I will also happily offer an app for Beta testing - some of my apps have 20,000 lines of CSS + more JS

[Roger]

Regarding the tables - these additions are really welcomed . One thing I have always thought should be a standard inclusion is “sticky headers” for the tables. Whilst it can be done code, I dont know of any of my users who dont prefer “sticky” table headers. It is always requested.

[JulianKirkness]

Quite agree Roger - I would really like to see control over table design at the individual view level (with defaults at the app level) and would like to see options for:

• Sticky headers

• Header, Row and Border colours, front sizes etc

• easier control of columns widths (including user control in the live app)

Not to say that I am not really delighted at this announcement - I love working in Knack and while the new builder move has been long and painful for everyone I am looking forward to see what comes along.

Like many, I am a bit concerned about the ‘breaking apps’ issue and hope a way is found to test apps for this - I have always been concerned about adding much JS and CSS to the apps I build for people but without it they just don’t look good enough at the moment. If changes were to come about which drastically broke apps I would not have the capacity to fix them in a reasonable period of time - so fingers crossed.

[DaveParrish]

@Les This is great stuff! Look forward to seeing all that is coming.

[Jessie]

If there is an opportunity to allow beta testing on some features before a roll out that may help.

We’re thinking about having the new theme in beta, will consider a beta testing group as well.

I’m thinking of the hover over feature as this is useless without the ability to change the colour, it’s almost invisible. I just tried it again and put the CSS back

I’m thinking we’ll have a separate topic in the forum to discuss each feature or design setting area, so we can communicate closer to real-time during planning, development and release. I look forward to starting those conversations and learning more about what you expect from each of these features, so we can make sure we hit the mark!

[Jessie]

I seem to recall last time the theme was changed we were ultimately forced into the new theme.

• The legacy themes were ultimately deprecated in order to unify our codebase, so that we’d be able to innovate and fix issues more quickly. There was a cost to supporting the legacy themes related to bugs, new feature compatibility, etc.
• The decision to sunset that was only made once we were confident that the impact was extremely low and the impacted users were given access to resources and ample time to prepare. We do not make these decisions hastily, and this is not something that anyone needs to worry about right now!
• The standard theme (which is now our default) had been around longer than my 4 years at Knack before the older themes were sunset, to give you an idea of the timeframe, and we all know in tech years, that’s practically a generation.

It would be ideal to allow us to sandbox during the updating period.

• Supporting sandboxing for apps or staging and production environments is a project we are very keen on exploring, but I’m not sure yet if that’s supportable for this project given some technical hurdles. I hear you on the need though. Food for thought for us, and let me know if you have ideas on potential solutions outside of a full sandbox feature.

[Jessie]

I have always been concerned about adding much JS and CSS to the apps I build for people but without it they just don’t look good enough at the moment.

Totally - we look at this as hopefully a way to reduce the need for this level of custom code going forward.

If changes were to come about which drastically broke apps I would not have the capacity to fix them in a reasonable period of time - so fingers crossed.

A breaking change that may be considered drastic would be reserved for the new theme, in order to keep your current customized apps intact.

What are your thoughts on the cost it would require to update minor customizations in specific areas when we update features that require breaking changes (such as a drag-and-drop file uploader)?

Is the issue in supporting many clients’ apps? Or is it more about locating/identifying the code and having the information needed to remediate?

[Roger]

@Les

We do not make these decisions hastily, and this is not something that anyone needs to worry about right now!

This is a comforting! Great to hear.

@Les

The standard theme (which is now our default) had been around longer than my 4 years at Knack before the older themes were sunset, to give you an idea of the timeframe, and we all know in tech years, that’s practically a generation.

I have been with you guys a long time!

[CarlHolmes]

Jessie, thank you for taking the time to feedback. It’s reassuring to know that there will likely be a new theme to test changes in and sufficient time and notice to update code if required.

I’m a very low code Knackster, mainly CSS for coloured buttons, sticky headers, borders and the like.
Other heavy lifting for workflow is done with Integromat so have a number of JavaScript webhooks.
Currently just under 100 active scenarios across eight clients.

[Malcolm-Optimi]

Have been waiting with baited breath for a more modern usable look and feel. Can’t wait! We’d much prefer to stick with Knack than try one of the other tools out there that do look and feel well, but don’t compete with Knack on functionality.

What was good about the new builder roll out, was being able to copy an app and switch on new builder on the copy to see how it goes. Not sure if that would work in this case since you’ll be rolling out regular changes but something like that would certainly help, in our apps that have been customised with code.

[Gil-Rabinovich]

Hi Knack team. Great to hear about the new theme coming. One of my biggest needs currently is the option to add toggle options when using multiple steps forms. Meaning when adding more than one sub-item you may consider moving to have an empty table raw to fill with a toggle option to add more lines instead of filling forms on a child page. This will improve dramatically the end-user experience.!

[Fabi]

Thanks for the Update Knack. Good to know that you can invest your energy elsewhere now that the new builder has been deployed.

However I would have liked to see some priority given to Reports. A couple of options from the top of my mind that will help drastically is the following:

• Running Sums (e.g. in pivot tables)
• Group dates by Quarters.
• New charts, e.g. funnel chart
• Customize color of each chart

Thanks!

[JulianKirkness]

Hi @Les

Sorry not to have responded before now - I think my concern is both finding any potential issues and time to repair - and what are clients going to say when you need to do this / are they going to be happy to pay for the time?

Most of us (even Expert Network members) are No Coders and so any actual coding we are forced to do is not by choice. Several of us have a set of more or less standard code snippets we use for a variety of things (I always start a new app by copying in a more or less standard set of CSS for example which provides classes for coloured buttons, a standard background, settings for List view etc). However we are generally NOT experts in either CSS or JS and so may not be that well placed to work out any issues.

Personally, my personal ideal would to be able to build apps with no code in them at all.

Julian

[Jessie]

Hi @Fabi - reports are on our radar, but not specifically an area we’re focused on at the moment. With that said, we’ll be exploring opportunities with this body of live app work to update the plugin tools we use, such as the one that generates our report views. Hopefully this will afford us some quick wins for report enhancements.

Thanks for the feedback and look forward to hearing more about what you need. Please be sure that your requirements/user stories are covered in the feature requests category!

[Jessie]

Thanks for expanding on that concern! We’ll keep this is mind when planning the feature releases.

Something we’re considering is the possibility of flipping the plan shared above. So we could release the new theme first (in beta, that you’d opt-in to). This would allow us to make the foundational breaking changes that we’d then build on iteratively, while allowing older apps to remain intact with their existing code.

The benefit there for you, would be that you can decide at what point you want to bite the bullet and make the switch to this new theme, without having to constantly go back into code and update it every time we release a small feature that requires a new structure.

[MichaelG]

(I had missed this thread)

FANTASTIC!! Looking forward to this shift of resources to modernize the Live App and delete my beautiful code.!! (just 50 lignes in JS and in CSS)

I will add that the new forum is great and you writing style is very nice, lively, and interesting giving some historical perspective some time.

I want to bite all the bullets!

Great:

@Les

1. Add new functionality to the live app, including new views, fields, and more.

One useful View is a Gant style calendar for project: people / time / activities.

@Les

While we’re excited to get started on this work, you won’t have to wait for one big release - expect to see faster iterations with new features.

@Les

A big reason for this message is to help you understand our initial plan so we can hear your feedback. Please comment here, sharing any feedback or concerns.

(while finishing the MySQL database speed, and adding field conections inputs to Email Rules )

great news!

[Jessie]

Thanks for joining this thread @MichaelG! We’re glad you’re as excited as we are for these forthcoming product updates.

[MichaelG]

adding to Item Properties…

Label Format: center
Styles: H3, Underlined
Colors: font, background
Icon: