WorkBuddy's Settings Entry: I Used the Wrong Layer for Three Weeks

That gear icon in the bottom-left of WorkBuddy holds a layered configuration setup, nothing to do with changing theme or language. Get the layers wrong and everything after is a pit — it took me three weeks to figure it out.

A couple days ago I came across an article about designing software settings entry points, written for front-end people. It split settings into three categories: system settings manage this machine, account management manages your account, connection config manages the workspace. At the time I thought, what does this have to do with me, a nurse. Looking back, all the pits I fell into are in these three categories.

My approach at first was to stuff everything into global.

The scheduling rules, the format requirements for the medication quick-reference table, file read permissions — I dumped it all into one global rule. Thinking it'd save trouble, configure once and it works every conversation after.

The first two weeks were fine. The third week problems started. I added a new Skill specifically for the medication quick-reference table, and it clashed with the global rule "don't modify raw data," and the resulting table swallowed the notes column. I thought it was the model's problem, switched models and it was the same.

Later I learned rules have priority: Skill level > session level > global level. I'd piled everything at the bottom layer, which meant every time I was fighting against myself.

How I configure it now

Open WorkBuddy, there's a gear in the bottom-left, click into it. The left column is groups, and I use them by the three categories.

The system settings category, I put things that are truly only about this computer — whether notifications pop, interface language. Get it wrong, no big deal, switch devices and it's back to how it was. The account management category is login, subscription, I basically don't touch it.

The one that really takes thought is the third category, the part about workspace and connections. My model, permissions, local file read scope, all in there.

On the model side I hit one specific pit. I hooked up a third-party model myself, filled in the provider and key, clicked save. It saved, but the conversation still used the default model. I refilled it twice before realizing you have to go back to the model list and manually switch — saving doesn't equal enabling. I wrote a separate post about this pit on the forum, and people are still replying saying they hit it too.

For permissions I use three levels: allow, ask, deny. allow passes straight through, ask pops up a question each time, deny rejects outright. My night-shift workflow I split like this. Reading the schedule in my specified folder uses allow, modifying file contents uses ask, sending emails out or touching the contacts list uses deny.

The logic is simple. Read wrong, worst case you redo it; modify wrong, you have to check one by one; send it out and you can't take it back.

Two things to do routinely

One is after adding a new Skill, go back and check whether it conflicts with the global rules. Skill has higher priority, it will override global, but it won't proactively tell you it overrode it.

The other is the local file read scope — narrow it down every so often. At first, to save trouble, I pointed it at the whole desktop. Later I found it would casually read my stored personal spreadsheets. Now I keep only one dedicated folder, with just scheduling and medication stuff in it.

My environment is the personal edition; the department side is a different system, so it may not apply to everyone. But the layering thing has nothing to do with which version you use.

Configuring the settings entry once doesn't last long — you have to go back and flip through it every so often.