Software > Our USER first Design Philosophy
"Just because we can, doesn't mean we should..."
Here's the deal...
Design Methodology and Philosophy that puts the USER first...
Here's the deal...
- As technologists, we can build add, update and delete forms in google sheets (not google forms -- form looking thingys in google sheets) that look and function in an amazingly similar manner to website form. Unfortunately each one of those forms requires a lot of hidden structure and javascript (much like web based forms) and it adds complexity to an otherwise simple process of entering data into rows and columns of a data table ( a spreadsheet).
- As technologists, we like to "show off" the cool things we can do with programming and software -- we must keep those show off items out of the user flow unless they truly add value
Design Methodology and Philosophy that puts the USER first...
- Build the data tables that reflect the data storage needs
- If the data can be entered into the tables with ease, don't build an add/update/delete form
- If filtering the table data itself meets all reporting needs easily, don't build a separate reporting component. Otherwise, build a report component as they are relatively easy with our templates, and they make both querying data and printing results easier and more aesthetically pleasing.
- If the data records have an active and a closed status associated with them, consider a manual deletion process or a manual archiving process (to another tab).
- If there are multiple status assocaited with records prior to a closed status, try to build data tables with status fields as much as possible (as opposed to using different tabs to hold different status items).
- If there are one-to-many relationships that can be handled in a reasonable fashion in one record such as payment amounts by payment method in a sales transaction record, build those out as a single record. In other words, Do NOT immediately go to a header/detail table setup and avoid it if at all possible -- as that just complicates all other aspects of the system and it requires more advanced knowledge for trouble shooting.
- Use default spreadsheet functionality before shifting to custom java-script at all times.
- Try not to use default spreadsheet functionality in the printable or view-able areas of a worksheet. Put that into hidden headers and silent tabs.
- Try not to use long and complex nested equations. Break those components out. Troubleshooting those is a nightmare.
- Minimize the use of named ranges. While they make some things easier, tracking the named ranges adds a layer of complexity and it makes troubleshooting more complex. Stick with the longhand when possible. Knowing when to use and when not to use named ranges is an art that you will need to grow into.
- Avoid using java-script for critical functions whenever possible. Always have a manual backup process in place.
- Avoid using script libraries unless the library and the sheets are all contained in the same organization, and even then, consider avoiding them. Scripting libraries are very powerful, but they aggregate control. In this case, it is easy to build an alternative local script if the library script doesn't please, so that is a great benefit if libraries are used. Google will NOT allow you to share a most recent copy of a libarary without also given edit control to that shared user and that is problematic (IMO).