Forum OpenACS Development: New Directory of OpenACS Sites
We are planning to renew the OpenACS Sites directory with a new full-featured one. More media, more data, AJAX an so on...
For details see Directory of OpenACS Sites.
Any suggestions are welcome.
- 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.
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.
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?
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.
Malte - Yes we definitely hope to continue to improve documentation and perhaps Miguel can also provide some in Spanish.
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.