gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] GUI design mix


From: Sebastian Hilbert
Subject: Re: [Gnumed-devel] GUI design mix
Date: Fri, 16 Jul 2004 08:28:16 +0200
User-agent: KMail/1.6.82

From my perspective this is not an issue of what is conceptually superior.
It is and most likely always will be an issue of simply *doing* things.

I can only speak for myself but the current mix of GUI designs came about 
because it was much easier for me to simply hack notebookplugins. All one has 
to do do is add a few lines to a plugin and voila it shows up as a notebook 
tab. 

This is simply the result of me not having enough time to do it right/better 
in the first place. I like the Richard space design very much and always 
planned on converting my plugins to it but that never reached priority high 
enough to actually get *done*. Does that make things clear ? 

I shamefully admit never to have read the design documents in the wiki. I know 
they are there. I point other people to it. But I never made use of them.

Is there a description somwhere of what one needs to do to convert a plugin 
from notebook style to Richard style. I have a strange feeling I don't even 
know what that means.

I don't know if we have reached a consensus on that but I would prefer either 
notebook tab design or integrated Richard design. 

The way I see it we need to get this separation done. Once this has been done 
I would welcome if anyone who knows Richardspace enough could convert let's 
say the labdata plugin and integrate it into Richard space. I would be more 
than happy to learn from that and make my other plugins (LabJournal, 
gmSacanMedDocs, gmIndexMedDocs, gmShowMedDocs ) fit for Richard space. 

