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 On Wed, Sep 30, 2015 at 12:14 PM, C. Scott Ananian <[email protected]> wrote: > 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 > > -- > (http://cscott.net) > > _______________________________________________ > Design mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/design >
_______________________________________________ Design mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/design
