[dfiler]

Originally posted by cpac:
Agreed. .pdfs and HTML differ in content in important ways.
...
With such fundamentally different types of content, it seems odd/forced to use the same means of viewing both.

cpac, thank you for taking the time to explain why pdf and html viewers should be separate applications. I have a few more points to add.

One of the easiest ways to screw up an existing interface is to add the features or functionality requested by users. There are often complicated but valid reasons why time-saving features shouldn't be implemented. In this instance, the convenience of recycling a browser window as a pdf viewer window is definately benneficial to many user's workflows. However, it comes at a cost.

The most significant caveat is that users interact with pdfs and htmls in drastically different fassions. pdfs are generally comprised of static, multi-page content. html content is dynamic, linked, single-paged, and designed to display differently based upon user preferences. This means, that over time, the interaction techniques for each medium have evolved to suit their intended purposes, domain of use, and user-base.

By blurring the line between html and pdf without unifying the two standards completely, users are put in the awkward position of needing to remember which 'mode' they are in. Apple was greatly responsible for instigating an industry wide switch to modeless computing. They chose object-selection->action as the interaction technique of choice. This subtlety is something that many GUI designers never pick up on. Many of them didn't work through the previous era and aren't privy to the pitfalls it entailed.


Windows often suffers from being mode based, where users must take care to remember the current state of the computer so that they know which action a single command will invoke. For instance, moving a file to the recycle bin has different effects depending on the location of said file.

By combining pdf and html applications, almost all user actions would be overloaded with multiple possible outcomes based on the current 'mode'. I think cpac listed a few of these such as keyboard shortcuts. But also, printing, saving, and key document behaviors. Page-element selection and manipulation would be heavily overloaded as well. Then there is the issue of toolbar commands appearing and dissappearing instead of being grayed out... the list goes on and on.

While browser based pdf viewing may speed up some workflows, it poses non-insignificant hurdles to many others.

[clarkgoble]

Let me get this straight. Someone is using Mozilla to the exclusion of other browsers and then complains about integrated PDF viewing as browser bloat?

Isn't that akin to Rosanne Barr saying she can't have any gum because she might get fat?

I mean if you were a minimalist using Chimera I might see how it would fit with your aesthetic. But Mozilla? That's the most bloated browser on the market? It makes IE seem lean and sleek.

Further I can see aesthetic complaints about in-browser PDF viewing. But I have a hard time seeing this as bloat. First off it is a feature of browsers many users expect. Secondly with OSX built in PDF display, it shouldn't be that hard to integrate. So I have a hard time calling it bloat. (As opposed to Mozilla's many, many features, most of which are bloat in my opinion)

[manfreds]

Originally posted by JKT:

Note how the scrollbar jumps upwards in the top image, and how the favourites toolbar has been wiped by the loaded pdf in the bottom image.

Yes, this is the same issue as with embedded PDFs in Chimera/OmniWeb. I just did not yet notice that it also happens if you use a separate location bar in OmniWeb.

These browsers change the port origin behind my back. Unfortunately I don't see a way to workaround this.

It's my opinion that it's up to the browser makers to fix this.

[Millennium]

Originally posted by clarkgoble:
Let me get this straight. Someone is using Mozilla to the exclusion of other browsers and then complains about integrated PDF viewing as browser bloat?

Isn't that akin to Rosanne Barr saying she can't have any gum because she might get fat?

I mean if you were a minimalist using Chimera I might see how it would fit with your aesthetic. But Mozilla? That's the most bloated browser on the market? It makes IE seem lean and sleek.

If you must know, I actually switched to Chimera last week. However, I have yet to stumble across any PDF files I was interested in since then, and so I don't know the process for Chimera yet (though I assume it is probably similar). So I used Mozilla as my example, because I'm more familiar with it. But this sort of process predates even the concept of browser plug-ins. Way, way back in The Day, Mosaic, Netscape 0.9 (did ther ever actually release a 1,0 of Netscape, or did they skip straight to 2.0?), and many other used this idea of "helper apps". And it was a Good Idea. Plug-ins make a great deal of sense, for things which are typically embedded in an HTML page, the most common example being Flash. But when's the last time you saw a PDF file embedded into HTML? Indeed, what would the point be of doing such a thing?

That's my philosophy on it, anyway. A browser is for viewing HTML, and those things which might conceivably be embedded into an HTML document. If it makes no sense to embed, then it should be a helper app. Flash was made for embedding (despite the people who do their sites completely in Flash, Just Because They Can), so a plugin makes sense. Same goes, of course, for most images and such. Video, such as QuickTime, is somewhat shakier, but sound is fairly common to embed, so it gets through at least on that basis. But PDF? What's the sense of embedding that?

[clarkgoble]

My philosophy is that a browser is to view web pages. HTML and the like are programmer concepts, not user concepts. PDF is an alternative web page format both in function and intent. (Clearly Adobe was positioning it in this way and clearly many people use it as such)

Treating PDFs differently, in my opinion, would be akin to a graphics program reading only one kind of graphics format. (i.e. Photoshop not opening JPEGs)

Further the work flow model of most users invovles them treating them like web pages. Certainly they can be saved to be stand alone data files. But then the same is true of HTML.

The issue isn't embedding at all. To me that is a red herring. (Although I admit that I will frequently use browsers to view GIFs or JPEGS) The issue is that I don't think PDFs are *used* differently from HTML.

[dfiler]

Originally posted by clarkgoble:
...The issue is that I don't think PDFs are *used* differently from HTML.

Zzzzt! They are completely different in functionality, intended use and interaction techniques.

They are as disparate as human-readable document types can possibly be.

[trusted_content]

I could give two shits about PDF.

How about PNG, eh? IE still doesnt support it natively, and when I try to select an app to open it with, Preview is grayed out. Isn't that just lovely.

[Rickster]

