Tech side of the new UI for UI Revamp Project

[thegostev]

Hi, for now we're far away from new UI implementation which marks a perfect time for discussing what are technological opportunities and constraints.

First I propose to discuss the framework using which we can assess technology side of UI Revamp.

Second, do you think usual checklist is applicable here?

• Is this change going to break current installations?
• Can we provide a backwards compatibility?
• How easy is gonna be for current implementations to migrate to this new release?
• Do current versions of CKAN have the adequate resources/support to migrate to this new version?
• Are we going to change the database schema?
• Are we going to change the API?
• Are we going to deprecate Interfaces?

Third, what tech you'd suggest and why?

Thanks! We have time so can have a relaxed discussion over whole February.

[pdelboca]

There has been some decisions about the Tech side of the new UI in #7524. I'll post here some Guidelines that we started working on:

Guidelines:

1. Base our entire styling on vanilla Bootstrap (meaning almost no CSS in our codebase):
   • It's gonna be easy to maintain.
   • First work item of 95% of CKAN implementations is to customize the theme so I don't see any point of putting effort on something that most of our users will change anyway.
   • Bootstrap is not ugly as a default style, we have been using it, and it is as good as whatever other framework on the internet.
2. Remove our macros.
   • They provide almost no value at all
   • They are painful to work with
   • Inputs are already well standardized
   • Users can control their look and feel using sass variables if desired.
3. Minimize our blocking specificity.
   • CKAN has abused of blocks to provide customization, it provides little value to have a block to override a CSS class in a 5 lines snippet. Or a block to change the title and subtitle in a 35 lines template.
4. Clean up all the dynamic custom styling in the admin setting
   • Remove style, theme, custom css and layouts. CKAN is extensible enough to maintain several out-of-the-box layouts.

[wardi]

Is this change going to break current installations?

Yes for sites with customized themes

Can we provide a backwards compatibility?

We could release a version with copies of old templates like we have in the past for bootstrap updates, but not sure it's worth the support effort

How easy is gonna be for current implementations to migrate to this new release?

Easy if the site has no or minor theme customizations

Do current versions of CKAN have the adequate resources/support to migrate to this new version?

Our theming documentation will need to be updated, what other support could we provide?

Are we going to change the database schema?

Not a problem either way

Are we going to change the API?

No need for breaking changes but we can add endpoints as required

Are we going to deprecate Interfaces?

The plugin interfaces won't need to change but we should consider how we support the old and new themes from extensions. Parallel template directories that we select based on the ckan version could work. Updating extensions that customize templates (most of them) will be a significant effort.

Base our entire styling on vanilla Bootstrap (meaning almost no CSS in our codebase):
It's gonna be easy to maintain.
First work item of 95% of CKAN implementations is to customize the theme so I don't see any point of putting effort on something that most of our users will change anyway.
Bootstrap is not ugly as a default style, we have been using it, and it is as good as whatever other framework on the internet.

I defer to @pdelboca on this but am unfamiliar with alternatives

Remove our macros.
They provide almost no value at all
They are painful to work with
Inputs are already well standardized
Users can control their look and feel using sass variables if desired.

ckanext-scheming and more recently the example I've added for #8014 use the form macros and they work well. Since they've been separated into their own templates they're easier to override now. It is useful to have a standard way to render labels, help text and error messages.

Minimize our blocking specificity.
CKAN has abused of blocks to provide customization, it provides little value to have a block to override a CSS class in a 5 lines snippet. Or a block to change the title and subtitle in a 35 lines template.

👍 but is there a better way to handle adding a class to to a tag in a jinja2 template? Should we have ids on everything and do it with CSS instead?

Clean up all the dynamic custom styling in the admin setting
Remove style, theme, custom css and layouts. CKAN is extensible enough to maintain several out-of-the-box layouts.

💯

[pwalsh]

Is there any decision, or guidelines, for the extent to which the UI work will impact the implementation in HTML, JavaScript, CSS, and logic in Jinja at all?

I think it is important to make this clear, for the project itself and also for the type of questions raised here by @pdelboca

Is this project also, by definition, a revamp of the templating layer, or, as much as possible, is it just about "look and feel"? If it is primarily or completely about look and feel then issues around macros and blocks etc are almost unrelated. If we think those things are part of the scope of the project then it probably requires quite a lot of thinking and planning.

Either direction is fine, but, I'd like to understand better to see how I could best contribute.

[wardi]

The "look and feel" leads the changes, and in parallel we should add HTMX for better interactivity where it makes sense like #7685. Both require some HTML template and JavaScript changes so, where we need to break backwards compatibility, we have an opportunity to clean up some of the templates to make them easier to understand and maintain.

[pdelboca]

I would totally go for breaking backwards compatibility.

I think we should remove a lot of our old CSS structure, reduce our blocks and templates specificity, leverage modern HTML, etc.

Our HTML and CSS codebase has 10+ years old. I think it is time to gracefully let it go :)

[thegostev]

I see it as area of responsibility of Alexandra and her decisions to make in order to implement a new design. It's only decoration as a primarily purpose for the project, though if it'd be a capacity and capability to fit in refactoring/rewriting, it'd be beneficial. We're estimating the workload now to understand how do we fit into 4 months. It's really important for these decisions to be made by Alexandra, though we can suggest our vision and help her.