iOS 7 Update and New Features

Posted on by

iOS 7 has finally been released today, and with it the first set of apps updated for the new version of the platform. Among them is a major new release of UX Write, which addresses language support, and adds several important new editing features. UX Write 1.2 requires iOS 7, and will run on the iPad 2 or later, iPad mini, and iPhone 4 or later.

Here’s what’s new:

User Interface Localisation

All menus, dialog boxes, and other user interface text have now been translated into the following languages: Chinese (Simplified/Traditional), Dutch, French, German, Italian, Japanese, Korean, Portuguese (Brazil/Portugal), Russian, Spanish, and Thai. The translations are thanks to the excellent work of LocalVersion. More languages will be added in the future.

UX Write in Thai

Text Entry in Chinese & Japanese

Keyboard-based text input mechanisms for east-asian languages require multiple key presses per character, due to the existence of many thousands of possible characters. For example, to type 中国 (the Chinese word for China), you would type the letters “zhongguo”, and then select from a list of candidate words from an extra row on the keyboard.

Chinese text input

Previously, UX Write operated under the assumption that every key press corresponded to an individual character, which is true of European languages, but not of Chinese or Japanese. There are also handwriting-based input mechanisms for these languages built in to iOS where you don’t press keys at all.

Luckily, Apple already provide all of the keyboard logic for taking this kind of input from the user, including the word choice mechanism described above. However, apps like UX Write which use custom text editing components have to explicitly cooperate with this logic by supporting so-called “marked text”, which is the sequence of letters that has been typed by the user, but is “provisional” in the sense that it will later become a different sequence of characters when you finally choose a word. It was this relatively small piece logic that UX Write was missing, and now that I’ve added support for this, the key-based and handwriting-based input mechanisms for Chinese and Japanese now work.

Find & Replace

You wanted it, you’ve got it. This has been the most requested feature of all over the past few months, and is finally in. You know that empty space at the top of the toolbar where other apps put direct formatting properties like font size and paragraph alignment that really belong in styles? I’ve used that space instead for a search bar — just like you have in Safari. Just tap on it and type in your search term. On the iPhone, it is accessible under the Settings menu.

Find and replace

If you tap the little arrow icon next to this bar, you’ll get some additional options. You can use these for find & replace (as opposed to just find), specifying whether to perform a case-sensitive or case-insensitive search, and also searching based on regular expressions. [see note at end of this post about a replace bug for which a fix will be available in a few days]

Regular expressions, if you haven’t encountered them before, are a way of specifying patterns of text that you want to match, rather than an exact match of a particular word or phrase. UX Write supports regular expressions in both the search text and the replacement text. If you’re an old-school Unix hacker you’ll be familiar with the concept; otherwise, you can learn about them here. UX Write’s regular expression support uses the NSRegularExpression class that is part of iOS; you can see the details in all their glory on Apple’s developer site.

One suggestion a beta tester made to me was offering a “whole words only” option for find & replace. I’ll be providing this in a future update.

Spell Check

Another often-requested feature, this is now available as well. You can access it from the Settings menu, and it will highlight any words it finds that aren’t in the dictionary. The user interface for correcting a word is the same as what you use for autocorrect — you can select from a list of alternatives, or add it to the custom dictionary (which can also be edited through the Settings menu).

One caveat with spell checking in UX Write is that it only works with languages for which Apple provides a built-in dictionary. These languages are: Danish, Dutch, English, French, German, Italian, Portuguese, Russian, Spanish, and Swedish. If Apple later start including dictionaries for other languages, then these will be automatically supported for spell checking and autocorrect purposes by UX Write.

Word Count

There’s not really much to say about this I guess other than yep, it’s there.

I did find out however rather late in the piece that Japanese is written without spaces between words, and I’ve been told that in Chinese spaces are often omitted as well. Thai is the same; I’m actually studying Thai at the moment and while the books we’re using in class use spaces between words to help us comprehend sentences more easily, this is not done for mainstream Thai writing.

So for now at least, word count only works properly for languages in which words are separated by spaces. However, it does also show the total number of characters and paragraphs in the document as well, so if either of those is what you’re after, you can get them as well. I’ll be adding an extra item for character count excluding spaces in a future update.

iOS 7

The release of iOS 7 is one of the most significant in the platform’s history, after the introduction of third-party apps in 2008, and multitasking in 2010. While on the outside there’s a complete visual refresh, there’s also a lot of new features “under the hood” that I’ll be taking advantage of in future versions of UX Write.

One of those in particular is real-time pagination in WebKit, which will allow me to provide an option in UX Write that will show you where page breaks will occur in the printed document. A lot of people coming from an MS Word background have been asking for this, but I haven’t been able to provide it to date due to limitations in WebKit. Unfortunately, the pagination support in the initial release of iOS 7 doesn’t work correctly, so I have to wait for Apple to fix the bugs I’ve reported before I can make use of it in UX Write.

