Affinity Publisher Beta Hands-On Review

Or How Design Behind Closed Doors Creates Disasters.

This is a mini review of Affinity’s highly anticipated DTP software, Publisher. Mini because it’s the first public beta

We’ll try using it to achieve a simple desktop publishing task — to create a few pages of a basic textbook — an share what we find.

Adobe Goliath v Affinity David?

Some context. Adobe has dominated the bitmap, vector and desktop publishing (DTP) sectors for decades with its Photoshop, Illustrator and InDesign the ubiquitous choices. Every competitor is compared to these, and often found wanting. Even when simpler cheaper and free tools will meet user needs, very often they opt for the expensive Adobe options.

What hope is there for Affinity?

  • Adobe’s code is decades old. That explains the huge resources required and poor performance. The software has accreted over decades. Affinity can craft modern lean software.
  • Adobe’s software is expensive. And then it became an eternal subscription making it even more expensive. Affinity can price their products reasonably, and avoid subscription.
  • Affinity can take the opportunity to undertake user research into what today’s users want to achieve, how they work, and craft tools that more efficiently and pleasantly meet these needs than trying to bend or twist Adobe’s megalithic software.

Affinity already have competitors for Photoshop and Illustrator, called Affinity Designer and Affinity Photo. Both of these are modern and fairly lean software. I have some experience with both creating diagrams and illustrations for books, presentations and teaching materials. Designer is intuitive and powerful — you find yourself creating high quality drawings with surprising ease. Photo sadly has a very poor user interface — with inconsistent ideas and confusing workflows — likely the result of trying to mimic Photoshop’s functionality.

At the end of August 2018, Affinity released the first public beta of Affinity Publisher, to eventually compete with Adobe Indesign.

Simple Task — Textbook Pages

The task is to create a few pages of a textbook.

A textbook doesn’t need an overly complex layout. In fact many authors successfully use word processing software like Microsoft Word and LibreOffice to create books. So why use DTP software?

Two key benefits of DTP are:

  • Typography and layout. A DTP application provides the ability to do much better typography — with finer control over things like spacing between letters, the ability to fit text to non-rectangular boundaries and making blocks of text fit nicely on pages without dangling orphans, for example.
  • Working at scale. A DTP application is not optimised for working on one page. You can use tools like Designer or Illustrator to design single pages to a high degree of accuracy. The key point of a DTP application is to make working with documents of 10s, 100s, even 1000s of pages easier. That means being able to change the style of a subheading and have that effect all such subheading throughout the document. Another example is being able to adjust the layout of text columns or frames once, and have all the 1000 pages adjust accordingly. This kind of indirection has made its way into consumer software — Microsoft Office has fairly mature text styles but undeveloped image styles, for example.

Let’s create a simple page layout like the following diagram:

The first thing to notice is that the left and right pages are not the same. There is a larger margin on the right of the left page, and on the left of the right page. This is common in bound publications to allow extra space for the binding itself. The pages have three main sections — a header for chapter titles, a footer for page numbers and a main text frame. The main body of text can have images or tables.

Nothing particularly complex or challenging here.

Let’s try it.

The above shows master pages set up as “facing” which means left and right pages can have a different design. You can see the page numbers at the bottom. The top frame has sample text, but isn’t a special field filled by the section or chapter title. The main body frame is linked so text flows from one to the next. So far so good enough for a first ever beta.

The app crashed at this point, but that’s expected in a beta.

Let’s create two actual pages based on this master page template.

The following shows the resulting pages. The first page is a right page which is correct. The text frames are visible, and the first right page has the larger inner margin — again correct. The page numbers are correct too. Excellent.

Let’s now add some text into the frame. I usually use a lorem upsum generator. Actually Publisher has a nice convenient built-in tool for generating sample filler text.

Typically we’d double click the frame to start entering text. Nope — that didn’t work. The frame appears in the layers panel — but selecting that doesn’t open it up for entering text. What’s that inviting blue rectangle for .. ?

After asking on the forums, it seems you can’t enter text into this blue rectangle that looks like the expected text frame inherited from the master template page. In fact you can’t use master page text frames as templates for normal pages.

This is a very major problem.

The established metaphor that DTP software has followed for years is that you use a master page to define elements which appear on all pages that are derived from that master page. You create invariants on the master pages. So text entered into the master page will appear on all pages. If that text is a special field, like a page number, then the actual page number is calculated and placed at that point on the real pages. We don’t enter the main body text onto a master page because its purpose is to be a design template. The design is the location and size of the text frames, not the text content.

This looks like a serious fundamental flaw. Perhaps Affinity have thrown off ossified orthodoxy and have a new better way of designing pages? I asked and apparently they don’t. The standard responce is to create text frames on normal pages and “copy and paste” them onto new pages. For 1000 pages?

