Re: [Gnumed-devel] Display of right-arrow next to Date of Birth in client

[Busser, Jim]

I would welcome an enhancement but only personally found the chosen 
implementation (an arrow before or after the DOB) to be confusing and trusted 
others too might be uncertain as to the meaning of the arrows.

I think this is because the date of birth is a raw value (somewhat like a lab 
result) but whereas conventions exist for signalling lab results which are 
parameters (any one test type being able to have multiple results per patient) 
there is no convention for denoting a date of birth as high or low … on top of 
which the arrows were not intending to refer to the whole DOB but rather to 
just the month and date relative to "now".

That is why any signalling of importance of something *derived* from a date of 
birth would best be included in the same parens (   ) as the derived age.

Especially if the above makes sense, we can consider how we want to issue these 
signals inside the

        (         )

Please advise if the topic remains of interest.

-- Jim

On 2014-02-12, at 1:48 PM, Karsten Hilbert <address@hidden> wrote:

> I have removed the arrows (for 1.5) as they appear
> to be too controversial.
> 
> The tooltip will retain the "interval to birthday"
> calculation.
> 
> Karsten
> 
> On Tue, Feb 11, 2014 at 11:23:49PM +0000, Jim Busser wrote:
> 
>> On 2014-02-08, at 2:14 PM, Jim Busser <address@hidden> wrote:
>> 
>>> 1. I find the distraction of arrows which signal "are we before, or after, 
>>> the birthdate" to outweigh their informational value.
>>> 
>>>     --> Can it be made possible to "turn them off"?
>>> 
>> 
>> I might be wrong, but I am interpreting the non-response to the thread 
>> (partially) as reluctance to drop the arrows.
>> 
>> I do concede a downside to the alternative
>> 
>>      [age at Dec 31]
>> 
>> and so if we would persist to find an optimal use for the arrows, can we 
>> relocate them into the "age"?
>> 
>> After all, arrows relate more to the impact of date of birth on "age at 
>> December 31" than they do on the date of birth itself and so how about, if 
>> instead of
>> 
>>      04 Jan 1998 ← (16y 1m)
>> 
>> we do one of
>> 
>>      04 Jan 1998 (16y ← 1m)
>>      04 Jan 1998 (16y 1m ←)
>> 
>> or even omit the above arrow as "implied" or express it instead as
>> 
>>      04 Jan 1998 (16y + 1m)
>> 
>> meaning that they did already this year attain 16 years and are now adding 
>> months to their age-this-year of 16, whereas in the case of a birthday yet 
>> to occur this year,
>> 
>>      04 Mar 1998 (→ 15y 11m)
>> 
>> the arrow is here better-connected to imply the forward (left to right) 
>> passage of time, such that the quantity
>> 
>>      → 15y 11m
>> 
>> will become 16 later in the current calendar year. On their birthday next 
>> month, their age could be shown
>> 
>>      16y
>> 
>> and then
>> 
>>      16y + 1m
>> 
>> which is, I think, better. A person born January 1st 1998, instead of being 
>> displayed 364 days of the year as
>> 
>>      01 Jan 1998 ← (16y …m)
>> 
>> could be more simply shown as
>> 
>>      01 Jan 1998 (16y + …m)
>> 
>> 
>> -- Jim
>>      
>> 
>> 
> 
> 
> 
>> _______________________________________________
>> Gnumed-devel mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/gnumed-devel
> 
> 
> -- 
> GPG key ID E4071346 @ gpg-keyserver.de
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> 
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnumed-devel

signature.asc
Description: Message signed with OpenPGP using GPGMail