UI Prototyping
This is a step which can be completely skipped if what we are building is a batch (or headless) tool. As a TD, you will find that there are many tools which can and must be written without accessing a user interface, especially if this tool is part of an automated workflow.
If the tool we are building is an interactive tool, then the next step will be to put together a quick prototype of what the UI will look like. When prototyping the UI we need to take into consideration all of the stories that were written down during the previous stage. Well, not really all of the stories, but we do need to include GUI to address the most important stories.
To do the GUI prototyping you can use any tool you please, as long as it allows you to express your idea clearly. I have sometimes used photoshop for this tasks. Sometimes I also use affordable wireframing tools such as moqups or balsamic. Whatever tool you are comfortable with, should work.
Avoid going into small details such as colors, size of fonts and button separation at this stage. Those are details that can be addressed later on. What we are really after here is to make sure that our GUI allows the artist to perform all of the tasks that they need to do, in a way that is easy to understand and as logical as we can make it.
Once I have a GUI prototype that I think will work, I tend to share it with the artists that will be using the tool to get feedback. The feedback that you get from the users can be extremely useful, especially when it comes to improving the usability of your tool.
Remember that a tool is only as good as it is used, You could build the most amazing tool that does the craziest things, but if the GUI is something that the end users cannot understand, then such tool will not get used.
Since we are building a simple I/O plugin, then I believe all we need is a field where the user will provide the materialX file for an object. For exporting, we could add a button here or try to integrate the command as a menu entry in the File->export menu of Blender.
Design
Once we have a GUI that we know will allow us to perform all the steps in the most important stories, then we are ready to begin the software design stage. This is the stage that tends to freeze up those who are new at coding. Questions such as What functions do I need? Should I use classes? How do I structure my code? are important and it is at this stage that we will figure it out.
I always try to find a balance between how much design I do before I start exploratory coding. Why? well, based on my experience, no matter how much I design something, I almost always run into small issues in my design once I start developing. This could be due to how a certain API requires you to interact with it, or slight modifications on how data is returned from functions, etc.
When I design software I normally use Object Oriented Programming. Here is why I'm a big fan of Object Oriented Programming; having the ability to create your own custom data types which can perform custom actions and that co-relate to constructs in the real world is extremely useful and it can make programming so much easier once you wrap your head around how OOP works.
To design my classes I like to use a UML editor program to create a class diagram. There are tons of free tools available for performing this task. In the past, I have used UMLet and Violet UML. Now, full disclosure here. I am not a UML expert by any means. UML can be quite complex since it is designed to model all sorts of different interactions and scenarios. I only know what I really need to use, which is how to create class diagrams.
