Orchardcore: Is this a good time to think about the admin?

[matiasmolleja]

Hi.
This is not an issue. It is just a suggestion from an end user. I think that in the last meeting Sébastien said this is a valid channel for that.

Maybe now that you are questioning many parts of Orchard 1 it's a good time to think about how the admin should like in Orchard 2. So that in the case that the desired UI requires something implemented in a specific way you can know that in advance.

Orchard is a very developer friendly CMS, and I love that. But maybe we are a little biased here.
Probably it's time to devote some of the (precious) core developers time to polish-rethink the UI. After all, the user that will spend more hours in front of a Content Management System is the content manager. And the content manager probably does not know anything about extensibility points, shapes, json, etc..

And while the Orchard1 user experience was OK 5 years ago, right now maybe It's a little outdated.

In my particular case I'd like to see:

• Fewer reloads ( maybe even a SPA ? ).
• Fewer clicks needed to perform most common editor tasks.
• More consistency in different parts of the UI, at least in the Core Modules. I know that Orchard is a very modular System and this makes difficult to achieve consistency in the UI, but now that we now what the core modules are going to be, it is possible to unify the look and feel: same buttons, same positions, same listboxes, "same everything" across admin pages :).
• Responsive layout.

And finally one more suggestion about the workflow for this task: First let's do a technology agnostic prototype, then choose the right technology to implement it. I mean, first use Photoshop-Painter-whatever , then use Angularjs-Knockout-React-whatever, bootstrap-foundation-whatever, less-sass-whatever :)
This is what this people did for it's CMS and maybe the same will work for us (I mean the workflow, not the nodejs thing).

Again, I love Orchard, and It's wonderful that you are adapting it so fast to the coreclr.

[bleroy]

My pet peeve: integrate workflow into everything to make it possible to replace processes, and implement custom logic easily. For example, you could imagine integrating a validation workflow right into the content creation process.

[jersiovic]

Also to use dynamic forms for define admin views would be a great advance for the ease of use.

[sebastienros]

Would you mind sharing your ideas during a meeting with some demos? Whatever level you have reached is fine by us.
Even like during triage in 30 minutes

[jeremycook]

(I deleted my last post, clarified, and posted as this one so my changes wouldn't be missed. Sorry not trying to spam and not sure what the best etiquette is in that case.)

I think Drupal 8's take on organizing theme elements could be good inspiration for improving UI consistency and modularity in Orchard 2.

Also, thinking of the admin UI as an example of how to build anything in Orchard 2 would be beneficial. Make it something that site builders can imitate and is consistent with how sites are themed inside and outside the admin UI will help improve consistency everywhere, benefiting everyone.

I know I'm new here but I'm particularly interested in helping with consistent, compliant, accessible, and modular HTML5 and CSS in Orchard 2. Please reach out to me if you would like my help.

[Skrypt]

I'm actually working on the new admin theme, if you want to chat about it with us you can get into sfmskywalker/Orchard Gitter channel. Any kind of help is always appreciated.

[jeremycook]

SPA-framework and forms agnostic admin UI. Allow the theme to determine read and edit UI.

For example: The default admin theme might take the simplest approach and use HTML forms with server-side validation. Another theme could implement the same pages using react/ang/ko/whatever and submit JSON AJAX payloads to the same end-point via content negotiation.

[jeremycook]

Extendable content types.

Example: The User content type that comes with core consists of the minimum number of fields needed. Modules (in code), administrators (in browser), even themes if it makes sense, can add additional fields to the User content type that will be rendered in the appropriate places.

• A content type can be created in code or visually in browser.
• A created content type can be extended with code or administratively in browser.
• In general, themes use content type information to render lists, read and edit UI, etc.

[bleroy]

@jeremycook not sure what you're suggesting here, as this is pretty much what Orchard has always been doing. Can you explain?
On admin themes, keep in mind that most of the admin templates actually come from modules. Putting too much burden on the admin theme means limiting module extensibility. If the admin theme, on the other hand, concerns itself mostly with generic styling, and behavior is still provided by modules, then the theme author doesn't have to only work against a fixed set of modules.

[jeremycook]

@bleroy sorry if I say silly things, I have little Orchard 1 experience.

If Orchard content types handle the behavior I described than awesome, and I look forward to trying it all out in Orchard 2. I take it the frowny face was because my content type request was redundant.

I'm not dismissing modules providing their own templates. I'm simply looking for more flexibility and consistency for theme and module makers:

1. The ability for theme designers, front-end folks, site-builders, and so on to have a great deal of _natural_ control over not just visuals but behavior.
2. If a content type can fully describe the elements of the UI then module builders need not provide templates in many cases, or the templates can be quite bare with most of the rendering driven by the content type (like MVC EditorForModel() except I hope for something better).

Rendering driven by content type enables module developers to write less html/cshtml/etc. when their lists, views and forms are pretty standard, and allows theme designers to not have to worry about specific modules, and instead use the standard content type model to render UI.

I can't imagine that what I'm suggesting would limit module extensibility, but I'm all ears. It may be the case I don't know what "module extensibility" means to you.

[bleroy]

@jeremycook the emoticon stands for "confused" (hover over it). Theme developers can override any shape template, so they do have control over behavior. It's just that it's a tricky road to take. Your point #2 is a good one, and in fact, there's a Forms API in Orchard 1 that enables modules to do away with templates in lots of cases, but not all. When a module does something a little bit more original (say, a goelocation module giving a map coordinate editor), it will always need custom templates. If the theme makes too many assumptions, it may cause degraded experiences for those "unexpected" modules. Also keep in mind that even basic building blocks such as parts and elements are provided by modules. I think Orchard 1 was providing exactly the right balance for this, so it's not quite clear what you're proposing.

[jeremycook]

@bleroy Thank you. All good points. It is sounding like most/if not all of what I have proposed can already be done in Orchard 1 and can be expected in Orchard 2. I have other thoughts and questions, but I'll wait until I have a chance to use Orchard 2, and familiarize myself more with the Orchard 1 features in 2.

[justrhysism]

It's been a little while since I worked with Orchard regularly, but one of my pet peeves was the inconsistency of the styling, classes etc of the Orchard Admin theme. I understand how it got to that point, and it _is_ a community project, so I never complained. I did spend some time thinking about it though.

Having recently worked on several SPA projects, I've learnt that they quickly get out of hand and can be more trouble than what they're worth (as opposed to traditional post-back).

The admin really just needs to be consistent; for that, you need a comprehensive UI library which module authors can leverage without having to bring in their own scripts and styles (or at least minimise the amount required). There are many, many admin UI themes out there. Many of them are extremely comprehensive, and most of them are built on Bootstrap. For better or for worse, Bootstrap does provide a consistent UI, good documentation and there are few developers who _haven't_ used it.

In addition, using a platform such as Bootstrap would make it quite simple to "drop in" a different theme depending on your use-case.

TL;DR
Let's not reinvent the wheel, or make this overly complicated. Admin UI has been done to death. Pick the most comprehensive existing theme (which has the right licensing) and move on to more important things.

[agriffard]

Closing it for the moment.
Let's continue on other specific threads like #149, #468, ...