UX Write is no longer available

Posted on by

I’ve recently removed UX Write from the app store. Unfortunately it’s been a complete commercial failure. For the last two years, it’s been bringing in just a few dollars a day in revenue, which is nowhere near the level that would would make it viable for me to continue development work. Because of this, I’ve long-since moved on to other paying work, and have not had the time or energy to continue maintenance of the app.

There are two main reasons I’ve decided to remove it from availability now:

  1. Every new iOS version breaks the app in some significant way, requiring a non-trivial amount of effort to work around the new bugs/API changes Apple have introduced. iOS 10 is on the way, and Dropbox have recently announced they will be dropping support their version 1 API, which UX Write relies on. Unfortunately as a result of this, UX Write will be unable to communicate with Dropbox after their API sunset date of June 28 2017. Implementing support for the new API and carrying out thorough testing with iOS 10 would involve more effort than I’m willing to invest now, particularly since it’s not going to change the revenue situation.
  2. I still receive occasional support requests for the app, most of which relate to bugs that would require a significant amount of effort to fix. I also sometimes receive requests for new features. As much as I’d love to continue improving the app, I can’t do it for (essentially) free, particularly when experience has shown that it’s first and foremost marketing that determines the success of an app, and almost every feature I’ve added over the course of the UX Write’s development (such as internationalization and LaTeX support) has resulted in no increase in sales.

I know there are a small number of dedicated fans of the app who use it regularly, and all I can say is I’m sorry it hasn’t worked out – no-one is more disappointed about this than me. However, I feel it’s not fair to ask new users to pay for an app which is no longer being maintained, and contains bugs that will never be fixed.

There are other alternatives available that I recommend. Microsoft Word is a good choice for most people, and although I strongly dislike it’s philosophy towards document authoring, it seems to suit the needs of the majority of the market (most of the complaints I’ve received about UX Write have stemmed from a lack of understanding of what the app is about – that is, structured writing – from people who have expected it to work just like Word). For those who are after something specifically designed for structured writing, I recommend the recently-released iOS version of Scrivener – which follows a very similar approach to UX Write to organising content. On the desktop, either Scrivener or LyX are great choices.

Some time ago I open sourced some components of UX Write – specifically the file format conversion library (written in C) and core editing code (written in TypeScript) in what became the Corinthia project. The code is available at https://github.com/corinthia – it’s not actively maintained right now, but hopefully may be of use to someone. For details on Corinthia you can see a couple of talks I gave about it here and here.

Designing for mobile first

Posted on by

When I began developing UX Write, I never consciously thought about having to do anything “special” to get it running on mobile. Initially on Android, but after a short period moved to iOS, it began much like the development of any other mobile app — I just used the tools available to implement the functionality I needed. Specifically, these tools were:

  • A system-provided version of WebKit
  • Native support for parsing and rendering HTML
  • A JavaScript runtime environment with access to the DOM
  • System-provided APIs (UIKit) for building a native user interface

The result was something that felt like a native iPad app because it was a native iPad app. All of the toolbars, menus, and so forth utilised the built-in user interface components provided by the platform, and I tried to follow Apple’s iOS human interface guidelines as closely as possible. It just seemed like the natural thing to do.

Only after UX Write was on the app store did I start learning about other attempts to achieve the same end result but based on ports of existing desktop suites, such as Microsoft Office and OpenOffice. Most of these efforts fall into one of the following two categories:

  1. Remote access clients to a server-hosted version of a desktop office suite, basically using the iPad as a remote desktop or VNC client. Examples include CloudOn and Documents Unlimited.
  2. Native ports of a suite to mobile. These are much rarer; there’s an Android port of OpenOffice, and reportedly an in-progress port of LibreOffice as well. On Windows 8 tablets, such as the Surface, Microsoft made available a version of Office that was effectively identical to the desktop version, right down to the same menus, dialog boxes, and other UI elements.

Both approaches are fundamentally flawed.

