<h2>Background</h2>
<p><a href="https://www.bildr.com/">Bildr</a> is a low-code tool for building web applications and browser extensions. One of the things it is missing at the moment though, is a graphical overview of the flows and actions that you set up in response to page and user events in the app you are building. Such UIs are available in other tools like AppGyver, Node-Red and n8n. And once you have worked with one of these, it is very arduous to think in any other way about flows and actions.</p>
<p>Of course, a visualization UI for flows and actions is very much an optional feature. Bildr doesn't need them at all. You can create all the flows and actions you need without such an overview, but eventually you get to a point where your flows are just too big, too complex to keep in your head. As an example, where does this flow go from this API action upon success? What happens when it gets there? I don't want to leave my current changes, but I do need to see what actions are downstream, outside the current flow based on nested flows or action-sourced flows, etc.</p>
<p>Seeing all the interconnections and conditional branching based on variables, or success/failure inside existing actions allows for quick refresh on what is going overall in response to user events, or page load. FlowViz is my attempt to solve this issue by creating a visualization of all of a page's flows, showing how they interconnect, and eventually, allowing you to make changes without leaving this graphical overview.</p>
<p>This wouldn't be possible without access to the internal data structure of both Bildr Studio and that of the project you are currently building in the Studio. It is so rare to find an app written this way! Bildr Studio is written with Bildr Studio! Big kudos to the Bildr team for their openness and forward-thinking!</p>
<h3>Current Version: 0.1.2</h3>
<h2>Status</h2>
<p>I have been working on the Bildr Object Model (BOM - my way of thinking about it) and it's workings and writing the basic processor for taking what is stored in the BOM with respect to flows and actions and rendering that graphically. So what follows is the state of FlowViz by way of a non-trivial example.</p>
<h2>The Example Flow</h2>
<figure>
<img
width='100%'
style="
object-fit: contain;
object-position: top;
padding: 4px;
"
src="/images/5/5-1.png"
alt='Bildr Studio with the `FlowVizDemo` page loaded'
/>
<figcaption>Figure 1. Bildr Studio with `FlowVizDemo` page loaded</figcaption>
</figure>
<p>Figure 1 shows the Bildr Studio with the <code>FlowVizDemo</code> page loaded. The page is simple. It has 2 buttons and a div. The button on the left, "Invoke Test Flow", has a click event that invokes the flow we are going to be plotting. The other button, "Show Test Flow", invokes another flow with a single action "Run JavaScript function v2" that maps the overall flow from the "Invoke Test Flow" button's click event and plots its findings into the div at the bottom of the page.</p>
<figure>
<img
width='100%'
style="
object-fit: contain;
object-position: top;
padding: 4px;
"
src="/images/5/5-2.png"
alt='actions of the (AA...) flow'
/>
<figcaption>Figure 2. Flow (AA ...) actions using Studio UI</figcaption>
</figure>
<p>Figure 2 shows the actions of the (AA...) flow that is called from the "Invoke Test Flow" button's click event. Note that there is a "wait" directive between the nested flow action and the action following it. This means (in my understanding) that the entire nested flow will run, and when complete, will return to this flow to further execute actions lower down in the list. Note also, that there are no details for a nested flow. You click on that UI element and the Studio replaces the UI in that part of the page with the destination flow's data/presentation (see Figure 3) below.</p>
<figure>
<img
width='100%'
style="
object-fit: contain;
object-position: top;
padding: 4px;
"
src="/images/5/5-3.png"
alt='actions of the (BB...) flow'
/>
<figcaption>Figure 3. Flow (BB ...) actions using Studio UI</figcaption>
</figure>
<p>Figure 3 shows the sequence of actions that are the "BB...". Note that there is a "wait" directive between actions (DD...) and (EE...). I haven't shown the UI contents of each action as they are not doing anything material (yet).</p>
<figure>
<img
width='100%'
style="
object-fit: contain;
object-position: top;
padding: 4px;
"
src="/images/5/5-4.png"
alt='FlowViz 0.1.2 output'
/>
<figcaption>Figure 4. FlowViz output for entire flow</figcaption>
</figure>
<p>Figure 4 shows the result of running the JavaScript function using the event (AA...) as a starting point. All of the non-actions in the flow are shown with coloured backgrounds for reference. The solid arrows show the top-down, implied sequence of the actions as rendered by the Studio. The dashed arrows represent an implied "jump" to a nested flow. If the nested flow is followed by the "wait" directive (as is the case here with BB), then there is an implied return "jump back" to the calling point shown as another dashed arrow.</p>
<figure>
<img
width='100%'
style="
object-fit: contain;
object-position: top;
padding: 4px;
"
src="/images/5/5-5a.png"
alt='Studio view of Value parameter of action CC'
/>
<figcaption>Figure 5a. Studio view of Value parameter of action CC</figcaption>
</figure>
<figure>
<img
width='100%'
style="
object-fit: contain;
object-position: top;
padding: 4px;
"
src="/images/5/5-5b.png"
alt='FlowViz view of Value parameter of action CC'
/>
<figcaption>Figure 5b. FlowViz view of Value parameter of action CC</figcaption>
</figure>
<p>Note that for each regular action, FlowViz plots the action's label to the left and its settings to the right (Figures 5b, 6b). The settings section is divided into 3 rows. The top row shows the parameter's label as shown in the Studio UI. The second row shows the sub-specifier/context where that label will present it's choices from. So far, the BOM reveals these in the text format of "static.---" . The 3rd row shows whatever choice you selected. If you did not make a selection for that particular parameter, then the default value (often blank in the UI) is shown.</p>
<figure>
<img
width='100%'
style="
object-fit: contain;
object-position: top;
padding: 4px;
"
src="/images/5/5-6a.png"
alt='Studio view of Value parameter of action FF'
/>
<figcaption>Figure 6a. Studio view of Value parameter of action FF</figcaption>
</figure>
<figure>
<img
width='100%'
style="
object-fit: contain;
object-position: top;
padding: 4px;
"
src="/images/5/5-6b.png"
alt='Studio view of Value parameter of action FF'
/>
<figcaption>Figure 6b. FlowViz view of Value parameter of action FF</figcaption>
</figure>
<p>Also note that in some types of context, like "Elements" above, what is shown in the Bildr UI is the Label associated with the element rather than the element's ID as I have shown it. I will be making the visualization more detailed to reflect this same translation in an upcoming release.</p>
<h3>A Note about action execution order and timing</h3>
<p>At this point in my exploration into the internals of the BOM, it is not clear how multiple actions within a single flow are timed. When do they start? How do they end in relation to the way they are shown in the Studio UI?</p>
<p>Note: for the next few paragraphs, consider the actions you see in the Bildr UI to be a collection of parameters and helpers that result in data that are passed to pre-made JavaScript functions created by Bildr that run inside the browser. This is one way that NoCode and LowCode tools work under-the-hood. And though possibly incorrect here, it shows the thinking process I am using.</p>
<p>For example, in JavaScript, if you have functions that may take a long time (relatively speaking) to execute you can execute them in order (synchronously), but this causes your app to become momentarily unresponsive for the time taken by the function. For example, API calls can take a while to return. Your users can do nothing but wait. Clicking will not work until the synchronous API call completes. The solution in coded environments is to use asynchronous functions which execute their target functions in parallel and return control back to your app right away. In these cases, any subsequent function calls can be told to "wait" for the primary function to complete before they execute. And so on. All of it without affecting what users can do with your app's UI.</p>
<p>Another technique, and one that I have heard referenced in 'Bildr Office Hours' and the prior 'Bildr Hour', is the technique of a queue. With a queue, functions intended to be executed are placed in an array (or similar) and a separate function executes each queued function in order. As each function completes, it is removed from the queue. The key here is whether the functions themselves are run synchronously or asynchronously. Synchronously-run functions can affect the user experience as already mentioned. Asynchronous functions will not. But if you use a queue for asynchronous functions, there is the issue of when the individual functions complete in relation to others. A long-running function that executes first will not complete before a short-running function started 2nd. As you can see it can get quite involved.</p>
<p>There is an explanation in a recent 'Bildr Office Hours' about how actions in sequence in the Studio UI are enacted by Bildr inside the browser, if you are interested (https://www.youtube.com/watch?v=aMYD4LJIWwg at 00:32:26). I will have to re-watch that this episode as well.</p>
<p>It's entirely possible I have this all wrong, but it is fun (for me, at least) trying to understand what is going on this using the data provided in the BOM and trial and error.</p>
<p>I am most interested in learning exactly how action execution happens, as it will make a big difference in how the FlowViz should be render/interpret arrows. For now, I am following the implied, top-down UI sequence of actions within flows and acommodating any subsequent wait directives.</p>
<h2>Where is this going?</h2>
<p>For now, I have been working on decoding the rich information found inside the BOM as it pertains to actions and flows. Some effort was needed to handle the recursion within the BOM. Next came the need to auto-route the arrows between flows and handle the implications of "wait" directives visually, so that the resulting plot was dynamic (more on how I did that in the next writeup). Unfortunately, I haven't given much attention to the visual presentation of the flows and actions. I hope to fix that very soon.</p>
<p>After that, I hope to be implementing click event handlers and hover handlers on the plot elements themselves and either call up the associated Studio UI for making changes, or better, offer an alternate UI to make those changes from modals/lightboxes with the needed forms.</p>
<p>Happy Bildr-ing</p>


Bildr is a low-code tool for building web applications and browser extensions. One of the things it is missing though, is a graphical representation of the inter-connected flows and actions that you can set up in your app. FlowViz is my attempt to add this feature. In this post, I will show my progress thus far in version 0.1.2

FlowViz for Bildr

green

<h2>Step 1</h2>
<p><img
width='100%'
style="
object-fit: contain;
object-position: top;
padding: 4px;
"
src="/images/4/1.png"
alt='Step 1. At The Gate'
/></p>
<p>You've been using, buying from,and possibly marketing for web and/or mobile apps for a long time. And you've got this idea for your own app that will really shine if you could do it yourself.</p>
<p>But your problem is, and has been for a long time, that you're not a coder. You don't know how to code nor do you want to learn. It seems too much learning, too technical (and maybe a little on the arcane side?) for you to take that learning on right now.</p>
<p>Before the advent of NoCode/LowCode (NC/LC) tools you'd have had to partner with a coder or hire one. But not any more. With NoCode and LowCode tools, you are free to write serious web and mobile apps all by yourself! Freedom!</p>
<p>So what's the first step?</p>
<p>Are there any other businesses on the web (or as mobile apps) like the one you are thinking about creating? How can you find out? You need to know more, so you can decide whether to pursue this.</p>
<p>Well, it's time to start looking and see what inspires you.</p>
<p>So get started! Learning sites like Udemy will show you if there is a market. YouTube can show you who is in this space and Google will find things for you when you only know a bit of what you might want to do.</p>
<h2>Step 2</h2>
<p><img
width='100%'
style="
object-fit: contain;
object-position: top;
padding: 4px;
"
src="/images/4/2.png"
alt='Step 2. Learning the Biz'
/>
You've spent several days researching competitors (new and established) and you think you have a handle on what makes each one work: what their strengths and weaknesses are. And you have a pretty good idea of where you could fit into this space.</p>
<p>You've collected what pages are common to each site and those which are unique. You also know what CTAs (Calls to Action) they use to get visitors to engage and ultimately buy from them. You've collected a bunch of bookmarks and made extensive notes in your note-taking app about what you found and how it will shape what you will do.</p>
<p>What is coalescing in your mind now is what your site is going to look like, how it will operate, and how visitors will engage with what you will be offering.</p>
<p>In short, you are ready to start your project. What you need to decide next is what NoCode/LowCode tool(s) you will use.</p>
<h2>Step 3</h2>
<p><img
width='100%'
style="
object-fit: contain;
object-position: top;
height: 115px;
padding: 4px;
"
src="/images/4/3.png"
alt='Step 3. Selecting the Tools'
/></p>
<p>Now that you know what to build, it's time to select one or more tools. But which tools?</p>
<p>There is a huge variety of NoCode and LowCode tools to choose from. Many of them claim to be just what you need - they do it all. Other tools specialize in one aspect of what you need (like databases, mail managers, payment handlers, etc.). There are tools which talk to other tools: monitoring changes in one tool and reacting by sending instructions to other tools.</p>
<p>Well, my friend, this is the truly hard part. You have a pick a tool for putting up the web pages. Something that looks good yet can be customized readily. This is no easy task! And once you pick one, you need to determine how you'll do the rest of your app, should this tool not do some things you had planned for your app.</p>
<p>In the end, it comes down to making a balanced decision from what you've read from the vendor's sites, 3rd-party reviews, etc., and then taking a few tools out for a spin. Deciding is the hardest part - you know when it isn't going to do what you want, but you might be a month figuring that out.</p>
<p>Just make the best decision you can for each tool you need, and get ready to start designing the exact pages of your app!</p>
<h2>Step 4</h2>
<p><img
width='100%'
style="
object-fit: contain;
object-position: top;
padding: 4px;
"
src="/images/4/4.png"
alt='Step 4. Designing the Site'
/></p>
<p>Some people start with pencil and paper. Others use online drawing tools to mock-up their pages and to give life to their designs.</p>
<p>Here you will be consulting your notes from Step 2 (Learning the Biz - i.e. researching your competition). You'll want to be sure you have the same pages that they (in terms of general content, anyway), but you also need to design your versions of those pages to showcase what you are offering and how it is different. In short, you need a style - a visual theme that ties all of your pages together. When a visitor arrives on your app, they should KNOW this app is different - visually. That doesn't mean wildly different (necessarily). But it does mean that they will remember it and as they travel from page to page they will feel they are on the same site because it has the same feel. This idea is intangible, certainly, but as you design your pages, you will see what I mean. If you are in doubt, go back to step 2 and re-examine your competitors' pages with an eye to their "style" or theme.</p>
<p>Next, pay attention to the new pages you'll need. Separately design the public pages, and the private (logged-in pages) if you have them). And give serious thought to having some admin pages where you make it easy to add images and content for the pages of your site, as well as manage users and their transactions/payments/settings.</p>
<p>In the end, you will have a well-designed web and/or mobile app of interconnected pages - entirely unique.</p>
<p>===</p>
<p>Now it's time to transfer those designs into real web pages on a real website of your own!</p>
<h2>Step 5</h2>
<p><img
width='100%'
style="
object-fit: contain;
object-position: top;
padding: 4px;
"
src="/images/4/5.png"
alt='Step 5. Implementing the UI'
/>
This step relies heavily on the capabilities of the NoCode tool you chose in step 3 for UI design, so your mileage may vary.</p>
<p>Some tools allow you to specify CSS and HTML directly, whereas most design NC/LC tools offer widgets that are rendered as HTML with CSS styling that can be somewhat customized via the settings they provide for users.</p>
<p>Expect to spend several days if not weeks learning how the tool you've chosen works: what things you can change and what things you can't. Also remember that when putting together your pages, make sure you have versions that look good on mobile devices and if you have the time, on tablets too.</p>
<p>===</p>
<p>Now it's time to connect the pages together, store the data, initiate the procedures (emails, etc), and add animation!</p>
<h2>Step 6</h2>
<p><img
width='100%'
style="
object-fit: contain;
object-position: top;
padding: 4px;
"
src="/images/4/6.png"
alt='Step 6. Implementing the Functionality'
/></p>
<p>Your pages look fantastic!</p>
<p>Now you need to interconnect them, with links between pages where you need them, and a navbar for navigating to the major pages. Don't forget the hamburger menu for when your site is viewed on mobile devices. There are also some important links that are usually found in the footer of most pages.</p>
<p>Your page creation tool will most likely have a way to create all of these navigation aids for your site.</p>
<p>Lastly, if you are going to have registered users on your site (and you have special pages just for registered users, right?) you will need a way to log in/log out/sign up, as well as a database to store users and other site data.</p>
<p>Now your site is full of inter-connected pages and functioning buttons and links. Customer data is being stored.</p>
<p>===</p>
<p>Now it's time to connect to external services - the ones not offered by your chosen NC/LC page design tool.</p>
<h2>Step 7</h2>
<p><img
width='100%'
style="
object-fit: contain;
object-position: top;
padding: 4px;
"
src="/images/4/7.png"
alt='Step 7. Connecting to External'
/>
This is the step where your users interact with services that your site needs. This includes payment processors, email senders, and databases. You may have others that you need to connect with as well.</p>
<p>Here you will be using one or more methods to access these external services. The first method is the simplest: built-in integrations offered by your page design NC/LC tool. If you are really lucky, they will have built-in integrations to all of the services you need for your app.</p>
<p>Next in convenience, is the availability of 3rd-party plugins that your NC/LC tool gives you access to. These can be very easy to use as well. Alternatively, your tool may offer a generic API action that can be customized to handle any service which has a REST interface (the acronyms mean something, but in this light overview, we'll skip them).</p>
<p>The 3rd-party "glue" tools like Zapier, and Make (formerly Integromat) can be connected to here as "services" albeit as indirect services: they connect other services together. You use them like executive assistants to whom you delegate tasks, and can be a real boon to your app (and to you as a business owner) if you need things like notifications when users sign up or when payments are made.</p>
<p>===</p>
<p>Well, the services are now all connected to your app. Emails can fly off to new customers, and data is updated when that happens.</p>
<p>Every external service you need is now working well and every action's results are being stored for later review.</p>
<p>Now it's time to launch!</p>
<h2>Step 8</h2>
<p><img
width='100%'
style="
object-fit: contain;
object-position: top;
padding: 4px;
"
src="/images/4/8.png"
alt='Step 8. Launching'
/></p>
<p>This step is basically when you take the testing/development version of your app LIVE. We call this moving to production.</p>
<p>Essentially, you deploy what you have been working on to a domain name you chose (you bought one already, right?). Then you use your NC/LC tool to deploy your app to this domain and sit back to watch the users streaming in and the money adding up.</p>
<p>That was SUPER easy!</p>
<h2>Step 9</h2>
<p><img
width='100%'
style="
object-fit: contain;
object-position: top;
padding: 4px;
"
src="/images/4/9.png"
alt='Step 9. Optimizing, Iterating'
/></p>
<p>OOk. Your app has been live for a while now. You've got a few customers, but not as many as you thought or want. You need that to change, and in a hurry.</p>
<p>You have some ideas of what the problem is, and you address those with tweaks. What you do now is, in essence, repeat all of the steps except the first and maybe the 3rd (tool selection) and make the changes you need to make to your test/development version of your app. Once you're happy with it, you deploy again to your LIVE domain (production). Rinse and repeat.</p>
<p>Your site just gets better and better.</p>


Even if you are starting with nothing but an idea, you can develop a SaaS app. That is possible now due to the NoCode movement and their extremely capable tools. Apps are no longer in the sole purview of developers who write code. Just start from wherever you are. Here's a light treatment of the stages you will go through.

The NoCoder's SaaS Journey

Part 1: Why I've chosen NoCode for all new client app development

Code or NoCode?

<h2>Proposal, Case No. 1</h2>
<p><strong>Add-on proposal to an existing project</strong></p>
<h3>Background</h3>
<p>Freelance coders: consider this scenario:</p>
<p>You've had a meeting with your client where you delivered some (or all) of the agreed-upon work. The meeting went very well. Your client liked much of what you delivered, but they also want changes. And, they found errors and shortfalls in what they think you should have delivered.</p>
<p>You ended the meeting well, saying, as you should, that you will review your notes (you took LOTS of notes, right?) and then get back to them before you start on any changes. You want to be able to discuss any implications that the meeting's observations have on deliverables and delivery. This internal review of yours is your way to get technical details ready as well as get your head clear to deal with any friction you feel.</p>
<p>So now you have reviewed. You agree that some things should have been done differently. You also agree that some other things were not working and need to be fixed. However, you don't agree with everything your client said/expected. In particular, you think some items are new to the scope. Your position with these: if they want them added to the current work, they will have to pay extra.</p>
<p>So now you have to report back to your client and you are a little worried about how they will receive this extra 'ask'.</p>
<h3>Here's what to do:</h3>
<ol>
<li>Separate the 'free' things from the ones you want to be paid for. Place the free items at the top of your message.</li>
</ol>
<p>I would even go as far as to list the free error fixes in one section followed by the free changes in another.</p>
<ol start="2">
<li>Transition into the items you want to be paid for, but don't give a price!</li>
</ol>
<p>Instead, list the work you want to be paid for by giving each a title, and then, in point form, list the advantages this work has for your client (as you currently understand them) as clearly as you can. Leave the price conspicuously absent.</p>
<ol start="3">
<li>Finally, in your message just below these payable items, say this:</li>
</ol>
<p>"Would you like me to quote on these?"</p>
<h3>Why? Here's my rationale:</h3>
<ol>
<li>You clearly define what <strong>you</strong> consider free and what is extra to your current scope.</li>
</ol>
<p>If they disagree, they will contact you. You can discuss from there.</p>
<ol start="2">
<li>You isolated the free items and thus remove them from further discussion.</li>
</ol>
<p>By leading with the free, you are delivering good news first and you transition to what you want to be paid for with the benefits in a natural way. In effect, you are opening the door to a conversation solely about the things you want to be paid for.</p>
<p>You'd be surprised how many times shortcomings and flaws in a milestone/final product get rehashed if you keep all of the work to be done in one big jumble. And that wastes everybody's time.</p>
<ol start="3">
<li>You clearly define what you think your client is asking for: the what and the why.</li>
</ol>
<p>By stating it in your own words and listing the advantages as you see them, you give your client a chance to confirm whether these items are truly wanted. A lot of misunderstandings are averted by this simple approach.</p>
<ol start="4">
<li>You give your client the opportunity to value the items you want to be paid for.</li>
</ol>
<p>After all, these work items are not valuable to your client until <strong>they</strong> say so.</p>
<p>By 1) telling them you think these work items are valuable, and 2) asking (tacitly) for their thoughts, you are signalling to them that you think they are valuable, but without their "how much is this going to cost me" guards coming up.</p>
<p>If they disagree with you, they will tell you and no harm done. You wasted no effort pricing the work. Neither you nor your client suffers any chagrin if they decide not to proceed as a result.</p>
<p>You may be surprised how often this seemingly negative outcome spawns a new idea (either from your client or you) that ends up being quoted, accepted and paid for. You are giving the right solution a chance to appear together.</p>
<ol start="5">
<li>You are giving them time to think about the amount they want to pay and the timetable for delivery <strong>before</strong> they ask you to quote.</li>
</ol>
<p>This takes the pressure off both of you.</p>
<p>If your client wants to pursue any of your extra items, you have given them time to consult bosses and internal stakeholders. They also have time to estimate the work involved (from their perspective) and possibly the amount they might want to pay.</p>
<p>You give them time to get a budget and timetable that works for them.</p>
<p>The actual price you assign to a quoted work effort is another subject that we shall explore a little later.</p>
<p><strong>Remember</strong>: There is no such thing as a bad conversation with a client, as long as you manage expectations (both yours and theirs).</p>

