[Design] The page design of our dreams

[C. Scott Ananian]

Let's revisit the basic way that Mediawiki lays out media and content.
It has worked well enough for twenty years, but perhaps we can do
better.

In particular, I would like to be able to (a) make Wikimedia projects
looks Really Beautiful (b) on a variety of different devices and
formats.

Mobile and print are the forerunners here: in both cases we'd like
more flexibility to lay out infoboxes, media, tables, and content in
not-strictly-linear ways:

1) We'd like to be able to tag lead images, and use them more
generally (backgrounds for page titles, previews, etc)

2) Infoboxes, references, footnotes, etc want to be untethered from
their source location in the content and moved around -- for example,
to sidebars or popups on mobile; to the footer or dedicated pages in
print.

3) We would like to be able to crop and scale images better, but need
focal point information or a box around critical regions of the image.
(If the article is about the sun, and the photo is of a sunny day,
cropping the sun out would be bad. Other images have critical
features at the edges of the image we don't want to lose.) We
currently have a single option "thumb", and a single user-specified
scaling factor, meant for accessibility --- but an accessible size
will differ on different devices, and the scaling factor doesn't apply
to all images, only to those using "thumb".

4) We need more semantic information about images in order to make
better layouts: in print, is this a "wide" image appropriate for
spanning across multiple columns, or a "feature" image appropriate for
having a page to itself? Is this a meaningful parallel grouping of
images (ie, before and after) which shouldn't be broken up (but could
be arranged either horizontally or vertically, or perhaps with a
slider)? Should this image be laid out inline (rarely) or can it
float to a more aesthetic location?

5) Even text content might be unmoored -- why can't we have pull
quotes or sidebars in our articles?

6) What else? What other features of magazine, newpaper, or
encyclopedia design are we missing?

From a technical perspective, I'd like to move eventually toward a
system with greater separation of layout and content (think of
something like adobe pagemaker), where changes to layout can be made
without editing the article text. But I'd also like to make sure that
the technical issues don't overshadow the actual goal:

* What beautiful designs would you like for article content?

* What tools could we build to enable these designs?

Eventually we'd like to boil this down into a concrete design for a
better image styling system, which seems like a reasonable first step
in revamping what mediawiki can do for designers. That RFC is
https://phabricator.wikimedia.org/T90914 -- ideally the RFC will be
guided by a concrete design for a specific article, say,
http://en.wikipedia.beta.wmflabs.org/wiki/Moon, so that the
implementation of the RFC can focus on building the capabilities
needed to execute that specific design. That way we're certain we're
building something useful and beautiful for designers and readers, not
just implementing something whose PHP code seems elegant.
--scott

[C. Scott Ananian]

On Wed, Sep 30, 2015 at 3:14 PM, C. Scott Ananian

Post by C. Scott Ananian
https://phabricator.wikimedia.org/T90914 -- ideally the RFC will be
guided by a concrete design for a specific article, say,
http://en.wikipedia.beta.wmflabs.org/wiki/Moon, so that the

This should be https://en.wikipedia.org/wiki/Moon -- the link to labs
was unintentional.
For what it's worth, I described why [[Moon]] makes an interesting
test case for design here:
https://phabricator.wikimedia.org/T112991#1661312
--scott

[Brion Vibber]

Super awesome thread starter, thanks! :D

A few things:


1) Semantic markup

Fundamentally, we need finer-grained information about *what* things are
and *why* they're there, so a layout engine can appropriately select the
relevant stuff and present it well.

This means for instance, marking things as "quotes" or "replies" or
"informative box with message" rather than just indenting them with ":"
syntax. :)

It also may mean fine-grained information: separating image captions from
descriptions, marking up relevant parts of an image to point out in a zoom
or crop, indicating what's quoted text and what's a quotation mark or the
name of the person.


2) Templates today

A lot of times stuff like this is done via templates today. But the
templates have lots of corner cases, and aren't consistent across
languages/projects, or even always within a single project. They may also
lack the fine-grained divisions that we want in the future, or inject a lot
of non-semantic style information that's hard to remove in post-processing.


3) Transitioning semantic info from templates to be VE-friendly

Sounds fun. ;)

A traditional worry about WYSIWYG editing is that folks will apply styling
for styling's sake without using the proper semantic markup. It's thus
important to think about the editing experience: how do we make it *easier*
to mark things up correctly than to do them incorrectly?

Do we need a Clippy saying "It looks like you're italicizing a ship name,
do you want to mark it as one instead?" :D *shudder*

Don't know. But I do know that the editing experience, and figuring out
both how people will enter correct information and how they will enter
incorrect markup and how that will get fixed, are super important.


4) Filtering/extracting

Our articles have gotten longer and longer over the years; popular topics
are just.... huge. Finding what you want within an article -- especially on
a small screen -- is itself difficult if you're not just reading an entire
booklet-length work from start to finish.

