abstracting the UI

[Thanood]

This is meant to be an ongoing post for the purpose of writing down my thoughts.

For Carmel to be bridge-agnostic (the first step in being tool-agnostic) we'd have to abstract the UI in a way that users can apply their bridge design.

Here are some first thoughts:

We should separate design and layout, defining some "static" elements (nav-bar and side-bar) and a completely customizable content section.

• blue section: static elements
• green section: customizable elements (ignore the editor placeholder)

To be bridge agnostic, the application should use an independent grid system (like http://flexboxgrid.com) to accomplish a layout without depending on the bridged library to provide one.

In contrast to being "static" regarding layout the nav-bar and side-bar should still be customizable regarding design, so that elements from the bridge can be used. I'm not sure how to adress this. Router viewports maybe? I didn't try layout views, yet.

So the general layout (top navigation for components, left navigation for samples) would be the same for all bridges while the design implementation may be different.

Any thoughts?

[adriatic]

I do not believe that making the carmel header (content of the blue rectangle which consists of the nav-bar and tool-bar - highlighted in yellow) static

is the right decision. To be correct, we should only be discussing the (yellow shaded) toolbar as this is the application specific navigation tool which has to be dynamic in order to support the concept of user added content.

I will return back to this issue tomorrow, as I want to address some more urgent information that would allow us to move ahead.

[Thanood]

Yes, I mean it's static regarding layout. With that I mean it is there (and nowhere else).. 😃 Anyway, you might be right. Materialize bridge does use another approach for this navigation (a side-nav "drawer").

[adriatic]

OK, I considered "static" as saying that the navigation toolbar is hard-coded in the program text. We are already using the dynamic approach since the database content is created from the this file, which is transformed in this seed data.

As we get smarter building this (and do some research on dynamic UI creation) we might do this in a more sophisticated way (this is the first area where we will miss Jeroen, as he is really creative doing such things 😄 )

Note that our first task (indeed your first task) is to think how to do the same for Materialize catalog.

[Thanood]

how to do the same for Materialize catalog

That's exactly what this issue is about. 😃 It's actually not an easy question. Maybe I should try layout views. If we changed layout for each bridge, the navigation parts can possibly anywhere... I think. That's why I should try it.

[Thanood]

Btw. my (still company-private - I always forget to ask if I can make it public) MDL bridge catalog looks like this:

The component navigation consists of dropdowns right where it would be in the "layout static" approach. I wouldn't mind doing something like that for Materialize bridge, too.

[adriatic]

I think that not strictly following KendoUI catalog navigation is a good thing, as it makes us think more generically.

[Thanood]

I'm writing this down as a note to myself so I don't forget. My current idea for having different ui toolsets in the same appication is as follows.. I will be summarizing bridges, tools, component libraries etc. as "libraries" from now on.

The current structure of Carmel editor implies a new route (with child routers) for each library. This means there will be a top-level router for each library (as a child of the app router). Their respective child routers will navigate between the pages of the library itself.

This opens the possibility to use layout routes for each library. Here is what the Aurelia docs say about layout routes:

Similar to MVC-style master/layout pages, Aurelia allows you to use a "layout" view like an MVC "master template" for a set of views. The set of views subject to being part of a layout is defined in Aurelia as a set of views referenced by one or more routes in a router configuration.

Taking KendoUI and Materialize bridges as well as aurelia-orm as examples, there would be three layout routes:

• KendoUI - using KendoUI layout and components
• Materialize - using Materialize layout and components
• aurelia-orm - using a default layout, probably bootstrap (just because it's ubiquitous)

The deal with aurelia-orm here is that it is a library which doesn't have any visual elements itself. So in my opinion we need a default layout for these libraries. I think bootstrap is a good choice because virtually everybody knows it.

How will the carmel tag editor itself be designed?

I think we should be really generous with css classes, giving each element of the editor certain easy to read classes and maybe follow a naming standard, like BEM. This way we can provide a default style (using bootstrap because it's the default UI library) and each library maintainer can customize styles by using their own CSS.

[adriatic]

I definitively like the layout routes idea - this feature was added after the catalog was well underway, otherwise we would likely use it already.

I am also thinking about the catalog app in a way that resembles a framework, so we can use the Auth0 Extend as a basic building block which would allow any or all catalog users to add to the content. I came up with this idea thinking how to extend the current concept of allowing users to add tags to the state where anything can be added to the content of the catalog.

I will write a lot more about this as soon as I "ship" the first alpha version of Auth0 samples for Aurelia community