Bug 78155 - EDITING: RFE: Allow custom editable fields as allowed in LO Writer
Summary: EDITING: RFE: Allow custom editable fields as allowed in LO Writer
Status: RESOLVED DUPLICATE of bug 53548
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-01 13:58 UTC by Máirín Duffy
Modified: 2016-10-11 09:49 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Máirín Duffy 2014-05-01 13:58:37 UTC
Problem description: 

I've created a screencast to demonstrate the need for this feature here: https://www.youtube.com/watch?v=6fdPIAPM_Pc

Essentially, for designers to be able to produce excellent and really usable slide deck templates, we need more custom editable fields to be allowed in the slide masters. In the example video, I show how there are more fields typical in slide decks that the default set (only Title and a plain text box are provided for autolayout) of styleable master slide text blocks aren't enough.

In the example, I have customer name, a subtitle for the presentation, and the presenter's name (which is sometimes the same as the author, but may vary especially for multi-presenter slide decks.) As a designer, I'd like to lay those fields out and style them for the users of my templates as well. Today that is not possible.

The workaround is to create sample slides, style the text on those slides using filler text and hope the template users don't muck with the styling too much. The problem is, though, as soon as template users add a new slide, the slide is going to default to the autolayout sample text provided by the slide master, so I as the designer can no longer suggest full layouts for them. 

If the master slide could house styled additional custom fields, then new slides created using the same slide master would inherit them and the experience for designers and template users would be much improved.

I have used LO to create such documents in LO Writer - it allows for the creation of arbitrary custom fields that users of my LO Writer templates can fill in the data for and have the styles already laid out and set up for them. I don't understand why those menu options are missing from LO Impress. If it was possible to implement it similar to how LO Writer does - including allowing for control of the sample text (E.g., "Type your name here." <= that kind of thing) then it would be excellent.

Operating System: Fedora
Version: 4.2.3.3 release
Comment 1 Cor Nouws 2014-05-01 14:52:42 UTC
Hi Máirín,

thanks for the ideas here.
I understand that Insert > Fields offers too little possibilities.

As a work around for time being, you can add more text to your (custom) master pages.
Comment 2 Máirín Duffy 2014-05-01 14:58:20 UTC
Hi Cor, as I explained in comment 0, adding text to the masters will not work, because that text will apply on every slide that uses the master and will not be editable by users. E.g., say I have a master, we'll call it 'MASTER A.' I put the following text on 'MASTER A':

Presentation Title
Subtitle

Customer Name

Case Study Text

Product Used


Now I have 5 customer case studies in my presentation; 1 slide for each case study. I create these 5 slides using MASTER A because that is the case study slide master design:

SLIDE 1
SLIDE 2
SLIDE 3
SLIDE 4
SLIDE 5

Now slide 1 is for customer 1, slide 2 for customer 2, etc. The slides for each of them will look like the following with uneditable text:

---

Presentation Title
Subtitle

Customer Name

Case Study Text

Product Used

----

I could go to the slide master and start filling that text out for customer 1. But then every slide, slide 1-5, will look like this:

---

Customer Case Study Report
Review session 4/30

ABC Company, Inc.

ABC company needed to weeble their sprockets and peep their pops. 

Product: XYZ Sprockulator

----

Well, so now we have slides 1-5 displaying text for customer 1. That makes no sense either.
Comment 3 Cor Nouws 2014-05-01 21:38:40 UTC
(In reply to comment #2)
> 
> SLIDE 1
> SLIDE 2
> SLIDE 3
> SLIDE 4
> SLIDE 5

Fields make particularly sense for information that is put on more then one place, or more then two.
So the given example with 5 slides and each different info for a special case, isn't a convincing argument for fields, is what I would say..
Comment 4 Máirín Duffy 2014-05-02 09:58:12 UTC
Hi,

Maybe my specific examples aren't dead on. But I have definitely worked with presentations that use the same information on multiple slides - such as the presenters' names, the customer name, the subtitle, the product name that the slides are about, etc. etc. etc.
Comment 5 Máirín Duffy 2014-05-02 10:07:31 UTC
Also please consider that whether or not a chunk of text is repeated on multiple slides or just the master slide, the fact that the text is not variable means that a designer cannot produce a template that accounts for that separate piece of information.
Comment 6 Cor Nouws 2014-05-02 11:11:14 UTC
Hi Máirín,

(In reply to comment #4)

> Maybe my specific examples aren't dead on. But I have definitely worked with
> presentations that use the same information on multiple slides -....

Of course. My comment was not at all meant to disagree with your request !
Comment 7 Rebecca Fernandez 2014-05-02 13:38:16 UTC
For me, this is about giving presentation designers expanded functionality and flexibility in Impress for designing more useful presentation templates, and it's a feature that they're accustomed to using in proprietary presentation software:

http://office.microsoft.com/en-us/powerpoint-help/add-a-text-placeholder-with-custom-prompt-text-HA010210725.aspx

http://help.adobe.com/en_US/captivate/cp/using/WSd160b5fdf5100e8f-a0ae387126564aa2e8-8000.html#WS3d71e636065aa5be-3048b96a126ae8d0d56-8000
Comment 8 M.Eng. René Schwarz 2014-12-28 11:11:02 UTC
I support this request for several reasons:

(1) The possibility to include custom fields will improve the flexibility of the creation of presentation templates as required data can be easily set using the File > Properties > Custom Properties dialog.

(2) An implementation in Impress could make reuse of the code base of the Writer implementation of fields and thus lower the efforts connected with the realization of this feature request.

(3) Since LibreOffice is seen as one software package from an end user point of view it makes sense to harmonize the features across the different LibreOffice components. That said, it is really not intuitive for an end user that the implementation of fields differs between Writer and Impress.
Comment 9 Cor Nouws 2015-08-12 21:06:17 UTC
OK.. already reported

*** This bug has been marked as a duplicate of bug 53548 ***
Comment 10 Máirín Duffy 2015-08-20 14:48:24 UTC
Cors, I really have to disagree that this is a duplicate of bug 53548 - that is a bug filed against Draw, not Writer, and involves Mail Merge of database content, whereas this doesn't involve database content. While the problem to solve is vaguely the same, that the applications are different should make them separate bugs, no?
Comment 11 Cor Nouws 2015-09-12 20:52:49 UTC
(In reply to Máirín Duffy from comment #10)
> Cors, I really have to disagree that this is a duplicate of bug 53548 - that
> is a bug filed against Draw, not Writer, and involves Mail Merge of database
> content, whereas this doesn't involve database content. While the problem to
> solve is vaguely the same, that the applications are different should make
> them separate bugs, no?

Hi Máirín,
53548 is  " Allow "Other" fields / DocInformation / custom editable fields in Draw/Impress (as in Writer)  " 

and the summary of this bug "  Allow custom editable fields as allowed in LO Writer "  Component Impress..

So I do not see a difference..
Comment 12 Xisco Faulí 2016-09-11 13:38:02 UTC Comment hidden (obsolete)
Comment 13 Xisco Faulí 2016-10-10 10:23:12 UTC Comment hidden (obsolete)
Comment 14 Cor Nouws 2016-10-11 09:49:09 UTC

*** This bug has been marked as a duplicate of bug 53548 ***