|Note: Started a GitHub project today
We'll be transitioning over to that mode where we can
leverage work on Truth Engineering and a new type of family
site that stresses holistic modes in the 'digital village.'
Context: Improvement to website using our own construction (TGS, Inc. discussion) return to: Home, Demo
Trade-off: Get or buy off the shelf versus roll you own (driven by content handling and expectations)
Side-effect: Learn computing from ground up experimentally (or computing exploratively)
Motivation: Computing for every man as our right, plus demonstration of this with relevant content.
Examples/Technical (DevLog): Continuation of log at Main site - devlog.
Discussion: We are now twenty plus years into the web (WWW) and have seen ubiquitous solutions in about every corner of human activity. Mobile devices provide power rivaling desktop workstations (even that of compute servers). 'Embedded' has entire new definitions and examples pending; reminder: this approach has been around for a long time, and pre-existed the Internet. HTTP enabled advances far beyond what was expected. But, with the evolution, one can trace the problems that arose, some of which were foreseen or could have been given the effort. One huge change was that requirements, which had been central to computer system development, lost its punch as a throw-out and respond to criticisms (and failures) became the vogue. Quick releases carried lots of risk that many times came to fruition; we are lucky that it was not much worse (as we seen has happened with social media's promise of maximum chaos). But the form followed the functionality that has increased without bounds, it seems. Just the simple configuration of HTML/CSS/JS has changed tremendously. This triad is mentioned as it will be the focus and tool for the start of the necessary work which has not been defined. Rather, we need to look at the situation and try to settled on what is to be done. There are good examples, such as the Stanford Encyclopedia of Philosophy which has clean and elegant look as well as fulfilling a huge commitment with regard to content of a superior nature. Examples, on the other side, can be found with any of the extremely managed site of commercialized mayhem and, perhaps, other sites whose intent is to lure (evoke reaction). In between is an endless, and growing, set of examples. And, we will pull some of these together (first example).Requirement: We started our site on Microsoft's OfficeLive in 2010. A couple of years later, we saw the emergence of Office360 and decided to not go that route (New era - March 2012). So, I went looking for web hosts plus did a survey of the approaches of the time. I settled on Hub (Linux, etc.). And, steered away from the heavy database usage. Hence, I had to build my site by hand, meaning HTML (so, I dropped back to about 2000). Also, we had our look established. I snapped images off of the site and built an interface using these. The color and layout is close to what we had on OfficeLive. But, the idea was to have enough to keep working. The left image shows the state of the system, at that time. OfficeLive allowed an asp-based website configurator which I used. After all, the intent was content management not coding. I got thrown into website building when going off of asp. What to use?
But, it gets back to the decision about buy versus build. Or, off the shelf, whether free or not, which ties one into the work of others versus roll-your-own. Since I am looking for simple, doing something that way looks appealing, especially if it ties in with trying to show how to learn coding. There are pros and cons for either choice. With the cloud, people are getting even more remote from their stuff. I, at least, can log into the host that is being access from the web. Too, files are more than a metaphor. The unstructured database can be a problem. Balance is important.
Leaving these types of decisions to academics might provide something useful. Rather, though, we see the large vendors establishing the protocols and what have you. In fact, things have changed so much in the rush forward, one has to wonder if we need to step back and look at things. But, that is getting ahead of ourselves. We want to show those who do not know code, or fear it, that they can learn, enough to know what is going on with these decisions and their discussions.
Editor/IDE: The tool set requirement is minimal. For editing HTML (in a WYSIWYG fashion), I use Sea Monkey's Composer. Otherwise, one can edit HTML files with any editor, say Wordpad. Same goes for CSS or JSS. What brings more power would be the workbench tools that come with a browser. And, any of these will allow writes within the code to go to a console which can be used to watch the computer do its thing.
The industry has evolved several IDEs which are development environments. They get complicated real fast. Doesn't everything? But, as my simple little website shows, one can do work and still not need complexity. That will come on its own. It's like pushing a wheelbarrow versus have a little bobcat do work. Would you believe that I can point to a post-Doc biology moving dirt by hand? Lots of it.
One of the hardest thing about code is that everything has to be specified. And, in the distributed world, finding the particular source for a value can be extremely difficult. CSS allows local overrides. With JS, one controls the environment, to an extent. But, your code may be dependent upon some other bit of code. Other than that, though, it is open.
Exercise to find where things are defined and why are always worth doing. CSS is a huge parametric system that gets larger by time. But, it also is quite capable (there is a 3D graphic engine written this way). And, CSS is like a database, too. One writes the CSS statements that will be subsumed with in a HTML file and presented to a browser. In short, this is coding albeit a high-level type. Note please, that plenty argue that we ought to be working at this level, anyway, due to complications that arise.
So, we will do some structure changes with code using CSS and JS. Too, we'll pick up existing examples and modify them. Lots of them. That is, coding is never tabula raza. After all, lots of stuff has already been done. And, reuse is something to be respected. One can take any page presented on a browser and look at specifics.
In a sense, this is 'computing for peasants' which is not derogatory. Let's say, not ivory towered. Top-down versus bottom-up will apply, always does. But, we can teach people to know how to open up and look at what is flowing on the web; it would be part of a truth engineering outlook.
Examples: We have started to collect approaches starting with a simple (scroll-options - only HTML/CSS) touch. The first is fully parametric making use of control 'float' of images which forces a scroll-bar with a manual slider. Not fancy. Works.
Configuration: Til now, all of our web pages have been, for the most part, thought of as building toward a book that included hyperlinks. As such, pages were mostly static except for things related to the mouse, such as 'hover.' Then, we could use SeaMonkey's editor plus some textual editors and worry about Content (see above). Too, we just pushed up via FTP from our local server to WebHostingHub. Early on, we had only HTML, with a footer script for 'date modified' added in once we got to HTML/CSS. You know how tedious it is to go through pages and change notices based upon years? All along, there was the intent to build further. And, not go off the shelf (a whole discussion that must be had - at some point). So, recently, we put in a 'image index' using adaptive techniques which are required for mobile. I do not have one yet but looked at this site recently and liked that the browser wars have settled down. That effort helped with maintaining the images. But, Chrome kept complaining when I was in the 'development tools' area about 'document.write' (which is still valid to use in the static mode). Well, on looking further, there is one war now about how to replace this facility. Given our thrust, we never had a problem. To make this short, the decision was to go with elements and properties (innerHTML). That has already been done for the footer for this site. The 'main' site has not been reconfigured yet. We intend to write about all of this as we start to bring in other modifications.
Technology: The industry rushes along in a lock-step. At each of the decision points that we are documenting and discussing, there were options based upon the current state of the art. Well, mobile apps that came in post 2008 have really changed in tone as the concept of services and resources to meet these evolved. For good mobile apps, there are corresponding views of web apps that require only a browser. Our main work entry has been via a laptop with simulation being used to assess mobility and such. We are about to step into the distributed world of apps where we handle any type of platform. BTW, this site represents a minimal 'roll your own' bit of capability sufficient to handle what we needed so far. Of course, we have a stack of new requirements to look at. However, we can continue in this mode and bring in new features in a stable manner. The main problem is trying to figure how to do this minimally as there are a whole lot of options with no clear winner. We'll have some commentary in this post: Techie stuff. Mostly, we'll have links to other areas as we proceed that will have more details.