How to make a combined user script for the site?
Suppose that with the help of a script and styles we got the solution of a collection of userscripts for the site, the idea of which had been in the air for a long time and was expressed in the form of wishes by many, in the comments to almost every article on user styles. At the beginning of the year, the implementation of such a solution was even observed - github.com/silentroach/habrafix , which since October 3, 2011, obviously, does not work either. In a simple, initial form, the solution would be difficult to maintain — one person would have to build scripts, support all browsers, add new features at the request of other users, or, at best, consider forks and integrate their functionality.
The big problem will be in the "Sisyphean work" over the scripts. The presentation of the site and scripts on them is regularly changed by official developers, the implementation of each new small functionality requires thinking through, solutions, debugging. When you change the presentation of the site you need to all who did users scripts, suddenly realize it, run to restore and retest all functions. Well, if the function is one and testing in browsers takes day, evening, 2 hours. Less is not always possible, because there are 5 browsers, browser versions, several types of site pages on which the solution (script or part of it) works. Test cases are multiplied and the combinatorial number can be reduced only by heuristics of the developers who are in the topic. If this is a collection of scripts, the author of the collection should retest each function for each movement of developers (or intuitively guess what broke, knowing all the dependencies on the site and in the scripts).
Let's see how many scripts recovered after October 3, 2011. Just do a search: userscripts.org/scripts/search?q=habrahabr&submit=Search , other search words are “habr”, “habr”. All that is higher than the specified date (6 pieces), the authors of the scripts were able to do after the destruction. The rest of the scripts, most likely, do not work (12 pieces only in 2011, 16 for 2010, another 20 for earlier ones), although each, of course, can be restored with the indicated manipulations and testing. But most of the authors, it is obvious that they no longer want to engage in the decision or its publication. What is easy to understand is that the script was, most often, the result of the inspiration of the idea, and a return to the solutions passed is not always interesting and necessary.
If you look at the browser-dependent scripts collections, we will see a similar and slightly different set of realized ideas, some of which, too, could not or did not have time to recover after October 3, 2011.
')
To get around system problems, you need to make system decisions. What kind? We list in the order of "brainstorming."
, collecting not only articles of authors, but also links from other resources to articles, interesting decisions, with the organization, with the development team. So the problems that cannot be solved by Habrom will be taken over by other people, who may be more responsive to innovations, listen to the wishes, and ensure the crowdsourcing development of the site’s automation.
What shall we have? Let's say the team has gathered and can do something for a while with enthusiasm or with the help of venture financing. During the exit to self-sufficiency or self-support, it should be in time:
* Attract a large number of people sufficient for self-maintenance of the public (community) and interest in visits and statements - to make an environment that benefits visitors. As can be seen from the experience of such resources, this is possible with the fulfillment of a number of requirements: the relevance of information, the arrival of people authoritative in some topics and the implementation of well-known principles of network etiquette by users and administrators.
* To improve interfaces - to be responsive to wishes and trends.
* To combine the merits of various resources - to provide a convenient reading of articles of other resources with the discussion at home.
Many people recognize in the described scheme Reddit.com, mixed with digg.com, mixed with RSS feeds from third-party sites (for example, Google Reader) and one more resource, carefully cut out from. Well, the scheme is viable, a group of enthusiasts is required (a recording is announced, and, moreover, there are already people on Habré who approached me with a similar group of ideas so that I could become a participant. It may be worth combining ideas and resources and group).
But the group of proposals is not limited to this, the article is not about this, but about a deeper essence. How else can we realize more viable support for userscripts from various authors?
Making myself aware of the inconvenience and "sisyphosis" of work on user scripts, we will try, yet to build a slightly viable design scheme. The difficulty of maintaining vitality is in strong dependence on the parent site and the lack of any support from it. In such conditions, you can fight and maintain the life of the project by distributing work by plug-ins, for example.
The basic functionality is written, which will be needed in all scripts of the site and which is quite easily mastered, with a minimum of tricks, with ease of documentation. This is a plug-in connection method, uniform plug-in settings, a version control agreement, an agreement on script connection points and styles. Further, in the main script (more precisely, in the utilities for it), regardless of the plug-ins, a project collector for specific browsers can be written. It will help build browser extensions automatically on the basis of pre-shared blocks, and a universal script * .user.js will work in the basic functionality, supporting maximum functionality with degradation.
Briefly for those who are in the know. The functionality of extensions is increased in comparison with the base script due to deeper implementation of code sections to other connection points. For example, we can define our images in the base script through the base64-style, and in the extension we can use images. Styles can be connected only at one point - at the end of the page, as well as perform the scripts. In extensions we can run some scripts before and in another environment. We will use this to improve the quality of page loading. Therefore, the source code of both the main script and the plug-ins will have at least 4 sections. Depending on the features of the site, the number of sections may increase, depending on the groups of HTML pages. Nevertheless, the plugin writer will understand the scheme in which he can quickly write an extension for the site and include it in various ways, including building a single script for a browser (in perspective).
Attempt to pass such a path will be made, because the developments on it already have and they help to simulate the interfaces of work with texts. Giving a report that it may not interest anyone, because there are only a few writers and it is always easier to write an independent script than a plugin.
Finally, there is another way to weaken the “Sisypheus” of work - the prepared parent site should be used to the minimum and in fact. That is, to take from it not content + layout, as all scripts do, but only content. Then we get rid of a number of minuses:
*) do not depend on the layout - a huge relief. Only the parser will depend on the layout, there is no way to go, but it is usually quite simple. Then, if the layout changes, everything collapses first (or what has changed), but after fixing the parser, all scripts and plugins that build the view will continue to work, because they will be on their stable layout.
*) practices are used for other content - it is enough to write a parser of another site - and we have the work of all previously made developments under the resulting data structure.
*) it is more complicated than RSS, but RSS can be an alternative, the official content provider in case the main supplier is broken - the site.
*) do not depend on script errors on parent pages. Now when JS fails, userscript is crashing on the page - a very uninteresting dependence on problems with the developers on the server. Some scripts will have to be duplicated and run due to ajax-uploading data on the parent site, but there is a balance of interests - either we get our own system for receiving someone else’s content, or we completely trust the delivery scripts, but they also have the risk of destroying our scripts (in in general, there are techniques for circumventing such problems, the main thing is that they should not be forgotten, even if everything worked stably for months).
What are the cons?
*) All ajax requests should be repeated in their scripts or use the launch of site scripts to exchange data.
*) the developer of the plug-in needs to work not with the page (which is simple - I watched Ctrl-U, and everything is visible), but with the data categories: message, author, date, answers, author, date, rating, voting site functions, sending messages and t .d .. This is more complicated (for the author of the parser too), but overlaps with a huge plus of independence from the layout, provided that there is a parser. Hence, the plugin, written 2-3 years ago, will work if it concerns the presentation, and 80-90% of the plug-ins are like that. But some of the functions of working with data can also be peeled off from the sites so that the operations “send a response” or send an estimate do not depend on the implementation.
*) the parser developer needs to think over the system well so that it remains easy for plugin developers. Overlapped by the advantages of expanding the developer base.
This third idea seems to be more promising, therefore a set of performers and sponsors is also announced on it.
There are other considerations on how to develop the resulting system to eliminate the next negative factors - deleted messages and articles, server crashes, but they are beyond the scope of the scripts issue under discussion.
There are 3 different ways to attract developers to improve the quality of data on the site. They vary in terms of labor costs and the monetization scheme - from zero to very full. It makes sense to assemble simple scripts in one plugin in order to have not only a useful tool for geeks, but also a model for flexible usability testing on real data and your own experience. For some ideas that can be applied elsewhere. This way is the least expensive and bringing indirect benefits to developers in the form of accumulating their experience.
But such a system is destructively affected by the arbitrariness of the developers of the site, so it would be nice to include the separation of the data structure from the layout into the architecture of the scripting layer. This kind of project can also be started as a public one, with access to cover not only one site, with better protection of information from loss, with deeper development of skills by developers. It is possible that after a project of this level, the development team will gain experience useful for other similar in terms of commercial projects, it will be a good self-promotion and experience.
Finally, it is also possible to attract venture commercial structures, both at the initial stage and later, to create an ambitious and unusual project that combines the solution of the system problems noted and listed in this text. The first two levels have an elaborated development strategy, albeit with an unclear width of audience coverage. Perhaps some of the readers will be able to think through the marketing side of the issue in an unusual plane - not among geeks, but into a slightly different one, and this will be more promising. The third level requires the development of a distributed server system, which goes far beyond the questions about scripts and the presentation of data in browsers. Therefore, it is better that people connect to this part (one is enough) - server-side architects.
So, all 3 directions are relevant and express an approach that is more focused on the quality of presentation of data in social networks.
The big problem will be in the "Sisyphean work" over the scripts. The presentation of the site and scripts on them is regularly changed by official developers, the implementation of each new small functionality requires thinking through, solutions, debugging. When you change the presentation of the site you need to all who did users scripts, suddenly realize it, run to restore and retest all functions. Well, if the function is one and testing in browsers takes day, evening, 2 hours. Less is not always possible, because there are 5 browsers, browser versions, several types of site pages on which the solution (script or part of it) works. Test cases are multiplied and the combinatorial number can be reduced only by heuristics of the developers who are in the topic. If this is a collection of scripts, the author of the collection should retest each function for each movement of developers (or intuitively guess what broke, knowing all the dependencies on the site and in the scripts).
Let's see how many scripts recovered after October 3, 2011. Just do a search: userscripts.org/scripts/search?q=habrahabr&submit=Search , other search words are “habr”, “habr”. All that is higher than the specified date (6 pieces), the authors of the scripts were able to do after the destruction. The rest of the scripts, most likely, do not work (12 pieces only in 2011, 16 for 2010, another 20 for earlier ones), although each, of course, can be restored with the indicated manipulations and testing. But most of the authors, it is obvious that they no longer want to engage in the decision or its publication. What is easy to understand is that the script was, most often, the result of the inspiration of the idea, and a return to the solutions passed is not always interesting and necessary.
If you look at the browser-dependent scripts collections, we will see a similar and slightly different set of realized ideas, some of which, too, could not or did not have time to recover after October 3, 2011.
')
To get around system problems, you need to make system decisions. What kind? We list in the order of "brainstorming."
* one more "Habr"
, collecting not only articles of authors, but also links from other resources to articles, interesting decisions, with the organization, with the development team. So the problems that cannot be solved by Habrom will be taken over by other people, who may be more responsive to innovations, listen to the wishes, and ensure the crowdsourcing development of the site’s automation.
What shall we have? Let's say the team has gathered and can do something for a while with enthusiasm or with the help of venture financing. During the exit to self-sufficiency or self-support, it should be in time:
* Attract a large number of people sufficient for self-maintenance of the public (community) and interest in visits and statements - to make an environment that benefits visitors. As can be seen from the experience of such resources, this is possible with the fulfillment of a number of requirements: the relevance of information, the arrival of people authoritative in some topics and the implementation of well-known principles of network etiquette by users and administrators.
* To improve interfaces - to be responsive to wishes and trends.
* To combine the merits of various resources - to provide a convenient reading of articles of other resources with the discussion at home.
Many people recognize in the described scheme Reddit.com, mixed with digg.com, mixed with RSS feeds from third-party sites (for example, Google Reader) and one more resource, carefully cut out from. Well, the scheme is viable, a group of enthusiasts is required (a recording is announced, and, moreover, there are already people on Habré who approached me with a similar group of ideas so that I could become a participant. It may be worth combining ideas and resources and group).
But the group of proposals is not limited to this, the article is not about this, but about a deeper essence. How else can we realize more viable support for userscripts from various authors?
* user script with plugin support and basic functions
Making myself aware of the inconvenience and "sisyphosis" of work on user scripts, we will try, yet to build a slightly viable design scheme. The difficulty of maintaining vitality is in strong dependence on the parent site and the lack of any support from it. In such conditions, you can fight and maintain the life of the project by distributing work by plug-ins, for example.
The basic functionality is written, which will be needed in all scripts of the site and which is quite easily mastered, with a minimum of tricks, with ease of documentation. This is a plug-in connection method, uniform plug-in settings, a version control agreement, an agreement on script connection points and styles. Further, in the main script (more precisely, in the utilities for it), regardless of the plug-ins, a project collector for specific browsers can be written. It will help build browser extensions automatically on the basis of pre-shared blocks, and a universal script * .user.js will work in the basic functionality, supporting maximum functionality with degradation.
Briefly for those who are in the know. The functionality of extensions is increased in comparison with the base script due to deeper implementation of code sections to other connection points. For example, we can define our images in the base script through the base64-style, and in the extension we can use images. Styles can be connected only at one point - at the end of the page, as well as perform the scripts. In extensions we can run some scripts before and in another environment. We will use this to improve the quality of page loading. Therefore, the source code of both the main script and the plug-ins will have at least 4 sections. Depending on the features of the site, the number of sections may increase, depending on the groups of HTML pages. Nevertheless, the plugin writer will understand the scheme in which he can quickly write an extension for the site and include it in various ways, including building a single script for a browser (in perspective).
Attempt to pass such a path will be made, because the developments on it already have and they help to simulate the interfaces of work with texts. Giving a report that it may not interest anyone, because there are only a few writers and it is always easier to write an independent script than a plugin.
* one more way - semantic scripts
Finally, there is another way to weaken the “Sisypheus” of work - the prepared parent site should be used to the minimum and in fact. That is, to take from it not content + layout, as all scripts do, but only content. Then we get rid of a number of minuses:
*) do not depend on the layout - a huge relief. Only the parser will depend on the layout, there is no way to go, but it is usually quite simple. Then, if the layout changes, everything collapses first (or what has changed), but after fixing the parser, all scripts and plugins that build the view will continue to work, because they will be on their stable layout.
*) practices are used for other content - it is enough to write a parser of another site - and we have the work of all previously made developments under the resulting data structure.
*) it is more complicated than RSS, but RSS can be an alternative, the official content provider in case the main supplier is broken - the site.
*) do not depend on script errors on parent pages. Now when JS fails, userscript is crashing on the page - a very uninteresting dependence on problems with the developers on the server. Some scripts will have to be duplicated and run due to ajax-uploading data on the parent site, but there is a balance of interests - either we get our own system for receiving someone else’s content, or we completely trust the delivery scripts, but they also have the risk of destroying our scripts (in in general, there are techniques for circumventing such problems, the main thing is that they should not be forgotten, even if everything worked stably for months).
What are the cons?
*) All ajax requests should be repeated in their scripts or use the launch of site scripts to exchange data.
*) the developer of the plug-in needs to work not with the page (which is simple - I watched Ctrl-U, and everything is visible), but with the data categories: message, author, date, answers, author, date, rating, voting site functions, sending messages and t .d .. This is more complicated (for the author of the parser too), but overlaps with a huge plus of independence from the layout, provided that there is a parser. Hence, the plugin, written 2-3 years ago, will work if it concerns the presentation, and 80-90% of the plug-ins are like that. But some of the functions of working with data can also be peeled off from the sites so that the operations “send a response” or send an estimate do not depend on the implementation.
*) the parser developer needs to think over the system well so that it remains easy for plugin developers. Overlapped by the advantages of expanding the developer base.
This third idea seems to be more promising, therefore a set of performers and sponsors is also announced on it.
There are other considerations on how to develop the resulting system to eliminate the next negative factors - deleted messages and articles, server crashes, but they are beyond the scope of the scripts issue under discussion.
Summing up
There are 3 different ways to attract developers to improve the quality of data on the site. They vary in terms of labor costs and the monetization scheme - from zero to very full. It makes sense to assemble simple scripts in one plugin in order to have not only a useful tool for geeks, but also a model for flexible usability testing on real data and your own experience. For some ideas that can be applied elsewhere. This way is the least expensive and bringing indirect benefits to developers in the form of accumulating their experience.
But such a system is destructively affected by the arbitrariness of the developers of the site, so it would be nice to include the separation of the data structure from the layout into the architecture of the scripting layer. This kind of project can also be started as a public one, with access to cover not only one site, with better protection of information from loss, with deeper development of skills by developers. It is possible that after a project of this level, the development team will gain experience useful for other similar in terms of commercial projects, it will be a good self-promotion and experience.
Finally, it is also possible to attract venture commercial structures, both at the initial stage and later, to create an ambitious and unusual project that combines the solution of the system problems noted and listed in this text. The first two levels have an elaborated development strategy, albeit with an unclear width of audience coverage. Perhaps some of the readers will be able to think through the marketing side of the issue in an unusual plane - not among geeks, but into a slightly different one, and this will be more promising. The third level requires the development of a distributed server system, which goes far beyond the questions about scripts and the presentation of data in browsers. Therefore, it is better that people connect to this part (one is enough) - server-side architects.
So, all 3 directions are relevant and express an approach that is more focused on the quality of presentation of data in social networks.
Source: https://habr.com/ru/post/133912/
All Articles