Forum OpenACS Development: Site Map UI Issues
..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.
Site Map hurt sheet
- does not show application's type (i.e. package_name)
- allows sub-folders under applications
- mount vs. new-application subtleties are opaque
- inverse of both mount and new-application is unmount (maybe these functions should be distinguished by only a checkbox)
- delete of an applications node instance should offer to delete/move the data
- no way to rename application instance's title
- subsite creation in relation to group types is opaque (i.e. same as above)
- Main Site looks like it is above in the hierarchy but actually it is at the same level
- subsite sitemap admin looks OK at first; but allows permissions to be set for other subsites/objects (i.e. more "real" risk)
- inconsistent template usage
- prognosis: more functional bugs (when compared to groups/perms); needs greater effort to "fix"
Because I found the lack of this extra column confusing also, I ported the code for the additional column to PostgreSQL and can make a patch available for inclusion in OpenACS if there is interest.
I have not done any work to port the wizards stuff.
There is a discussion about the UI and folders in the OpenACS 4.0 Testing forum.
I have thought about this a bit, though, and wonder if it might not be made useful in the future. For instance, being able to mount a bboard under and SDM instance might be a useful way to provide a devoted set of forums relating to it.
I think we need more discussion of this particular issue. I don't see any *harm* in being able to mount packages under (non-subsite) package instances...
But in this case, I posted the other thread out here about this, because one of my guys did this, and could not figure out its meaning. In the dated UI book called About Face, the guy who wrote the original VB (and sold it to M$oft) talks about programmer-type interfaces with all options possible. This is what I refer to when I talk about smart defaulting.
A goal that I think can be realized using this system is to de-skill the admin task so I could give a non-programmer the control of their own sub-site and I would not have to include in my training don't use this button in this case, it doesn't make sense.
In my other server (where I put my original experiences with these applications) I guessed (and now I think it might be true) that several of these problems can be exposed differently to achieve this goal since I have gained a lot of confidence in the strength of the underlying design, and its authors, I might add!
I read those bboard posts. I did not jump in or reference those appends since I thought maybe a UI discussion board might be created. I have been chasing these issues for my project, and I had posted some of my issues a while back. I was not sure if these were just my "personal problems" . I have read some (well taken by me) references by DonB and BenA about newbies (e.g. guys with yahoo accounts) trying to drive discusions towards their own work/problems. And of course, getting OACS working period has to be the top priority.
Finally, Talli has a short message on his site about AdminUI that I found illuminating.
Here is the other thread in which I asked about the efficacy of this.
I did not in anyway mean to imply that you were "jumping in" or trying to steer things for your own means, I actually assumed the opposite.
I included the references I did because, personally I have found it difficult to track or even find ALL the discussions on this topic and really appreciatite with various postings references other threads where similar discussions are occuring.
As for getting OACS working period, I think we're all in the same boat. I've got a well received site running OACS 3.x inside my company and want to move to OACS4. I need to get OACS4 working then migrate my old site to, including several internally developed applications. I aplogize if my contributions are "below the bar".
Thanks for the reference to Talli's pages about the Admin Interface.
> other packages *other than* a subsite instance. None of the
> current packages have any functionality that makes that desirable.
Actually, unless I'm mistaken, I believe ETP uses this mechanism to support the notion of subtopics. So, for instance, if you could created the following structure:
Main ETP page --> ETP News (subtopic) --> ETP FAQ (subtopic)
in the sitemap, the News and FAQ subtopics would actually be subdirectories under the Main ETP page, but all 3 would be instances of the ETP application.
So, I believe there is good precedence for this very thing.
So my question is, are these sub-topics relly applications? I think so-called "real" applications do this by pkg-id (pls correct me if this is wrong).
BTW, *after* I got this working it occurred to me how CMS (and by reference ETP) could be used to make lots of "applications" of this type.
Perhaps packages need to specify whether or not such mounting "makes sense", and the site map UI smart enough to take advantage of this knowledge?
Another "site map hurt" which also ties to package-level information being kept is the distinction between "applications" and "services". The Site Map UI suggests rather strongly that one not map services, even though some (acs-workflow, for instance) do provide web pages for tinkering. I "fixed" this confusion for acs-workflow by auto-mounting it during installation. A more general "fix", which probably involves explicitly declaring whether or not a package includes mountable web pages (rather than assuming "applications" do and "services" don't), is needed.
I'm sure we can add so much to this list that Roger could be kept busy working on Site Map UI issues for months! :)
From my understanding, ETP does a similar thing to your news application. One of the parameters you can set is the ETP application, which can be "default", "news", or "faq" (or roll your own if you like). Depending on its value, the mounted ETP instance will behave differently.
Sorry if I'm not explaining it well. I'm doing a poor job of juggling sitemap and ETP jargon. The best thing to do is install ETP, mount it somewhere, create a few pages and subtopics, then check out the sitemap (ideally, with the "show package name" patch installed). That should definitely clear things up better than my explanations! :)
Don, I totally agree with your suggestions for the sitemap. And, in general, while there are many issues with the APM, sitemap, permissions, etc, I'm happy that I can find ways to use them, even in their current state, to get stuff done. And I'm even happier to be part of a community that will tackle all these issues over time with the goal of making OACS the best product of its kind.
The post, though, was a discussion that Michael Feldstein and I were having. We actually discussed precisely these issues about a month ago. Michael thought that the Site Map UI was the most critical thing and I thought it was the permissioning and user admin UI that needed to be fixed. He suggested we come up with use cases for both problems and he would concentrate on the Site map and i would do the user admin stufff. Alas, I think we both got busy and it's been on the back burner.
The short of it, though, is that IMO the admin UI is damn near unusable. Roger, I agree with 100% about these issues. We met at the SF OACS social, right? I believe that we spoke and I said that this is the stuff we were going to focus on because it's pretty much impossible to pass off a system to non-techies in the shape it's in right now.
So I'm down for tackling this prob too!
Here's another hurt for ya:
* Sub-site admins can mount any enabled package on the system.
The old ACS' closest equivalent was the group pages, where when creating group types and groups you could specify which applications a group admin could later mount. (speaking of group pages, we don't have any... I think we need a group/group-type package...)
As it stands it's probably a security risk to allow untrusted users admin rights over a sub-site, which is a shame. No ASP style ACS...
I used the Intranet module only a could of times under ACS3.3 (I think), and it was quite nice. I also saw some dream fragments about how the 4.x Intranet module was going to be really well done with sub-sites and portals, etc.
But the subject question still evades me. If you had an integrated set of applications (e.g. ttracker/WF), why could they not be mounted cleanly in a sub-site (or a sub-sub-site)? Alternatively, how is it a more elegant design (to the users or to the programmers) to have its sub-apps mounted under some main app?
(Actually, I wanted to understand this!)
- familiarity with the external view of the enabled applications
- trained in community-building tasks
- familiar enough with the external view of the permissions/groups subsystems to perform his tasks
- connected into a "community" of sub-site admins
- not normally taking a technical orientation
This is the kind of person that I think/thought the sub-site "application" is built for. Sometimes I am naive, but I believe that is mostly achieveable with the current design.
You certainly could build yourself an intranet right now by mounting a new instance of the acs-subsite package at /intranet and making 'Herbert' the admin. Herbert would then create folders /intranet/bboard and /intranet/ticket-tracker and mount the appropriate packages. Then Herbert would fire up emacs and create an index.tcl / index.adp pair of pages that linked to bboard and ticket tracker and contained whatever else he needed and place them in the file systen at www/intranet.
An intranet *package* would be mounted at /intranet and would already contain the 'portal page' functionality Herbert just programmed and would automatically mount the bboard and ticket tracker packages, and would do alot more besides.
I don't know why a sub-site is 'cleaner'. A sub-site has specific functionality -- It provides a generic admin interface for mounting packages. ETP, Intranet, SDM are examples of packages with specific functionality that must be programmed, and may make use of existing packages by mounting them themselves.
Obviously programmers like to make hierarchies, and maybe it is not a good idea to make another one, but I am thinking that to the user all of these applications are not "equal". I guess I was thinking that lack of a "new-sub-folder" link would give them the impression that those are different. Maybe this is a distinction that should not be made.
<p>The portal they're shown will not give them the option to mount packages willy-nilly, or (worse) dismount them, but will be tailored to the specific administration taaks they're allowed to have.
<p>So this approach is a bit of a hybrid one, i.e. making use of subsite's user management semantics but limiting the ways in which a professor can screw up his class site.
<p>At least last time I talked to Ben that was the plan...
I have no knowledge of dotLRN or any idea of what OF is, but I can understand (I think).
I thought of Stephen's characterization as akin to having a GeoCities id. I do not know whether they provide any applications to put in your "site", but certainly you are not "trusted" by them. In fact, most of those sites are evidently untrusted.
I know that was an original dream of ACS 4.x, but I did not think that it had the infrastructure to support a "sandbox" concept that I guess that GeoCities and sites like it have.
I was/am looking for the more modest goal of just allowing someone who my organization can trust be able to navigate this thing with having to know any hierarchies (or even what a hierarchy is). If that can be accomplished by other means or screens (sorry!), I am all for it. I definitely do not want to cut out underlying function, just expose what is meaningful to the intended audience.
In the other thread, you refer to CMS as a bad design. I have purposely stayed away from it for the very reasons you list (i.e. own login, own skin). It seemed completely unintegrated. I could guess that there is significant function buried inside, but these other areas (i.e. permissions, et.al.) seemed integrated underneath. I am just trying to get them integrated and with a meaningful interface on the outside also. My study of all of the doc makes me think that this is achieveable.
What I was referring to was Stephens characterization of an intranet package being a package aggregate, if you will, that would mount the various pieces (bboard, etc) needed automatically. In dotLRN a "class" (in the school sense - a group of folks being taught a subject by a teacher, as opposed to say a Java class) will be a package that can be mounted and that will automatically mount a bboard instance, calendar instance, etc. And set up a bunch of portals and portlets that will set up a standardized page set for the class (so students will see very similar web pages for each class they take).
I wasn't referring to Stephen's comments about the ISP selling webspace example ...
It has to do with multilanguage support in dotLRN. If I create a community and in the title box I write the title with Greek characters
the community is made ok but when you try to join it you see that the URL part of it has Greek characters in and the browser does not understand it.