Free GUI: Development Tiers

Detailing Free GUI's concepts of development tiers is dangerous, because there is a lot that can conflict before the acts of finalizing design and then further creating a real world implementation.

The concept of inventing development tiers like this is extremely alien to any existing development techniques. It is what is meant by creating very refined tools and new methods for easing development. Multiple major aspects of Free GUI hugely converge around these tiers to create new positive trade-offs of development and sharing workflows and rationales in technical optimizations.

Development tiers are about accentuating clear distinctions between defined sandboxes of development and contribution that correspond to:

• development skill
• language involvement
• portions of contribution
• clarity in packaging types and risks
• clarity in security levels of package contents
• stopping points for user investment of time and effort
• scopes with clarity
• skill ascension levels
• degrees of confidence and mastery
• clearly shared points of
• reversal
• swapping / modularity
• management

Generally, the idea is to define a tier according to a particular skill level, and one corresponding language. Next, the idea is to customize each corresponding language to include as much possible capability into that skill level as is reasonable (such that it does not exceed the skill level).

One can see why this makes it unacceptable to acquire existing languages and group them together. Free GUI requires detailed design attention to each and every individual language and associated files and editors, as well as a packaging technique that would work across the system.

Some Predictive Intuitions

We might apply some common sense predictions onto Free GUI.

First, let's describe the process of thinking about the system from a new angle:

1. Take a normal woven process of developer workflow from an experienced standpoint.
2. Divide that chaotic process up into smaller portions, potentially serialized, with some in parallel
3. Accentuate clear distinctions between the conceptualization of these divided skill levels or development stages
4. Create clear technical and process-based stopping points between these skills
5. Create individual contribution and packaging techniques for each of these skill sets

We can see why dividing up the process of configuration and development of a software system in these ways can be unappealing to typical experienced developers. It might be wasting their time. It might add extra code and packaging overhead. It might be intrusive to preferred and comfortable workflows.

Software Development Story Time

Every public school in the US discusses in their history classes the American Revolutionary War, and how one reason the British were losing battles early in the war was because the revolutionaries were practicing guerrilla warfare, which was tactically difficult for the British to carry out. The British were trained and commanded to fight in rows of soldiers all lined up, whereas the revolutionaries were not only running circles around the British, but they were also familiar with the landscape on a personal basis. The revolutionaries had knowledge that could not be replaced with generalized training and simplistic, inflexible formations.

This metaphor describes an aspect of experienced software development that makes it impossible to beat. For experienced developers, what others might describe as chaos, is actually just much more natural for them, to whatever degree they have acquired their skills, and to whatever degree they select, manage, combine, and implement their technologies. For a fully realized professional, the only way to do software is also what adds difficulty for newcomers. Another way of saying it is that advanced software development is difficult.

This metaphor can make sense out of many aspects of understanding the development world, whether you are talking about proprietary or open source or whatever. It can relate to gripes developers have about tool selection and ecosystem or company or project culture. 

It overlaps with the concept that people will go and do things the way they see fit, regardless of the path you might create for them. ie: A cat or a toddler will reject a new toy that's made for them, but then choose to play with a random box from the Cosco. People have their own way of doing things that works best for them, and when you spend a lot of time learning different thought processes to develop software over a lot of time, then you become even more entrenched in doing things the unique way you've evolved to.

This comparison between ordered technique and advanced familiarity would probably be a description of Free GUI's negative trade-offs all said and done, especially from the point of view of professional developers. 

It is a fairly common sense anticipation. A lot of experience and time invested in the skill tends to translate to larger oversight of many simultaneous factors of the process, with a very wide range of applicable dynamic decision making and value considerations.

• Total development time might be longer because of added coding to compensate for stop points and imposed development gaps
• Tier isolation interrupts organic cohesion of advanced workflows and code weaving processes
• Limited flexibility imposed by highly ordered structure
• Overly stringent form

Not Primarily for Advanced Developers

Free GUI is not primarily designed for experienced developers, because a large part of the project deals with dividing development up into smaller distinct portions for people with more time to learn as they use the system. This can impact the flow of advanced development for people who go to school full time, or spend full days over long periods aggressively acquiring the skills.

Still a large part of designing Free GUI's workings is about creating redundant methods for development, both GUI based, and text based, and more conventional methods - that all attack the same code and packaging from different angles of approach.

In any case, there will be those aspects of Free GUI that fill niches that even experienced developers can find useful in daily life - particularly in cases wherever having a custom GUI interaction matters to them.

Alas, there are many many tasks where experienced developers do not prefer any GUI interaction at all, even when the option is convenient.

One Specific Development Context

It is not insignificant to mention this. One thing Free GUI has going for it is that all of the use cases of Free GUI exist within the same context: 

• Desktop customization
• Desktop tasks
• Application creation
• Application-level Tasks

The reason this is critical is because you're talking about the ability to really narrow down the purposes of the coding, and to contextualize the environment. This can contribute to enhancing rapid development and compilation processes.

Primarily For:

• Learning as You Go (non-pro)
• gradual processes of building life-long skills
• Building as You Go (non-pro)
• gradual accruing of more advanced workflows
• gradual accruing of comlex tool combinations
• Contributing as You Go (non-pro)
• system script GUIs
• toolbar tasks
• visual styles
• Consumers of Variety (Anyone)
• people who simply enjoy many theme options
• people who enjoy small tool options
• Heavily Individual Utilities (Anyone)
• DE System Workflows
• Unique task-level utilities
• Fastest Simple GUI Construction (Anyone)
• fastest tools for moving scripts to fully launching applications
• most rapidly implement databases, spreadsheets, custom config options with GUI actions
• High Priority Exceptions (Anyone)
• people who highly value the design techniques
• people who highly value the shared resources
• people who prefer the Free GUI techniques even for more advanced applications

So Why Development Tiers?

• Small portion sizes
• Easier contribution and consumption
• short-term commitments are increasingly possible
• Both low-key and critical levels of contribution and sharing are possible
• re-use of components
• Enables anticipation of skill ceilings at varying levels
• Additional kind of users who know they only want to invest a certain amount
• Additional kind of users who know they can only get so technical
• Enable different user types to engage with creating highly convenient systems, with as little excess in technical requirements as possible.
• Facilitate much greater level of optimization in skill acquisition, skill productivity, and skill transfer across the system
• Facilitates structured relationships between modular components
• Not necessarily enforces them
• Modularity Structures Built Into the Packaging and Sharing Systems
• Enables sub-class based modular siblings for swapping and interchanging parts
• This is hard to describe, but very significant
• It deals with building larger systems with smaller components.
• It deals with potentially leveraging cross-modular interfaces for consistent compatibility and re-usability towards very rapid and variable construction of larger systems.
• Still requires user investment to understand how this works
• Still allows multiple methods of accomplishing this, or not creating highly modular systems at all.