[RFC] Reinventing the ACP

Note: We are moving the topics of this forum and it will be deleted at some point

Publish your own request for comments/change or patches for the next version of phpBB. Discuss the contributions and proposals of others. Upcoming releases are 3.2/Rhea and 3.3.
Post Reply
Sam
Registered User
Posts: 31
Joined: Fri Jan 23, 2009 10:24 pm

[RFC] Reinventing the ACP

Post by Sam » Mon Oct 11, 2010 8:51 am

The current tabular/navigation based ACP is effective and very clean, but perhaps this type of administration of software via a web interface has numbered days. With rich internet applications taking over, and the web seeming less stateless each day, we may want to consider other alternatives to this style of administration. Additionally, the current module system is really frustrating and can be improved greatly for ease of programing within it.

The current issues:
- The module system requires a minimum of 4 files to create a new module.
- Lack of standard handing of configuration options (cfg templates help, but the PHP end is poorly documented)
- Lack of standard handing of list based management modules (such as the BBcode lists, forum lists, ranks, etc)
- Module system allows for visual reorganization, bit is often a pain for the user

The proposed system:
The idea for this came off of an open source project I am working on, I came up with this idea when browsing files. The idea is make the interface similar to what we see currently in our desktop environment, make the ACP a system of files (modules) and folder (categories). Folders would contain groups of modules that are related, and the Admin can drag and drop rearrange them as they please.

Modules:
Modules would come in two types: configuration and list.
Configuration modules would provide the framework for the template (like a cfg template) so no template edits would be required at all. This type of module would simply be a page of controls, values, buttons, and other options for the Admin to do/perform.
List modules would provide the framework to list items from a table and display them as objects within a special "folder". This module would act like a folder, but instead of modules inside, it would be the objects from the list. Pagination, editing, adding, deleting all would be built into the system, allowing the one writing the module to turn them all on, or all off if they so choose.

Folders:
Folders would simply be folders that contained modules. The admin should be able to move them (within a grid) around the ACP, and be able to create them with infinite depth (folder inside a folder recursively).

Design Concept:
Image

Image

User avatar
ameeck
Registered User
Posts: 86
Joined: Sun Nov 13, 2005 6:43 pm
Location: Prague, Czech Republic
Contact:

Re: [RFC] Reinventing the ACP

Post by ameeck » Mon Oct 11, 2010 12:59 pm

Overall, this might end up a good idea. Just a few things I'd think about:
  • I wouldn't tie up the design and the backend code - they can be developed independently. I certainly agree with changing the backend code to make creating modules simpler, but I'm not so sure about the new interface.
  • Are CFG module types flexible enough? We have action-based modules, e.g. backups, complex modules like permissions.
  • I'm not too sure about the naviation through such an interface. Browsing through a list as we have now (either horizontal or vertical) is much easier than finding information in a clump of icons (even though sorted in a grid). While we will be able to reduce the amount of settings pages we have, we will still have many. Be aware that by designing the interface, you don't have the required distance to see if it really works. User testing could prove me wrong though, so I'd love to see it being done if you decide to continue with this.
Please think before you post.

Sam
Registered User
Posts: 31
Joined: Fri Jan 23, 2009 10:24 pm

Re: [RFC] Reinventing the ACP

Post by Sam » Mon Oct 11, 2010 9:07 pm

The first post has been edited with another screenshot concept.
ameeck wrote:Overall, this might end up a good idea. Just a few things I'd think about:
  1. I wouldn't tie up the design and the backend code - they can be developed independently. I certainly agree with changing the backend code to make creating modules simpler, but I'm not so sure about the new interface.
  2. Are CFG module types flexible enough? We have action-based modules, e.g. backups, complex modules like permissions.
  3. I'm not too sure about the naviation through such an interface. Browsing through a list as we have now (either horizontal or vertical) is much easier than finding information in a clump of icons (even though sorted in a grid). While we will be able to reduce the amount of settings pages we have, we will still have many. Be aware that by designing the interface, you don't have the required distance to see if it really works. User testing could prove me wrong though, so I'd love to see it being done if you decide to continue with this.
1) Yes, it would be layered: Underlying framework > ACP module system > Module files
The ACP modules system would be responsible for parsing HTML templates into ACP modules, unless an override is given by the module file itself to use a custom HTML template.
2) The CFG template system is currently not that powerful, which is where we can make the most improvement. Having some nice API classes for the module system would take a lot of repetitive code work out of creating modules. The new system could provide two types: Config + actions and list based. Basically you would be able to have a function callback for anything custom you needed, but as far as getting something up, it should take no more than 5 mins to get a working module together, 10 mins for a list based. (minus the language entries) Basically, the API functions would allow you to simply map out our configs to corresponding entries, map action buttons with functions, provide callback functions for more custom things, and map out your database table to be displayed on a list based system. Pagination, sorting, etc would all be built in.
3) This type of interface would be very familiar to anyone who has used a desktop operating system. They can organize things the way they want via a drag 'n drop system to suit the needs of their ACP.

User avatar
3Di
Registered User
Posts: 759
Joined: Tue Nov 01, 2005 9:50 pm
Location: Milano (I) Frankfurt (D)
Contact:

Re: [RFC] Reinventing the ACP

Post by 3Di » Mon Oct 11, 2010 11:02 pm

Indeed, good ideas here I can say. Let's see what will happen, now.
Please PM me only to request paid works. Thx.
Want to compensate me for my interest? Donate
My development's activity º PhpStorm's proud user
Extensions, Scripts, MOD porting, Update/Upgrades
👨‍🏫 | Take a tour to | The Studio | 👨‍🏫

