I thought about distilling an argument for the sake of a modeling exercise that would feed into and inform our preliminary implementation plans. I below argue that upon moving from interaction design to implementation we need to come up with a model of relevant data sources available in ICARDA and how these can support the activities we designed for.
Evidenced by our dynamic prototype, we have adequately addressed our software requirements (functionality) and how it unfolds in terms of interaction, organization, and layout.
Moving on to translate our design to a functional implementation, we need to base our technical decisions on a technical design, which addresses technical details and corresponds directly to computational data structures (e.g. databases tables, variables, lists..) and operations (e.g. data retrieval). In the general case this would imply that focus prior to implementation should be given to engineering our data sources (e.g. databases), business processes (e.g. the publication workflow), and the relationship in between. However, In our specific case the following conditions govern our operations:
- We do not have the authority nor the resources to design various databases to be used by ICARDA’s units. This restricts our activity regarding data sources to analyzing and understanding what data exists and where it lives (we leave the "how to retrieve it" to guru developers).. Documenting data sources will also be of high value for the main development phase.
- It is out of the scope of the project to re-design the publication workflow. On the other hand, we need to review and document the various roles and tasks of authors and users. This would illustrate different parties acting around the website, their responsibilities, and the outcomes of their online interactions.
- Engineering the relationship between our data sources and the activities they should support is of high importance. We have actually traced relevant sources data in ICARDA, as well as designing for supporting activities around promotion and electronic publishing. What remains is this technical vision on linking data sources and functionality. Luckily, this shouldn’t be a complex task as our activities revolve around publishing, viewing, and retrieving information. Also, Drupal already takes a database-oriented view, which makes this engineering effort a matter of understanding our databases and constructing adequate queries.
- Drupal kindly handles many other aspects of the workflow, such as role management, content authoring, and publishing which is kewl!
In a nutshell, I think this calls for doing a data modeling practice where we define relevant databases and data relationships in light of the activities we designed for. Then we are ready to go code as never before!