[Gnumed-devel] Carlos - Soap2 - design comments

[Richard Terry]

This who debate typifies what goes on within gnuMed and why very little 
forward progress is made in the gui design. The current incarnation of gui 
design sucks big time.

It is a source of never ending frustration and saddness for me that we have 
never reached a point of respecting each others abilities and learning to 
work as a team together. Despite constant statements that anyone can have 
whatever plugins they desire - the fact is that will never happen.

Overall functionality and utility will be dictated by the ergonomics of the 
design. I note the interim jpg below and put forward these comments.

Again, as doctors we don't (and not just me - this is observation on the 
ground of tens of dozens of GP's using computers) by and large 'go back' to a 
tree like list of encounters very often. Having this take up valuable 
workspace next to your input area's is a waste of screen real-estate - and 
deprives you of much peripheral information.

Carlos - I'm not sure if you have read any of the philosophy behind my stuff - 
if not - look at www.gnumed.net/rterry/Index.htm

Also - I knocked up a quick wxPython2.5.1 design a couple of months ago - much 
more flexible than 2.4 -  (havn't touched the keyboard really since  despite 
keeping an eye on the list) which illustrates a much more rational approach 
to overall design  - as you can see from the attatched png's I've dumped 
today, apart from the SOAP editor, I've just used some stock wxPython Demo 
examples to fill in the spaces, so you will have to use your medical 
imagination to fill medical data into this. 

I keep coming back to the fact that we must have an overall design in mind as 
we do this stuff.

Imagine how SOAP2 could be progressing if a team was working on it - ie say 
Ian, Carlos, whoever. This data-entry paradigm pisses all over anything in 
existance because it is so powerful, quick and easy.

Why in the hell can't we for once and for all give certain people 
responsibility for segments of gnumed - allow them a final say - and then 
just get on with it. Those who watch this list in the background - eg in the 
AU university scene/governernment/medical defence organisations, have 
expressed privately to me at times their frustration at watching this process 
we have - and us getting nowhere fast. There are organisations in AU who 
would like to contribute time/money to our effort, if only we could show some 
progress and unity. The way things are moving here it could be in a couple of 
years time that irregardless of the state of gnuMed it will be unusable for 
us in australia because of local legislation regarding requirements for 
medical records. If the project actually produced something, it could become 
part of that process, rather than being trashed by it.

Seems like this is not going to happen anytime soon.

Regards

Richard

On Wed, 10 Nov 2004 05:59 am, Carlos Moro wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi all,
>
> Ian Haywood wrote:
> |> While in fact I do like the approach a lot. Carlos has already
> |> started to use it in writing a SOAP entry plugin for HorstSpace.
> |
> | Excellent, but please don't pointlessly duplicate this work. Speak
> | up if you want something changed.
>
> The idea is  use SOAP2.py widget as the key input element of the SOAP
> input plugin. I comment the initial approach/proposal, as commented
> with Karsten, including with his feedback  ;) :
>
> ~    -It would be mainly a split  window:
>
> ~    A) On the right: gmEMRBrowser: allows problem selection. Only a
> new SOAP input control can be created when selecting for input a new
> problem. For future:  tree will allow more sophisticate SOAP
> navigation/edition/selection, according patient's EMR.
> ~    B) On the left:
>
> ~ 1. MultiSash seems the adecuate base widget for our SOAP entries.
> It's completely implemented in python (wxPython/lib/multisash.py),
> looks really nice and is very effective splitting views.
>
> 2 . When a new split view is created a new instance of the target
> class is created. Perfect for us: create an instance of cSOAPControl
> and pass to it the currently selected health issue in the tree (we can
> improve selection in future).
>
> 3. There would be a unique pair of clear/save buttons in the plugin.
> The user must
> be really sure wich problem currently selected SOAP belongs to.
> Multisash provides a
> yellow border in the active split, so doesn't seem too difficult. The
> plugin will query
> the controls for the input and dump to the backend (interacting with
> gmClinicalRecord)
>
> 4. To improve usubility, only horizontal multiusash splitting will be
> allowed,
> disabling vertical. In that way, SOAP input controls will
> be displayed like in one column from top to bottom.
>
> 5. In order to allow another split SOAP creation (initially by
> dragging the sash creator, we can later improve with the + button), we
> could check that a problem in the tree is selected, and it must be
> different of the problems of the other cSOAP input views. Also, we can
> limit the total views to 3 or 4...
>
> 6. Regarding implementation, we could at first take multisash.py
> and customize to adapt to our needs. In future we can always decide to
> extend or something to make our approach more generic...
>
> I attach a shot of a very first try, yet using old SOAPCtrl...(just
> for the general idea...)
> We are synchronized and in contact to advance both SOAP2.py and
> gmSOAPInputPlugin... :)
>
>
> Best regards,
> Carlos
>
> |> One thing I am wondering about is: How are we intended to deal
> |> with data having been typed into a functional popup ? Eg. imagine
> |> the user incantates the magic string that pops up the
> |> vaccinations control. After completing that control the user
> |> clicks OK. What happens next ? One thing is that we do want to
> |> drop a quick note about the vaccination into the SOAP widget.
> |> OTOH, we would also want to store the vaccination details into
> |> the database. Do we do this immediately when OKing the
> |> vaccinations popup ? If so how do we handle the case when the
> |> user CANCELs the master SOAP control ? If not where do we keep
> |> that information around and until when ?
> |
> | Three options: - parseable string, when we commit the SOAP, we
> | parse the text and do the database commits. We can mark the text
> | not-editable to prevent the user messing it up. IMHO, with care, we
> | can make strings parseable and readable. - use the string as a key
> | to a cache dictionary of "hidden" objects. This exists in vestigal
> | form already. - wxStyledTextControl markers, which can be
> | invisible, again as keys to a cache dictionary.
> |
> |> # - this should not be a physical replacement for the edit #
> |> area, just a logical one where people want to use it ! #   IOW we
> |> will keep gmEditArea around as it IS a good design !
> |
> | I hope SOAP2 to be a complete superset of cEditArea functionality,
> | I don't want it to co-exist as IM[and Richard's]HO, consistency of
> | GUI appearance and behaviour is important.
> |
> |
> | Ian
> |
> |
> | ----------------------------------------------------------------------
> |
> |
> | _______________________________________________ Gnumed-devel
> | mailing list address@hidden
> | http://lists.gnu.org/mailman/listinfo/gnumed-devel
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFBkROV5BCD+/pQ4WIRAu82AJ93UtkDD+taJpEjXGS0KIR2WHQUBgCgjZJd
> D5Q9+R6e0+goYVjiM6XMO5w=
> =f0XJ
> -----END PGP SIGNATURE-----

251gnumed_SOAP.png
Description: PNG image

253gnumed_demographics.png
Description: PNG image

252gnumed_Inbox.png
Description: PNG image

253gnumed_Reference.png
Description: PNG image

253gnumed_drugs.png
Description: PNG image