QuarkXPress 7: the Good, the Bad, and the Ugly

The Bad

The Measurements Palette
I love the vast improve­ments to the Measurements palette, but would like to see them tak­en yet fur­ther. First, all the usu­al one-object lim­i­ta­tions of dialogs still apply to the reborn Measurements palette. You still can’t, for exam­ple, select mul­ti­ple box­es and set their runarounds simul­ta­ne­ous­ly. Without the need to open the Modify dia­log for each instance, set­ting runaround is a faster process, but it could be much faster if the Runaround tab didn’t dis­ap­pear as soon as more than one box is selected.

Another improve­ment I’d like to see to the Measurements palette is to make it dock­able to the top or bot­tom of the appli­ca­tion win­dow. Maximizing a doc­u­ment win­dow still means mov­ing the Measurements palette out of the way of the scroll­bars and lay­out tabs, which can be nettlesome.

Floating Palettes
The XPress 7 method of group­ing palettes is clunky and coun­ter­in­tu­itive. Multiple float­ing palettes may be stacked into a ver­ti­cal group, which makes them mov­able as a unit. Even bet­ter, all palettes in a stack can be rolled up into a sin­gle, tiny title bar, or even closed with a sin­gle click. This is, of course, a very impor­tant fea­ture for lap­top users or any­one with lim­it­ed screen real estate (and who he thinks he has enough?). Once they’re stacked, 7’s palettes are won­der­ful; it’s the act of get­ting them stacked, in the desired order, that’s awkward.

To attach palettes to one anoth­er, you must right-click (CTRL-click on Mac) the title bar of the intend­ed upper palette and choose from a pop­up menu the name of the palette to attach beneath it. Repeat the pro­ce­dure to attach each sub­se­quent palette to the bot­tom of the whole stack. New palettes are only append­ed to the bot­tom of the stack; they must then be dragged up or down to rearrange their order, which isn’t obvi­ous when the start­ing point is a menu.

Quark claims XPress 7’s menu-driven palette stack­ing is supe­ri­or to Adobe’s method of drag­ging palettes toward each other’s tops or bot­toms to stack. I dis­agree. The Adobe method pro­vides more imme­di­ate con­trol and visu­al feedback–a bold line appears to indi­cate the point of attach­ment before com­mit­ting to it. Additionally, Adobe appli­ca­tions allow mul­ti­ple palettes to occu­py the same space on screen through tabbed group­ing, some­thing XPress 7 doesn’t have.

I do very much like the fact that dif­fer­ent palette arrangements–including stack­ing order and sizes–can be saved as sets acces­si­ble with key­board short­cuts. InDesign offers the same key­board access to saved work­spaces, but that fea­ture is buried in the Keyboard Shortcuts dia­log. XPress also lacks a default palette arrange­ment or set–move and resize the palettes, and there’s no way to get back to the default.

Quark may have a long way to go toward find­ing the most effi­cient method of man­ag­ing palettes, but so do Adobe, Corel, Apple, and Microsoft. No one has found the mag­ic for­mu­la yet, and I’m glad Quark is trying.

Origin
Very close to wind­ing up under “The Ugly” sec­tion because of its ongo­ing require­ment for need­less pen-and-paper cal­cu­la­tions is the con­tin­ued lack of an object proxy in XPress 7. All posi­tion­ing and siz­ing data is still rel­e­vant to the top left cor­ner of objects–the “origin.” While this may be com­fort­ing to those who wor­ried about the appear­ance of any sim­i­lar­i­ty to InDesign or PageMaker creep­ing into in XPress 7, it’s pro­found­ly dis­ap­point­ing to those of us who want to focus on lay­ing out pages instead of stop­ping to crunch numbers.

The proxy–a rep­re­sen­ta­tion of an object’s cen­ter point, four cor­ners, and four sides, usu­al­ly locat­ed near the trans­form con­trols on the Control or Transform palettes, and enabling posi­tion­ing and siz­ing rel­e­vant to any of the object’s nine coordinates–has been a stan­dard part of XPress’s com­peti­tors for more than 15 years. Quark should have incor­po­rat­ed a proxy or oth­er means of con­trol­ling object posi­tion­ing and size rel­e­vant to dif­fer­ent cor­ners and sides–at the very least the cen­ter point–years ago; find­ing it still absent from XPress 7, which has advanced in so many oth­er ways, is pro­found­ly disappointing.