Think about ways to filter down relevant information, or extract
information related to a search, and expose that more aggressively.

-- brion

Post by C. Scott Ananian
Let's revisit the basic way that Mediawiki lays out media and content.
It has worked well enough for twenty years, but perhaps we can do
better.
In particular, I would like to be able to (a) make Wikimedia projects
looks Really Beautiful (b) on a variety of different devices and
formats.
Mobile and print are the forerunners here: in both cases we'd like
more flexibility to lay out infoboxes, media, tables, and content in
1) We'd like to be able to tag lead images, and use them more
generally (backgrounds for page titles, previews, etc)
2) Infoboxes, references, footnotes, etc want to be untethered from
their source location in the content and moved around -- for example,
to sidebars or popups on mobile; to the footer or dedicated pages in
print.
3) We would like to be able to crop and scale images better, but need
focal point information or a box around critical regions of the image.
(If the article is about the sun, and the photo is of a sunny day,
cropping the sun out would be bad. Other images have critical
features at the edges of the image we don't want to lose.) We
currently have a single option "thumb", and a single user-specified
scaling factor, meant for accessibility --- but an accessible size
will differ on different devices, and the scaling factor doesn't apply
to all images, only to those using "thumb".
4) We need more semantic information about images in order to make
better layouts: in print, is this a "wide" image appropriate for
spanning across multiple columns, or a "feature" image appropriate for
having a page to itself? Is this a meaningful parallel grouping of
images (ie, before and after) which shouldn't be broken up (but could
be arranged either horizontally or vertically, or perhaps with a
slider)? Should this image be laid out inline (rarely) or can it
float to a more aesthetic location?
5) Even text content might be unmoored -- why can't we have pull
quotes or sidebars in our articles?
6) What else? What other features of magazine, newpaper, or
encyclopedia design are we missing?
From a technical perspective, I'd like to move eventually toward a
system with greater separation of layout and content (think of
something like adobe pagemaker), where changes to layout can be made
without editing the article text. But I'd also like to make sure that
* What beautiful designs would you like for article content?
* What tools could we build to enable these designs?
Eventually we'd like to boil this down into a concrete design for a
better image styling system, which seems like a reasonable first step
in revamping what mediawiki can do for designers. That RFC is
https://phabricator.wikimedia.org/T90914 -- ideally the RFC will be
guided by a concrete design for a specific article, say,
http://en.wikipedia.beta.wmflabs.org/wiki/Moon, so that the
implementation of the RFC can focus on building the capabilities
needed to execute that specific design. That way we're certain we're
building something useful and beautiful for designers and readers, not
just implementing something whose PHP code seems elegant.
--scott
--
(http://cscott.net)
_______________________________________________
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design

[C. Scott Ananian]

Good thoughts. And without getting too side-tracked from the design
questions, I'll note that the recent work towards "global templates"
(https://www.mediawiki.org/wiki/Requests_for_comment/Shadow_namespaces)
would make collaborating on a set of templates with agreed-upon
semantics easier. I've also proposed "hygenic arguments" for template
that would make the use of templates for ordinary tasks like "mark
this block as a quote" easier
(https://wikimania2015.wikimedia.org/w/index.php?title=File:Templates_are_dead!_Long_live_templates!.pdf&page=31).

But maybe not all of the design nails will be appropriate for hitting
with our hammer labelled "templates".
--scott

Post by Brion Vibber
Super awesome thread starter, thanks! :D
1) Semantic markup
Fundamentally, we need finer-grained information about *what* things are and
*why* they're there, so a layout engine can appropriately select the
relevant stuff and present it well.
This means for instance, marking things as "quotes" or "replies" or
"informative box with message" rather than just indenting them with ":"
syntax. :)
It also may mean fine-grained information: separating image captions from
descriptions, marking up relevant parts of an image to point out in a zoom
or crop, indicating what's quoted text and what's a quotation mark or the
name of the person.
2) Templates today
A lot of times stuff like this is done via templates today. But the
templates have lots of corner cases, and aren't consistent across
languages/projects, or even always within a single project. They may also
lack the fine-grained divisions that we want in the future, or inject a lot
of non-semantic style information that's hard to remove in post-processing.
3) Transitioning semantic info from templates to be VE-friendly
Sounds fun. ;)
A traditional worry about WYSIWYG editing is that folks will apply styling
for styling's sake without using the proper semantic markup. It's thus
important to think about the editing experience: how do we make it *easier*
to mark things up correctly than to do them incorrectly?
Do we need a Clippy saying "It looks like you're italicizing a ship name, do
you want to mark it as one instead?" :D *shudder*
Don't know. But I do know that the editing experience, and figuring out both
how people will enter correct information and how they will enter incorrect
markup and how that will get fixed, are super important.
4) Filtering/extracting
Our articles have gotten longer and longer over the years; popular topics
are just.... huge. Finding what you want within an article -- especially on
a small screen -- is itself difficult if you're not just reading an entire
booklet-length work from start to finish.
Think about ways to filter down relevant information, or extract information
related to a search, and expose that more aggressively.
-- brion

