[Joomla 4.0 backend template] Edit Article Layout

[coolcat-creations]

So this is the proposal for the Article Edit View.

Just in this view the tabs are at the bottom, the focus should be at the contents and many tabs can follow with custom fields so it's good to think affront how to add more tabs then the viewport is able to show in a row. A possibility could be to add a double angle icon left and right to switch through the tabs in the moment they would break.

Also attached a mobile example.

Any ideas are welcome and i can provide the sketch file for those that want to contribute to the design.

1) Create Article

2) Save Actions

3) Inline Editing

4) Image Inline Editing and contextual change of the Editor Buttons

5) Example for the images and Links Tab

6) Saved Dialog inside the input

7) Mobile Example (Icons not correct right now)

[dgrammatiko]

A possibility could be to add a double angle icon left and right to switch through the tabs in the moment they would break.

New tabs will never break (theoretically because ycfs), as if the viewport gets narrower they collapse to accordion

My question here will be:

Why tabs? It's a known antipattern for forms (we should never hide form elements)

[coolcat-creations]

@dgrammatiko Which other solution would you suggest? Please keep in mind Custom Fields Tabs and on...

[dgrammatiko]

Well my question is simple why do we need to hide form elements?

The solution is not how we're hiding them, but stop hiding them. Or in other words reduce the stupid options (they don't belong to data entry first of all, this is something that controls the layout) find another way for the permissions. To put it simple we're not improvising enough here, (nothing to do with the proposed design I like it). We need to rethink what, how,where things are happening. All that from a UX perspective...

[brianteeman]

1. i dont believe we can ever reduce the number of fields to the point that it is not overwhelming on a single screen

2. accessibility. tabs at the bottom can be done if there is a "jump to" link

3. accessibility. putting all the fields on a single form would mean you had to press the tabkey through a large number of fields to find the one you want, as opposed to "jumping to" a tab and then pressing the tabkey through a limited number of fields

[dgrammatiko]

putting all the fields on a single form would mean you had to press the tabkey through a large number of fields to find the one you want

Depends what we consider data field, (I do not consider the stupid switches data entry fields), also last time I checked wp there is one page full of fields for the page/post. So someone got it wrong here, either we or they...

[brianteeman]

joomla is not wordpress

[mbabker]

WordPress doesn't have 100 options on the page/post editor like articles do.

[coolcat-creations]

We discussed every single bit of that design for so long and with so many... Before the JCM Article was published we even agreed on it.

Please lets focus on -> Yes -> improvement but -> No -> changing everything from scratch again

[dgrammatiko]

WordPress doesn't have 100 options on the page/post editor like articles do.

And exactly this is our problem and what I'm trying to highlight here. On the data entry form we also include the ACL and the output control. It's obvious that we're doing it wrong

[mbabker]

And it's not a fix to be made by slapping a new coat of paint (template) on the admin UI. A lot of code and workflow adjustments involved here...

[dgrammatiko]

We do have a GSOC for the overrides, so all we have to fix ourselves is the ACL layer, or not?

[ciar4n]

@coolcat-creations Thank you for posting

Regarding the tabs, is there any benefit to placing the tabs at the bottom. Honestly I am failing to see any good reason for it. One issue I have with it is that it means users have to scroll to navigate to the majority of available options for this view.

[mbabker]

Nope.

You start moving params out of the backend forms, you have to pull those out of the layouts, pull the param handling/merging out of the code that handles that (i.e. when you're merging menu item params with article params on various views), etc.

It's documenting the ever loving crap out of all of this because you're basically going to start telling a lot of people they're going to have to make more use of layout overrides. They're going to have to get smart in our PHP API, because some of the things you can do in the UI with options right now can affect a small subset of items; leaving this all to layouts means if you want an exception for a couple items you either hardcode ID exemption rules in your layouts or you build alternate layouts (and have to learn that feature to do it right).

Removing the stuff from the UI is just one small aspect of pulling options out of core.

[mbabker]

err, my comment was to @dgrammatiko, didn't see the other post come in 😉

[brianteeman]

and what would you do with upgraded sites?

[coolcat-creations]

@ciar4n The Tabs should be fixed at the bottom. There were some people suggesting to make the most important - the editorpanel - as far at the top as possible. So you don't have to scroll down towards the editorwindow on each article edit. You rather switch the tabs not that often, then editing an article. I tried with different approaches and at JCW17 we made tests in a small team and that was the result.

[ciar4n]

When I get the chance I'll create the PR and see how it works... admittedly I am still not convinced but willing to give it a try :)

[dgrammatiko]

and what would you do with upgraded sites?

well if we can't handle this, farming has been always a good alternative.

But anyways there is not strong will to move forward for J4, so I'll stop here. I'll back up @ciar4n for the tabs

[coolcat-creations]

@dgrammatiko Great! What will you need for the contextual change of the Editor Buttons ? (Since it was your idea) ;-)

