Rishi's comments are, in my opinion, correct. Assuming the typical XXE user is intelligent but lacks expertise in technical details (or is uninterested in learning these technical details), these error message(s) are cryptic, contain too much information, and don't guide the user to a solution.
My users run into this problem frequently. I've had to include in the training material a statement to the effect, "If XXE fails to generate pdf after the first successful generation, close the file in pdf viewer." Anything that takes the user out of the primary job of writing should be minimized. These 'context switches' are mentally disruptive and reduce productivity. To that end, please consider: 1. Have the pdf generation process check before generating the pdf and tell the user "Cannot generate pdf until the pdf file is closed in pdf viewer" or words to that effect. 2. Include a 'friendly' pdf viewer in XXE. That way, the user wouldn't have to switch between applications and the pdf viewer pane/tab could use a 'refresh/redraw' strategy (instead of locking the file) to 'play nicely' with the editing panes/tabs. clark -----Original Message----- From: [email protected] [mailto:xmleditor-support-bounces at xmlmind.com] On Behalf Of Rishi Khan Sent: Thursday, April 23, 2009 7:36 AM To: xmleditor-support at xmlmind.com Subject: Re: [XXE] Detecting a locked PDF file Hussein, The problem with this error box from a GUI perspective is that there is WAY too much information. For a technical person, this is fine because he can read all of this and it somewhat makes sense. However, someone not familiar with the XML -> FO -> PDF internals will have almost no understanding of the bottom box. "Permission denied" is buried at the end of the 6th line. How is a lay user to know THAT is the problem and the problem isn't "Cannot copy" or "Command execution failed" (well, these are higher level problems. Suggestion 1: Put the error reason up front like this: Error: Permission Denied Cannot copy ... to ... Suggestion 2: Have the "Details" box as an optional drop down with a little ">" that you can click on to turn to "V" (like OSX when copying many files). Or have a "Details" button like Windows GPF's. This way the technical person can see the data, but the non-technical person doesn't get inundated. The second problem is that although "permission denied" tells the user the problem, but it doesn't tell the user how to SOLVE the problem. I would add, in the case of "Permission Denied", "Check if this file isn't open in another application". (Permission denied can happen for other reasons, but on a windows machine, this is the main reason you can't write to a file). The other option is to have a "Help" button. When the user clicks on that, it brings up a box that suggests how to fix the problem. Rishi On Apr 23, 2009, at 3:16 AM, Hussein Shafie wrote: > Andy Black wrote: >> >> Some PDF reader applications lock the PDF file they are >> displaying. One >> implication of this is that if a user tries to re-generate a PDF file >> from within XXE while that file is currently being viewed in the PDF >> reader, then the generation process will result in a "command >> execution >> has failed" message. (Well, at least it does for my configuration >> files...). >> >> My question is this: is there a way within the XXE configuration >> files >> to detect if the PDF file that is about to be generated is in a state >> where this situation will happen? If so, I'd like to then give >> the user >> a message saying that they need to remove the PDF from their PDF >> reader. >> >> I'd be happy with any kind of detection such as >> cannot delete the file >> file is being used by another application >> the reader has the file open already >> or any other conceivable way to detect this situation. I want to >> avoid >> users being confused by this scenario. Most likely they will think >> something on the order of "I just created the PDF file a few minutes >> ago. Why won't it generate it now?" and be frustrated. >> > > The error message issued by the operating system should be crystal- > clear > in such case. > > This error message is indeed reported by XMLmind XML Editor. See > attached screenshot. Notice the "(Permission denied)" error cause. On > Windows, error causes are even more explicit (e.g. "file is being used > by another application"). > > No offense intended, but are you sure that your users actually read > what > is displayed by the error dialog box before clicking OK? > > > > <error_dialog_box.png> > -- > XMLmind XML Editor Support List > xmleditor-support at xmlmind.com > http://www.xmlmind.com/mailman/listinfo/xmleditor-support -- XMLmind XML Editor Support List xmleditor-support at xmlmind.com http://www.xmlmind.com/mailman/listinfo/xmleditor-support
