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.
Because of its technical simplicity, my blocki navigation is rough and limits its practicable size. Blogs do not really do structured navigation, they just throw some stuff at you in a hopeful kind of way and leave you to figure out what to do about it. On the other hand web sites tend to have good navigation but much of the link grouping and stuff has to be hand-built, if it is to be any good. In both cases the navigation ends up being duplicated on every single page and javascript is invariably used to make it behave smoothly. That makes most web and blog pages both bloated and open to a range of hacking and data-slurping techniques.
Getting away from all that means that even javascript has to be avoided, which is why I chose that route. That means using only static pages, coded in the HTML markup language for web content and the CSS styling language for its look and behaviour. But that does not simplify the task of designing the navigation, in fact rather the reverse. These languages are very limited in their ability to display functional navigation widgets. I am rather pleased even to have created viable pop-up menus, though the limitations of current web standards mean that they do not behave very well.
One technique that helps hugely is to create a navigation menu as a page in its own right and then pop it up in other pages as needed. This means that I can keep the menu present on all pages but only maintain one copy of it. When I add a new page related to its subject, I just add a link to one menu and it appears everywhere. This too is usually done with javascript and complicated programming. In stark contrast, Mediawiki does it brilliantly and calls it "transclusion," but that comes with a heck of a back-end system overload. But it can be done, if rather clunkily, in HTML and CSS. HTML provides several mechanisms; the iframe, embed and 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.
Why do web pages, or browsers, never have a sticky or pop-up "Back to top of page" link? Not every client device in the mobile era has a [Home] key! How often have you had to scroll, scroll, scro-o-o-lllll to get back up there, or hit Reload but the browser kept its current focus near the bottom? So I have been experimenting with one. Sticky top-left seems the best place (for Western left-to-right languages anyway). That puts it in my nav bar, which is in an iframe. But a boilerplate link inside an iframe will only go to the top of the iframe, not of the containing page. For it to work from inside the iframe, it would need to be either javascripted or customised for each page, either of which defeats the whole point of the iframe. One for my HTML5 Sucks rant, methinks. Workaround: leave the navbar corner empty, code the link directly in the main page, and use the CSS position attribute to make it stick over the blank space. Not nice, as it adds boilerplate to every page, but it works. As I write, I am slowly rolling it out as the opportunity occurs; see top left here, for example.
Meanwhile, the rest of the design is still being refined in other small ways and is still proving its point, for example pop-up menus have recently been repositioned. I have even sketched out a longer-term software roadmap.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.
Javascript, cookies and so forth can be used to fill in the missing functionality but are inherently insecure and cautious users disable them. And of course those missing functions and features have to be coded in some way.
Most web site and content creation tools can be used for this, but getting rid of proprietary hooks, spyware, javascript and other anti-privacy features can be a nightmare. Then, building the features from scratch, even to the basic level of this demonstration blocki, is too difficult and time-consuming for most users.
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.
Another way would be to create a blocki using a conventional web design and maintenance tool, and accept the insecurity and risk to privacy introduced by javascript. The tool could then be evolved to move more smarts back server-side, until javascript can be dropped entirely.
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.1 This is the baseline, pretty much what I have here now. Platform is any old web server, site written in HTML and CSS, accessible via HTTPS. Javascript and other active languages are not permitted. Web forms passing data back to any kind of service are ouside this standard, though opening the user's email client is permitted. To qualify as a blocki, topic-oriented click-through navigation (though not necessarily one-click) from any content page to any other must be provided and all content pages should be datestamped for when the content was last updated. Page indexes, Contents lists, etc. count as content for these purposes. Simple navigation boxes and page banners are not content; the use of iframes for such entities is strongly recommended. As CSS has developed, some improvements have pulled through to this blocki, so in this sense v0.1 is an evolving baseline.
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).