In recent years there’ve been quite a few new low code/no code entrants into the market. Among those is an interesting new entrant from Amazon called, Honeycode.
Honeycode is a well-designed tool that encompasses tables, user interface creation, and automation control. These work wonderfully together to allow business users to build team-sized applications to solve productivity challenges.
When building any new application, there are many best practices one should follow to attain optimum results.
We attempt here to share some of the wisdom from our decades of experience. What works. What doesn’t. And more importantly, a series of steps we recommend to follow to maximize application effectiveness.
Building a New Application using Honeycode
Honeycode allows new business users to jump in and build apps for their teams. Whether you’re getting ready to start a brand-new application, or rebuild from the ground up, planning is key.
Living in Massachusetts, I’ve been to Cape Cod many times. There are thousands of small cottages that were originally built decades ago as a small family getaway. But as each generation took ownership, they expanded the structure with additional rooms or even a second floor. Each new project stretched the limits of what the original foundation, frame, plumbing, electrical, and heating could handle. Until such time as expansion was no longer possible. At some point, the only choice left is demolition and reconstruction, this time with forethought and planning for what the family really needs.
If your foundation is solid, you’ll be able to build on top of it, such as new features and functionalities.
Where to Start?
In order to build applications that are useful, it’s important to follow these best practices. The first step is to turn the computer off and break out the paper, pencils, and erasers. We love using a whiteboard in this process as well. Only when the planning is complete do we go back, turn the computer on, and begin the construction process.
The second step is to sit down with all stakeholders to discuss the application requirements. Management will have an idea of the high-level goals that improve productivity, reporting, and automations that share or collect data from disparate sources used in the organization. Focusing on a minimum viable feature set without over complicating the requirements is important.
These steps are really about practicing good product requirements. We often recommend that a big development project be broken down in phases, with the first phase representing a minimally viable feature set. This allows feedback from users and managers alike that could impact the direction of future phases. We frequently hear in the business of software development that we’ve given our client exactly what they asked for, but now that they see it they realize it’s not exactly what they want.
The key is to get distinct, hard requirements documented and agreed to by all stakeholders. Do your best to repeat back to the client what you think you heard them say. Perhaps mockup the interface so they can see what they’re agreeing to. These additional steps go a long way towards delivering on the client’s expectations.
At the end user level, we’ll find all sorts of interesting and obscure details. Some special cases occur regularly, and others are more fringe cases the application will need to allow for when necessary. We always want to understand the business logic behind these use cases so that the app responds appropriately.
While approaching the second step, brainstorm with the group: what you’re developing at this stage is a mission statement for the new application.
- What will you track?
- What information will the application provide to users and management?
- What existing manual processes can be replaced with automation?
- What’s the projected return on investment (ROI) in terms of productivity or increased operational wisdom that justifies the expense?
More Detailed Planning
At the third stage, many will be chomping at the bit to get back to the computer to begin app development. They see the vision and are sure they know what is needed. But really, they don’t. They need to wait a little longer. The devil is in the details.
Every Honeycode application is made up of Honeycode tables, which contain different fields (aka columns). They’re often referred to as entities and attributes. An entity is something about which you track information. It’s a category of characteristics that generally describes people, events, or things. Customers, appointments, and repair parts are all examples of entities. The small cottages in Cape Cod that we referred to earlier would also be a great example of an entity.
Attributes are characteristics of entities. Attributes of customers might be name, address, web address, phone number, and number of employees. Attributes of repair parts could be manufacturer, part number, weight, and unit price. For cottages, this could be the number of rooms, address etc.
It’s important to identify all the entities and attributes and how they’re related to each other before you start building your application with Honeycode. With Rowlinks, Honeycode makes it really easy for non-technical users to create relationships among entities.
Time for a Review
Earlier in this process our team developed a plan. What are the inputs? What are the required outputs? What special automations are required? Now it’s time to validate the needed outputs against the plan we’ve outlined, as we’ve reviewed the proposed entities and attributes to see if they’ll meet all needs. If not, adjust and then review all needs again. We’ll do that until we’re able to validate the needs are satisfied.
Once we can cross these items off of our list, there’s one more important step.
Designing the User Interface (UI)
Designing an effective customer experience (CX) is a very critical aspect of the app building process in Honeycode.
Amazon’s Honeycode uses a popular approach called ‘Responsive Design.’ With Responsive Design, we design once and then we’re able to deploy across web and mobile. What this means is that Honeycode takes care of creating a device appropriate interface for each platform, which is a productive approach to app building.
It’s still incumbent on the developer to build an app that organizes data entry screens and data editing, and viewing interfaces that make sense to customers. Also, we must think about personalization during this phase of the project. Who can see what? Who can add, edit, or delete? And which actions each customer is allowed to perform?
The good news is that Honeycode makes this easy for both new and advanced customers. We create forms for these purposes along with automations to make the magic happen. In the end, these forms can be edited easily at any point, allowing for changes that’ll certainly be needed along the way.
Time to Begin Building
Now it’s time to head back to the computer with your plan firmly in place. Start by creating your tables and fields. Create the Rowlinks specified in your application. Begin building forms, automations, and more to bring the app to life.
One pro tip… involve customers and management in the building process. Don’t build the entire app and then show these key stakeholders what you’ve built. Instead, do the development in phases where customers can give feedback early and often. Let them experience the user interface. Let them comment on the color themes and organization. Observe how the automations work. Even with Honeycode’s ease of development, we want to know early and often what needs to be tweaked before we move on to the next level.
Sometimes customers will see the initial app version, and realize it doesn’t quite solve their problem or best fit their business case. That’s why we iterate with the key stakeholders throughout the development process so they can get exactly what they want. And they have some ownership in the final product, which improves acceptance of the application we’ve built.
Finally, realize that in most applications we’re never really done. Business needs change. New reports or types of information are required. New management asks for more. It’s the nature of software development. The only constant in this process is change. Next we'll tackle the different types of database relationships and their importance in the design process. Stay tuned!
This article is also published on HoneycodeCommunity.aws