ACP UX Improvements

[DavidIQ]

And I would like to have a language feature so that each admin can choose his own ACP language which can be different from the board's language.

Settings and administration areas for any software I've ever used either go by the language the application is set to or, in the absence of such a setting, the system language which ends up being the language the software is also presented in. Adding a second language layer just makes things unnecessarily more complex with very little to zero ROI.

[Louis7777]

And I would like to have a language feature so that each admin can choose his own ACP language which can be different from the board's language.

Settings and administration areas for any software I've ever used either go by the language the application is set to or, in the absence of such a setting, the system language which ends up being the language the software is also presented in. Adding a second language layer just makes things unnecessarily more complex with very little to zero ROI.

For any forum - specifically - software you mean?

Because I can think of a few where the administration area has such a feature and also many that have a known plugin for that purpose (so that means that it's a wanted feature). One such software that I am using extensively is PrestaShop.

The image below is the profile for a backoffice user or employee of older PrestaShop series:


And you may think it is useless but there's a good use case. What if an admin wants to be able to see exactly what the users are seeing and so he wants the board to be in German, but meanwhile he wants to view the administration area in English, because he is one of us who likes to have all of his software in English, for reasons (perhaps in case he wants to lookup something in Google)?

Also, I know for a fact that it's a pain in the ass when I make a site for a client and there has to be a specific language set for the administration, if we are both using it (because I usually go with English rather than his native language), or when we are viewing it in different languages and we can't easily communicate because it's cumbersome for him to change it for the admin panel since it will also change for the frontend... </end-of-ranting>

[DavidIQ]

Fair enough, you make some good and valid points. 😉

[DavidIQ]

• COPPA - (This should go into an extension)

+∞

Cookie notice as well then.

[Elsensee]

Maximum private message folders - (Is it really necessary to limit this?)
I think yes, because otherwise some boards will have more PM than "real" posts, so keep it
But maybe there can be an extra explanation: "For the total users limit you need to multiply those parameters"

Why would it matter if a board has more PMs then Posts? If that actually happens...

+1 to remove

The option or the functionality?

Not strictly always. It has already been discussed that description is wrong here (see this PR). Option should be kept.

When is it different?

But separate the OAuth then. OAuth is simple, commonly used and doesn't require expert to handle (you can't break login by adding OAuth keys).

I also thought about this.. but wouldn't know where to put it. But I agree that this might be an often requested feature.

And I would like to have a language feature so that each admin can choose his own ACP language which can be different from the board's language.

You can write an extension for this, but since this is a veeery limited use case I'd rather not have this functionality in the core. (Also, this is about simplifying ACP, not the opposite)

Throwing out options will not result in better UX. I don't think that it is possible to improve UX without completely redesigning the ACP.

I think not giving the User a HUUGE load of settings is already an improvement. Also, it can help supporters since there will be less mistakes and when redesigning ACP, we can just focus on organising the important stuff.

• COPPA - (This should go into an extension)

+∞

Cookie notice as well then.

I'm sorry, my european bias has affected me here, I think.
It's very hard to see things objectively but in the end I agree.


I've updated the first post to reflect the arguments in the posts made until this point.

[Senky]

• COPPA - (This should go into an extension)

+∞

Cookie notice as well then.

Sure.

+1 to remove

The option or the functionality?

Functionality.

Not strictly always. It has already been discussed that description is wrong here (see this PR). Option should be kept.

When is it different?

In 99.99% it stays the same. There are, however, cases when you have multiple boards running on subdirectories of the same domain. Cookie prefix solves the problem with the same cookie name, but with cookie path set to "/", you receive all cookies on whatever board. Some intranets might, however, block your access to different subdirectories, but you receive cookies regardless. I know, it's so complicated situation, that maybe we should remove the option and if (ever) someone complains, provide an extension that covers the functionality.

But separate the OAuth then. OAuth is simple, commonly used and doesn't require expert to handle (you can't break login by adding OAuth keys).

I also thought about this.. but wouldn't know where to put it. But I agree that this might be an often requested feature.

Probably new module. It's not that difficult to copy already existing HTML from the template, put it to new one and do the same with PHP.

[Elsensee]

Not strictly always. It has already been discussed that description is wrong here (see this PR). Option should be kept.

When is it different?

In 99.99% it stays the same. There are, however, cases when you have multiple boards running on subdirectories of the same domain. Cookie prefix solves the problem with the same cookie name, but with cookie path set to "/", you receive all cookies on whatever board. Some intranets might, however, block your access to different subdirectories, but you receive cookies regardless. I know, it's so complicated situation, that maybe we should remove the option and if (ever) someone complains, provide an extension that covers the functionality.

For those use cases we can still use the cookie_name which should be different of course.

[hanakin]

In regards to the ACP style. Its might be best to leave it as its own style but overhaul to be based on one of the open front-end frameworks that already have countless admin UI available for it. Pick one we like fit it our software to it and vice-verse then release this way we can take advantage of what already exists. The real argument is which framework to use. In my eyes there is really only one, but we can not use it as it requires angular. So that leaves us with bootstrap or MDL which are the two primary competitors when it comes to admin UIs so find my suggestion for the ACP.a UI we like and adopt its framework is.

I really to do not want to muddle the front-end components for base-l with ones that are not used anywhere other than the ACP. This may be confusing to authors.

but I am open to suggestions either way.

exp:
https://cssauthor.com/material-design-admin-templates/

[P_I]

I haven't had time to read through the full list, but my number one suggested change would be on the General Tab, I would split the software versions (phpBB, PHP, Database server) into a separate section, they are NOT Board statistics. I attempted to implement this in [PHPBB3-15198] Fix phpBB and PHP version info displayed in the ACP but it was felt to be inconsistent with the existing UI.

A potential model that could be followed is https://www.mediawiki.org/wiki/Special:Version.

[CHItA]

Throwing out options will not result in better UX. I don't think that it is possible to improve UX without completely redesigning the ACP.

I think not giving the User a HUUGE load of settings is already an improvement. Also, it can help supporters since there will be less mistakes and when redesigning ACP, we can just focus on organising the important stuff.

The ACP is not unusable because the number of settings available, but because of their organisation (or lack there of). Eg. "Board settings" and "Board preferences" are pretty *beep* names as you don't really know what you would find there.