[Printing-architecture] Common Dialogs for Printing

[Printing-architecture] Common Dialogs for Printing

[Petrie, Glen]

[-- Attachment #1: Type: text/plain, Size: 4514 bytes --]

All,

 

I guess the addition of the actual preview to the CPD has triggered more
review of CPD from my perspective.

 

I hope and believe the key object of this effort is focused on "Common".
Thus, I now believe we may be trying to do too much in the CPD and
actually need three common dialogs; specifically, the Common Preview
Dialog (CRD), the Common Print Dialog (CPD), and the Common
Status/Monitoring Dialog (CSD).  

 

Actually, what we call print preview is really "preview of the page
setup" or "layout".  It is expected that printer will print the page as
shown in the "print preview" or "page preview".   So is this the "print
preview" or the applications "page preview"???

 

Background:

1.	We should learn from what other OS / Application have evolved
from or to.
2.	We have now have usability test data and results but I have not
seen use-cases.

 

 

Print Preview Dialog:

*       As Johannes stated and I agree, I use Print Preview but only
about 20% of the time (maybe less); the other 80% I am not concerned
with how the content will appear printed or I already know.  The key,
however, is that when I want to print preview I am interested in the
details that really cannot be obtained from a thumbnail representation
of the content.  Example 1; I want to know what rows/columns of my
spreadsheet will fit on a page and will I be able to read the content
once printed.  Example 2; I want to place an image at a specific place
on the print page.   The point is I will need to see the print content
at full scale (as rendered to the screen resolution as a representation
of the print resolution).

o        In this case, I am willing to wait for what ever the needed
processing time is to render the print content because reviewing the
rendered print content is what I want to do.

*       Thus, this needs to be a separate callable dialog from an
application that has the emphasis on panning or zooming of a single page
while stepping through individual pages.  It could have operations to
show margin positions, hole punch locations and other normally invisible
markings/attributes.

 

 

Print Dialog:

*       When I print, however, 95% of the time I want to see a symbolic
representation of the print options.  That is, which edge is selected
when duplex printing, where are the punch hole locations, is the print
BW or color, is the media in portrait or landscape mode.  None of these
and other print options require the actual print content.

o        In this case, I am not willing to wait for a thumbnail
representation of my actual print content because it adds no value to
setting print options.

o        Having a consistent symbolic representation is critical because
it makes it easier to quickly identify what options I have set or have
not set.

*       Therefore, I really support using the previous version of the
CPD along with a symbolic representation of the print options. 

 

Status/Monitoring Dialog:

*       Some days I want to see this dialog and others days it is very
annoying; so careful consideration of this dialog is important.

o        I don't want see ink/toner levels every time I print. 

o        I don't want see supply levels (waste, paper, trays) every time
I print.

*       What do I want to see?

o        I would like to have the option of three type of dialogs

*         1. A popup dialog box (option to auto close when complete)

*         2. A desktop iconic (with start, % complete, done)

*         3. An application bar (like the % indicator when downloading a
file)

o        First thing, and not really shown today, I want to know if the
printer really accepted my job

o        I want to know what page, of the total pages, is being printed
right now -- not just spooled.

o        I want to know what percentage of the current page has actually
been printed right now at the printer; not just spooled.

*         Yes, there could be a indicator that the print content has
been spooled - therefore, the user know that print content is ready for
physical printing.

o        I want to know when the job has completed.

*       What I do not want to see?

o        I do not want a dialog to popup with "Job Complete" that would
interrupt the work I may be doing to address an "OK done" dialog.

 

I think I will leave out any other details until I hear feedback from
reading this email.

 

gwp

 


[-- Attachment #2: Type: text/html, Size: 20993 bytes --]

Re: [Printing-architecture] [Printing-summit] Common Dialogs for Printing

[Petrie, Glen]

> -----Original Message-----
> From: Michael R Sweet [mailto:msweet@apple.com]
> Sent: Friday, April 17, 2009 9:05 AM
> To: Petrie, Glen
> Cc: printing-architecture@lists.linux-foundation.org; printing-
> summit@lists.linux-foundation.org
> Subject: Re: [Printing-summit] Common Dialogs for Printing
> 
> On Apr 17, 2009, at 8:15 AM, Petrie, Glen wrote:
> > All,
> >
> > I guess the addition of the actual preview to the CPD has triggered
> > more review of CPD from my perspective.
> >
> > I hope and believe the key object of this effort is focused on
> > "Common".  Thus, I now believe we may be trying to do too much in
> > the CPD and actually need three common dialogs; specifically, the
> > Common Preview Dialog (CRD), the Common Print Dialog (CPD), and the
> > Common Status/Monitoring Dialog (CSD).
> 
> I really don't think this is necessary or useful in the long term.
> The whole idea of providing a common print dialog is to provide a
> common programming interface so that it is possible to unify key
> application UI between GUI toolkits and NOT to (re)write all of the
> printing system UI beyond the application.
> 

What!  I hope the goal is a much more than just the APP-API's -- this is only a small part of the issue.  The principle issue is to provide the User with a common print experience no matter what application they are doing.  That includes preview, that includes print options; that includes status monitoring. Therefore, this is about having a set of common printing system UI's for all applications to call and User to use.

> Status monitoring exists separate from the application for a reason -
> you don't want multiple windows coming up, one for every job that is
> printed.  We already have monitoring applications/applets for both
> GNOME and KDE - there may be room for improvement, but that is another
> effort entirely.  Let's please keep the focus on the print dialog.

I never stated that status monitoring should be called by the application for the vary reason you state - but I want a common one. (Use what CUPS; maybe yes, maybe no)

I am focused on Printing from the User perspective; that includes preview, that includes print options; that includes status monitoring.

Yes, GNOME and KDE already have these; the issue is that GNOME and KDE have different app/applets for monitoring and the goal should be common printing dialogs for the User.

> 
> > Actually, what we call print preview is really "preview of the page
> > setup" or "layout".  It is expected that printer will print the page
> > as shown in the "print preview" or "page preview".   So is this the
> > "print preview" or the applications "page preview"???
> 
> Ideally applications should be providing a print or page view if they
> are page-oriented (that's the whole point of WYSIWYG, right?)
> 

Even if they are page-oriented or not there should be a common print/page preview for all applications to use so that the user has a common experience on what they consider to be a print function/operation.


> The print dialog provides additional layout options - visualizing them
> improves usability, and seeing the actual content that is getting laid
> out is even better. On the desktop, preview time (especially for low-
> resolution previews that only exist to help the user visualize layout/
> finishing options) is insignificant for most documents, and for those
> that take a few seconds to render we can show some sort of progress/
> activity imagery.
> 
> It doesn't matter that print preview might steal cycles from a video
> player and cause skipped frames - the user is printing something and
> is focused on that activity!

Not really, I (as a user and print driver developer) do not want or support printing ever being the focused activity.  Printing is and will always be a background function/operation.  I/Users want to submit a print job and go on to something else.  Why should printer interrupt anything else I am doing unless there is a problem!


> 
> It doesn't matter if this won't work on an embedded device - embedded
> devices have much different UI requirements and capabilities and will
> not be using this print dialog!
> 

I am not addressing embedded or mobile device at this time.  We have enough to do just getting a common print experience for desktop users.

> >
> > Background:
> > 	* We should learn from what other OS / Application have evolved
> > from or to.
> 
> Windows has no preview and provides up to 6 layers of dialogs to set
> printer and layout options.
> 
> Mac OS X has a standard built-in preview that is driven directly by
> Cocoa applications - we call the applications "draw" method on the
> view they have asked us to print to get  it. The preview is drawn in a
> separate thread so that the UI does not become unresponsive.
> 

Again, from the User point-of-view, they see "printing" as preview, print options and status.  Whether that done in the application, OS, spooler, etc, it does not matter to them.

> > Print Preview Dialog:
> > n       As Johannes stated and I agree, I use Print Preview but only
> > about 20% of the time (maybe less); the other 80% I am not concerned
> > with how the content will appear printed or I already know.  The
> > key, however, is that when I want to print preview I am interested
> > in the details that really cannot be obtained from a thumbnail
> > representation of the content.
> 
> You are not the user.

What!  I am illustrating a point by stating my experience as a User.  You missed the point of the paragraph.

> 
> >   Example 1; I want to know what rows/columns of my spreadsheet will
> > fit on a page and will I be able to read the content once printed.
> > Example 2; I want to place an image at a specific place on the print
> > page.   The point is I will need to see the print content at full
> > scale (as rendered to the screen resolution as a representation of
> > the print resolution).
> 
> IMHO, the application should be providing a mode so you can see this;
> Excel does this, Numbers does this, I think even OpenOffice does this
> (though I haven't used OpenOffice spreadsheet in a long time so I
> can't be sure...)
> 
> In any case, on the Mac we have a button (the "PDF workflow" button)
> that allows you to get a large preview (in the Preview application, of
> course :)
> 

Again, I am prompting a common preview dialog.  Why should each application write what is the same code for the same function but provide the user with a different experience for each application. 

Mac may be POSIX but not open-source and not Linux.  Windows is not open-source. Both are developed by private companies and thus, a measure of control for system level functions like printing dialogs, status monitoring, etc.  Open-Source is a free to do what they want.  I believe we are proposing a common set of dialog to applications and users on an area (printing) that they really don't want to write code for nor support. 


> > Print Dialog:
> > n       When I print, however, 95% of the time I want to see a
> > symbolic representation of the print options.  That is, which edge
> > is selected when duplex printing, where are the punch hole
> > locations, is the print BW or color, is the media in portrait or
> > landscape mode.  None of these and other print options require the
> > actual print content.
> 
> You are not the user.
> 

What!  I am illustrating a point by stating my experience as a User.  You missed the point of the paragraph.

> > o        In this case, I am not willing to wait for a thumbnail
> > representation of my actual print content because it adds no value
> > to setting print options.
> 
> You are not the user.
> 

What!  I am illustrating a point by stating my experience as a User.  You missed the point of the paragraph.

> > o        Having a consistent symbolic representation is critical
> > because it makes it easier to quickly identify what options I have
> > set or have not set.
> 
> I have a hard time understanding what all of the "universal symbol"
> idiot lights on my car's dashboard mean. Do you expect a non-printing-
> professional to have a clue what a particular icon means WRT any
> particular printer option?

Yes non-printing-professional do have a clue.  I believe they already understand what the symbolic representations means; it is shown in most (windows) print dialogs today.  Remember, the thumbnail is just a visual aid to the actual print option the user has selected.  Thus, the option setting (button on or off) really tell the user what to expect.

> 
> > n       Therefore, I really support using the previous version of
> > the CPD along with a symbolic representation of the print options.
> 
> Symbolic representations only work by themselves when they are truly
> universal - skull-and-crossbones, stop sign, etc. There is a reason
> why applications have text and icons in toolbars - you need to learn
> the associations.
> 

I am surprised that you have not seen the symbolic (iconic) representation of collated versus un-collated print of multiple copies; and the many other representation of print options that are in use today.  

> A picture of what the printout will look like is the best symbolic
> representation we can provide.
> 

What value does it add to see a thumbnail of a web page with 3/4" (scaled down in five pixels in the thumbnail) in setting number of pages, duplex, color/bw, landscape/portrait, n-up, etc.  And, if I could agree it has value; what is the cost in processing time.   I really don't believe user want printing to take a lot (any) processing time.


> > Status/Monitoring Dialog:
> > n       Some days I want to see this dialog and others days it is
> > very annoying; so careful consideration of this dialog is important.
> > o        I don't want see ink/toner levels every time I print.
> > o        I don't want see supply levels (waste, paper, trays) every
> > time I print.
> > n       What do I want to see?
> > o        I would like to have the option of three type of dialogs
> > §         1. A popup dialog box (option to auto close when complete)
> > §         2. A desktop iconic (with start, % complete, done)
> > §         3. An application bar (like the % indicator when
> > downloading a file)
> > o        First thing, and not really shown today, I want to know if
> > the printer really accepted my job
> > o        I want to know what page, of the total pages, is being
> > printed right now -- not just spooled.
> > o        I want to know what percentage of the current page has
> > actually been printed right now at the printer; not just spooled.
> > §         Yes, there could be a indicator that the print content has
> > been spooled - therefore, the user know that print content is ready
> > for physical printing.
> > o        I want to know when the job has completed.
> > n       What I do not want to see?
> > o        I do not want a dialog to popup with "Job Complete" that
> > would interrupt the work I may be doing to address an "OK done"
> > dialog.
> 
> I believe you have described what is already available on all the
> popular distributions with their print status monitors.
> 

Everything we are talking about in this email, including Print Dialogs, already exists; the point is to create a common everything so application and users have common experience.



> ____________________________________
> Michael R Sweet, Senior Printing System Engineer
> 
> 

Re: [Printing-architecture] Common Dialogs for Printing

[peter sikking]

Glen wrote:

> I guess the addition of the actual preview to the CPD has triggered  
> more review of CPD from my perspective.
>
> I hope and believe the key object of this effort is focused on  
> “Common”.  Thus, I now believe we may be trying to do too much in  
> the CPD and actually need three common dialogs; specifically, the  
> Common Preview Dialog (CRD), the Common Print Dialog (CPD), and the  
> Common Status/Monitoring Dialog (CSD).
>
> Actually, what we call print preview is really “preview of the page  
> setup” or “layout”.  It is expected that printer will print the page  
> as shown in the “print preview” or “page preview”.   So is this the  
> “print preview” or the applications “page preview”???

without a doubt _and_ proven by our first tests: the preview needs to be
a lo-res version of exactly what will come out of the printer.

the good thing about usability tests is that it shuts down, for ever,
endless discussions about what users really need.

> Print Preview Dialog:

this station is long past. see above.

may I remind you all that is is 100% part of the design that when
the transformation (formatting for paper) is for users creative/
tricky/involved that then we recommend applications to show
a dialog (the size of the actual application window) to let users
hands-on control the transformation. this includes for instance
sizing a spreadsheet (with the mouse, not by some number fields)
across a grid of pages, or placing that image (for hi-end graphics
apps like GIMP, inkscape) exactly on the page.

from this transformation dialog the choice is going to be
'just print' or to go through the print dialog.

> Print Dialog:
> n       When I print, however, 95% of the time I want to see a  
> symbolic representation of the print options.  That is, which edge  
> is selected when duplex printing, where are the punch hole  
> locations, is the print BW or color, is the media in portrait or  
> landscape mode.  None of these and other print options require the  
> actual print content.
> o        In this case, I am not willing to wait for a thumbnail  
> representation of my actual print content because it adds no value  
> to setting print options.
> o        Having a consistent symbolic representation is critical  
> because it makes it easier to quickly identify what options I have  
> set or have not set.
> n       Therefore, I really support using the previous version of  
> the CPD along with a symbolic representation of the print options.

like Mike said: you are not the user. please...

with your knowledge of how it all works you are separating things out
that are not separate for any non-printing-industry user.

remember the video clips I showed: the only thing that counts is
the hardcopy that comes out of the printer. the preview as an integral
part of the dialog reflects that fact.

> Status/Monitoring Dialog:

as I said: next project.

     --ps

         founder + principal interaction architect
             man + machine interface works

         http://mmiworks.net/blog : on interaction architecture

Re: [Printing-architecture] Common Dialogs for Printing

[Petrie, Glen]

The email I sent was to start a discussion; not a war.  But, I gather
from your replies; "that it is your way or no way".

Thus, I would like to stop this email thread and return to something
else. Please..................

Glen

P.s.

I sorry, I am a user.  I have been a user, architect and developer on
everything from embedded, handheld, mobile, desktop, office, and
production printing solutions including front-end and back-ends.

And Please..... two people in one usability test does not define a
solution!!!!!!!!!!!!!!!

Peace ...............  please ...............

glen
> -----Original Message-----
> From: peter sikking [mailto:peter@mmiworks.net]
> Sent: Friday, April 17, 2009 11:50 AM
> To: Petrie, Glen
> Cc: printing-architecture@lists.linux-foundation.org; printing-
> summit@lists.linux-foundation.org
> Subject: Re: [Printing-architecture] Common Dialogs for Printing
> 
> Glen wrote:
> 
> > I guess the addition of the actual preview to the CPD has triggered
> > more review of CPD from my perspective.
> >
> > I hope and believe the key object of this effort is focused on
> > "Common".  Thus, I now believe we may be trying to do too much in
> > the CPD and actually need three common dialogs; specifically, the
> > Common Preview Dialog (CRD), the Common Print Dialog (CPD), and the
> > Common Status/Monitoring Dialog (CSD).
> >
> > Actually, what we call print preview is really "preview of the page
> > setup" or "layout".  It is expected that printer will print the page
> > as shown in the "print preview" or "page preview".   So is this the
> > "print preview" or the applications "page preview"???
> 
> without a doubt _and_ proven by our first tests: the preview needs to
be
> a lo-res version of exactly what will come out of the printer.
> 
> the good thing about usability tests is that it shuts down, for ever,
> endless discussions about what users really need.
> 
> > Print Preview Dialog:
> 
> this station is long past. see above.
> 
> may I remind you all that is is 100% part of the design that when
> the transformation (formatting for paper) is for users creative/
> tricky/involved that then we recommend applications to show
> a dialog (the size of the actual application window) to let users
> hands-on control the transformation. this includes for instance
> sizing a spreadsheet (with the mouse, not by some number fields)
> across a grid of pages, or placing that image (for hi-end graphics
> apps like GIMP, inkscape) exactly on the page.
> 
> from this transformation dialog the choice is going to be
> 'just print' or to go through the print dialog.
> 
> > Print Dialog:
> > n       When I print, however, 95% of the time I want to see a
> > symbolic representation of the print options.  That is, which edge
> > is selected when duplex printing, where are the punch hole
> > locations, is the print BW or color, is the media in portrait or
> > landscape mode.  None of these and other print options require the
> > actual print content.
> > o        In this case, I am not willing to wait for a thumbnail
> > representation of my actual print content because it adds no value
> > to setting print options.
> > o        Having a consistent symbolic representation is critical
> > because it makes it easier to quickly identify what options I have
> > set or have not set.
> > n       Therefore, I really support using the previous version of
> > the CPD along with a symbolic representation of the print options.
> 
> like Mike said: you are not the user. please...


I sorry, I am a user.  I have been a user and developer on everything
from embedded, handheld, mobile, desktop, office, and production
printing.


Please..... two people in one usability test define a
solution!!!!!!!!!!!!!!! Please.............




> 
> with your knowledge of how it all works you are separating things out
> that are not separate for any non-printing-industry user.
> 
> remember the video clips I showed: the only thing that counts is
> the hardcopy that comes out of the printer. the preview as an integral
> part of the dialog reflects that fact.
> 
> > Status/Monitoring Dialog:
> 
> as I said: next project.
> 
>      --ps
> 
>          founder + principal interaction architect
>              man + machine interface works
> 
>          http://mmiworks.net/blog : on interaction architecture
> 
> 

Re: [Printing-architecture] Common Dialogs for Printing

[peter sikking]

Glen wrote:

> The email I sent was to start a discussion; not a war.  But, I gather
> from your replies; "that it is your way or no way".

developers are happy to receive any bug report, then reproduce and
decide if it is really a bug, then see in the tech design/code
(bug reporter has no idea what is in there) where the cause is,
then make a solution and apply the fix.

developers are not happy when people with near-zero development
experience start saying that whole block of code need to be
rewritten in this or that fashion. that does not wash.

interaction designers are happy to receive any bug report about
the concept, then reproduce and decide if it is really a usability  
issue, then see in the concept/detailed design (bug reporter has no idea
what is in there) where the cause is, then make a solution and
apply the fix to the concept.

interaction designers are not happy when people with near-zero
interaction design experience start saying that central parts
of concept need to be redesigned in this or that fashion.
that does not wash.

I am open to any bug report on the concept. I will treat these very
seriously, like you guys treat bugs in engineering.

> I sorry, I am a user.  I have been a user, architect and developer on
> everything from embedded, handheld, mobile, desktop, office, and
> production printing solutions including front-end and back-ends.

the first rule of professional interaction design is that you
cannot design it for yourself. I design this keeping in mind
the Gaussian distribution of 5 million users in umpteen dimensions.

> And Please..... two people in one usability test does not define a
> solution!!!!!!!!!!!!!!!


if you want to discuss the rigours of usability tests please
go ahead and do that with Jan Mühlig of relevantive.

both relevantive for the usability work and m+mi works
for the innovative interaction design stake their international
reputations on the design and validation of this printing UI.

both our companies work (together and separately) for huge
companies on UIs with hundreds of millions of users and
on vertical market UIs which specialisation and complexity
easily match that of the printing world.

we are not here to play games. we are here to implement
usability for open source projects and to show professional
interaction design processes that deliver the goods again
and again.

     --ps

         founder + principal interaction architect
             man + machine interface works

         http://mmiworks.net/blog : on interaction architecture

Re: [Printing-architecture] Common Dialogs for Printing

[Petrie, Glen]

[-- Attachment #1: Type: text/plain, Size: 3165 bytes --]

I sorry about your personal insecurities; because that can be the only reason you would/could have written such an email.  You have no concept of what is means to a be a professional.
 
I ask one more time --- Peace..... Please.
 
glen
 

________________________________

From: peter sikking [mailto:peter@mmiworks.net]
Sent: Sat 4/18/2009 3:39 AM
To: Petrie, Glen
Cc: printing-architecture@lists.linux-foundation.org; printing-summit@lists.linux-foundation.org
Subject: Re: [Printing-architecture] Common Dialogs for Printing



Glen wrote:

> The email I sent was to start a discussion; not a war.  But, I gather
> from your replies; "that it is your way or no way".

developers are happy to receive any bug report, then reproduce and
decide if it is really a bug, then see in the tech design/code
(bug reporter has no idea what is in there) where the cause is,
then make a solution and apply the fix.

developers are not happy when people with near-zero development
experience start saying that whole block of code need to be
rewritten in this or that fashion. that does not wash.

interaction designers are happy to receive any bug report about
the concept, then reproduce and decide if it is really a usability 
issue, then see in the concept/detailed design (bug reporter has no idea
what is in there) where the cause is, then make a solution and
apply the fix to the concept.

interaction designers are not happy when people with near-zero
interaction design experience start saying that central parts
of concept need to be redesigned in this or that fashion.
that does not wash.

I am open to any bug report on the concept. I will treat these very
seriously, like you guys treat bugs in engineering.

> I sorry, I am a user.  I have been a user, architect and developer on
> everything from embedded, handheld, mobile, desktop, office, and
> production printing solutions including front-end and back-ends.

the first rule of professional interaction design is that you
cannot design it for yourself. I design this keeping in mind
the Gaussian distribution of 5 million users in umpteen dimensions.

> And Please..... two people in one usability test does not define a
> solution!!!!!!!!!!!!!!!


if you want to discuss the rigours of usability tests please
go ahead and do that with Jan Mühlig of relevantive.

both relevantive for the usability work and m+mi works
for the innovative interaction design stake their international
reputations on the design and validation of this printing UI.

both our companies work (together and separately) for huge
companies on UIs with hundreds of millions of users and
on vertical market UIs which specialisation and complexity
easily match that of the printing world.

we are not here to play games. we are here to implement
usability for open source projects and to show professional
interaction design processes that deliver the goods again
and again.

     --ps

         founder + principal interaction architect
             man + machine interface works

         http://mmiworks.net/blog : on interaction architecture






[-- Attachment #2: Type: text/html, Size: 4243 bytes --]

Re: [Printing-architecture] Common Dialogs for Printing

[peter sikking]

Glen wrote:

> I sorry about your personal insecurities; because that can be the  
> only reason you would/could have written such an email.  You have no  
> concept of what is means to a be a professional.

that. got. personal.

we had a nice time talking in sf.

strange...

     --ps

         founder + principal interaction architect
             man + machine interface works

         http://mmiworks.net/blog : on interaction architecture

Re: [Printing-architecture] Common Dialogs for Printing

[Alex Wauck]

[-- Attachment #1: Type: text/plain, Size: 1055 bytes --]

Peter and Glen,

There is no need to CC your personal arguments to public mailing lists.
Honestly, I think you two need to just leave each other alone for a while.
Just back off and calm down, then discuss your differences once you are able
to do so in a rational and civil manner.

Alex

On Sun, Apr 19, 2009 at 4:34 AM, peter sikking <peter@mmiworks.net> wrote:

> Glen wrote:
>
> > I sorry about your personal insecurities; because that can be the
> > only reason you would/could have written such an email.  You have no
> > concept of what is means to a be a professional.
>
> that. got. personal.
>
> we had a nice time talking in sf.
>
> strange...
>
>     --ps
>
>         founder + principal interaction architect
>             man + machine interface works
>
>         http://mmiworks.net/blog : on interaction architecture
>
>
>
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/printing-architecture
>

[-- Attachment #2: Type: text/html, Size: 1764 bytes --]