CoolStateLA/March 22, 2008

From CSWiki

[edit] Agenda

• Introductions. Dhaval Joshi and Lakshmi Nidamarthy. Decide on projects. Here are some possibilities. (These are not necessarily projects, just ideas.)
  • Develop the community interface. It's not clear how much of this Deidre Foster-Smith will be able to do.
    • Install and integrate a community forum system.
    • Develop a mechanism for community members to suggest leads.
    • Install and integrate a calendar, including extracting information from the university's calendars. Allow community members to add events—to be approved by CoolStateLA staff before display. Include events from Caltech, the LA Central Library, Zocalo, local bookstores such as Vroman's, The Huntington, The Norton Simon museum, Occidental College, local churches such as All Saints and other community organizations, events listed in the LA Times, etc. Accept RSS feeds for events. For example, USC has RSS feeds for a number of calendars.
  • Make parallel versions of the staff/public system using Spring/Ajax/Ruby-Rails/Flex/… .
  • Develop a set of interfaces so that parallel versions (such as the above) can be substituted for each other.
  • Integrate Lucene into the system so that it indexes and can search the relational database and Fedora. It would be nice if it could also index the database used by the CMS if one is used for the public/staff version.

• Joomla!. Deidre Foster-Smith, Dhaval Joshi.

Generate Joomla! pages automatically by looking up information in the relational database and extracting content from Fedora. If necessary contact Jonathan Berney, who developed a PHP - Java bridge as part of his CS 491a project. Alternatively, get together with Kaleem to determine whether you should access Fedora directly via the web.

• Development environment. MK.

• Use cases/Mock-up. Muhammad Lodhi, Ren.

The next step is to create a site mock-up by converting the use cases into page mock-ups. This should start immediately—even if you don't feel confident about the use cases. Each use case should have an associated page mock-up. Starting next week, we should think about the use cases in terms of the mock-ups. The mock-ups should be linked together reflecting the possible transitions in the actual system. This will give us an immediate feeling for how the system will appear to the user. And it will give the customer an opportunity to determine how well it suits his needs.

Work with MK to determine where to put the site mock-up.

Each page should include (a) a sketch of what the page looks like (and when the view is developed the actual page) and (b) a description of the use case it satisfies.

• Basic Architecture. Muhammad Lodhi, Ren.

• Documentation. Muhammad Lodhi. Determine how and where the system documentation will be organized and kept so that it will be easy for new people to learn the system.

• Database schema. Sepideh Nazari, Ishani Vyas, Deidre Foster-Smith, Muhammad Lodhi, and Ren.

• Page development. Sepideh Nazari, Ishani Vyas. Do we want to split page development into a view part and a model part?
  • The person responsible for the view will generate page views to be used both in the actual system and in the mock-up. (But this is not a justification for delaying the development of mock-up sketches.)
  • The person responsible for the model will write the functional code.

• Fedora. Kaleem Rana, Farrukh.

• Feed reader. Mark Luntzel.

• Next week and following: we'll meet at 1:30.