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