To be honest, I'd prefer it if even image format support were made into a set of plug-ins. Slim the browser down even further. Did you know that most browsers reinvent the wheel completely with their image display code? For the Mac, for example, there is perfectly good code in QuickTime for displaying GIF, JPEG, PNG, and many other image formats, and they do it even better than most browsers because QuickTime's code tends to have such niceties as ColorSync support built in. But the only browser to leverage this code is iCab. All the other browsers out there bloat themselves by using their own code to do exactly the same thing. I'm not sure, but I think that even the current version of OmniWeb does this.

Actually, OmniWeb's image support is implemented as plugins -- you can remove the plugins from the app wrapper if you'd like to not be able to view images.

We actually use a mix of Apple-provided imaging code and "our own". One of our plugins is a shim on top of Cocoa's NSImage functionality (which in turn uses QuickTime to display mostly anything). NSImage doesn't include support for some image formats, nor does it support the likes of animated gifs and progressive display while loading, so we also use standard libraries (linpng, libjpeg, etc) to provide that functionality. In fact, we use the JPEG library to do progressive display of a JPEG as it loads, then use NSImage to draw the final result so that we get all the benefits of QuickTime and ColorSync.

[clarkgoble]

Dfiler: They are completely different in functionality, intended use and interaction techniques. They are as disparate as human-readable document types can possibly be.

The only difference is that simple HTML reflows to make better use of different sized frames. PDF sticks with a fixed page metaphor. And even that isn't always true with HTML with the various additions that have been given to it the past 5 years. Many pages have an optimal frame to view them in and don't reflow in any formal way.

Beyond that both are designed for displaying textual information and subframes of graphics. Both support links, although link heavy pages are obviously more efficient with HTML. Further Adobde pushed PDF as a web standard, so saying that intent is different is silly given the stated intents of the author.

Now it is true that HTML has two functions. One is as a kind of corridor to end information. Google is an excellent example of this. Further scripting has been added to HTML to extend it since the old golden years of Mosaic. So HTML does more. However while HTML does interactive pages and PDF really doesn't in the same way, the fact is that there is an overlap in functionality. That is in terms of displaying textual documents. In that PDF sometimes actually does a better job than HTML. As I mentioned CSS was designed to overcome some of the limitations of HTML, but it still isn't as good as PDF. Further if I am looking for this end document to read and study, I shouldn't care whether it is in HTML or PDF.

This is the key factor. Why should I care whether a manual is in HTML or PDF if I just want to browse it? You are saying that the document ought to be treated differently simply because of the additional functionality of HTML. But it seems like you've got so caught up in this additional functionality that you forgot the main point of HTML - to display textual documents. Yes it does more. But for that basic functionality of *content* both PDF and HTML do the same thing!

My point is that for many, many people they do not interact with PDF documents and HTML documents in different ways. People who say this clearly spend most of their time browsing dynamic web pages and not relatively static documents. Yet most web pages are relatively static and the point of them is content not redirection. In terms of that functionality there is no difference between PDF and HTML. On the PC that usage is acknowledged. On the Mac the only solution is a piece of beta code that must be located by the user. That is unacceptable.

This is not bloat but a simple fact of how many use PDFs. If you primarily use PDFs only for saving or printing you won't recognize this usage. However for people who use the web for finding and studying technical documents, PDFs are not used in a dramatically different fashion from HTML.

[cpac]

Originally posted by clarkgoble:
If you primarily use PDFs only for saving or printing you won't recognize this usage. However for people who use the web for finding and studying technical documents, PDFs are not used in a dramatically different fashion from HTML.

Thanks for the support other plug-in dis-likers.

I think your use, clarkgoble, is atypical. It may be that, for you, having a plug-in is the best way to go about browsing and viewing .pdfs.

But for most people, I believe the opposite is true. Aside from the developer time I would rather was spent on other things (either in finishing up Chimera, or in getting OW5 put together and out the door), the costs mentioned above in interface confusion, and user "modal" confusion far outweigh the costs of having to allow preview or acrobat to open up the file. Command-tab isn't really that difficult, not is a single click on the dock (or click & hold if you have a bunch of .pdfs open, and need to select just one).

HTML is different from .pdf not only in that it "reflows" but that it is not "page" based in the same way. You don't go back/forward *in the same HTML document* in the way you do in a .pdf.

That said, continue to support the plug-in developer if it's what you want. I just don't think there's a need for the browser developers to focus on this.

[Brass]

Originally posted by clarkgoble:
Further the work flow model of most users invovles them treating them like web pages. Certainly they can be saved to be stand alone data files. But then the same is true of HTML.

The issue isn't embedding at all. To me that is a red herring. (Although I admit that I will frequently use browsers to view GIFs or JPEGS) The issue is that I don't think PDFs are *used* differently from HTML.

NO, you cannot just download and save an HTML file. Just try it and then disconnect from the network, and then try to load your saved version from disk. Suddenly you've got a text-only version with no ebedded graphics, animations, etc.

It is VERY different to PDF.

PDF's are completely different to HTML. They are layout oriented so that they always appear the same. HTML is content oriented such that the same data may appear layed out differently in different contexts.

And not just in "reflow" (page layout). There's colours, sizes, how frame borders appear, the browser's interpretation of many tags is different (eg, <emph> simply means emphasis, which can be rendered bold, flashing, differenct colour, or whatever the developer chooses). People who try to make HTML look exactly the same everywhere it might be used are using the wrong medium. That is NOT the purpose of HTML.

[McDriver]

This is not bloat but a simple fact of how many use PDFs. If you primarily use PDFs only for saving or printing you won't recognize this usage. However for people who use the web for finding and studying technical documents, PDFs are not used in a dramatically different fashion from HTML. [/B]

Well said. If I want to browse a pdf document why shouldn't I be able to use my browser? I know a lot of nonpower users and they have severe problems of understanding all the different file formats that exists, they just want to look! Frankly so do I. I want to be able to have a quick glance and see if it's interesting enough to be saved. This discussion so far has been very "poweruser" minded, think of all the not so experienced users out there, why confuse them more than necessary???