User avatar
ameeck
Registered User
Posts: 86
Joined: Sun Nov 13, 2005 6:43 pm
Location: Prague, Czech Republic
Contact:

Re: [RFC] Reinventing the ACP

Post by ameeck » Tue Oct 12, 2010 7:03 am

Sam wrote:This type of interface would be very familiar to anyone who has used a desktop operating system. They can organize things the way they want via a drag 'n drop system to suit the needs of their ACP.
Keep in mind that files you browse on the PC are not the same thing as configuration and managment modules. Have you seen somebody browsing through the Control Panels on Windows? Often it's not a pretty sight. Though your assumption could be correct, I'd really try to verify that with some test from real users. This is an overhaul of a key part of the system, so it's vital to be sure it's the right way to go. People also accept what is given to them at most times and only a minority will tend to play with and organize the layout.

Is this headed for phpBB 4.0? If yes, there is a lot of stuff that will already be done and which will ease up work for developers, a prominent example in this case is Symfony Forms, which basically takes care of the cfg modules. I wouldn't strictly define the type in the module definition but rather make it a blank document that you can fill with anything you want (be it a combination of both or something completely different). We would only provide auxiliary functions which would take care of some repetitive things (like a Bundle or SubController in Symfony terms) for the lists for example.
Please think before you post.

/a3
Registered User
Posts: 97
Joined: Mon Sep 20, 2010 6:44 am

Re: [RFC] Reinventing the ACP

Post by /a3 » Tue Oct 12, 2010 10:24 am

Perhaps something with a little more contrast? That's really my main criticism of the current ACP - too little contrast for my liking.

I do like the concept though... :)
$ git commit -m "YOLO"

User avatar
3Di
Registered User
Posts: 759
Joined: Tue Nov 01, 2005 9:50 pm
Location: Milano (I) Frankfurt (D)
Contact:

Re: [RFC] Reinventing the ACP

Post by 3Di » Sun Oct 02, 2011 1:48 am

/a3 wrote:Perhaps something with a little more contrast? That's really my main criticism of the current ACP - too little contrast for my liking.

I do like the concept though... :)
About style(ish).. that's indeed the last part IMHO, in case.
Please PM me only to request paid works. Thx.
Want to compensate me for my interest? Donate
My development's activity º PhpStorm's proud user
Extensions, Scripts, MOD porting, Update/Upgrades
👨‍🏫 | Take a tour to | The Studio | 👨‍🏫

nathansuchy
Registered User
Posts: 3
Joined: Sun Sep 02, 2012 3:55 am

Re: [RFC] Reinventing the ACP

Post by nathansuchy » Sun Sep 02, 2012 4:04 am

This seems like a great idea but would be a major code change and would take months just for this RFC but on the other hand phpbb is open source so it could finish quickly.

User avatar
callumacrae
Former Team Member
Posts: 1046
Joined: Tue Apr 27, 2010 9:37 am
Location: England
Contact:

Re: [RFC] Reinventing the ACP

Post by callumacrae » Mon Sep 03, 2012 8:47 am

nathansuchy wrote:This seems like a great idea but would be a major code change and would take months just for this RFC but on the other hand phpbb is open source so it could finish quickly.
It's in the 4.x RFC forum, and 4.0 is going to be a complete rewrite.
Made by developers, for developers!
My blog

User avatar
AmigoJack
Registered User
Posts: 103
Joined: Wed May 04, 2011 7:47 pm
Location: グリーン ヒル ゾーン
Contact:

Re: [RFC] Reinventing the ACP

Post by AmigoJack » Sun Oct 28, 2012 6:14 pm

ameeck wrote:finding information
You said more than you may have thought of: the ACP should have a keyword search, so you're able to find what you want by typing in an appropriate caption. However, since captions are language-specific we have to find a connection to the language files (definitions) and back again. For 3.0.11 I've developed a basic approach with good results, but yet I'm not entirely happy with it.
ameeck wrote:ave you seen somebody browsing through the Control Panels on Windows? Often it's not a pretty sight.
Which version? 4, 5 and 5.1 were fairly straight dialog windows, whereas 5.2 and 6 have gone horribly wrong HTML-like things that are hardly to control with a keyboard alone anymore, not to speak of their overall grouping. Likewise the biggest advantage of the current ACP style is that you'll know where the keyboard input focus will land when TABing and you hardly need the mouse.
Sam wrote:a drag 'n drop system to suit the needs of their ACP
Yes, why not. That doesn't even requires icons and could be manifested right now in the 3.0.11 module system: drag'n'drop the modules as an alternative of using the "up" and "down" links. Which would come in handy for any type of list: think of a lot of forums where you want to move one of them from the bottom to the top - currently that needs a lot of time, not to speak of the patience needed to re-arrange a couple of forums.
Sam wrote:The module system requires a minimum of 4 files to create a new module
Let me rephrase it: the template system requires a minimum of 3 files to create a new site. In the end it won't change much in the future, since:
  1. Every language needs to be regarded, which results in 1 new or modified file for each ( = localization/view).
  2. The core needs its own zone, of course ( = controller).
  3. Display/template files might need to fit every module on its own. If we end up doing one general template file for every module we have won nothing by cacheing that, as it would have too much IF/THEN/ELSEs which in the end consumes more CPU than having several well-specialised templates ( = view).
I have no idea what should be an improvement here: reducing files will reduce flexibility and increase CPU usage. The only thing to improve is to get rid of module definition files and put those definitions straight into the core files themselves - since those are arrays/classes they won't collide with the core code, neither now nor in the future (when the core code also becomes OO only).

Post Reply