Post by C. Scott Ananian
Let's revisit the basic way that Mediawiki lays out media and content.
It has worked well enough for twenty years, but perhaps we can do
better.
In particular, I would like to be able to (a) make Wikimedia projects
looks Really Beautiful (b) on a variety of different devices and
formats.
Mobile and print are the forerunners here: in both cases we'd like
more flexibility to lay out infoboxes, media, tables, and content in
1) We'd like to be able to tag lead images, and use them more
generally (backgrounds for page titles, previews, etc)
2) Infoboxes, references, footnotes, etc want to be untethered from
their source location in the content and moved around -- for example,
to sidebars or popups on mobile; to the footer or dedicated pages in
print.
3) We would like to be able to crop and scale images better, but need
focal point information or a box around critical regions of the image.
(If the article is about the sun, and the photo is of a sunny day,
cropping the sun out would be bad. Other images have critical
features at the edges of the image we don't want to lose.) We
currently have a single option "thumb", and a single user-specified
scaling factor, meant for accessibility --- but an accessible size
will differ on different devices, and the scaling factor doesn't apply
to all images, only to those using "thumb".
4) We need more semantic information about images in order to make
better layouts: in print, is this a "wide" image appropriate for
spanning across multiple columns, or a "feature" image appropriate for
having a page to itself? Is this a meaningful parallel grouping of
images (ie, before and after) which shouldn't be broken up (but could
be arranged either horizontally or vertically, or perhaps with a
slider)? Should this image be laid out inline (rarely) or can it
float to a more aesthetic location?
5) Even text content might be unmoored -- why can't we have pull
quotes or sidebars in our articles?
6) What else? What other features of magazine, newpaper, or
encyclopedia design are we missing?
From a technical perspective, I'd like to move eventually toward a
system with greater separation of layout and content (think of
something like adobe pagemaker), where changes to layout can be made
without editing the article text. But I'd also like to make sure that
* What beautiful designs would you like for article content?
* What tools could we build to enable these designs?
Eventually we'd like to boil this down into a concrete design for a
better image styling system, which seems like a reasonable first step
in revamping what mediawiki can do for designers. That RFC is
https://phabricator.wikimedia.org/T90914 -- ideally the RFC will be
guided by a concrete design for a specific article, say,
http://en.wikipedia.beta.wmflabs.org/wiki/Moon, so that the
implementation of the RFC can focus on building the capabilities
needed to execute that specific design. That way we're certain we're
building something useful and beautiful for designers and readers, not
just implementing something whose PHP code seems elegant.
--scott
--
(http://cscott.net)
_______________________________________________
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design

_______________________________________________
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design

[Jon Robson]

I think this a good summary and I think generally this can be summarised as
how can we get from a monolithic block of text to a componetised view with
more freedom to the designer.

Right now the main must have for the mobile site in any mediawiki based
parser is to be able to distinguish the lead section from the rest of the
article. This seems like an obvious starting point (and we're discussing in
https://phabricator.wikimedia.org/T114072).

Shadow namespaces sound like a great idea that will help carve the way to
solving even more granular problems such as how can we mark up an
infobox in a consistent way.

Another approach is to codify these concepts - for instance the
WikidataPageBanner [1] extension builds the page banners for the Wikivoyage
communities, and by owning the rendering it can behave differently in
different contexts. This won't scale to all templates but could for widely
templates such as infoboxes, an approach which Wikia is taking [2] .
Obviously this means more code to maintain, but more control.

I'd be interested in seeing both approaches play out and see which wins. I
think both are worth exploring since different communities.. different
tastes.

[1] https://www.mediawiki.org/wiki/Extension:WikidataPageBanner
[2] http://community.wikia.com/wiki/Help:Portable_infoboxes

Post by C. Scott Ananian
Good thoughts. And without getting too side-tracked from the design
questions, I'll note that the recent work towards "global templates"
(https://www.mediawiki.org/wiki/Requests_for_comment/Shadow_namespaces)
would make collaborating on a set of templates with agreed-upon
semantics easier. I've also proposed "hygenic arguments" for template
that would make the use of templates for ordinary tasks like "mark
this block as a quote" easier
(
https://wikimania2015.wikimedia.org/w/index.php?title=File:Templates_are_dead!_Long_live_templates!.pdf&page=31
).
But maybe not all of the design nails will be appropriate for hitting
with our hammer labelled "templates".
--scott

Post by Brion Vibber
Super awesome thread starter, thanks! :D
1) Semantic markup
Fundamentally, we need finer-grained information about *what* things are

and

Post by Brion Vibber
*why* they're there, so a layout engine can appropriately select the
relevant stuff and present it well.
This means for instance, marking things as "quotes" or "replies" or
"informative box with message" rather than just indenting them with ":"
syntax. :)
It also may mean fine-grained information: separating image captions from
descriptions, marking up relevant parts of an image to point out in a

zoom

Post by Brion Vibber
or crop, indicating what's quoted text and what's a quotation mark or the
name of the person.
2) Templates today
A lot of times stuff like this is done via templates today. But the
templates have lots of corner cases, and aren't consistent across
languages/projects, or even always within a single project. They may also
lack the fine-grained divisions that we want in the future, or inject a

