[pmwiki-users] wikipublisher questions
john.rankin at affinity.co.nz
Thu Mar 30 16:10:44 CST 2006
On Thursday, 30 March 2006 10:04 PM, noskule at gmx.net wrote:
>John Rankin schrieb:
>>On Thursday, 30 March 2006 9:15 AM, noskule at gmx.net wrote:
>>>In a farm wikipublisher only works in the main field. In all other
>>>fields the wikipublisher server gives the "wikipublisher error report".
>>>The strange thing is that the pdf icons are only shown in the mainfield
>>>but not in all others.
>>If you do a View Source to look at the html of a page with a ? pdf icon,
>>what is the address of the icon? Is it the *farm* pub or the
>>*current field* pub?
>hm, it looks like wikipublisher couldnt find out that the current wiki
>is a field, cause
>the url is:
To fix this, I think I need to change the image locations to use
$FarmPubDirUrl, but to prevent this breaking in non-farm
installations, I also have to SDV($FarmPubDirUrl, $PubDirUrl);
as this doesn't appear to be set until later.
I am hoping to release a new wikipublisher today, if all goes to
>>If it's the current field pub, I'll guess that this
>>is also the cause of the typeset failure, as it's probably not finding
>>the latexprint and latexpublish skins in the *farm* pub directory, but
>>is looking in the *current field* pub directory instead.
>yep, guess thats the problem
Maybe. The pmwiki skins script looks in pubdir and farmpubdir, so it
*should* find the pdf skins wherever they are. Let's get the above
problem fixed and see what happens.
>>>I would like to have a simple pdf icon on the several locations (page,
>>>wikitrail, wikiforms, ...) that leads the user to the pdf option in on a
>>>new page, so when he is finishing making pdf he can close the window and
>>>is on he's startposition)
>>I *think* you are asking for the following behaviour changes:
>>- clicking a pdf icon or pressing a typeset button opens a new
>> window with the confirmation screen
>yes, that means that the user could browse a page and if he deside to
>make a pdf a new window opens, he does the pdf operations (configure the
>pdf seddings, deside if he want an email ore waite for it), and if hes
>finisch he closes the window an is at the same point at the
>Currently it works on (my installation) like this:
>click pdf icon:
>-> 1. new page (pdf options)
So you *always* present the user with the options? Our view was that
an administrator would configure the defaults so the reader rarely
needs to worry about this -- She just gets a pdf, but the options are
there in the background if needed.
>-> 2. new page (delivery desition (mail, wait))
>push I'l wait:
>-> 1. new page with the pdf
>so the user probably wants to save the pdf. He save and close the
>window. Now he stay at the second "delivery-window". If he want back to
>the starting situation he will press the backbutton of the browser 2
>times. He also could press "cancel", but in my "limited "expiriance,
>nobudy press cancel, I guess its because cancel implies to stop somthing
>but the user wants "back" so he takes the backbutton
And that's because you want the reader to select pdf options all the
time instead of by exception. I do agree that "Cancel" is a poor
choice and "Back to Page" would be *much* clearer. You can change
this by editing Site.Wikipublisher so it reads:
(:wikipublisher cancel='Back to page':)
But I'll change the original -- good idea!
>For my understanding, operations like pdf print and that like should
>open a new window that can be closed if the operation is finish, or mybe
>work in the same window but in this case brings the user automaticly
>back to the startingpoint.
Currently, as long as you are in the wiki, no new windows open;
when you leave the wiki to get a pdf from the pdf server, it opens a
new window. When you are finished with the pdf, you close the window.
This was deliberate: only open a new window when the user has made a
conscious choice to go somewhere else. Some people would argue that
sites should *never* open a new window. If somebody wants a new
window (or new tab), she will control or right click the link.
>in my personal taste im not fan of many windows that let the user step
>througt, if the information can be displayed in one window, so i would
>merge the config and deliverywindow. The mailfeature (supper-nice
>thing!) the people use in my expirience for to send the pdf to other
>people. If the want it for themselfs the allways whait cause they want
>to check how it look like and to recive it in the mail and store it
>somewhere is more work.
I see it a bit differently. My experience is that one should hide as
much information as possible and keep the interface simple. But if
more information is needed, it's no more than a click away. If the
administrator has configured the defaults correctly, most users most
of the time will not need to change them. And remember that these
can be set on a per group basis, through a Group.PublishTemplate
and Group.PrintTemplate etc, as well as the Site templates. And
for publishing trails, they can be set on a per page basis.
So our idea was that most of the time you will press Typeset then
press I'll wait. And that's it; job done. Of course, if you have a
very diverse group of users with strong and differing opinions on
how pages should be laid out for printing, then they will want to
select their own personal options every time. But I think they will
soon get tired of this and settle for the defaults.
But that's just me. You might want to work out how your users are
reconfiguring the default settings and come up with site settings
that more accurately reflects your community. I think this could
be more productive than reconfiguring the user interface so that
the options are visible to everyone all the time. I think your
users will thank you for it.
>I guess the back button (Cancel) will be used if au user opens pdf by
>misstake. So he will/could naturaly hit the backbutton. This sould not
>happen to many times.
I *will* change 'Cancel' to 'Back to page'.
>I dont no how other admins (i'm not a real one, more on the desing side)
>think about this. IMHO, it would be best if be start of the pdf
>operation opens a new window and if the operation is finish the window
>can be /will be closes and the user is on its starting point.
I would like to hear other opinions. I must admit that I lean to the
school that says *never* open a new window. I was talked into having
*one* place that opens a new window. You want new windows opening
all over the place. One easy solution is to make the current
newwindow an option and you teach your users how to open a new window
(or tab) in their browsers! Then if those who want a new window they
can have one, and you disable the current new window, so they can
close the window to get back to the page.
Arguably, we shouldn't build into the server, functions that already
exist in the browser.
Thanks for the excellent feedback.
More information about the pmwiki-users