Summary of problems
When Wikipedia was created, its minimalistic interface made it possible to spread it over the whole world, as it did not demand too much from the user’s computer and from the user himself or herself. One can start using Wikipedia on a simplest 386 processor machine, being a user with a minimum experience.
However, at a certain stage of development of Wikipedia, which in my opinion was reached 3 or 4 years ago, this simplicity began turning into difficulty. As more functions were added to Wikipedia, it resulted in the impossibility to review them all at a glance, and what’s more important, it resulted in the overloading of servers, and thus in significant growth of expenses, which are currently used for support and maintenance of Wikipedia, instead of developing its functionality.
Moreover, a lot of functions currently executed by servers could be easily executed on the client’s side, which would also contribute to Wikipedia’s functionality and increase possibilities of fine tuning and better adaptability to users’ need without incurring extra costs.
To summarize the main problems that should be overcome in new generations of Wikipedia:
1. Scattered interface.
2. Reduplication (sometimes retriplication, requadruplication etc.) of many functions.
3. Server overloading.
Spheres where improvement is possible
1. Avoiding the scattered interface
2. Articles, categories, Commons and Metawiki.
3. Discussions and forums.
4. Cooperation between users (finding each other, portals and projects)
5. From thematic cooperation (portals and projects) to tagged cooperation and presentations (and still avoiding the risk of becoming a social network)
6. Translation needs a special interface
7. Further issues of international cooperation
Avoiding the scattered interface
Just from the start page, the Wiki interface looks scattered. You can find some functions at the top, some other in the sidebar menu, and some at the bottom. Why? It would be better to see them all at a glance.
The same problem exists with Wiki-editing: although the editor’s interface has been significantly improved over the last years, it is still scattered:
The two possible solutions are:
1. To create a multi-level interface at the top of the page (top level – Wikipedia general, second level – article-related etc.) similar to that of MS Office 2007-2010.
2. To create a software, or, more precisely, a browser plugin allowing to execute at least part of Wikipedia’s most frequent functions at the client’s side. When a user opens Wikipedia, it will detect if he/she has a plugin. If not, Wikipedia will execute everything on the server side.
3. The above mentioned interface should have fixed position at the top, bottom, side of the page or as a pop-up window, depending on the user’s preference. The rest of the page should be scrollable. It will release a lot of useful space on the page.
Articles, categories, Commons and Metawiki
In my opinion, articles and categories are just different levels of information structuring. It is like describing physical or chemical properties of substances: just different levels of speaking about the same thing.
In some cases the difference between an article and a category is vanishing. For example, a disambiguation page is at the same time a category, even though it is not considered as such. A disambiguation page about people under surname Smith, at the same time, represents a category called “Smith (surname)”.
My proposal is to automatically assign each article a category under the same name, but to interwikify articles and categories separately. Articles are more closely related to the living human language, while categories rather deal with structurization of information, and, as part of it, with ambiguities that exist between several languages.
An example: a German surname Piel and an English surname Peel will be represented in Russian by the same article, as Russian spelling is phonetic. Very often ambiguities or quasi-homonyms may arise just because one language does not distinguish certain sounds, which will sometimes result in politically provocative similarities: for example, a German surname Hitler and a Jewish surname Gietler will be spelt in the same way, as Russian does not distinguish G from H, and IE from I or EE.
In the same way, it would be expedient to create several subspaces for each article: a Wikipedia subspace, a categorization subspace (which I consider almost identical, if not totally identical, to the role of Metawiki), a Wikidictionary space, a Wikicommons space etc. Interwikis for each of these spaces should still exist separately.
Links between categories: instead of superior or inferior categories, propose a multiple choice: category A is included in category B, includes category B or is somehow related to category B (the latter is at the moment represented by “See also” lists at the bottom of many articles).
One more word about interwikis. Currently Wikipedia does not allow creating interwikis linking to articles not yet created. In my opinion, Wikipedia should enable users create “red interwikis”. It will solve several tasks:
- When reading the article, the user will judge by red interwikis that, although articles in these languages have not been created, users of Wikipedias in respective languages are interested in reading such articles, as they at least know how to translate the name of the article in their language.
- When an article is created, a bot can start searching other Wikipedias for red interwikis under the same name. At the moment, a lot of articles lack links between versions in different languages, just because of this prohibition of red interwikis: users are simply not aware that versions in other languages do exist.
Discussions and forums
One of Wikipedia’s advantages was the easiness of cooperation in process of creating articles. However, while this is easy, some other aspects of cooperation between users in Wikipedia seem to be difficult or awkward (or both), which can potentially result in Wikipedia’s being superseded by competing projects offering more advanced tools of cooperation between users and groups.
At the moment, discussions are attached to certain pages, such as articles, categories, images, user pages etc. Very often discussion between two users creates quite a weird situation when one of them: it is either attached to the user page of one of them (and so is difficult for the other to track back, say, in a year), or is scattered between two user pages, so that several months, sometimes even days later you have to switch between two user discussion pages to understand the topic of the discussion.
What can be done:
1. Each reply or message should be treated as a separate tagged article or file (whichever is better applicable).
2. These articles/files should be automatically assigned such tags as user names of the sender and the receiver, as well as the article in whose space it was created. However, users are free to add more tags.
3. Discussion chains can be created post factum by filtering messages by the above tags, dates, spaces (Wikipedia, Wikimedia, administrative space etc.)
4. The above will enable searching messages by upper level categories, as well as by multiple languages, as tags will have versions in different languages.
5. What I described above will be a step forward towards an absolutely new form of global communication, which should supersede existing forums and discussion groups.
While communication between individuals in Wikipedia is still relatively easy, in spite of all the problems described, group cooperation is confined to projects, portals and forums, whose interface does not seem to be cooperation-friendly. Wikipedia lacks an efficient mechanism of creating workgroups. Although a list of interested participants on a project page, or within a category, can be formally considered as a group, it in fact lacks what real groups have: real-time interaction and cooperation. On the other hand, vandals and biased users can create groups outside Wikipedia and cooperate in group attacks, which found reflection in multiple wars within Wikipedia, e.g. on topics related to LGBT, India vs Pakistan, Israel vs Palestine etc. To avoid vulnerability, Wikipedia should enable creation of real-time short-living tagged groups. I am going to discuss it further in this report’s sections about cooperation, user interface and translation.
From thematic cooperation (portals and projects) to tagged cooperation and presentations (and still avoiding the risk of becoming a social network)
It was a surprise for me to discover that certain language versions of Wikipedias do not have user boxes by interests: this is the case, for example, for the German Wikipedia.
Yet, there is a need of cooperation between Wikipedians by interests. Currently, there are several ways, which in my opinion not only overlap, but are all inefficient and insufficient for group cooperation:
1. User boxes by interest.
2. Participation in projects/portals.
3. Individual topic-related discussions on article pages and category pages.
One more thing: one of rules of Wikipedia says that Wikipedia is not a social network. Well, if it is not, so how can users cooperate in working on certain topics and articles? One of the important prerequisites for cooperation is the possibility to quickly find other interested people and quickly organize cooperation. How is it done at the moment? There are several forms, such as thematic weeks or simply sending messages to interested users (and the latter resembles spamming, doesn’t it?)
What I want to propose:
1. Instead of creating multiple (useless) user boxes, create space within the User Global account allowing him to tag his interests and knowledge of languages. It is quite simple, as the user can just give links to existing articles.
2. When knowledge of languages is reflected in the global account, it will enable cooperation in translation of articles in a much more efficient way than current embassies do.
3. Existing portals should be replaced with Wiki-presentations.
To summarize the above: Tagged cooperation is a good alternative of either converting Wikipedia into a social network or scattering information by creating multiple user boxes.
Translation needs a special interface
Wiki editing should be extended with a special panel for Wiki translation. When translation of an article is created, a lot of actions can be performed automatically, such as:
- Saving it for several days in a special temporary space
- Automatic translation of terms in square brackets (as long as such articles exist in the target language Wikipedia), which will be a good protection against creating red links just due to ignorance of terminology. Even the most experienced user can be not aware how this or that term is called in his native language (or, if the target language is not his native, it makes the problem even worse).
When an article is created by a person in his/her non-native language, the article should be automatically tagged as “verification by native speaker required”. I suppose that in the future some sly people will pretend to be native speakers, and administrators should be enabled to mark those users as “possibly non-native speakers”.
As Wikipedia efficiently cooperates with Google, may I expect that at least partial integration of Google Translation tool into Wikipedia is possible? Let me be clear, I do not want to create machine-translated articles (being a professional translator and interpreter, I hate machine translated texts), but rather to create a kind of a cheap translation memory tool.
International cooperation: further issues
(to be expanded)
Summary of problems
When Wikipedia was created, its minimalistic interface made it possible to spread it over the whole world, as it did not demand too much from the user’s computer and from the user himself or herself. One can start using Wikipedia on a simplest 386 processor machine, being a user with a minimum experience.
However, at a certain stage of development of Wikipedia, which in my opinion was reached 3 or 4 years ago, this simplicity began turning into difficulty. As more functions were added to Wikipedia, it resulted in the impossibility to review them all at a glance, and what’s more important, it resulted in the overloading of servers, and thus in significant growth of expenses, which are currently used for support and maintenance of Wikipedia, instead of developing its functionality.
Moreover, a lot of functions currently executed by servers could be easily executed on the client’s side, which would also contribute to Wikipedia’s functionality and increase possibilities of fine tuning and better adaptability to users’ need without incurring extra costs.
To summarize the main problems that should be overcome in new generations of Wikipedia:
1. Scattered interface.
2. Reduplication (sometimes retriplication, requadruplication etc.) of many functions.
3. Server overloading.
Spheres where improvement is possible
1. Avoiding the scattered interface
2. Articles, categories, Commons and Metawiki.
3. Discussions and forums.
4. Cooperation between users (finding each other, portals and projects)
5. From thematic cooperation (portals and projects) to tagged cooperation and presentations (and still avoiding the risk of becoming a social network)
6. Translation needs a special interface
7. Further issues of international cooperation
Avoiding the scattered interface
Just from the start page, the Wiki interface looks scattered. You can find some functions at the top, some other in the sidebar menu, and some at the bottom. Why? It would be better to see them all at a glance.
The same problem exists with Wiki-editing: although the editor’s interface has been significantly improved over the last years, it is still scattered:
The two possible solutions are:
1. To create a multi-level interface at the top of the page (top level – Wikipedia general, second level – article-related etc.) similar to that of MS Office 2007-2010.
2. To create a software, or, more precisely, a browser plugin allowing to execute at least part of Wikipedia’s most frequent functions at the client’s side. When a user opens Wikipedia, it will detect if he/she has a plugin. If not, Wikipedia will execute everything on the server side.
3. The above mentioned interface should have fixed position at the top, bottom, side of the page or as a pop-up window, depending on the user’s preference. The rest of the page should be scrollable. It will release a lot of useful space on the page.
Articles, categories, Commons and Metawiki
In my opinion, articles and categories are just different levels of information structuring. It is like describing physical or chemical properties of substances: just different levels of speaking about the same thing.
In some cases the difference between an article and a category is vanishing. For example, a disambiguation page is at the same time a category, even though it is not considered as such. A disambiguation page about people under surname Smith, at the same time, represents a category called “Smith (surname)”.
My proposal is to automatically assign each article a category under the same name, but to interwikify articles and categories separately. Articles are more closely related to the living human language, while categories rather deal with structurization of information, and, as part of it, with ambiguities that exist between several languages.
An example: a German surname Piel and an English surname Peel will be represented in Russian by the same article, as Russian spelling is phonetic. Very often ambiguities or quasi-homonyms may arise just because one language does not distinguish certain sounds, which will sometimes result in politically provocative similarities: for example, a German surname Hitler and a Jewish surname Gietler will be spelt in the same way, as Russian does not distinguish G from H, and IE from I or EE.
In the same way, it would be expedient to create several subspaces for each article: a Wikipedia subspace, a categorization subspace (which I consider almost identical, if not totally identical, to the role of Metawiki), a Wikidictionary space, a Wikicommons space etc. Interwikis for each of these spaces should still exist separately.
Links between categories: instead of superior or inferior categories, propose a multiple choice: category A is included in category B, includes category B or is somehow related to category B (the latter is at the moment represented by “See also” lists at the bottom of many articles).
One more word about interwikis. Currently Wikipedia does not allow creating interwikis linking to articles not yet created. In my opinion, Wikipedia should enable users create “red interwikis”. It will solve several tasks:
- When reading the article, the user will judge by red interwikis that, although articles in these languages have not been created, users of Wikipedias in respective languages are interested in reading such articles, as they at least know how to translate the name of the article in their language.
- When an article is created, a bot can start searching other Wikipedias for red interwikis under the same name. At the moment, a lot of articles lack links between versions in different languages, just because of this prohibition of red interwikis: users are simply not aware that versions in other languages do exist.
Discussions and forums
One of Wikipedia’s advantages was the easiness of cooperation in process of creating articles. However, while this is easy, some other aspects of cooperation between users in Wikipedia seem to be difficult or awkward (or both), which can potentially result in Wikipedia’s being superseded by competing projects offering more advanced tools of cooperation between users and groups.
At the moment, discussions are attached to certain pages, such as articles, categories, images, user pages etc. Very often discussion between two users creates quite a weird situation when one of them: it is either attached to the user page of one of them (and so is difficult for the other to track back, say, in a year), or is scattered between two user pages, so that several months, sometimes even days later you have to switch between two user discussion pages to understand the topic of the discussion.
What can be done:
1. Each reply or message should be treated as a separate tagged article or file (whichever is better applicable).
2. These articles/files should be automatically assigned such tags as user names of the sender and the receiver, as well as the article in whose space it was created. However, users are free to add more tags.
3. Discussion chains can be created post factum by filtering messages by the above tags, dates, spaces (Wikipedia, Wikimedia, administrative space etc.)
4. The above will enable searching messages by upper level categories, as well as by multiple languages, as tags will have versions in different languages.
5. What I described above will be a step forward towards an absolutely new form of global communication, which should supersede existing forums and discussion groups.
While communication between individuals in Wikipedia is still relatively easy, in spite of all the problems described, group cooperation is confined to projects, portals and forums, whose interface does not seem to be cooperation-friendly. Wikipedia lacks an efficient mechanism of creating workgroups. Although a list of interested participants on a project page, or within a category, can be formally considered as a group, it in fact lacks what real groups have: real-time interaction and cooperation. On the other hand, vandals and biased users can create groups outside Wikipedia and cooperate in group attacks, which found reflection in multiple wars within Wikipedia, e.g. on topics related to LGBT, India vs Pakistan, Israel vs Palestine etc. To avoid vulnerability, Wikipedia should enable creation of real-time short-living tagged groups. I am going to discuss it further in this report’s sections about cooperation, user interface and translation.
From thematic cooperation (portals and projects) to tagged cooperation and presentations (and still avoiding the risk of becoming a social network)
It was a surprise for me to discover that certain language versions of Wikipedias do not have user boxes by interests: this is the case, for example, for the German Wikipedia.
Yet, there is a need of cooperation between Wikipedians by interests. Currently, there are several ways, which in my opinion not only overlap, but are all inefficient and insufficient for group cooperation:
1. User boxes by interest.
2. Participation in projects/portals.
3. Individual topic-related discussions on article pages and category pages.
One more thing: one of rules of Wikipedia says that Wikipedia is not a social network. Well, if it is not, so how can users cooperate in working on certain topics and articles? One of the important prerequisites for cooperation is the possibility to quickly find other interested people and quickly organize cooperation. How is it done at the moment? There are several forms, such as thematic weeks or simply sending messages to interested users (and the latter resembles spamming, doesn’t it?)
What I want to propose:
1. Instead of creating multiple (useless) user boxes, create space within the User Global account allowing him to tag his interests and knowledge of languages. It is quite simple, as the user can just give links to existing articles.
2. When knowledge of languages is reflected in the global account, it will enable cooperation in translation of articles in a much more efficient way than current embassies do.
3. Existing portals should be replaced with Wiki-presentations.
To summarize the above: Tagged cooperation is a good alternative of either converting Wikipedia into a social network or scattering information by creating multiple user boxes.
Translation needs a special interface
Wiki editing should be extended with a special panel for Wiki translation. When translation of an article is created, a lot of actions can be performed automatically, such as:
- Saving it for several days in a special temporary space
- Automatic translation of terms in square brackets (as long as such articles exist in the target language Wikipedia), which will be a good protection against creating red links just due to ignorance of terminology. Even the most experienced user can be not aware how this or that term is called in his native language (or, if the target language is not his native, it makes the problem even worse).
When an article is created by a person in his/her non-native language, the article should be automatically tagged as “verification by native speaker required”. I suppose that in the future some sly people will pretend to be native speakers, and administrators should be enabled to mark those users as “possibly non-native speakers”.
As Wikipedia efficiently cooperates with Google, may I expect that at least partial integration of Google Translation tool into Wikipedia is possible? Let me be clear, I do not want to create machine-translated articles (being a professional translator and interpreter, I hate machine translated texts), but rather to create a kind of a cheap translation memory tool.
International cooperation: further issues
(to be expanded)