Talk:Comparison of reference management software/Archives/2017

On Word processor integration

I want to propose two changes in the structure of the comparison of word processor integration:

(1) Currently, Word and Word for Mac are listed as separated entries. I propose to combine these two entries, as there is no program that runs on Windows and macOS, but supports Word on Windows only. Additionally, support for other word processors are not split per operation system making the split for Word not only unneeded, but also inconsistent.

(2) Currently, even word processors a reference manager cannot support because it does not run on the same OS (e.g. citavi is Windows only, meaning it cannot support Apple's Pages that only runs on macOS) the support is listed as no. While this is correct, I think labeling such cases as 'n/a' more clearly communicates that such a support is impossible. Schlappwiki (talk) 14:30, 22 July 2017 (UTC)

On splitting the "General" table into "Proprietary" and "Libre" software

Splitting the "General" table into "Proprietary" and "Libre" software is not as good as keeping it united.

a) An alphabetical list allows readers to easily find the software package if they look for the name. A split table means that they have to look in two tables.

b) There is a color coded column with the heading "Free software" (yes|no) which makes it very easy to see in a combined table if a software is proprietary or not.

c) It does not make sense to include a column "Free software = no" in a table labelled "Proprietary software", and neither does "Free software = yes" in a table labelled "Libre software", but deleting this column in the split table would make it indeed harder to distinguish proprietary from free software. For these reasons, I propose to revert the split table to list all software alphabetically, regardless of whether it is proprietary or "libre".

Pahi (talk) 15:01, 7 June 2017 (UTC)

Disagree, and hold that combining the two categories into a single table is inadvisable for the following reasons:

1) Finding a particular package you already know about, is trivial in either case - each table is alphabetical, and search is otherwise trivial.

Searching using e.g. CTRL+F or auto-search-on-type makes no difference.

Searching two tables visually is a small difference.

Assuming that such an overhead is significant for any significant portion of the users of Wikipedia is insulting the intelligence of the average human user of Wikipedia.

2) Although a color coded column does allow one to visually identify "the current line" as being proprietary or floss software, when one is searching only for floss software, and wanting to compare floss software only, the intermixing of floss with proprietary makes it quite a bit slower to keep double checking each line, against the license, and the name, and any other feature one is interested in.

With a small monitor such as on my 12" laptop, and this large(ish) table, this also requires scrolling left and right, over and over again, which is very slow in comparison to having a table of just floss software (or proprietary when that is all I'm interested in).

3) Superfluous columns should perhaps be removed - in the split table, that means removing "floss=no" for proprietary software, and "floss=yes" for libre software; this is however debatable, as the "free-ness" of a license is indeed a feature (as in, software being proprietary is a positive feature for some), and some folks do appreciate being reminded of this;

I suspect in general that the proprietary vendors may prefer to not have this reminder be so obvious (see below).

3.b) If the issue of a color coded "license" feature column were considered significant as in "red looks negative" or something else emotional like that, then for the proprietary software, the column could be coded green, the heading be "Proprietary", and the text of each entry be "Yes". For some people, proprietary is genuinely seen as an advantage, and there's no scientific reason to trigger them in regards to their personal views.

3.c) Similarly, for the corresponding libre software column, it could just be header "license" and the text as the generally accepted abbreviation for that license (e.g. GPL2, GPL3+, MIT, BSD 3-clause etc).

4) It is posited that there is a significant and growing awareness of the benefits, and differences, of both proprietary as well as libre/ floss software.

Those who have either corporate imperatives to use proprietary software (e.g. due to perceived liability mitigation, perceived quality of customer support etc), and those who have a corporate or organisational imperative to use libre software (e.g. the human rights association I volunteer for), and are only interested in one subset, should not be penalised in their comparison research by the mixing up of these two fundamental categories.

Those who are ambivalent, are not disadvantaged with two tables except in the most minor way - and they're ambivalent anyway.

5) Combining proprietary with libre software into a single category table, can be seen to conflate proprietary, with libre/floss, software. This is not a good thing to do - it can be seen to be a political statement that those actually using the website table for comparisons, should consider both proprietary and libre floss software to be "roughly equivalent", when in fact the consequences to the user, and to the broader community, can be very significant indeed, and so papering over differences becomes a significantly political action.

