Unlike almost all other software programs, iProjects allows you to extensively customize the software to suit the way you work. When updates are issued, it would be easy to over-ride your modifications, and change your system back to the “default” standard – but that would defeat the whole purpose of being able to customize the system to suit your practice.
Furthermore, iProjects has a database structure, and project records are contained as part of the database to enable the comprehensive cross-linking that design management requires.
As we began to work our way through these issues, the reasons why nobody has ever developed a comprehensive design management system before became obvious – it was NOT going to be easy!
To resolve this – how to update the system without deleting the user’s modifications and project records – required a complete re-think of the normal processes for updating software. We’ve done that, creating a new update process whereby all system content – system as well as project-based – is first saved, then the underlying iProjects framework separately saved, and the update base installed as a master with all content reinstalled over the new updated system. Because the old structure is saved, system administrators can blend their unique modifications into the new structure, with minimal adaptation.
We are explaining this in some detail to highlight what has been one of the most complex issues to work out in building the world’s first design management software program, and to point out what may be obvious: that it probably will take a bit of further work with early users to refine the update process so it works the way users will find really easy to deal with.