The first requires a fast, reliable Internet connection, which even those of us who live in major metropolitan areas don’t have 24/7 (think traveling or going out). The second, as well as the first, squeezes far too much onto a tablet screen to provide something usable. Desktops and laptops have larger screens and more precise pointing devices (mice & trackpads), but the combination of a small screen and fat fingers does not lend itself to tiny little checkboxes, buttons, and scroll bars.

Remote access to OpenOffice on an iPad, complete with scroll bars, windows, and a mouse pointer

Remote access to OpenOffice from an iPad, complete with scroll bars, windows, and a mouse pointer (Documents Unlimited)

On mobile — especially on phones, but also tablets — you don’t have the luxury of being able to fill up the screen with innumerable buttons and other widgets. You must be judicious in your use of screen real-estate, and design an interface hierarchy that avoids unnecessary duplication and moves all but the most important options into sub-menus or alternate screens.

There’s a long tradition of mobile-first productivity apps that began well before the emergence of the iPad and Android tablets. Platforms like the PalmPilot, Windows CE, Symbian, and Blackberry all had various apps available for them which provided a subset of the functionality of their desktop counterparts. Notable among these were Documents to Go and QuickOffice, which both made it across from these more limited platforms to iOS and Android, though still retaining their fairly minimal feature set. Since the iPad appeared, a large collection of writing apps have followed in their footsteps — that is, being targeted at mobile, not desktops. UX Write is among this latter group, though closer to the desktop-level feature set than most others.

UX Write on iPad

UX Write on iPad

When Microsoft finally released Office for the iPad, they did something I didn’t think they were capable of: They actually started from scratch with a new UI implementation, completely abandoning the desktop interface present on Windows and the Mac. I specifically use the term implementation here, as the design is closely based on the ribbon used in the desktop versions Office, to provide a familiar experience. But by starting with a new implementation instead of trying to do what would have been terrible port, and by reusing the core rendering and file format support that make up the Mac version of Office, they ended up with a product that is actually pretty decent to use on mobile, though sadly some rather important capabilities like custom styles and tables of contents did not make it across.

As I look towards the future of UX Write, which most likely involves an expansion onto not just other mobile platforms but also desktop and web, I’ve gained an appreciation for the benefits that starting from scratch — and building an app in a flexible and portable way — can provide. The architecture of UX Write is such that there are several components that can be taken more or less verbatim and, with a few compatibility adjustments, made to work on other platforms. Each port needs it’s own distinct user interface design appropriate for the platform — the Mac version of UX Write I spent some time prototyping a while back provides a native OS X user interface, which is not the same as the iOS version. But the core code is able to remain the same.

As much as I’d like to claim I planned all this deliberately, I can’t — it’s simply a natural outcome of developing for mobile first, and keeping open the possibility of an Android port in addition to the current iOS version. After seeing the results of other efforts to take large, legacy codebases designed for desktop systems and bring them to mobile, I think I took the right approach.

I believe that the best way to future-proof an application is to build it in terms of a small number of core, portable libraries with minimal dependencies; then, for each platform, build a native application layer that ties them all together and follows the user interface conventions of the host platform. This leaves open the possibility of porting to other platforms (including other classes of platforms — desktop, mobile, and web) with less difficulty than with monolithic architectures. It also allows for the provision of a high-quality user experience that matches what users expect from a native app.

Change Tracking & Version Control – Part 1

Posted on by

This post is the first in a series that outlines my views on the problem of versioning in word processors. I’ll update this post with links to subsequent posts as they’re published.

When multiple people are collaborating on a document, it’s a common requirement for a given person to be able to see what changes others have made, and to approve, reject, and comment on those changes. There’s two main approaches to doing this.

The first approach is change tracking. This involves storing all the content of the original and modified versions in a combined form within a single file, with markers present to indicate where insertions and deletions have occurred, and by whom. The files are often sent around via email, which is simple to work with and understand. Change tracking is well-supported by Microsoft Word.

The problem with change tracking is that you can easily end up with multiple versions of a file laying around on different people’s hard drives, email inboxes, and network shares, and it’s not always obvious which is the “latest” version. Furthermore, if the author of a document makes further changes after sending a previous version out for review, then the modified versions they get back from those they have sent it to are often not easy to integrate into the author’s own updated version. In practice, any time you have multiple people working on a document concurrently, this problem can arise.

The second approach is version control. This involves storing multiple versions (or revisions) of the file as a whole, without any information about changes included within the document versions themselves. Rather, this information is stored separately in a repository – a database which stores all individual versions of a document, and the derivation relationships between them. Popular version control systems include Git and Subversion.

Determining what changes have been made between different versions can be done automatically by software. Tools such as ‘diff’ take two documents as input, and output a description of the changes that have occurred, in a format equivalent to what one might see in a document containing change tracking information. Where there are two or more versions derived from the same original, a process called a three-way merge can be used to incorporate all the changes, potentially marking some parts of the resulting document as “in conflict” because two mutually-exclusive changes have been made to the same part of the file.

While change tracking is the conventional approach for word processing, version control is the conventional approach for software development. The latter is significantly more powerful, due to the needs of developers — it’s not uncommon for there to be tens or hundreds of people involved with a project containing many thousands of files. This requires sophisticated tools and a higher level of skill to work with, but is inherently necessary for the task at hand (try to find a software company or open source project that doesn’t use version control in some form). The same principles can  — and I argue, should — be applied to word processing documents. Version control provides a solution to the problems with change tracking mentioned above.

In part 2, I’ll discuss the two types of version control — linear and non-linear — and how they correspond to the workflows people typically use when working with word processing documents.

Announcing UX Write 2.0

Posted on by

After six months of work, it’s great to finally have version 2.0 of UX Write done. There’s some significant changes in this version, and most importantly, a new pricing model.

Try out UX Write for free

UX Write is now available via the “freemium” model. The basic edition, which can be downloaded for free, provides the core essentials – creating and editing HTML and Microsoft Word documents, syncing with various cloud services, and basic formatting like bold, italic, underline, lists, plus images and tables. It also includes heading styles and the outline view for navigating documents.

The professional edition, available via either a subscription or purchase option, has everything else. This includes custom styles and formatting, print/PDF export, structural features like a table of contents and cross-references, plus editing tools like find & replace, spell checking, outline editing, and word count (see the app website for full details).

You can upgrade to the professional edition via in-app purchase. There are two ways to go: you can buy the app straight out for $25, which is the same as the previous price. Alternatively – and this is what I recommend if you want to try it out for a while – is to subscribe at $1/month. Subscriptions are renewed manually, so you can decide at the end of the first month to extend your subscription or purchase the app if you feel it’s working well for you.

If you’ve bought UX Write prior to the release of 2.0, you automatically get access to the professional edition – there’s no extra payment required.

Updated look & feel

Version 2.0 introduces a brand-new visual appearance, courtesy of a new member of the team, Ian Weatherseed. Both of us have put a great deal of thought into how to best represent what the app is about, and how to make the overall experience more intuitive. Ian has a very different background to me – being much more oriented towards to the human rather than technical aspects of a product, and I’m pleased with the results of his work.

First of all is the new logo and icon, which unlike the old, skeuomorphic one, doesn’t appear completely out of place on an iOS 7 home screen:

UX Write 2.0 - Logo

Next is the colour scheme and background, which are designed to make the app stand out from the plain iOS 7 defaults. These were some difficult decisions, and I know it’s going to generate some controversy, but overall the feedback on it has been pretty good, though it might take a little getting used to.

The file manager has also been reorganised so that the set of storage locations (local storage and cloud services) is now on a separate screen to the folders where you store your files. This means less clutter when browsing a folder, and a more intuitive setup experience on first launch, where you start off with the following screen:

UX Write 2.0 - Locations

Google Drive and OneDrive support

Microsoft made a big splash with the introduction of Office for iPad, but unfortunately decided to only support their own cloud service, OneDrive. Google did the same thing when they bought QuickOffice, even going so far as to remove support for Dropbox.

UX Productivity is not in the cloud business and has no incentive to do something as dumb as this. I really don’t care what you use – the only limiting factor on the number of services supported by UX Write is the development effort required to support each one, as each has a different API and slightly different way of doing things. But I believe that choice is very important, so you’ve now got two extra options: Google Drive and OneDrive.

