Forum OpenACS Development: New Directory of OpenACS Sites

Request notifications

Collapse
Posted by Miguel Cordova on

We are planning to renew the OpenACS Sites directory with a new full-featured one. More media, more data, AJAX an so on...

The idea is making a new package (websites-db) using dynamic-types and categories to create a data structure to collect metadata about openACS sites.

For details see Directory of OpenACS Sites.

Any suggestions are welcome.

Collapse
Posted by Malte Sussdorff on
In general I like the idea, I have some concerns though:

- It would make sense to use contacts for storing the company data. In your proposal you are just saying "link" so that is fine, just want to make sure you are not keen on adding something like "country" or "company name" to it, as this information really belongs into a CRM and I would love to finally get a list of OpenACS member contacts and their companies on openacs.org, but this is a different story.

- If you are going to use a lot of Ajax as a showcase, I suspect that you are going to do a lot of documentation on *how* you did it and why. This will be essential for future use of Ajax in the toolkit.

- We had some discussion already to collect new sites using a question upon installation of OpenACS if the site might report back to openacs.org about it's existence. Therefore I would ask you to take this into account when designing the module so we can have an easy mechanism for reporting back.

Collapse
Posted by Olga C. Santos on
Going further Malte concern: "If you are going to use a lot of Ajax as a showcase, I suspect that you are going to do a lot of documentation on *how* you did it and why. This will be essential for future use of Ajax in the toolkit".

I would like to remark that there is currently a lot of effort going on in .LRN community to achieve a high level accessibility in .LRN. Therefore, AJAX developments should follow this working line. In this sense, I suggest you (in case you are not aware of it) to take into account the Accessible Rich Internet Applications (WAI-ARIA) Suite concerning accessibility of "Web2.0" technologies including AJAX.

There is also a document from IBM, one of the partners in the aforementioned consortium that built the Dynamic Accessible Web Content Roadmap regarding some of the challenges that AJAX technology poses.

Olga

Collapse
Posted by Caroline Meeks on
Thanks Olga,

The use case for this functionality is someone new comes to the site wants to learn about OpenACS. One of the things they will want to do is look at sites that are built on OpenACS.

It looks like OpenACS will shortly become a leader in accessibility! Thus we should certainly expect that people who need accessible web sites will be coming to OpenACS.org to find out about what they could accomplish with OpenACS. Having the directory of sites area inaccessible would be very bad. Perhaps we could meet with Miguel and talk about how we can be sure it is accessible or an accessible alternative is available.

Also, are there questions we could ask site owners/developers while they are registering their site that would be helpful/interesting to potential new users of OpenACS who are interested in accessibility? What can we ask that will help potential users interested in accessibility issues learn about and connect with existing sites and users also interested in accessibility issues?

Thanks,
Caroline

Collapse
Posted by Tom Jackson on
Is the purpose of this package to promote OpenACS or the underlying technologies like dynamic-types and AJAX? It seems to me that most of the information you wish to collect is available to the APM, and the submission could be nearly or completely automatic. Maybe it would be nice to create an OpenACS package which could self advertise local information, so that when it changes you get automatic updates. Then your websites-db could consist of links to these sites and pull in the data.

At any rate, it would be helpful to step through the process of data collection that you expect site developers to use to provide this information to you. The easier it is, the more likely it will be used. Updates will be important, because over several years you may have so many changes that are not reflected in your list that new potential developers will discover your link rot, and get the wrong idea.

Collapse
Posted by Caroline Meeks on
Tom - Good points! I have added more information to the wiki to try to address these issues.

Malte - Yes we definitely hope to continue to improve documentation and perhaps Miguel can also provide some in Spanish.

Thanks everyone,

Collapse
Posted by Tom Jackson on
It looks like Miguel made a similar comment on the wiki two days ago. The additional suggestions that I see don't really reflect what I was thinking.

Most important is that the directory remain up-to-date. It is a big red flag to find a list that has old links. The only way to ensure this is to have local sites publish information, which can be grabbed on occasion.

Second, it seems like it would be better to create a new package to collect and publish the info, otherwise sites will need to update their APM for the new functionality. The new package will probably develop more rapidly than the APM. Also, information will probably come from more places than APM, and the package might depend upon non-core packages, which the developer might not want to install just to get the necessary APM package. Maybe the design of the websites-db package would satisfy the collect/update/publish functions.

Third, a separate package would run at OpenACS.org to grab the published data and make it available to promote the listed sites and the usefulness of OpenACS.