Date: prev next · Thread: first prev next last
February 2012 Archives by date, by thread · List index


On 02/15/2012 02:44 AM, Jan Holesovsky wrote:
Hi NoOp, Jean-Francois,

NoOp píše v Út 14. 02. 2012 v 20:16 -0800:

So, introducing the new feature is ok for me as it may help some
users. But this decision should not interfere with satisfied
users who now *lack* an important visual clue when devising their
documents. In the previous releases, the option was there: users
could display or hide the text limits; why change that?

Thank you very much for the feedback!  The change was discussed
here, mostly with Christoph [cc'd], see:

http://lists.freedesktop.org/archives/libreoffice-ux-advise/2011-August/000240.html

I sincerely appreciate your reponse. However:

Perhaps... such a dramatic change should have also been discussed on the
discuss and/or user list before implementation?

That thread doesn't focus on the 'no border'/modified
Edit|View|Text Boundries (margin and column) issue(s), but instead
primarily discuses/focuses (as it's subject implies) "Header and Footers
separators design").


Basically it comes from the design that was proposed already in the
OOo times, see
http://wiki.services.openoffice.org/wiki/DocumentBorder .

That page was last modified in 2009:
[This page was last modified on 18 November 2009, at 19:02]
So you've/we've implemented a change that was suggested on OOo over 2
years ago for the sake of 'modernization' that has never been
implemented in OOo, including OOo-dev 3.4.0? Well done.


The current (3.5) design looked as the best option, was in the daily 
builds [http://dev-builds.libreoffice.org/daily/] for several
months, and nobody complained - so we were happy with it; what a pity
that you haven't pointed it out earlier :-

There will be much "you should have tested", "you should have pointed it
out earlier"; unfortunately, the primary users will not have discovered
the "improvement"/"feature" was released in the 'new & improved version'
and would not have noticed until they upgraded from 3.4 to 3.5.

https://bugs.freedesktop.org/show_bug.cgi?id=46073
[Bug 46073 - Page Layout Guides (margins, headers, footers) No Longer
Visible (regression bug) ]


The good news is - nothing is lost!  It is just code, and can be 
changed.  It is here:

http://opengrok.libreoffice.org/xref/core/sw/source/core/layout/paintfrm.cxx#6276

 [the method lcl_CreatePageAreaDelimiterPrimitives()], please play
with it a bit, and try to come up with something that will be both
pretty, and will fit your needs - I am sorry, but we do not want just
to switch back to the old behavior, it was so 90's, and we have
already been getting too much beating for looking old, and obsolete.

Great! Then is shouldn't be difficult for those that made the change to:
1) modify the code to replace the original code to change it back,
and/or 2) create an extension to allow users the option to switch
between the two... right?


If you need any help, please come to the #libreoffice-dev on 
irc.freenode.net.

If you need user feedback, please visit users@global.libreoffice.org for
added user experiences/remarks.


So is this the correct list, or is the design list more
appropriate?

The design list has much broader goal than this mailing list - it 
involves website design discussions, general discussions, etc.  The
goal of libreoffice-ux-advise@ is to get quick feedback on patches
that involve usability, and tight and fast designers + hackers
co-operation. Please join if you are interested!

Thank you for that information/advise. Given the:
Easily - somebody creates a patch, sends info about that to this
list, and then it is is discussed here.  If it does not fit as it
is, then it is tweaked until both the original developer + the UX
people are all
resonse (below), it would seem to me that LO should relook at their policy.


If the latter is the case, then it appears that this request from
January has been ignored: 
<http://listarchives.libreoffice.org/global/design/msg03578.html> 
[libreoffice-design] Text boundaries like 3.4.x

We have too many switches already, sorry, adding more options is not 
what we want.  Even with the 'borders' feature we were able to find
a solution that fits all involved, I am sure we will succeed here
too.

Please explain 'we were able to find a solution that fits all involved'.
Who is "we" and what exactly was the solved.


doesn't seem to address the issue. So how can a change like this
be changed without a specific bug report?

Easily - somebody creates a patch, sends info about that to this
list, and then it is is discussed here.  If it does not fit as it is,
then it is tweaked until both the original developer + the UX people
are all happy :-)

So let's review:

1. "Somebody creates a patch that affects the entire
look/feel/GUI/workfolow et al of LO and "sends info about that to this
list" and then it is is discussed here."

2. "If it does not fit as it is, then it is tweaked until both the
original developer + the UX people are all happy :-)"

And then, apparently, the change is incorportated in the next LO
release... regardless of user feedback/tests? Amazing. Of course LO
developers/testers et al will complain that 3.5 has been available for
testing for several months. But LO need to expect and understand that LO
have a similar/migrated OOo user base, so to react with "That was a
design choice that was started long ago in the OpenOffice.org
times, discussed at least lively with Christoph Noack (and most probably
on the ux-advise list) a few months ago...

I don't really like being asked to get some different feature back right
after the release when people have plenty of times to report the
(not-really-a) bug months before."
<http://permalink.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/24300>
is nonsense.

It appears that Cedric is unwilling to make any changes:
<http://comments.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/24267>
[No page and Columns boundaries in 3.5]

So who determines who these "ux-adivse" determiners who apparently have
the power to make these 'changes' are?

Again:
====
<http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
"About Libreoffice-ux-advise>
        
English (USA)

Meeting ground for hackers and UX experts - get advise here for user
experience questions

Please confine discussions about implementation details and
decision-making about the right UX solution to the respective lists.

To see the collection of prior postings to the list, visit the
Libreoffice-ux-advise Archives. "
===

I see nothing in that indicating that this list is somehow the
place/authority to:


1. "Somebody creates a patch that affects the entire
look/feel/GUI/workfolow et al of LO and "sends info about that to
this list" and then it is is discussed here."

2. "If it does not fit as it is, then it is tweaked until both the
original developer + the UX people are all happy :-)"

Bottom line is that LO decided to implement Cedrics header/footer
additions (should have been an extension IMO as it's already pissing
some users off
(<http://permalink.gmane.org/gmane.comp.documentfoundation.libreoffice.user/17009>)
and seemed surprised when the change goes live as a standard release:
====
"http://www.libreoffice.org/download/
LibreOffice 3.5.0 Final (2012-02-14)

Our latest, feature rich version"
====

So it's a release, it's not a beta/RC etc. LO have significantly
modified the basic document page & workflow and responses are along the
lines of:
<https://bugs.freedesktop.org/show_bug.cgi?id=46073#c7>

====
I don't really like being asked to get some different feature back right
after the release when people have plenty of times to report the
(not-really-a) bug months before.

--
Cedric
====



Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.