Home
The Toolkit for Online Communities
17598 Community Members, 0 members online, 2407 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Development : Merging of /admin and /acs-admin

Forum OpenACS Development: Merging of /admin and /acs-admin

Icon of envelope Request notifications

Collapse
Posted by Dan Chak on
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.

Collapse
Posted by Talli Somekh on
Dan,

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?

talli

Collapse
Posted by Dave Bauer on
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.

Collapse
Posted by Stephen . on
It is a confusing interface and improvements would be great, but unless you can preserve the distinction between site-wide admins and subsite admins, I'd object.
Collapse
Posted by Don Baccus on
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).

Collapse
Posted by Jun Yamog on
I think it should be kept separate.  But I think we should do the baby steps now.

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

Collapse
Posted by Dan Chak on
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.

Collapse
Posted by Lars Pind on
Dan,

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

/Lars

Collapse
Posted by Jun Yamog on
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.

Collapse
Posted by Don Baccus on
I don't think we need to move the files (I do think they make sense where they are) but there's certainly no reason not to decorate the subsite admin page with links to site-wide admin pages if the subsite admin also has sitewide admin privs.

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?

Collapse
Posted by Torben Brosten on
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?

Collapse
Posted by Stephen . on
My admin page has links to Site Map, Groups, Group Types etc., and at the bottom of the page it says  "To administer the site-wide services of OpenACS, use /OpenACS Administration/".

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

Collapse
Posted by Don Baccus on
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.
Collapse
Posted by Lars Pind on
Don,

Why can't we depend on portals for 4.6?

/Lars

Collapse
Posted by Don Baccus on
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.

Collapse
Posted by Talli Somekh on
Would the decision to hold off on focusing on a large improvement of the admin UI be due to energy and time or due to priority?

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?

talli

Collapse
Posted by Lars Pind on
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

Collapse
Posted by Don Baccus on
Right-O, Lars.  Let's see how many folks get involved with 4.6 when we fire the starting pistol and then decide ...
Collapse
Posted by Joel Aufrecht on
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