[clarkgoble]

Most browsers actually do allow you to save web pages, embedded graphics and all. This is an other limit on many Mac browsers. For instance in the XP version of IE the default for Save As is to save all embedded graphics.

Regarding my use being atypical. It isn't the typical use, but I don't think it is that atypical. The average browser user rarely sees PDFs at all. If they do access one then it is likely just a manual that they plan to print off or access rarely.

However for many, many users, my situation is very common. Further many people in this thread shared the same frustration that I have. Further I see no confusion. If you want simplicity, I can understand that argument. (I obviously disagree, but at least I understand) If you start speaking about confusion though then I'm at a bit of a loss. I don't see how PDFs in a browser are confusing. The back and forward buttons work exactly the same as before. The scroll bar works exactly the same as before. Have you used PDFs in a browser before?

[Gul Banana]

So what's wrong with options? Let the user /choose/ whether they want to see PDFs in the browser. Set a sensible default - perhaps do make them open-in-browser by default since it seems to be the power users who dislike that and the power users are the ones who don't mind changing things in preferences to get the exact setup they want. Options are always good, until you start getting to bloat, but given that this is something people have grown to expect as a feature of a web browser I do't think it could be considered bloat to provide the option...

If Adobe came out with a PDF plugin tomorrow, that's pretty much what we'd have, actually, except with the defaults reversed. I don't want to view PDFs in my browser, so I wouldn't install it... and those who do, would. No need to get uppity with each other about it.

[Brass]

Originally posted by clarkgoble:
Most browsers actually do allow you to save web pages, embedded graphics and all. This is an other limit on many Mac browsers. For instance in the XP version of IE the default for Save As is to save all embedded graphics.

Okay, but the point is that the files are very different. Even if you do download an HTML file, and save it to disk, and your browser kindly saves all the embedded graphics, animations, etc with it, you still cannot treat it in the same way as any other file. Eg, you cannot just move that file elsewhere and keep it working. The gist of what I'm trying to say, I guess, is that the web page does not consist of 1 file, but of many files (at least in most cases).

I don't see how PDFs in a browser are confusing. The back and forward buttons work exactly the same as before. The scroll bar works exactly the same as before. Have you used PDFs in a browser before?

I agree with this. Yes, I have used PDFs in browsers (a lot) before and I don't find it at all confusing. However, I still would prefer to have the browser call a helper application to view the PDF rather than use a plug-in to view it in the browser window. I guess that just makes more sense to me.

As the previous poster said... options would be okay. I guess that because I wouldn't use the option, I don't want it wasting space on my hard disk

[clarkgoble]

Even if you do download an HTML file, and save it to disk, and your browser kindly saves all the embedded graphics, animations, etc with it, you still cannot treat it in the same way as any other file. Eg, you cannot just move that file elsewhere and keep it working.

Actually that is exactly what you can do. That's the whole point. You ought to try some PC browsers. This is a very useful function when you are downloading pages to read later.

As I mentioned, I think you are getting caught up in the technical aspect of how the data is represented and programmed. Instead think of it more from a user perspective. We just have documents that the user reads. Other than showing page breaks and margins, PDF are no different in this from HTML.

Like others have said, I just want the option. Right now I don't have it except via a rather buggy 3rd party plug-in. If browser authors would add this feature then I'd have that option. I'd actually say this is a major issue for me. The 3rd party plug in was a godsend to me, but the before mentioned scroll bar bugs and other problems limit Mac browsers from being as efficient as PC browsers in this regard.

I don't want to force you to do it my way. (Although I think it a much more efficient method of dealing with texts) I just want the choice.

[Millennium]

Originally posted by clarkgoble:
My philosophy is that a browser is to view web pages. HTML and the like are programmer concepts, not user concepts. PDF is an alternative web page format both in function and intent. (Clearly Adobe was positioning it in this way and clearly many people use it as such)

Um... no.

One, PDF had been around since significantly before the Web became popular. It was, in fact, intended for electronic document exchange, but that's precisely where the difference lies. HTML is for carrying information. PDF is for carrying a representation of a document. This difference might seem small, but there are some significant implications. Among other things, PDF has no notion of semantics, which are an important part of HTML. But by contrast, HTML doesn't by itself do much in the way of presentation, and PDF is all about presentation.

Adobe did, at one point, try to position PDF as an alternative Web page format. This failed quite miserably, and they've given up on that idea. However, PDF has found its uses in areas where it's important that the document have an identical appearance no matter where it's taken, such as for legal forms.

Treating PDFs differently, in my opinion, would be akin to a graphics program reading only one kind of graphics format. (i.e. Photoshop not opening JPEGs)

Um, no. It would be more akin to Photoshop not opening Illustrator files. These two programs are about fundamentally different ways of working with data, just as browsers and PDF viewers are.

Further the work flow model of most users invovles them treating them like web pages.

For you, yes. But to be frank, I've never seen anyone else who uses them as such. It's not what they're meant for, and they don't perform as well in that area.

The issue isn't embedding at all. To me that is a red herring. (Although I admit that I will frequently use browsers to view GIFs or JPEGS) The issue is that I don't think PDFs are *used* differently from HTML.

I'd say that embedding is far from a red herring. The primary purpose of a browser is to view HTML, and things which are embedded within HTML such as graphics and Flash (though depending on who you talk to, Flash is basically just another graphics format). PDF is not something embedded into documents, it is instead a completely different document format. It does things differently, and has different strengths and weaknesses. Better to give it its own application, which can be tuned to better suit its quirks, than a browser which was designed for something completely different.

But if you must have it in a browser, that's what plug-ins are for.

[manfreds]

Originally posted by Millennium:

