gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Time for a major re-think in 2005 - opinions please.


From: Richard Terry
Subject: Re: [Gnumed-devel] Time for a major re-think in 2005 - opinions please.
Date: Thu, 6 Jan 2005 15:00:51 +1100
User-agent: KMail/1.5.4

I;'m not advocating 'hacking a gui' and filling it with functionality. You've 
commented many times just how different our brains think.

Medical director BTW ended up with a crap gui because if was a DOS based 
program which was migrated to a gui-environment which attempted to mimic the 
DOS stuff, and then, yes, had stuff bolted onto it in an ad-hoc way. The 
majority of GP's don't necessarily like Medical Director Gui. Many many I've 
spoke to desribe it as a 'dog', most know no different. Its not all bad 
anyway and does have good features as well as bad - we should learn from 
both.

I'm not advocating ad-hoc gui design. I'm advocating a gui where functionality 
is built in. I don't agree one can use wxGlade to acheive this as it does not 
give one fine enough control over the visual design.

I'm not advocating a crap back-end. I respect the work of the back-end coders 
who have, according to those who have the ability to make the judgement (not 
me as I don't have that skill) been doing an excellent job, so that we don't 
end up with an unreliable back end.

Regards

PS:Welcome back to the list!!!! At least we know you are monitoring it.

Richard

On Thu, 6 Jan 2005 02:31 pm, Horst Herb wrote:
> On Thu, 6 Jan 2005 14:02, Richard Terry wrote:
> > doesn't say 'hey I don't like that - why don't we do x,y,z, or 'I don't
> > think that will work'. Do so, but let the gui-designer then experiment
> > and make the modificications, and if at the end of the day he decides,
> > 'no we will do it this way', then so be it, the backend coders will have
> > to work around that.
>
> I have always advocated clean separation of GUI design, GUI functionality,
> and non-UI backend code.
>
> You can use wxGlade to "paint" the user interface (elements),
> then a coder *inherits* the autogenerated (and *never* manually modified)
> GUI code and fills it with functionality.
>
> If it is done that way, designers can do their work, and coders can do
> theirs, without standing each other in the way ....
>
> ... except if you require weird window manager magic which to you is
> appealing, but I cannot cope with a user interface where I don't see all
> elements in a way that I can consistently access them at any time regardles
> of context. My brain is obviously wired different from yours, and Karstens
> and Syans brains must be wired different yet again - point I am trying to
> make is that there won't be one single design that makes everybody happy,
> because we think and perceive too differently. Meaning we need to keep the
> code and interface design flexible enough to make any user interface
> element redesignable and interchangeable without much coding, meaning we
> need to stick to an architecture that allows this.
>
> Under Karsten's leadership, the backend has come a long way. The middleware
> is getting there. Some GUI is functional, other isn't quite there yet - but
> the GUI is only a small fraction (albeit the only visible one to the end
> user) of the work, and ***NOT*** the most significant one!
>
> The main purpose of medical software is making data collectible and
> accessible in a *safe* and *reliable* way, and in a way that will not
> prevent us from reusing existing data in any perceivable way. Just hacking
> a GUI and filling it up with functionality will not get us there - this is
> how "Medical Director" emerged, Australias "market leader", and look how
> crappy it is under the hood - wouldn't entrust it any data at all,
> regardless how much people like the user interface (I know you don't like
> it at all, but the majority of Australian GPs seems to like it).
>
> Horst
>
>
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnumed-devel





reply via email to

[Prev in Thread] Current Thread [Next in Thread]