UX Write 2.0 - Google Drive & OneDrive

In fact, if you have all your files on, say, Dropbox or Box, and wanted to use them with Word on your iPad, you could download the free version of UX Write and use that to copy them across, and then switch over to Word to work on them. Or… you could just use UX Write itself 😉

Footnotes and Endnotes

By popular demand: You can now use footnotes and endnotes in your document. This has only become possible now because of the LaTeX support (see below) required to typeset them properly. HTML itself provides no way to place footnotes at the bottom of the page (since HTML has no concept of pagination), so they’re displayed in-line during editing, as shown below:

UX Write 2.0 - Footnotes and endnotes

If you typeset your document using LaTeX, then the print or PDF output will have the footnotes positioned correctly at the bottom, and the endnotes will appear at the end of the document. If the file you’ve created is in MS Word format, then they will also appear in the expected place when you view the document in Word.

Moving & copying files

I’ve written before about the complexities of moving files and folders in the context of file synchronisation. UX Write has been designed to work entirely offline, and there’s some rather obscure things that can go wrong if the same item gets moved around to different places on separate devices, and later synchronisation runs into conflicts – or, even worse – loss of data. This is the reason that moving and copying hasn’t been supported until now.

There’s been a lot of demand for these features though so I’ve now implemented them in such a way that avoids these problems by performing the operations synchronously. This means that in order to do a move or copy you have to be connected to the Internet at the time, and the app will send a request to the server to carry out the transfer, and force you to wait until it’s completed. This is a simple solution that avoids the risk of data loss, and I think will suffice in the vast majority of cases. Uploads still happen in the background as usual, and you can still do everything else offline.

UX Write 2.0 - Moving files

LaTeX typesetting

Finally – and this is a big one – UX Write now includes a built-in port of LaTeX (based on XeTeX) that runs directly under iOS. If you go into “Typesetting” under the settings menu and select LaTeX, then when you tell UX Write to print or generate a PDF, the app first translates the HTML representation of the current document into LaTeX source, and then runs that through LaTeX to produce a PDF:

LaTeX1000

While the current LaTeX support works for simple use cases, I still regard it in many respects as an experimental feature. There’s lot of aspects that I’ve yet to get working properly, including font support for non-English languages, plus import of files in .tex format – currently the LaTeX support is limited to PDF output only. As with everything else in UX Write, this is an evolving codebase that takes time to get right. In future updates, you’ll see support for equation editing, BibTeX, importing files, extra page layout options, and more.

Try it out today

With the new basic edition now available for free, there’s no longer any reason not to give UX Write a try. If you’re new to the app, you’ll be able to get a pretty good understanding of what it’s like to use, and there’s no time limits or third-party advertising there to annoy you. The only difference between the two editions is the set of features available. And if you do decide to try out the professional edition, you can sign up for a month and see how you go, before deciding if you want to continue subscribing or purchase the app.

Download on the App Store now

How to find the UDID of your iPad or iPhone

Posted on by

Beta testing of iPad and iPhone apps is normally done via ad-hoc distribution, whereby the apps are distributed directly from developers to testers, instead of via the app store. However, because Apple normally only permits apps to be installed from the app store, it’s necessary for the developer to explicitly include a list of device identifiers in the beta version of their app, which allows the app to be installed on those devices. These identifiers, called UDIDs, must be registered with Apple; each developer is allowed up to 100 registered devices for testing purposes.

To install an app via ad-hoc distribution, you must send the UDID of your device to the developer. You can determine your UDID by plugging the device in to your computer, going into iTunes, and looking at the top of the “Summary” screen.

Initially this will show the serial number of the device, which is not what you want. To find out the UDID, click on the serial number and it will change to show the UDID instead. To copy this to the clipboard, control-click on the UDID and select “Copy”. You can then paste this into an email to the developer.

UDID

Can’t this be done from the device itself?

No.

There used to be an app called Ad Hoc Helper which you could run directly on the device. It would retrieve the UDID and allow you to email it directly. However, in iOS 7, Apple introduced restrictions that prevent apps from determining the UDID, as it was being used by some apps to uniquely identify users for advertising purposes without their consent. While the change is a good thing for privacy, it means that Ad Hoc Helper no longer works (in fact it has been removed from the app store).

