|
From: | Richard Terry |
Subject: | [Gnumed-devel] Carlos - Soap2 - design comments |
Date: | Wed, 10 Nov 2004 12:19:30 +1100 |
User-agent: | KMail/1.5.4 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |