[Libreoffice-ux-advise] Advice on adding Smart-Art related settings

Mirek M. mazelm at gmail.com
Wed Oct 2 00:31:56 PDT 2013


Hi guys,

On Wed, Oct 2, 2013 at 8:09 AM, Samuel Mehrbrodt <s.mehrbrodt at gmail.com>wrote:

> Hi Jacobo,
>
> good to see this being improved. I don't think an option in the Options
> dialog is the best way to go. Users might not expect it there and think
> it's a bug that you can't edit SmartArt (because you could before)
>

Not only that -- because the dialog is so full of options, this option
would be lost to most users.
Also, because of the usability disaster that the dialog is, I'd rather not
add any more options to it.

>
> I have another suggestion:
> You could disable editing SmartArt by default and offer editing via the
> context menu. Would that be possible to convert the SmartArt live to shapes
> when the user wishes it?
>

That's exactly what I was going to suggest, except in the name of
discoverability and tablet-readiness, I'd rather have a contextual toolbar
(appearing only when a SmartArt shape is selected) with a "Convert to
Shapes" button.

>
> Thanks
> Samuel
>
> Am 01.10.2013 17:49, schrieb Jacobo Aragunde Pérez:
>
>  Hi :)
>>
>> Lately we have been working on SmartArt support on Writer. As you know,
>> in 4.1 and prior the SmartArt figures were imported to LO shapes but
>> they weren't exported back when saving to docx, causing data loss.
>>
>> Our first approach, which is already pushed to master, was saving the
>> full SmartArt information in the InteropGrabBag of the shapes and save
>> it back when exporting to docx. In this situation, users are allowed to
>> do changes to the shapes but these changes are not saved back.
>>
>> That takes us to the next step: we want to make imported SmartArt
>> immutable, so users are aware that they can change the document but not
>> the shapes. We would like to add a configuration setting to enable or
>> disable this behaviour, and we have thought of doing it at Options ->
>> Load/Save -> MS Office. We have some doubts on how to call this
>> parameter and what should be the default behaviour.
>>
>> Following the existing conventions in that dialog, we could call the
>> option "OOXML Smart-Art to LibreOfficeDev".
>>
>> Right now we think that the proper way would be to mark the load option
>> always, making the option read only, so the user would not be able to
>> modify it and will be aware that OOXML SmartArt would always be loaded
>> and converted.
>>
>> The second option, saving, would be the selectable one. If we would mark
>> the option, the Smart-Art will be converted into basic shapes and saved
>> as such. If it would not be marked, the Smart-Art will be saved as such
>> in the OOXML documents and, to avoid user modifications, it will be
>> converted to a bitmap in the UI and saved as such if saved as an
>> OpenDocument format.
>>
>> Another topic is whether it would be desirable to let the user select
>> this option per application. This way, we would have 3 options:
>>   * "WinWord OOXML Smart-Art to LibreOfficeDev Writer".
>>   * "Excel OOXML Smart-Art to LibreOfficeDev Calc".
>>   * "PowerPoint OOXML Smart-Art to LibreOfficeDev Impress".
>>
>> In the future, if we would have a decent implementation of a similar
>> functionality of Smart-Art for the OpenDocuments, we would have both
>> options selectable and the options would say:
>>   * "WinWord OOXML Smart-Art to LibreOfficeDev Writer or reverse".
>>
>> Comments? Suggestions?
>>
>>
> ______________________________**_________________
> Libreoffice-ux-advise mailing list
> Libreoffice-ux-advise at lists.**freedesktop.org<Libreoffice-ux-advise at lists.freedesktop.org>
> http://lists.freedesktop.org/**mailman/listinfo/libreoffice-**ux-advise<http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libreoffice-ux-advise/attachments/20131002/fc511a2e/attachment.html>


More information about the Libreoffice-ux-advise mailing list