If you are a developer and receive a UDID from someone who uses the app, you’ll get what looks like a valid UDID but actually isn’t. iOS feeds a bogus UDID to the app, which begins with the string “FFFFFFFF”. If you add this to your provisioning profile, it will not work, as it’s not the true UDID of the device. The person installing it will either get an error message, or the installation will just silently abort once it’s nearly complete. So make sure that you only use UDIDs obtained through iTunes in the provisioning profile, and avoid any that start with “FFFFFFFF”.

Coming soon: LaTeX support

Posted on by

The most important new feature in the upcoming UX Write 2.0 release is support for typesetting your documents using LaTeX. It’s been a major effort to implement this, and the full benefits will take some time to materialise (see below). Nonetheless, this sets the stage for a lot of great new features important for academic and technical writing, which will be added in subsequent 2.x releases.

I’m looking for beta testers for this release; if you’re interested, let me know.

What is LaTeX?

LaTeX is a file format and typesetting system designed for producing high-quality print output suitable for publication in books and academic journals. The file format is similar in nature to HTML; it can either be written by hand, or exported from a visual editor such as LyX. The typesetting system is based on TeX, which implements sophisticated typography including hyphenation, ligatures, and kerning, as well as beautifully-rendered mathematical equations. The result is print and PDF output that looks just great.

LaTeX has been the de-facto standard in many scientific and technical disciplines for decades. In the business world however, it’s not so well-known. But like switching from Windows to a Mac, or from working an office job to being a digital nomad, there’s just no going back once you come to appreciate the benefits. I’ve used LyX and LaTeX for my PhD thesis and all of my research papers, and like most people in my field, would never even contemplate anything else for a formal publication.

LaTeX comes to UX Write

From the very beginning, the design of UX Write has been driven by my desire to have something like LyX on the iPad. As much as I like the output of LaTeX, I don’t like writing the markup by hand; I find it much less distracting to have a visual editor where I can see headings, lists, bold/italics and so forth without special syntax. LyX does this on the desktop, exporting to LaTeX and producing a PDF identical to what you would get if you’d written the LaTeX source in a text editor. I’ve always wanted this same functionality in UX Write, but like most features, it involves an incredible amount of time and effort to implement.

Finally, after months of work, I now have a functioning port of LaTeX running under iOS, and integrated directly into UX Write. I’ll discuss the challenges I had to overcome to get this working in another post, but for now the key point is that this will be included in the upcoming 2.0 release.

First successful on-device typesetting run

The first successful on-device typesetting run

Why is this important?

Even if you’ve never heard of LaTeX before or aren’t obsessed with typography, this work is a huge step forward for UX Write because it lays the groundwork for many features people have been asking for but I haven’t been able to provide with the current WebKit-based PDF output. These include:

  • Footnotes
  • Headers and footers
  • Page breaks
  • Custom page layout
  • Cross-references to specific page numbers
  • Bibliography and citations

To be clear — these features won’t be in 2.0: the LaTeX integration has only been working for a few weeks, and I have a great deal more work to do in order to add all this functionality to the editor and convert these elements from the HTML (used internally by UX Write) to LaTeX syntax. And for the time being at least, LaTeX support will be export-only; parsing and conversion to HTML for editing is whole other story.

However, the hard part is now done, and you can expect to see these features gradually appearing in updates throughout the 2.x release cycle. In the initial 2.0 release (which will be a free update for all existing users) you’ll be able to get LaTeX typesetting with basic formatting for English documents, both when printing and exporting to PDF.

Tabs and multiple spaces

Posted on by

I often get questions about why UX Write doesn’t allow you to insert tabs into a document, or place multiple spaces after a period. Some people have also asked about why existing tabs in a Word document show up as a grey [tab] marker. In this post I’m going to explain why this is.

UX Write uses HTML – the language of the web – for displaying and editing documents. When you open and save a Word document, UX Write converts it to HTML and back again. The HTML content is displayed on screen using a software component called WebKit, which is the same layout engine as used by Safari (and formerly Chrome). Every document you edit in UX Write is quite literally a web page; the only difference with a web browser is that your document is stored locally on your device, not published online.

