Page MenuHomePhabricator

Make printable css more obvious (for people expecting a "print version")
Closed, ResolvedPublic

Description

Author: bjoern.kuestner

Description:
Wikipedia users find an article and want to print it.

The Wikipedia layout is nice and clean for the screen.

But for a printout there's still too much extra information that does not belong to the
article,

  • most notably the menu links on the left (Main Page, Community Portal, ...)
  • and potentially also the menu links on the top (article, discussion, ...)

The article print layout should just have the article beginning to end with all sources
and the reference to Wikipedia.

Thanks for your work!

Björn Küstner


Version: unspecified
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=63972

Details

Reference
bz1577
TitleReferenceAuthorSource BranchDest Branch
Start branching CommunityConfiguration extensionrepos/releng/release!63urbanecmT357766main
Make ZNC runtoolforge-repos/wikibugs2-znc!2bd808work/bd808/configmain
Document the use of a settings.xml to access this parent pom.repos/ci-tools/wmf-jvm-parent-pom!7geheldocument-archivamain
Update documentation to release this parent pom to Maven central.repos/ci-tools/wmf-jvm-parent-pom!5gehelrelease-to-centralmain
Customize query in GitLab

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 8:12 PM
bzimport set Reference to bz1577.
bzimport added a subscriber: Unknown Object (MLST).

river wrote:

Did you try "print preview"?

richholton wrote:

What version of MediaWiki are you using, and what browser / OS are you
attempting to print under? If I understand correctly, in later versions of
MediaWiki, the print formatting is done via a skin, and only occurs when you use
"print preview" or "print". When I do this, I get a very specific print of the
article itself, with none of the excess info you're talking about.

bjoern.kuestner wrote:

Now imagine that: I never, _never_ actually printed like this because I was so sure that the
printer would printout all the menus and everything. I mean, it's always like that on every other
web page. Even this bugzilla page has a "format for printing" link at the bottom! So to avoid that
in the past I always copied and pasted into a text document, then printed from there.

I have now tried the preview and it works just like you said. That's elegant. Great.

But I would be surprised if not many, many other users still run into the same thinking mistake
like I have. Surfers are used to a "print" button. This is just against all experience and habit
they have learned everywhwere else. It's like a Windows user on the Mac: "I want to shutdown this
thing. Where's the 'start' menu?" It's habit.

Now, a print button is a little bit more logical than shutting down from a menu named "start".

Maybe you can still add a print tab at the top of the page alongside "edit" and "history". It
would take users directly to the print preview as if they chose "print preview" in the browser
menu.

I'm happy now. Thanks for your quick help. My suggestion is only for the rest of the users.

Thanks!

zigger wrote:

This is probably a duplicate of bug 259 / bug 265 / bug 906.

river wrote:

yes, but i'm going to retitle it and leave it open. i think a way to make
printable version more obvious would be nice: this is a very FAQ.

bjoern.kuestner wrote:

Zigger:

259 seems covered in that "print preview" actually gives you a preview of the printed page. Just
to get there is not obvious on the Wikipedia page, and that's different from 259 in my opinion.

265 fell for the same problem as I did:_He thought there was no printing view. Because there was,
the case was closed. But the interface problem, i. e. Wikipedia leading users to believe that a
print version of the article does not easily exist, was not solved.

906 same problem like I originally posted.

I think keturner did the right thing: Take my request which was resolved in its original form but
relabel it to something that describes the interface problem with the Wikipedia page.

Thanks keturner and thanks Zigger for looking up the other requests.

rowan.collins wrote:

[tweaked summary and tags to reflect request even better]

