Content modeling
Alternative 1: "Hard-coded" fully functional prototype instead of a time-consuming mock-up
One first make a hard-coded content driven prototype, with prototype level content placed in the Vuex store in order to then properly hydrate pages and components. This, in place of a mock-up, which is just a waste of time when we can so quickly prototype with Nuxt.js/Vue.js/Vuetify.js
Once this is done, the content model can be abstracted out of the fully functional prototype using UML design tools, in function of the requirements, stakeholder needs and marketing hypotheses in function of the current business model. Then the SCS and CMS implement the content model, and replace the hard coded hydration of components and pages in the Vuex store (app state).
Alternative 2: Create a scaffolded CWA without content, perform content model design, then implement and test the content model completely in the CMS and SCS
When there is a high degree of familiarity with the application domain, the content modeling may be done via design tools (i.e. UML diagrams), and content modeling can proceed directly with the CMS and SCS first.
This is what we have chosen to do here.
Initial version of CWA (following Alternative 2)
The basic objectives of the DurableDrupal Content Migration Rescue website are to:
- Explain the goals and the characteristics of the content migration rescue process
- Thoroughly document the building of the DDCMR website itself.
- Thoroughly document the initial case study (the migration of Drupal 6 based AWebFactory.com to a full stack JavaScript decoupled architecture).
- In addition to the case studies, include articles, books, and a blog in order to share resources.
CWA Tasks:
Once these tasks are completed, a staging instance can be set up, after which we will be able to proceed to deployment.
Content modeling
Alternative 1: "Hard-coded" fully functional prototype instead of a time-consuming mock-up
One first make a hard-coded content driven prototype, with prototype level content placed in the Vuex store in order to then properly hydrate pages and components. This, in place of a mock-up, which is just a waste of time when we can so quickly prototype with Nuxt.js/Vue.js/Vuetify.js
Once this is done, the content model can be abstracted out of the fully functional prototype using UML design tools, in function of the requirements, stakeholder needs and marketing hypotheses in function of the current business model. Then the SCS and CMS implement the content model, and replace the hard coded hydration of components and pages in the Vuex store (app state).
Alternative 2: Create a scaffolded CWA without content, perform content model design, then implement and test the content model completely in the CMS and SCS
When there is a high degree of familiarity with the application domain, the content modeling may be done via design tools (i.e. UML diagrams), and content modeling can proceed directly with the CMS and SCS first.
This is what we have chosen to do here.
Initial version of CWA (following Alternative 2)
The basic objectives of the DurableDrupal Content Migration Rescue website are to:
CWA Tasks:
- [ ] Initial case study: AWebFactory.com
- [ ] AWebFactory.com: Step one
Once these tasks are completed, a staging instance can be set up, after which we will be able to proceed to deployment.