iWork ’09 and long documents

Posted by Pierre Igot in: Pages
August 20th, 2012 • 9:13 am

If you want evidence that Mac users are being somewhat neglected by Apple these days because all the focus is on iOS devices, you just need to look at Apple’s iWork productivity suite. We are approaching the back-to-school season for the 2012–2013 school year and the software is still stuck at version… ’09 — which stands for 2009, in case that wasn’t obvious.

Granted, the suite has received minor updates since 2009, but the only visible improvements have been to maintain compatibility with Lion, and then with Mountain Lion and iCloud. There have been no new features and no significant bug fixes. And nothing new has been announced. I realize that the competition (i.e. Microsoft) is just as slow, if not slower, but is that really an excuse? Since when is Microsoft a good example of how to do things?

So, while we continue to wait for an elusive upgrade, I can continue to point out persistent flaws in the current version… The one I want to talk about today has to do with documents of a certain size. As soon as my Pages ’09 documents exceed a certain number of pages or my Numbers ’09 exceed a certain number of table rows, I find that the application is simply unable to remember the exact scrolling position when I close and reopen the document.

For instance, right now I have a Numbers ’09 spreadsheet containing a single table that has approximately 360 rows. I am at row 320 and I edit a cell there. So the selection focus is on that row and the scrolling position is such that this row is approximately in the middle of the window. I then close the document window and reopen it. Even though the focus is still on row 320, when I reopen the document, the scrolling position of the document window is such that Numbers ’09 shows me the section of the table from… row 200 to row 249. It makes no sense whatsoever. Since the focus is still on row 320, I find that I can use the cursor keys to move around in that section. This forces Numbers ’09 to scroll down to that section in order to show me what I am doing with the cursor keys. But still… Why on earth is Numbers ’09 unable to show me that section to begin with?

The exact same thing keeps happening in Pages ’09. If I have a 50-page document and the focus (insertion point) is currently on the very last page, when I close the document window and reopen it, the scrolling position is somewhere around page 30. Again, since the insertion point is actually on page 50, I can force Pages ’09 to scroll down and reveal the appropriate section by using the cursor keys. But again, why is it now showing the section where the focus/insertion point is to begin with?

This has been a problem in iWork for as far as I remember — in other words, for something like six or seven years. Granted, it’s not a huge problem, especially since the cursor keys can be used as a quick way to alleviate the problem. But still… I simply do not understand how such an obvious flaw can be allowed to survive for so long in these applications. To me, it’s quite symptomatic of the stagnation of the product suite as a whole. At this point in time, it just feels like Apple does not really care. (There are numerous similar issues in iWork ’09.)

And it’s not like they don’t have the resources that would be needed to move this thing forward.

I sincerely hope that I will be proven wrong and that Apple will soon announce a major update to the iWork suite. But until then, I will continue to be a rather unhappy user of the suite. It’s still much more pleasant to use than Microsoft Office in most cases, but really, I expected a much better rate of progress and improvement when I first embraced the product and adopted it as a central part of my workflow.


One Response to “iWork ’09 and long documents”

  1. Pages and Long Documents : Clark's Tech Blog says:

    […] Pages and the problem of long documents. It’s extremely surprising to me how long Pages and Numbers have gone without a significant update — there’s no shortage of problems with them. […]