Entelligence: Grant Application, Submission and Review

One of the more intricate websites recently completed by ISL Consulting is the grant submission site, Entelligence built for Jobson Healthcare Information (JHI) in New York. The premise of the site is familiar to many, especially in the non-profit world: users register on the site and submit an initial proposal (this site accepts grant proposals from young scientists for research in cardiopulmonary medicine).

There are strict deadlines for submission. These are evaluated in detail by a Steering Committee (SC). Deliberations are managed by a Chairman, who assigns reviewers and collates the rankings and comments from SC members online. These are confidential until a final, simultaneous online/offline voting meeting that determines the winners. As the function of the site shifts, the administrative interface changes.

The website’s behavior also shifts substantially for applicants and judges depending on the grant submission stage.

Drupal offered key site features like registration, extensive user roles and permissions, as well as the content management. Actions, via emails and onscreen messages help guide applicants through the process. The Entelligence grant review process, however, required a customized system familiar to the doctors from previous offline cycles. Without the flexibility to accommodate these requirements, Drupal would not have been the right choice. Drupal’s permission system enabled us to empower the Chairman to manage the flow of information without controlling the outcome and input of colleagues. Much of this process of interactions between documents, groups and individuals, however, had to be implemented through customization. Entelligence was also one of our first projects using the Acquia Network Program.

Design

Before coding began, the design challenge was to make something appealing to upcoming researchers in pulmonary hypertension. While many of these scientists are young, the site also had to appeal to experienced medical and industry professionals (mentors and judges). The navigation had to be prominent, with the calendar a key component. The site also had to convey a contemporary professional style to reflect a call for novel research.

Our solution was to come up with a design that used photographs of lab work and bright, contemporary colors. A subtle background of fresh water droplets helped to channel the materiality of lab work.

Once the design was approved, we built our own style sheet that meshed nicely with the Acquia Marina theme for administrators. The blue-green combination the client wanted made this choice very easy. Indeed, we find the Acquia Marina theme works very nicely for site administrators and for us to demonstrate functionality to clients even before real design work begins. We've found in using it like this that it is far superior in its professional corporate look to the usual installed Drupal themes.

For all the technical capability of Drupal, looks count for clients; and standard themes, in our experience, do not satisfy clients even during the prototyping phase.

The Process

Once a user has submitted an LOI, it appears on a Dashboard for the Program Chair to examine and then assign to members of the Committee for review. The Chair can assign a Project either on this screen, at which point the field turns green, or within the document via a drop-down that uses a User Reference field provided by CCK.
When Reviewers log in, they are presented with the LOI which they can then rate as Y(es) or N(o), in terms of whether the applicant will be asked to submit a full grant proposal. The Program Chair can evaluate the progress of Reviewers and votes on this screen below. Other Reviewers can see the responses of their colleagues at this early stage – represented below in the Category grids.

Once all of the LOIs have been submitted and reviewed, the system places them into Categories based on whether the votes are unanimous Yes (Category A), split (B), or all No (C). The Chair can break ties. Once the LOI process is over and done, the Chair or site administrator informs approved LOI candidates via email that they can submit the full application. The Chair or site administrator can then change the Project Status on the home page via a simple setting we put into the Site Configuration admin panel. This changes the home page indicator for site visitors.

This setting change permits previously registered users to submit their complete proposals. Once they login, their previous information is presented and new fields are exposed to upload a full PDF of their grant proposal and enter accompanying notes and information. Data management is streamlined by re-using the original LOI node form and having the user edit the original node. The form_alter hook allows us to present the appropriate fields for the appropriate circumstances.

When the second phase of submissions commences, the Chair’s dashboard changes to reflect the new steps, although the assignment and voting is now different. Grant proposals are rated on a scale of 1 to 5 (yes, like Drupal field weighting, the scale is counter-intuitive – 1’s float to the top, 5’s are sunk by their own weight). Votes are now also private – the reviewers cannot see the input of their fellow reviewers. Only the Chair is privy to all votes, and can override a tie, until the final stage when once again everyone’s rating and comments are visible to everyone else.

A second round of development utilized Views to create CSV files of user and application information. The site administrator can deliver detailed statistics to foundation directors and key stakeholders. The Views module, including some programming into its API, was used to create Summary pages that display all comments and ratings for each application. An add node form at the bottom of the comment display lets the site administrator or primary reviewer draft a summary of the comments that are sent to the applicant with their acceptance or rejection letter.

Workflow Module

In the first iteration of the application, we decided to not use the Workflow module and instead rely on customization using the nodeapi and forms hooks, which already provided all the necessary conditional information and triggers relating to an individual item and actions of individuals upon those items. The various treatment and display of items in this application were reflected mostly in the UI, for which these modules would be of little help. Our items are also dependent upon a master setting for the phase of the process, as well as a complex amalgamation of data contributed from a group, which is not built in to Workflow. Some messaging had to occur as a batch and is not reliant upon individual actions. Therefore we initially judged that using these modules would probably just create more work for us in terms of learning curve and adaptation to this rather unique process.

However, a second phase of development introduced some new wrinkles. The client required the users to signal their application's completeness during phases of the process, and an administrator needed to determine whether they were ready for review by the Steering Committee. Also, email events were needed to inform the applicants of their approval status at the time it was granted. These sorts of approval phases and notifications are the sweet spot for the Workflow module, and it proved to be sophisticated yet easy to apply, while eliminating some of the custom code that was formerly needed. We also used the integration of Views with Workflow to create administrative tools for Workflow related tasks.

Modules and more

We find this to be a recurring question as we expand our Drupal portfolio – whether to customize an existing module or build the functionality to fit the specific needs of the project. It always depends. This site used few contributed modules (besides Views and CCK); other sites would have been impossible without a score or two of them. We have learned to avoid modules for which support is lacking, and we are becoming increasingly picky about which modules we do use because incompatibilities and latent bugs are not worth the initial flush of enthusiasm at finding something suitable.

The inconvenience of maintaining module updates and testing module interactivity is one of the reasons – besides curiosity – that we decided to try the Acquia network on this project. Their basic compatibility test of key modules working together and install package was attractive. This makes updating site modules proceed with fewer inconveniences and worries.

After completing this rather complex application, we can envisage a more general version for a module or profile. This module would allow users with a certain permission to submit review nodes relating to the original node, and assign a ‘rating widget’ as the measurement for the review. Another feature of the module would provide the “dashboards” that would allow the reviewers to see an overview of the results from fellow reviewers. This module would provide specific actions and triggers that could be used to assist processing. Moving ahead with such a project would make sense when cases present themselves that would require such a module, and the features provided would be refined by that knowledge. This kind of feature set might suit client situations in the non-profit world where similar grant proposal submission and review mechanisms need to be deployed. There are also opportunities in the job application and project review process, another area where ISL is gaining Drupal-centric expertise and has larger projects underway. We look forward to finding ways to turn any of this learning and coding into a module for the Drupal community. If you have ideas, please weigh in.

Team

The project is currently led by Amy Shoemaker at ISL Consulting in San Francisco. The site was designed by Creative Director Joe Kraynik and themed by Senior Programmer, Jeff Turner. All custom programming was done by our CTO, Bob Hinrichs.