Command Wiki: High Level Structure

 All Posts Tagged: Command Wiki 

"High Level Structure" could also be read, "High Layer Structure". It is about the expression of data structures that is made possible at the UX layer. It is specifically about how the application's users can create things at the frontend, as opposed to low layer backend programming code of the application. 

This is inclusive of:

• GUI UX tools
• Text-based syntax coding and markup UX
• Abstract models / logic models / relationship models

The concept of this high level structure is to provide basic means to creating more emergent complexity from it. It's about using these tools to provide the maximum amount of practical usability within the confines of non-professional level coding. These tools include GUI tools, markup syntax, coding syntax, and pre-configured models of abstract data representations.

Code as UX

Again, it means there is a big distinction between backend code and frontend code in the application. 

Code as UX is like some kind of markup. However in the case of this application, it is taking the idea of markup further conceptually. The markup is treated as if it never had anything to do with a straight expression of a few html elements. In this case it is more distinctly UX as a goal, so that the UX is liberated to become designed according to however it might best serve the purposes of the application.

Due to this design goal, it will not likely make as much sense to focus on using a web-based platform for the application, but instead a Linux native tool set for a more ground-up approach. That does not necessarily mean that it cannot be built using a web engine, but it definitely reduces the number of benefits of using a web-based platform.

Thoughts on platform considerations probably needs a dedicated post.

Tiddlywiki High Level Structure

If one takes a while to look at the application Tiddlywiki for example, then there are methods for mimicking all kinds of data structures and relationships through what they call "tiddlers" and "tiddler fields", or "tiddler dictionaries", and their tagging system. 

These features are very very generic and basic, to be able to mimic many things at the GUI level. The generalization and simple approachablility makes them user friendly, but they are not intended to fill the purpose of creating professional enterprise databases by any means.

Tiddlywiki has application-unique, special-purpose front-end coding syntax for managing a lot of programmatic-type tasks for users. Tiddlywiki is also highly extensible and modifiable by virtue of some specific plugin techniques, and even more so because it is built around general web technologies.

Tiddlywiki uses its own code-based techniques for users to specify variables, parse and recombine text, perform mathematical operations, express custom GUI widgets, filter lists, etc.

Tiddlywiki is a huge inspiration for this application idea. Tiddlywiki's tool set also has its proclivities and limitations however. In particular, its fundamental basis on tiddlers is very much up for contemplation as compared to some other version of feature emergence. 

Another point against it is that the default UI's particular methods of interacting with tiddlers and fields  and dictionaries is a problem. Tiddlywiki is made to be able to add custom themes to it, but most efforts are not complete, and they are especially NOT geared towards changing the UI to deal with Tiddlers in a more expedient fashion for these kinds of purposes.

Now, it is worth considering that if the right UI is combined with Tiddlywiki, then it would somewhat change this. This would be a compromise of a particular vision, but it might be the best compromise under my own personal constraints.

In any case, there should be some simplistic basis to create emergent structure. It needs to be simple to grasp quickly, but extent out from that. It also needs to be performant and have system accesses, and that might be a critical issue with Tiddlywiki as well. Tiddlywiki simply is not built with these things in mind.

The details of the emergent complexity from simplicity can make or brake the idea completely in practice. It is far too easy to overshoot or undershoot on exactly how such emergence should play out with an original concept, so it would take some serious effort: failed trial experiments. Again though, Tiddlywiki just is not purpose-built for this idea as a whole, which speaks to the issue.

MediaWiki High Level Structure

With MediaWiki, there is an extension called "Semantic MediaWiki" which is a bit of an afterthought to MediaWiki, and it is almost certainly not purposed the same way that this application has in mind. However it is an example of taking wiki database information - and interpreting it as data in order to accomplish tasks of data analysis about information in the wiki, or about meta information about the wiki.

Comprehensive Wiki, and Internal Data System

One key bit of intention of this application is to have some mixture of these examples to have an intuition based data system to be able to build open-ended kinds of relationships with data in the application.

This syntax can be used to manipulate data that is brought into the application to parse it and re-synthesize it for open-ended purposes.

This topic could probably use its own post in order to attempt to describe it more effectively.

Without Underestimating System Scripting

The point of exchanging data between complex systems on the OS, and the application, and having application methods to work with this data, is to create a space of consistence, where it all becomes usable and interpreted in open-ended ways - to be acted upon and manipulated and recombined and compared for open-ended reasons.

The application data system UX syntax needs to be designed for just the right goldy locks zone of sophistication and ease of use, so that it can serve as a general data liaison between the inner application data - and between any system data that uses full-fledged databases and other complex systems.

The whole reason that this would be able to work is because of just how much can be done with bash, python, and other scripting tools - not because the wiki system attempts to replace these tools. The application UX syntax system, and various tools are about working by itself, and very much so with those commandline tools as equal priorities of the application.

The point of this space of consistence is that these individual OS systems and commandline tools do not have that space of consistence - and they can be swapped out and change at any time. In an application that is created for being able to engage with these other systems and present information about them, all this can benefit from a common method of expression and manipulation - as much as can be done in that UX syntax goldy locks zone, which is open-ended.

(This is about fleshing out a big part of the intent of the application to sufficiently contemplate the application's built-in syntax design. It is more than a toy.)

Not an Online Collaboration Wiki

Despite the queues taken from these wiki examples, they are typically defined as being online and collaborative. This application's purposes can potentially make good use out of many of the same kinds of features that these online wikis have, but the idea is that it is foremost for individuals, and it is a desktop application.

Now, this could change in some regard. But the point is that this application is first and foremost tied to the native system. Making it online has a new set of security concerns that constitutes a whole different can of worms.

That being said, you can just as easily use SSH scripts etc. with this application's integrated terminal access albeit obvious to point out.

A Feasible Application 

In any case, these examples serve as a demonstration of how emergent complexity is able to exist in real-world applications. The one thing that these applications lack however is this exact ability to interface with the commandline with great intention into their core design. This functionality might be able to be tacked on to them, but it would really not be a small fraction as good as it would be with directed intention.