Other new features I plan to utilise include improved background file transfer, AirDrop support, and CSS regions (enabling magazine-style page layout). I’ve really only scratched the surface of what iOS 7 has to offer at this stage, because all the beta versions of 1.2 had to be compatible with iOS 6 as very few of my beta testers have developer accounts.

Now that iOS 7 is available to the public however, new releases of UX Write from now onwards will depend on it. While I’ve been reluctant to drop support for older versions — particularly because iOS 7 won’t run on the original iPad — I’ve concluded that the effort required to support both is too much to be worth it, and I’m better off putting my time into adding new features. If you have an iPad 2 or later (including iPad mini), or an iPhone 4 or later, you can update to iOS 7 for free.

Known Issues

There’s been a lot of “behind the scenes” changes in the UX Write codebase for this version which won’t be readily apparent to you as a user, but have increased the risk of bugs in this version. It’s had a fair amount of testing while in beta, however there are several issues that have come up since I submitted 1.2.0 to the app store a week ago:

  • When opening an existing Word document that doesn’t already contain heading styles, these will not show up in the formatting menu. If you encounter this problem, open up the document in Word, mark one or more paragraphs using the heading styles you want, and then take the document back to UX Write.
  • The external keyboard is not recognised in some cases. If this happens, just tap on the screen and this should get it to recognise the keyboard.
  • The replace field doesn’t work on the iPad. Currently there’s no workaround for this; it only works on the iPhone. Yes, this is a bit embarrassing.

I’ve already fixed all three of these bugs (plus a few others) and submitted a 1.2.1 update to Apple. It should be approved for release in the next few days. Do let me know if you find any other problems.

Update (19 September): Apple approved the 1.2.1 update in just over 24 hours. Normally it takes 4-5 days; I’m impressed!

WWDC wrap-up

Posted on by

It’s been a pretty amazing week for me here in San Francisco, attending WWDC 2013. This is my first time at the conference (and my first time in San Francisco, or the US for that matter), and I’ve really had an incredible time meeting some great people and experiencing some of the energy here.

There were basically two main parts to the conference – sessions on new features in iOS 7 and OS X Mavericks, and the labs in which developers have the opportunity to sit down with people from various engineering teams within Apple. My primary focus of course was on WebKit, as this is main the part of iOS that UX Write is built on. I had the opportunity to talk with some of the team about new features that have been introduced, and work through a few issues I encountered – which has been extremely valuable.

WWDC - Keynote Lineup

Much of what was covered during the conference is subject to a confidentiality agreement that all developers are required to comply with, so unfortunately I can’t give details about the new features other than what was discussed in the keynote. The session videos and all new documentation & SDKs are, however, available to all registered Apple developers (and, presumably, NSA contractors). What I will say is that there are some very exciting capabilities coming in iOS 7 that are going to enable me to provide certain features in UX Write that I haven’t previously been able to, and I’m very much looking forward to taking advantage of these. Once iOS 7 is out, all future updates to UX Write will depend on it, so at that point you’ll need to have it installed (iOS 7 will run on iPad 2 and later, as well as iPhone 4 and later).

The atmosphere was electric

Take 5000 developers from all around the world, 1000 people from Apple, and put them together for a week, and it’s not hard to predict that there’s going to be a very large number of great conversations and exchange of ideas. This is where it all happens – it’s the center of the Apple universe. The success of the iPhone and iPad is as much due to third-party developers as it is due to Apple themselves. This is the only time of year where both get together on such a massive scale. And I don’t think I’ve ever seen so much aluminium in one place before.

WWDC - 30 mins before the keynote

The labs were invaluable

By far the best part of the conference was the labs held each day, where you could talk with engineers from various teams about any questions or issues you had about features of iOS that relate to your app. Most of my lab time was spent with the Xcode and WebKit teams. When you find a bug and are trying to track it down, it’s great to be able to get in touch with the person who works on that part of the OS and have them go into the debugger with your program, and say “ok, I think I can see what’s happening here. You can work around it for now by doing X, and I’ll put this in our bug tracking system”.

I also had some questions about a new feature in WebKit that I’m going to be using, and it was incredibly valuable to sit down and get advice on best practice for using it directly from the people who implemented it. You simply can’t get that kind of thing anywhere else.

Pirated copies of UX Write are no longer in the App Store

It took a flight to the US, a meeting with two people from the app store team, and a very unambiguous demonstration of both the original and rip-off versions of UX Write (including the crash in the latter when you change the text colour, the “UX Write has crashed” screen, and the crash log that it sends to my email address) to convince them, but the problem has finally been dealt with. Now the only version of UX Write you can buy on the App Store is the one which is actually going to be updated with a ton of new features over the coming year and beyond.

I’ve also made some suggestions about how these problems could be avoided in the future, using a very straightforward O(n log m) algorithm in which the hash of each of the n files in a new submission is checked against a database of hashes for each of the m files from every version of every app previously submitted. From there, it would be necessary to filter out known common, publicly-available files (such as resource files from SDKs and open source libraries), and then flagging any app with remaining matches for manual inspection. It would likely be necessary to throw a fair bit of hardware at this, but I can’t imagine it being particularly difficult to implement.

I think they get it now, and I’m really hoping to see something along these lines put in place, because I think it’s very important for the credibility of the app store as a reliable and trustworthy marketplace for both app developers and customers.

My laptop died on Thursday morning

Half-way through WWDC, when you’ve spent the past day or two writing prototype code and test cases to discuss with engineers in the labs, is quite possibly the worst imaginable time to lose an SSD. In my particular case it was an OCZ Octane S2 drive that went, and I believe the failure came about due to either a firmware update I had to install on Monday night so I could upgrade to Mountain Lion, or a compatibility issue between Mountain Lion and the drive’s firmware itself. OCZ’s mac support is laughably bad.

I could have gotten a replacement drive installed, but it looked like that was going to take a few days to organise – time that I simply didn’t have. The situation I was in meant I absolutely had to have a working machine to make the most out of my time in the labs, plus some meetings I have lined up with a number of companies next week. So I bit the bullet and decided to just walk a couple of blocks away to the Apple store and buy a new machine.

I’m now the proud owner of a brand-new 2.8 Ghz quad-core retina Macbook Pro with 16Gb of RAM and 3/4 of a terabyte of (Apple-supported) SSD storage. It was a very expensive day to say the least, but my old laptop was about due for an upgrade anyway, and I’m very happy with the performance of the new machine.

WWDC - New Macbook Pro

There were some great networking opportunities

One of the things I want to do with UX Write in the future is to improve integration with other apps – in particular those which provide complimentary functionality, such as diagram editing (OmniGraffle), text manipulation (TextExpander), and online storage & collaboration (Box). It’s kind of difficult getting data between apps on iOS, since unlike on other platforms this requires explicit cooperation between app developers. I’ve already been doing some of this with Box and Texpad, and met with people involved with both OmniGraffle and TextExpander and I hope to get some some integration happening with both of these great apps.

Everyone loved UX Write

I demoed the app to quite a few people, and had some really encouraging responses. Many were previously unaware of the app – building awareness has been perhaps the biggest challenge for me – but once they saw it they thought it was very cool.

UX Write of course isn’t perfect yet (what software is?), and there’s still a lot of work to be done on advanced features like change tracking, EPUB export, page layout, file management etc. So if you’ve had issues with these, I don’t want you to read the above paragraph as me thinking the app is “done” – it’s still very much a work in progress. But things are looking very good, and I’m feeling pretty confident about the future as I continue to work through my roadmap.

Microsoft released Office for the iPhone

This was one of the biggest pieces of news (or perhaps non-news) to hit iOS in a long time. After 5 years of it being possible to create third-party apps for the iPhone, Microsoft finally achieved the goal of bringing Office to the platform. I tried it out, and perhaps the most amazing thing about it is how spectacularly bad it is.

I don’t usually criticise the competition, but I’m going to make a special case here, specifically due to the incredibly high ratio of brand recognition to actual product quality involved. To be clear, this is absolutely nothing like the Office you’re used to on your PC or Mac, and in fact I really consider it misleading to even use the name “Office” for an app like this. The iPhone version of Word has roughly the same level of functionality as what I remember being present in Wordpad back in the Windows 95 days.

Someone I know at Microsoft has told me there’s an iPad version due out around a couple of months from now. I don’t know any more details, but I’d be very surprised if it provided the full functionality that’s available on the version for the Surface.

San Francisco has an awesome music scene

Would a visit to America still qualify as valid if it didn’t include attending at least one or two live blues performances?

I don’t think so.

Cafe R&B

What I hope to get from WWDC

Posted on by

So I’ve just arrived in San Francisco for WWDC. This is my first time here, and in fact my first trip to the US, and I’m really excited about the conference. Primarily I’m here for networking – I see it as a great opportunity to meet with other developers and chat about our experiences and ideas.

Here are the main things I’m hoping to get out of the conference:

  • They keynote, of course! I’ll be very interested to see what’s announced with iOS 7. There’s the much-rumoured new interface design from Jony Ive of course, but I’m also hoping to see some improvements under-the-hood which make it easier for developing content creation apps. My #1 wish in this area would be a user-visible filesystem which allows you to organise documents by project rather than by application. I’m not holding my breath for this, but a man can dream…
  • Learning from other developers about their experiences with marketing apps – what works, and what doesn’t. To be honest, the development part of this project has been the easiest aspect (a huge amount of work, but comparatively easy). The marketing part has been really hard. It’s an unfortunate fact of life that the success of technology products has more to do with marketing than their actual features or quality. I think this is something a lot of us struggle with, but I’m sure there’ll be plenty I can learn from the experiences of others.
  • Finding other developers to collaborate on an open source file synchronization framework. This is one of the most time-consuming parts of developing a content creation app, particularly given that each different service such as Dropbox, Box, Google Drive etc. has a separate API, so you have to implement each individually. I’d like to put together a framework which takes care of all this stuff for you, so you can just plug it into your app and easily sync with all of these services. I’m sure there are many others who have struggled with this, and I think if we work together we can come up with something that benefits app developers, users, and storage services by abstracting away all the boring plumbing stuff.
  • Identifying opportunities to have UX Write tie in with other apps that provide complementary functionality, as I’ve already been doing with Texpad and Box. I’m focusing specifically on word processing with UX Write, but there’s a number of other types of apps (such as drawing programs, mind-mapping tools, and outline editors) that I’d love to make UX Write work with.
  • And finally, the sessions. These are actually last on my list because I’ve already got access to Apple’s excellent documentation and they are also making the videos available for developers who missed the two-minute registration window for the conference. But it will nonetheless be good to hear directly from Apple engineers about advice on making the most of the platform. In particular, I’m keen to get a better understanding of localisation, as one of my main priorities right now is improving support for a wider range of languages in UX Write.

Given the immense concentration of tech companies in the valley (far more than anywhere in Australia), it’s also a good opportunity to meet with other companies working in the area of mobile and online services, and I have several meetings lined up that I’m hopeful could lead to some useful collaborations in the future.

Pirated copies of UX Write on the App Store

Posted on by

Over the last couple of weeks I’ve been dealing with a very frustrating problem. I’ve become aware of three different instances in which unauthorised, repackaged copies of UX Write have been submitted to and approved for sale on the app store, each under a different name. I’ve been going through the standard process to pursue these cases, but decided to post here as well, to clarify that these copies are not legitimate versions. The genuine version of UX Write is available on the app store here.

The unauthorised versions are as follows:

All three are verbatim copies of UX Write version 1.1.4, with only the name and icon changed. The Getting Started guide has been modified to use the name “Document Master”, even in the case of the last two apps. The screenshots on the app store are completely inaccurate and the descriptions highly misleading, in many cases listing features the app does not actually provide.

The only reason I even became aware of these is because the people who did the repackaging made a certain mistake (the details of which I won’t go into) which results in the app crashing under certain circumstances, where the original does not. Since the actual program itself is unmodified, it still uses my email address as the destination for all user-submitted bug reports and feedback. I’ve received emails about these from more than 200 people so far, none of whom initially realised that what they’d purchased was an unauthorised copy.

Piracy is a fact of life in the software industry and ultimately there’s nothing you can do to stop it. It would not surprise me one bit to see copies of UX Write on the Pirate Bay or other sites that have apps for downloading to jailbroken devices. But the app store is different – it’s run by Apple, who review every submission to ensure it complies with their rules, and once approved, they earn a 30% cut of every sale. So while I wouldn’t even bother spending time trying to deal with copies posted on torrent sites or similar, the nature of the app store is such that I think it’s reasonable to expect a higher standard from it.

The last time something like this happened, Apple refused to do anything about it and told me I had to deal with it myself. I made it clear to them that I’m expecting a better answer this time, and the people I spoke to were very understanding and I’m hopeful they will eventually remove the apps. After all, telling developers such as myself to email the people selling pirated copies to ask if they’d please stop doing so is not, in my opinion, a viable solution. There’s nothing to stop the other party from ignoring emails, refusing to take their copies down, or simply doing so but then resubmitting with a new account and a different name.

I don’t directly blame the reviewers for approving these copies in the first place – there are hundreds of thousands of apps out there and it must be huge task to manage it all. But the process is clearly broken, and needs to be fixed. I’m due to attend WWDC in a couple of weeks and hope to have the opportunity there to speak with people from Apple about the issue and how the situation could be improved. I’m far from the only developer affected by this problem – in checking for other copies of UX Write, I’ve found many other instances of apps from other companies being repackaged and approved as well; it’s clearly a widespread problem.

Using Box with UX Write

Posted on by

The latest update to UX Write, version 1.1.6, has just gone live on the app store. This introduces integration with the native Box app for the iPad, which provides an alternative to UX Write’s own built-in file management and syncing capabilities.

One of the biggest problems with the iPad for content creation tasks is the lack of built-in file management capabilities. Despite these being present on every major desktop operating system for the past 30 years and a critical component of almost all professional workflows, the iPad itself does a very poor job of catering to these needs. Thus, it is left up to third-party developers to implement their own file management and syncing solutions, which is a huge time sink that takes away time from working on core app features. Thus I’m always happy to see apps & SDKs which make this process easier.

Box is an online storage service (similar to Dropbox and Google Drive) and has client apps for the iPad, iPhone, Android, Mac, and Windows. A critical and unique feature of the native iPad app is it contains facilities that allow both opening and saving of files with other apps. While the iPad has a built-in “Open in” feature (supported in many apps) which let you send a document one way, there’s usually no way to get it back. Box provides an SDK that individual app developers can use to provide the ability for you to save a document back to Box once you’ve modified it. This is a critical piece of the puzzle that is missing from other solutions that I’m aware of.

Using Box with UX Write

Once you have an account with Box (which you can register for free) and install the Box app, here’s what you’ll see:

Box - Main screen

To create a new document, click on the cloud ‘+’ button in either the top-right or bottom-left corner of the screen. Then select the app (UX Write), and the file type (e.g. DOCX):

Box - Create document

This will bring up UX Write, and you can start adding text to your document. When you’re done, tap on “Close” and then “Save to Box”:

Box - Save

This will switch to the Box app, which will prompt you to type in a name for the document. When you’re done, press upload.

Box - Upload

And that’s it! You can now have your document synced with other devices and computers that you’ve installed the Box client on. You can also view and edit the document in any other Box-compatible apps you have installed:

Box - View & edit

Footnotes, Headers, and Footers

Posted on by

Among the features I’ve had the most requests for are the ability to add footnotes to documents, as well as custom page headers and footers. These are standard features of print-oriented word processors and many people naturally expect to find them in UX Write. So I thought I’d give an outline of my plans for supporting these. There’s some rather tricky issues involved due to the web-oriented nature of the app, but fortunately these are solvable.

WebKit for editing

UX Write actually doesn’t do any layout itself; it is entirely dependent on the WebKit rendering engine, as used in Safari and Chrome, for displaying all content. WebKit is based on HTML and CSS, the document structure and formatting languages of the web, which work somewhat differently to the file formats used by print-oriented word processors such as Microsoft Word and OpenOffice Writer. The differences — in particular, HTML’s continuous, non-paginated nature — have important implications for the feature set that is possible to support in UX Write.

Writing a (sufficiently capable) custom layout engine is a task that takes a sizeable team of people and many years of effort, which simply wasn’t a viable option for this app. Relying on WebKit makes it possible to invest all development resources entirely on editing capabilities, rather than all of the logic to calculate where each piece of text goes and how it’s formatted. This is why UX Write possesses so many more features than its competitors — all the hard work of layout is already taken care of. WebKit is also built in to iOS, which makes it a very convenient choice for use in an iPhone/iPad word processor.

By using WebKit, UX Write inherits both the capabilities and limitations of HTML. Although HTML has a lot of great features — styles, tables, images, lists, hyperlinks, and a ton of formatting options — it’s not particularly good at paginated, print-based output. On the web, there’s no notion of a document being divided into a series of (virtual or real) sheets of paper like in a traditional pure-WYSIWYG word processor. I’ve previously discussed why relying on explicit pagination during editing doesn’t make sense in the context of writing for e-books or the web, but it is relevant for documents that are ultimately destined for print output only. Unfortunately, among the features HTML lacks are — you guessed it — footnotes, headers, and footers.

Currently, UX Write uses WebKit for both editing and print/PDF output — but there’s some changes on the way for the latter.

LaTeX for printing

WebKit isn’t the only layout engine out there of course. Another popular one is Donald Knuth’s famous TeX typesetting engine, which was designed in the early 1980s for high-quality presentation of scientific and mathematical publications. It was later used by Leslie Lamport as the basis for LaTeX, a high-level set of macros for structuring documents that are ultimately typeset by TeX to produce printed output. I’ve used LaTeX for producing all of my academic publications (though doing my writing in LyX, a graphical front-end), and it’s pretty much the de-facto standard for academic publishing in computer science, mathematics, physics, and other scientific fields. After being around for more than 25 years, LaTeX is still regarded as one of the best quality typesetting engines out there.

LaTeX provides excellent support for print-oriented features such as footnotes, headers, and footers, plus many others such as page-number references and embedding of hyperlinks and outline navigation elements in PDF files. It’s a much better option than WebKit for generating print output, and making use of it in UX Write will make it possible to provide these features.

There’s one major problem with LaTeX however — it is only able to run in batch mode, and cannot provide real-time updates to the typeset document during editing, as WebKit can. What batch mode means is that a document is supplied to LaTeX, it goes away and does its thing, and then a few seconds later you get back a PDF file with the output. This means that it can only realistically be used for printing or exporting PDF files, and leaves us with WebKit as the only viable option for actual editing.

It’s always been a goal of mine to have built-in LaTeX support in UX Write. My hopes were initially dashed after I read about the immense difficulties the developers of Texpad had encountered while attempting a port to iOS due to the complexity of the codebase, however they eventually achieved success with a much simpler LaTeX distribution than that which is typically used on desktop systems. Upon learning of this I realised two things — that it is viable to do, and that I should work with them.

