Tuesday I picked Ally up at The Fort at No 4. On the way home, we stopped to do some banking and pick up some groceries.
As we were walking to the bank I said, “Oh, it is closed.”
“Why?”
“Because it’s Sunday.”
“Huh?”
I then got home and posted “Tuesday Tunes” to show up on Wednesday.
I’ve been working on a major website. This includes a content management system for the site that meets the requirements for that vertical.
What I decided on was a “management bar” for those logged in as manager. When they activate the “edit page” function, all the blocks that can be edited are highlighted. Click on the block to start editing the block.
Save your changes. When you are satisfied, click “make live” on the management bar to make all the changes at once.
There are a few good tools for editing text in place.
This left all the other blocks, image editor, carousel editor, calendar editor and a few others.
Design from the top, build from the bottom
I know what I want to do, how I want it to work. Fortunately, I only have to worry about the “working” part. Not the pretty part. I have a team member who helps with that.
What this means is that I see the entire system laid out. This thing will do this, this other thing will do that, the user will see this.
Which leads to a balancing game. How much is done in the template build out? How much is done in the JavaScript module? How much is done on the backend? And how much support does the Frontend request from the Backend?
Currently, I have three different editing models built, each one a bit different from the others. Why? Piece wise progression.
In my original implementation, all logic was done on the Frontend from data provided by the Backend during page load. These led me to a working edit for the carousel. Click here, drag and drop or upload an image. Click there, and you can rotate, mirror, flip, and crop an image, maintaining a fixed aspect ratio.
The next was the text editor. That was simple because the editor works in place, sort of. But it is working. I’ll be adding more features to it, but that is mostly done.
Then the new image processing came into play. Click on the image you want to edit, a dialog pops up, the original, raw image is loaded. Recorded edits are applied, the image can now be edited.
All modals had to be preloaded. All the content of the modal was preloaded. Everything works by modifying existing elements or modifying the DOM. The only communications with the backend are fetching the raw image.
Which led to the calendar editor.
Piecewise progression.
With this, the amount of data started to exceed easy storage in the DOM. Access to needed data was looking more and more like a call back to the backend. The need to serialize objects on the backend for the frontend to manipulate was starting to get stupidly complex.
This led to a redesign. Instead of multiple modals, there is now a single modal (dialog) which is fetched, on need, from the Backend. In this modal, there is a tabbed pane. Click on the tab, a different pane shows.
By listening for a pane to be displayed, we can determine what content we require and request that from the backend, which has full access to all the data and logic required to make this work.
Bingo, everything starts to get easier.
Which means, once this edit is completed, I’ll return to the image editor, make the same design decisions, which in turn will make the carousel editor a simple modification of the image editor.
Things are getting a little easier as I become more comfortable with TypeScript and “promises”
Why the concerns?
First, when I started programming, you didn’t do redundant things because there were no spare cycles and there were no spare bytes.
As an example, I like to write a = do_it(param)->do_other(params2)->do_different(do_wildly_different(param3))
.
This seems reasonable to me. No extra cycles, no extra bytes.
Today, it is better to do r1=do_it(param); r2=do_wildly_different(param3); r3=r1.do_other(param2); r4=r3.do_different(r2);
This performs the same actions, but it is often clearer to read and allows for checking results at each step. All good.
The other big thing is communications. My last project was a shopping app. Our family still uses it. It creates shopping lists that you can then use from your Android Phone. It has more to it, but that’s the gist.
Because communications is sketch around here, it was designed to work in a standalone state, uploading changes when it could, downloading changes when required.
This lead to an entire mindset of “Communications is expensive”. Which I’ve had to break. The new site makes seriously different design choices.
- All Manager level actors will have modern browsers
- All staff working with the site will have reasonable download speeds
- All volunteers using the site will have reasonable browsers and speeds.
- All visitors to the site will have a relatively modern browser.
In other words, If you are working on the site, and it takes 5 seconds to get an updated pane or modal, this will be acceptable, or you will need to upgrade your device.
In looking at the current usage of browsers on the Internet, more than 95% of the people using the Internet will do just fine.
Now back to the Bootstrap 5 grind as I design pretty forms.