Quantcast

more compact edit person

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

more compact edit person

Benny Malengier
Hi,

I said to wait a bit before doing changes, but I had some ideas and I liked the result, so a changed edit person in trunk.
To see how it compares, open both
http://gramps-project.org/introduction-WP/wp-content/uploads/2010/11/editpersond.png (new one)
and
http://gramps-project.org/introduction-WP/wp-content/uploads/2010/11/editperson3_3_a1.png (old one)

My believe it is important that we can have a lot of the tabs visible at the bottom of the dialog, which this change makes possible, 3 lines saved. Without compromising the organization (in my feeling).

Benny

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: more compact edit person

DS Blank
On Fri, Nov 5, 2010 at 6:47 AM, Benny Malengier
<[hidden email]> wrote:

> Hi,
>
> I said to wait a bit before doing changes, but I had some ideas and I liked
> the result, so a changed edit person in trunk.
> To see how it compares, open both
> http://gramps-project.org/introduction-WP/wp-content/uploads/2010/11/editpersond.png
> (new one)
> and
> http://gramps-project.org/introduction-WP/wp-content/uploads/2010/11/editperson3_3_a1.png
> (old one)
>
> My believe it is important that we can have a lot of the tabs visible at the
> bottom of the dialog, which this change makes possible, 3 lines saved.
> Without compromising the organization (in my feeling).

Yes, agreed, that is looking even better!

-Doug

> Benny
>
> ------------------------------------------------------------------------------
> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> David G. Thomson, author of the best-selling book "Blueprint to a
> Billion" shares his insights and actions to help propel your
> business during the next growth cycle. Listen Now!
> http://p.sf.net/sfu/SAP-dev2dev
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>
>

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: more compact edit person

Gary Burton
In reply to this post by Benny Malengier
Hello Benny,

This is a good improvement. I am trying this new layout on my Asus eeePc and the person editor just about fits the width of the screen now. The previous version did not.

Is it possible to include ellipses in some of the wider fields to allow the window to contract further in width. I am thinking that the Given, Surname, Type & Tags fields prevent the window from narrowing further and ellipses might allow this for devices that require a narrow person editor.

Bye

Gary

From: Benny Malengier <[hidden email]>
To: Gramps Development List <[hidden email]>
Sent: Fri, 5 November, 2010 10:47:10
Subject: [Gramps-devel] more compact edit person

Hi,

I said to wait a bit before doing changes, but I had some ideas and I liked the result, so a changed edit person in trunk.
To see how it compares, open both
http://gramps-project.org/introduction-WP/wp-content/uploads/2010/11/editpersond.png (new one)
and
http://gramps-project.org/introduction-WP/wp-content/uploads/2010/11/editperson3_3_a1.png (old one)

My believe it is important that we can have a lot of the tabs visible at the bottom of the dialog, which this change makes possible, 3 lines saved. Without compromising the organization (in my feeling).

Benny


------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: more compact edit person

Benny Malengier


2010/11/5 Gary Burton <[hidden email]>
Hello Benny,

This is a good improvement. I am trying this new layout on my Asus eeePc and the person editor just about fits the width of the screen now. The previous version did not.

Is it possible to include ellipses in some of the wider fields to allow the window to contract further in width. I am thinking that the Given, Surname, Type & Tags fields prevent the window from narrowing further and ellipses might allow this for devices that require a narrow person editor.

svn up, it should now fit in 799 pixels. I think Asus will be 800.
Setting lower default width pixels in some fields can reduce this further, but we run the risk of things not being well 'connected' anymore, that is, surname should be larger than prefix, ...

Benny


Bye

Gary

From: Benny Malengier <[hidden email]>
To: Gramps Development List <[hidden email]>
Sent: Fri, 5 November, 2010 10:47:10
Subject: [Gramps-devel] more compact edit person

Hi,

I said to wait a bit before doing changes, but I had some ideas and I liked the result, so a changed edit person in trunk.
To see how it compares, open both
http://gramps-project.org/introduction-WP/wp-content/uploads/2010/11/editpersond.png (new one)
and
http://gramps-project.org/introduction-WP/wp-content/uploads/2010/11/editperson3_3_a1.png (old one)

My believe it is important that we can have a lot of the tabs visible at the bottom of the dialog, which this change makes possible, 3 lines saved. Without compromising the organization (in my feeling).

Benny


------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel



------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: more compact edit person

Nick Hall-6
In reply to this post by Gary Burton
The tags field already uses an ellipsis if the tags are wider than the
width available.  The full tag list is displayed in the tooltip.

Nick.


Gary Burton wrote:

> Hello Benny,
>
> This is a good improvement. I am trying this new layout on my Asus
> eeePc and the person editor just about fits the width of the screen
> now. The previous version did not.
>
> Is it possible to include ellipses in some of the wider fields to
> allow the window to contract further in width. I am thinking that the
> Given, Surname, Type & Tags fields prevent the window from narrowing
> further and ellipses might allow this for devices that require a
> narrow person editor.
>
> Bye
>
> Gary
>
>
>     *From:* Benny Malengier <[hidden email]>
>     *To:* Gramps Development List <[hidden email]>
>     *Sent:* Fri, 5 November, 2010 10:47:10
>     *Subject:* [Gramps-devel] more compact edit person
>
>     Hi,
>
>     I said to wait a bit before doing changes, but I had some ideas
>     and I liked the result, so a changed edit person in trunk.
>     To see how it compares, open both
>     http://gramps-project.org/introduction-WP/wp-content/uploads/2010/11/editpersond.png
>     (new one)
>     and
>     http://gramps-project.org/introduction-WP/wp-content/uploads/2010/11/editperson3_3_a1.png
>     (old one)
>
>     My believe it is important that we can have a lot of the tabs
>     visible at the bottom of the dialog, which this change makes
>     possible, 3 lines saved. Without compromising the organization (in
>     my feeling).
>
>     Benny
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> David G. Thomson, author of the best-selling book "Blueprint to a
> Billion" shares his insights and actions to help propel your
> business during the next growth cycle. Listen Now!
> http://p.sf.net/sfu/SAP-dev2dev
> ------------------------------------------------------------------------
>
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>  

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: more compact edit person

