Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More intuitive Backend (switch basic/advanced) #7

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

More intuitive Backend (switch basic/advanced) #7

wants to merge 1 commit into from

Conversation

astridx
Copy link

@astridx astridx commented Jan 19, 2020

This specification aims to define a more intuitive Backend for output.

In the basic mode the backend will show only important options.
It is going to add a switch for enable a advanced mode.
The advanced mode shows all possible options.

This proposal is a result of the Forum for the Future and was proposed by Elisa Foltyn.
Editor of this text is Astrid Günther

@astridx
Copy link
Author

astridx commented Jan 19, 2020

i just saw this issue.
#6

@astridx astridx closed this Jan 19, 2020
@nibra
Copy link
Member

nibra commented Jan 22, 2020

Yes, but please keep it open, until those two proposals are merged into one - there's already too much valuable work put into this! Please work together with Elisa to merge this and #6

@dgrammatiko
Copy link

This proposal is not aiming to actually solve any of the UX/UI problems but rather hide the ugliness under the carpet.

A different approach would be:

  • Separate the input data from the display option. Eg the article form right now asks for both the data for the article and also the presentation of this data. These are 2 different concerns and quite honestly they should never be mixed. The cases where an editor is also the designer of the site are extremely low and even in these cases mixing the 2 different concerns is architecturally wrong
  • Embrace the inheritance for layouts. Right now Permissions are correctly inherited from the category (parent). This should be done also for the the layouts, eg the layout of an article should be inherited from the category. How that would look like? The parent category of an article, for example, should have a default.article.php file that would act as the default.php layout of the article. Also all the design options should be available in the category edit view and by default should be missing in the article edit form (since the article default layout is inheriting from the category).
  • Also the edit for of a singular item (eg article) should be controlled from the category. a dev/admin should be able to create different form.xml definitions and edit.php per category that would drive the view of the articles of this particular category.

I think this is in line with the rest of the Joomla's architecture, so embracing inheritance should be a better approach than adding a fake layer that sooner or later will be hard to maintain...

BTW I have written couple of articles on this exact topic few years ago..

My 2c

@brianteeman
Copy link

The cases where an editor is also the designer of the site are extremely low and even in these cases mixing the 2 different concerns is architecturally wrong

I think the prevalence of page builders contradicts this

@dgrammatiko
Copy link

I think the prevalence of page builders contradicts this

Not really. There is an audience for both and since there are already 3-4 page builders for Joomla the core should probably give more attention to the other part of the spectrum

@brianteeman
Copy link

I was contradicting your statement that "the cases where an editor is also the designer of the site are extremely low "

@dgrammatiko
Copy link

the cases where an editor is also the designer of the site are extremely low

the cases where an editor is also the designer of the site and not using a page builder already are extremely low

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants