Form for Daily Checklists?

[al1388Bek]

Hi All,
I’m looking for guidance on the best architectural approach for building a daily checklist process.

• Currently, drivers are required to complete a printed daily checklist and physically turn it in (screenshot below).
  
  

Of course, there are multiple ways to skin this cat, and I think that’s where I’m struggling. I’m having difficulty trying to format the above into something scalable and maintainable. Specifically:

• Balancing a simple UI against the 50+ required inputs .
  • Is there a more efficient and scalable way other than creating 50+ columns?
• Determining the “right” architecture since there seem to be several adequate approaches (forms vs display view, columns vs canvas fields?).
  • There are fields like driver and vehicle number that are accessible from a cross doc/relation columns.

The Ask:

• How can I allow drivers to initiate a new checklist each day, optimized for mobile-use.
• Present the 50+ checklist fields in a way that is quick and minimizes user adoption friction (e.g., mark only the items that require attention).
• Maintain structured data for reporting/history/auditing purposes.
• Wishlist: If an inspection item is flagged as “Requires Attention” or similar, trigger a notification/maintenance review workflow (a general outline would be sufficient)

Thanks in advanced for any thoughts!

[Christiaan_Huizer]

hi @al1388Bek ,

a warm welcome to the community.

Fir st I would suggest to use the fillout pack (or any other pack that handles forms elegantly) to make use of the branching options inside these form builders. in Coda you cannot skip fields. No branching and with 50+ fields you need in coda 50+ columns anyway. There is a difference having a back end table with 50+ columns and a form that forces you to check every field.

In case your set up does not require a form, you can play with various layouts inside a coda doc, but the problem remains, you cannot hide columns (input fields) programmatically.

Anyway, you may benefit from a coda expert helping you out in finding the approach that fits your needs and expectations; which may require some webhooks or other links to your form builder to feed the form per driver with the correct info.

Packs are the intelligent bridges between coda and the form builders. I wrote a blog on the Fillout pack I created a while ago and updated it recently.

Cheers, Christiaan

[al1388Bek]

Thanks, @Christiaan_Huizer . I’ll give the Fillout Pack a look. Glancing through the medium article, it seems like it’s pointing in the right direction.

[Melanie_Teh]

@al1388Bek

welcome to the community!

softr also forms that can be a direct link to your coda docs.

hope this helps!
Cheers!
Mel

[al1388Bek]

Thanks, Mel!
I’m a little familiar with Softr, I was hesitant to do a deep analysis simply because of software creep and additional costs.
But since Melanie Teh, of all people, recommended it; it must mean it’s worth the deeper investigation

Thanks again. I’ll look into it.

[Melanie_Teh]

again @al1388Bek

LOL i wouldnt put my golden stamp of approval on it but it does the job haha

here’s the TL:DR

1. its a bit slow(like long pause) for the data from a coda table to come up (e.g. when u drop down select).
2. the UI/UX for form isnt great. just 1 (or 2 - cant remember but would say on par with fillout) fields per line/row. Im more of a 4 fields to a line person ala Jotform/Coda forms.
3. the form is free feature.

with regards to your “The Ask” - youll first have to decide whether you want to go coda native or 3rd party route. Then can give you ideas on how best to execute.

so between coda native and 3rd party - consider
a. cost
b. privacy of data i.e. driver can only see them, driver can only see the vehicle number they are working on or can search database
c. once submitted, can this info be edited by submitter?

regardless of which, theres no getting around 50+ checklist fields
but how its inputted- there are creative solutions.

looking forward to your thoughts!

Cheers!
Mel

[Christopher_Dasca]

Hey,

Have you considered having 50 rows instead of 50 columns? Much easier to read on mobile and then the done checkbox goes as a column.

Each row acts as 1 checkbox item for 1 day.

So 50 rows a day.

Driver opens the page presses button for “get checklist” which creates 50 new rows for the day.

Can add the other details like data driver name etc. into the columns.

Thanks,
Chris

[al1388Bek]

Thanks, @Christopher_Dasca ,

I have thought about doing it by rows. My reservations are having 20+ drivers complete the form weekly. I’m just sure how well that would work with scaling and speed, Bc we’re talking 1000+ new rows and columns each week.

After thinking about it more, I’d love to create a canvas “template” that gets replicated for every form. I’m just not certain how/if that’s possible. @Melanie_Teh - Any thoughts on this?

[Christopher_Dasca]

How long do you need to keep the data for? Does it need to be kept after the week?

Hmm actually just saw you need it for auditing and reporting.

[al1388Bek]

Normally I wouldn’t have a preference, but the stakeholders are big on keeping record for everything.

[al1388Bek]

@Christopher_Dasca

I just came across this thread (that you also happened to be in) A dynamic Checklist design idea help? - Ask the Community - Superhuman Community

I think that gave me some ideas to try out. I appreciate your help

[Christopher_Dasca]

Makes sense. Based on what I know so far, I think the decision depends on whether you have any limits in your Coda account on how many rows you can have.

As far as i know having 10,000 rows isn’t such a big deal - it’s a pretty simple table (but someone may have experience that says otherwise).

