Re: GUI (was Re: [Gnumed-devel] Results tracking)

[catmat]

Sebastian Hilbert wrote:

> On Sunday 06 March 2005 02:38, J Busser wrote:
>  
>
> > At 10:13 AM +1100 3/6/05, E Dodd wrote:
> >    
> >
> > > > Oh, I was thinking of adding more structure on the *backend*.
> > >      
> > >
> > > > Karsten
> > > >        
> > > Last week Richard and I had a phone conversation about his frustration
> > > with the "adding more structure on the *backend*" and not getting closer
> > > to having this working with the GUI.
> > >      
> > I think Karsten is very good about focusing on 0.1 and cannot imagine
> > he plans to spend much (if any time) on the backend on post-0.1
> > issues until 0.1 is done.
> >
> > I totally feel for what Richard is wanting to do (I wish I had the
> > skills to help) and I think his biggest frustration is working so
> > much alone while Karsten and Ian *seem* to work on backend and
> > middleware. While I think Ian also works on some GUI stuff it may be
> > unrelated to what Richard is doing.
> >
> > Maybe there is frustration because Richard would love for what he is
> > doing to be *part* of a 0.1 version whereas others think they can get
> > by for 0.1 with weaker but more-straightforward prototypes?
> >
> > Maybe if anyone is in any position to contact & ideally collaborate a
> > bit (or a bit more) with Richard privately, about how to connect his
> > evolving GUI up with the ***0.1 middleware***,  that could help? I
> > feel it is important, if not in the next few weeks, then at minimum a
> > commitment to try to help at least a *little* with this over
> > April-June. Any possibility of this?
> >
> >    
> This sums it up pretty good. 
>
> Working quietly I am spending many hours a day to make 0.1 happen. Am I 
> codding ? Unfortunately not. There is so much else to do. Getting wiki 
> content straight (Jim is doing an outstanding job here). Talk to companies 
> (no results yet) , answer questions of potential users and much more. This is 
> the work of a release guy.
>
> Having praised my work enough I basically want to say that I understand 
> Richard's frustration but can do very little about it. We simply lack the 
> manpower. As hard as it seems we simply cannot (IMHO) have Richard's GUI in 
> 0.1. After the release this is a entirely different story. The GUI is nice. 
> Lets say it *looks* nice. That doesn't help at all. I know Richard does an 
> excellent GUI job but This code needs to be connected. Well the good code, 
> not the crap one.
>
> So here is what I can add to the discussion.
> Karsten is the backend guy. Forget about him for a second.
> Now who is going to connect the GUI to the middleware ?
having once tried to work on connecting Richard's gui, it is not
all that easy to do.  More than a year ago , it seemed that
there were concepts Richard had, which didn't fit in with Karsten's
schema, but later Karsten made concessions to allow for some of
Richard's ideas, but no one progressed to connect the gui
with the middleware.  When someone tries to look at Richard's widgets
and then connect them,  they can't do it exactly how Richard conceives
it , because the static picture doesn't document the workflow intended
to enough detail that Richard can say,  yes you've followed each
point of the workflow correctly . Sometimes there's a feature that
Richard thinks is necessary, and may be difficult to implement
and seem icing on the cake to a developer, and therefore frustrating  to do.
Perhaps what's needed is more detailed functional requirement
specification *and* goal specification, so along with a certain
look, we get how it should be done ( a walkthrough, which might
have the usual CrUDF branches , but with extra detail about
how the gui helps with Cr or U and *why* making it help that way
is good, and maybe why it may not be so good. Then someone with
the role of official pragmatist nominates whether it gets done,
and like the ozzie senate, "all hands say aye,  all hands say nae,
the ayes have it", and then it's decided whether Richard's
slightly to greately difficult gui feature gets done in the first cycle 
or not).

Another things is what kind of focus should the gui have ?  e.g.
medication tracking might consist of a way of capturing changes to 
medications
during an encounter, and also recording changes outside an encounter and
by who , and reported by whom, and whether it's reliable information,
so that's why there's a narrative on all clin_items including medications.
the emr at work, tracking of meds is just a list of current recorded 
medications,
and we do simple edit, delete, create on the list, and all the 
medication actions
are recorded as auto-generated text in the narrative, ( probably not as
action objects , but I'm not sure) . Is this all right for Karsten or 
Jim  ?
My guess is, probably not good enough.  I hardly ever figure out the 
changes in
medications by looking at the auto-generated text, I usually ask the 
patient what's happened.
So why record it?  If our emr asked about each change to enter a reason, 
I might
be able to figure it out, but when there's a waiting room full of 
patients, sometimes
you just want to hit enter until the script gets printed.

On the other hand, if what you need
is basically a script printer, and don't want to sprain a frontal lobe 
implementing
medications, then it may be good enough. 

Then there are the problems of locality :
might as well write a separate prescription module for each country 
gnumed is
used .


> Is the following possible ?
> Richard. Please talk to Karsten which feature will be in 0.1.
> Please write *good* code for one feature and tell Ian once you are ready.
>  
*good* can be a matter of taste and different goals.  If Richard's gui 
is just a
configurable "look and feel" for the gnumed gui, and works well with itself
and uses the middleware, (and therefore obeys the schema constraints),
it doesn't really need to be *good* stylistically,
as long as it can be maintained to not break when the middleware evolves.