It seems to be a bit confusing that the acs administration pages are
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.

Improving the admin UI is important.

/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.

Dave's right ... "/admin" are the admin pages for the "/" subsite, not for the site at large.  We need to preserve the distinction.

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).

I agree that there is a philisophical difference between the two admin areas, but in practice, the divide doesn't seem to exist.  subsite depends on the core, so is it actually that bad for subsite's admin pages to reference the core's admin page?

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 think lets take Lars baby steps.  Lets just put Sub-site stuff above the page and put Site-wide stuff on the 2nd half of the page.

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.

Don,

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?

Stephen's description is similar to what I've got in mind.  We'll need a volunteer to work on admin UI issues for 4.6 and we should look further than just this tiny issue.  We want the overall admin UI to be blindingly obvious and perhaps somewhat attractive visually because this  is one of the first things people run into when they download and install OpenACS.

Time and the number of tasks we're going to try to squeeze in, since we want 4.6 to come out relatively soon.

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.

Talli,

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.

Don,

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.

/Lars

It seems to me that most of the administrative functions in OpenACS are sound, and that most of the admin usability problems are labelling and organization.  I see only two fundamental issues that may need serious code to fix:
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:

http://openacs.org/doc/openacs-HEAD/images/adminia.png