The beta version of PageFour 1.4 has just been released.
Development over the past few weeks has gone very well, and I’m more than happy with the result. Every time I make a major change or addition to PageFour I start wondering how I possibly managed without it, and the new printing options are no exception.
The Print Templates add yet another unique feature and key selling point to the product, which alongside the Snapshot and Archiving features make PageFour stand out from its competitors. Now all I have to do is capitalise on this uniqueness and turn it into downloads and sales.
Ain’t life grand.
Work is almost complete on the next version of PageFour. This release will see major improvements to the printing capabilities of the product, focusing as always on the needs of writers, rather than business users.
Building on feedback over the past few months, the basic printing options of version 1.3 have been drastically overhauled. Changes include:
- Full control over headers, footers, and page numbers when printing.
- Facility to ‘override‘ font, paragraph, and line spacing settings.
- Feature whereby the user can create multiple print templates, and choose which one to use when printing.
Lack of control over headers and footers has always been a weakness of PageFour, so I’m very pleased that this is about to be resolved. The key feature of the coming release however, is the ability to print using different font and paragraph settings to those you use when writing.
I work on a high resolution monitor, and use Verdana 11 as my default font, with single line spacing. The changes in version 1.4 will allow me to continue using these settings, yet print using Times New Roman 12, with one and a half line spacing. Different publishers have different requirements, and the font or paragraph settings you use when writing may be completely different to those you would use when printing a manuscript. In the past, you may have had to change these settings within the document each time before printing. With version 1.4 of PageFour, it’s simply a case of setting up however many print templates you may need, and choosing which one to use when printing.
If all goes to plan, a beta version should be available for download and testing this weekend, with the release version following a week later. If anyone is interested in trying out the beta version, please and I’ll point you in the right direction. Previous beta testers have had a major impact on the shape of the product, so it’s a good opportunity to have a say in how PageFour develops.
Programmers don’t like users. In an ideal world, whatever product they are designing would be beautifully written with the latest trendy technology, passed on to a testing department (preferably in a different city), and never sold to a single user. It would work like a charm when configured correctly through hacking various text and script files in Notepad, produce in depth exception reports for every problem encountered, and have a beautifully crafted and fully modular framework of code that can be reused in every future conceivable product - whether a flight simulator for NASA or a stock inventory for Jerry’s Fish and Chip Shop.
The problem with users is that they tend to get this crazy idea that what they see on the screen actually is the product. They seem to think that the hastily thrown together heap of grey dialogs and tacky icons sourced from a free download site is what they’ve paid all that money for.
They’d be right.
Software is designed to be used, which means it’s designed for users to use. Note the emphasis on the word use here. When someone pays you money for a piece of software, they don’t care how the underlying code base has been constructed, and they don’t care about the structure of the database. All that matters is: Can I use it to do the job, or will it cause me grief?
Every programmer pays lip service these days to the importance of user interfaces, but in most cases they don’t really believe it. Like an alcoholic who tells you about his drink problem, they say the words because they are the words people expect to hear, but deep down they still believe that they control the drink, it does not control them, and the GUI really isn’t as important as the engine running underneath.
For too many programmers the GUI is the bit bolted on at the last minute to satisfy users and the guys in sales. It is often designed by someone who thinks typing configuration commands into a text file is far more useful than an interactive GUI with trees and checkboxes; that a visual interface can never allow the flexibility and customisation of a simple configuration file. This is all true - if the sole user of the product is the guy who wrote it!
If you don’t think about the user from day one, you will never design a truly great product; you will never design a product people want to use. Even the giants make this mistake. I stumbled across an article the other day on the failings of Lotus Notes, one of IBMs big groupware products everyone was talking about ten years ago. To quote one of the many disgruntled users:
“Notes’s backend functionality has no bearing on us 100m or so end-users. As far as we are concerned the GUI is the system. And boyo… is the GUI client a heap of ill-conceived, non-intuitive rubbish.”
Lotus Notes now has the dubious honour of its very own hate site where its many failings and embarrassments are displayed and dissected for all the world to see.
There’s a lot more competition out there today than there was ten or twenty years ago. If you build a technological marvel and ship it with a shabby user interface, and the competition builds a functional product that looks fantastic, who do you think will win the sale?
