Apparently Adobe Acrobat 7 is out. I wrote this review about the beta; not much has changed, so I thought I’d post it here as well. I wouldn’t normally care all that much about proprietary software, but when I first heard that Adobe was porting to gtk, I was pretty excited- I hoped/assumed that they’d Get It and make an actual gnome-y app. That didn’t happen. I realize there are economic realities about our platform that make that difficult, but some of the options they’ve chosen are… very odd at best, even taking that into account.
So, anyway- I do applaud Adobe for taking a plunge that many other proprietary software makers have been unwilling to take. But I hope that their next step is to become a real, native-looking Linux app, and not just a lukewarm port.
Summary:
The Acrobat reader beta has a lot of problems. It uses custom widgets where standard gtk widgets are available, causing issues with integration, theming, and accessibility. It does not take advantage of long-available bits like CUPS and gconf, causing usability and manageability problems. Finally, it does not follow modern (i.e., since 2002) GNOME design standards, making it a less integrated part of the desktop.
Technology choices:
All of these techs except the last are available, I believe, on all the distros Adobe wants to support.
* still uses ‘/usr/bin/lp’ for printing. C’mon. It is 2005.
In the gnome screenshot, note the presence of the ‘HP-4100’ printer in the printer list; the adobe reader is forced to confront and understand the mysterious string ‘/usr/bin/lp’.
* It should use gconf to store and read preferences so that it can be remotely configured and managed by tools designed to read and write gconf keys, like the current tools from Sun and the forthcoming tools from Novell and Red Hat.
* Appears to use gtk 2.2 instead of gtk 2.4 or 2.6, each of which would allow access to the newer, improved file selector, and improved toolbar and menu APIs.
Design issues:
* generally speaking, the beta does not attempt to follow modern GNOME standards for dialog layout. The UI design of the app should seek to follow the GNOME Human Interfaces Guideline (HIG). Compare and contrast the use of indentation, spacing, bold text, and lines suggested by the HIG:
with the file->print menu above, or the preferences menu below. This is a problem in effectively every dialog in the application. If you’re going to port to Linux, port to look like modern GNOME or KDE apps- not GNOME 1.4. Please. :)
* In buttons, there is frequent use of ‘Cancel’ and ‘OK’, where GNOME standards would prefer more descriptive terms- for example, in the print dialog, ‘OK’ is replaced by the more informative ‘Print’ in the GNOME dialog. One is a lot easier and clearer, regardless of whether you use GNOME, KDE, or Windowmaker; one is not.
Custom widgets:
* The main toolbar is not a GTK toolbar, and so does not respect GNOME/gtk theming. This has two significant implications: it does not respect accessibility theming, nor does it look/feel like a ‘native’ application, which I’d originally thought was a goal for them.
In the acrobat screenshot, note the difference in background color between the toolbar and menu (an accessibility problem), and note the different icons (a cosmetic and accessibility problem). [I assume they’ve tried to understand the a11y problems, as they have a number of accessibility menus and are probably working around a lot of these with their own settings.]
* in many cases standard gtk widgets are simply not used; see, for example:
Note the very primitive looking for a checked box in the acrobat example, and the more modern and professional-looking checkboxes in the gedit/gnome example. There are others: there is a custom checkbox widget, and a custom dropdown list widget. Besides looking out of place and not being properly themeable, there are almost certainly accessibility implications for doing custom widgets.
Big picture design choices:
* It is a pdf viewer. With built in web searching. WTF. Compare and contrast Evince.
* It has MDI. Not just tabs, but true, old-school, MDI. Why does a pdf viewer (or anything) have a multi-document interface (MDI) instead of per-document windows? MDI was the way to go in Windows 3.1, and has (for good reasons) fallen out of favor since then. I should get one window per document as I do virtually everywhere else in any Linux desktop, be it GNOME, KDE, or even OOo (which managed to grok this was a bad idea by, like, 2001). Worst-case scenario, the interface should be tabbed (as in firefox and gedit) and not MDI.