AutoFlow discoverability and configuration

[MikeTO]

Users keep asking about why Publisher doesn't flow text automatically like other apps. This is because the AutoFlow feature isn't discoverable - the Text Flow Out control must be Shift clicked so new users have to read/watch instructions or seek help.

I never use AutoFlow because it breaks my documents but the suggestions below would address all of these issues.

Add setting for automatic AutoFlow: Most apps have an on/off setting for auto flow and when selected will auto flow text without needing to click a control like Publisher. Those apps can also delete blank pages automatically. Publisher doesn't delete unneeded pages so to keep this simple, I suggest adding an "Automatic AutoFlow" checkbox to settings, selected by default, that would prompt the user to automatically auto flow when text is overset. In a perfect world, the alert would include a "Don't show this again" checkbox that would disable the setting without having to visit settings, to avoid annoying experienced users.

Add setting to limit AutoFlow to master page frames: The current feature is manual so pages are never created accidentally, but if the automatic option was enabled, it could get annoying when you temporarily overset a small text frame while editing an image caption. This is why ID limits the feature by default to primary text frames. Publisher doesn't have a primary frame feature but a similar option to limit it to master page frames would be nice. It should limit it to true master page frames, not to text frames pinned inline in master frames.

Add setting to always add pages at end of story: AutoFlow correctly creates pages at the end of a section instead of at the end of a document which is great for those who use sections. For those who don't and who use separate stories for each "chapter", Publisher really needs an End of Story option because otherwise the new frame will be created at the end of the document, potentially hundreds of pages later. ID offers three options: End of Story, End of Section, and End of Document but Publisher does a great job of automatically choosing End of Section versus Document so I think it only needs a checkbox named "Always add pages at end of story".

Add setting to preserve spreads: You might not want a single page to be added because it will mess up your perfect spreads which is why ID offers its "Preserve Facing-Pages Spreads" option. This option adds full spreads and not single pages and would be a good enhancement for Publisher.

Support multiple stories per page use case: When auto flowing a document page frame, if a single text frame exists on an existing page, AutoFlow will skip that page. This makes it impossible to use AutoFlow for both stories in a side-by-side layout (e.g., a Bible translation). AutoFlow could instead check if the new frame would overlap with an existing frame on the page. If it would overlap, create a new page, but if not, then create the frame on the existing page.

Fix issue with non-master frames created on top of master frames: When auto flowing a document page frame, if a single text frame exists on an existing page, AutoFlow will skip that page. But it will create a frame on an existing page with a large master frame full of text - the end result will never be usable. It would be better if autoflow also checked for text names in master page layers.

Thanks

Edited January 5, 2024 by MikeTO
Added the multiple stories use case

[fde101]

Why not make "autoflow" a property (checkbox) of the text frames?

Not only would that solve this problem but it could also connect separate frames from the same page which are also set to autoflow so that if you have parallel stories which are independent of each other but which both span a shared set of pages (ex. a parallel bible where there are two different bible translations side by side in columns but each spanning the same set of pages) then both sets could be connected with themselves (but not each other) automatically as pages are added.

[MikeTO]

1 hour ago, fde101 said:

Why not make "autoflow" a property (checkbox) of the text frames?

Not only would that solve this problem but it could also connect separate frames from the same page which are also set to autoflow so that if you have parallel stories which are independent of each other but which both span a shared set of pages (ex. a parallel bible where there are two different bible translations side by side in columns but each spanning the same set of pages) then both sets could be connected with themselves (but not each other) automatically as pages are added.

I'm glad you pointed this out. There's a really simple solution for the side-by-side use case which I didn't provide a suggestion for. I'll edit my post above to add that. I'd prefer to avoid having autoflow as a frame property, I think that might confuse users.

[MikeTO]

I added this to my first post:

Support multiple stories per page use case: When auto flowing a document page frame, if a single text frame exists on an existing page, AutoFlow will skip that page. This makes it impossible to use AutoFlow for both stories in a side-by-side layout (e.g., a Bible translation). AutoFlow could instead check if the new frame would overlap with an existing frame on the page. If it would overlap, create a new page, but if not, then create the frame on the existing page.

[fde101]

51 minutes ago, MikeTO said:

I added this to my first post:

Support multiple stories per page use case: When auto flowing a document page frame, if a single text frame exists on an existing page, AutoFlow will skip that page. This makes it impossible to use AutoFlow for both stories in a side-by-side layout (e.g., a Bible translation). AutoFlow could instead check if the new frame would overlap with an existing frame on the page. If it would overlap, create a new page, but if not, then create the frame on the existing page.

This behavior would break if the frames were on a master page.

 

Try this: in a new document, put two text frames on a master page.  

Go to the document page and paste a large amount of text into each of the two frames.

Auto-flow one of them.  You wind up with X number of pages, each with text in the frame you auto-flowed, and on each page a blank frame that came from the master.

Thankfully, the existing feature is smart enough to link the frames when you auto-flow the other one - it does not create new pages as long as you do it right away without putting content in the intervening frames (if you do, then auto-flow creates new pages at that point instead of reusing the existing ones, which is understandable but also undesirable).

Making this a property opens the possibility of having the frames pre-connected when any auto-flow activity takes place, which has the benefit of reducing the likelihood of a user accidentally putting something in one of the intermediate frames and disrupting a later auto-flow at that point.  It could also be pre-rigged and tested in a template.

[Bit Disappointed]

3 hours ago, MikeTO said:

Users keep asking about why Publisher doesn't flow text automatically like other apps. This is because the AutoFlow feature isn't discoverable - the Text Flow Out control must be Shift clicked so new users have to read/watch instructions or seek help.

There's plenty of material for usability changes in this section alone.

[MikeTO]

1 hour ago, fde101 said:

This behavior would break if the frames were on a master page.

it would today, but see the final paragraph in my suggestion. It should check for frames on the master layer, not just the document page layers.