This post is a follow-up to the 7 part series I wrote on Decomposing Spotfire Projects. The idea first came to me when I documented a large enterprise project. I didn’t build it. It wasn’t my baby, but it was important to the company. Management wanted it documented in case the author moved on. I also think about this subject every time I build a project for a user. What’s the best way to go about helping the user get a solid grasp on the project? Is there a formulaic way to decompose a Spotfire project or at least a good order of operations. Decomposing a project you didn’t build is often quite difficult and can seem like trying to assemble a jigsaw puzzle with 1,000 pieces. Where do you even start?
So, I broke it up into 7 pieces. As I wrote the series, I realized I was also writing a bit of a best practices guide or a do’s and don’ts guide for project development. In an effort to help my readers, I thought a summary post would be helpful. Thus, this post summarizes 3 – 5 pieces of development advice from each part in the series. Keep in mind, I am not going to elaborate in great detail. All the info you need is in each post. Use this to jog your memory.
- Use a naming convention.
- Delete unused tables, connections, and data sources.
- Limit data as much as you can. Less is more.
- Leave comments in your code to explain what the code is doing in case someone has to modify it later.
- Provide a general description of what the data function is doing in the description section.
- Include code that will install and attach any required packages.
- Clean up your joins. Don’t join to the same table over and over again. Delete duplicates and have one join and only one join from table to table.
- Architecture is the single most important component of any project. Put time into planning it out. Don’t just start building.
- Document your architecture choices. Include information on not just what you did but why you did it.
- Delete unused document properties.
- Document what each document property should influence or control. l
- Use a naming convention.
- Delete unused calculations or columns.
- Add a description to the calculation if it gets complex.
- Use naming conventions.
- Use Exclude columns transformations to exclude any columns that aren’t needed.
- Don’t copy and paste from Word into a text area. Just don’t do it.
- Include descriptions in scripts and data functions that explain where they are used or what they impact in the project.
- Use the text area to explain how the user should move thru a workflow or text area.
- Use HTML and CSS. That’s not really a best practice per se, but learning even a little bit of HTML will make text areas so much better.
- Remove the unnecessary. Hide column selectors. Only show what a user needs to see in a legend if a legend is even needed.
- Make data limiting as visible as possible with legend items or naming conventions.
- Minimize usage of custom expressions in visualization properties.
- Don’t put too many visualizations on a page. Four is usually the limit.
- Articulate the business question you are trying to ask and answer with visualizations.
Now, I know some of these may seem super obvious, but I never cease to be amazed at what people create or leave behind. Please take these to heart. The developer that comes after you will be thankful.
Guest Spotfire blogger residing in Whitefish, MT. Working for SM Energy’s Advanced Analytics and Emerging Technology team!