lot

Post by Brion Vibber
of non-semantic style information that's hard to remove in

post-processing.

Post by Brion Vibber
3) Transitioning semantic info from templates to be VE-friendly
Sounds fun. ;)
A traditional worry about WYSIWYG editing is that folks will apply

styling

Post by Brion Vibber
for styling's sake without using the proper semantic markup. It's thus
important to think about the editing experience: how do we make it

*easier*

Post by Brion Vibber
to mark things up correctly than to do them incorrectly?
Do we need a Clippy saying "It looks like you're italicizing a ship

name, do

Post by Brion Vibber
you want to mark it as one instead?" :D *shudder*
Don't know. But I do know that the editing experience, and figuring out

both

Post by Brion Vibber
how people will enter correct information and how they will enter

incorrect

Post by Brion Vibber
markup and how that will get fixed, are super important.
4) Filtering/extracting
Our articles have gotten longer and longer over the years; popular topics
are just.... huge. Finding what you want within an article -- especially

on

Post by Brion Vibber
a small screen -- is itself difficult if you're not just reading an

entire

Post by Brion Vibber
booklet-length work from start to finish.
Think about ways to filter down relevant information, or extract

information

Post by Brion Vibber
related to a search, and expose that more aggressively.
-- brion
On Wed, Sep 30, 2015 at 12:14 PM, C. Scott Ananian <

Post by C. Scott Ananian
Let's revisit the basic way that Mediawiki lays out media and content.
It has worked well enough for twenty years, but perhaps we can do
better.
In particular, I would like to be able to (a) make Wikimedia projects
looks Really Beautiful (b) on a variety of different devices and
formats.
Mobile and print are the forerunners here: in both cases we'd like
more flexibility to lay out infoboxes, media, tables, and content in
1) We'd like to be able to tag lead images, and use them more
generally (backgrounds for page titles, previews, etc)
2) Infoboxes, references, footnotes, etc want to be untethered from
their source location in the content and moved around -- for example,
to sidebars or popups on mobile; to the footer or dedicated pages in
print.
3) We would like to be able to crop and scale images better, but need
focal point information or a box around critical regions of the image.
(If the article is about the sun, and the photo is of a sunny day,
cropping the sun out would be bad. Other images have critical
features at the edges of the image we don't want to lose.) We
currently have a single option "thumb", and a single user-specified
scaling factor, meant for accessibility --- but an accessible size
will differ on different devices, and the scaling factor doesn't apply
to all images, only to those using "thumb".
4) We need more semantic information about images in order to make
better layouts: in print, is this a "wide" image appropriate for
spanning across multiple columns, or a "feature" image appropriate for
having a page to itself? Is this a meaningful parallel grouping of
images (ie, before and after) which shouldn't be broken up (but could
be arranged either horizontally or vertically, or perhaps with a
slider)? Should this image be laid out inline (rarely) or can it
float to a more aesthetic location?
5) Even text content might be unmoored -- why can't we have pull
quotes or sidebars in our articles?
6) What else? What other features of magazine, newpaper, or
encyclopedia design are we missing?
From a technical perspective, I'd like to move eventually toward a
system with greater separation of layout and content (think of
something like adobe pagemaker), where changes to layout can be made
without editing the article text. But I'd also like to make sure that
* What beautiful designs would you like for article content?
* What tools could we build to enable these designs?
Eventually we'd like to boil this down into a concrete design for a
better image styling system, which seems like a reasonable first step
in revamping what mediawiki can do for designers. That RFC is
https://phabricator.wikimedia.org/T90914 -- ideally the RFC will be
guided by a concrete design for a specific article, say,
http://en.wikipedia.beta.wmflabs.org/wiki/Moon, so that the
implementation of the RFC can focus on building the capabilities
needed to execute that specific design. That way we're certain we're
building something useful and beautiful for designers and readers, not
just implementing something whose PHP code seems elegant.
--scott
--
(http://cscott.net)
_______________________________________________
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design

_______________________________________________
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design

--
(http://cscott.net)
_______________________________________________
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design