Terminal Command and Scripting Wiki

 All Posts Tagged: Command Wiki 

3 stages of learning are:

1. mimicking and memorization
2. static perceived understanding and memorization with awkward dynamism
3. working dynamic understanding with owned knowledge and context.

(1. Child 2. Teenager 3. Adult)

This description of learning stages are major in the process of going from child to adult, but they are still very descriptive of adult learning, especially when learning very new or alien skillsets.

Almost zero software applications are built to transition users between these phases of learning.

When learning something altogether new like going from Windows to Linux, technical people forget that they take general technical familiarity for granted, especially from seemingly totally different technical skills. People who are going from Windows to Linux are making multiple leaps of blind faith - not just one. They may not even be familiar with text-based stuff at all, or the mindset of acquiring technical-type knowledge. It's not just about knowing about forums and things. It's very often only extensively guided GUI stuff they've encountered.

From a community angle, this issue causes design drama all the way up through the top of open source software applications in general. That's not to say that many applications should try to please so many people at the same time, because most things are designed to do a few things concisely. However, there's a strong use case to advocate for application category that can fulfill this particular set of use cases.

To clarify this use case, there are some ideas about what this use case is. Users are trying to:

• Implement existing techniques without full comprehension
• Add/remove skills to the knowledgebase
• Create dynamism in the implementations of skills that corresponds to personal, nuanced skillset
• Elevate and lower the prominence of skills as they are needed or not needed
• Adapt the knowledge and methods to their individually complex state of learning from one day to the next

In this context, it's critical to note that extensive configurability is only half of the picture. But for the entirety of this idea, it should be assumed that extensive configurability is always looming in the distance. Extensive configurability might also be synonymous with variability, such as with the variability of implementing bash commands with their individual arguments, as well as piping and other bash and cli characteristics for example.

Software that would attempt to fit within these parameters would need to be able to create static systems, and have the user be able to alter those static systems into dynamic ones as the user goes from mimicking commands they do not fully comprehend - to using the occasional option patterns - to dynamically building commands on the fly. But really, it's not a linear process, and that's the key.

Users need to:

1. feed off of the application to give them at least some "fish" to start off from (as in "giving a man a fish" to feed him for a day) This would consist of generalized scripts and commands for common tasks, as well as the GUI widgets and tools to use them and move them around.
2. transition into finding and adding information as an application knowledgebase while being able to rapidly retrieve that information to accomplish specific tasks
3. be able to rapidly retrieve and implement specific actions that are constructed on a custom basis.
4. subtract tasks and information as they no longer rely on helpers
5. keep retired helpers in the background just in case
6. delete, replace, or edit constructed actions

Here's "the Catch"

Because this is specifically for a kind of manually managed learning as opposed to attempts at automated dynamic lesson plans, or pre-programmed linear lesson plans, then the system relies on the users' consciousness of their own learning processes for the developers to trust THEM as users to have a heavy role in morphing the system as they learn. 

The application's job is to provide the tools to facilitate and empower the user to quickly build and morph their own learning, accessibility, and implementation processes, to be as tightly focused, or as varied as they like.

By contrast, many other learning systems, either designed for children, or designed by virtue of their material, focus on a much more fully guided learning process.

Very Few Such Manual Learning Systems

Almost zero software learning systems rely on this trusted consciousness of adults to morph their own acquisition process, and the ones that do don't really understand what they're doing, or if they do, it's not with much pointedly thorough deliberateness.

Flashcard Applications

