Approaching the front-end framework

I want to share my discoveries and tell about stuffed bumps in the way of creating a framework for my employer.

Outsourcing IT companies often work with clients from the same market niche, developing similar solutions. Naturally there is a desire to avoid the invention of the same bicycle in each new project. Most of the developers during their career develop their own frameworks, which by the way is a good indication of their competence. And the trend of turning a web page from a document into an art object translates the presence of a framework from the category of the desired into the category of the necessary, because it is becoming more and more difficult to neglect team connectivity, universalization (and the synergy expected from it), reduction in the volume of routine tasks and associated stress.

Ready-made frameworks have a serious drawback - the framework is an image of the collective consciousness (and subconsciousness), preferences, style of its development team, as well as its initial “sharpening” one way or another to solve a certain (own) task. The problem is that these tasks are either too specific (and a step away from the internal logic of the framework is punishable by “reeling” the whole structure), or too abstract (and there is a danger of using the framework only for the use of the framework). For myself, I discovered that creating your own framework as a kind of ongoing process within an IT company or department has many side positive effects. And this is why: when a team is assembled for a project, a set of abstract project roles is often identified, rather than a team of real personalities, i.e. for example, an analyst and a designer, not Sergey O. and Sergey M., who have very specific (and different) values, visions, their own perceptions, and problems with communication. When these problems emerge and force management to pay attention to them, the problems of communication and harmony are evaluated by some weighted average or indirect indicators, and solved by facs and “general strengthening training-drinking drills”. Although it is precisely by creating your own framework that these problems can at least be revealed.

A professional worker is allocated (at least) with 3 signs: a process, a framework and introspection (working with feedback on one’s activities). And all these things are individual and organic for a particular person. The goal is to compile a common framework that will pull the establishment and calibration of a better overall process and will allow you to do self-analysis on a team or even company scale. And it is necessary to observe the personal characteristics of the participants, but at the same time the framework should be useful to all participants in the development process. Let's start with the front-end framework. The front-end framework here fits like nothing else, because it can be packed with the expectations and visions of all project participants, also interactive components are intuitive and illustrative, this is a cool slice.
')
By the uselessness of the framework, we mean the ratio of time spent on its creation, to the time that was saved due to its use, this indicator is useful to publish in the form of a poster in the smoking room. Let's start with an analysis of the existing company portfolio and do the following visualization: we place all the company's projects as points in a discrete space (let's call it the team / company competence space) with coordinates in the axes “IxD Patterns”, “Visual Design Concepts” and “Back-end Requirements and Restrictions.



The coordinates, of course, are conditional, the point-projects should be located closer / farther from the typical “nodal” solutions with coordinates like Project-X (business card site; in a minimalist style; on Drupal) . Understand the axes. Suggest your interactions designer (because of the confusion with the posts, it's hard to guess how this person is called in you) to disassemble the patterns that were used in the creation of previous projects, and make a list of them in terms of (for example) welie.com/patterns in decreasing order of frequency their use, this list will be the scale on this axis. Creating a graduation of this axis requires significant intellectual efforts, however, a person with experience must have already developed his own hierarchical system, which is easy to interpret on a similar scale. Here it is necessary to decide on the degree of immersion in the details, take the site-business card, or, say, a block like the main navigation for a serif pattern, again, everything is decided by competence / experience. Next, ask your graphic designer in the company with the coder to determine the scale of "increasing complexity" of appearance for each of the patterns of the previous scale, best if the designer draws them in the form of an evolutionary series, for example:



And the coder will have an understanding of how to create a solution like <tag class = "button-frutiger button-curved-7px button-gradient-03 button-shadow-04" ...> Caption </ tag>, when it can without significant time costs, transform one skin into another. Pre-determine the list of "supported" designism or the so-called. "Sure fire" execution techniques. This is the most subjective moment, the personal qualities of the designer and coder, their ability to communicate can cause the failure of the whole undertaking. Finally, invite back-end developers to draw a scale out of the requirements / constraints for each of the patterns, in terms of applicability and “digestibility” of solutions within the framework of the engines used by them. Each axis, points on the axes and the whole process of creating a framework should be widely discussed using wiki-like solutions, since the value of the result for all participants in the development is guaranteed only by the degree of their involvement.

Of course, there are much more axes / parameters for describing projects. You can recall the User Experience layers from JJ Garrett , but the proposed 3 axes are enough to isolate the core - the bike most often invented by a team / company. This core describes the scope of the framework, the creation of which will be useful for this team / company, taking into account the focus on niche customers, in the future the volume of a fairly dense part of the core can be considered as an indicator of growth / narrowing competence and use it when planning growth, analyzing competitors, etc. .

Later, when the framework exists, the development should be reduced to using solutions from the framework with minor modifications, in the case when the framework does not have a suitable workpiece, the framework expands first, and then we obtain a particular solution with it, this guarantees the inertia in evolution . Creating a framework is an eternal project, around which the discussions should not stop, you should make the process of creating it for everyone and everyone with responsible persons, curators from among informal community leaders within the company, builds (which can be made commercial products). Creating a front-end framework can now coincide with the transition to html5 and can help you transform the content of the work of developers from the high-speed delivery of your portion to a common conveyor into an act of joint creativity in the spirit of Dadaists or pop art artists . Ideal effect: when all team members unconsciously are in continuous dialogue with each other about the processes around the framework, provoke each other to professional growth, strive to reach transcendental solutions.