Re: [Gnumed-devel] installing and using gnumed

[Richard Terry]

At the risk of starting a flame war, and please when reading this all remember 
I am in no way putting anyone down!

James , I agree wholeheartedly with your comments! I've installed it many 
times on number of distro's and always got stuck at some point.

The roadmap-sequence-plan is a constant thorn, and characteristic of open 
source. The problem I think with this project is that we have never reached a 
common agreement of the path forward, and I hope that doesn't mean that 
gnumed will eventually fail.

For example I spent many months doing the gui-prototype, and documentation 
(its tucked away somewhere, Karsten will know the URL), based on my excellent 
vb client (see www.gnumed.net/rterry/Index.htm (with capital I in Index) in 
case you've missed the philosophy and gui's of the vb client. The program was 
demonstrated live at the sydney gnumed conference and usually blows away 
people because of its breathtaking simplicity and power and speed (runs as 
quick on a pentium 266 as it does on modern machines!). Though I wrote the 
guts in 1995 (script) and the rest in 1997 it is still light years ahead of 
anything I've ever seen.

Its success in practice was a combination of the gui with a functional 
philosophy and automatation. The code was crap as I'm not a programmer.

Despite this, I've not been able to  pursuade the code writers to stick to its 
features, as, I suspect, because they have not used it in clinical practice, 
they have not experienced how it flows, and often think some features are not 
necessary or should be done differently, whereas since I've developed and 
used it, I usually went through the iterations they now are putting in place 
and found they just didn't function optimally, so I advanced the design.

This illustrates, I guess, a lack of structure where one person gets the 
ultimate say on functionality and features, and others code it. What happens 
is that the main coders (Karsten and Ian) change the gui to suit what they 
think would be better - please no flame wars - I'm not a coder at all and 
don't profess to be). Personally I still think wxPython sucks as a gui 
interface compared to QT which was my personal preference, where the vb 
client could have been reproduced in its entireity and hence in all its 
funcitonality.

I think we lack a co-ordinator who can visualise the grand plan and allocate 
coding of each section to whovever and overview and have a final say on the 
result. I'm aware those of you with computer degrees/commercial experience 
think I'm wrong in this as we have had the conversation already.

I've seen many people who obviously wanted to help come and go over the last 
couple of years,  (eg people really interested in HL7, pathology downloading 
etc) and I don't blame them because there was no structure for them to become 
involved, but it is a sad loss of talent.

I would probably be the best beta-alpha tester because I know how the gui is 
meant to function, as I use it every single day and have years and years of 
data and experience using it, yet I've not been involved with this. When I do 
try out the latest interaction and post comments as a result I don't get far 
so I give up. There isn't any mechanism in place to incrementally improve 
after I comment. 

I don't pretend to understand the under the hood design/database etc, but I do 
intimatley know how it should work. What interests me is, that If you look at 
the vb screen dumps and functional descriptions in the *.doc files on the web 
(not in my Index.htm), it will immediately be apparent that every single 
section of the program is the same in its design and functionality. My vb 
coding reflected this, and the same subroutines handled 
loading/displaying/manipulating the data, no matter whether you were in 
vaccinations/scripts/pathology requests etc. I'm not sure why this can't be 
done in python, but perhaps it is an I'm not aware of it.

Anyway, perhaps this post is not of much use, and hope it hasnt upset anyone 
cause no offense is intended. But I find it frustrating and sad to see so 
many willing people come, have a look, offer to contribute, and leave without 
comment.

Regards

Richard
gui-coordinator/ gui designer (in name)

PS, I'm switching off now so will pick up the flak tomorrow.


On Thu, 19 Feb 2004 05:16 pm, James Busser wrote:
> More than one person --- me included --- have found gnumed a challenge
> to install. Though I figure I am an 'advanced novice', I and others
> would like to make installation easier through some combination of
> improved web site materials including FAQs, cvs tidying, and (if
> applicable) the code base.
>
> I looked to gnumed.org at the previous version of what was given as the
> "cvs link" and it occurred to me that in addition to making the
> installation manual available as _part_ of the CVS, it might be helpful
> to point people to the installation pages, so they can be read via
> browser IN PREPARATION FOR cvs checkout.
>
> The following questions are addressed mainly to those who found it
> difficult to install and to use gnumed, and either gave up, or who
> managed it only after some difficulty.
>
> Could people offer their experiences and ideas on the main problem
> areas and possible improvements:
> - Do we need more / better information at gnumed.org. What kind?
> - Do the installation manual pages need to be improved? In what way(s)
> - Is it the "using" part that is hard to figure out?
>
> Are there people on the list who would be able to help with
> code-writing, but who have held back because
> - they had trouble getting a sense of the roadmap, sequence, plan of
> development etc.
> - they were not sure which individual(s) to approach about a particular
> area, or how to collaborate with said people?
>
>
>
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnumed-devel