I'd say that embedding is far from a red herring. The primary purpose of a browser is to view HTML, and things which are embedded within HTML such as graphics and Flash (though depending on who you talk to, Flash is basically just another graphics format). PDF is not something embedded into documents, it is instead a completely different document format.

That's not true. The Delphion patent server for example uses PDF inside web pages. This is a very valid application of PDF in my opinion - due to PDF's strengths which excel in exact this case.

Better to give it [PDF] its own application, which can be tuned to better suit its quirks, than a browser which was designed for something completely different.

Honestly, I don't see the problem you have with previewing PDFs inside the browser window before you use them in their own dedicated application. The Finder isn't the perfect program for PDFs (or images, or movies) either and yet it previews them. I didn't hear you complain about that.

[clarkgoble]

HTML is for carrying information. PDF is for carrying a representation of a document.

Exactly what is the difference between "carrying information" and "representing a document"? Both carry information and for both that is the primary purpose. Both also carry information about related documents and have a standardized way for displaying that information. (Although HTML uses it more)

If you mean by representation the appearance of how the informaiton is displayed, you'd have been correct back in HTML 1.0. However the vast majority of additions to HTML have been to provide greater and greater control over the display. This has culminated in CSS.

Don't get me wrong, I think HTML is useful in this fashion and have long decried this move towards making HTML more PDF-like. However to make it as big a difference as you are inclined is simply not applicable.

Now had the original committies done things right and formally separated content and presentation then you'd have a point. I'm not sure that many documents permit such a separation, but at least we are moving that way with XML. However from the beginning HTML was a rather half-assed mixing of content and display. It didn't provide enough "content" mechanisms and hopelessly conflated them with appearance.

About the best you can say about the HTML vs. PDF difference in this regard is that PDF provides a far more static display mechanism than HTML. But I don't think the relative static nature of the documents is an argument for whether it should be displayed in a browser or not.

One, PDF had been around since significantly before the Web became popular. It was, in fact, intended for electronic document exchange, but that's precisely where the difference lies.

Actually they both arose around the same time. HTML arose to help sharing technical files in a network. PDF arose to share documents for printing or reading when you didn't have the original docuement. HTML was original more network centric, but PDF quickly moved in that direction. The only difference was that PDF matched printer output while HTML was far less exacting about display but provided hyperlinking. As I mentioned though PDF came to have hyperlinks and HTML came to have more information about display.

Today both are treated about the same by Google and the majority of browers. Except on the Mac. . .

[Brass]

Bye the way, people, there is the option of using the PDF plug in for Mac OS X browsers available at:

http://www.versiontracker.com/dyn/moreinfo/macosx/16527

[Brass]

Originally posted by clarkgoble:
Actually that is exactly what you can do. That's the whole point. You ought to try some PC browsers. This is a very useful function when you are downloading pages to read later.

I still think you're missing my point completely. You may be able to do this with some browsers, I don't know. But if you can really download an HTML page AS A SINGLE FILE which includes all the embedded graphics, etc, then it is no longer an HTML file at all, because HTML cannot contain graphics, only references to graphics in OTHER FILES.

If instead it downloads the HTML page as a group of files, then that becomes a management problem when really you just want ONE FILE to manage and you've now got a whole group of files just for ONE web page.

Or does it work in some other way still? If so, I think you'll need to explain what really happens.

EDIT:

Actually, come to think of it, I've completely forgotten what my original point was too It's now so obfuscated. I really can't be bothered with this any more. Especially since there IS now a PDF plugin available for OS X (as I posted above).

[clarkgoble]

The problem as I mentioned is that the plug-in is rather buggy. I've been using and upgrading it for some time now. However it is nowhere near as smooth as say Acrobat integration in Internet Explorer in XP.

I've probably spent way too much time on this. And I'm sure most couldn't care less about this debate. If anything I just hope that perhaps the folks writing the new versions of Omniweb and Chimera include this into their products.

BTW - the way most browsers save pages is by saving it in something like a zip file. This is a mht file. You can also save it as a directory with the links recast as relative to the top file. So you can do it either way. I believe that most Windows browsers open mht files, although I mainly just use IE on that platform. (I'm primarily an Omniweb guy on the Mac)

[Brass]

Originally posted by clarkgoble:
The problem as I mentioned is that the plug-in is rather buggy. I've been using and upgrading it for some time now. However it is nowhere near as smooth as say Acrobat integration in Internet Explorer in XP.

Hopefully the new version (just released) has addressed some of these bugs, but in any case, it looks like the developement of this product is ongoing and improving so it shouldn't be long before it's usable and reliable.

I've probably spent way too much time on this. And I'm sure most couldn't care less about this debate. If anything I just hope that perhaps the folks writing the new versions of Omniweb and Chimera include this into their products.

heheh... me too, but I've just remembered what my original point was, so here I go again

BTW - the way most browsers save pages is by saving it in something like a zip file. This is a mht file. You can also save it as a directory with the links recast as relative to the top file. So you can do it either way. I believe that most Windows browsers open mht files, although I mainly just use IE on that platform. (I'm primarily an Omniweb guy on the Mac)

Originally, you said, "Certainly they (PDFs) can be saved to be stand alone data files. But then the same is true of HTML."

But I think that it's now obvious that you cannot save an HTML web page in the same way that you can a PDF file. You've either got to save it as something other than HTML (which involves a lot more than simply saving a file to disk, even if it is hidden from the user), or you've got to deal with a bunch of files in a directory instead of a single file.

Now it still beats me why I was trying to say this, but *sigh* I just can't help myself Maybe I was trying to say something about how different PDF and HTML are... dunno.

[dfiler]

Reading this thread makes me want to pull my hair out! There is so much faulty conjecture about interaction design that its tough to decide what to address first. These armchair GUI-designers need to take a step back and ponder the topic longer...

They are falling into the all too easy trap of feature creep intended to fascilitate a particular workflow. While it is true that embedding a pdf viewer in web browsers will make some or even most users more efficient at some or most tasks, it is still not advisable for a default install. For many this is difficult to understand. Why would you not want to speed up most work flows most of the time? The answer is that by improving the scenario in question, other scenerios are made much worse.

This gets back to my earlier discussion about mode-less computing. While some users interact with pdf and web pages in similar manners, this is not always the case. It is when users really start interacting with these document formats, rather than just reading simple text and graphic files, that a unified interaction model breaks down completely. One action can have completely different results based upon the 'mode' that a user is in, the type of document they are interacting with. This is what I mean by overloaded commands. The same action can have multiple outcomes. Avoidance of command overloading and interaction modes is one of the first tenants in the field of human computer interaction. Users get lulled into thinking that they understand how to interact with web documents and construct an appropriate mental model of the underlying process. However, on occasion they will stray into the disparate regions of the two command sets. They won't necessarily realize this.

Off the top of my head, here's an incomplete list of how pdf and web page interactions differ:

availability of user defined display preferences
document saving behavior
document opening behavior
file size considerations
navigation shortcuts
form submission
control focus selection
keyboard shortcuts
toolbar/frame associations
print scaling
window resizing
font selection for viewing and printing
right click behavior
text flow behavior for viewing and printing
dynamic content behavior
menu contents
page element selectability
granularity of user accessible elements
expected feedback mechanisms
general command availability
... nearly every form of interaction is different including scrolling!

There are very good reasons why pdf and web-pages should be accessed though different applications.

Is anyone else glad that software isn't designed by MacNN forum consensus? ;-)

[dfiler]

I thought of one more significant difference, Caching.

It is hard enough for most users to build a mental model for a web browser's caching mechanism. Entire web pages can be cached, images can be cached, form-fields and cookie data is cached. Throw pdfs into the mix and they'll be even more confused. I actually watch people at my workplace repeatedly 'refresh' pdf-web-pages because they think it didn't 'load' completely or properly. Then they try changing the window and text size to see if that was the problem... heheh

In the physical world, we are well adapted for using interaction-A with object-A while using using interaction-B with object-B. People, especially at work, are quite habitual creatures. The sheer presence of an object calls to mind its associated interaction model. By using two separate applications, we are reinforcing the concept that pdfs and web pages are not the same thing. Users are less likely to preform habitual, but incorrect actions during their rote workplace tasks.

[clarkgoble]

Ok, I was going to drop the topic, but there are a few interesting questions in the below. Further they get at my point about keeping a separation between user experiences and underlying program structures and data.

But I think that it's now obvious that you cannot save an HTML web page in the same way that you can a PDF file. You've either got to save it as something other than HTML (which involves a lot more than simply saving a file to disk, even if it is hidden from the user), or you've got to deal with a bunch of files in a directory instead of a single file.

This is the prime example of confusing programming issues with "data" issues. Ideally a user shouldn't care whether something is or isn't HTML. The point you make is only a concern if you are dealing with and generating HTML files. i.e. you care about the way the program is written. To the typical user they don't care what is or isn't an HTML file. They just care whether they can save it and open it up. And most browsers do just this. Can you put this saved file on a server? I actually think you can with Microsoft's server. If you save it as a directory you can with Apache and others as well. Can you double click on it and get what you were looking at back? Once again yes.

The point is that you've confused how the user interacts with their web browsing experience with how the programmer handles this. From a programmer's point of view keeping PDFs and HTML files separate is important. For the typical user they are just documents that they want to see. (Recognizing that editing isn't an issue of the browser)

What you are arguing for is a fundamental difference in interface because of a slight programming difference that is hidden from most users. The Illustrator / Photoshop example doesn't fit because they involve fundamental different ways of encountering the data. Both a web browser and Acrobat are for displaying and possibly searching documents. Illustrator is for a way of editing documents that is different from how one edits Photoshop. For Illustrator you are grabbing and manipulating subparts of the document. For Photoshop you have layers, but beyond that you are applying filters and "painting." Metaphorically one is like painting while the other is like moving around pieces of cutout paper.

(BTW - I believe both Photoshop and Illustrator can import and view each others data within each program. So your example is poor for that reason as well. If we adopt your example then consistency requires that Chimera open PDFs internally)

The way one interacts from an interacting perspective isn't in PDF and HTML. For those documents the way in which we encounter them is to view them, to scroll within them, to copy text, and to print. That's about it. There isn't a difference in our way of encountering them that isn't fundamentally due to the impositions of programmers based upon their programming and not the nature of the data.

[clarkgoble]

A few more comments for Dfiler.

There is so much faulty conjecture about interaction design that its tough to decide what to address first.
. . .
They are falling into the all too easy trap of feature creep intended to fascilitate a particular workflow.

I don't think that is a fair characterization of my position. I'm not emphasizing a particular way of workflow. (Although I used a particularly common workflow to illustrate my point) The issue is the underlying ways of encountering the phenomenological objects we work with. My work flow is one way to have a process using those phenomena. However radically other workflows are possible, and often even advisable. The point is though the fundamental objects and ways of encountering those objects.

When you list your examples of why PDFs ought to be treated differently than HTML all of your examples are not based upon how we think of the objects (the documents themselves and what they represent) but rather the ways in which programmers have limited our encounters with them. Thus fundamentally your argument is one based upon circular logic. It should be programmed in this way because of the ways in which PDFs and HTML are programmed.

The interactions you list are, what they are, because of how the programmers have written them. Certainly I agree that different programs can work on similar data in different ways. For instance Omniweb and Preview can both open up JPEGs but there are differences in how we work with them.

So your complaints are really not about how PDFs and HTMLs ought to be handled. Rather you simply point out that at the moment on the Mac they are handled different. As I said though, that's circular logic. (Several are wrong, as well, such as "Font Selection for Viewing and Previewing" - most HTML don't let the viewer specify that) Also your point about Caching is irrelevant since both HTML and PDFs that aren't saved are cached in the same basic way. (In some temporary directory that gets cleared at some point) If I want to keep a HTML or PDF I do it in the same way - with the Save command.

To discuss caching issues is a perfect example of defining an interface based upon how the programmer implementation issues. The interface should not be defined by the programmer's ways of encountering the data but by the user's ways of encountering the data. To a user most aspects of caching should be hidden. To make an analogy, the user of a computer shouldn't have to worry that much about the algorithms used for its virtual memory. In the same way the user shouldn't worry about caching, except for power users specifying limits on storage space by time or size.

[Brass]

Originally posted by clarkgoble:
This is the prime example of confusing programming issues with "data" issues. Ideally a user shouldn't care whether something is or isn't HTML. The point you make is only a concern if you are dealing with and generating HTML files. i.e. you care about the way the program is written. To the typical user they don't care what is or isn't an HTML file. They just care whether they can save it and open it up. And most browsers do just this. Can you put this saved file on a server? I actually think you can with Microsoft's server. If you save it as a directory you can with Apache and others as well. Can you double click on it and get what you were looking at back? Once again yes.

The point is that you've confused how the user interacts with their web browsing experience with how the programmer handles this. From a programmer's point of view keeping PDFs and HTML files separate is important. For the typical user they are just documents that they want to see. (Recognizing that editing isn't an issue of the browser)

Well, by that logic, we ought to be viewing everything in a web browser, no matter what the file format is.

Yes, that is a nice ideal, but in the real world it just doesn't work well (at least not on any system I've seen). And yes, I've used Acrobat plug-ins on a few different browsers in a few different OSs and I think it works much better when it uses a stand-alone help application, but that's a matter of opion, it seems.

What you are arguing for is a fundamental difference in interface because of a slight programming difference that is hidden from most users.

Hidden, is arguable, as any user can tell the difference between an HTML and PDF document, even when both are viewed in a browser.

SLIGHT? Are you for real? Have you ever programmed either? The programming difference is enormous (both for viewer applications/plug-ins, and for the files themselves).

(BTW - I believe both Photoshop and Illustrator can import and view each others data within each program. So your example is poor for that reason as well. If we adopt your example then consistency requires that Chimera open PDFs internally)

I've no idea what your refering to here, so I guess your talking about somebody else's post(s) here.

[dfiler]

Originally posted by clarkgoble:
all of your examples are not based upon how we think of the objects (the documents themselves and what they represent) but rather the ways in which programmers have limited our encounters with them.

Hehheh

And damn them hodna engineers for limiting my accord's flying capabilities.

A user can only interact with the interface that is provided. We shouldn't pretend that the two formats and associated interactions are the same just because that's the way it should be.

[clarkgoble]

A user can only interact with the interface that is provided. We shouldn't pretend that the two formats and associated interactions are the same just because that's the way it should be.

Um. Yeah. Duh.

I think you missed my point. The issue isn't the limitations of any particular interface or what a poor interface allows a user to do in odd ways. If that were the case then we end up just saying that any old interface will do.

A good book on the point I'm trying to make is Paul Dourish's Where the Action Is: The Foundations of Embodied Interaction. This will be my last post on an already over-extended topic. So if you are interested you might check it out at your library. It is all about interfaces and the philosophy behind human-computer interactions.

Basically we encounter data and utilize that data. A good interface tries to utilize natural metaphors and interactions that enable us to utilize tools and documents without thinking about it. For instance when you are driving a car, you don't typically think about turning the steering wheel to turn the wheels. It just happens. This isn't just because it has become instinctive but rather that the steering wheel is a natural way of dealing with how a car operates and our interactions through the car with the road. Ideally you stop thinking about the car entirely and just think about driving.

The same thing happens with pens and mice. You only notice them when they stop working.

What I'm trying to get across is that the fundamental ways users encounter PDF files and HTML files isn't that different. Yes, from a programmer's point of view they are different. But from a user's point of view they aren't. That's why I contrasted their similarity with the difference between Illustrator and Photoshop documents. In those cases the nature of the document (not just the interfaces) leads to very different kinds of applications.

All the examples you guys have given are from the programmer's side of things. You don't even discuss how users use PDFs or HTML to achieve a goal except in relation to how programmers set it up.

That is such a fundamental point that if we can't agree on that we probably won't agree on anything. It is that point that leads, I think, to many of the problems of applications under Linux. They tend to be driven from a programmer's perspective rather than the nature of how the document will be used. On the XP side of things Microsoft goes part way, but instead of thinking through the uses of a tool or document they simply provide Wizards or invisible helps to get the user through. However those then cause a "break" with the unconscious use of the tool. (It would be akin to having a car break for you when it thought you were speeding or needed to slow down)

The original Macintosh really thought through a lot of these issues. It used metaphors to aid users in manipulating documents and tasks, but typically limited metaphors and metaphors that were action oriented. (The original Inside Macintosh really emphasized verbs in its functions) Apple moved further along this path with OpenDoc but many problems kept the document-centric view from succeeding. Some of these were management issues but many others were because emphasizing documents to the exclusion of other things ignores many crucial aspects of how we interact with documents - how we use them. Most implementations of document-centric or even object-centric computing unconsciously impose "modes" on ones ways of working with the computer.

My point is to think of what HTML documents are for from a user's (not programmers) perspective and also for PDFs. Once you think about how users manipulate and use such things for many tasks you reduce those actions to a basic kind of interaction and phenomena. That then ought to guide ones user interfaces.

Typically interfaces guided by programming structures impose great limits on interactions.

[clarkgoble]

Well, by that logic, we ought to be viewing everything in a web browser, no matter what the file format is.

Not at all. Actually only certain kinds of documents are primarily browsed. For instance Photoshop documents are primarily manipulated to change color, tint, and then paint. The primary use is thus editing along a certain kind of tasks. Illustrator is once again editing based, but with a different set of ways the user encounters the document. Different still with programming code.

Indeed I'd say one problem with computing at present is the tendency to put everything in the browser. Many actions and interactions with computers are placed within a browser environment when it really ought to be a separate application. That is one reason why Sherlock and Watson are moving in the right direction. They are recognizing that the browser isn't the best way of doing certain tasks. They aren't perfect, but I think they are an excellent break from a browser-centric approach.

Probably the worst offender here are the many, many administrator tools on Linux that are browser based. (The Samba tools come to mind) That once again is thinking from a programmer's point of view. They work and there are excellent reasons why the programmer did things that way. (It is a cheap and easy way to get remote control, for instance) But from an UI point of view they are a step back.

Microsoft is an offender as well mixing its version of the Finder, Windows Explorer, into the browser model. While XP isn't quite as bad as 98 was, it still tended to cause quite a bit of confusion, interface wise. (IMO) The problem was that fundamentally the way we manipulate files and organize them is different from how we go about browsing documents. There are some sub-tasks that they share. For instance I think file management programs ought to offer previews that parallel what a browser does to some degree.

Yes, that is a nice ideal, but in the real world it just doesn't work well (at least not on any system I've seen).

My point is that a PDF ought to be treated as just an other read-only document. If you want to save it rather than just browse it then you ought to save it locally the way you do other read-only documents you browse. If you want to open it up an other window, you ought to be able to do that the way you can other documents. A PDF is different from say a zip file or sit file you download. You treat it differently and interact with it differently.

Make no mistake. I'm not saying that PDFs should only be viewed within the browser. If you prefer it in a separate window automatically downloaded to your download directory that is fine. Because what I'm saying is that is one way in which people use documents. I do that same thing with many HTML files I read. However I also open up read-only documents by moving between them in a browser. Those are two common ways of dealing with text presentations. I want the freedom of manipulating them in that way.

BTW - I strongly disagree with you on "how well it works." Hopefully you are characterizing "how well it works" on the basis of "how much I prefer it."

SLIGHT? Are you for real? Have you ever programmed either? The programming difference is enormous (both for viewer applications/plug-ins, and for the files themselves).

Yes, I program for a living. It is a slight difference compared to different programming functions. For instance how you program displaying a document is very different from how you program calculating prime numbers. The implementations between a PDF and a HTML clearly are different. However if you are calling an API rather than writing the code yourself the APIs are likely to be very similar.

Once again I'm trying to focus on the difference between using a piece of data or object and how you implement that. This is a basic programming concept that has been around for decades (hiding implementation) so it shouldn't be that new to you.

But clearly our basic assumptions and philosophy of computing are different. I'll not pursue the topic further.

[tooki]

Originally posted by Millennium:
To be honest, I'd prefer it if even image format support were made into a set of plug-ins. Slim the browser down even further. Did you know that most browsers reinvent the wheel completely with their image display code? For the Mac, for example, there is perfectly good code in QuickTime for displaying GIF, JPEG, PNG, and many other image formats, and they do it even better than most browsers because QuickTime's code tends to have such niceties as ColorSync support built in. But the only browser to leverage this code is iCab. All the other browsers out there bloat themselves by using their own code to do exactly the same thing. I'm not sure, but I think that even the current version of OmniWeb does this.

I assume that the primary reason for keeping image support native is speed. It is doubtless faster to call code that's in the browser (or a browser library) than to first call QuickTime or a plugin. The other reason I can see is making it unbreakable. Imagine the tech-support nightmare it would be to have users deactivating, say, the JPEG and GIF plugins...

Oh yeah, IE5 supports ColorSync on both OS 9 and Classic.

FWIW, I hate inline PDF viewing, at least on Mac OS 9, where the Adobe PDF plugin would even be reinstalled if you dared open Acrobat Reader without changing preferences! The Adobe PDF plugin, IMHO, is so slow that it's annoying (the Windows version seems to be a lot better.)

trusted_content wrote:

How about PNG, eh? IE still doesnt support it natively, and when I try to select an app to open it with, Preview is grayed out. Isn't that just lovely.

Uh, IE does support PNG natively. It's just not set to do so by default (why is beyond me). Just go to the file helpers preference panel and set PNG to View with Browser. (There may be several for .png; set them all to View with Browser.)

tooki

[KidRed]

Not sure if this is the same plugin as mentioned above, but yes, PDF is now viewable in borwsers-

http://www.schubert-it.com/plugin/

[Millennium]

Originally posted by clarkgoble:
HTML is for carrying information. PDF is for carrying a representation of a document.

Exactly what is the difference between "carrying information" and "representing a document"? Both carry information and for both that is the primary purpose.

Yes, but the type of information is very different. PDF carries information about what a document looks like. HTML carries information about what a document says.

Each spec has also been designed for totally different purposes. PDF was designed, first and foremost, to be printed; this is why all PDF documents are broken into pages. It's not a matter of how is is programmed; it is intrinsic to the concept of PDF itself. Similarly, HTML was designed to be viewed on a computer screen, which is why we don't see things like pagination controls in HTML (though CSS2 provides some ability to control pagination).

This is also why, for example, PDF did not get the ability to display links or forms until long after its introduction; Adobe was attempting to bolt screen functionality onto a format designed for printing. This wasn't enough to make it the next Web page format (which is why you almost never see links in PDF files anymore), but the form functionality flourished, because it fit in with the primary function of PDF: printing files. With the form functionality, rather than printing a form and filling it out, you could print an already-completed form.

But the fact is, they remain different file formats, designed for different purposes. They're both good in some areas and poor in others, but the big thing is, they're best served by different interfaces, which can take advantage of the strengths of their given formats.

[dfiler]

Originally posted by clarkgoble:
A good book on the point I'm trying to make is Paul Dourish's Where the Action Is: The Foundations of Embodied Interaction.

Not a bad read but I've always found Dourish's work to be a bit too ivory-tower / pie-in-the-sky. His advocacy of embodied action isn't very applicable to the discussion of merging two, well-entrenched formats. His approach to interface design is better suited for guiding long-term software industry design paradigms. It provides a good foundation for conceptualizing interfaces in a way that is most useful for the end user.

Originally posted by clarkgoble:
What I'm trying to get across is that the fundamental ways users encounter PDF files and HTML files isn't that different. Yes, from a programmer's point of view they are different. But from a user's point of view they aren't.

Some of the time the formats are encountered in similar contexts. However, if a user tries to use both with a single interaction technique, they will likely fail.

Originally posted by clarkgoble:
All the examples you guys have given are from the programmer's side of things. You don't even discuss how users use PDFs or HTML to achieve a goal except in relation to how programmers set it up.

None of the examples in my list are "from the programmer's side of things". You refer to the way programmers 'limit' users and imply that most software is poorly designed. Heheh... Sure, it would be nice if there were but one document format, but there isn't. In the mean time, we shouldn't unify the GUIs for document editors unless their interaction sets are nearly identical.

Originally posted by clarkgoble:
My point is to think of what HTML documents are for from a user's (not programmers) perspective and also for PDFs.

I think this is at the root of our debate.

I am advocating the separation of pdf and webpage apps despite their having similar, typical-use scenarios. It is important to consider more than the typical scenario. It is when users deviate from their typical workflow that they derive the largest benefit from having a valid mental model for underlying technology. I'm not advocating that they fully understand the underpinnings, merely that their approximation won't get them into trouble.

The process of form submission is enough of a difference to cause unexpected and catastrophic results. Imagine a user filling out an imbedded-pdf tax form. Do they submit the form? Do they save it? What happens to its dynamic content if they hit the back button? If they save the document, can they fill it out later and then submit it? The underlying document formats and associated editor capabilities do make a difference in the real world. Giving people the false impression that these two formats can be interacted with in the same manner is a recipe for disaster. (some of the time)

I now officially take back my arm-chair GUI designers comment... Its nice to see mac users putting this much thought into interaction design! It looks like we simply disagree on the degree of similarity between pdf and html user interactions.

[clarkgoble]

OK, I said I was going to drop the thread, but both of you made some good points. I think DFiler is probably right regarding our main difference. So just a few minor comments.

Not a bad read but I've always found Dourish's work to be a bit too ivory-tower / pie-in-the-sky. His advocacy of embodied action isn't very applicable to the discussion of merging two, well-entrenched formats.

Hmm. I'm not sure I agree. But as you said later, that is the core of our disagreement. I don't think document format really ought to factor in. It gets back to my comment about implementation being hidden.

I admit that I was overall disappointed with Dourish, but that is partially because one of my degrees is in philosophy. So I was already very familiar with phenomenology, Husserl and Heidegger. So many of the basic approaches Dourish made were already old hat to me. (Several of his examples are famous phenomenological examples) I do tend to recommend the book to people not familiar with philosophy. I think it does change how people view things. I tend to think that a nice mixing of theory and practice are appropriate. So I tell them to read Dourish for the one and TOG for the other.


Imagine a user filling out an imbedded-pdf tax form. Do they submit the form? Do they save it? What happens to its dynamic content if they hit the back button? If they save the document, can they fill it out later and then submit it? The underlying document formats and associated editor capabilities do make a difference in the real world. Giving people the false impression that these two formats can be interacted with in the same manner is a recipe for disaster.

This is an excellent point. Please recognize that I am not suggesting that all features of PDF or HTML be available in a browser. You emphasize the ways in which a PDF is editable. However that is true of HTML as well. The way in which I interact with an HTML document in a browser is different from how I encounter it in Adobe Go Live.

So to utilize the document in a fashion different from how the browser allows has to involve a change of application. (This is why, as I alluded earlier, I'm opposed to na�ve document-centric interfaces - they ignore the wide range of ways we use documents and favor a "one size fits all" approach)

I should add that this is a place where Microsoft went wrong. In my previous job doing some IT they had remote clients opening up MS-Word documents. The problem was that Microsoft opened it up within the browser. (This was back during the height of Microsoft's browser-centric days) However clients were confused about what to do with the documents. They weren't read only but they didn't behave the way other Word documents did. In my opinion MS should have made Word documents appear only as read only if they were to appear in the browser. Further they should have made it more straightforward to decide between the two.

I think that is more or less your complain about PDFs. So I agree to a point. Ideally Adobe should have had two document formats here. One that was primarily a document exchange format and then a modified version of this for doing forms. I admit that I'd not thought of forms since the only time we've used those in Acrobat was while exchanging legal documents for a contract. Even then it was a bit of hassle I'm told.

One last point. What you bring up is one of the problems with browsers in general. For instance I am writing this in an interactive field. So the problem with PDFs isn't unique. If forms are enabled in a browser based PDF then plug-in or interface must mimic the way these are encountered in browsers. I must admit that I think that the web has a big problem with interface in this regard. It tended to develop quickly in a rather poorly thought out manner. (Partially due to Microsoft, partially because it was the "latest thing" and became a catch all) I'd hoped Java would help cure this by opening up windows for these sorts of things. However in practice that never happened.

[cpac]

Originally posted by clarkgoble:
Please recognize that I am not suggesting that all features of PDF or HTML be available in a browser.

Ah-ha! that's it you see.

All the features of HTML are there SO THAT they are available in a browser. That is the reason for the existence of HTML.

.pdfs are fundamentally different. I can manipulate, highlight, fill out forms, etc. with them.

HTML by comparison - if the functionality doesn't show up in a browser, there's no point to it (at least, as you stress, from a *user's* point of view).

[clarkgoble]

The only browser I know of that can edit HTML is Mozilla (or was it Netscape? One of those two). Coincidentally I consider both Mozilla and Netscape to be bloatware.

That's why I brought up the difference between how a program like Go Live allows one to deal with HTML and how a browser allows one to deal with HTML.

[Developer]

.