Time to get this truck rolling, I am going to start with “ONE terrible, rambling paragraph” just to see if I can even do that. Turning off perfection, leaving critiquing at the door, shoving the grammar police into a corner, and just letting the words fly. This is a free writing exercise in the process of cracking through the imposter syndrome and the procrastination situation. I think I may even be able to find a sense of rhythm in this. BARBLESHNOOTZ!!!!
I need to write this up! It needs to get finished, but I keep getting distracted. Why are all of these pop-up suggestions and grammar police alerts always interrupting me?
I understand those feelings. I was actually trying to write up a blog post for my web page and was getting frustrated by the distractions and noise of the actual writing process. So I designed an application to help me. This is the story of how that application came to be and the lessons I learned along the way.
Honestly, I had no idea how to design or build an application, or even to determine what type it should be. I decided it was time to make some new friends. People had been suggesting that I start using AI to assist with tasks, and I even took a prompt writing class, so I thought, why not give that a try?
The first lesson I learned is that making a new friend of an AI is easier than it actually is. I know, that made no sense to me either, at first, but eventually it clicked. You see, you can start off in a chat mode where you are just talking away, like you would to someone you meet sitting on a park bench or something. Everything is going fine. Then you ask a question that requires a little deeper understanding and you are suddenly chatting with your know-everything neighbor, getting advice you didn’t ask for, having little minute details explained to you, that you not only already know, but never asked for, and you start to feel like you just met your arch nemesis.
It takes some time to get the model you are working with trained to you and your particular personality and style. That time can be a lot of fun, though, so totally worth it.
Now I was sitting on the proverbial park bench chatting away with a couple of friends, you know, just checking them out to see which one would be a good source for what projects, when one suddenly hit the pay wall and the conversation stopped. Another hit a pay wall and dropped into an older version. Two stayed there and kept the chat alive. Until one decided to take a side road. In the course of an afternoon, I had found, vetted, and established working relationships with four AI models. I will not be naming names because that could influence you, my frustrated reader, and that would not be productive. Yes, I know, it seems like it would, but your personal preferences and my own may be three different models apart. That is a step you will need to perform yourself (if you so desire).
During the chats, I had mentioned that I was having thoughts about creating something to assist with my writing situation, and the idea came through to build an application that fit my own criteria, rather than the imposed manacles of corporate oppression. OK, maybe that is a bit over the top, but you understand the point. Frustration can lead to over exaggerations.
When it was down to my new friend and I, alone on the bench, I started to understand just how little I really understood the proposed project. Did you know that it takes more than just typing some code to get it done? There is planning, detail, all the boring things to complete before you can even toss in the first <tag> of code! I can design things fairly well, but I need to understand the concept first.
I started with the basic questions relating to what would be the most practical way, the easiest way, and the ultimate question: the least expensive way. Now this was based on my personal situation. Money is almost always a concern. I hadn’t even considered making something for other people to use as well. That turned into an educational conversation. There are two ways these can go: excited anticipation or overwhelming loss of interest. If it leads to a loss of interest, perhaps it is time to step back and rethink the concept, not that it is a bad idea, but just that it isn’t ready for the building stage yet. And if it leads to the anticipation, you may want to slow down, because jumping in with a truckload of excitement and a sandwich bag of planning will likely lead to a lot more extra rework and replanning as you go.
My AI friend was all about jumping in. There were 500 lines of code popping up before I had any idea what was being built! Lesson two: Take the time to write the prompts for your AI assistant!
Let me provide you with a basic template you can use:
Please ask ME clarifying questions about each of these points before suggesting any code. I want to understand what I'm building before we build it.”
This is a solid start and you can modify as you need, or if you need. Remember that by default, most AI will be in ‘helpful’ mode, and you may want to change that by telling it what role you want it to take. One of my AI ‘friends’ said you can even add this line: "Pretend I'm explaining this project to a friend who knows nothing about technology - help me get that explanation clear first." (I find that ironical because I used that prompt on another one and it lasted for almost three entire prompts before there was a sudden jump back into helpful mode. Can you guess which one it was?)
Once that was under control (or closer to it) it was time to get to the designing. The preliminary discussions had led to the project being a standalone application to reduce potential distractions, but also to help ensure writers’ privacy for their work. The vision I had in my head seemed plausible, which was a relief, let me assure you! There were those features that I wanted that I had to set aside, though, for the offline mode to function. Integration of some features would require reaching out to a server for full and proper functionality. I did not want that. This brings us to lesson three: be prepared to make changes.
That was one of my highest hurdles to designing. Initially, I wanted an integrated AI writing assistant like Chrome uses Gemini and Microsoft uses Copilot, but to tie something like that into the project would require connections to the server every time it checked anything. That is as far removed from the offline core principle as I could get, and I did not want to get away from it a single step. It was time to make a change.
I am not familiar with every tool available out there. No one can be as it seems new ones are being created almost hourly. I needed something though, or the entire project would just be a fancier-looking Notepad. Following more discussions with my group of friends, my planning committee so to speak, the idea morphed into creating a PWA. Give me a second and I will explain that to you. I needed it explained as well.
PWA is a Progressive Web Application.
Still clear as mud, isn’t it? Well, what that means is that the application can be installed on the computer as a native application, though it is designed and built to be accessible through a browser and run offline. You don’t have to even open a browser to run it as it will create its own instance for you. (That is handy!) This was also an advantage for my concept as it allows the documents to be stored directly in the browser and not easily found on the system hard drive. Another step of privacy I wanted to have. Sometimes writers may be working on a shared system, but working on highly confidential or private material. Who wants their nosey roommate stumbling across their script for the next Broadway smash!?
This opened up a whole new field of confusion for me, though. I have some familiarity with and comfort with HTML5 and even some CSS, but something like this was a level of coding I knew of, but not anything about how. I understood the base concept of requiring java integration (and no, I was wrong too, it doesn’t mean drinking coffee while designing.) I went to my Coding AI associate to have this all explained. If I wanted to have the application installable, it would need to be wrapped and made.
Exactly. WTF?
What it means is that your app needs to be structured in a way that browsers and operating systems recognize as installable. That’s what a Progressive Web App (PWA) is for. You’re not just tossing HTML and CSS into it—you’re adding other things it will need. Things like a manifest file (to tell the system what your app is and how it should behave) and a service worker (which handles offline access and caching). Together, they give your app the polish and presence of something native, even though it’s built with web tech.
Why does this matter? Because without that wrapping, your app is just another webpage, but with it, that page becomes a locally installed application. You can launch it even without any internet connection. Yes, with a PWA, you can continue to work on your laptop without power for as long as your battery lasts. (So don’t tell the boss you have this!)
So here I was, already to start building my dream application, only to realize that I had even less of an idea how than when I started. It was more than a little disappointing. This was a make-or-break moment, though. I could either stick it out and carry on, even with the additional learning curve, or determine that it wasn’t worth the effort. When this moment hit, I looked deeper into why I wanted to build this application. I didn’t see this as my get-rich-quick plan for retirement. (Though the thought does have appeal!) I was still on the fence about if it was even something I wanted to share. I had to determine if my reason for this project was strong enough to push forward, digging through the trenches of struggle and persevering through the trials of JS, JSON, and Electron.
It was actually not as complicated as all that, though, for me. I felt I needed this for myself.
I had a vision. I had a plan. I didn’t have the training. I did have my four AI friends, each of which claimed to be experts at that. Time to fill the coffee cup, roll up the sleeves, and start pulling out my hair. I had a computer. I had internet. I had software. I should be all set to start building, right?
Wrong. I had to set up the ‘environment’ for developing the ‘package’. (Aren’t lingo and jargon fun?) Once again, I had to have discussions with my AI team to even learn what I needed to learn. The first conversation dealt with exactly what I needed the application to be, not wanted. That led to the discussion of what each feature would be like, in detail, to determine which type of language would be best for building each, and then how they would all work (or not) together. Remember lesson three? That was a major component of this stage. In fact, that plays the role of a familiar neighbor that feels welcome to barge into your kitchen, any time, day or night, grab a cup of coffee, and sit down to chat.
I had determined what my environment would be: a nice, fancy WYSIWYG (What You See Is What You Get) web building tool, a couple of legal tablets, a box of colored pencils, and a three-pound bag of dark roast coffee beans. Lesson three sat down, smiled and me, and stole my colored pencils and started doodling all over the tablets. I was not going to be needing those, it seemed. That three-pound bag? Not even close to enough. Dedication and commitment were challenged, but perseverance won out.
After having the first draft built in HTML, I brought the team together, and it was promptly picked apart, shuffled around, and determined that it looked cute, but wasn’t ever going to be practical. And thus I was introduced to the wonderful world of JAVA, and shown how .js and .json files were going to replace all my carefully integrated .css tags. We had not even gotten to the discussion on the make, build, or deployment process. This was going to put my confidence and trust in AI on a whole new level. I had toyed around with several, but never this intensely.
Did you know that packaging the application is an entirely new and different environment from the one you actually create it in? I didn’t either. Isn’t all this learning and growing fun? Anyway, as I was running the first demonstration version of the application, Lesson three looked over the rim of its umpteenth cup of java and ask if this was going to be something that needed to be installed. Remember the part about the PWA? Apparently, in the excitement of creating my masterpiece, I had neglected to remind the AI team of that little detail. Lesson four: not all redesigns are total wipe and start over situations, thankfully.
My initial design incorporated the setup in the index.html file. The transition to an installable format required wrapping the project. This required the switch to an index.js file. This is where housekeeping started to become confusing. I was keeping all of the original files and work done even after the switch, for my own sanity, so I could go back and check details. Lesson five: changes need to be documented separately for sanity!
I learned this one the hard way and going back to try and document after the fact makes for an imprecise and inaccurate record. It became almost worthwhile to save it all to a different location and start over. Do not be afraid if you find yourself in this situation. Rather than seeing this as a failure, change your point of view, like Edison did. You found another way to not build your application. This can save days of work and frustration in your next project.
At this point, I had a working version set up on my local system that did everything I wanted it to do, but the packing broke several parts. I learned how to open and use the browser’s built-in dev tools to help isolate the problems. Again, remembering which files were actually being used -vs- which ones I thought were active would have saved headaches. Documentation is more than a good idea, it is an essential tool in the process. I would like to say I have learned that lesson, but I am nothing if not a victim of my own human nature.
Arguably the most important lesson, lesson six, is to test often. I was testing after every code change and not seeing results. That is when I learned that I needed to clean and rerun the make operation between every change and test. It took longer, but it did improve the results.
Another pointer I discovered the hard way, was that different AI models give different responses to the same situation. Attempts to correct Access Violation errors led to different ‘fixes’ that usually ended up breaking some other part of the application. Looking back on this, it makes sense as they were not current on any work done my another AI model, which confused me, as I was sharing the files directly. Needless to say, my levels of frustration made me pause and even stop for the day at several points. It is OK to take a break. Sometimes it is even necessary!
I think this is about all I have to say on this issue for now, as my recent break from the application building has turned into a hiatus while another thought tickles my fancy. Stay turned for further updates and additional words of wisdom. Thanks!
Doctor Donald