Forum OpenACS Development: Groups UI Issues

Collapse
Posted by Roger Williams on
Here are some issues that I have been chasing for an ACS4 rollout I am working on. DonB asked me to share these as an impetus for design discussions.

..you might want to start a thread in the 4.x design forum describing exactly what you intend to provide. That way others can chime in with whatever additions or changes might be needed based on their experience.

I basically view these as requirements, and I intend to provide some proposals later, as I am actively working these to resolution. Note that these are all ACS4Tcl, so I am not sure if they are already fixed in OACS4.

Groups UI hurt sheet

  • a programmer's UI; completely unusable for non-programmer admin
  • exposes object model with incomprehensible terms (i.e group type group!)
  • magical group created during subsite-creation (i.e. not documented)
  • magical group not listed under groups
  • screens to add member to groups enforces a hidden constraint
  • cannot create a relation except one that inherits from MR, CR
  • more views needed (e.g. what groups am I in?)
  • can be "fixed" with simple effort (i.e rearranging screens, exposing useful internal data)
  • prognosis: small bugs; mostly works; good internal design

Regards..

Collapse
Posted by Don Baccus on
First of all, a global response to all three of your posts:

No, these haven't been fixed in OACS 4 and I'm sure we'd find folks eager to help move your changes into our version.

Secondly, of the three posts the groups UI sounds like it is perhaps the easiest to fix.  Maybe it should be tackled first?

Thirdly ... thank you for starting these three threads!  We all recognize the need for improvements in these areas but have not had any specific discussions thus far.  Hopefully these posts will serve as a catalyst for such discussions, leading to useful proposals followed by improvements being implemented.

Collapse
Posted by Roger Williams on
I perceive the Groups UI to be the easiest (to "fix") only because my list of requirements for this one is the easiest. The requirements for the permissions sub-system is the "hardest".

Now I have a roll-out due early next year. I typically attack first the area I am most worried about, and I think of the permissions-objects-context_id area to be the one that I do not have my head completely around yet. So, of these, I am spending most of my time right now on this area, not to speak of search, webmail and some other areas needed for our project. And I did figure out another permissions problem the other day that I need to post in the Testing forum and in the SDM.

My eventual goal is that sometime in 2002, I will be able to migrate my client over to OACS 4.x semi-smoothly, with the functions I am improving (if not the screens) included in that release (maybe a production 4.3).

That said, it is interesting to me that this thread has a dearth of respondents. This fact supports my theory that this area is the most opaque. Regardless, I will append my proposals in all of these areas in the coming weeks.

Regards..

Collapse
Posted by Andrei Popov on
I would not go as far as to say that this is a very ``opaque'' area :).  Improvement is definitely needed, and the first one that is needed is a sample walkthrough with some meaningful example how groups/group types/relationship types/users get pieced all together to create a robust and flexible permissions/user management structure.  Whatever is in the /doc section of this site (and any site having [O]ACS4.x installed) is, well, stimulating, but far from clear on this...

Anything changed since you last touched upon this?

Collapse
Posted by Roger Williams on
Opacity in my mind implies fogged up or cloudy. So when I use a piece of software that has many behind-the-scenes (hence the term magic) behaviors that are not exposed in the UI, it seems opaque.

In any event, I have increased my knowledge about this and made some minor changes. I just sent a note to DonB about going thru this area with a wide plow, amd posting the design docs on this board similar to some other stuff I published last week.

My earlier beefs are listed in the hurt sheet above. Now I have: more beefs, more internal knowledge and (finally!) some ideas as to how to clean this stuff up. My background tells me that you start from the things it does wrong and what the user requirements are.

I would be happy to start a thread about this (obviously I started this one). Let me know how/if you want to proceed, since this stuff has bubbled close(r) to the top of my annoyances list.

Regards..

One caveat: I have not been able to move over to OACS 4.5 yet. My project is still based on ACSTcl 4.2b. DonB and others perceive that the problems that I am talking about have not been fixed in OACS yet. But I am doing my testing/fixes in a slightly different environment.

Collapse
Posted by Talli Somekh on
Roger, I agree with you. This stuff *sucks* in the OACS. I am only sorry that we haven't had time to address it, as I said we would at the SF OACS social. Our solution has been in client projects to try to make them use it as little as possible, or even less than that.

Your work here is critical and appreciated. I hope it's the first thing we address in the next version of OACS.

talli

Collapse
Posted by Don Baccus on
As Roger mentioned he had e-mailed me a couple of days ago, resurrecting this issue and telling me that he's had time to think about solutions, as well as the problems.

The time to start a new thread, Roger, might be when you have a new document uploaded to new-file-storage.

BTW I moved a client's new site development from ACS 4.2 to OpenACS 4.5 in the time it took to dump the tablespace, reload, and diddle a couple of datetime things.  Just food for thought :)

Collapse
Posted by Andrei Popov on
I guess my brain was a bit foggy so that I mistook transparency for opacity...