Tim Lyons
Administrator
In reply to this post by Benny Malengier
So, that is seven or eight tabs to go from given name to surname. I have to say that it will make inputting people even more laborious than it is now.

Possibly, if you were to put Title/Suffix etc. above Given, and start the cursor at Given, this would make it slightly easier. I am not in favour of changing the tab order from the order of the fields in the display, even though it is not always obvious where a tab is going. For example, with the current layout, I keep trying to use only two tabs between Family and Given, forgetting that Suffix is a tabbable field!

I have taken to using the Data Entry gramplet (but it really needs a sources field). However, I have to ask whether the need to have a proliferation of gramplets to input data (DataInput, Census, AttachSource, Note, SetAttribute) suggests that some aspects of basic data input might need to be improved. Unfortunately, I am not a UI guru, so can't suggest what might make a significant  improvement. The only thing I can say is that is if some of the main displays were made active, this could help in correcting an entry. For example, I keep trying to fill in the Country field in the Places display!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: more compact edit person

DS Blank
On Tue, Nov 9, 2010 at 10:20 AM, Tim Lyons <[hidden email]> wrote:
>
>
> Benny Malengier wrote:
>>
>> http://gramps-project.org/introduction-WP/wp-content/uploads/2010/11/editpersond.png(new
>>
>
> So, that is seven or eight tabs to go from given name to surname. I have to
> say that it will make inputting people even more laborious than it is now.

Yes, I was able to do some data entry this weekend, and not having
Given and Surname close is very awkward. It is getting better, but
still needs some polish.

> Possibly, if you were to put Title/Suffix etc. above Given, and start the
> cursor at Given, this would make it slightly easier. I am not in favour of
> changing the tab order from the order of the fields in the display, even
> though it is not always obvious where a tab is going. For example, with the
> current layout, I keep trying to use only two tabs between Family and Given,
> forgetting that Suffix is a tabbable field!
>
> I have taken to using the Data Entry gramplet (but it really needs a sources
> field).

The Data Entry Gramplet has sources for Gramps 3.3.

> However, I have to ask whether the need to have a proliferation of
> gramplets to input data (DataInput, Census, AttachSource, Note,
> SetAttribute) suggests that some aspects of basic data input might need to
> be improved.

I think we all agree on that, and have come to settle on the idea of a
"certificate". Although this isn't really written down anywhere, I
think the idea is that one could fairly easily design a custom input
format for whatever they might be entering. The Census Addon is an
example [1], but I think the developers would like to make a standard
way for creating (and storing) such data entry forms.

-Doug

[1] - http://www.gramps-project.org/wiki/index.php?title=Census_Addons

> Unfortunately, I am not a UI guru, so can't suggest what might
> make a significant  improvement. The only thing I can say is that is if some
> of the main displays were made active, this could help in correcting an
> entry. For example, I keep trying to fill in the Country field in the Places
> display!
> --
> View this message in context: http://gramps.1791082.n4.nabble.com/more-compact-edit-person-tp3028462p3034441.html
> Sent from the GRAMPS - Dev mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> David G. Thomson, author of the best-selling book "Blueprint to a
> Billion" shares his insights and actions to help propel your
> business during the next growth cycle. Listen Now!
> http://p.sf.net/sfu/SAP-dev2dev
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: more compact edit person

Gerald Britton-2
On Tue, Nov 9, 2010 at 1:33 PM, Doug Blank <[hidden email]> wrote:

> On Tue, Nov 9, 2010 at 10:20 AM, Tim Lyons <[hidden email]> wrote:
>>
>>
>> Benny Malengier wrote:
>>>
>>> http://gramps-project.org/introduction-WP/wp-content/uploads/2010/11/editpersond.png(new
>>>
>>
>> So, that is seven or eight tabs to go from given name to surname. I have to
>> say that it will make inputting people even more laborious than it is now.
>
> Yes, I was able to do some data entry this weekend, and not having
> Given and Surname close is very awkward. It is getting better, but
> still needs some polish.
>
>> Possibly, if you were to put Title/Suffix etc. above Given, and start the
>> cursor at Given, this would make it slightly easier. I am not in favour of
>> changing the tab order from the order of the fields in the display, even
>> though it is not always obvious where a tab is going. For example, with the
>> current layout, I keep trying to use only two tabs between Family and Given,
>> forgetting that Suffix is a tabbable field!
>>
>> I have taken to using the Data Entry gramplet (but it really needs a sources
>> field).
>
> The Data Entry Gramplet has sources for Gramps 3.3.
>
>> However, I have to ask whether the need to have a proliferation of
>> gramplets to input data (DataInput, Census, AttachSource, Note,
>> SetAttribute) suggests that some aspects of basic data input might need to
>> be improved.
>
> I think we all agree on that, and have come to settle on the idea of a
> "certificate". Although this isn't really written down anywhere, I
> think the idea is that one could fairly easily design a custom input
> format for whatever they might be entering. The Census Addon is an
> example [1], but I think the developers would like to make a standard
> way for creating (and storing) such data entry forms.

It may be time to write up something formally on this.  I've been
thinking along the lines of the book Evidence by Elizabeth Shown
Mills.  In that hefty (almost 900 pages!) volume she lays out a
comprehensive plan for citing sources.  At this stage, we need a
flexible framework.  Then, we can add definitions for every source
type in Evidence (will certainly take some time!) and have a good
guide for new source types as they come along.

At a minimum we should have:

1. an Evidence plugin and do the presentation, storage and retrieval
2. Separate definitions for each source type in a simple, easy-to-edit
format (thinking of avid genealogists -- even professional -- who are
not programmers).
3. Optional specific edits by source type(s)

We could also have some way to weigh various sorts of evidence in
order to propose or support conclusions.  e.g. if the evidence is a
primary document (or microfilm of the actual document), it would weigh
heavily;  OTOH if it is a compilation -- say, a published genealogy --
it would weigh less heavily;  if it's just aunt Martha's say-so and
she is 95 and has Alzheimer's, the weight would be, well,
featherweight!

Let's get a discussion going!