So LaTeX provides the solution to the problem of producing high-quality print output with all the layout features typically expected. However because getting this integration working is quite an involved task, I’m going to be doing it in two separate stages:

Stage 1 (soon): External typesetting

Initially, UX Write will provide an option to export the current document as a .tex file, which can either be converted to a PDF directly on your iPad or iPhone using Texpad, or on your desktop system using an existing LaTeX distribution such as TeX Live.

Installing and using LaTeX on a desktop system requires a fair bit of technical proficiency, and is something I only recommend for advanced users who are already familiar with the process. Texpad is a much easier solution, as it’s just as easy to install as any other iOS app, and will integrate seamlessly with UX Write. I’ve been working with the Texpad developers over the past couple of months on getting this integration working, and we’re getting fairly close to having it available.

Stage 2 (later): Built-in typesetting

Eventually, UX Write will contain a built-in version of LaTeX that it will run directly when you print or export to PDF. Everything will be done within the app, without requiring any third-party software, and it will be just as seamless and easy to use as the current print/PDF option. You won’t even realise there’s anything special going on behind the scenes.

Given that Texpad provides a very good solution to the problem, I’m going to be leaving this second stage until much later on, and focus on other features like find & replace, spell checking, EPUB support, and better file management over the next few months.

In summary

I know all this sounds awfully complicated — and, well, it is. I understand and sympathise with those of you who are waiting for these features and I’m just as keen as you are to have them in place. Unfortunately these things take a lot of time and effort — even Microsoft, with all the resources at their disposal, are at least 18 months away from having a working release of Word on the iPad, if recent rumours are to believed. The important thing to know is that I’m very much aware of the needs of professional writers and have a solid roadmap in place for the future of UX Write.

This Month’s “Office for iPad delayed” Rumour

Posted on by

Every now and then a “leak” comes out about a purported Microsoft roadmap saying that they’re planning a version of Office for iOS and Android, but it’s been delayed for one reason or another. This month is no exception, with a release slated for the second half of 2014 [1].

I honestly don’t know if these rumours are actually true, or just a clever PR stunt on behalf of Microsoft to discourage others from trying to produce competing apps. What I am certain of however is that the task of porting the huge legacy codebase of Office to the iPad must be absolutely daunting. Office is an immensely complicated piece of software, and if they are working on an iOS version, I’m not surprised it’s taking a while.

The best comment I’ve seen so far on the issue was one made in response to the Macrumors article, by a user named (well, I guess I have to say it if I want to quote them) nuckinfutz:

“Office is becoming irrelevant. The iPad has flourished despite not having MS Office and that’s an encouraging sign. The days of Microsoft software being a “must have” for success are over.

Today people just care about having some sort of import/export capability and are comfortable with non Microsoft solutions.”

I think there’s a great deal of truth in this. There’s a school of thought that considers MS Office as the be all and end all of productivity apps, and that every other piece of software must be measured by how closely it matches it. I disagree with that notion, and as nuckinfutz pointed out the most important thing is not whether you have MS Office per se, but whether you can actually get your work done and access your documents. UX Write fulfils this criteria.

In fact I’m of the view that MS Word is a really bad starting point if you’re trying to create a tablet word processor. We’ve seen what they’ve managed to come up with on the tablet form factor so far, and it leaves a lot to be desired, to put it mildly. UX Write has been designed from the ground up with mobile devices in mind – catering for the small screen, adapting cursor movement and selection for the on-screen keyboard, and making it dramatically more intuitive to achieve consistent formatting throughout your document.

This stuff is much easier to do if you’re starting from scratch. Sure, it takes a long time to get all the features people want and expect in, but that’s probably no less a task than porting a large codebase with lots of dependencies on Windows.

So why wait for Microsoft? Give UX Write a try today (which you can now do for free in your browser), and check it out in the app store if what you’re looking for is a high-end word processor that works well with existing docx files created in Word.

[1] Side note to Americans: “fall” (aka Autumn) occurs at a completely different time of year in Australia and other countries in the southern hemisphere. Months or quarters are less ambiguous 😉

Thoughts on the Blink/WebKit fork

Posted on by

It’s been a few days now since Google announced their decision to start their own fork of WebKit, called Blink. I was initially quite surprised and disappointed by this, given the duplication of effort and fragmentation this could possibly lead to. I understood the situation much better however after reading Alex Russell’s post which explains their rationale, and I feel that all the reasons he gave make sense — that is, Google has more freedom to innovate by working separately from Apple.

There’s an even more important reason though that I think this is actually a good thing — diversity. People forget the dire state the web was in back in 1999, when Netscape was on its deathbed and Internet Explorer was emerging as the winner of the “browser wars”. Developers started targeting IE only, and those using anything else were left in the cold. People who argued against this were considered by the mainstream to be on the fringes of society, and ridiculed for not simply giving in and accepting the inevitable victory of the almighty IE6. My, how times have changed.