HTML provides a slightly different set of layout features to Word. While most features can be converted back and forth without problems, there are some features present only in HTML, and some present only in Word. Thus, UX Write can never provide a 100% faithful rendering of all Word documents, and doing so has never been a design goal.

I chose HTML partly because it’s so widely used – as the foundation of the web – and partly because it enabled me to use an existing layout engine, rather than spend years writing my own. HTML is also much better designed than Word, and with a minimal amount of training a person can reasonably read and write HTML code directly. This is not the case with Word documents.

Tabs

HTML doesn’t support tabs. There’re simply not used not the web.

While I’m not sure of the exact rationale for the W3C (who designed HTML) to exclude tab support, I suspect the reason is because it’s unnecessary, in the sense that everything you can achieve with tabs you can also achieve without.

There are two main use cases I’m aware of:

1. Paragraph indentation. This can be achieved in both HTML and Word by changing either the left margin or text indent formatting properties of the paragraph or style.

In UX Write, go into the formatting menu and then either direct formatting or the style manager, and set these as appropriate. I recommend creating a style for the indented paragraph, so that you can do this again easily by selecting the style from the formatting menu, and later adjust the amount of indentation if you so wish.

2. Tabular data. This can be achieved in both HTML and Word by using tables, either with or without a border. Instead of adjusting tab stops, you adjust column widths. Instead of setting the alignment of a tab stop, you set the alignment of a table cell or column.

Even better, with tables it’s possible to create a custom style that defines the horizontal alignment, vertical alignment, and border appearance once and then use this for all tables in your document, so you don’t have to go formatting each manually.

Unfortunately UX Write doesn’t support customising table formatting at present, but this is coming in the near future. However, any customisations you make in Word will be retained by UX Write. I’m also considering providing the ability to convert tabs to a combination of indented paragraphs and tables when the app encounters a document containing these, so you don’t have to do so manually.

Multiple spaces after a period

By default, HTML collapses all whitespace in the source file, which means that any consecutive sequence of one or more spaces or newline characters in the HTML code is displayed on-screen in the same way as if there were a single space. If you view the source of a HTML document, you’ll typically see that a single paragraph is actually spread over multiple lines, e.g.:

<p>Here is a HTML paragraph. Its
content spans multiple lines in
the source file, for convenience of
editing in a text editor, but the
author's intention is to have it
displayed using word-wrapping according
to the user's browser window size.</p>

In a sense, HTML considers a sequence of space and newline characters simply as an instruction: “Don’t put the surrounding characters next to each other”. In fact, if you use justified text, the amount of space between different words will vary, as the layout engine will space the words out appropriately to ensure that both the left and right edges of all lines except the last line up with the left and right margins. In HTML, and most other file formats, spaces are not a fixed width character, and two spaces are considered no different than one.

While I’m aware of the controversy surrounding the “one space or two after a period” debate, I think it’s a pointless one. This problem was already solved more than 30 years ago by Donald Knuth when he created TeX, which automatically adds a small amount of additional whitespace between sentences, and gives higher priority to inter-sentence spacing than to inter-word spacing when it needs to stretch out a line when performing justification. If you really care about typography this much, you’ll already be using a system like TeX or LaTeX to prepare your final publication-ready output. The image below shows the same two sentences as typeset by LaTeX, Safari, and Microsoft Word; in all three cases, the text was entered with only a single space after the period.

Sentence spacing

The good news is that built-in LaTeX typesetting is coming to UX Write in the very near future. Most of my development effort over the past couple of months has been in porting LaTeX to the iPad, and when this work is complete you’ll be able to take advantage of the beautiful typographic output it produces when printing or generating PDF files, producing much more professional-looking results than is possible with Word. Stay tuned for more on this.

Why does typing two spaces insert a period?

The iOS text entry system has a built-in feature, which I believe is on by default, that allows you to type two spaces in succession to get a period, as a shortcut mechanism. This is an option which can be configured under the in the Settings app, under General > Keyboard > “.” Shortcut:

Period shortcut

While you can turn this off on a system-wide basis, the setting only applies to apps which use Apple’s built-in text entry mechanism (which most do). However, for apps like UX Write that provide their own text input handling, changing the setting has no effect. Unfortunately, to the best of my knowledge Apple do not provide any mechanism by which apps can determine whether this setting is on or off, so it’s not possible to automatically adjust the input behaviour based on this.

UX Write re-implements this feature itself, to match the behaviour seen in other apps when the setting is on. Before I implemented this, I received a number of complaints about the fact that it didn’t add the period after pressing two spaces, which is why I added support for it. Since then, I’ve received only a handful of complaints about the fact that it does add a period, so of the two options I’ve concluded that it’s better to have it on. This also seems to make sense given what I’ve discussed above about the inability (and pointlessness) of typing multiple spaces manually in a document.

Understanding Layout in UX Write

Posted on by

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.

Moving Files and Folders

Posted on by

(or “Why File Synchronisation is Hard”)

One of the questions I get asked most often is why it’s not currently possible to move files or folders in UX Write. While this might seem like a very simple feature to add, there’s actually a lot more to the story, due to the need to ensure reliable file synchronisation in which no data loss can ever occur.

Normally, this is all handled by the operating system and third-party sync clients like that provided by Dropbox. However, Apple made the tremendously unfortunate decision to exclude any notion of a user-visible filesystem on iOS, so this isn’t possible. Desktop operating systems have had built-in file management capabilities for more than thirty years, and everyone who’s ever used a personal computer is familiar with the concept of organising their files into different folders.

While unnecessary for casual usage like browsing the web or playing games, file management is absolutely critical for content creation and management; its omission from iOS cripples the iPad as a productivity device. Nonetheless, it is possible for individual app developers to work around this limitation, but doing so is highly non-trivial in the case where synchronisation with an online file storage service is needed.

For the developer, moving files locally on a device is trivial to implement. There’s programming interfaces built in to the operating system to do this, and it’s a simple task to create a user interface for selecting the files to move and their destination. The difficulty lies in synchronising those changes with a server (or “The Cloud”, if you prefer that term) in such a way that guarantees no data gets lost in the process.

Clients and server

With online storage services, it’s possible to have multiple devices and people with access to a particular account. Software like the Dropbox desktop client, and UX Write itself, allow changes to be made to files while you are offline, and then later push those changes to the server. However, cases can sometimes arise in which different people have changed or moved the same file or folder while offline, and then later reconnect to the Internet and sync with the server. This is where things can go disastrously wrong, if conflicts are not handled carefully by the software.

An Example

Suppose Bob and Alice have access to a shared account, and are working with the same set of documents relating to a particular project. Both are working offline, when Bob decides to move a folder to a different location and Alice simultaneously makes some changes to a document inside that folder.

When they subsequently reconnect to the Internet, their iPad or PC will try to sync with the sever. Whoever happens to sync first will “win” and have their changes applied to the server successfully, while the “loser” will run into errors, with the server reporting that the folder doesn’t exist any more.

If Bob wins, the folder will be moved, but when Alice’s device tries to upload her modified version, it will encounter an error because the folder it was in no longer exists at its previous location. An incorrectly-implemented syncing mechanism may conclude that because it can no longer see a folder at that location on the server, it must have been deleted and that it should therefore result in the local copy being deleted as well — which happens to contain Alice’s modified document. The syncing mechanism would then see what appears to be a completely new folder on the server, and download that. But Alice’s changes would be gone.

Solutions

File synchronisation is a complex topic, but necessarily has to be addressed to at least some extent by any app that lets you work offline with documents whose primary copy resides online. It’s unacceptable for an app to blindly push changes to a server without checking to see if the files or folders in question have been modified by someone else, and it’s also unacceptable for the app to download all changes from the server and overwrite local copies that may have been modified independently. It’s necessary to provide both conflict detection and resolution capabilities, with the latter preferably involving automatic merging of changes where possible.

There are many possible solutions to these problems, which have been implemented in various syncing clients and version control systems. Git provides what I consider to be the most elegant solution to this (plus a whole host of other things), but that’s another topic entirely which I won’t get into right now.

