Tue, Nov 20
Mon, Nov 19
@GoranSMilovanovic no, I'll close it. Thanks btw, this was very useful.
Tue, Nov 13
Nov 5 2018
Yes, what @kai.nissen said: The links are merely static links to the plans, they do not interact with page content (the most simple reason: it is easier to build, and probably easier to use)
Nov 1 2018
@gabriel-wmde : I like the idea. I think it would create too much overhead, to create this – I do not consider the sidebar interaction wise essential, here.
Oct 30 2018
Since the color changes are an easy fix for issues with our last-years best performing banner and has a rationale: Is this on any TODO-list? @kai.nissen
Oct 29 2018
How is this imagined to work for our users ? e.g. imagine, a donor moved to a new place. When/Why would they change the address? Where would they go? How would they know this has been successful?
Oct 26 2018
@tmletzko: This would be in a "text component" for me. After MVP state, it might make sense to give it some sort of style-class to e.g. make it "fine print" (aka a bit smaller and/or lighter) or so.
Oct 24 2018
Briefly talked to @kai.nissen – here clarifications:
Oct 23 2018
Oct 22 2018
2.1 Q2.x are like 1.x, but only for september 2018.
Yes. Initially, you asked for an overview of the last 30 days or so. However, the wmf.mediawiki_history Hadoop table, where the data for this analysis is found, …
Oct 19 2018
Oct 18 2018
Wikibase and help people find all the tools and documentation around it.
People need to better understand what Wikibase is, why they'd want to use it and get answers to questions about how to install/use it.
Oct 4 2018
Oct 1 2018
Monserrat is not wide spread, it is not a standard font to be found in OSes standard font distribution. It is open, though, so potentially it can be installed or distributed.
Sep 27 2018
I do not understand this ticket: What are concept types?
I do not entirely understand this. Is this about creating a mockup/image of a wikibase, but with some custom data in it, because an example item does not match the subject that shall be covered int he custom installation?
Is this tied to docker or should OAuth work no matter which way I install?
As a user need (as in the ticket’s body properly described) the title might be better: "easily modify the color of the theme used in an Wikibase instance". This could have the following solutions:
- Some sort of form where you can choose the colors (and a logo)
- Possibly different implementations for docker vs. old install
@Yurik : Thanks for pointing this out and for providing the graspable OSM example. I added the additional assessment of the usecase in the issue.
Sep 26 2018
Not researched, more expert-y verdict: This should be: Adapt branding for custom installs, which usually entails choosing one or two colors (accent+ secondary), fonts and a logo. Wordpress themes often do this quite well, as do "off-label" software services.
The "root" of the problem seems to be that the frameless buttons can not be toggled. If there is no particular reason against this it seems to be the most sustainable to add toggle mode to the frameless button class (or however OOUI calls "class"/"template"…). If that is not possible for us, I would leave it as it is.
Sep 24 2018
you clarified: reason for this = that I know that formerly, the payment buttons were submit buttons and I might still get stuck in this assumption.
From the point of accessibility I think the "Hoher Kontrast" is best. The "wenig Kontrast" I find problematic, since the light blue and green have a very similar brightness and offer mainly color/hue contrast rather than brightness.
Thanks for the examples!
Could you put the font question in an extra ticket? I think it is useful to get feedback from the devs and they could work on it as a separate task, then.
@Tobias_Schumann_WMDE If that is worth the investment depends on how often people fill in the form and stop OR how often the button is clicked and yields an error.
Sep 20 2018
Sep 6 2018
I'm not sure to understand what you mean :)
Without a deep analysis: Revision history of "Lemma" (Q1) makes sense.
Only having the ID is problematic.
A design/tech suggestion: Define the "box" the lemma is in as wide as possible inside the UI (which follows UI-aligment). Inside this box, align content according to the appropriate alignment for the language it content is in.
Would that go through a function of some sort that renders the Word/Language combination? Or would this be defined in CSS what the sepreator is?
In any case, I have few preferences except that consistency would be great.
Could this always be done or are there case (Languages) where this would be a problem? Because if we can always pre-fill, we could just make it use the same data anyway.
It would make sense if miss-spelling would be also a selectable option (or "flag"?), as far as I understand, you need to define it manually.
- First fix would be getting away from alphabetical sorting of numbers
- I think that sorting by meaning (here: grammatical features) makes the most sense.
Sep 4 2018
Which actions are these? We would need a list of problems OR try to find them ourselves, but that might not surface the relevant ones since we are no frequent editors of Lexeme.
Aug 30 2018
Aug 24 2018
Aug 22 2018
Aug 21 2018
I assume, the proposed application behaviour would fix this as well.
With the caveat that it lack the project’s background, it looks good to me.
Aug 16 2018
Aug 14 2018
Aug 13 2018
Quick solution: Display an animated symbol to signal that the tool is indeed working
Aug 2 2018
I looked at this UI as @Tim_WMDE told me.
Is that an API-ticket or a GUI-Ticket?
@Lea_WMDE @WMDE-Fisch : Did you (or anybody else) try out how such scaling works with a larger sample of changes? I am uncertain here – changing the scaling-the-bars-paradigm from linear to logarithmically strikes me data-viz-wise as very unusual which can indicate that this is not wide spread for a reason.
Aug 1 2018
@Lucas_Werkmeister_WMDE’s suggestion seems sensible, particularly since he tried already. I see the advantage that we block on the concerning thingy, not on the save button in general.
Jul 30 2018
Could I get a screenshot of the gadget/script UI, so we could have a look (I could not get it running myself right now)
Jul 28 2018
@Addshore Yes, JS bit only.
Jul 25 2018
I guess that consistency to the non-contact-form should be there, so the color should also change on the contact form when the fields are on focus.
Rationale: 1) I see no point why it should not 2) If we keep it all constant, it is easier in the future to change widget code and design centrally since it prevents creation of solutions dependent on unusual, only-at-one-location behavior which is hard to factor out again.
Jul 24 2018
I wonder – did any of the teams/people involved in this ticket make any further decisions in the last months or had success in refactoring (core?) code to enable previously difficult things in relation to MVVM Frameworks and Server Side Rendering in PHP and/or Node?
@Cirdan When testing, I noted that we do not execute the searches when a suggestion is selected, but when users press enter. since the suggestions are essential (except you know the category names by heart) it would make sense to execute the search on selection of a suggestion. Can this be done? Or was it tried and it turned out to be a bad idea?
I tried on a HD display as well on a smartphone (Moto G4) and on simulated screens in the firefox dev tools down to 280x280px and encountered no new issues due to screensize there.
Jul 23 2018
Since @Tim_WMDE asked me about the blue framed box and it's content: For longer text e.g. "donation promise" via bank transfer, the text goes between the amount/payment method and the "Spendennummer" and enlarges the box by doing so.
To understand you correctly: Is "too wide" referring to the width of the left search/result column or the whole content-carrying part of the site.
Jul 19 2018
Jul 17 2018
@Verena @Cirdan : We have two choices here – one is going with the Wikimedia Design Style, the other is using the Wikimedia Deutschland e.V. Styleguide. The advantage of the former is that is is made to be used in a digital context, whereas the Wikimedia e.V. is stronger in print application. We could also try to mimic the campagins, but they change(d) style over time a bit and are also specific – maybe someone else wants to adapt the tool, too and then the campaign colors do not make sense – so I would suggest going with the Wikimedia Design Style
Jul 16 2018
I would see the suggestions mainly as a way to understand how the tool works – it is highly unlikely that a suggestion matches a special interest of the user (particularly for long, detailed category names). Thus, it is not essential to have a full name. We could either discard too-long-categories or we shorten them with an ellipsis (max-width and text-overflow: ellipsis; ). Bonus, if the title attribute has the full name, still, since it appears on hover in browsers.
What is meaningful to track depends on our concerns. I assume for now, it is
I like the idea. I would not do this via color due to accessibility and style reasons (quickly looks "too confetti"). The most solid seems for me to just add "schwierig:" or "einfach:" in front of the badges – something like this:or "Ungeprüfter Link (Einfach)"