The KHTML library (which became WebKit) was initially created around this period by Lars Knoll and other developers involved with the KDE project, with the goal of producing a modern, high-quality browser for the Linux desktop. While KDE never saw the success it deserved, WebKit went on to become one of the biggest success stories of the open source movement, after being adopted & improved first by Apple (for Safari), and then by Google (for Chrome). What started out in its first few years as an underdog has now become the market leader on mobile by an overwhelming majority.

We’re now in the ironic situation where instead of the web being at risk of becoming an IE monoculture, it is now at risk of becoming a WebKit monoculture. Both of these things are bad; it’s important that web sites continue to be developed based on standards, not on the quirks of a particular browser engine. Multiple implementations are key to this — it ensures, in the long term, that all browsers converge towards consistent behaviour, and keeps the possibility open of entirely new browser engines being created in the future.

Although Blink and WebKit are identical right now, the fact that Google is going to follow a separate development path will help ensure that as the web evolves, we’ll have an additional implementation of all new APIs and layout features. There’ll undoubtedly be fragmentation problems with new features added to standards in the short term, but it will result an a better outcome in the long term as bugs are fixed to comply with the standards, and developers are forced to create sites that work in any browser, not just those based on WebKit.

Page Layout in the Era of Electronic Publishing

Posted on by

The basic design of modern word processors has its roots in the WYSIWYG (“what you see is what you get”) revolution of the 1980s, which became possible with the introduction of the graphical user interface. Whereas people once had to use a text editor to enter markup by hand, and never really knew what their document was going to look like to readers until they printed it, WYSIWYG provided an accurate on-screen depiction of how the final print output would appear.

For most of the history of personal computing, documents have been written for print. Even when they were viewed on a desktop or laptop, the screen was always large enough to display either the whole page — or at least the full width of the page, with the possibility to scroll vertically. However in the last few years we’ve witnessed an incredible shift in the way people consume content — e-readers and tablets are now widely used by people for reading books, papers, and notes.

Because devices like the iPad, Kindle, and Android tablets have screens that are smaller than a typical printed page — particularly in the case of 7″ tablets — it’s necessary for software that displays documents to take a different approach to layout than what has traditionally been used. Whereas in a Microsoft Word document or a PDF file you have a fixed page layout where the placement of text on a page is predictable, e-book readers instead use a reflowable layout in which the text is adjusted to suit the screen size, orientation, and user preferences. If you’re writing an e-book, you can’t rely on the assumption that page breaks will occur in particular places, since this will be different for every reader. In other words, what you see is not what you get.

e-book layout

If you look closely at the picture above (click to see full-size), you’ll notice that the page being displayed is different on every device. My Macbook Pro, with a 24″ external monitor, has lots of screen real estate available and can thus fit a lot more text on the page than any of the other devices. The two iPads are both displaying the same page, but because the one on the right has a non-retina display, I’m using a larger font than on the retina iPad on the left, for legibility — meaning less text fits on the screen. The Android tablet (sorry Steve) has different dimensions and is in portrait mode, while the iPhone’s screen is so small that it only has room for the picture plus two lines of text.

On every device, the book has a different number of pages. And neither has the same number of pages as the print version.

Reflowable Content and Editing

The new reality of multi-format publishing we find ourselves in demands a different approach to document editing than was the norm during the print-only era of the 1980s and much of the 1990s. This has actually been a long time coming — the web ushered in the first major platform for viewing reflowable content, with most early web pages readily adapting to whatever size your browser window was. However graphic designers schooled in the print mindset soon came along and changed that, forcing every website into a fixed-width layout.

This worked fine for quite a while, as pretty much everyone’s computer screens were large enough to display these pages, but mobile browsing sucked for a very long time until Apple finally came along with the iPhone and Mobile Safari, with its zoom feature. For many websites however, this didn’t fully solve the problem, as although you could zoom in and out, you often had to repeatedly scroll left and right as you read through a paragraph, because some web designer had decided that their layout looked best at 1024×768, and forced the text to be that wide. The web design community realised this problem fairly quickly and started adapting their sites to either serve up a different layout to mobile devices, or use a reflowable layout that results in a good-looking document regardless of the screen size.

So if you’re designing a word processor in the early 2010s which has to run on the iPad, iPhone, and now the iPad mini, do you use fixed layout, or reflowable layout?

Based on what I’ve discussed above, the answer might seem pretty obvious, but it’s actually a bit more nuanced than that. Many people are used to the fixed layout of Microsoft Word and similar programs, and there’s a lot of established practice about the way in which formatting is done — such as entering in a series of blank lines to cause text to appear at the start of the next page, tabs to indent text to a specific width, placement of images relative to the top or bottom of the page, etc. These things don’t translate well into reflowable layout where the width of a page, and the location of page breaks (if they exist at all, which they don’t on the web) can differ between devices, and even on the same device if the user rotates it or changes their preferred text size.

