This content is incomplete and may be inaccurate, feel free to look around & please check back later for updates.
- Modular. The platform would be split into logical components, each a product in itself. This allows for multiple individuals or teams to work individually on each product without interfering or (merge) conflicting with the others. All API’s would sit in an API product, all videos would be rendered with a video product, communication to and from services such as Google and Facebook would be handled with an IO product, and so on. This has numerous other benefits so I might break this out in to a dedicated explainer or article later.
- No AJAX. The UI was to use a standard LAMP stack so everyone could understand it, nothing was hidden, and page loads are baked in meaning no need to keep track of statuses or triggers for refreshes of components. It also removes a layer as no dedicated interface API’s are required.
- Simplified interface. Using a component library (CSS framework) for the interface allows for a friendly user interface for the customer with a consistent look and feel, without the need for expensive staff at this stage. A huge head start.
- Shared components. Utilising shared components & functions allows for tremendous time savings. The downside is the same as any shortcut – it’s a cost later on (technical debt). However the aim is to get a product out there fast to solve customers problems. Once the customers are onboard this can be addressed – and often the product will be different/change anyway.
- Shared. A hidden product would house shared components and libraries allowing for rapid development across all modules/products through re-use, while also providing a cohesive feel to the entire platform of products.