So if that gets done within the next five weaks (earliest :-) ) I could start 
hacking again right after my exams.
> snip >
>
> >I and others would think
> > we should still post any worries or concerns, trusting Richard will at
> > least note them, and give them due consideration before disregarding,
> > if that is his decision. Richard would need to advise whether "blindly"
> > means no questions, or whether alternative views are welcome along the
> > way, maybe sent to him and Ian privately, but without them having to
> > feel the need to explain or defend everything along the way.
>
> Obviously everyone should still comment/postconcerns/raise objections/point
> out other possibilities.
>
> My interest in this is not to just push my paradigm, but to ensure gnuMed
> gets running with the best possible functionality - and I don't presume to
> beleive that I alone can do that. In fact the current mixture contains
> elements from many different inputs, and quite rightly so.
>
>  Where I think I have the skill is to integrate much of this both visually
> and functionally.
>
> The current SOAPtext control is a good example. The edit area's I designed
> in VB work brilliantly, in part because vb is visually and 
> programmatically easier than wxPython, but there are inherent design
> problems in wxPython. However, having put out my functionality wish-list to
> the list, Ian was able to do the coding to modify the programming editor as
> I suggested to form the basis for an improved version of the editing area
> concept. Karsten originally took my popup word suggestion lists as used in
> VB and implemented it in wxPython, python etc.
>
> >if I can reference the John Belushi
> > film "Animal House", to NOT listen to the devil on the left shoulder
> > saying "where does Richard get off, thinking he is the master and we
> > are the slave" and instead think "let's cut him however much slack I/we
> > can". Any pessimists can even reserve the right to expect to be able to
> > say (silently I hope) "I told you so", but hopefully with a *sliver* of
> > willingness to be proven wrong.
>
> I would hope people are not so thin skinned as to say "where does richard
> get off thinking he is master......", that's not what it is about. I can't
> possibly know all the answers for the gui, all the best ways, but I can, do
> and will sit and spend hours fiddling with combinations and permutations or
> the screen (usually in QT designer) or VB,or wxPython,  to see what does
> functionally work. At the end of the day however, someone has to be able to
> say that from their experience, I think xyz will work.
>
> And yes, I won't get it right all the time, yes I'll balls some things up,
> yes others will chip in and correct the process, yes in version nnn from
> users experience and combined wishes stuff will be changed,  but someone
> needs the hand on the gui-design tiller, and that was what I was designated
> to do in the first place.
>
> Regards
>
> richard
>
> On Fri, 16 Jul 2004 02:13 pm, you wrote:
> > On Jul 15, 2004, at 4:44 PM, Richard Terry wrote:
> > > I wish somewhere in your hearts you could put some trust in my
> > > abilities to
> > > make things functional and just, even for a period of say two months,
> > > follow
> > > my instructions blindly regarding the gui,  and just do what I say to
> > > improve
> > > the look of the gui and its functionality
> >
> > This has come up more than once and maybe it is in the interest of the
> > project to address it now, so that we either commit (say through 0.1)
> > to let Richard drive the GUI, or to more clearly resolve why not.
> > Warning: while 9 more paragraphs follow, most are bearably short :-)
> >
> > I can agree that during any one iteration (like getting to 0.1) it
> > behooves us to work consistently under one GUI plan.
> >
> > Only a few have commented, but most have so far seemed supportive of
> > the Richard/Ian SOAP widget and where not, maybe only through
> > misunderstanding.
> >
> > I think we should give it a "go" . We may just need to be mindful of
> > the following:
> >
> > It is possible that there may be some uneasiness / unhappiness about
> > the choices along the way!
> >
> > a) even the "technical" people may not be able to see their way fully
> > to the end of a 0.1 GUI implementation until it has been tried, i.e. to
> > know in advance whether everything (maybe some key things) that Richard
> > wants, or will want, will be deliverable. However, though we cannot
> > predict these in advance, we can discover them on the way, and likely
> > in such event we can find acceptable (if not ideal) solutions.
> >
> > b) part of any uneasiness might derive from intermittent limitation on
> > Richard's part, in either time or in his ability to convey by email
> > particular reasonings, but maybe it is only through a successful
> > implementation that the reasoning and the "pros" -- which presumably
> > may outweigh any "cons" -- can be better experienced and thus
> > understood. And if it proves to be broken (not able to be made to work
> > satisfactorily) then at least Richard can know it wasn't for lack of
> > most people having given it a real chance.
> >
> > NB on b) I still have trouble with the idea of an editing area in which
> > arrow keys permit the insertion point to travel anywhere within the
> > entire area, and the Enter key will start a new line *provided the
> > insertion point is in mid-text*, yet in the face of an insertion point
> > begging to receive more text input, or pending a request for a new
> > line, the Enter key will otherwise behave quite unconventionally and
> > IGNORE the insertion point, NOT exit saving the SOAP note, but JUMP
> > somewhere. And yet, if we give Richard the nod, I will accord him the
> > responsibility of devising a consistent and satisfactory system, if not
> > up front, then fixed in due course. Ordinarily I and others would think
> > we should still post any worries or concerns, trusting Richard will at
> > least note them, and give them due consideration before disregarding,
> > if that is his decision. Richard would need to advise whether "blindly"
> > means no questions, or whether alternative views are welcome along the
> > way, maybe sent to him and Ian privately, but without them having to
> > feel the need to explain or defend everything along the way.
> >
> > c) it is pretty clear to me that Richard would not be asking other
> > people to take a lead in the coding if he were able to do most of it
> > (or even lead it) himself. Therefore a deliberate mindset would be
> > needed by all during this effort, if I can reference the John Belushi
> > film "Animal House", to NOT listen to the devil on the left shoulder
> > saying "where does Richard get off, thinking he is the master and we
> > are the slave" and instead think "let's cut him however much slack I/we
> > can". Any pessimists can even reserve the right to expect to be able to
> > say (silently I hope) "I told you so", but hopefully with a *sliver* of
> > willingness to be proven wrong. Flames tolerated, though my intent was
> > to dampen rather than fan any.
> >
> > Sorry for preaching, especially without a license, let alone training,
> > but can we achieve a consensus?
>
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnumed-devel

-- 
Sebastian Hilbert 
Leipzig / Germany
[www.openmed.org] -> PGP welcome, HTML ->/dev/null
ICQ: 86 07 67 86   -> No files, no URL's
My OS: Suse Linux. Geek by Nature, Linux by Choice

Unterstützen Sie die Entwicklung von freier Software durch Ihren
        Internet - Einkauf unter der Adresse:
http://profiseller.de/shop1/index.php3?ps_id=P1658133




reply via email to

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