There’s an inherent conflict between the goals of achieving full compatibility with the way in which desktop word processors are often used, and what works well on a tablet. Some apps have opted to simply copy the pure WYSIWYG model — dividing documents into fixed-size pages, always using a fixed width and providing a zoom feature so you can enlarge the text. While this makes it possible (in principle at least) to maintain the exact same formatting as you would see in Word, it causes lots of usability problems on small screens, particularly with the iPad mini and iPhone.

Trade-offs

There’s no ideal solution to this dilemma — it’s necessary to either provide a fixed layout, and try to preserve the exact placement of everything as it will appear in print on the small screen, or to use a reflowable layout, where the text and images are adapted to be readable on the small screen. Both approaches involve trade-offs, and which one is best depends very much on what the user’s primary goal is — layout or writing.

In designing UX Write, I decided to go with the reflowable option, because I think that of the two, it provides the best user experience on a small screen. This is also based on the assumption that the primary interest of people who use the app is their content, rather than how it looks. Of course this assumption doesn’t hold for everybody — depending on your needs, you may need finer control over layout and want to see an exact print-like representation of your document during editing. However UX Write does provide a print preview option (it’s called “Generate PDF” — they’re one and the same), so it is still possible to get this view, just not in real time.

As with many design decisions that have to be made with an app like this, things like layout approaches and file format support involve trade-offs. Different developers will make different choices on these issues based on the sort use cases they’re targeting with their app, and at the end of the day from a user’s perspective it’s necessary to choose the right tool for the job. In the case of UX Write, my goal has been to cater for multi-format publishing, where the separation between content and presentation is a necessary aspect, and to provide the best possible user experience for writing on mobile devices.

UX Write 1.1.0, now with Microsoft Word support

Posted on by

At long last, the first release of UX Write to support Microsoft Word’s .docx file format is now available on the app store. This has been a very complex undertaking that’s involved many months of work, and represents a significant step forward for the app in terms of making it useful to a much wider audience. Now you can seamlessly work on the same document using UX Write on your iPad or iPhone and Microsoft Word on your PC or Mac.

To the best of my knowledge, UX Write now provides the highest level of compatibility with .docx files out of any word processor available for the iPad. Virtually all of the basic text and formatting properties are supported, along with essential features like figures, tables, styles, numbered headings and captions, cross-references, and automatically-generated tables of contents. While these features were already supported for HTML documents in version 1.0, you can now use all the same features with Word documents as well.

As with previous versions of UX Write, all documents are displayed using a continuous, reflowable layout rather than the fixed-size page layout that Word uses. Reflowable layout is a much more suitable approach for mobile devices, which, particularly in the case of the iPhone and iPad mini, do not have screens large enough to comfortably display a full-sized A4 page without some combination of squinting or excessive horizontal scrolling. The reflowable layout model used by UX Write is the same as that of e-book readers such as Kindle and iBooks, and just like in these apps, UX Write lets you adjust the text size to whatever you find the most comfortable for reading. You can still see what the printed version of your document will look like by using the “Generate PDF” option.

HTML remains the default file format, and UX Write continues to rely on the WebKit layout engine (the same as used by Safari and Chrome) for displaying documents. When you open a .docx file, UX Write temporarily converts it to HTML for editing, and then converts it back to .docx upon save. However, it does this in an intelligent manner which preserves any formatting properties or other elements in the document (such as page breaks and tabs) that can’t be represented in HTML, as I described in an earlier post.

I’m still a very strong proponent of HTML as a standard document format — it’s worked pretty well for the web over the last 20 years, and is fully supported by every modern computing platform and web browser. Its simple, text-based syntax makes it easy to edit by hand (as millions of web developers do every day), and plays well with version control systems such as Subversion and Git. HTML is also the basis for the EPUB standard for e-book publishing, which I’ll be adding support for in an upcoming version.

One caveat I should mention is that I won’t be supporting the legacy .doc file format used by older versions of Microsoft Word prior to 2007. While I’m aware that it’s still used by some people, it’s a hideously complex binary format that wasn’t designed with interoperability in mind, and I estimate it would take at least another six months to support (and probably a great deal longer to do so properly). When faced with the choice between doing that, and instead investing that time in arguably more important features like find & replace, spell checking, footnotes, EPUB export etc., I decided to go with the latter. If you have a .doc file you wish to edit in UX Write, you can easily convert it to .docx using any recent version of Word (2007 or later).

Although this release has had extensive beta testing, it’s inevitable there’ll still be a few issues remaining, and I’ll be releasing regular updates (probably every couple of weeks or so) during the 1.1.x series. There’s a bunch of other features (such as footnotes, citations, and improved PDF output) I’ve got planned for upcoming major versions which I’ll be working on in parallel, but bug fixes to any issues reported with the .docx support will take priority for the time being. If you do encounter any bugs in this version, don’t hesitate to contact me, and I’ll endeavor to get them fixed as quickly as possible.