But given the data is relatively simple - task, driver name, checkbox. It might also be quite easy to every now and then just export all the data to a CSV file for storage.

It’s an added step, which is never ideal, but something that could be a monthly/weekly clean up process that makes it easy to store years of data over time.

[Christopher_Dasca]

Glad it helped. Let me know where you land. Be interested to see what you came up with in the end.

[Paul_Danyliuk]

Saw a checklists thread, decided to show off one of the modules I was recently building specifically for checklists.

The ultimate goal with this module is to be able to define checklists with a simple DSL like this:

Collecting preorders here

[Melanie_Teh]

@al1388Bek

the Canvas “template” is a good option but i probably wouldn’t replicate it for every form, as your doc size could hit the limits pretty quickly.

i started putting together a demo doc for you, but there are quite a few variables to decide on first. If you’re still feeling stuck, I’m happy to jump on a quick call to help map out a strategy and direction for your build, and i can show you some examples and demos of different approaches.
Usually, this kind of high level strategy session would fall under paid consult work, but i’m happy to waive that if you’re willing to upload a demo or concept doc here afterwards, so it can help others in the future too.

if we’ve got a deal…you can book a time here: cal.com/mel-teh

Cheers!
Mel

[al1388Bek]

@Melanie_Teh

I appreciate the offer and may reach out to you directly as (other) project complexity ramps up.

But honestly, I think I may have overthought the “issue”.
Last time I needed to create a loop-related function was before Coda added the ForEach() formula . And I remembered how laggy the process was to create a similar function.

Here’s what I’ve settled on thus far:

1. A table for the questions/checklist items. And a separate table that “collects” the responses.

2. Buttons triggered by a daily automation that loops through the list of vehicles and creates the daily checklist for each.

   

3. And here’s a mockup for the driver interface:
   

   

Embarassingly simple, I admit. Regardless, I appreciate your help and patience, Mel and @Christopher_Dasca !

And same for you, @Paul_Danyliuk (although I couldn’t get the video you linked to play). I hope you’re well and safe in UA.

[Ben_Lee]

@al1388Bek, “embarassingly simple” is not a thing, “embarrassingly complex” is.

People confuse the fundamentals for basics, but the fundamentals are the aspects of a system that always hold true, no matter what, and take a lifetime to master.

All problem solving involves getting the idea out there, with all the bloat that comes with it because we’re not sure of the fully polished solution yet. Complexity builds as we include different paths as if they all might be needed. It’s the chipping away at what’s not needed, all the way down to the fundamentals, that is the path to mastery. That’s just the arch every solution takes, but very few take the time or see the value in coming down the last half of the arch.

“Embarrassingly simple” is elegant, it’s where we recognize genius, it’s mastery.

Great work on something that isn’t easy to see at first.

[al1388Bek]

@Ben_Lee
You’re right, at the tail end of whatever project, hindsight usually highlights the simplicity of the solution and overshadows the hours of trudging through the different paths, and dead ends we took to get there. But I guess that’s just the nature of learning.

That was really well said and a great perspective that I’m glad you voiced, Ben. Thank you.

[Christopher_Dasca]

Very true.

My most useful and elegant designs seem simple because of the many hours of building, testing, experimenting, then deleting 60% of what was built.

[Coda_Solutions]

Very well said Ben. While the request is simple it is far from it. I have spent much time on trying to learn the framework to build and manage systems (for personal/business) before using any software to implement - like you said the fundamentals. Made the mistake of building without a plan which ended up in disaster.

The challenge is that fundamentals comes from multiple sources - database design, software development (build with modularity in mind), project management, etc. Maybe this could help others with a big picture overview but here is what I have pieced together and maybe other more experience people can comment :).

Two simple, yet biggest, concepts I learned are:

1. When building a system, all we are doing it taking inputs and transforming them into something new - an output. A meal prep system takes ingredients and transform them into a meal. A laundry system takes dirty clothes and transform them in to clean clothes, etc., and

2. Its not the destination but the journey/different paths to get to the same output. Variables like limitations in resources (time, personnel, supplies, tools, etc.) all add complexity and is what creates different paths in a given system. As stated there are multiple ways to do something but the best way will be the most effective (it gets done) while being efficient(optimized resources).

Just a side note, there is a series of stages to get a system to an optimization level and beyond to a maintenance level. The problem I see, especially with AI, is trying to jump straight to optimization and basically overengineering things (i.e using several software to do a procedure) and wasting resources. Something to keep in mind.

I’ve only scratched the surface but when building systems, I realized it is like building a house. A house blueprint has layers for foundation, electrical, plumbing, etc. Similarly, you are doing that for a system. The picture below is an example of that analogy with system layers and using laundry system as example.

Having this framework sets up for easier workflow/automation/ai management. If familiar with Pareto Principle, this would be the 20% that yields 80% of the system-building work. Also note, you’ll need a system to manage your systems, especially if you want to implement AI/automation with little human interaction…so having a solid system building framework will help in the long run.

Also wanted to include the progression levels to building a robust system. I call it versioning but its essentially system levels. As stated previously, there is this push toward optimization with AI bells and whistles but that does NOT help when you are at stage 0. Hope this insight is helpful!