Re: [Wikimedia-l] The wikisites looks like 1996

[John Erling Blad]

This tend to diverge away from the chrome and into the content, which
is a lot more difficult to change. (Urgh, way to long…)

Anyway, I have this really-really weird idea that “staff” should
provide (extremely good) design elements, and then local projects
would chose to use them in favor of their own because they are better
than what the have locally. Those elements should typically provide
some features that would otherwise be to difficult or expensive to
make locally, thus the projects would want to use them.

Example 1: The staff could provide a complete set of design symbols
for featured articles, not the jammed together mix that is used now.
At some projects they even claim that the current kludges are what WMF
want to use, and that they are “Wikipedia”. Pretty weird.

It should be pretty easy to set up a project “Design elements:
featured articles”. We probably need them to have sufficient details
for badges, indicators, and pages. They should have symbolic names,
and they should probably adapt to the chosen skin. Remember, if the
design element is an SVG then it might be styled.

Remember to add a page indicator from the item on the local page
itself. Now we only add badges in the sidebar.

Added feature: The design elements will look good over all projects
and skins, and they will look consistent. (Increased conformance over
projects leads to decreased boundaries between the projects, that is
less “us and them”.)

Example 2: The staff could provide necessary modules for common tasks
like an infobox, navbox, taxbox, succession box, etc. There are not
many of them. Most of them will use structures at Wikidata, with some
local adaptation.

The present use of modules tries to support existing templates, but I
believe that is a wrong approach. By doing this we perpetuate present
problems with the templates. Instead of redirecting calls to modules
through templates we should simply call the modules as
{{module:infobox}} in the articles, and only add arguments as
necessary to solve problems. The module should check out the type of
item (P21) and act accordingly. (Yes it is possible, but then modules
must implement and use a __tostring metamethod. It is a tech-ting.)

Added feature: I guess editors will be glad to finally have infoboxes
that work as expected in all articles, and the conflicts between
various infoboxes would go away . (The soccer fans will probably hate
it, they can't style the infobox in the colors of their favorite
soccer team. Don't tell them they can still mess with the colors
through template styles.)

Example 3: The staff could provide well-defined help pages, that could
be localized at Meta, and the localized page transcluded into the
local project. It should be possible to link to such pages as if they
were local, and even if locally overridden they should always exist.

It is a pretty large undertaking to define all necessary help pages to
kick off a local project. To have some help pages, even in English or
some other language, would be a real boon. Also to link those pages we
need a slightly more advanced help indicator. Now we only have one
link that follows the page, but there are probably several given the
role and state of the user.

Added feature: It would be possible to find the help pages, thus
making the editing simpler. (Some oldtimers will probably get a grudge
over their favorite nit-pick items being thrown out on the common
pages, and will thus insist on keeping their favorite help page.)

On Sat, Dec 14, 2019 at 9:38 AM Amir E. Aharoni
 wrote:
>
> Yes, and that's why I really, really, really want to hear more feedback on
> it from various communities of editors, including criticism. That's also
> why in my proposal I write that it's a requirement that communities must be
> able to override any central functionality, and I only speak about the
> generic principle of making templates global, mentioning particular
> templates only as examples. I leave everything else to the communities.
>
> The parts about which I wrote that they will have to be done mostly by
> staff are the parts that require heavy PHP coding, code review, and
> testing, and as far as I know, most of the people who know the relevant
> areas of code well are on staff. (I might be wrong. Also, everything I'm 
> saying
> here are my own assessments, and they don't represent the WMF in any way.)
>
> However, the more volunteer developers and editors participate in it, the
> better—not because it saves money, but because it makes the project more
> "owned" by the community.
>
>
> בתאריך שבת, 14 בדצמ׳ 2019, 09:12, מאת John Erling Blad ‏:
>
> > I get a little scared when I read “probably, but not necessarily,
> > mostly by staff” because all kind of central standardization creates a
> > whole lot of arguing in the individual subprojects. If that
> > standardization means changing a whole lot of templates I'm afraid it
> > will create much more fighting than real solutions. I'm a little
> > “Marvin” here…

Re: [Wikimedia-l] The wikisites looks like 1996

[Pine W]

Regarding Timeless, folks may want to read
https://meta.wikimedia.org/wiki/Grants:Project/Timeless/Post-deployment_support/Final
.

I'm cross-posting this thread to the public Design mailing list. That's
usually a quiet list, but I think that if people want to have an extensive
discussion that is focused on design issues then that list would be a good
venue.

Pine
( https://meta.wikimedia.org/wiki/User:Pine )


On Sun, Dec 15, 2019 at 8:01 PM Aron Manning  wrote:

> On Sun, 15 Dec 2019 at 18:53, Chris Gates via Wikimedia-l <
> wikimedia-l@lists.wikimedia.org> wrote:
>
> > Is this the right time to plug Timeless?
> > It is, well, timeless. Looks modern too.
>
>
> Should be the default imho by now.
> Then the wikimania design features could be added to it, to make it almost
> up-to-date.
>
> Aron
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] The wikisites looks like 1996

[Gerard Meijssen]

Hoi,
I am game, to make me interested again in the editing sense of Wikipedia,
there are a few things on my wish list.

The first thing I will happily contribute to are "red links on steroids".
The problem with red links is disambiguation.. Suppose that there is no
article by that name, chances are that in another Wikipedia, Wikidata the
subjects is already known. Only when an article is written about *that
*subject,
the red links is bluefied. Easy, obvious. The first start is to have a
background job link all the blue link to their respective Wikidata items
and then compare links on the same subject. There are bound to be a lot of
false friends becoming obvious in that way.

The second wish is that lists are marked as such. My preference is that we
use Listeria on steroids ie the data displayed is from Wikidata but that is
secondary. What I aim to achieve is that with lists marked as such, it
becomes easy to compare lists and mark them for attention when attention is
needed to get agreement on the list.

The third wish is that when there are individual references for list items,
they are shared. A great example is found in the list of fellows of the
African Academy of Science. I noticed this in the English Wikipedia and it
started me adding references because typically they are great reads as well.

My most cherished wish though is that we stimulate people to *read *more
than what we offer in a Wikipedia article. Currently we offer our blue
links, interwiki links and references as reading material and it is quite
the rabbit hole. Great for our readers, not so much for our editors. What
they need is more and more found in the links that are part of the Scholia
[1] for any subject, author paper name it. The experience is becoming more
rich. Unlike Reasonator [2] which has only one way of serving its audience,
Scholia has different views telling different stories. It allows for new
papers / literature for a subject.

Given that *we want people to read*, why not expand search results in any
project with what is available elsewhere in our Wikiverse. Those who know
about it have it for years now. I do not want to do without it. It is a
great tool to help with disambiguation. It can be expanded with Scholia
results... to be really, really wild.

Talking about disambiguation.. Reasonator has always been superior at
disambiguation. We know how to prioritise results, we have had superior
description, descriptions for many years.

My key take away, if you want to be better forget dogma or "consensus" and
start with objectives and how we aim to get there.
Thanks,
  GerardM




[1] https://tools.wmflabs.org/scholia/
[2] https://tools.wmflabs.org/reasonator

On Sun, 15 Dec 2019 at 18:53, Paul J. Weiss  wrote:

> "I think we all generally endorse incremental improvements, instead
> of drastic overhauls."
>
> Um, that is clearly not true, since otherwise, for example, the original
> poster would not have sent out his message.
>
> For readers, I think many, if not most, would want a look and feel that
> works for them, aesthetically and functionally, regardless of how much a
> redesign was evolutionary or revolutionary. Many websites have gone through
> major redesigns successfully. (And of course some have been utter
> disasters, but many of those disasters came about because of poor design,
> not just because the design was a significant departure from the previous
> design.)
>
> For WMF wikis with very small editor bases, the degree of change may be
> less important than the quality of the change. A meaningful change, however
> small or large, may enable that community to recruit new editors who were
> previously turned off by wiki syntax (or other) complexities.
>
> As a WP editor myself, I would absolutely welcome a drastically different
> design, if it were a great design, that facilitated the editing and reading
> activities I want to engage in, and was pleasant to the eye. I welcome each
> change, regardless of size, that is an improvement.
>
> One side benefit of a revolutionary design change is that it can make
> long-term users reassess their use of a website, sometimes discovering a
> "new" feature, which has actually been there all along, nevertheless
> creating more engaged users. Another, I imagine, is that often there is a
> spike in word-of-mouth surrounding a major redesign, which can also have
> positive recruitment effects. A third might be that a drastic redesign
> would re-level the playing field, so to speak. New editors might be less
> subject to poor conduct from some long-term editors who lord their arcane
> wiki knowledge over newbies.
>
> Paul
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 

Re: [Wikimedia-l] The wikisites looks like 1996

[Aron Manning]

On Sun, 15 Dec 2019 at 18:53, Chris Gates via Wikimedia-l <
wikimedia-l@lists.wikimedia.org> wrote:

> Is this the right time to plug Timeless?
> It is, well, timeless. Looks modern too.


Should be the default imho by now.
Then the wikimania design features could be added to it, to make it almost
up-to-date.

Aron
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] The wikisites looks like 1996