Some flashcard applications for instance give users the ability to assess their own success, and classify flashcards accordingly, but they do not give the user much ability to practically implement the learned knowledge rapidly. (That's because flashcard managers are too generically purposed towards any type of knowledge.)

They also many times have tagging systems or deck classification systems, which is something.

Once again however, this is what can only be expected, because they are constructed to fill the needs  leftover form an overlap of many use cases for different topics.

Foreign Language Learning

The most extreme example of adaptive learning systems I can think of is foreign language learning systems, where users are required to re-implement their knowledge on a regular basis relatively quickly, in the midst of learning it.

Yet even still, it's not the same as software system like the commandline example. In the case of the commandline, the implementation of the knowledge can have an immediate, realworld impact on the users's computer system. So the learning system is incredibly unique in its realtime relevance.

This is what makes it so critical be able to rapidly:

• input
• find
• implement

(In no particular order) (and for a single system)

Users need to be able to rapidly input and then use the system at the same time, and then have some user skill in terms of how they access their highly personalized inputs to use them in the future. The software would play a key role in guiding the user in doing this with various alternative toolsets for rapid input and retrieval of self-created tool libraries.

The Benefit to "the Catch"

These aspects of the software that make it seem manual, as opposed to automated, are the same aspects that are advantages in terms of "personalization". The personalization is not due to the system reading users' minds, but because the users know themselves. It requires it, but gets out of the way. That's why it's more on the adult side, and requires skill in its usage. Users learn over time what works in how they input and classify commands, or whatever content they're creating.

If such applications are created, then many of the skills of knowing learning techniques could be transferred to other applications that might have similar learning tools.

Unlike child learning systems that must build all learning logic in the system, An adult oriented learning system in this design philosophy provides concise tools for connecting the personal knowledgebase. This might end up look something like a personal wiki, but it would be more streamlined for this specific purpose. 

It's kind of like the difference between an open-world role playing game, and a guided, linear role playing game.

Additionally, another important point is that in terms of development, this takes a specific kind of pressure off the developer, although it matters critically that the designer / developer understands how to create tools that empower the user to rapidly add, subtract, and morph the system - NOT a complex system of automation and user prediction.

• Simultaneous learning and implementation
• Personalized by the person
• Works for realworld practical purposes
• Transferrable to other systems if desired

Sharing is Still Possible

Despite all the power of personalization, users who are desiring to share - and seek to generalize their knowledge for others - can also share more generalized knowledge bases by the software's philosophy, although it's a second priority to personalized setups.

Wider System Freedom of Motion

Without getting overly specific, the content in the knowledgebase can/should be simple files or maybe archives, more-so than closed databases for the specific directed purpose of being able to make use of the tasks independent of the software application itself - to translate [somehow] into usability in the vaster system. There needs to be a commandline environment or prefix to implement the software's benefits in addition to the GUI, though it would not attempt to fully mimic the GUI.

Furthermore, the philosophy is not to lock people into using the application, but to liberate the user at any time, in as many ways as possible. This means that text-based files and classifications can/should work with standard filesystem directories and files and formats that can be parsed and manipulated by scripts.

In this way, the knowledgebase usage can fluidly move between:

1. GUI
2. CLI environment
3. wider system usage
• bash / python / lua scripts
• other

	Widgets	View Docs	Data Tables	Deep Data	User Data	Content Files
GUI Application	yes	yes	yes	yes	yes	yes
CLI Environment	no	via links	with effort	yes	yes	yes
General System	no	no	with effort	no	with effort	by filetype

From a Step Back

This system might be summated as a terminal application with a personal wiki attached to it (or visa versa). The wiki corresponds intimately to permission granting and security concerns of the Linux commandline. This is not a cross platform application, but a native Linux application.

Being a native Linux application is very critical in how the application can integrate into the system. It's a very open-ended concept, but it is doubtless to have important implications regardless of variation in security and other philosophies.

There is an application data subsystem, and a separate user-facing data system that the user interacts with. The user data system is expressed in transparent text files, as is all content wherever possible. Visual table data systems that can conditionally modify custom data points, dates, and numbers like spreadsheet applications - or import external spreadsheet data. Users can create swaths of application variables with these tables, and data types that can be defined according to compatible scripting languages.

The application can embed external files visually, from the filesystem, meaning that they update as the files individually get modified. They are viewable, but probably not editable except for perhaps very specific formats.

Where text-based files are concerned, the files can serve as a base for differential additions, subtractions, formatting, and annotations. The wiki is aware if the source files change. A good example of this is for man pages

Wiki-ness From a Step Back

Wiki entries might consist of commands, passively stored scripts, active scripts, buttons and gui widgets. Base documents can be shown, and additions can be made to them in the wiki, that do not get transferred to the base documents. These consist of personal notes, highlights, graphics, 

Wiki entries would include personal notes about the context of a script or a document or a tool. They can include reminders and lesson plans for knowledge that is very personally applicable to the tools and skills being implemented.

The wiki works heavily with transclusion and substitution features like MediaWiki has. This helps preserve individual file types and data types, while also allowing embedding these visually into constructed pages. application data, meaning that produced text files can be final products of the application data, presented in the form of the user data.single pages. 

Transclusions and substitutions can also be implemented in the user data space, but might negatively impact produced documents' usability at the independent system level. This will depend on what other applications are attempting to interpret these independent files.

CLI Environment From a Step Back

There is a CLI environment that utilizes the application data engine still, but lacks access to viewing external pdf and doc files etc. except for of course opening them externally.

General Accessibility From a Step Back

By contrast, general accessibility to the text-based wiki files does not include access to the deeper data engine, but it should in some way shape or form lend general access to json or some other generalized formatting technique to be interpreted by external means if those are developed by other projects' efforts.

The deeper data engine is for application data to assist in creating and connecting the user markup and text-based documents, as well as connecting tools to particular tasks. It exists to make the content data usable, and to keep it arranged etc. It is also what makes the application more complex and user friendly than a typical wiki.

Accessing the files on the filesystem from programs like awk, sed, vim, or any other code editor etc. will not utilize the application data subsystem, but potentially any user tagging and class system could be made compatible with other applications on their end of development. Perhaps standard format like json or something like json could be used for this, but it's specifically a secondary priority especially if the usability demands of the GUI system would benefit greatly from a more in-depth, custom format.