>
> -Doug
>
> [1] - http://www.gramps-project.org/wiki/index.php?title=Census_Addons
>
>> Unfortunately, I am not a UI guru, so can't suggest what might
>> make a significant  improvement. The only thing I can say is that is if some
>> of the main displays were made active, this could help in correcting an
>> entry. For example, I keep trying to fill in the Country field in the Places
>> display!
>> --
>> View this message in context: http://gramps.1791082.n4.nabble.com/more-compact-edit-person-tp3028462p3034441.html
>> Sent from the GRAMPS - Dev mailing list archive at Nabble.com.
>>
>> ------------------------------------------------------------------------------
>> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
>> David G. Thomson, author of the best-selling book "Blueprint to a
>> Billion" shares his insights and actions to help propel your
>> business during the next growth cycle. Listen Now!
>> http://p.sf.net/sfu/SAP-dev2dev
>> _______________________________________________
>> Gramps-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>
>
> ------------------------------------------------------------------------------
> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> David G. Thomson, author of the best-selling book "Blueprint to a
> Billion" shares his insights and actions to help propel your
> business during the next growth cycle. Listen Now!
> http://p.sf.net/sfu/SAP-dev2dev
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>



--
Gerald Britton

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: more compact edit person

John Ralls-2

On Nov 9, 2010, at 10:46 AM, Gerald Britton wrote:

> On Tue, Nov 9, 2010 at 1:33 PM, Doug Blank <[hidden email]> wrote:
>> On Tue, Nov 9, 2010 at 10:20 AM, Tim Lyons <[hidden email]> wrote:
>>>
>>>
>>> Benny Malengier wrote:
>>>>
>>>> http://gramps-project.org/introduction-WP/wp-content/uploads/2010/11/editpersond.png(new
>>>>
>>>
>>> So, that is seven or eight tabs to go from given name to surname. I have to
>>> say that it will make inputting people even more laborious than it is now.
>>
>> Yes, I was able to do some data entry this weekend, and not having
>> Given and Surname close is very awkward. It is getting better, but
>> still needs some polish.
>>
>>> Possibly, if you were to put Title/Suffix etc. above Given, and start the
>>> cursor at Given, this would make it slightly easier. I am not in favour of
>>> changing the tab order from the order of the fields in the display, even
>>> though it is not always obvious where a tab is going. For example, with the
>>> current layout, I keep trying to use only two tabs between Family and Given,
>>> forgetting that Suffix is a tabbable field!
>>>
>>> I have taken to using the Data Entry gramplet (but it really needs a sources
>>> field).
>>
>> The Data Entry Gramplet has sources for Gramps 3.3.
>>
>>> However, I have to ask whether the need to have a proliferation of
>>> gramplets to input data (DataInput, Census, AttachSource, Note,
>>> SetAttribute) suggests that some aspects of basic data input might need to
>>> be improved.
>>
>> I think we all agree on that, and have come to settle on the idea of a
>> "certificate". Although this isn't really written down anywhere, I
>> think the idea is that one could fairly easily design a custom input
>> format for whatever they might be entering. The Census Addon is an
>> example [1], but I think the developers would like to make a standard
>> way for creating (and storing) such data entry forms.
>
> It may be time to write up something formally on this.  I've been
> thinking along the lines of the book Evidence by Elizabeth Shown
> Mills.  In that hefty (almost 900 pages!) volume she lays out a
> comprehensive plan for citing sources.  At this stage, we need a
> flexible framework.  Then, we can add definitions for every source
> type in Evidence (will certainly take some time!) and have a good
> guide for new source types as they come along.
>
> At a minimum we should have:
>
> 1. an Evidence plugin and do the presentation, storage and retrieval
> 2. Separate definitions for each source type in a simple, easy-to-edit
> format (thinking of avid genealogists -- even professional -- who are
> not programmers).
> 3. Optional specific edits by source type(s)
>
> We could also have some way to weigh various sorts of evidence in
> order to propose or support conclusions.  e.g. if the evidence is a
> primary document (or microfilm of the actual document), it would weigh
> heavily;  OTOH if it is a compilation -- say, a published genealogy --
> it would weigh less heavily;  if it's just aunt Martha's say-so and
> she is 95 and has Alzheimer's, the weight would be, well,
> featherweight!
>
> Let's get a discussion going!

Mills's "Evidence" is a mere 124 pages. It's "Evidence Explained" that runs 900+ pages -- but the extra is almost entirely examples.

Don't get hung up on that stuff. It's mostly formatting, and every publication in the world has its own style guide. The major US genealogy journals (NGS Quarterly, NEHGS Register, and The American Genealogist) use versions of the Chicago Manual of Style, and most of the minor ones follow their lead. I've no doubt that the European journals have European style guides that bear only passing resemblance to CMS. Very few genealogists get published in journals anyway, so for them it's a matter of personal taste how they format their citations.

Gramps should be flexible: There's an open format for storing citation data, BibTex (http://www.bibtex.org).

The American genealogy blogger "Ancestry Insider" did a nice write up on how software should handle evidence and proof arguments: http://ancestryinsider.blogspot.com/2010/05/evidence-management.html I don't think that it's a perfect exposition, but it's a darned good start. (You'll find some of my thoughts in the comments to the blog.)

Merely assigning a credibility score to a citation or to a piece of evidence is what every other genealogy program does, and as anyone who has studied Ms. Mills's work on the subject or is familiar with the American Board for the Certification of Genealogists "Genealogical Proof Standard" (http://www.bcgcertification.org/resources/standard.html) knows, it's nowhere near adequate.

Regards,
John Ralls


------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: more compact edit person

Gerald Britton-2
On Tue, Nov 9, 2010 at 2:42 PM, John Ralls <[hidden email]> wrote:

>
> On Nov 9, 2010, at 10:46 AM, Gerald Britton wrote:
>
>> On Tue, Nov 9, 2010 at 1:33 PM, Doug Blank <[hidden email]> wrote:
>>> On Tue, Nov 9, 2010 at 10:20 AM, Tim Lyons <[hidden email]> wrote:
>>>>
>>>>
>>>> Benny Malengier wrote:
>>>>>
>>>>> http://gramps-project.org/introduction-WP/wp-content/uploads/2010/11/editpersond.png(new
>>>>>
>>>>
>>>> So, that is seven or eight tabs to go from given name to surname. I have to
>>>> say that it will make inputting people even more laborious than it is now.
>>>
>>> Yes, I was able to do some data entry this weekend, and not having
>>> Given and Surname close is very awkward. It is getting better, but
>>> still needs some polish.
>>>
>>>> Possibly, if you were to put Title/Suffix etc. above Given, and start the
>>>> cursor at Given, this would make it slightly easier. I am not in favour of
>>>> changing the tab order from the order of the fields in the display, even
>>>> though it is not always obvious where a tab is going. For example, with the
>>>> current layout, I keep trying to use only two tabs between Family and Given,
>>>> forgetting that Suffix is a tabbable field!
>>>>
>>>> I have taken to using the Data Entry gramplet (but it really needs a sources
>>>> field).
>>>
>>> The Data Entry Gramplet has sources for Gramps 3.3.
>>>
>>>> However, I have to ask whether the need to have a proliferation of
>>>> gramplets to input data (DataInput, Census, AttachSource, Note,
>>>> SetAttribute) suggests that some aspects of basic data input might need to
>>>> be improved.
>>>
>>> I think we all agree on that, and have come to settle on the idea of a
>>> "certificate". Although this isn't really written down anywhere, I
>>> think the idea is that one could fairly easily design a custom input
>>> format for whatever they might be entering. The Census Addon is an
>>> example [1], but I think the developers would like to make a standard
>>> way for creating (and storing) such data entry forms.
>>
>> It may be time to write up something formally on this.  I've been
>> thinking along the lines of the book Evidence by Elizabeth Shown
>> Mills.  In that hefty (almost 900 pages!) volume she lays out a
>> comprehensive plan for citing sources.  At this stage, we need a
>> flexible framework.  Then, we can add definitions for every source
>> type in Evidence (will certainly take some time!) and have a good
>> guide for new source types as they come along.
>>
>> At a minimum we should have:
>>
>> 1. an Evidence plugin and do the presentation, storage and retrieval
>> 2. Separate definitions for each source type in a simple, easy-to-edit
>> format (thinking of avid genealogists -- even professional -- who are
>> not programmers).
>> 3. Optional specific edits by source type(s)
>>
>> We could also have some way to weigh various sorts of evidence in
>> order to propose or support conclusions.  e.g. if the evidence is a
>> primary document (or microfilm of the actual document), it would weigh
>> heavily;  OTOH if it is a compilation -- say, a published genealogy --
>> it would weigh less heavily;  if it's just aunt Martha's say-so and
>> she is 95 and has Alzheimer's, the weight would be, well,
>> featherweight!
>>
>> Let's get a discussion going!
>
> Mills's "Evidence" is a mere 124 pages. It's "Evidence Explained" that runs 900+ pages -- but the extra is almost entirely examples.
>
> Don't get hung up on that stuff. It's mostly formatting, and every publication in the world has its own style guide. The major US genealogy journals (NGS Quarterly, NEHGS Register, and The American Genealogist) use versions of the Chicago Manual of Style, and most of the minor ones follow their lead. I've no doubt that the European journals have European style guides that bear only passing resemblance to CMS. Very few genealogists get published in journals anyway, so for them it's a matter of personal taste how they format their citations.
>
> Gramps should be flexible: There's an open format for storing citation data, BibTex (http://www.bibtex.org).

Flexible, but consistent, easy to use and easy to extend.  We'd store
the data as attributes on the source or source reference, I suppose,
and present it a consistent way -- hopefully one that is easily
exportable to the various citation methods.  Also, we need to be able
to track non-print data (pictures, sound bites) and data in the cloud
even though clouds are far too fleecy for me.

>
> The American genealogy blogger "Ancestry Insider" did a nice write up on how software should handle evidence and proof arguments: http://ancestryinsider.blogspot.com/2010/05/evidence-management.html I don't think that it's a perfect exposition, but it's a darned good start. (You'll find some of my thoughts in the comments to the blog.)

Looks like a great reference!

>
> Merely assigning a credibility score to a citation or to a piece of evidence is what every other genealogy program does, and as anyone who has studied Ms. Mills's work on the subject or is familiar with the American Board for the Certification of Genealogists "Genealogical Proof Standard" (http://www.bcgcertification.org/resources/standard.html) knows, it's nowhere near adequate.

True enough, but rather than giving up, let's include something that might help.

>
> Regards,
> John Ralls
>
>



--
Gerald Britton

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: more compact edit person

John Ralls-2

On Nov 9, 2010, at 12:12 PM, Gerald Britton wrote:

> On Tue, Nov 9, 2010 at 2:42 PM, John Ralls <[hidden email]> wrote:
>>
>> On Nov 9, 2010, at 10:46 AM, Gerald Britton wrote:
>>
>>> On Tue, Nov 9, 2010 at 1:33 PM, Doug Blank <[hidden email]> wrote:
>>>> On Tue, Nov 9, 2010 at 10:20 AM, Tim Lyons <[hidden email]> wrote:
>>>>>
>>>>>
>>>>> Benny Malengier wrote:
>>>>>>
>>>>>> http://gramps-project.org/introduction-WP/wp-content/uploads/2010/11/editpersond.png(new
>>>>>>
>>>>>
>>>>> So, that is seven or eight tabs to go from given name to surname. I have to
>>>>> say that it will make inputting people even more laborious than it is now.
>>>>
>>>> Yes, I was able to do some data entry this weekend, and not having
>>>> Given and Surname close is very awkward. It is getting better, but
>>>> still needs some polish.
>>>>
>>>>> Possibly, if you were to put Title/Suffix etc. above Given, and start the
>>>>> cursor at Given, this would make it slightly easier. I am not in favour of
>>>>> changing the tab order from the order of the fields in the display, even
>>>>> though it is not always obvious where a tab is going. For example, with the
>>>>> current layout, I keep trying to use only two tabs between Family and Given,
>>>>> forgetting that Suffix is a tabbable field!
>>>>>
>>>>> I have taken to using the Data Entry gramplet (but it really needs a sources
>>>>> field).
>>>>
>>>> The Data Entry Gramplet has sources for Gramps 3.3.
>>>>
>>>>> However, I have to ask whether the need to have a proliferation of
>>>>> gramplets to input data (DataInput, Census, AttachSource, Note,
>>>>> SetAttribute) suggests that some aspects of basic data input might need to
>>>>> be improved.
>>>>
>>>> I think we all agree on that, and have come to settle on the idea of a
>>>> "certificate". Although this isn't really written down anywhere, I
>>>> think the idea is that one could fairly easily design a custom input
>>>> format for whatever they might be entering. The Census Addon is an
>>>> example [1], but I think the developers would like to make a standard
>>>> way for creating (and storing) such data entry forms.
>>>
>>> It may be time to write up something formally on this.  I've been
>>> thinking along the lines of the book Evidence by Elizabeth Shown
>>> Mills.  In that hefty (almost 900 pages!) volume she lays out a
>>> comprehensive plan for citing sources.  At this stage, we need a
>>> flexible framework.  Then, we can add definitions for every source
>>> type in Evidence (will certainly take some time!) and have a good
>>> guide for new source types as they come along.
>>>
>>> At a minimum we should have:
>>>
>>> 1. an Evidence plugin and do the presentation, storage and retrieval
>>> 2. Separate definitions for each source type in a simple, easy-to-edit
>>> format (thinking of avid genealogists -- even professional -- who are
>>> not programmers).
>>> 3. Optional specific edits by source type(s)
>>>
>>> We could also have some way to weigh various sorts of evidence in
>>> order to propose or support conclusions.  e.g. if the evidence is a
>>> primary document (or microfilm of the actual document), it would weigh
>>> heavily;  OTOH if it is a compilation -- say, a published genealogy --
>>> it would weigh less heavily;  if it's just aunt Martha's say-so and
>>> she is 95 and has Alzheimer's, the weight would be, well,
>>> featherweight!
>>>
>>> Let's get a discussion going!
>>
>> Mills's "Evidence" is a mere 124 pages. It's "Evidence Explained" that runs 900+ pages -- but the extra is almost entirely examples.
>>
>> Don't get hung up on that stuff. It's mostly formatting, and every publication in the world has its own style guide. The major US genealogy journals (NGS Quarterly, NEHGS Register, and The American Genealogist) use versions of the Chicago Manual of Style, and most of the minor ones follow their lead. I've no doubt that the European journals have European style guides that bear only passing resemblance to CMS. Very few genealogists get published in journals anyway, so for them it's a matter of personal taste how they format their citations.
>>
>> Gramps should be flexible: There's an open format for storing citation data, BibTex (http://www.bibtex.org).
>
> Flexible, but consistent, easy to use and easy to extend.  We'd store
> the data as attributes on the source or source reference, I suppose,
> and present it a consistent way -- hopefully one that is easily
> exportable to the various citation methods.  Also, we need to be able
> to track non-print data (pictures, sound bites) and data in the cloud
> even though clouds are far too fleecy for me.
>
>>
>> The American genealogy blogger "Ancestry Insider" did a nice write up on how software should handle evidence and proof arguments: http://ancestryinsider.blogspot.com/2010/05/evidence-management.html I don't think that it's a perfect exposition, but it's a darned good start. (You'll find some of my thoughts in the comments to the blog.)
>
> Looks like a great reference!
>
>>
>> Merely assigning a credibility score to a citation or to a piece of evidence is what every other genealogy program does, and as anyone who has studied Ms. Mills's work on the subject or is familiar with the American Board for the Certification of Genealogists "Genealogical Proof Standard" (http://www.bcgcertification.org/resources/standard.html) knows, it's nowhere near adequate.
>
> True enough, but rather than giving up, let's include something that might help.

You missed my point. Don't give up, do what the AI piece says to do.

Regards,
John Ralls


------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: more compact edit person

Gerald Britton-2
On Tue, Nov 9, 2010 at 4:08 PM, John Ralls <[hidden email]> wrote:

>
> On Nov 9, 2010, at 12:12 PM, Gerald Britton wrote:
>
>> On Tue, Nov 9, 2010 at 2:42 PM, John Ralls <[hidden email]> wrote:
>>>
>>> On Nov 9, 2010, at 10:46 AM, Gerald Britton wrote:
>>>
>>>> On Tue, Nov 9, 2010 at 1:33 PM, Doug Blank <[hidden email]> wrote:
>>>>> On Tue, Nov 9, 2010 at 10:20 AM, Tim Lyons <[hidden email]> wrote:
>>>>>>
>>>>>>
>>>>>> Benny Malengier wrote:
>>>>>>>
>>>>>>> http://gramps-project.org/introduction-WP/wp-content/uploads/2010/11/editpersond.png(new
>>>>>>>
>>>>>>
>>>>>> So, that is seven or eight tabs to go from given name to surname. I have to
>>>>>> say that it will make inputting people even more laborious than it is now.
>>>>>
>>>>> Yes, I was able to do some data entry this weekend, and not having
>>>>> Given and Surname close is very awkward. It is getting better, but
>>>>> still needs some polish.
>>>>>
>>>>>> Possibly, if you were to put Title/Suffix etc. above Given, and start the
>>>>>> cursor at Given, this would make it slightly easier. I am not in favour of
>>>>>> changing the tab order from the order of the fields in the display, even
>>>>>> though it is not always obvious where a tab is going. For example, with the
>>>>>> current layout, I keep trying to use only two tabs between Family and Given,
>>>>>> forgetting that Suffix is a tabbable field!
>>>>>>
>>>>>> I have taken to using the Data Entry gramplet (but it really needs a sources
>>>>>> field).
>>>>>
>>>>> The Data Entry Gramplet has sources for Gramps 3.3.
>>>>>
>>>>>> However, I have to ask whether the need to have a proliferation of
>>>>>> gramplets to input data (DataInput, Census, AttachSource, Note,
>>>>>> SetAttribute) suggests that some aspects of basic data input might need to
>>>>>> be improved.
>>>>>
>>>>> I think we all agree on that, and have come to settle on the idea of a
>>>>> "certificate". Although this isn't really written down anywhere, I
>>>>> think the idea is that one could fairly easily design a custom input
>>>>> format for whatever they might be entering. The Census Addon is an
>>>>> example [1], but I think the developers would like to make a standard
>>>>> way for creating (and storing) such data entry forms.
>>>>
>>>> It may be time to write up something formally on this.  I've been
>>>> thinking along the lines of the book Evidence by Elizabeth Shown
>>>> Mills.  In that hefty (almost 900 pages!) volume she lays out a
>>>> comprehensive plan for citing sources.  At this stage, we need a
>>>> flexible framework.  Then, we can add definitions for every source
>>>> type in Evidence (will certainly take some time!) and have a good
>>>> guide for new source types as they come along.
>>>>
>>>> At a minimum we should have:
>>>>
>>>> 1. an Evidence plugin and do the presentation, storage and retrieval
>>>> 2. Separate definitions for each source type in a simple, easy-to-edit
>>>> format (thinking of avid genealogists -- even professional -- who are
>>>> not programmers).
>>>> 3. Optional specific edits by source type(s)
>>>>
>>>> We could also have some way to weigh various sorts of evidence in
>>>> order to propose or support conclusions.  e.g. if the evidence is a
>>>> primary document (or microfilm of the actual document), it would weigh
>>>> heavily;  OTOH if it is a compilation -- say, a published genealogy --
>>>> it would weigh less heavily;  if it's just aunt Martha's say-so and
>>>> she is 95 and has Alzheimer's, the weight would be, well,
>>>> featherweight!
>>>>
>>>> Let's get a discussion going!
>>>
>>> Mills's "Evidence" is a mere 124 pages. It's "Evidence Explained" that runs 900+ pages -- but the extra is almost entirely examples.
>>>
>>> Don't get hung up on that stuff. It's mostly formatting, and every publication in the world has its own style guide. The major US genealogy journals (NGS Quarterly, NEHGS Register, and The American Genealogist) use versions of the Chicago Manual of Style, and most of the minor ones follow their lead. I've no doubt that the European journals have European style guides that bear only passing resemblance to CMS. Very few genealogists get published in journals anyway, so for them it's a matter of personal taste how they format their citations.
>>>
>>> Gramps should be flexible: There's an open format for storing citation data, BibTex (http://www.bibtex.org).
>>
>> Flexible, but consistent, easy to use and easy to extend.  We'd store
>> the data as attributes on the source or source reference, I suppose,
>> and present it a consistent way -- hopefully one that is easily
>> exportable to the various citation methods.  Also, we need to be able
>> to track non-print data (pictures, sound bites) and data in the cloud
>> even though clouds are far too fleecy for me.
>>
>>>
>>> The American genealogy blogger "Ancestry Insider" did a nice write up on how software should handle evidence and proof arguments: http://ancestryinsider.blogspot.com/2010/05/evidence-management.html I don't think that it's a perfect exposition, but it's a darned good start. (You'll find some of my thoughts in the comments to the blog.)
>>
>> Looks like a great reference!
>>
>>>
>>> Merely assigning a credibility score to a citation or to a piece of evidence is what every other genealogy program does, and as anyone who has studied Ms. Mills's work on the subject or is familiar with the American Board for the Certification of Genealogists "Genealogical Proof Standard" (http://www.bcgcertification.org/resources/standard.html) knows, it's nowhere near adequate.
>>
>> True enough, but rather than giving up, let's include something that might help.
>
> You missed my point. Don't give up, do what the AI piece says to do.

Yeah.  Too much multitasking!

>
> Regards,
> John Ralls
>
>



--
Gerald Britton

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: more compact edit person

Tim Lyons
Administrator
In reply to this post by John Ralls-2
John Ralls-2 wrote
The American genealogy blogger "Ancestry Insider" did a nice write up on how software should handle evidence and proof arguments: http://ancestryinsider.blogspot.com/2010/05/evidence-management.html I don't think that it's a perfect exposition, but it's a darned good start. (You'll find some of my thoughts in the comments to the blog.)
Looks like an example of the aphorism that "All problems in computer science can be solved by another level of indirection"!

Actually, in Gramps, one can store the most of the evidence summary (shown in green) in the Source Reference. The source reference does not have attributes, but it does have notes, so the detailed attributes, evidence and notes would all have to be stored in the notes field. This would seem to work well. (Except that the notes field doesn't get output in some reports).
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: more compact edit person

Benny Malengier
In reply to this post by Tim Lyons


2010/11/9 Tim Lyons <[hidden email]>
So, that is seven or eight tabs to go from given name to surname. I have to
say that it will make inputting people even more laborious than it is now.

The idea is that in most cases surname is preentered. It is the case from the tree person view and from the family editor. I'll add it on relview and pedigreeview.
We now have english surname derivation and latin (from mother and father). I want to work that out a bit more.

Apart from that, ALT+S moves you to the field.
Not that I cannot switch some fields, but I'm wondering if it really is such a problem. People who use the mouse use the mouse, people who use keyboard have one key combination..
Should eg CTRL+TAB also go to surname on given name?

Benny


Possibly, if you were to put Title/Suffix etc. above Given, and start the
cursor at Given, this would make it slightly easier. I am not in favour of
changing the tab order from the order of the fields in the display, even
though it is not always obvious where a tab is going. For example, with the
current layout, I keep trying to use only two tabs between Family and Given,
forgetting that Suffix is a tabbable field!

I have taken to using the Data Entry gramplet (but it really needs a sources
field). However, I have to ask whether the need to have a proliferation of
gramplets to input data (DataInput, Census, AttachSource, Note,
SetAttribute) suggests that some aspects of basic data input might need to
be improved. Unfortunately, I am not a UI guru, so can't suggest what might
make a significant  improvement. The only thing I can say is that is if some
of the main displays were made active, this could help in correcting an
entry. For example, I keep trying to fill in the Country field in the Places
display!
--
View this message in context: http://gramps.1791082.n4.nabble.com/more-compact-edit-person-tp3028462p3034441.html
Sent from the GRAMPS - Dev mailing list archive at Nabble.com.

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel


------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: more compact edit person

John Ralls-2
In reply to this post by Tim Lyons

On Nov 9, 2010, at 3:26 PM, Tim Lyons wrote:

>
>
> John Ralls-2 wrote:
>>
>> The American genealogy blogger "Ancestry Insider" did a nice write up on
>> how software should handle evidence and proof arguments:
>> http://ancestryinsider.blogspot.com/2010/05/evidence-management.html I
>> don't think that it's a perfect exposition, but it's a darned good start.
>> (You'll find some of my thoughts in the comments to the blog.)
>>
>
> Looks like an example of the aphorism that "All problems in computer science
> can be solved by another level of indirection"!
>
> Actually, in Gramps, one can store the most of the evidence summary (shown
> in green) in the Source Reference. The source reference does not have
> attributes, but it does have notes, so the detailed attributes, evidence and
> notes would all have to be stored in the notes field. This would seem to
> work well. (Except that the notes field doesn't get output in some reports).

The problem with that approach is that an evidence summary and proof argument will encompass all the sources found during one's "reasonable exhaustive search".

Elizabeth Mills's position on this is that the entire research process should be completed before creating any event records in one's genealogy database. That includes searching for any evidence which might refute the conclusion *after writing the proof argument*. Her position is based on the way most programs work, providing no support for the research, evidence evaluation, and proof argument phases of the process. (Mills; "Smith and Jones: How to Cope with Families of Common Name"; NGS Family History Conference, Salt Lake City, May 2010, Session W141)

This isn't a computer science issue at all. It's about how to perform genealogical research, and how genealogical database programs (don't) support doing that research.

Regards,
John Ralls


------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: more compact edit person

Gerald Britton-2
On Thu, Nov 11, 2010 at 12:57 PM, John Ralls <[hidden email]> wrote:

>
> On Nov 9, 2010, at 3:26 PM, Tim Lyons wrote:
>
>>
>>
>> John Ralls-2 wrote:
>>>
>>> The American genealogy blogger "Ancestry Insider" did a nice write up on
>>> how software should handle evidence and proof arguments:
>>> http://ancestryinsider.blogspot.com/2010/05/evidence-management.html I
>>> don't think that it's a perfect exposition, but it's a darned good start.
>>> (You'll find some of my thoughts in the comments to the blog.)
>>>
>>
>> Looks like an example of the aphorism that "All problems in computer science
>> can be solved by another level of indirection"!
>>
>> Actually, in Gramps, one can store the most of the evidence summary (shown
>> in green) in the Source Reference. The source reference does not have
>> attributes, but it does have notes, so the detailed attributes, evidence and
>> notes would all have to be stored in the notes field. This would seem to
>> work well. (Except that the notes field doesn't get output in some reports).
>
> The problem with that approach is that an evidence summary and proof argument will encompass all the sources found during one's "reasonable exhaustive search".
>
> Elizabeth Mills's position on this is that the entire research process should be completed before creating any event records in one's genealogy database.

I would certainly disagree with that approach.  I use my database to
collect and index sources, wherever I find them.  One such source may
not help me today and may even contradict something else I hold more
reliable but tomorrow that same source could be helpful for something
else entirely.

> That includes searching for any evidence which might refute the conclusion *after writing the proof argument*. Her position is based on the way most programs work, providing no support for the research, evidence evaluation, and proof argument phases of the process. (Mills; "Smith and Jones: How to Cope with Families of Common Name"; NGS Family History Conference, Salt Lake City, May 2010, Session W141)

Again, not my MO.
>
> This isn't a computer science issue at all. It's about how to perform genealogical research, and how genealogical database programs (don't) support doing that research.

Well said, and an opportunity for us to try to fill the gap.





--
Gerald Britton

------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: more compact edit person

Jason Simanek-2
In reply to this post by Tim Lyons
Hello,

On Tue, Nov 9, 2010 at 9:20 AM, Tim Lyons <[hidden email]> wrote:
> Possibly, if you were to put Title/Suffix etc. above Given, and start the
> cursor at Given, this would make it slightly easier. I am not in favour of
> changing the tab order from the order of the fields in the display, even
> though it is not always obvious where a tab is going.

I have always thought about trying to improve the Edit Person UX/UI,
but Benny's post about the new multi-surname approach got me engaged.
I submitted a design proof and some comments to the blog post:

Here’s my attempt at improving the Edit Person UX. It’s very similar
to the “compact” version you display at the end of the post, but I
think the relationship of the Surname and Origin properties need to be
more clearly presented. In the compact version you display, it’s
difficult to understand if Origin relates to the person or to the
surname.

I also see this problem with the Type property. Type should refer to
all of the name properties displayed, correct? It relates to this
particular/primary name-group, not to the person. The person can have
multiple name-groups that each have their own Type.

One other thing I added is a “preview” of the name so that you can see
how adding content to the various inputs affects the name.

<http://bohemianalps.com/GRAMPS/ui/gramps_editperson_redesignJS.png>

I'm not super excited about it—it's not undeniably good—but I think
it's slightly more well-structured than what we currently have. More
importantly I hope we can continue to discuss and improve the
usability of this particular part of Gramps.

-Jason Simanek

------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: more compact edit person

robhealey1
Dear Jason:

Wow!  It has been a while since we last heard from you...  I am glad to see that you are still part of this mailing list!

I truly LOVE the new design that you have created in your graphic, and the link!  I think this would make an incredible re-design of the person editor/ name editor....

Sincerely yours,
Rob G. Healey


On Thu, Nov 11, 2010 at 3:54 PM, Jason Simanek <[hidden email]> wrote:
Hello,

On Tue, Nov 9, 2010 at 9:20 AM, Tim Lyons <[hidden email]> wrote:
> Possibly, if you were to put Title/Suffix etc. above Given, and start the
> cursor at Given, this would make it slightly easier. I am not in favour of
> changing the tab order from the order of the fields in the display, even
> though it is not always obvious where a tab is going.

I have always thought about trying to improve the Edit Person UX/UI,
but Benny's post about the new multi-surname approach got me engaged.
I submitted a design proof and some comments to the blog post:

Here’s my attempt at improving the Edit Person UX. It’s very similar
to the “compact” version you display at the end of the post, but I
think the relationship of the Surname and Origin properties need to be
more clearly presented. In the compact version you display, it’s
difficult to understand if Origin relates to the person or to the
surname.

I also see this problem with the Type property. Type should refer to
all of the name properties displayed, correct? It relates to this
particular/primary name-group, not to the person. The person can have
multiple name-groups that each have their own Type.

One other thing I added is a “preview” of the name so that you can see
how adding content to the various inputs affects the name.

<http://bohemianalps.com/GRAMPS/ui/gramps_editperson_redesignJS.png>

I'm not super excited about it—it's not undeniably good—but I think
it's slightly more well-structured than what we currently have. More
importantly I hope we can continue to discuss and improve the
usability of this particular part of Gramps.

-Jason Simanek

------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel


------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: more compact edit person

Benny Malengier
In reply to this post by Jason Simanek-2


2010/11/12 Jason Simanek <[hidden email]>
Hello,

On Tue, Nov 9, 2010 at 9:20 AM, Tim Lyons <[hidden email]> wrote:
> Possibly, if you were to put Title/Suffix etc. above Given, and start the
> cursor at Given, this would make it slightly easier. I am not in favour of
> changing the tab order from the order of the fields in the display, even
> though it is not always obvious where a tab is going.

I have always thought about trying to improve the Edit Person UX/UI,
but Benny's post about the new multi-surname approach got me engaged.
I submitted a design proof and some comments to the blog post:

Here’s my attempt at improving the Edit Person UX. It’s very similar
to the “compact” version you display at the end of the post, but I
think the relationship of the Surname and Origin properties need to be
more clearly presented. In the compact version you display, it’s
difficult to understand if Origin relates to the person or to the
surname.

I also see this problem with the Type property. Type should refer to
all of the name properties displayed, correct? It relates to this
particular/primary name-group, not to the person. The person can have
multiple name-groups that each have their own Type.

One other thing I added is a “preview” of the name so that you can see
how adding content to the various inputs affects the name.

<http://bohemianalps.com/GRAMPS/ui/gramps_editperson_redesignJS.png>

I'm not super excited about it—it's not undeniably good—but I think
it's slightly more well-structured than what we currently have. More
importantly I hope we can continue to discuss and improve the
usability of this particular part of Gramps.

Looks nice. Some things:
* prefix is the prefix of the surname, like Van Damme, so it  must be on the surname line.
* The English short labels are nice, but in translation we might loose that. With prefix gone, it can should not matter too much. Design must still work with labels that are a bit longer though.
* The HIG says to align input fields. This is not the case here for title and given input. I don't mind too much about that, but we have to be aware of it.
* This design has an extra line in the compact mode. The offset is that that creates more clarity as you indicate.
* On a new person there is no image yet and many people have no image. Is it nice then to have image to the left?

I can give it a try, from what I see only the glade file changes. What do others say?

Benny


-Jason Simanek

------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel


------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: more compact edit person

DS Blank
On Fri, Nov 12, 2010 at 3:17 AM, Benny Malengier
<[hidden email]> wrote:

>
>
> 2010/11/12 Jason Simanek <[hidden email]>
>>
>> Hello,
>>
>> On Tue, Nov 9, 2010 at 9:20 AM, Tim Lyons <[hidden email]> wrote:
>> > Possibly, if you were to put Title/Suffix etc. above Given, and start
>> > the
>> > cursor at Given, this would make it slightly easier. I am not in favour
>> > of
>> > changing the tab order from the order of the fields in the display, even
>> > though it is not always obvious where a tab is going.
>>
>> I have always thought about trying to improve the Edit Person UX/UI,
>> but Benny's post about the new multi-surname approach got me engaged.
>> I submitted a design proof and some comments to the blog post:
>>
>> Here’s my attempt at improving the Edit Person UX. It’s very similar
>> to the “compact” version you display at the end of the post, but I
>> think the relationship of the Surname and Origin properties need to be
>> more clearly presented. In the compact version you display, it’s
>> difficult to understand if Origin relates to the person or to the
>> surname.
>>
>> I also see this problem with the Type property. Type should refer to
>> all of the name properties displayed, correct? It relates to this
>> particular/primary name-group, not to the person. The person can have
>> multiple name-groups that each have their own Type.
>>
>> One other thing I added is a “preview” of the name so that you can see
>> how adding content to the various inputs affects the name.
>>
>> <http://bohemianalps.com/GRAMPS/ui/gramps_editperson_redesignJS.png>
>>
>> I'm not super excited about it—it's not undeniably good—but I think
>> it's slightly more well-structured than what we currently have. More
>> importantly I hope we can continue to discuss and improve the
>> usability of this particular part of Gramps.
>
> Looks nice. Some things:

I agree that it looks nice, and the best so far. Some further points:

> * prefix is the prefix of the surname, like Van Damme, so it  must be on the
> surname line.

I have 2,000 people in my tree, and none have prefixes (and few
suffixes). It makes sense that Prefix would be before, but it doesn't
have to.

An idea: currently, this view is  always in "new data" mode. That is,
it always shows all fields that one can add new data. What if there
were two, or three modes: view, edit, add? View mode would show
read-only what the data is. Edit mode would allow you to edit it as it
exists (no prefix, don't show it). New data would show all fields.

In any event, I would be happy with prefix and suffix not showing by
default, but only when you click "More details" (which could be
shorted to the "collapse" arrow or ">>").

> * The English short labels are nice, but in translation we might loose that.
> With prefix gone, it can should not matter too much. Design must still work
> with labels that are a bit longer though.

We could have special short label translations, or move labels to mouse over.

> * The HIG says to align input fields. This is not the case here for title
> and given input. I don't mind too much about that, but we have to be aware
> of it.

Perhaps put labels over input fields.

> * This design has an extra line in the compact mode. The offset is that that
> creates more clarity as you indicate.

Yes, looks nice. Most of the time we are not editing, but viewing, and
this helps a lot.

> * On a new person there is no image yet and many people have no image. Is it
> nice then to have image to the left?

Maybe not show it if it doesn't exist? I have few images (so far).

> I can give it a try, from what I see only the glade file changes. What do
> others say?

-Doug

> Benny
>
>>
>> -Jason Simanek
>>
>>
>> ------------------------------------------------------------------------------
>> Centralized Desktop Delivery: Dell and VMware Reference Architecture
>> Simplifying enterprise desktop deployment and management using
>> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
>> client virtualization framework. Read more!
>> http://p.sf.net/sfu/dell-eql-dev2dev
>> _______________________________________________
>> Gramps-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>
>
> ------------------------------------------------------------------------------
> Centralized Desktop Delivery: Dell and VMware Reference Architecture
> Simplifying enterprise desktop deployment and management using
> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
> client virtualization framework. Read more!
> http://p.sf.net/sfu/dell-eql-dev2dev
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>
>

------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
12
Loading...