The simplest approach I’ve been considering for an initial implementation of moving is to do it synchronously — that is, require you to be online at the time of the move, and wait until the server has reported a successful completion of the operation before allowing you to continue using the program. In computer science terms, this is known as an “atomic test and set” operation, where a check is performed to see if the change is valid, and if so, the change is made, all in one indivisible operation, avoiding race conditions. The alternative is to perform the move asynchronously — that is, in the background at a later point in time; but that has all the problems mentioned above, and requires keeping track of lots of extra information in order to do it reliably.

In the long term, I plan to integrate support for Git directly into UX Write, so you’ll have access to its full set of functionality, including versioning, branching & merging, and conflict resolution. Software developers use this all the time for collaboration, and I’d encourage you to learn more about it if you’re interested. I’ll be posting more about this integration in the future once I’ve had a chance to think it through further.

Doesn’t iCloud handle all of this?

Sort of, but only in the context of a single application and a single user. Since UX Write only runs on the iPhone and iPad, many people use it in conjunction with other applications like Microsoft Word on their desktop, so it’s necessary to sync the files between different platforms. iCloud has a restriction that only allows files to be accessed from within the application that created them, and provides neither a generic filesystem model of the sort found on Mac, Windows, or Linux, nor does it cater for the need to edit a given document with different applications. So that basically rules it out, as far as I’m concerned.

In Summary

Better file management facilities are coming to UX Write, but as described above these aren’t straightforward to provide in the context of the ecosystem we have today where everything is stored and synced online across multiple devices. At the moment, my primary focus is on building a word processor, not a file manager, so the latter has secondary priority. But I am very much aware of the need for improvements in this area, and will get to them eventually.

Content, Structure, and Presentation

Posted on by

UX Write is designed around three primary aspects of electronic documents: content, structure, and presentation. To appreciate how and why the app works the way it does, it’s important to understand each of these aspects and how they relate to each other:

  • Content is simply the words and images in your document — nothing more, nothing less. It is the most important aspect, because it contains the primary value — your idea, your story, your message; whatever information you intend to convey to the reader.
  • Structure is the way in which your document is organised. Typically this involves a hierarchy of sections with one or more levels of headings, as well as the arrangement of content into paragraphs, lists, tables, and figures. Any special designation attached to certain paragraphs, such as the document title or a footnote, is also considered structure.
  • Presentation is what your document looks like. It is determined by formatting and layout options such as fonts, colours, margins, and line spacing. These options are either set on a case-by-case basis via direct formatting, or, preferably, using styles to specify how headings, normal paragraphs, and other structural elements should appear.

All three of these are critical aspects of any professional documentation tool; when tied together, they permit the automation of many editing and publishing tasks. Structural information, in particular, is necessary for generating a table of contents, numbering headings, figures, and tables, supplying the text of cross-references, and providing navigational aids during editing such as an outline view. Furthermore, the use of styles enables the presentation to be based on the structure, so a consistent visual design can be reliably maintained throughout the whole document without manual effort.

Word processors vary greatly in their support for the structural aspects of editing. Some provide none at all — requiring all presentation to be specified via direct formatting, which makes it difficult to achieve a consistent look and feel or conform to organisational style guides. Others provide very basic facilities, such as lists and tables, but little else. The most capable provide full support for all aspects of structure, such as headings, built-in and custom styles, automatic numbering, and table of contents generation.

Even when a word processor supports advanced features, they are not always obvious from the user interface, and are only revealed in their full glory after you’ve climbed a steep learning curve. The canonical example is Microsoft Word, which has hundreds of features hidden away in various menus and dialog boxes, but has a default toolbar configuration which encourages bad practices like direct formatting, as I discussed in a previous post.

UX Write is designed first and foremost for structured writing, with the hierarchical organisation of sections made explicit, and direct formatting deliberately discouraged in favour of styles. This is why it feels so different to use than Word — it’s a cleaner, more disciplined approach to document authoring, which is optimised for writing, with presentation as a secondary concern. The focus is on helping you with your most important task — getting your message across.