(a) Yes, that was kinda the realisation that I was pushing you towards, without wishing to put it to you in a negative way.
(b) Ditto - that was kinda the realisation that I was pushing you towards, without wishing to put it to you in a negative way,
How very condescending of you.
Naturally I knew this at the beginning which is why I never attempted it.
Your project scope would seem to be infeasible for that reason.
the optimal approach to analysis and study of it would have been to break it down group by group - which you are apparently not intending doing.
Of course, I'm not intending to do it - though I didn't want to stop you trying.
If I thought it would be productive I would have done it.
By the time you break it down to groups small enough to analyse, you end up with something that is useful to virtually no-one. That's fine for work you are commissioned to do, where the commissioners provide the boundaries, but not for something that might help an undefined writer casually browsing the net.
though "workflow" probably needs definition - e.g., (say) "a process that does XYZ and is at CMM Level 3 or higher would be feasible for URA."
It's only an internet post, I thought normal English was more appropriate.
The study of the ergonomic needs of users of video screen output and who have vision/perception difficulties (visually impaired or of different visual ability) - and even for different psychological disorders - has identified/built a wealth of knowledge and understanding and user requirements standards relevant to the ergonomic needs of some generic groups. This knowledge is sometimes of crucial importance to the proper design efficiency and effectiveness of mission-critical systems in the fields of computer operations rooms, graphics design workstations, on-board military and aviation systems, military war-rooms and aviation control applications, for example, but since (I think) the days of CDC's Plato software it has also been applied with very good results to programmed learning systems, particularly children's (e.g., such as the one's my now 8 y/o son uses online through his primary school).
The trouble is that system developers who have not been involved in developing such systems have rarely received any training in the use of applied ergonomics in systems design, so most commercial software developers are relatively ignorant (don't have the foggiest idea) and thus oblivious to the wide potential need for such knowledge and feasibility of application of same.
You might like to think that, but you are wrong.
Such 'knowledge' as has been acquired is limited and frequently hits exceptions in the real world.
The trigger for me in starting this review was the irritation from years of reading reviews evaluating software, usually only a few at a time, by comparing feature lists &etc, but never finding these reviews helpful for my own use. There were either assumptions about the type of writing being done, or about the writing workflow, and they never looked at alternative ways of achieving the same end or how they interacted with the parts of the workflow outwith the functions of the software being examined. I've tried to highlight some alternative approaches and writing roles that are usually ignored. But this makes it huge and, in my view, necessarily broadbrush.
I have a lot of experience of a wide range of writing roles, and a lot of knowledge about how different writers tackle their writing tasks; this review seemed a good way of leveraging it.
I suspect that you are not the target market.