Comments interspersed,
Martha
[EMAIL PROTECTED] wrote:
ubject:
Re: [users-biblio] Comments & clarifications for dev & users list msgs
From:
"Bruce D'Arcus" <[EMAIL PROTECTED]>
Date:
Fri, 25 Feb 2005 09:41:58 -0500
To:
users@bibliographic.openoffice.org
To:
users@bibliographic.openoffice.org
CC:
dev@bibliographic.openoffice.org
I commented on this email in the users list.
Subject:
Re: [dev-biblio] Initial comments on OOoBib UI Architectural Design 2.0
From:
Peter Tandler <[EMAIL PROTECTED]>
Date:
Fri, 25 Feb 2005 09:36:32 +0100
To:
dev@bibliographic.openoffice.org
To:
dev@bibliographic.openoffice.org
Hi,
speaking of multiple databases: What I have been missing in
bibliography systems is the possibility to synchronize bib DBs.
Scenario: There are shared bibDBs for our institute and for our
division, but I also have a personal DB on my laptop (and on my PC at
home). If I copy entries to my laptop it would be cool if the copied
references would be synchronized automatically so that I get all
(public) updates automatically (as soon as I have the network
connection) -- and vice versa.
What do you think?
(And this implies the need for supporting multiple databases.)
Yes, synchronization is directly related to the issue (users list) of
sending a doc with metadata to someone and then getting back their
corrections/additions to the references. In that case OOoBib would need
to request whether to overwrite the current data with the new data --
therefore similar issue to synchronizing.
Subject:
Re: [dev-biblio] Initial comments on OOoBib UI Architectural Design 2.0
From:
Matthias Basler <[EMAIL PROTECTED]>
Date:
Sat, 26 Feb 2005 22:23:31 +0100
To:
dev@bibliographic.openoffice.org
To:
dev@bibliographic.openoffice.org
Hi bibliographers,
what came into my mind when I just read Marthas comments:
Is one of those code developers that will eventually work on OOoBib reading our
mailing list?
If not, we need to involve them even in early decisions, because they have a
clearer idea what features are easy/hard to implement and what of our "whishes"
for OOoBib are more or less unrealistic to code.
Those of us with programming skills certainly have some ideas of that aspect,
but since most of us have not worked with the actual source code of OOo (in
C++) we might propose things that can hardly realized within the current OOo
framework. (I for one can only GUESS what is easy/hard/not to realize.)
In cases like f.e. the "standalone OOoBib" questions they might tell us some
side effects of our design decisions that we did not yet foresee.
I simply want to avaoid that Martha builds a nice GUI concept with us ... and at
the end the actual coders tell us they cannot do this or that in a reasonable
time frame or cannot do other things at all.
So, is the feedback from the potential coders ensured?
Yes! Yeah! Amen! and whatever else I can say to indicate strong
agreement!!!!!!!!!!!!!!!
Subject:
Re: [dev-biblio] Initial comments on OOoBib UI Architectural Design 2.0
From:
David Wilson <[EMAIL PROTECTED]>
Date:
Sun, 27 Feb 2005 11:37:25 +1100
To:
dev@bibliographic.openoffice.org
To:
dev@bibliographic.openoffice.org
I have been in contact with Andreas Martens, the Project Lead for the
word-processor project. I outlined the scope, approach and objectives of our
project in December 2004. He has discussed them with Oliver Specht the User
Interface project leader. Andreas responded -
"The support of a useful bibliographic interface is on my wish list and
we're willing to spent development effort on the Writer side of this.
What we need to know are your requirements.
The first step should be that your project members agree on an interface which
should be supported by the Writer. This has to be discussed with our
developers, Oliver Specht will be responsible. After we come to an agreement
we create a new feature issue via issuezilla.
The (Writer-)implementation could start in March, April.. when the OOo2.0 is
finished. So my request for you is to come up with a specification about the
interface Writer should support. Oliver will have a look at it [to determine]
if we could implement it technically. Then I'll organize development
resources to do so."
Notice that there appears to be some confusion about whether we are
going to provide them an "interface" or a "specification" document --
these are very, very different levels of GUI design, and the more visual
the GUI design (e.g., detailed physical-display design), the more rework
will have to be done if they say they cannot support something. From
experience that is why I am using my iterative design process --
resolving the higher-level issues without doing visual design yields a
"specification" document that makes it much easier to change when the
developers say "No!" to something. At this point it definitely sounds
like the GUI logical-design level (i.e, task-flow specifications) would
be the appropriate deliverable, but if we could get feedback on the
conceptual design (next after architectural design), that would be best!
Subject:
Re: [dev-biblio] Initial comments on OOoBib UI Architectural Design 2.0
From:
"Bruce D'Arcus" <[EMAIL PROTECTED]>
Date:
Sat, 26 Feb 2005 20:36:52 -0500
To:
dev@bibliographic.openoffice.org
To:
dev@bibliographic.openoffice.org
I wrote this before David responded, but will send nonetheless.
On Feb 26, 2005, at 4:23 PM, Matthias Basler wrote:
I simply want to avaoid that Martha builds a nice GUI concept with
us ... and at
the end the actual coders tell us they cannot do this or that in a
reasonable
time frame or cannot do other things at all.
So, is the feedback from the potential coders ensured?
We still can't tell you who is going to code the GUI, nor how.
I think if we don't show people how it ought to be done, however, it
won't ever happen. It's easier to scale back based on the realities
of context -- and be explicit about the compromises you are making
-- than to start with a compromised design.
Also, OOo is itself a bit of moving target. 2.0 adds XForms
support, for example. It's currently aimed more at end users, but I
happen to believe it could be expanded to make things easier for
developers as well.
So, I'm not too worried about this issue.
I understand, Bruce -- but I have little interest in spending time doing
rework. ;-) Thus it is critically important that we have a strong sense
of what is supportable in the GUI before doing the lower-levels of GUI
design.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
