Feature Request: Assets Stored in Document/Template

[John Hind]

Hi,

The new templates feature is much appreciated, but some more features are needed to make it truly useful. I'll post these separately for easy tracking:

3. Option to store assets in Document/Template file. The existing global assets feature is useful, but sometimes assets are specific to a specific type of document rather than a specific user or group of users. It would be good if there was the option to specify assets as global or document specific. The latter would be stored in the document file and hence more usefully in the template file.

More to follow.

[Move Along People]

-

[John Hind]

How?

According to the help file, assets are global for a specific user (but can be exported and imported by another user). I want it so any user can create a document from a specific template and get assets saved with that template. These assets would be displayed along with any global assets the user had from the current system.

[Move Along People]

-

[John Hind]

Thanks, that works but is not quite ideal in the way it is implemented. It imports embedded assets into the user's assets collection (optionally) and does not remove them again when the document is closed. Ideally I would want the assets to be displayed and available while the document is open without the user having to choose to import them. The assets panel should separate 'document assets' from 'global assets' which would also make this feature more discoverable.

[John Hind]

Furthermore, it does not seem to be possible to delete embedded assets.  Now I tried this in my template file and deleted the asset again but I still get prompted to import assets every time I create a document from that template. Feature badly needs a re-think IMHO!

[Move Along People]

-
 

[John Hind]

22 hours ago, haakoo said:

It's not a viewer or a word processor.
 

You are not wrong. I've long been dissatisfied with the distinction between word processors and 'publisher' style apps. Lack of clear thinking about workflows has led to huge, unnecessary feature overlap between the two and important missing features in the gap. I hoped using 'publisher' would enable me to drop word processors altogether and in truth publisher just needs a few relatively trivial features to make that work. As usual, Microsoft has a lot to answer for as everyone is following their way of doing things rather than thinking about workflows.

I see two distinct professional document workflows:

A: The few-to-many workflow typical of book production or maybe catalogs, advertisements or static web sites.  Here an author produces text and passes it to a designer who lays it out to a publish-ready form. Then many people consume it.

B: The few-to-few workflow typical of business proposals, letters, low-volume product datasheets etc.  Here a brand designer and/or a business process developer makes a template which is passed to operations staff to fill in the content for many documents each of which will be read by just a few people.

The processor/publisher distinction seems designed mainly to serve A, but over time the processor part has suffered feature creep far into publisher territory, but not far enough to make publishers obsolete.

B is not well served at all because the template features of both processors and designers are under-powered afterthoughts.

Affinity's common file format offers a way forward. Just as there is Photo and Designer to prepare graphics assets which can later be laid out by Publisher, there should be a new Author tool used to prepare text assets, in the common file format, without all the distractions of layout and formatting (a simplified word processor). This could be used either starting with an empty file so the text would later be used in Publisher to complete the layout (type A workflow) OR it could be used to add the text to a pre-existing template produced in Publisher (type B workflow).

[Old Bruce]

2 hours ago, John Hind said:

Affinity's common file format offers a way forward. Just as there is Photo and Designer to prepare graphics assets which can later be laid out by Publisher, there should be a new Author tool used to prepare text assets, in the common file format, without all the distractions of layout and formatting (a simplified word processor). This could be used either starting with an empty file so the text would later be used in Publisher to complete the layout (type A workflow) OR it could be used to add the text to a pre-existing template produced in Publisher (type B workflow).

I could get behind this idea.

[thomaso]

On 5/3/2020 at 3:34 PM, John Hind said:

there should be a new Author tool used to prepare text assets, in the common file format, without all the distractions of layout and formatting (a simplified word processor). This could be used either starting with an empty file so the text would later be used in Publisher to complete the layout (type A workflow) OR it could be used to add the text to a pre-existing template produced in Publisher (type B workflow).

It seems you have an editorial system software in mind. Note that this would require to enable to work in 1 document by more than 1 user (author + designer), and ideally simultaneously. So, to enable true teamwork it needs a quite different and special handling of both file + UI/tool access rights and also requires special temporary memory management of all file data.

This complexity simply can not be achieved with a few additional features in the UI, as e.g. an improved asset panel or a separate text editor mode. That is why even Adobe developed that options many years after ID and with 1-2 additional, partially independent apps (id server + incopy).

Any solution without true teamwork capabilities will be of quite limited use and will end up in further feature requests. Only if it is ensured that the app's rights management allows and prevents the access according to the specific needs of a certain project it will work as expected. Imagine the author would be able to alter the designers layout and vice versa – in worst case without noticing from the others changes. Such a resulting chaos can get achieved with the current stage of APub already if you just let 2 people work in 1 file.

[John Hind]

On 5/5/2020 at 11:42 AM, thomaso said:

Any solution without true teamwork capabilities will be of quite limited use and will end up in further feature requests.

Yea, sucks to be a software developer! Case in point, they put in templates and now annoying people like me want them done right!

Simultaneous teamwork is certainly a harder case probably requiring re-architecture of the file format (unless they planned ahead for this). However waterfall workflow is a valid use case. In my case I actually wear both hats but it is useful for me to separate my work into template design followed by document design. This is because I will produce many documents from one template and this approach saves time, maximizes consistency and reduces cut-and-paste errors..