[pmwiki-users] wikipublisher questions

[John Rankin]

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.
<snip>
>>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:
>
>http://www.netstreams.org/netstreams/spedlog/pub/images/pdficon.gif
>
>should be:
>
>http://www.netstreams.org/netstreams/pub/images/pdficon.gif
>
>
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
plan.
>>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.
>
<snip>
>
>>>publishing links:
>>>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)
>>>    
<snip>
>>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
>beginning.
>
>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.
>
>push submit:
>-> 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.
>
<snip>
>>  
>>
>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'.
>
<snip>
>>
>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.
-- 
JR
--
John Rankin