Master Page Items
Master page items are still fully–and too easily–selectable on doc­u­ment pages. An errant flick of the wrist can still move or delete a mas­ter page item–or, worse, leave an extra, slight­ly out of place copy on the doc­u­ment page when the mas­ter page is reapplied.

Master Page Layers
Layer sup­port on mas­ter pages has been a long hoped for relief from the ease with which mas­ter page items may be altered. Unfortunately, that relief is still nowhere in sight.

Inconsistent Measurement Field Entry methods
Many mea­sure­ment fields still require typ­ing in new val­ues while oth­ers includes slid­ers, drop­down menus, and oth­er alter­nate input meth­ods. I would like to see more mouse-driven con­trols added–or at least used consistently–including up and down arrows beside fields like the X and Y coor­di­nates, and slid­ers or dials added to fields like the drop shadow’s angle.

Palettes Refuse to Hold Positions
Between ses­sions, palettes move. They don’t go back to their default loca­tions, they just move–usually to the bot­tom of the screen. This hap­pens regard­less of whether you have saved a palette set. The Measurements palette also doesn’t remem­ber the state of the tab bar; whether you set it to always show or always hide, it reverts to its default behav­ior of appear­ing when the mouse moves over where it should be. (Although the palettes mov­ing is annoy­ing, the ani­ma­tion that accom­pa­nies the move is pret­ty cool–even on Windows.) This behav­ior, more so than just about any­thing else, smells like a bug. Hopefully Quark will stamp it out before the retail release.

The Not So Little Little Stuff
Layouts may be named, but those names don’t trans­late to the Save dia­log. It would be just a lit­tle extra touch of con­ve­nience if XPress auto­mat­i­cal­ly entered the name of the first lay­out as the project’s name dur­ing the first save. Microsoft Word and Photoshop take this lit­tle user-friendly step, and it would be nice if XPress did, too.

When using the Split Windows fea­ture, a fresh set of lay­out tabs appears at the bot­tom of every pane. These tabs enable not just mul­ti­ple views of one lay­out, but views on all lay­outs in the doc­u­ment. The tabs are quite handy when work­ing on relat­ed lay­outs, but use up far too much valu­able screen space when work­ing in a sin­gle lay­out. If that one lay­out is the only one, you can hide the tabs and reclaim some of the space by acti­vat­ing Single Layout Mode, but that won’t help if there are sev­er­al lay­outs in the project. There should be a con­ve­nient way of hid­ing the tabs for split views.

There are no new text com­po­si­tion fea­tures. InDesign still holds the title of World’s Best Composer by a long shot with its hang­ing punc­tu­a­tion, opti­cal char­ac­ter spac­ing, and multi-line para­graph com­po­si­tion. In fact, Illustrator boasts more advanced text com­po­si­tion than XPress. As a small redemp­tion, XPress enables edit­ing of kern­ing and track­ing tables, which InDesign does not.

The Ugly

While some areas of the inter­face have been updat­ed, oth­ers real­ly show their age, smack­ing of the untamed System 7 and Windows 3.1 days. Even some­thing as sim­ple as the New Layer but­ton on the Layers palette, with its stick figure-esque icon, shouts util­i­tar­i­an after thought, not planned user inter­face. Why can’t XPress be both func­tion­al and attrac­tive? I would very much like to see the XPress inter­face updat­ed to mod­ern stan­dards of appli­ca­tion design–I’m not nec­es­sar­i­ly talk­ing about Adobe’s inter­face here. Both Apple and Microsoft have estab­lished guide­lines for com­mon inter­face ele­ments such as default but­tons, rollover but­tons, and icons, and just a sim­ple update to mod­ern OS X- and Windows XP-style but­tons and icons would hint at the next-generation pub­lish­ing fea­tures under the XPress 7 hood.

Undo
Undo still won’t res­cue you from the mis­takes you real­ly want to back out of. Saving and insert­ing, remov­ing, or rear­rang­ing pages still can­not be undone with a flick of your fingers.

Locking
Object lock­ing has been improved, but to what degree depends on your per­spec­tive. In pre­vi­ous ver­sions of XPress, lock­ing an object mere­ly pre­vent­ed it from being repo­si­tioned or resized with the mouse; it was still ful­ly sus­cep­ti­ble to any and all oth­er mod­i­fi­ca­tions. Locked box­es could still be select­ed, and then moved or resized by chang­ing the val­ues in the mea­sure­ment fields on the Measurement palette. They could also be altered in any num­ber of oth­er ways, includ­ing the appli­ca­tion of fill and frame col­ors, changes to runaround set­tings, sent back­ward or brought for­ward, and their con­tents edit­ed. In XPress 7, how­ev­er, locked box­es can no longer be repo­si­tioned or resized using the Measurement palette, but every­thing else still works: their fills and frame col­ors can be changed, as can runaround set­tings and their stack­ing order rel­e­vant to oth­er objects, and their con­tents are still editable.

As I not­ed under “The Good” above, text inside box­es can be locked, but that only pre­vents copy and col­or changes; text inside locked sto­ries inside locked box­es can still be mod­i­fied in numer­ous ways, includ­ing col­umn options, insets, base­line options, and rota­tion of text.

XPress 7’s object and sto­ry lock­ing is not what I think of as “locked.” Locking some­thing should make it total­ly, utter­ly, whol­ly untouch­able until and unless delib­er­ate­ly unlocked. As doc­u­ments become more complex–and with the new­found abil­i­ty to com­pos­ite in XPress, the lay­ers of com­plex­i­ty will pile up–it’s impor­tant to pro­vide a facil­i­ty for total box and con­tent pro­tec­tion. Working on the mid­dle object in a stack of ten is much eas­i­er when upper objects can be ren­dered uns­e­lec­table. The old bring & send rou­tine is just that: old. Moreover, it’s risky–did I press CMD+F5 five times or six?

When con­tent is frozen, it should be frozen, with­out the con­stant risk that a dis­tract­ed, tired, or less fas­tid­i­ous pro­duc­tion intern will acci­den­tal­ly change a designer’s work. The Layers palette can help in some such sit­u­a­tions, but not all and often not with­out unnec­es­sar­i­ly increas­ing both the com­plex­i­ty of the lay­out and the job of work­ing in it.

The Icon
It would be remiss to over­look the ugly Quark appli­ca­tion icon. Is a yel­low traf­fic light tru­ly the best har­bin­ger for XPress 7 Proceed with cau­tion! May stop at any time! Fortunately, the appli­ca­tion itself is strong and sta­ble, because brand iden­ti­ty is not Quark’s strongest point.

Glyphs Palette
If you are accus­tomed to the extra­or­di­nar­i­ly use­ful short­cut of typ­ing a font name into the type­face box to acti­vate that font, one quirk of the XPress 7 Glyphs palette could dri­ve you up a wall. You can indeed type the name of a font into the type­face box, and, like any Adobe, Macromedia, or Microsoft appli­ca­tion, XPress will auto-complete the name as soon it rec­og­nizes it. However, if you enter the name of a font that is not installed, XPress will beep and pop­up an error mes­sage. Trying to clear the erro­neous font name can be frus­trat­ing because every time you type or delete a char­ac­ter, XPress search­es again–and errors again if the font isn’t found. Clicking away from the Glyphs palette also spawns the error, as does attempt­ing to click the type­face drop­down list or high­light­ing and delet­ing the name entire­ly. The only way to clear the beep-prompt-click OK loop is to type the name of a font that XPress can find–which may take some time.

Type Style Buttons Not OpenType Compatible
Since time immemo­r­i­al, XPress has includ­ed style but­tons beneath the type­face menu on the Measurement palette. Experienced XPress users under­stand that using some of these style but­tons car­ries with it an inher­ent risk. Sending bold or ital­ic type through a RIP gen­er­al­ly requires the pres­ence of a bold- or italic-style font file, which is a com­plete­ly dif­fer­ent set of font out­lines than the nor­mal or Roman style of the same type­face. Heedless of this require­ment, press­ing the Bold style but­ton on the Measurements palette will beget bold text–even if no bold-style font file exists. XPress will fake bold by thick­en­ing stroke weights, and it will fake ital­ics by slant­i­ng text. Similarly, XPress has always faked super­script and sub­script by scal­ing char­ac­ters and adjust­ing their base­line off­sets, as well as faked small caps by cap­i­tal­iz­ing text and scal­ing it down a user-specified per­cent­age (usu­al­ly 70–85%). The net result is just text set at a small­er point size–baseline align­ments are usu­al­ly off, and, more impor­tant­ly, the stroke weights of the affect­ed glyphs don’t match those of sur­round­ing text. Often the dif­fer­ence is so pro­found that you might as well be using dif­fer­ent type­faces entire­ly! Unlike faux bold and faux ital­ics, these faux styles don’t cause prob­lems on-RIP, they just cre­ate hack­neyed type.