Re: [libreoffice-design] Improving Impress' UX

Hi,

Le 11/06/2015 16:59, Joel Madero a écrit :
> On 06/10/2015 11:18 PM, Jean-Baptiste Faure wrote:
> > [...]
> > > Likely when the document is fully finished, it would be published to the wiki,
> > > similar to how we are doing with the HIG.
> > And you will lost the complete history of the document. That is a very
> > important information and it is a bad idea to rely on Google to keep the
> > memory of the LibreOffice community. The data of the LibreOffice project
> > must be stored on TDF servers not elsewhere. The "working in progress"
> > documents are project data and must be stored on TDF servers.
> While I fully respect your opinion - this last statement is just not
> correct. We don't use words like "must" in the project when referring to
> how other people accomplish their work. The doers get to decide,

Well, it depends of the kind of tool :
when working on code, each dev can use whatever editor/IDE he wants [1], 
but he *must* use git.
Devs who prefer svn, mercurial or bazaar *must* use git to commit 
LibreOffice patches.


And if every designer starts to use his own online office (gdoc, office 
365, why not Feng Office ? some private Owncloud and others...), it'll 
be a real mess ! ;-)

And another *must* : we *must* write in english ! It's so obvious that 
we don't realize it. What would happen if each doers decide to use his 
own language ?

> Jay has
> been doing a *lot* of work, he has found a workflow that works for him,
> and no one is going to dictate that he change it. That being said, he's
> been incredibly accommodating and has shared the document through email
> so that others can download it, comment on it, and get their feedback
> incorporate, all without affecting your (and others) phobia of google
> products.

So he's very productive when using gdoc (and I agree because I know that 
gdoc is 'state of the art' of collaborative editing). But time spent to 
export/import and possible loss of data/style/information makes him less 
productive.

So when we look at the whole process of creating a document, with all 
participants, there should be no loss of time when using the least 
common tool : a wiki. And we avoid any problem of data export/import.
The downside is that everyone has to learn that least common tool (but 
as Sophie told us, a new wiki editor is coming that will lower that 
barrier).


> So I'll respectfully say, there is no "must" - there seems to be a
> perfectly acceptable compromise that Jay found. Instead of everyone
> wasting their time arguing over what tool we use, maybe just
> (suggestion) download the doc that he shared (that is on the wiki), do
> your edits, and share it back on the mailing list. The other alternative
> is that you or one of the other google haters (which is fine...), take
> the document that he shared through email, you create a wiki, and you
> guys can edit it on the wiki, then Jay can incorporate those change in
> his google doc....again, the doers can decide.

Sorry, but I don't agree : even in a free software project, there must 
be some minimum mandatory tools that ease working together.

Doers can decide on some tools : theirs internal tools, but not on 
common tools.

In our example, IMHO, Jay can use gdoc for his own research, and ask 
other people to comment on gdoc.
But when the document is an official TDF one, it should be 
handled/stored by tdf tools (for technical and ethical reasons).
Ex : the new HIG should be worked only on tdf wiki.


Everyone should ask himself : if I use that tool to create a file, will 
it easy for other people to work later on that file ?
("easy" means : free as free beer + free as free speech + standard 
format that is supposed to be available/readable in next years)

So designers can use any software to produce screenshots/mockups that 
we'll be integrated in the HIG (Gimp, inkscape or Pencil... they just 
have to export as png, jpg or svg).
Using Photoshop or Balsamiq to create mockup may generate problems as if 
other designers want to modify them, they have to buy/crack those 
software, or use it with some restrictions. Or recreate from scratch, 
which is a waste of time.


I'm the first to ask myself this question : I used Pencil :
- it's free as free beer
- it's free as free speech
- it produces mockups as beautiful as Balsamiq's ones
- but his own format is not known by other software : will it be easy to 
read those '.ep' files in the future ?
So I learned Inkscape (some basic functions) to replace it. I lost some 
specifics tools for mockups (hand-made style, widgets gallery...), but I 
gained a standard software with standard format, maintained software 
[2], fast and powerful software.

When you see the UbuntuTouch UI Toolkit [3], you have a good example of 
how we could create mockups.
And if we want to "eat our own dog food", we should use LO Draw only for 
mockups ! (We should define a template or a widget gallery)


Cheers,
Michel

[1] I'm the one who started to add QtCreator support :-)
[2] With some Firefox update, Pencil could not export to png anymore... 
I had to find a solution in forums, and patch myself Pencil
[3] https://github.com/halfsail/Ubuntu-UI-Tookit, ubuntuUiToolkit.svg

--
To unsubscribe e-mail to: design+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted