If the PDF is behind a secure form, how do you stop the user saving the PDF, then emailing to everybody? -> if the information is in a PDF, then you must consider that information to be insecure. That also applies to all web pages -> they can be saved locally, etc.
Mathew Robertson > Sandy @ Mega Star Media INC <sa...@megastarmedia.com> wrote: > > I agree with download if that is an option..meaning that the PDF is not > an > online secure form... > Good point. > sandy > > -----Original Message----- > From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] > On > Behalf Of Mathew Robertson > Sent: Thursday, February 05, 2009 2:49 PM > To: wsg@webstandardsgroup.org > Subject: Re: [WSG] PDFs and other non-html files opening in a new > browser > window > > > My Web team and I are discussing whether or not we should open links > to > PDFs > > and other non-html pages in a new window. Someone cited Jakob > Nielsen's > > argument at http://www.useit.com/alertbox/open_new_windows.html as the > > reason we should open in a new window. (We all work on government Web > sites > > and they are about to release a new set of linking standards.) > > > > I know this is an old school type question, but we are very divided > about > > this. The people on our usability team are with Nielsen, but others > (like > > me) are not so sure. Isn't accessibility to new windows a problem as > it > > changes the focus? What do you think? > > I'll go out on a limb and say 'niether' -> allow the user to save the > document locally, becuase: > - opening a non-web document in a browser, causes the browser to freeze > while the application gets loaded; on a slow machine, this can be > upwards of > a minute or two. > - you cant switch tabs to continue working, while the application loads > - often browser plugins dont support a "save to desktop" option > - some plugins are notoriously buggy, so as website designer you > shouldn't > encourage the browser to crash (an thus destroying the history of every > other tab in the process - firefox/opera not withstanding), just to > display > your non-web document, eg: some older versions of Acroread come to mind > as > causing much frustration in this regard. > - most browser plugins have a cut-down feature set from the full > product, > making them quite unhelpful to use. > > In any case, it is possible to detect if the browser supports a given > plugin > (eg: pdf, doc, etc) -> so it becomes possible to supply the user with > the > most appropriate format. > > For example: the purpose of pdf's is for offline reference or for > printing - > if the browser doesn't support pdf, the server could reasonably assume > that > the user doesn't have native pdf support. Then a suitable message could > be > displayed accordingly. Alternatively the server could convert the pdf > to > html and thus be able to at least render it (probably quite awfully) > within > the browser. > > regards, > Mathew Robertson > > > ******************************************************************* > List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm > Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm > Help: memberh...@webstandardsgroup.org > ******************************************************************* > > > > ******************************************************************* > List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm > Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm > Help: memberh...@webstandardsgroup.org > ******************************************************************* ******************************************************************* List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *******************************************************************
