I sometimes get questions from people asking why some particular layout-related aspect of UX Write doesn’t work the same way as in Microsoft Word or Pages. The answers all invariably come down differences in the approaches these programs take to layout — that is, the way in which they display the text you’ve entered on screen, and the level of control given to you over how this layout is done. Because UX Write is based on Safari’s layout engine, its capabilities depend entirely on what is possible to do on a web page, which excludes certain features like tabs, page breaks, footnotes [1], and columns [2].

Microsoft Word, OpenOffice Writer, and Pages are all based around the idea of WYSIWYG (What You See Is What You Get). This is a visual approach to writing, where the position of text and other elements in the document is remains unchanged regardless of how you are viewing the document, whether on-screen or in print. This model is appropriate for people who need precise control over exactly how their final published document will look, and want to have that layout control combined with text editing facilities in the same program. If you have these needs, then UX Write is not a good choice for you as it specifically does not attempt to provide a fixed layout, for reasons I’ve written about previously.

UX Write, HTML, Markdown, LaTeX, and LyX are based around the idea of WYSIWYM (What You See Is What You Mean). This is a structural approach to writing, where you add text, sections, subsections etc. in an abstract manner, and the way in which they are actually displayed depends on the circumstances in which the document is being viewed. Often referred to as the separation of content and presentation, this model is appropriate for people who care only about the content of their writing, and are happy for the presentation to be tailored to suit the output device (tablet, phone, desktop, print), subject to some level of customisation (such as fonts and colours) defined in a stylesheet. If you have these needs, UX Write is really your only choice on the iPad right now — I’ve still yet to see another app which properly supports even styles, not to mention automatic numbering, table of contents generation, and other features that depend on structural information.

You use this latter model every day when you browse the web. Well-designed websites [3] will wrap their content to the width of your browser window or your phone/tablet screen, and this will change as you resize your window or rotate your device between portrait and landscape. On some desktop browsers, you can also change the font size to what is most comfortable for you to read. E-book software like iBooks and Kindle also follows this model. If you’ve ever tried to read a PDF document formatted for a full-size A4 page on your iPhone or iPad mini, you’ll undoubtedly have been frustrated by the small text and excessive scrolling; reflowable text avoids this.

Neither the visual or structural approaches are inherently “right” or “wrong” — everyone has different needs, and you should pick the app that’s right for you. UX Write is very much built around the structural approach, because it’s intended for long-form technical and academic writing, though is useful in many other contexts as well.

I realise now that the current messaging on the app’s website is too ambiguous — it compares UX Write to Pages, which I now think is a pointless comparison given that they’re designed for different types of users. I’ve actually found it quite a challenging task to communicate what UX Write is to an audience unfamiliar with the structural writing approach, and the app often gets judged badly when measured on those grounds. As part of a larger rebranding exercise I’m working on with a colleague of mine, I plan to redo the website to try and clarify the app’s focus on technical and academic writing, and make the differences from visually-oriented word processors clearer.

[1] Though they can be “faked”, like this

[2] Columns have actually been added recently to the web standards, but without pagination, placing an entire document in columns would cause the second column to start half-way through the document. The reader would need to scroll down the entire first column, then right back up to the top, before they can read the second column. That’s not good.

[3] And I don’t consider this blog particularly well-designed, though the latest WordPress update does seem to finally implement text wrapping when you resize the window, and it’s readable on an iPhone without zooming.