For a very long time I have been creating web pages, and ones with alternative effects. They have been, I think, pretty darned good. The very few people who have seen them have responded positively, along the lines of "huh." However, I have only shown them to a very few people.
My concern has been, to put it in as few words as possible, that unguided users wouldn't understand what's going on on these pages. It's a silly notion. For example, though the controls on these pages are unusual, the truth is, people play around with things and are likely to figure them out. Well, if I'm being silly, still, there's probably a reason. Mystical reasoning, which that is, then reveals to me a little whirlwind of reasons. Maybe it's not so important to detail them because, going over this earlier, I found myself emerging from the swirl of reasons into something of a statement of what it is I ultimately want to accomplish. Oh, I remember. I think the results I have been getting are very beautiful. The pages are much simpler than most pages, and partly so in the sense that elements are pared to a kind of absolute simplicity in a way that is unusual - and powerful, too, I think ... but they are, in a way, not so functional, these pages. Maybe I don't want to or need to give up the aesthetic I've developed, but - and this applies to other parts of my life - I'm discovering that aesthetics without functionality maybe leads to trouble.
So, part of the reason the pages aren't functional is because of my limitations as a programmer. For instance, I really only have a working familiarity with the front end - is that the best condensed term we have for it - HTML, CSS, and JavaScript. This means I can't readily save changes. But that's sort of a phantom issue. It's not so much fundamental as it is representative. The front end is an environment within which changes can be made and saved. I am speaking of changes to a page ... I am speaking of looking at a page and making changes to it within an operating environment.
Of course we have very crude tools for this purpose. I'm not talking about packaged content creation software, like Blogger, here, or, say, Facebook. They are slightly more evolved tools. I'm talking about using a text editor to write an html document including styles and scripts. I can then open that file with a browser and the browser will render my code for me.
I'm going to tell my story a little more than I thought. The above procedure allows me to display things around the browser window, pretty much however I like, and then one kind of thing I can display acts as a button, and one thing I've played around with is creating buttons that allow me to move one or another element on the page ... which is to say, in the window. For example, I can put an image on the page, and maybe display at a small size, the size of a postage stamp, and I can also put buttons in the window that allow the visitor to move that image around in the window, and to make it bigger and smaller.
And that's sort of the limit of what I've been able to accomplish, as a matter of fact. From there it's all fantasy. But, going with that, regardless, If there were a number of small images in the window, loaded by the page, and the visitor could move each image independently - it's actually not that hard to set up and I've even done a little of this - then the page would act as almost a board game, or a collage tool. In fact, collage tool is essentially what this is.
So there's this problem of saving changes. Let's say you visit the page, and you move the images around for a while, and then you leave again. You don't want the page taking up space in you cache ... somehow you need to create a record of where the different pictures are, a record which you can provide the page with at a later date, so that, by visiting the page again some time, and giving it that record, you can return to the view of the page you formerly created.
There are, of course, various ways this could be done. For example, if you could somehow get just the code for the page in its new configuration, and paste that into a new text file, and save it as an html file, then you could open the page from there next time. I'm guessing you could do that with one or another of the browser's developer tools. Well, quite aside from the fact that it's a laborious procedure, we would want to consider what exactly would be happening if we did that, because the code for the page, once we've used the controls to move things around, doesn't necessarily exist in the form of an html file, any longer. The code in the original file has been translated into something in RAM, the DOM, and now we need to translate the DOM into code again, which isn't necessarily the same thing as just copying it out.
So, moving page elements around is done with an interface, which, by the way, is part of the page, not part of the browser, and there are some other things we will want to be able to do in this environment, the environment being this page. A short list: adding new elements, and, I suppose, removing elements, and there are also modifications we will want to be able to make to elements, and also moving elements forward and backward, and also moving groups of elements. These are mostly things I haven't been able to demonstrate. I think I probably could create demonstrations of them, but I'm not sure that's the main issue.
Here, really, is a more significant problem. Just image that, playing with this page, I have added really quite a large number of, say, pictures. In order to fit a lot of them on the screen, I made them really small, and then, if I want to see one more completely, I can enlarge it, because the controls do work for that purpose. But seeing a lot of them on the screen at once is interesting because now I have moved them around into groups, and I know that this group over here is pictures of this ... let's say of this project, and that one over there is pictures of another project, and that group down there is resources for a third project, and I have groups on the screen for quite a few more projects, too. So this is why I would want as many as hundreds of pictures in the window at once, but here's the difficulty: if what I've loaded in cache is several hundred full size images, I've used all my cache ... and really to no end. I can't see any of those pictures in detail. Most of that data isn't actually doing a darned thing, but it's taking up space in cache, which, in fact, is an area of memory specially adapted for exactly what all that extra data isn't doing: things. And cache is specifically not adapted for storing stuff, which is exactly what we are doing with it if we are keeping all that data that isn't doing anything in it.
It is, however, a challenging problem. What we need to do is this: when we add an image to the page, we display it, in the page, in the browser, and we do that by putting its data into cache, but not the entire dataset of the original image, rather, only enough data to render it at the desired size in the window. And then, when we push that image back in space, that is, make it smaller and smaller, progressively parts of the data in cache becomes unnecessary, so we want to remove that data from cache. We can now repeat that procedure hundreds of times, adding an image, then pushing it back until it becomes just a dot, and all the images together are clouds of dots, and there are hundreds of them, each of which is an image, but the amount of data in cache remains essentially the same: just the data required to display the page, as configured.
Just to be complete about this, and without going on for too much longer, because you can grasp the principle already, but to be complete, let's say you now move the whole page forward around a point in the window. All the images start to grow, and, in order for them to grow and be detailed, the page needs to get additional data for each image as it grows ... and add that data to cache. But as the page grows, and the images grow, some of them are starting to fly off the edges of the window. And when an image flies off the edge of the window, its data becomes irrelevant to the the window, and to cache, or, if part of the image is outside of the window, the data for that part becomes unnecessary, and this unnecessary data needs to be removed from cache. Our page needs to do this quite efficiently, removing the precise portions of image data that become extraneous, as they become extraneous, and adding precisely the data that becomes newly relevant, as it becomes newly relevant, and, if that is done with precision, it should be efficient, and result in a smooth and manageable flow of data even when and if the page "moves" quite a lot and rapidly. This presumes, in the extreme case, which may well be the default case, that newly relevant data is retrieved from remote servers over the internet. Meanwhile, images are not removed from the page when they fly off the window. The record of the image's identity, location size, and other such details, are retained, even though the image data is being partly or wholly removed.
That, then, is my programming goal, in a sense. As a problem, its solution shapes up into an interesting array of data structures, database structures, geometric "checks", request protocols, and so on.
Behind this goal, however, there is a larger goal, another extension of the functionality of the page, essentially similar, but with additional complications, but, if this larger problem can be solved, it also solves the simpler problem just described.
At any rate, one expedient which came to mind often as I worked on my demo pages, and struggled, however rationally or irrationally, with the feeling that they would not be understood, was the idea of creating manuals. Also, a long time ago I formed the notion that the proper way to teach someone to use a tool must be to tell them how the tool works, in other words, to explain its structure. And I never got very far with manuals, but when I thought about them, which I did often, I see now I thought about the wrong thing. I didn't think about explaining the mechanics of the tool, and instead thought about how to explain how to use the tool. And this always seemed so complicated. First you need to do this, but in order to do that you need to know about this, and here's how you do that, and on and on in circles.
Well, I have been thinking a great deal about this, running new experiments, and trying to fiddle with code in more rational ways, partly based on reading about what rationality is, in this context. Which is interesting because it comes to seem that rationality is the same thing in all contexts. But this is beyond the scope. At any rate, today I found myself almost accidentally writing my manual - it has been acutely on my mind the last few days, but without finding a way to do it - the right way. I described how the program works. And the problem is solved.
Where this is today's Essay 3, Essay 1 starts of quite poetically, but, at the same time, it is, from the beginning, about what the problem is, which is to say, what the product I want to create is, my whole thoroughly wild and gargantuan plan. And then it sort of settles down and establishes some foundational concepts in what I think is quite a rational way. And then where Essay 1 is core concepts, the basic tool set, Essay 2 describes, via a simple scenario, how those tools can be put to use. There is now, before this, an Essay 4.