How to help ensure you get paid for extra work

Avoiding scope creep

<p>At a certain point the incentive to do these often old, out-of-context tasks turns vengefully into a serious disincentive to even look at them, much less attempt to get them done.</p>
<h3>Nobody starts out thinking they will have hundreds of tasks</h3>
<p>It happens slowly, just a few tasks added every day that just don't seem to get done. Before you know it you have a behemoth of tasks, seething just under the surface of today's task list</p>
<h3>This task is important! <span class='uuuu'>(at the moment, at least)</span></h3>
<p>Imagine an important project of yours is on your mind, and after thinking about how it is going and where it is going, you get a great idea or you think of something that will avoid future issues. An important task is born!</p>
<p>So you add it to today's task list. Your full of hope, confidence and determination. This task is gonna get done today!</p>
<h3>Context gets lost as time passes</h3>
<p>At the time you record a task as being something you want to do, you choose a title for the task that encapsulates:</p>
<ul>
<li><strong>what</strong> to do, and</li>
<li><strong>how</strong> to do it (maybe)</li>
</ul>
<p>But <strong>why</strong> you want to do the task is often missed: it makes the task too long. After all, you have a lot more things to do today.</p>
<p>And you'll definitely remember why you wanted to do this task. Right?</p>
<h3>Uh oh, tomorrow is here <span class='uuuu'>(already)</span></h3>
<p>Somehow the day gets used up and this task was either not done or not even started. Now it's tomorrow. It's the new today. And today has a new set of urgent tasks, commitments and want-to-dos. Yesterday's leftover tasks get shuffled into today. And it still doesn't get done.</p>
<p>At some point, that not-yet-started task from one or more days ago starts to look like an accusation. Not pleasant.</p>
<p>Your daily task list gets too long to see at a glance. The the number of things you get done each day hardly makes a dent in the task list in front of you. Something snaps. Time to pare down.</p>
<p>And so, you make the bitter decision to move some tasks off today's task list, put them on hold. Ah... Now I can focus.</p>
<p>Now where should you put these? Of course! Right into a task manager! Or maybe I'll write them into nice moleskin notebook.</p>
<p>Yeah - I've got one right here, uh somewhere, - there it is! I signed up ages ago.</p>
<h3>Sure, you'll review these on-hold tasks every few ....</h3>
<p>... days, or weeks. Certainly every month on the 1st. Right after my morning coffee, and after I feed the dog, just before I feed the fish... Ahhhhh !</p>
<p>Now, extrapolate this behaviour over weeks and months.</p>
<p>That, my friends, is the beginning of your task database.</p>
<h2>The problem with tasks, is their title</h2>
<p>The titles you choose for your tasks should be chosen carefully: some represent novels that you can't read in a day.</p>
<h3>Granularity</h3>
<p>When you look at today's task list, try to get a feel as to how much is hidden behind the brief description you gave as a title. For example, "feed the dog" is very low level and actionable today in a reasonably short period of time. Whereas, "revisit my video setup" or "code the Stripe interface for one-time subscriptions" are more involved, possibly multiple-stepped and may require some thought.</p>
<p>What you have here is a difference in granularity, the particle size of your tasks is not the same. The way forward (for you, buddy) is not as clear for each of them. So when you see this, then your tasks title are not tasks at all, but triggers that need further breakdown into actionable steps. Your titles become mini-goals that will have several tasks.</p>
<p>You need sub-tasks or ordered steps (or both).</p>
<h3>Sub-tasks and sequences of steps</h3>
<p>You don't want to lose that nice title you first gave, but you need to augment that with all the steps that are needed to accomplish this. So go ahead, start to flesh this title out into sub-tasks, ordered in the proper sequence.</p>
<p>Wow! This is a bigger "task" than I imagined.</p>
<p>Don't despair! You just got an action plan of tasks together and you're going to be able to do some of them today. So highlight the very next step and put that on your task list for today. Keep the rest together and handy - you're going to want to do the 2nd step after you do the first, and so on until it is done.</p>
<p>So I have hundreds of tasks? What's the big deal? They're all there and I can find them when I need them. I'll get around to them eventually. I have to prioritize my time, you know.</p>
<h3>Now where did I put that ?</h3>
<p>Clearly, your task list for today will end up being fairly short (If you want to get it done) and so you have to choose what gets done and push off what does not to another day. This includes things that you <strong>want</strong> to get done. The day is only so long.</p>
<p>At some point in the future, though, your project will become front-of-mind once again and the pathways in your brain will lead to fuzzy recollections of the things you had intended to do: "Hmm, I'm sure I had a lot of things I wanted to do on this..." But what were they?</p>
<p>At this point you will have to draw upon the tools you used to store them away for future reference: the task manager (manual or electronic forms). Hopefully you tagged them with a project code and client code. It may take a while but you will find them.</p>
<h3>I was going to do ... that?</h3>
<p>Now as you glance over the list of tasks you made for yourself way back when, the difficulty will be figuring out what exactly you meant - what were you thinking of when you wrote this down? Is the task still valid? Have circumstances changed the need or the process of doing it?</p>
<p>You will have to decide that all over again in light of today's situation. So with that said, just how important were those task that you put off all those weeks ago?</p>
<h2>OK, but what's the solution?</h2>
<p>There is none. Intentions to do things should never to curtailed, in my opinion. Keep trying to do a lot each day, especially the things that lead to your goals.</p>
<p>It's not the end of the world that you didn't get all of them done today. There is no need to rue them. Look at them as new friends that you created to give focus to your day. Keep them for a while in your daily task list, but move them out if you think they do not or cannot realistically be done within the week.</p>
<p>Store them away if you want for later review, but take a moment to add the 'why' and any other context. And be realistic about your future self. If you find the 'why' of now will likely have no merit before you think you will get back to this project, then simply delete them.</p>
<p>You may end up with a task database. That's OK. It's your database. Keep it as small and as meaningful as you can but don't spend much time on it. After all you got things to do, buddy.</p>


Articles

FlowViz for Bildr

The NoCoder's SaaS Journey

Code or NoCode?

Avoiding scope creep

Is your task list becoming a task database?

Testimonials

Blog

Contact