This will be a deal breaker for anyone who wants to work with more than say 10 pages.

Ok, let’s go with it for now and add text frames on the normal pages. To have them line up we’ll have to add guide lines to our master pages.

Luckily these guide frames to have the desire effect on normal pages, allowing us to draw correctly aligned text frames.

Adding text to the frame works, but the overflow doesn’t go anywhere.

We’ll have to create a second frame manually on the second page, and link the frames to get the text to flow from the first to the second.

That’s rather manual, and not something we’d want to do for 1000 pages. Imagine created 1000 text frames, aligning them manually, and then creating 999 links between those frames to get the text to flow.

Publisher does provide us with something called Autoflow (shift-click text flow handle) which creates new pages with linked text frames until all the text can be displayed.

That sounds good. But…

Imagine we had 2 text frames on the left page, shown like this.

We’ve even linked the two smaller text frames to tell Publisher we intend to flow text from one to the next on that page.

Let’s see if Autoflow works…. it doesn't.

Trying other combinations of linking frames to get the correct autoflow that creates the 2-frame left page and 1-frame right page doesn’t work.

This illustrates why the long established and proven powerful idea of linked template text frames on a master page is actually useful.

Can we now change the size of the right page text frame so that all of the change? Nope. We have to change them all manually. Imagine if we had 10000 pages.


Better Beta

Myself and others have long encouraged Affinity to be engage the very enthusiastic community of potential users, to better understand their needs.

Many organisations have learned that design by a closed secretive committee doesn’t work — and leads to expensive disasters.

An open development process encourages participation and spotting issues before they become too established. Altogether it derisks the product for everyone.

Why wouldn’t you be open and engaging? Especially with a community that’s almost begging to support Affinity.

Instead we get Affinity posting arrogant messages further entrenching their closed committe mindset.

A beta is a feature complete product that needs final testing with users. An alpha is a set of experiments to test ideas to see if the ideas are viable. What Affinity have released seems to be alpha, and even then without having undertaken the user research to understand user needs, and discuss potential ideas to solve them.

Basic software product developement 101.

Publisher == Designer with Pages?

A key message some of us repeated to Affinity was not to produce a Designer with pages. With the lack of openness and engagement we had no clue what they were working on.

It seems that’s what’s been produced so far — Designer with pages.

The following text controls look familiar. They’re not from Publisher, but Designer, and look idential to the ones in Publisher. Reusing useful elements is fine, but it makes me wonder where all the effort went.

Let’s press on.

Embedding Images

Let’s add some images to our text. Novels rarely have images but textbooks have frequent diagrams as part of the narrative.

This isn’t something complex. All word processors that I know of can insert images into documents.

Exploring Publisher doesn’t seem to reveal am image frame. Perhaps it’s missing from this beta?

It is possible to “place” an image, just like you would with Photo and Designer. This results in an image placed onto the page, floating free.

There does not appear to be any way to anchor the image to the text so that the image moves as the text moves — because we might add words, adjust font size, tweak the size or position of text frames.

It turns out you can’t do this in this beta.

You can’t anchor images to text!

Pick any word processor — Microsoft Office .. Libreoffice .. all of them can do this.

Again a serious fundamental flaw — how can Affinity issue a beta that doesn’t implement this really basic capability. What else was higher priority? We’ll never know because Affinity works like a closed secret committee, and doesn’t do development in an open engaged way.

Product development like it’s 1985!

Imagine having to place 200 images into a 600 page textbook — not an uncommon ratio. Then imagine a small change at the start of the book caused the text to reflow. Who is going to adjust those 200 images manually again? This fails the “working at scale” function of DTP solutions.

Post Mortem

The message here isn’t about which features Affinity Publisher does or doesn’t implement, or how many it has compared to InDesign.

The message is this:

  • All organisations, no matter how successful, need to do user research to understand what their users’ needs are. Without this, products are designed based on assumed priorities. Understanding users allows you to be creative and innovative about how efficiently and pleasantly you meet those needs — a competitive advantage.
  • A closed development process is risky. If you have an enthusiastic community willing you to do well, why wouldn’t you have an open development process to take advantage of thousands of minds, testers, ideas, checks, suggestions, feedback, … Asking users for bug reports but not wider suggestions via the forums seems very narrow and very exploitative. Pay us to do your bug testing?
  • Affinity have not understood the basics of product development. A beta is a product know will meet user needs, and you’re testing it for bugs you might have missed. An alpha is where you test ideas that you think will meet user needs.

I leave this review puzzled as to what could have been more important than master page templates and anchored embedded images?

Did Affinity really just add pages to Designer? There is no evidence that Affinity understands DTP users — users working at scale.

Reforming Enterprise (Technology) Strategy for the 21st Century