One of the suggestions in previous discussions about this was for a JavaScript
link that somehow triggered the browser's Print Preview function. However, it
seems there is no standard way of doing this, so it might lead to some rather
unreliable and tangled code. (See e.g. the thread beginning
http://mail.wikipedia.org/pipermail/mediawiki-l/2004-October/#1978)

Skins other than Monobook, I believe, retain a "printable version" link, even
though they too simply use alternate stylesheets; this was considered
undesirable for monobook partly because it detracts from the elegance of it
being available automatically. Perhaps a special "fakeprint.css" could be added,
so that the page could be displayed with the print style sheet, but with an
extra message saying something like:

"All pages printed from this website should appear in a similar style to that
below when printed. This alternate display is here as a preview and
demonstration only, and you should not need to load it before printing."

The "fakeprint.css" could then simply be the print stylesheet with an extra rule
making that message visible on-screen but not when printed. We could even label
the link "print preview" - the idea being that hopefully people would spot the
message and not bother reloading before printing in future.

One final comment I found in my archives is that to minimise server load, we
could look into switching the displayed stylesheet using JavaScript, rather than
reloading the page. I don't know enough to expand on that, but I believe such
tricks are possible.

bjoern.kuestner wrote:

From my simple user perspective I feel like Rowan Collins' suggestion of using a fakeprint.css
captures the best of both worlds:

  • Provide to users the "print" button they expect
  • Communicate that this is actually not needed in most cases, so that users know to take the

standard and short way in the future.

The "printable version" link in Classic provides precisely what the requester is
asking for.

bjoern.kuestner wrote:

David, since I am the requester, I would like to understand your reply. Where or what is the

"printable version" link in Classic<< ?

I found no "Classic" nor "print" on the Wikipedia site. I googled for "printable version classic"
and for "printable version classic wikipedia" but found nothing useful.

I'm surely missing something obvious.

Thanks.

rowan.collins wrote:

(In reply to comment #9)

The "printable version" link in Classic provides precisely what the requester is
asking for.

The "Classic" skin (and all other pre-"MonoBook" skins, such as "Nostalgia" and
"Cologne Blue") have a redundant "printable version" link *because it was
already there*. Rather than being removed (which would have been even more
confusing than monobook not having one to start with), those links have been
made to just include the print stylesheet as the display stylesheet. They are,
in fact, counter-productive, as people think they are making a difference by
clicking, when actually they could just print straight away and save the extra
server hit. If we *were* to have a "fakeprint.css" (or "printpreview.css"),
therefore, I would suggest its inclusion on *all* skins, in an attempt to
educate people of the magic.

The print stylesheet provided by *every* skin provides what the *original*
requester was asking for. The point under discussion *now* is how best to
*present* this feature to the user (again, in *every* skin, the misleading
"printable version" links in old skins being equally unhelpful). The two
counter-arguments to having such a link on monobook are 1) it misleads the user
into thinking they *have* to click it (hence my "invisible message" idea) and
the general ugliness of adding it (which clearly didn't apply to leaving it in
the old skins) - as Paul Johnson described it 'a rather amateurish "click this
for a printable version of our broken design" link'.

Given how many people *don't* realise how it works, and reports of some
switching skin to get back the printable version link even though it doesn't
really do anything, I'm inclined to think we need to bite the bullet of the
ugliness for the sake of "intuitiveness" and "user education". Like I say, we
could even call the link 'print preview' rather than 'print version', and I
imagine people would still click there before switching skins / requesting features.

[For reference, see this bit of the MediaWiki-l archive:
http://mail.wikimedia.org/pipermail/mediawiki-l/2004-September/#1452
Particularly,
http://mail.wikimedia.org/pipermail/mediawiki-l/2004-September/001474.html and
http://mail.wikimedia.org/pipermail/mediawiki-l/2004-September/001464.html]

[Meanwhile, why did this bug get switched back to "Wikimedia websites"? It's a
request for a new feature in the software, to be used on *any* website, and
therefore belongs under "MediaWiki".]

  • Bug 1703 has been marked as a duplicate of this bug. ***

rowan.collins wrote:

*** Bug 1835 has been marked as a duplicate of this bug. ***

brian wrote:

(In reply to comment #3)

Even this bugzilla page has a "format for printing" link at the

bottom!

Firstly, it's not at the bottom; it's above the comments. Secondly,
users of this feature will suffer from exactly the same confusion
they will on MediaWiki sites - even after clicking "Format For
Printing", you still see the menu on the screen, but not in print
preview. I think there should be another bug filed under MediaWiki
pointing to this one.

ajdlinux wrote:

The reason for the 'Format for printing' link in [Media|Bug]Zilla is that CSS can't take out
buttons and comboboxes. I think we should just put a link that leads to a printable version
page. Either that or use JavaScript to open a print dialog or display an alert saying that you
just have to print. The print stylesheet must be improved, though. I have had spacing problems
with it.

Added a printable tab for 1.5, made ?printable=yes force the print stylesheet in MonoBook.

zigger wrote:

*** Bug 259 has been marked as a duplicate of this bug. ***

Moved it from a tab to the 'tools' section in the sidebar.