Introduction
We have recently launched a large Drupal 8 Web system. The purpose of this article is to review and reflect on the workflow.
Firstly, I’ll identify the problems encountered, then I’ll continue with their evaluation.
Challenges
- Gathering the requirements and understanding the business logic. Communicating with the client.
- Graphic design.
- Prototyping and development.
Solutions
Gathering the requirements
It was impossible to understand all the requirements in one sitting. In fact, before one section of the project was developed, the requirements for another part of the system were already changed. This was especially difficult because even the client struggled to understand the business logic. This is perfectly normal and to be expected in such organisations.
The project was divided into three sections. We defined different deadlines for each of these sections. That’s said, each section was a system on its own. Once a project section was developed, it was pushed live for the client to add the content. Other sections were merged later. This allowed us to proceed with the project and regularly add new changes.
We communicated with the client over numerous emails, as well as in person. It was a service for a big organisation with many different stakeholders, often disagreeing on certain core aspects of the website. It was important to assign one person, or a small team on the client’s site to be responsible for communicating with us. I dare to say, that without this step the project wouldn’t be a success.
Once the tasks’ functionality were gathered, we added them manually to the shared spreadsheet, including the estimated time and delivery date. This worked well, as it was easily accessible by the executives, project manager and the client.
Note however, that we didn’t have regular scrum sprints. The team members were working on various projects simultaneously, while the client was adding the content to the already published part of the website. This way we delivered junks of the functioning website to the client on regular basis. Note, that no part of the website, even those already published, was considered as complete. Small fixes to the front-end were added as the system evolved (this is especially difficult to explain to the client, or to win a tender) .
The wireframe of the website was layout in Adobe Illustrator. It included the title of the page, content type, hierarchy and taxonomies. It was used by all the team members everyday. It visualised the business logic. It was also used by the client to prepare content.
Interestingly, marking what was done one the wireframe was rewarding for the team members as we could clearly see our progress. The long wireframe looked like a loading bar with additional sections being marked as complete – gamification.
I am still looking for a way to auto generate a wireframe from a spreadsheet or ideally InVision or equivalent.
Graphic design
We’ve used a modular atomic design. Rather than designing web pages, the UI team designed modules.
An example of a UI module is a text field, image with a caption, or automatically aggregated news listing based on certain taxonomy.
Is was crucial so that the design and development members were communicating well. This is why, we came up with naming conventions that were universally understood. This way we avoided any assumptions.
Majority of the graphic design was layout in Adobe InDesign. This allowed the designer to simply drag and drop the already designed modules for fast prototyping. The client also saw the graphic concept straight away, which was also an important aspect.
It was crucial to keep the number of UI modules to minimum in order to keep the system uniformed. For that reason the existing modules needed to be versitile and flexible. This also minimised the design and development costs. Of course there were exceptions.
Prototyping and development
We’ve used incremental methodology. We’ve used scrum practices, even though it wasn’t fully book example scrum workflow.
Because of the scale of the project, it was necessary to use a high level of abstraction. The UI modules were mapped in the code as its own entities. We followed the same naming convection in the code to keep everything standardised. Those blocks were flexible to fit many roles.
In the end, I could focus only on one Graphical UI module or a Drupal module at once, both front end and backend. This way the system was modular, both from interface and code. The developer could focus on small manageable fragments. At that time I was the only developer, however, this workflow would allow the project manager, scrum master, to assign small jobs to other developers, who wouldn’t at all be familiar with the projects.
As with any projects, we had to allow for exceptions.
Conclusion
This workflow certainly worked in our scenario, as we delivered what was required, within a deadline and up to a good standard. Of course this isn’t the best workflow.
Next time I will definitely strive to follow scrum principles more and to have regular sprints.
Sticking to development standards, avoiding assumptions and good documentation was necessary.