2013/5/29 Tim Lyons <firstname.lastname@example.org>
I am sorry this will appear very negative :-( I know that you are
trying to improve the collection of sources. I have tried to be
positive at the end :-)
I am concerned that the User Interface of Gramps is already laborious
for data input, and this will make things worse.You can't know that yet.
Both Benny  and Gerald were initially against this proposal.
Gathering the data may be encouraged by the presentation of specific
fields, but if data entry is too laborious, then people will just
invent a simple source type (with the same fields as at present as I
suggest elsewhere). After all, even some people in this discussion are
suggesting that they will do that, and don't underestimate the
propensity for users to make things easy for themselves.
As far as output presentation is concerned , the fact that the
style conforms to Elizabeth Shown Mills style guide is largely only
necessary if the output is to be published in some formal place -
otherwise, the main thing is just that whatever goes in comes out (if
things like italics are really important, and I'm not saying they
aren't, they could be encoded into the existing fields as is done in
some other FH applications).
It seems as though input of the data will be very complicated and log-
winded. Selecting the right Source Type from a list of 170 types (and
that is apparently mainly for the US-centric data) is tedious,
especially as many appear to be somewhat similar (e.g. there are some
19 census types, and I don't even know where BMD Certificates are!).
When you have selected the type, there is all the data to input.
I don't know whether the data will be spread over both Source and
Citation, but if not, there will be a lot of duplicate input needed
(even if you provide a copy and paste facility - and that would cater
for allowing global changes later).
The approach needs to cater for existing Source and Citation data.
When Benny started, he said;
> Whatever we do, note:And the original Proposed changes:
> 1/ Old way is needed to keep working as that are the GEDCOM fields
> 2/ We don't want Aunt Martha to have problems with Evidence Style
> if she only wants to make a simple family tree. So what we do in GUI
> should be non-intrusive, like the buttons suggested above
> 3/ We could provide an option in the Preferences for experts: 'Only
> use Evidence Style fields for Source/Citation.'
> In which case we make Date, Volume/Page, Title, Author, Pub.Info and
> Abbreviation less prominent or something likewise
also said "Continued support of GEDCOM and GrampsXML is of course
given" that all seems to have gone.
I appreciate that trunk only has the new srcattrtype at the moment,
but that already introduces a huge number of options presumably in a
drop-down iist?, and the evidence templates are already there.If we don't do evidence style, they will go away again. Generic things like author, item, ... will probably remain. If we do evidence style they will be reduced a lot more before we ship something.
I would like to see some more detail about the proposed specification
- something was suggested, with various alternatives, under 'Workflow'
in the previous versions of GEPS 018, but has not been provided in
such detail in the new text. I'm afraid I am used to a commercial
development world, where people can consider what is proposed first
(even with agile, I think one has some idea of what is going to be in
the next sprint). I appreciate that Benny is trying to provide
information and interaction with the developers in the mailing list -
but I think he needs to summarise his conclusions, as it is hard to
know what the current state is.Reality is, I can code something in the GEP and show things which allow discussion , or we can discuss years on end, wait for replies, ..... . Without seeing each other in a sprint or so, the last is too slow to fit with my own schedule. This is OSS, code rules :-)
So, don't worry, in the GEP branch there will be a prototype. Some will like it, some will hate it. A decision will be taken on how to proceed. If more worked out design is needed, the GEP on the wiki will be extended. I have written for companies design docs of software for months without coding, some more agility is what I do for my OSS hacking in the few hours I have time for it. Get hands dirty, see where it leads. Refractor, rewrite, redo, ... . I have better code locally already, but because this is not git, nothing in subversion. This is a good instance in which git would be better.
I think I should prefer:
* Storing the formatted strings in Title, Author, Pub-Info, Page/
Volume etc. as appropriate (Could use simple formatting like
<i>italic</i>) (last proposal in 'Storage' in the GEPS).
* Probably also storing the elements in attributes as proposed
* Offering the existing Title, Author, Pub-Info, Page/Volume etc. for
editing initially, (Benny's initial 2/ objective)
* with an option to open a source-type specific editor for input
(clicking on something to open this editor is similar to (or the same
as) the necessity to select the source-type) (Benny's initial 3/
* The source-type specific editor should be selected from the
sourcetype stored on the source
* The source-type specific editor would need to store the input data
in the attributes, and also generate the formatting and store the data
in the Title, Author, Pub-Info, Page/Volume etc. fields as appropriate
* If the user wants to change the source/citation (e.g. wants to make
some part of the title or author italic, or uses a special formatting
for a specific source or citation) then he can do so knowing that it
will be preserved when the citation is output.
This has the advantages
* It works for existing data (Benny's initial 1/ objective)
* If the user wants to add a new citation, for example a new Page/
Volume he can just type that into the normal editor, knowing from
experience the formatting necessary to achieve the required Evidence
* If, exceptionally, the user has a citation that is not included in
the templates he can enter it, using the formatting codes, into the
* If the user decides that part of the information is wrong (e.g. he
has entered the publisher for the UK Census as "UK Government" but
decided it really should be "UK Home Office") he can make that change
in the Source record, and it will be output for all citations that use
that source record.
* Data associated with the Source will already be there when an
existing source is selected when inputting a citation - without
needing to re-input or copy/paste.
GRAMPS is not a bibliographic tool. That would open a complete new
world, and is overkill for a genealogy program.
GRAMPS needs sufficient fields in the source editor so as to make
good citations possible in its own reports. This is probably your main
gripe now. We have not felt the need to increase on the present amount
of entry fields. No complaints have been received. If you would like
to have extra fields added, please do a suggestion. It is not hard to
do. If you have experience with bibliographic data, you will know that
these applications have up to hundred possible entries! GRAMPS needs
to remain simple with a clear interface.
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).
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
Gramps-devel mailing list