Developing such tools has been part of the plan from the beginning. We did a lot of exploratory work at the same time as we were developing the AIM style of workshop. Some examples are:
A glossary (Representations of surface groups)
Lesson learned: almost nobody is excited about creating a glossary by itself.
Another lesson learned: you need some control over the contents,
or else it will fill up with spam.
Another tool we built was highly specialized, designed to help the participants of one workshop display their results:
The minimum rank of graphs catalog.
Note that this is out-of-date, not due to a lack of energy on the part of the people doing the research. They have a lot of recent results which they would like to add to the list, but the software needs a bit of work and I don't have the time to do it.
Lesson: be aware of how much time it take to maintain and add enhancements to software that weren't anticipated when you started the work.
Lesson: don't write software that you can't commit to maintain.
Another tool we built was a very general outline tool, designed for ambitious projects like writing a survey article or organizing all of mathematics:
A general outline tool (L-functions and random matrix theory)
Lesson learned: you need professional programmers, because just a few minor quirks in how the program operates will turn off most users.
For the followup, we recognized the need to keep problem lists up-to-date. Many AIM workshops produce a problem lists that capture the current state of research in that area. But the list will become obsolete very quickly if nobody updates it.
This points to the need to have problem lists that are easy to maintain. Let me tell you a couple of lessons we have learned.
First: one person, the web liaison, writes the first version of the list. However, if only one person is responsible for the list, then it usually will not be kept up-to-date. For example:
Lesson: you need multiple people to keep things current.
A specific example of a one-person list non being kept up-to-date is Mladen Bestvina's list of Problems in Geometric Group Theory (idle since 2004). Mladen asked Rick Scott, from Santa Clara, to make a wiki version of the problem list, with the work distributed among 20 people.
Problems in Geometric Group Theory
(problem list in a wiki)
Lessons: 1. (Again) one person, even Mladen Bestvina, is not enough to maintain a problem list. Kirby's famous list of topology problems is another example.
Lesson: Modifying wiki software is not feasible in the long run.
Lesson: Nothing else out there is adequate, either.
Another lesson is that poorly written code and highly specialized code is costly to maintain. So it is a mistake in the long run to think of the problem lists as an isolated activity. If you think about it the right way, a problem list is a document with a very simple structure:
introduction
Section: intr to section
"problem block"
[[repeat]]
[[repeat]]
bibliography
Here is an example:
Components of Hilbert Schemes problme list
This problem list was created by the web liaison from the workshop. The format is pretty much as I described, and if you browse the web for problme lists you will find that nearly all lists follow the same general format.
There are other documents with a similarly repetitive structure such as a glossary or annotated bibliography.
So this points to the need for a program that handles not just the problem list, but rather a variety of documents, each having a similar but not identical structure.
This is the Collaborative Authoring Tool, the CAT, which you have read about in
the material we have prepared for you.
What we propose to build is a computer program that lets a people
collaboratively write a variety of different type of documents.
The tools that directly support AIM workshops, like
problem lists, glossaries, and annotated bibliographies would
be served by the CAT, but there are a myriad of other possibilities.
Lesson: you shouldn't build a huge complicated program, that operates in a fundamentally new way, all at once.
Talk about: structured documents, levels of access, intuitive interface.
And so we decided to build the AimPL tool that handles the Problem Lists, as a learning experience to put us into a position to build the CAT. Things are going well, and we are close to being ready to build the collaborative authoring tool. So I would like to show you a bit about the AimPL.
[LONG DEMO] Components of Hilbert schemes
Principles:
Highly structured
Levels of access
Intuitive
Looks good!
JSJ Decompositions
[END LONG DEMO]
Rob Beezer has a lot of experience at putting mathematics on the web and he has also thought about the process by which people could work collaboratively on large documents, so I would like him to share his perspective.
[BEEZER PRESENTATION: his linear algebra book with knowls, and his thoughts on the need for and feasibility of the CAT]
Knowls aren't that different from regular links, but they make a big difference to the user experience when you are reading a web page. [[say more]][[put knowls in the AimPL]]
The CAT will handle many but not all of the documents to be used for AIM workshops. Another enhancement that we plan for the workshops is better management of the participant list. Currently, the list of participants for a workshop is just a bunch of names and email addresses. That is pretty standard: if you are going to a conference they send you a list of participants.
But it is possible to provide a much more useful participant list. Imagine you are getting ready to go to a workshop, you look at the participant list, and you remember thinking that one of the participants might have a useful suggestion about a problem that interests you. So you decide that you want to take a look at some of their papers.
You could google the person, find their home page, hope that they post their papers. And if they don't, you could go to math reviews or the arxiv to look for more information.
But it could be easier: the participant list could be online and could have links to all that information, sitting right there in front of you.
I'd like Brian to give a little demonstration of how this is possible.
The AIM People tool
Most of these tools are only somewhat useful in isolation. The real benefit comes when that work together.
We have started having the Problem List and People tools work together. When a problem is posed by someone, it is useful to see their name, but it is more useful to have them marked in a way that helps you organize the information. We have that feature partially implemented in AimPL.
AimPL (JSJ Decompositions)
Where we are headed in the long run, after we have enough of the individual tools, is a Project Forum which gathers together the tools that will help mathematicians initiate and sustain collaborations, both small and large, over a long span of time. These will be designed and tested with AIM workshops, but it will be a valuable resource for the entire mathematics community.