grant

So, making things composable is good (spreadsheet). Giving people only a confined set of parameters to tweak is bad (analytics custom view). That is my take... for now.

I thought I would just customize the google analytics dashboard, but quickly hit the limits there. With sheets, I'm moving ploddingly (running reports across lots of sheets then assembling them by linking cells) but I haven't hit any limits in terms of what I want to show.

I am building a focused analytics dashboard in google sheets via the google analytics add-on? I'm trying to use it as an opportunity to think about low-code/no-code interfaces.

So possibly I should just get over my aesthetic aversion to http://reportname.org.com . Or I figure out some script/deployment thing that makes it so 'npm run deploy' from the individual report repo seamlessly updates and deploys the parent repo. That's where I stand.

Which is enough complexity that people will probably ask me to deploy instead of doing it on their own. And all this just because I want it on a subdirectory. If I just use a custom subdomain I don't have to go down the submodule path at all.

But that still adds the friction of making anyone who wants to modify and deploy a single report clone the entire reports repo (including the submodules). And I'll have to add explainers to each individual report repo, that you actually need the 'reports' repo.

I think I can smooth this out a bit with npm scripts. So you could clone the reports repo, make changes within the relevant report, 'npm run deploy' from within that report and have it do the report commit and the submodule update so that it will immediately go live.

So I can use submodules. The reportname repo can be a submodule of the reports repo. But this breaks the 'one-command report deployment' that I really like. You have to make the report changes and then tell the reports repo to update its submodules.

I would like the report to sit in a subdirectory. The ideal structure would be http://reports.org.com/reportname . But to get it in a subdirectory it has to actually... be in a subdirectory. Which means that instead of its own repo it needs to be under a 'reports' repo.

We're going to deploy a report using github pages. This is a nice set-up because any team member can clone the repo, make changes, run the deploy script and have the updates go live immediately.

I'm going to type through a github pages subdomain/subdirectory/submodule dilemma I'm working on. Please jump in if you spot a solution.

I wonder what interfaces are closest to representing application state as it actually 'is' on the computer hardware.

Can I expand the user’s understanding or build their intuition about what exactly a computer does and is. Can I demystify.

I’ve been very interested in the possibility of ‘fitting the computer inside your head’ lately. Previously I thought about mental models as something I needed to design and share with the user, something overlaid. Now it’s: can I productively expose lower-level logic.https://twitter.com/tmcw/status/1222351878131834881 …

Thinking about making myself a writing site (again) where the only entry constant is the file naming convention. The generation method is separate and every page is completely self-contained. A redesign only applies going forward, old entries remain the same.

'Asked by Lucy if it was Mr. 95472's way of protesting. "5" replies that this was actually his father's way of "giving in."'https://twitter.com/ChappellTracker/status/1221999333563719680 …