When my company from some years ago had a corporate imperative to use proprietary software, it was decidedly irritating to continually reminded (both verbally and on the web comparison tables) of all the libre alternatives, when all I wanted was to compare the proprietary alternatives.

6) Libre floss software developers and corporate service providers, have a value proposition that libre floss software has foundations of benefit which ought not be glossed over nor conflated with proprietary software.

Proprietary software providers have a vested interest in conflating the benefits of libre floss software with those of proprietary software - that is, they have a vested interest in papering over the differences between proprietary and libre software, and their vested financial interest in creating such conflations causes a natural pressure upon sites like Wikipedia to aid and abett this conflation/ the papering over of the benefits (or even the differences) of libre software - it is unwise to submit to such pressure.

That is, combining the tables conflates proprietary with libre software, which is a disservice to both camps, whereas separating the tables preferences neither proprietary nor libre software.

7) As tables get larger, splitting them makes more sense regardless of categorization preferences. In other words, the less scrolling around the better, and so fundamental or broad category separation makes sense in this case, given that there are more than 5 packages being compared.

8) Those who have already made a decision that they require EITHER proprietary OR floss software and service providers, are given a disservice by mixing up the two tables into one large table; whilst those who are ambivalent are provided no real disservice by the separation.

So for these reasons, I propose we not combine the two tables into a single large table.

--User:Zenaan

Zenaan, we are not discussing if "combining the two categories into a single table is inadvisable" or not, but rather, if splitting the combined table into two is advisable or not.

ad 1) The article consists of 9 tables, not just one. Splitting just the first one but leaving the others untouched creates confusion.

ad 2) Wanting to check "any other feature one is interested in" against the proprietary/floss paradigm would mean that the other tables had to be split, too.

I agree that scrolling right and left can be tedious, but this is possibly due to Wikipedia tables not being very responsive. I also agree that some columns might be debatable and could be adapted, but deleting columns just to adapt the tables to cater for the limitations of a certain type of device is not advisable.

ad 3) We should consider features and characteristics, not what folks might appreciate or software vendors might prefer or not.

ad 4) As stated above, the whole article consists of 9 tables, all of them list the discussed software packages alphabetically. Do you propose to split all of them to make comparison research easier for those people that search along the lines of proprietary or floss?

ad 5) and 6) Let's keept political action out of the articles in Wikipedia, let's stick to being consistent. Splitting just one out of 9 tables along the lines proprietary/floss where these characteristics are discussed makes the whole article inconsistent, and this should be avoided.

ad 7) Your argument does not hold. If the items to be compared are many, the table will be as long as it will have to be. <irony>Or should we split the table of the planets of the solar system into separate groups, given that there are more than 5 planets being compared?</irony>

ad 8) Proprietary vs. floss is one possible characteristics and just one among many others people might be looking for. One could only be interested in software available for Mac, or software that has been updated in the last 12 months, or that is compatible with LaTeX. There are columns for these differences.

Summing up, since consistency would require all tables to be split, and since this would make the article less clear, I propose to revert the splitting of the first table into proprietary vs. floss software to make it consistent with the rest of the article.

--Pahi (talk) 17:32, 12 June 2017 (UTC)

Also, I propose RV of table split by User:Zenaan because of WP:NPOV concerns. User:Zenaan argues in 5) and 6) that NOT splitting the table into proprietary / floss software equals conflation of differences equals political action. This is a biased argument. In combination with the inconsistency introduced by splitting just one of 9 tables I propose RV the changes.

--Pahi (talk) 08:46, 13 June 2017 (UTC)

Fully agree.

Schlappwiki (talk) 10:43, 22 July 2017 (UTC)

I agree aswell, and have reverted the table structure back to the original long-standing layout - until an eventual consensus is formed for such a significant change. An inconsistent table structure would be a serious layout flaw. Also, the various philosophies and concerns behind free or non-free licensing should be irrelevant for this discussion - our only goal should be an uninvolved encyclopedic representation of facts. The licensing information is already clearly indicated with an appropriate color-coded sort column - this handling is not confusing or conflating. It simply lists all entries within the article's defined scope in one non-judgemental overview. GermanJoe (talk) 23:01, 11 August 2017 (UTC)