[ciar4n]

PR created regarding fixing the tab navigation to the bottom of the viewport... #434

[dgrammatiko]

@coolcat-creations keep it on hold for the moment, @brianteeman already proposed the new version of CK and also we were discussing the possibility to go to a newer editor with better UX, better pluggability and drop completely the iframe old tinyMCE

[dgrammatiko]

@coolcat-creations but even if that won't happen due to workload, I can easily make a PR with a custom element to get tinyMCE with inline theme (which has the behaviour we need, only thing is we need to plug our xtd-buttons): https://www.tinymce.com/docs/demo/inlite/

[brianteeman]

CK Editor 5, is the best editor for this , but may not be an option depending on IE 11 support (see https://github.com/ckeditor/ckeditor5/issues/330#issuecomment-380376874)

[dgrammatiko]

@brianteeman it shouldn't be a major problem, we have ES6-Es5 code for the custom elements so we can beef up our building tools and make 2 versions of CK and deliver the correct one depending on the client capabilities (also provide missing polyfills). We're already doing this with ce's

[micker]

I like this design... For me if i can say anything is the position for plugin button like module ect... I think we need to put it later this button are less important than content... Maybe After description or in dropdown to be more compact For me button need to be arranged in order of importance (most uses) What do you think ?

[mbabker]

For me button need to be arranged in order of importance (most uses) What do you think ?

That's too subjective. Your workflow is different from mine which is different from everyone else's in this thread (I essentially don't use the WYSIWYG editors except to validate my markup isn't completely broken, others write in them like they're in a Google Docs or MS Word style editor).

Also, the editor button plugins are fully controlled by the plugin ordering, so you can customize at least that aspect of things to your liking.

[dgrammatiko]

For me if i can say anything is the position for plugin button like module ect... I think we need to put it later this button are less important than content...

Well I don't know on what research all these ideas of putting things up/down is based on but I don't think I quite agree with all of them. But almost all my daily applications in my PC follow a very well established pattern: toolbar on the top, edit area bellow so yes the buttons belong in the upper area.

[dgrammatiko]

@coolcat-creations why were are separate xtd-buttons? I mean I already concentrated that space to one dropdown. So in that sense with a little tweaking of the tinyMCE template you get almost what you need:

Also I tried to unify the xtd-buttons to the upper part of the editors (for all joomla editors) but brian and charlie was against it and I'm sick and tired fighting over obvious things...

[coolcat-creations]

@coolcat-creations why were are separate xtd-buttons? I mean I already concentrated that space to one dropdown. So in that sense with a little tweaking of the tinyMCE template you get almost what you need:

I can't install the current staging as posted 2 times ;) i have no idea about the current state.

[micker]

@dgrammatiko @mbabker sorry but its not realy subjective think about end-user not joomla pro if you create an article did you insert module or menu-link before adding text ?? for important option like bouton editor i am agree but for less used button we can win some place and having a better ux for first user impression the question the ordering of content is important about user apprehension ... create a joomla content is for integrator skill or author skill ? it a detail but interesting to keep a little time one it for a better finition

[dgrammatiko]

@micker unless you haven't realised Joomla's tinyMCE (default core editor) has the xtd buttons inside the tinyMCE toolbar since 2014-15. I did that part after JAB Prague as it was decided that this was one of the easy UX improvements for J4, but we managed to get it in J3. So I'm not even following why do we have to discuss about reverting this...

[mbabker]

for important option like bouton editor i am agree but for less used button we can win some place and having a better ux for first user impression

So you're suggesting to create a massively subjective set of two toolbars (one being the editor's "native" toolbar and one being the Joomla context specific buttons) instead of having a consistent UX with one toolbar?

the question the ordering of content is important about user apprehension ... create a joomla content is for integrator skill or author skill ? it a detail but interesting to keep a little time one it for a better finition

By this argument tools like Microsoft Office or Google Drive have it wrong having the toolbar before the content workspace.

[micker]

ok i respect this no problem it's a details lol thanks for time reply !