Updated 11 Nov 2021
A "blocki" is a cross between a blog and a wiki. It is for all those miscellaneous thoughts you want to share as they occur, like a blog, but keep growing on you so you want to go back to refine them and keep them up to date, like a wiki.
The idea crystallised in 2014 and I started this one as a personal experiment. I wanted to see how useful a tool it might be. I also wanted it to be lightweight, to avoid any need for a complicated back-end server to administer like Drupal or Mediawiki. Indeed I cannot find any kind of publishing server that can be set up and controlled easily by a non-technical user, so I also wanted to see just how little programming code it could get away with. None seemed a good place to start. I decided to keep it in my regular web space and build the whole thing with a text editor. For both security and simplicity I refused to use any active programming languages at all. So it is a bit basic - no search, no visitor comments, no tag clouds, nothing that does anything in the slightest bit smart.
object elements. Of these, the
iframe has proved to work best for blocki navigation menus.
For more about the limitations of HTML and CSS, see HTML 5 Sucks. (technically, the main issue for this blocki is that CSS3 does not auto-size a container to fit imported content, so all my pop-up-menus have to occupy the same fixed slab of real estate. The bit you don't see is transparent, but it is still there. It messes up the full Contents page worst.) Unless and until CSS3 gets its head together, a basic blocki likle this needs to be kept small and easily manageable.
The blocki has proved great for throwing up ideas as I go along, ideas that would disappear into the past on a blog but would turn a normal web site into a half-baked mess and need constant maintenance.
It would be nice to do something similar with graphics and maths equations, but the associated web languages, SVG and MathML, are hideously convoluted. Still, maybe I'll give them a whirl one day.
Some pages, even gropus of pages, eventually mature and become more or less permanent fixtures. As such they continue to clutter up the blocki navigation and it helps to move them logically to a separate, conventional static web site. Moving them physically should also be an option. I have begun to do that with some topics. Each page already has header and footer sections for navigation, with the links and other information provided by templates. To move a topic area logically, I currently clone and update the iframed pages and stylesheet, go through every page and update file paths and the odd name, and updated the blocki's various navigation lists. To move it physically, I also have to go through every page on both sites, checking and updating cross-topic links, and replace every original blocki page with a redirect. To make things as simple as possible, the blocki file tree and CSS structuring need careful design. I am embarrassed to admit that I have had to re-learn the old site-building rule, not to create deep file trees but to keep everything wide and flat. That way, physical moves will seldom be needed at all.
The first sub-sites I moved out went to new folders. The last time, I just moved the aerospace section out as a separate logical web space, still in the blocki file tree. This was easier, but really brought home how the structuring of the file paths and CSS are critical to a minimalist process, even down to things like the stylesheet file name, so that every page in the section does not need updating. The same applies to any header, footer, etc. pages included via iframes. So I still need to revisit that. I then moved it out of the Blocki folder to alongside it anyway, per my remarks above. That needed more fiddling, but physical moves always will.
What software does a blocki need, and not need, to make it easy to set up and use? This one is built on nothing more than a web server, text editor, HTML and CSS, and consequently is clunky and limited for both author and reader. How to do better? Some incomplete thoughts follow.
There are three main classes of user: admin, creator and reader:
Most of the basics are covered by standards-compliant web servers and browsers. HTTPS has become the standard access protocol for almost all remote content. HTML and CSS provide the remaining text functionality after a fashion (and SVG + MathML the diagramming and equations), but with some key shortfalls.
One way forward is to improve the tools I already use, i.e. HTML and CSS, along the lines set out in my HTML 5 Sucks study. Even a local search facility could be implemented in my "Cascasding Simple Smarts" realignment of CSS, without the need to access anything outside the immediate sandbox of the blocki pages; think of it as an additional widget for web forms. A selection of navigation templates and CSS stylesheets would then be all that was needed for many a site creator.
Of course, all this is bound to remain clunky for some users. The ideal would be to develop an easy markup language encompassing both HTML, CSS and the necessary smart functions, such as panscript, and code up a dedicated client-side blocki site designer and maintainer. Panscript will have a Turing-complete programming subset, so the client tool should be compiled from panscript source. Any active code present in the content it processes will be treated as passive content for display.
Any viable blocki standard must engage in three distinct work strands:
Cookies can be useful in giving the user a consistent experience. But client-side cookies are in general no longer trustworthy and tend to get turned off. Cloud-held data swaps one set of risks for another. User preferences are best held server-side, where they can be managed securely alongside their login credentials. Client- and cloud-held repositories can then be offered as options via linking from the server-side preferences, for those users who prefer it that way.
This and other server-side smarts such as search indexing would end up associated with small databases. To what extent should these be maintained off-blocki by a suitable service, or brought into the blocki site space via flat-file csv and similar formats? In-blocki is attractive for its low service overheads and ease of assistive text-based editing.
Can a web server be relied on to block crawlers, bots and other spyware from areas containing sensitive private information in blocki space, or to implement them with an encrypted filesystem? The blocki owner probably has no control over all that, so the generic answer has to be "no". So all that would ideally be managed by dedicated blocki software. The alternative is to leave it up to the provider and caveat emptor - let the prospective user read the small print if they care.
These are things that might be added server- or client-side. Ideally, server-side stuff would be backported to the web server, e.g. as an Apache module, rather than as a bespoke service such as Wordpress. Similarly, client-side features might be backported to the browser.
Indexing and searching. The server maintains searchable/clickable indexes of page content, images and media. When a page is uploaded, the server updates the indexes. The visitor can search or browse the indexes and click through. Would the search algorithm run server- or client-side? Might both be useful, depending on whether the user has opened the index for browsing or not? Client-side can use the browser's search, server-side would only be needed if the index is not opened first and so is not essential.
Site content lists and keywords. The server maintains a clickable list of all articles, sorted alphanumerically. Keywords added to the page by the author may be used to auto-build hierarchical listings by subject, perhaps also a tag cloud, etc.
This is just a notional roadmap towards a viable blocki solution. Almost certainly no more than one grumpy old git's fantasy.
v0.2 This adds a client-side blocki creation and maintenance tool. Its initial purpose is to remove HTML/CSS coding skills from the site desiger and content creator, and is therefore a basic but user-friendly web page editor with a targeted set of features. Later iterations would introduce a simple tag search, list/link html file builder and viewer/page selector display, allowing the creator to tag content and thus supplement or even generate the structured navigation. A tag list template allows the creation and editing of tag/link lists using other tools, including hand coding.
v0.3 Functionally unchanged from v0.2, but implemented in compiled panscript. This implies the development of a suitable compiler which is, in all but name, where the dream parts with sanity.
v1.0 Content creators may write in panscript, with much enhanced transclusion and navigation features. The creation tool automatically transcludes subsidiary content and converts the page to HTML+CSS, when uploading to the live site. Hand-coding of v0.1 pages is unaffected.
v2.0.x... Server-side desirable features standardised via RfC or similar and fed upstream to OSS web servers such as Apache, well-behaved menu features and selected ideas from HTML5 Sucks incorporated into CSS. In particular, the server must be configured such that cookies and other non-volatile (lasting beyond the current session) user information are not exploited without the user's active, explicit and securely recorded consent (for example any default to assumed consent is strictly forbidden).