[Paul J. Weiss]

"I think we all generally endorse incremental improvements, instead
of drastic overhauls."

Um, that is clearly not true, since otherwise, for example, the original
poster would not have sent out his message.

For readers, I think many, if not most, would want a look and feel that
works for them, aesthetically and functionally, regardless of how much a
redesign was evolutionary or revolutionary. Many websites have gone through
major redesigns successfully. (And of course some have been utter
disasters, but many of those disasters came about because of poor design,
not just because the design was a significant departure from the previous
design.)

For WMF wikis with very small editor bases, the degree of change may be
less important than the quality of the change. A meaningful change, however
small or large, may enable that community to recruit new editors who were
previously turned off by wiki syntax (or other) complexities.

As a WP editor myself, I would absolutely welcome a drastically different
design, if it were a great design, that facilitated the editing and reading
activities I want to engage in, and was pleasant to the eye. I welcome each
change, regardless of size, that is an improvement.

One side benefit of a revolutionary design change is that it can make
long-term users reassess their use of a website, sometimes discovering a
"new" feature, which has actually been there all along, nevertheless
creating more engaged users. Another, I imagine, is that often there is a
spike in word-of-mouth surrounding a major redesign, which can also have
positive recruitment effects. A third might be that a drastic redesign
would re-level the playing field, so to speak. New editors might be less
subject to poor conduct from some long-term editors who lord their arcane
wiki knowledge over newbies.

Paul
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] The wikisites looks like 1996

[Chris Gates via Wikimedia-l]

Is this the right time to plug Timeless?

It is, well, timeless. Looks modern too.

On Thu, Dec 12, 2019 at 18:22 John Erling Blad  wrote:

> Try holding your cellphone vertically.
>
> tor. 12. des. 2019, 22.38 skrev Todd Allen :
>
> > Erm, I remember what websites looked like in 1996. I even made some then.
> > It looks nothing like that.
> >
> > On the other hand, on the site you linked to? The first thing I see is an
> > absolutely huge photo of a robot looking at me. I have to scroll down
> past
> > that to get to the actual meat, the text content. *That* looks like 1996.
> >
> > I'll take the way we have it over that, thanks very much.
> >
> > Todd
> >
> > On Wed, Dec 11, 2019 at 2:48 PM John Erling Blad 
> wrote:
> >
> > > Could we please update them with a slightly more up-to-date skin?
> > >
> > > Take a look at our Norwegian competitor in the lexicon field.
> > > https://snl.no/kunstig_intelligens
> > >
> > > John Erling Blad
> > > /jeblad
> > > ___
> > > Wikimedia-l mailing list, guidelines at:
> > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> > > https://meta.wikimedia.org/wiki/Wikimedia-l
> > > New messages to: Wikimedia-l@lists.wikimedia.org
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > 
> > ___
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> > https://meta.wikimedia.org/wiki/Wikimedia-l
> > New messages to: Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > 
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,