Forum OpenACS Development: Merging of /admin and /acs-admin
split between /admin and /acs-admin, the former having most of the
stuff you want to get to, and the latter having only the
package-manager and user administration.
If nothing else, it's confusing to have to access to package manager
from one admin interface, and then go to another admin interface to
actually mount the package somewhere...
If no one objects, I'd like to merge the two together.
I think that's a pretty major issue that needs to be addressed in terms of 4.6 because all of the admin interfaces are kinda crappy. Are you hoping to do a quick fix or something major?
/admin is actually acs-subsite/www/admin so the same admin pages are used for "Main Site" as any other subsite.
The acs-admin are site wide setting that affect all subsites.
Now ... a better UI that steers you to the right places is needed, no doubt about that. Given the better UI the confusion as to what's what should go away. And a better UI's being talked about for 4.6 (or at least it's on everyone's 4.6 wishlist).
Why not just change the text at /acs-admin from "ACS Administration is used to administer the site-wide services of the ArsDigita Community System." to "OpenACS Administration is used to administer the site-wide services".
Then on /admin just place a text on top of the page "[subsite name] Administration is used to administer the subsite services".
Small changes but that should help new users... that there is a differenct between the 2 of of them. Or why don't we just rename "OpenACS Administration" to "Site-Wide Administration".
I am also fully aware that I might be missing something here. Can someone describe a scenario where having links to the package manager and user admin on subsite's admin page would be _more_ confusing than not having it?
I am also in agreement that the admin interface needs a large-scale overhaul. I am also in agreement that baby steps along the way are useful. Is this a baby step that will make things easier for people (especially new users of OACS), or is it just not useful?
My personal opinion is that if you ever have to type URLs into your web browser to access part of your site, then your site is broken.
I'd agree that moving APM and user admin to the subsite admin page would make sense (obviously, don't show them to people who don't have site-wide admin).
A little less baby-step-ish, I'd really like us to have one /admin control panel acting as your portal into all the administrative functions that you have on the site (or in this subsite, if you're under /somesubsite/admin).
And just use one url. Not too sure how easy that will be since from what I remember /admin is not really very separate with sub-site.
Maybe we can live with 2 urls we just need to make a good first front page at /admin.
I'd like to do as Lars suggests in 4.6, though I'd express it somewhat differently - "yank the dotLRN control panel functionality into the core". Something like that. In other words dotLRN has a control panel that exposes your dotlrn admin functions and a link to sitewide administration (which could be expanded to include explicit links to the things one most frequently wants to visit like the APM).
I don't think we're ready to make 4.6 depend on the new portals system (though I suspect that long-term we may want to) so rather than a "control panel" portlet we'll probably want to offer admins a link to a "control panel" page that presents them an "admin central" view of everything they're entitled to break ... errr administer ... on the system.
This would be easy to do, no?
As one person who regularly experiences information overload (and subsequent memory crashes and rebuilds), I'd appreciate all the links available on a page as you suggest --instead of trying to rely on memory.
I have actually been attempting to role this kind of page into the documentation, but including a reference to an existing page would be better. Having the page created by experienced administrators would be better still! =)
Any ideas on how the page would be organized?
From OpenACS Administration there are links to ACS Package Manager and Users, and at the bottom of the page there's a link back to subsite administration, for every mounted subsite.
The confusing part is that admining users is considered a site-wide admin task, and the acs-admin package is not called apm. It's more than just moving a link though, user administration needs to be scoped to the particular subsite.
I'm wondering if the concept of dependant and independant sub-sites is worthwhile. It would be nice to specify that a sub-site of some parent site is visible from can be controlled by the parent site, or that it's completely independant. For example, are users of the sub-site considered users of the parent site, can the parent site admin them? Does the parent site show up in the bread crumb trail of the sub-site? etc...
Why can't we depend on portals for 4.6?
I'm not saying it shouldn't be on the table, I'm just thinking out loud that when the table's loaded with things we want to do and we get into triage mode tossing out things that can wait until after 4.6, doing an admin portal-based control panel is likely to get tossed onto the table labelled "the version after 4.6".
Maybe not, though. Clearly improving the admin UI ranks pretty high on everyone's list, including mine. If we decide to essentially rewrite all or most of it then I'd vote for writing portlets and a control panal portal page. If we just add some more complete links to the admin overiew pages and work on improving the worst pages then I'd probably suggest holding off on the portal approach.
From a user's perspective, the UI is really confusing and difficult to use since one of the major strengths of the OACS is being able to manage users.
Would the time it takes to improve the interface depend on rearranging the way the underlying system works or is it just rewriting the pages?
I think that's exactly what Don's saying, that doing it the portal way would require significant rearranging of the way things work, over and above rewriting the pages to actually make sense to normal people.
I understand what you're saying now. I thought that what you were saying was that the portals package itself wasn't ready, and I couldn't understand that. I see now that you were thinking further ahead.
1) the sitewide/per-site split
2) the bewildering terminology for user groups (Group Type, Relational Segment, Relational Type, Composition Relation, Membership Relation - a set of words that could arguably be hidden/simplified in presentation until only "group" remained)
For everything else, there's re-arranging. Here's my first stab at identifying commonalities between the admin functions: