Kendy's Work in LO GUI+Help

l10n
#1

Hello,

I was flabbergasted by the forced-unto-us not-so-functional online help
system, as you might have read several times on this list. This is something
that mostly targets the non-English speaking communities (at least on Linux
and OS X) - and we were not asked how the end product should look like.
Since it was implemented there were no major enhancements and the
non-functionality of that online help is still obvious to all.
Now the thing will go further:
http://artax.karlin.mff.cuni.cz/~kendy/blog/archives/monthly/2011-03.html#2011-03-31T11_35_21.htm
What are the OFFICIAL specs, confirmed by the LibreOffice community for
further development of the online help? What is "our approach", who is "us"?
Does it include us, the L10N community, translating and updating the help,
or who? Did the L10N teams leads give their perspective on this issue?

The online help system developer has also revamped the search toolbar "to
behave more like in [...] Firefox":
http://artax.karlin.mff.cuni.cz/~kendy/blog/archives/monthly/2011-03.html#2011-03-29T09_43_06.htm
and he is now also mentoring students cleaning the UI. While some tasks in
http://wiki.documentfoundation.org/Development/Gsoc/Ideas#UI_cleanup
look like real cleanup, some might really be re-designs.

I am wondering if LO is (unlike OOo) going in the direction that every
developer can change the UI without consent from the community. (That could
lead to LO developers thinking loud on their blogs like this: "Playing with
the LO code yesterday I decided that LO will now drop the Base component,
because I don't like it, it just takes place on disk, it should be an
extension.") Or maybe there are some individuals (or employees of some
companies) with greater rights and privileges than others in the LO
community?

Should not the UI changes be discussed in length? With some usability
studies etc.? Will the disappointment with the decision-making process lead
to further forks of LibreOffice or to the return of translation teams back
to the OOo project?

I am writing here, because I think this is not a single-developer decision
nor just a GUI/developer-people-thing, and because I would like to know the
official specs for the Help and GUI redesign/cleanup as well as the opinion
of the L10N teams, because international help system is very much in the
hands of the L10N teams.

I do like Kendy and his commitment to this project, I do know that he means
well and is spending a lot of time working on the development of
LibreOffice. But some things just need major consensus of all the people
deeply involved. Maybe there should be a sandbox for that kind of
enhancements and people should then vote if they like the feature enough so
it would be further developed and included into vanilla LO.

Thank you for your time and attention.

Martin

#2

Hi

I tend to agree with Martin comments and I also praise the work and committment of Kendy to the project, as well as each individual developer trully commited to the project goals.

LO went into a new and frenetic development pace which concerns me if no strong leadership and planning is not well conducted.

Tha include proper collaterals.

For example, I missed the help for the new Writer title pages of the latest releases, and I know they are not there because I have not found them for translation.

On top of the need for specs (often seen as a unimportant and cumbersome task by casual developers) I am struggling with the radical changes of the configuration of the software since release 3.2 that has almost no document on how to make it work for you, much less on examples and snippets.

For me, no new feature should be released without proper /help/user/admin documentation, even if this is is slowing the pace of the release schedule.

Thanks for the attention as well. I do speak for myself but I know this is what a large enterprise want.

Olivier

#3

Hi Martin,

I was flabbergasted by the forced-unto-us not-so-functional online
help system, as you might have read several times on this list.

I am sorry that you feel personally offended by that; the online help is
not perfect - but for those who feel that as a stopper, there is always
the possibility to install the offline version.

And patches are greatly appreciated! I have no intention to let it be
bad; it is an easy code, some 1300 lines of Python:

http://cgit.freedesktop.org/libreoffice/help/tree/helpcontent2/to-wiki/wikiconv2.py

This is something that mostly targets the non-English speaking
communities (at least on Linux and OS X) - and we were not asked how
the end product should look like. Since it was implemented there were
no major enhancements and the non-functionality of that online help is
still obvious to all.

http://wiki.documentfoundation.org/Development/Wikihelp was created
after I did the wrong step that I developed the initial version without
consulting you. I thought that this version was agreed on the l10n
mailing list - was it not?

Now the thing will go further:
http://artax.karlin.mff.cuni.cz/~kendy/blog/archives/monthly/2011-03.html#2011-03-31T11_35_21.htm
What are the OFFICIAL specs, confirmed by the LibreOffice community
for further development of the online help?

I am extremely sorry if I misunderstood that the above mentioned spec
was generally embraced; but let me assure you once again that I won't do
any more work for you. You may have noticed that I become a translator
in the meantime too (http://translations.documentfoundation.org/cs/), so
now I have much better understanding when you talk about the translator
needs.

What is "our approach", who is "us"?

In this context, it was those who contributed to the development of the
conversion tool.

Does it include us, the L10N community, translating and updating the
help, or who? Did the L10N teams leads give their perspective on this
issue?

It is in line with the spec, so in fact yes, I thought that it was
discussed, and agreed.

The online help system developer has also revamped the search toolbar
"to behave more like in [...] Firefox":
http://artax.karlin.mff.cuni.cz/~kendy/blog/archives/monthly/2011-03.html#2011-03-29T09_43_06.htm
and he is now also mentoring students cleaning the UI. While some
tasks in
http://wiki.documentfoundation.org/Development/Gsoc/Ideas#UI_cleanup
look like real cleanup, some might really be re-designs.

I am wondering if LO is (unlike OOo) going in the direction that every
developer can change the UI without consent from the community. (That
could lead to LO developers thinking loud on their blogs like this:
"Playing with the LO code yesterday I decided that LO will now drop
the Base component, because I don't like it, it just takes place on
disk, it should be an extension.") Or maybe there are some individuals
(or employees of some companies) with greater rights and privileges
than others in the LO community?

Well - should we vote on each and every feature that would go into
LibreOffice? That would bore people to death after a while :wink: If you
look at the development mailing list, each and every patch that does
more good than bad is committed; and everything can be again reverted,
or subsequently fixed, no problem there.

Should not the UI changes be discussed in length? With some usability
studies etc.?

If there is somebody who comes up with a beautiful design and convinces
enough people to implement it, that's perfect! But do you remember the
amount of controversy that Renaissance project brought? And where did
it end up? Lots of discussions, and no result.

So my conclusion is "never let perfect be enemy of the good" :wink: There
are so many obviously incorrect things in the UI, that you just cannot
make things worse when you fix that. And if you do, there is a plenty
of other developers who will just fix your error. Or users make me
revert that. Whatever :slight_smile: - that's the beauty of freedom.

Will the disappointment with the decision-making process lead to
further forks of LibreOffice or to the return of translation teams
back to the OOo project?

Again - I promise to do everything to save you work. When the help
switches to something that would need change of your workflow, the l10n
people will be the first to be involved.

But the GSoC task does not involve any change for you, it is only about
the technical part, and that is converting the wikihelp to native help
systems.

I am writing here, because I think this is not a single-developer
decision nor just a GUI/developer-people-thing, and because I would
like to know the official specs for the Help and GUI redesign/cleanup
as well as the opinion of the L10N teams, because international help
system is very much in the hands of the L10N teams.

I do like Kendy and his commitment to this project, I do know that he
means well and is spending a lot of time working on the development of
LibreOffice. But some things just need major consensus of all the
people deeply involved. Maybe there should be a sandbox for that kind
of enhancements and people should then vote if they like the feature
enough so it would be further developed and included into vanilla LO.

Well, honestly, I am not interested in a setup where I work on something
for 3 months, that would be just thrown away by a poll :wink: - similarly
as you do not want to see your work being erased. I do hope what helps
more is the introduction of the development snapshots:

http://dev-builds.libreoffice.org/daily/

There you can test the changes early, and get the developers to improve
them, or revert, or whatever. Unfortunately no Windows builds yet - but
only due to master still not being buildable on Windows; and only one of
the machines builds with translations (MacOSX).

We (OK - Norbert, Thorsten, Robert, me) are working on both - that way
you'll be able to test your improvements in translations the next day
after you change something, without you having to build your own build.

Hope this helps,
Kendy

#4

Hi Olivier,

-------- Original-Nachricht --------

Von: Olivier Hallot <olivier.hallot@documentfoundation.org>

LO went into a new and frenetic development pace which concerns me if no
strong leadership and planning is not well conducted.

I slightly disagree here on the term "leadership". I'd rather see
"collaboration" here (kathedral vs. bazaar).
But after all, some early brainstorming / decision making / specification
would be very appreciated, as well as documentation.

On top of the need for specs (often seen as a unimportant and cumbersome
task by casual developers) I am struggling with the radical changes of
the configuration of the software since release 3.2 that has almost no
document on how to make it work for you, much less on examples and
snippets.

Well - good example, that "strong leadership" itself does not really help
to prevent such things. The new configuration was implemented under
OOo's (Sun's) "strong leadership" model (with all the requests for
specification, qa, documentation etc. in place).
I don'T want to say, that missing documentation is a good thing -
just, that you don't create the docs by enforcing leadership.

For me, no new feature should be released without proper
/help/user/admin documentation, even if this is is slowing the pace of
the release schedule.

"Proper" is a very subjective term. I'd like to see a basic documentation
from the developer - a a certain place (something like OOo's spec
project, but not such bloated spec document formalism). This should
be reviewed and enhacend by other community members (in collaboration
with the developer).

regards,

André

#5

Hi guys.

Hi Olivier,

-------- Original-Nachricht --------
> Von: Olivier Hallot <olivier.hallot@documentfoundation.org>

>
> LO went into a new and frenetic development pace which concerns me if no
> strong leadership and planning is not well conducted.

I slightly disagree here on the term "leadership". I'd rather see
"collaboration" here (kathedral vs. bazaar).
But after all, some early brainstorming / decision making / specification
would be very appreciated, as well as documentation.

+1. Leadership occurs naturally. There's no need for naming a leader.

>
> On top of the need for specs (often seen as a unimportant and cumbersome
> task by casual developers) I am struggling with the radical changes of
> the configuration of the software since release 3.2 that has almost no
> document on how to make it work for you, much less on examples and
> snippets.

Well - good example, that "strong leadership" itself does not really help
to prevent such things. The new configuration was implemented under
OOo's (Sun's) "strong leadership" model (with all the requests for
specification, qa, documentation etc. in place).
I don'T want to say, that missing documentation is a good thing -
just, that you don't create the docs by enforcing leadership.

Yeap! There's a lot of examples out there too. Not only about document
creation, but in any community made jobs.
But I don't want to get in Philosofic issues in this thread.

>
> For me, no new feature should be released without proper
> /help/user/admin documentation, even if this is is slowing the pace of
> the release schedule.

"Proper" is a very subjective term. I'd like to see a basic documentation
from the developer - a a certain place (something like OOo's spec
project, but not such bloated spec document formalism). This should
be reviewed and enhacend by other community members (in collaboration
with the developer).

+1. Collaboration is basics.

regards,

Cheers

#6

Hi all,

There something my grand'ma always said to me: help you and heaven will help you :wink:

Hi Olivier,

-------- Original-Nachricht --------

Von: Olivier Hallot<olivier.hallot@documentfoundation.org>

LO went into a new and frenetic development pace which concerns me if no
strong leadership and planning is not well conducted.

I slightly disagree here on the term "leadership". I'd rather see
"collaboration" here (kathedral vs. bazaar).
But after all, some early brainstorming / decision making / specification
would be very appreciated, as well as documentation.

What we miss the most is communication, whatever the medium, finding the information is something currently to difficult for all the steps of the project.

On top of the need for specs (often seen as a unimportant and cumbersome
task by casual developers) I am struggling with the radical changes of
the configuration of the software since release 3.2 that has almost no
document on how to make it work for you, much less on examples and
snippets.

Well - good example, that "strong leadership" itself does not really help
to prevent such things. The new configuration was implemented under
OOo's (Sun's) "strong leadership" model (with all the requests for
specification, qa, documentation etc. in place).
I don'T want to say, that missing documentation is a good thing -
just, that you don't create the docs by enforcing leadership.

+1 and again, anybody is free to collaborate with the developers to write the documentation. We should define where to retrieve the basic information and then work on the top of that for our different needs (documentation, QA, marketing, and so on).

For me, no new feature should be released without proper
/help/user/admin documentation, even if this is is slowing the pace of
the release schedule.

"Proper" is a very subjective term. I'd like to see a basic documentation
from the developer - a a certain place (something like OOo's spec
project, but not such bloated spec document formalism). This should
be reviewed and enhacend by other community members (in collaboration
with the developer).

yes, exactly. But again, everybody is free to set this process.

Kind regards
Sophie

#7

Hi André

Well... the terms leadeship was a perhaps bit strong as I also don't want to loose the bazaar, it just cannot be toooo bazaar-ish.

Just for the records, I created a new wiki page to remind us on the missing docs ("easy doc"). Ideally it should be linked in the development menu (the one in light blue).

http://wiki.documentfoundation.org/DevDocumentation

Regards

Olivier

#8

Hi Olivier,

Hi André

Well... the terms leadeship was a perhaps bit strong as I also don't
want to loose the bazaar, it just cannot be toooo bazaar-ish.

Just for the records, I created a new wiki page to remind us on the
missing docs ("easy doc"). Ideally it should be linked in the
development menu (the one in light blue).

http://wiki.documentfoundation.org/DevDocumentation

I've already called for help on that on the project list. I've begin the work by filling issues assigned to me. I've asked to do the same, see
http://listarchives.libreoffice.org/www/projects/msg00009.html

Kind regards
Sophie