Data Entry Process :
Data entry scenario
I imagine that from each affiliate campus we'll be able to recruit several students who will do the bulk of the data entry of news and resources and perhaps some of the research information.
I think they would go to a url specific to the site they are contributing to and would have a login name and password controlled by a managing editor.
Once they've logged in, they would be on a page that would give them the option to choose to add a new entry or edit existing entries. This page could have a series of buttons/menus that give the student the relevant options. Alternatively, the page could look just like the end-user view but with add/edit options in the appropriate places. This second option might be useful (even if it is an alternative) because it would allow the reporters/editors to see what's happening and how their edits are changing the pages.
News & Resources Entry
The news and resource entries will be straight forward data entry.
In terms of the fields that are displayed, they will differ slightly depending on the type of news or resource being entered. We will want to look closely at this when you get to programming this. For instance, a Proposed Legislation entry uses an identifier unique to it (e.g., S-# for a Senate bill and H-# for a House bill).
Also, there are several type of entries that can be related:
- Proposed Legislation entries will have update entries as the bill moves through Congress. As long as the data entry person is careful to use the proper identifier codes for these later entries, we should be in good shape. We will, however, want the updates to be displayed with the appropriate primary entry (sorted by most recent last). This can be complex so I will need to develop directions for this in greater detail.
- Available Fund entries will eventually lead to Grant & Contracts Awarded entries. The latter should be distinct entries (and, as long as the user is careful to use the proper identifier codes, we should be in good shape). Available Fund entries will have also a field that identifies which government Program they are connected to (though not all entries will have this link since Foundations will also have Available Fund announcements). Finally, Available Fund entries will also have a field that identifies what Organization is sponsoring the entry.
Research Entry
The CBR Papers, Data, and Orgs & People will be straight forward individual entries.
The Issue Briefs (and, within them, the Policy Option Planning Trees) will be constructed from other entries. One way this could happen is to have a data entry page for an Issue Brief that has each of the sections as the divisions (scope of the problem, past policy, current policy, proposed solutions, key organizations & individuals, glossary of terms), each with two buttons: ADD NEW ENTRY and FIND EXISTING ENTRY. When clicked, a pop-up search box would appear to allow the user to add a new entry (appropriate to the particular section) or find an existing entry. Once added or found, a summary of the entry would then appear on the Issue Brief page. Each of these entries would have an EDIT and REMOVE button next to it so the page could be modified later [we will need to determine what information appears in this summary and how to handle the references for each in the printable version of the Issue Briefs]. The top section of each Issue Brief will need a Title, Goal Statement, and categorization fields (issue, level, location). Finally, the Proposed Solution Planning Trees will need to be programmed so they show up at all levels. Remember, Issue Briefs will be developed for the same issue at multiple levels and locations (Affordable Housing nationally, in NJ, and in Trenton). Note: There's one other idea here which would be to allow sites to indicate which option is currently in operation in their area. This might be handled in the EDIT option with an additional field that references this and then in the display that option might show this by color or bold or something. This is still a little sketchy so we can leave it for a future refinement.
There is one more data entry option: creating a proposed solution wiki. The idea I have here is to have a link on each proposed solution display page that would take the end user to a wiki page for that solution. This will allow for additional end users to contribute to the site, and help us create a community of researchers connected to the sites. I've known about wikis for awhile now, but just noticed that the option I'm describing has now shown up on Amazon.com. We would probably want these end users to first log-in before being allowed to make a submission on the wiki pages to help combat spam.
National vs State vs Local
One issue that will arise is when the state or national level editors will want to "raise" or "capture" or "control" an entry from a lower level so it shows up in the higher level. This situation will happen most often with research and resource entries. For instance, there may be a resource entry (say, a guide on fundraising) that is entered from a local site but is noticed by the national editor who wants that entry to show up in the national resources section. Another example would be a Policy Options entry that is entered at a state site but is selected to be included as part of a Planning Tree (which by definition would be available in all Issue Brief regardless of level or location (see above).
End User Submissions
We will also want to allow end users to submit entries on many but not all pages. For instance, end users could submit meeting announcements, CBR papers, but we would not allow them to create an Issue Brief.
Of course, these would be reviewed by editors before being approved for publication.
We would not require end users to log-in to be allowed to make submissions but we would ask them to identify themselves in the submission form so we could contact them if need be.
However, we will want a "member" registration and log-in feature to allow end users to "join", sign-up for email alerts, custom home pages, and so forth.