[Wikimedia-l] The wikisites looks like 1996

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Alessandro Marchetti 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 <[hidden email]> wrote:

> Try holding your cellphone vertically.
>
> tor. 12. des. 2019, 22.38 skrev Todd Allen <[hidden email]>:
>
> > 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 <[hidden email]>
> 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: [hidden email]
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > <mailto:[hidden email]?subject=unsubscribe>
> > _______________________________________________
> > 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: [hidden email]
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:[hidden email]?subject=unsubscribe>
> _______________________________________________
> 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: [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
_______________________________________________
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: [hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

Todd Allen
In reply to this post by John Erling Blad
I'm not using my cell phone. I'm using an actual computer with a 28"
monitor.

There's really no excuse, in web design, for something aside from the
content to absolutely overwhelm the whole monitor on a first view. That
robot image should be about a third of its size.

Todd

On Thu, Dec 12, 2019 at 4:22 PM John Erling Blad <[hidden email]> wrote:

> Try holding your cellphone vertically.
>
> tor. 12. des. 2019, 22.38 skrev Todd Allen <[hidden email]>:
>
> > 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 <[hidden email]>
> 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: [hidden email]
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > <mailto:[hidden email]?subject=unsubscribe>
> > _______________________________________________
> > 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: [hidden email]
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:[hidden email]?subject=unsubscribe>
> _______________________________________________
> 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: [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
_______________________________________________
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: [hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

Nick Wilson (Quiddity)
In reply to this post by Juergen Fenn-4
Multiple responses:

On Thu, Dec 12, 2019 at 10:07 AM Juergen Fenn <[hidden email]> wrote:

> Am 12.12.19 um 02:25 Uhr schrieb Strainu:
> > There is also a
> > question of opportunity: with less and less desktop users, it just
> > makes more sense to invest in the mobile experience
>
> Most authors still use desktop computers for writing articles or doing
> maintenance work. Mobile is for readers.
>

That is true in most wikis, but not all, and it's a slowly growing
percentage. Some contributors only have a phone as their single (or
sometimes even just *shared*) access to the internet. Much of the world
cannot afford a laptop/desktop computer. There are edit-percentage
statistics in this spreadsheet in columns P and K:
https://docs.google.com/spreadsheets/d/1a-UBqsYtJl6gpauJyanx0nyxuPqRvhzJRN817XpkuS8/edit#gid=1610967999
Secondly, we always need/hope to find new editors in all the projects, and
if the readers are getting to our projects via mobile, then that could be
the best place to get them started on the path to being an editor
(occasional or regular). Getting readers to take that first step of an
initial edit, can be the hardest part.
Lastly, there's a useful essay by this Ewiki admin about mobile editing.
https://en.wikipedia.org/wiki/User:Cullen328/Smartphone_editing


On Wed, Dec 11, 2019 at 11:21 PM Amir E. Aharoni <
[hidden email]> wrote:

> The tragic thing here is that reading is increasingly done on mobile
> devices, and in some countries it's already the majority of pageviews. But
> editing is mostly done on the desktop, which looks completely differently.
> So editors don't even see a preview of how what they write will look for
> *most* readers.


Agreed.
There is an old gadget on Enwiki (and re-used at a dozen other wikis, per
[[m:Gadgets]]) which shows a mockup of how the article might appear on a
small screen. I suspect it needs improvements in a few aspects (design,
performance), but it works quite well.
Anyone can see how it looks (ideally from a laptop-or-bigger window!) with
this URL:
https://en.wikipedia.org/wiki/Moon?withJS=MediaWiki:Gadget-mobile-sidebar.js&withCSS=MediaWiki:Gadget-mobile-sidebar.css
Or here's a screenshot: https://i.imgur.com/juXqcKW.png


On Wed, Dec 11, 2019 at 5:26 PM Strainu <[hidden email]> wrote:

> The main problem I see with that is that is changing all the on-wiki
> templates and scripts that work with the current skin. There is also a
> question of opportunity: with less and less desktop users, it just
> makes more sense to invest in the mobile experience (and the beta mode
> there is super cool, but still breaks some templates).


Templates that still have problems on mobile at some wikis, can usually be
fixed with the assistance of this page (especially section #12)
https://www.mediawiki.org/wiki/Recommendations_for_mobile_friendly_articles_on_Wikimedia_wikis
-- I'll be sending a reminder to a few VillagePumps about this in the next
few weeks.

Gadgets/scripts sometimes work as expected across different skins, and
sometimes not. That's a very different and distinct problem from templates.


On Wed, Dec 11, 2019 at 8:58 PM Aron Manning <[hidden email]> wrote:

> That's nice. Try these redesigns with an adblocker for a comparison:


I've just added a new batch of links that I learned about yesterday, to
that page. ;)
https://en.wikipedia.org/w/index.php?title=Wikipedia:Unsolicited_redesigns&diff=930505897&oldid=913318977&diffmode=source


On Thu, Dec 12, 2019 at 1:38 PM Todd Allen <[hidden email]> wrote:

> 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.


I initially learned HTML from this site/book c.1998,
https://web.archive.org/web/20000818170520/http://www.arsdigita.com/books/panda/index.html
and ever since I've appreciated clean simple structured content. I
completely understand what you mean here, Todd. Although I'd balance it out
with: not-all-wikis-are-Wikipedia, and hence some of the Wikivoyages have
their distinct intro-landscape-image design, e.g.
https://es.wikivoyage.org/wiki/Tokio

I think we all generally endorse incremental improvements, instead of
drastic overhauls. Overhauls can make many users (of any site) confused or
frustrated, and our users (readers and editors) are the whole point of this
endeavour. The problem is there simply haven't been many improvements to
the basic site-design elements over the last decade, despite the numerous
great ideas that editors and gadget-authors and others amongst us (and
beyond us) have had.

The biggest complexities of any changes here, are the vastly different
needs of all the different demographics/types of users (e.g. keeping things
similar enough so that readers don't get confused when they start to edit;
e.g. not disrupting the current editors whether they use phones or
desktops; e.g. adding new accessibility & usability improvements/options;
etc), balanced with the technical requirements of efficiency given our
current software "stacks".

Hence the "Goals" and "Constraints" sections (for the TL;DR) in
https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements
We're planning on adding/tweaking/changing elements in the UI slowly and
carefully, so that editors can keep on efficiently editing, and readers
(and editors implicitly!) can slowly get a clearer/better reading
experience, over the years ahead.

There are /many/ ideas for subtle or significant improvements listed in the
project pages (don't get distracted by just the first image in the
slideshow!), and probably more good ideas we're still missing.
Anyone's feedback (hopefully nuanced and friendly) and further
ideas/links/suggestions/etc would be appreciated at that project page.

Quiddity / Nick
_______________________________________________
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: [hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

Amir E. Aharoni
‫בתאריך יום ו׳, 13 בדצמ׳ 2019 ב-2:13 מאת ‪Nick Wilson (Quiddity)‬‏ <‪
[hidden email]‬‏>:‬

> On Wed, Dec 11, 2019 at 5:26 PM Strainu <[hidden email]> wrote:
>
> > The main problem I see with that is that is changing all the on-wiki
> > templates and scripts that work with the current skin. There is also a
> > question of opportunity: with less and less desktop users, it just
> > makes more sense to invest in the mobile experience (and the beta mode
> > there is super cool, but still breaks some templates).
>
>
> Templates that still have problems on mobile at some wikis, can usually be
> fixed with the assistance of this page (especially section #12)
>
> https://www.mediawiki.org/wiki/Recommendations_for_mobile_friendly_articles_on_Wikimedia_wikis
> -- I'll be sending a reminder to a few VillagePumps about this in the next
> few weeks.
>

The instructions on this page are probably correct, but the practical
problem with this attitude is that to actually get it to work, it has to be
discovered, read, understood, and acted upon by people from 900 wikis, and
much less than half of these wikis have people who have the necessary
programming skills to do all of this. And, as you say, you need to say
reminders.

This is different from extensions, which are developed once and used
everywhere. The only thing that needs to be done to make them fully usable
is translating them, which is a reasonable thing to request. Some
extensions, such as Citoid and Wikilove, do need local adaptations to
actually be useful, but these are exceptions that prove the rule: it would
be better if these local adaptations weren't needed.

That's why templates need to be global, so that there will be a repository
of templates that are written once and usable everywhere. (Some templates
should be converted to extensions, but it's far from feasible to do it with
all templates.)

One crucial thing that makes templates (and gadgets) relevant to any major
redesign project is that the designers and the developers who will work on
it should themselves be accustomed to seeing them in the content or next to
it, or at least to have a way to experience them easily in a language they
know. This is possible to do in a scalable way only if they are global.
(Some people assume that all templates are available in English, but it's
very, very far from being true. The innovation in templates in Russian,
French, Hebrew, Persian, and many other languages is amazing and mostly
unknown to English-only Wikipedians. But that's a topic for a different
thread. Maybe I'll start a series of blog posts titled "non-English
Wikipedia template of the week"?)

Gadgets/scripts sometimes work as expected across different skins, and
> sometimes not. That's a very different and distinct problem from templates.
>

Indeed. It's tempting to think that global templates and global gadgets are
the same project, but they aren't.

I focus my efforts on promoting the idea of the necessity of global
templates and modules, which are also distinct from each other, but much
more closely related. Gadgets should be global, too, however.
_______________________________________________
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: [hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

Shlomi Fish
In reply to this post by John Erling Blad
Hello John,

On Thu, 12 Dec 2019 14:01:46 +0100
John Erling Blad <[hidden email]> wrote:

> I wrote 1996 in the subject field because that was the year I made a
> wikisite with tabbed interface, and experimented with a paper-like
> design in Xt. More or less what designers today would call a material
> design. The present design is what I would call Monobook 2.0, and that
> imply a 15 year old design. Monobook was rolled out in 2004-2005 if I
> remember correctly.
>

In that case, it was flamebait and provocative.

> At nowiki we had a discussion with a designer from The Oslo School of
> Architecture and Design around 2009, and he come up with a really nice
> design. The design at SNL (the other Norwegian lexicon) starts to look
> more and more like it. The design proposal was deemed to radical and
> to simple for Wikipedia. He got several awards for the design.
>
> No, I'm not a designer, but I do like good design.
>

Like I said, I do not find the current https://en.wikipedia.org/wiki/Main_Page
design lacking, except for the fact it may not be mobile-friendly (or so called
https://en.wikipedia.org/wiki/Responsive_web_design ) enough, which is a
difficult problem to tackle.

> On Thu, Dec 12, 2019 at 1:34 PM John Erling Blad <[hidden email]> wrote:
> >
> > Thank you, but discussing how your site or any other specific site
> > looked like in some year is an distraction.
> >
> > On Thu, Dec 12, 2019 at 12:30 PM Shlomi Fish <[hidden email]>
> > wrote:  
> > >
> > > Hi John!
> > >
> > > On Wed, 11 Dec 2019 22:47:21 +0100
> > > John Erling Blad <[hidden email]> 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
> > > >  
> > >
> > > I took a look at https://en.wikipedia.org/wiki/Main_Page and it doesn't
> > > look anything like a geocities/etc. site from the 90s, and I feel it
> > > doesn't look bad.
> > >
> > > For the record that was my site at around 1998 -
> > > https://old-1998-site.shlomifish.org/ and people complained enough that my
> > > current site looks like "[insert  year here]" that I added a FAQ entry:
> > >
> > > https://www.shlomifish.org/meta/FAQ/site_looks_old.xhtml
> > >
> > > See https://everybootstrap.site/ for how many contemporary sites look
> > > like.
> > >
> > > Someone on freenode told me he thinks plain black-on-white sites look
> > > great.
> > >
> > > Regards,
> > >
> > >         Shlomi
> > >  
> > > > 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:
> > > > [hidden email] Unsubscribe:
> > > > https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > > <mailto:[hidden email]?subject=unsubscribe>  
> > >
> > >
> > > --
> > >
> > > Shlomi Fish       https://www.shlomifish.org/
> > > https://www.shlomifish.org/lecture/C-and-CPP/bad-elements/
> > >
> > > As it turns out, compiling a C program from more than 20 years ago is
> > > actually a lot easier than getting a Rails app from last year to work.
> > >     — https://passy.svbtle.com/building-vim-from-1993-today
> > >
> > > Please reply to list if it's a mailing list post - http://shlom.in/reply
> > > .  



--

Shlomi Fish       https://www.shlomifish.org/
List of Graphics Apps - https://shlom.in/graphics

Tech needs less wizards, ninjas, and rockstars, and way more sociologists.
    — https://twitter.com/nslater/status/545592700289155072

Please reply to list if it's a mailing list post - http://shlom.in/reply .

_______________________________________________
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: [hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

Paul J. Weiss
In reply to this post by John Erling Blad
"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: [hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

Amir E. Aharoni
In reply to this post by Pine W
‫בתאריך יום ה׳, 12 בדצמ׳ 2019 ב-23:37 מאת ‪Pine W‬‏ <‪[hidden email]
‬‏>:‬

> I'm thinking out loud here. Are there any estimates of would be required in
> terms of time (both staff time and community time) and money to make
> templates and other tools be much easier to globalize across wikis and
> across skins? I'm looking for an answer that is more specific than "a lot",
> but isn't a promise or a detailed estimate.
>

Difficult to say.

I won't make an actual time estimation, because I'm very bad at doing it,
and because I have too many conflicts of interest ;)

However, I do hope to give you something more specific than "a lot". I
envision the following feasible plan for "global modules and templates,
phase 1":
* Make a localization framework for modules. (
https://phabricator.wikimedia.org/T238417 ; probably, but not necessarily,
mostly by staff)
* Develop a documentation page and a framework for making robust modules (
https://phabricator.wikimedia.org/T238532 ; probably, but not necessarily,
mostly by staff).
* Make modules storable and loadable from a global repository, and
*actually enable it on all Wikimedia projects* (
https://phabricator.wikimedia.org/T41610 ; probably, but not necessarily,
mostly by staff).
* Migrate most local modules from all the wikis to using global modules,
and deleting all the migrated local modules. This will have to be done by
the editors communities in many wikis, and it will only be feasible if all
the points above are planned and executed well. The challenges I expect at
this step are:
** Making sure that just the right amount of things are global and
everything that communities want to override locally can be conveniently
overridden.
** Making tough choices about which modules to use when several communities
developed modules with similar functionality. For example: English, French,
Russian, Spanish, and Hebrew Wikipedias have modules for loading Wikidata
values. They aren't the same, but they probably should be. Merging them
into a global module will require a lot of good-faith collaboration.

Note that I only mentioned modules. Templates have some extra challenges.
But once modules are done well, a "phase 2" of this project, that would
tackle templates, will become possible. Also, global gadgets will have to
be a separate project. Maybe the same localization framework can be used
for both modules and gadgets, but I cannot think of anything else that they
really have in common.

All of the above is my interpretation of discussions in the recent Tech
Conf in Atlanta (other people may have a significantly different
interpretation). See these Phab tasks, and the web of other tasks linked to
them:
https://phabricator.wikimedia.org/T234661
https://phabricator.wikimedia.org/T52329
_______________________________________________
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: [hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

John Erling Blad
In reply to this post by Todd Allen
I don't see any reason to turn this into a help thread, but yes there
are a few browsers that don't fully support responsive design. For
example IE11 has trouble with responsive images.[1]

Mobile best Practices become a W3C Recommendation 29 July 2008, we're
not compliant as far as I know.[2]

[1] https://caniuse.com/#feat=picture
[2] https://www.w3.org/TR/mobile-bp/

On Fri, Dec 13, 2019 at 12:39 AM Todd Allen <[hidden email]> wrote:

>
> I'm not using my cell phone. I'm using an actual computer with a 28"
> monitor.
>
> There's really no excuse, in web design, for something aside from the
> content to absolutely overwhelm the whole monitor on a first view. That
> robot image should be about a third of its size.
>
> Todd
>
> On Thu, Dec 12, 2019 at 4:22 PM John Erling Blad <[hidden email]> wrote:
>
> > Try holding your cellphone vertically.
> >
> > tor. 12. des. 2019, 22.38 skrev Todd Allen <[hidden email]>:
> >
> > > 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 <[hidden email]>
> > 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: [hidden email]
> > > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > > <mailto:[hidden email]?subject=unsubscribe>
> > > _______________________________________________
> > > 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: [hidden email]
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > <mailto:[hidden email]?subject=unsubscribe>
> > _______________________________________________
> > 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: [hidden email]
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:[hidden email]?subject=unsubscribe>
> _______________________________________________
> 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: [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>

_______________________________________________
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: [hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

John Erling Blad
In reply to this post by Nick Wilson (Quiddity)
A skin does not have to change the content, most of the skin is chrome
and can be changed without touching the content at all.

On Fri, Dec 13, 2019 at 1:12 AM Nick Wilson (Quiddity)
<[hidden email]> wrote:

>
> Multiple responses:
>
> On Thu, Dec 12, 2019 at 10:07 AM Juergen Fenn <[hidden email]> wrote:
>
> > Am 12.12.19 um 02:25 Uhr schrieb Strainu:
> > > There is also a
> > > question of opportunity: with less and less desktop users, it just
> > > makes more sense to invest in the mobile experience
> >
> > Most authors still use desktop computers for writing articles or doing
> > maintenance work. Mobile is for readers.
> >
>
> That is true in most wikis, but not all, and it's a slowly growing
> percentage. Some contributors only have a phone as their single (or
> sometimes even just *shared*) access to the internet. Much of the world
> cannot afford a laptop/desktop computer. There are edit-percentage
> statistics in this spreadsheet in columns P and K:
> https://docs.google.com/spreadsheets/d/1a-UBqsYtJl6gpauJyanx0nyxuPqRvhzJRN817XpkuS8/edit#gid=1610967999
> Secondly, we always need/hope to find new editors in all the projects, and
> if the readers are getting to our projects via mobile, then that could be
> the best place to get them started on the path to being an editor
> (occasional or regular). Getting readers to take that first step of an
> initial edit, can be the hardest part.
> Lastly, there's a useful essay by this Ewiki admin about mobile editing.
> https://en.wikipedia.org/wiki/User:Cullen328/Smartphone_editing
>
>
> On Wed, Dec 11, 2019 at 11:21 PM Amir E. Aharoni <
> [hidden email]> wrote:
>
> > The tragic thing here is that reading is increasingly done on mobile
> > devices, and in some countries it's already the majority of pageviews. But
> > editing is mostly done on the desktop, which looks completely differently.
> > So editors don't even see a preview of how what they write will look for
> > *most* readers.
>
>
> Agreed.
> There is an old gadget on Enwiki (and re-used at a dozen other wikis, per
> [[m:Gadgets]]) which shows a mockup of how the article might appear on a
> small screen. I suspect it needs improvements in a few aspects (design,
> performance), but it works quite well.
> Anyone can see how it looks (ideally from a laptop-or-bigger window!) with
> this URL:
> https://en.wikipedia.org/wiki/Moon?withJS=MediaWiki:Gadget-mobile-sidebar.js&withCSS=MediaWiki:Gadget-mobile-sidebar.css
> Or here's a screenshot: https://i.imgur.com/juXqcKW.png
>
>
> On Wed, Dec 11, 2019 at 5:26 PM Strainu <[hidden email]> wrote:
>
> > The main problem I see with that is that is changing all the on-wiki
> > templates and scripts that work with the current skin. There is also a
> > question of opportunity: with less and less desktop users, it just
> > makes more sense to invest in the mobile experience (and the beta mode
> > there is super cool, but still breaks some templates).
>
>
> Templates that still have problems on mobile at some wikis, can usually be
> fixed with the assistance of this page (especially section #12)
> https://www.mediawiki.org/wiki/Recommendations_for_mobile_friendly_articles_on_Wikimedia_wikis
> -- I'll be sending a reminder to a few VillagePumps about this in the next
> few weeks.
>
> Gadgets/scripts sometimes work as expected across different skins, and
> sometimes not. That's a very different and distinct problem from templates.
>
>
> On Wed, Dec 11, 2019 at 8:58 PM Aron Manning <[hidden email]> wrote:
>
> > That's nice. Try these redesigns with an adblocker for a comparison:
>
>
> I've just added a new batch of links that I learned about yesterday, to
> that page. ;)
> https://en.wikipedia.org/w/index.php?title=Wikipedia:Unsolicited_redesigns&diff=930505897&oldid=913318977&diffmode=source
>
>
> On Thu, Dec 12, 2019 at 1:38 PM Todd Allen <[hidden email]> wrote:
>
> > 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.
>
>
> I initially learned HTML from this site/book c.1998,
> https://web.archive.org/web/20000818170520/http://www.arsdigita.com/books/panda/index.html
> and ever since I've appreciated clean simple structured content. I
> completely understand what you mean here, Todd. Although I'd balance it out
> with: not-all-wikis-are-Wikipedia, and hence some of the Wikivoyages have
> their distinct intro-landscape-image design, e.g.
> https://es.wikivoyage.org/wiki/Tokio
>
> I think we all generally endorse incremental improvements, instead of
> drastic overhauls. Overhauls can make many users (of any site) confused or
> frustrated, and our users (readers and editors) are the whole point of this
> endeavour. The problem is there simply haven't been many improvements to
> the basic site-design elements over the last decade, despite the numerous
> great ideas that editors and gadget-authors and others amongst us (and
> beyond us) have had.
>
> The biggest complexities of any changes here, are the vastly different
> needs of all the different demographics/types of users (e.g. keeping things
> similar enough so that readers don't get confused when they start to edit;
> e.g. not disrupting the current editors whether they use phones or
> desktops; e.g. adding new accessibility & usability improvements/options;
> etc), balanced with the technical requirements of efficiency given our
> current software "stacks".
>
> Hence the "Goals" and "Constraints" sections (for the TL;DR) in
> https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements
> We're planning on adding/tweaking/changing elements in the UI slowly and
> carefully, so that editors can keep on efficiently editing, and readers
> (and editors implicitly!) can slowly get a clearer/better reading
> experience, over the years ahead.
>
> There are /many/ ideas for subtle or significant improvements listed in the
> project pages (don't get distracted by just the first image in the
> slideshow!), and probably more good ideas we're still missing.
> Anyone's feedback (hopefully nuanced and friendly) and further
> ideas/links/suggestions/etc would be appreciated at that project page.
>
> Quiddity / Nick
> _______________________________________________
> 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: [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>

_______________________________________________
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: [hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

John Erling Blad
In reply to this post by Amir E. Aharoni
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…

On Fri, Dec 13, 2019 at 10:14 AM Amir E. Aharoni
<[hidden email]> wrote:

>
> ‫בתאריך יום ה׳, 12 בדצמ׳ 2019 ב-23:37 מאת ‪Pine W‬‏ <‪[hidden email]
> ‬‏>:‬
>
> > I'm thinking out loud here. Are there any estimates of would be required in
> > terms of time (both staff time and community time) and money to make
> > templates and other tools be much easier to globalize across wikis and
> > across skins? I'm looking for an answer that is more specific than "a lot",
> > but isn't a promise or a detailed estimate.
> >
>
> Difficult to say.
>
> I won't make an actual time estimation, because I'm very bad at doing it,
> and because I have too many conflicts of interest ;)
>
> However, I do hope to give you something more specific than "a lot". I
> envision the following feasible plan for "global modules and templates,
> phase 1":
> * Make a localization framework for modules. (
> https://phabricator.wikimedia.org/T238417 ; probably, but not necessarily,
> mostly by staff)
> * Develop a documentation page and a framework for making robust modules (
> https://phabricator.wikimedia.org/T238532 ; probably, but not necessarily,
> mostly by staff).
> * Make modules storable and loadable from a global repository, and
> *actually enable it on all Wikimedia projects* (
> https://phabricator.wikimedia.org/T41610 ; probably, but not necessarily,
> mostly by staff).
> * Migrate most local modules from all the wikis to using global modules,
> and deleting all the migrated local modules. This will have to be done by
> the editors communities in many wikis, and it will only be feasible if all
> the points above are planned and executed well. The challenges I expect at
> this step are:
> ** Making sure that just the right amount of things are global and
> everything that communities want to override locally can be conveniently
> overridden.
> ** Making tough choices about which modules to use when several communities
> developed modules with similar functionality. For example: English, French,
> Russian, Spanish, and Hebrew Wikipedias have modules for loading Wikidata
> values. They aren't the same, but they probably should be. Merging them
> into a global module will require a lot of good-faith collaboration.
>
> Note that I only mentioned modules. Templates have some extra challenges.
> But once modules are done well, a "phase 2" of this project, that would
> tackle templates, will become possible. Also, global gadgets will have to
> be a separate project. Maybe the same localization framework can be used
> for both modules and gadgets, but I cannot think of anything else that they
> really have in common.
>
> All of the above is my interpretation of discussions in the recent Tech
> Conf in Atlanta (other people may have a significantly different
> interpretation). See these Phab tasks, and the web of other tasks linked to
> them:
> https://phabricator.wikimedia.org/T234661
> https://phabricator.wikimedia.org/T52329
> _______________________________________________
> 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: [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>

_______________________________________________
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: [hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

John Erling Blad
In reply to this post by John Erling Blad
For those interested: https://www.w3.org/TR/css-device-adapt-1/

On Wed, Dec 11, 2019 at 10:47 PM John Erling Blad <[hidden email]> 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: [hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

Amir E. Aharoni
In reply to this post by John Erling Blad
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 ‏<[hidden email]>:

> 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…
>
> On Fri, Dec 13, 2019 at 10:14 AM Amir E. Aharoni
> <[hidden email]> wrote:
> >
> > ‫בתאריך יום ה׳, 12 בדצמ׳ 2019 ב-23:37 מאת ‪Pine W‬‏ <‪
> [hidden email]
> > ‬‏>:‬
> >
> > > I'm thinking out loud here. Are there any estimates of would be
> required in
> > > terms of time (both staff time and community time) and money to make
> > > templates and other tools be much easier to globalize across wikis and
> > > across skins? I'm looking for an answer that is more specific than "a
> lot",
> > > but isn't a promise or a detailed estimate.
> > >
> >
> > Difficult to say.
> >
> > I won't make an actual time estimation, because I'm very bad at doing it,
> > and because I have too many conflicts of interest ;)
> >
> > However, I do hope to give you something more specific than "a lot". I
> > envision the following feasible plan for "global modules and templates,
> > phase 1":
> > * Make a localization framework for modules. (
> > https://phabricator.wikimedia.org/T238417 ; probably, but not
> necessarily,
> > mostly by staff)
> > * Develop a documentation page and a framework for making robust modules
> (
> > https://phabricator.wikimedia.org/T238532 ; probably, but not
> necessarily,
> > mostly by staff).
> > * Make modules storable and loadable from a global repository, and
> > *actually enable it on all Wikimedia projects* (
> > https://phabricator.wikimedia.org/T41610 ; probably, but not
> necessarily,
> > mostly by staff).
> > * Migrate most local modules from all the wikis to using global modules,
> > and deleting all the migrated local modules. This will have to be done by
> > the editors communities in many wikis, and it will only be feasible if
> all
> > the points above are planned and executed well. The challenges I expect
> at
> > this step are:
> > ** Making sure that just the right amount of things are global and
> > everything that communities want to override locally can be conveniently
> > overridden.
> > ** Making tough choices about which modules to use when several
> communities
> > developed modules with similar functionality. For example: English,
> French,
> > Russian, Spanish, and Hebrew Wikipedias have modules for loading Wikidata
> > values. They aren't the same, but they probably should be. Merging them
> > into a global module will require a lot of good-faith collaboration.
> >
> > Note that I only mentioned modules. Templates have some extra challenges.
> > But once modules are done well, a "phase 2" of this project, that would
> > tackle templates, will become possible. Also, global gadgets will have to
> > be a separate project. Maybe the same localization framework can be used
> > for both modules and gadgets, but I cannot think of anything else that
> they
> > really have in common.
> >
> > All of the above is my interpretation of discussions in the recent Tech
> > Conf in Atlanta (other people may have a significantly different
> > interpretation). See these Phab tasks, and the web of other tasks linked
> to
> > them:
> > https://phabricator.wikimedia.org/T234661
> > https://phabricator.wikimedia.org/T52329
> > _______________________________________________
> > 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: [hidden email]
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
>
> _______________________________________________
> 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: [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
_______________________________________________
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: [hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

Aron Manning
In reply to this post by Alessandro Marchetti via Wikimedia-l
On Sun, 15 Dec 2019 at 18:53, Chris Gates via Wikimedia-l <
[hidden email]> 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: [hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

Gerard Meijssen-3
In reply to this post by Paul J. Weiss
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 <[hidden email]> 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: [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
_______________________________________________
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: [hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

Pine W
In reply to this post by Aron Manning
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 <[hidden email]> wrote:

> On Sun, 15 Dec 2019 at 18:53, Chris Gates via Wikimedia-l <
> [hidden email]> 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: [hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

John Erling Blad
In reply to this post by Amir E. Aharoni
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
<[hidden email]> 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 ‏<[hidden email]>:
>
> > 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…
> >
> > On Fri, Dec 13, 2019 at 10:14 AM Amir E. Aharoni
> > <[hidden email]> wrote:
> > >
> > > ‫בתאריך יום ה׳, 12 בדצמ׳ 2019 ב-23:37 מאת ‪Pine W‬‏ <‪
> > [hidden email]
> > > ‬‏>:‬
> > >
> > > > I'm thinking out loud here. Are there any estimates of would be
> > required in
> > > > terms of time (both staff time and community time) and money to make
> > > > templates and other tools be much easier to globalize across wikis and
> > > > across skins? I'm looking for an answer that is more specific than "a
> > lot",
> > > > but isn't a promise or a detailed estimate.
> > > >
> > >
> > > Difficult to say.
> > >
> > > I won't make an actual time estimation, because I'm very bad at doing it,
> > > and because I have too many conflicts of interest ;)
> > >
> > > However, I do hope to give you something more specific than "a lot". I
> > > envision the following feasible plan for "global modules and templates,
> > > phase 1":
> > > * Make a localization framework for modules. (
> > > https://phabricator.wikimedia.org/T238417 ; probably, but not
> > necessarily,
> > > mostly by staff)
> > > * Develop a documentation page and a framework for making robust modules
> > (
> > > https://phabricator.wikimedia.org/T238532 ; probably, but not
> > necessarily,
> > > mostly by staff).
> > > * Make modules storable and loadable from a global repository, and
> > > *actually enable it on all Wikimedia projects* (
> > > https://phabricator.wikimedia.org/T41610 ; probably, but not
> > necessarily,
> > > mostly by staff).
> > > * Migrate most local modules from all the wikis to using global modules,
> > > and deleting all the migrated local modules. This will have to be done by
> > > the editors communities in many wikis, and it will only be feasible if
> > all
> > > the points above are planned and executed well. The challenges I expect
> > at
> > > this step are:
> > > ** Making sure that just the right amount of things are global and
> > > everything that communities want to override locally can be conveniently
> > > overridden.
> > > ** Making tough choices about which modules to use when several
> > communities
> > > developed modules with similar functionality. For example: English,
> > French,
> > > Russian, Spanish, and Hebrew Wikipedias have modules for loading Wikidata
> > > values. They aren't the same, but they probably should be. Merging them
> > > into a global module will require a lot of good-faith collaboration.
> > >
> > > Note that I only mentioned modules. Templates have some extra challenges.
> > > But once modules are done well, a "phase 2" of this project, that would
> > > tackle templates, will become possible. Also, global gadgets will have to
> > > be a separate project. Maybe the same localization framework can be used
> > > for both modules and gadgets, but I cannot think of anything else that
> > they
> > > really have in common.
> > >
> > > All of the above is my interpretation of discussions in the recent Tech
> > > Conf in Atlanta (other people may have a significantly different
> > > interpretation). See these Phab tasks, and the web of other tasks linked
> > to
> > > them:
> > > https://phabricator.wikimedia.org/T234661
> > > https://phabricator.wikimedia.org/T52329
> > > _______________________________________________
> > > 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: [hidden email]
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:[hidden email]?subject=unsubscribe>
> >
> > _______________________________________________
> > 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: [hidden email]
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:[hidden email]?subject=unsubscribe>
> _______________________________________________
> 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: [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>

_______________________________________________
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: [hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
12