App design flows from business need
This should seem obvious, but before we can jump into application development, we as software consultants have to start with an understanding of the business need and the processes we are trying to automate.
For example, we've got a customer who has an on-site operations working on the pipes that go under our streets.
One of the things that they have to do is they have to keep track of all of the personnel and equipment that are on site.
They have to keep track of all the activities that happen during their daily operations and workflow.
Currently they're using text chains with their phones and tablets to communicate where they are in their project and send corresponding pictures to document their work. From this text chain hey are creating reports manually.
There are lots of ways to improve their process, but the Minimum Viable Product, the most important and core deliverable is to give them is a central place to put all the information (website) and a way to automate those reports.
Instead of one massive, noisy text, they need a simple website and database that will hold their project information, their uploaded pictures, and their progress notes.
The business goals of this project are to:
- Recover several hours a week of managers' time by automating admin work
- Cut down on "noise" in their communication with irrelevant texts in the chain
- Create polished report for their clients
- Streamline the reporting workflow for the crews
Product design
Phase 1: Technical Discovery
The first thing that really kicks off a software project is a technical discovery.Our Chief Executive Developer, Randy Syring, has a meeting with the client and their technical team to figure out what exactly the business needs and how we might meet those needs from a technical standpoint.
We talk through the client's vision and possible implementations to help discover what is the most important deliverables to the client and what should or should not be in the project scope.
The idea behind this process is what we call Client Empathy - the desire to truly understand what our clients need and to build tools that are truly beneficial for them.
From that process we get an idea of what the basic bullet point items that the customer needs and we can start designing their custom software.
Our goal is to define exactly what needs to be done before we start writing code. It may be to enhance their data flow, or to provide better reporting, or automate calculations.
Phase 2: Mock-Up Driven Development
Once we have a detailed list of work and priorities, we start building wireframe mock-ups to show (in general) what the layout of the product is going to look like visually. We think through things like, where the particular buttons they need will go and what workflows those will kick off.The idea is to give the client a way of stepping through the design process that will help them experience the future state of their company rather than just thinking abstractly about what the software will be like.
Once we have the mock-ups together, we walk the client through what their daily work is going to look like with the new software.
We work in an iterative way, so we expect to field comments, questions, compliments, and concerns when we show our clients the mock-ups.
We'll take their feedback to the drawing board, sometimes we do this a couple of times, and reword the model until the client can say, "Yeah, I can see myself using and being helped by this software."
Once the mock-ups are accepted, we take them to the code stage, where we start writing code and making the software work.
The upshots of "Mock-up Driven Development" are
- The client saves time and money. A picture's worth 1000 words. It's always easier to change something at the mock-up stage where the design is not actually affecting any code than after you've started writing the code. The mock-up is a non-functional example of the end product, so you don't have to worry about changing or breaking code.
- We engage the client's imagination to think through what it's going to be like to do their job with the custom software. That brings up a lot of questions and details that they hadn't really thought of before the technical discovery. You start having the "wouldn't it be nice to..." sort of conversations. That turns into a conversation of "here are the things that we could give you within the budget" and what are the priorities (the must haves, should haves, could haves, and won't haves).
Building with JavaScript and React
Once we have cleared the design phase, we can start working on the application itself.In the case of our pipeline app we are using Python on the back end and JavaScript in a React framework on the front end.
Any time you start developing with JavaScript with another application on the back end, you're essentially developing two applications. One is going to run on the server (typically Python in our dev shop), and then one's going to run in the client's browser (typically JavaScript).
What the JavaScript does for our client is provide dynamic elements on the page.
You're not just looking at a static page with static form fields and filling out the forms and submitting those.
When you change things on the page, the page is going to respond. If you click buttons, it's actually going to do some other things on the page and interact with that Python application on the back end.
So the JavaScript front end is passing lots of data back and forth from the browser to the Python back end.
React is a framework that we use to develop with JavaScript and is the one that Facebook created.
Benefits of React
- Widely used, so easier to hire developers skilled in React
- Low learning curve
- Efficiency - React is used widely, so it is a lot easier to find documented answers to problems if we run into them. This allows us to stay on task and quickly advance in our development efforts
If you need help designing and building custom software, please contact us.
If you want to learn more about custom software projects we have undertaken, take a look at our projects page.