Req: more summaries

[glocalglocal]

In addition to the other summaries, a Case and possibly an attributes summary would complete the set.

IMV allowing users to select more than one file, case, code, code category, attribute to produce a summary report would be useful.

[AndrzejWawa]

But the question is, if it is needed now for merit reasons? If not, I think that the work on easier installation for Windows is more important - while for many users it will be dilemma have or not have software at all ), as well as critical for diffusing the software wider. It is because installing Python and installing packages via cmd requires breaking the significant mental barrier, also for me, but I was highly motivated to support open source and community-based solutions : )

Moreover, there are such issues as advancing graphs for example. In the Maxqda, there is possibility to change category of the code from the graph level and export the whole graph. I think that visual tools really make significant change for interpretation and analysis. So, if sth is not needed for user, I think it is better avoid details and focus on bigger things.

But of course, if you see these summaries helpful for your work, my comment is not applicable to this : )

[glocalglocal]

I haven't said anything about how these should be prioritised. Prioritisation is not up to me because I am not the one spending days and months developing QC. And I don't see why issues must be closed in a rush because there are too many open issues. This and other requests/bug reports can stay open for as long as it is necessary, possibly forever.

On the specific point, certain issues can be trivial to address compared to others. The 'low hanging fruit' principle alone may be a reason to prioritise certain less high-power issues, particularly when doing so increases users' confidence in the application. I am certain people are put off using many apps because of sloppy and underwhelming UI, including trivial things like typos, and I think this impacts on diffusion very dramatically. I suppose the idea is that if a developer (not Colin!) missed this and that, the application may lose or lock in my dataset. How many times have you read reviews saying 'this looks like something out of the 90s or Windows 95'? First impressions matter.

But of course, if you see these summaries helpful for your work, my comment is not applicable to this : )

Most of the 100s of feature requests I put forward have nothing to do with my work. :)

[ccbogel]

I do prefer to close issues sooner rather than leaving them open for a long time. I prefer to have fewer issues to deal with, as this is meant to be a somewhat enjoyable hobby. I close what I think are lesser issues quickly. Actual bugs (errors in logic or when error messages are thrown) are a priority.

Attribute summary; the attributes can be exported for cases or files. no need to summarise this. case summary - what exactly is beneficial, i.e. why. when a case can be viewed n the cases tab.

[ilippert]

I do prefer to close issues sooner rather than leaving them open for a long time. I prefer to have fewer issues to deal with, as this is meant to be a somewhat enjoyable hobby. I close what I think are lesser issues quickly. Actual bugs (errors in logic or when error messages are thrown) are a priority.

I allow myself to comment. The policy of the development is of high interest. Maybe a note on the opensource development strategy (in more detail than a grand philosophy) might be a next step. This would be a different ticket/conversation, I guess.

[ccbogel]

I allow myself to comment. The policy of the development is of high interest. Maybe a note on the opensource development strategy (in more detail than a grand philosophy) might be a next step. This would be a different ticket/conversation, I guess.

Thank you. What would you suggest for this to occur?

[ilippert]

I allow myself to comment. The policy of the development is of high interest. Maybe a note on the opensource development strategy (in more detail than a grand philosophy) might be a next step. This would be a different ticket/conversation, I guess.

Thank you. What would you suggest for this to occur?

Well, given we do not know each other well, I have no idea how interested you are in reducing complexity or inviting open discussion. In one extreme, you might issue a statement on your philosophy (which might start with points on how you imagine ideal bug/issue reports, how you read and engage with these); in another extreme, you might open a discussion place (maybe simply a new ticket), in which points, interests, commitments might be shared and you would take input or some form of distributed o-authoring of open development policy points emerge.

[AndrzejWawa]

I reflected on this and I think that table with codings frequencies for all files could be meaningful.

1) Firstly, provide, e.g. in report "code frequencies" additional columns for each file.

2) Secondly, provide similar report but named e.g. "files comparisons", where in rows wll be files and with different columns: 1) total number of codings, 2) percentage of codings character related to the length of the document (total number of characters in document), 3) number of applied codes, 4) names of applied codes.

Some of this information are already placed in "files summary", so, the comparative table with additional information (number of applied codes, total number of codings, percentage of cover in characters of all codings) could be added to this report, with the option to export and conduct statistical analysis.

This would be a tool for checking how consistent we are in coding different files.

[ccbogel]

@AndrzejWawa OK, so the Files Summary Report does show: 3., 5. and 6. the total number of codings and names are there already.

I can add percentages to the Files Summary report - my TODO list.