User Details
- User Since
- May 2 2016, 2:46 PM (445 w, 2 d)
- Roles
- Disabled
- LDAP User
- WMDE-jand
- MediaWiki User
- Jan Dittrich (WMDE) [ Global Accounts ]
Aug 17 2022
Aug 12 2022
Jul 6 2022
Using vuetify, we probably want a skeleton loader with, lets say, two list-items in there?
Jul 5 2022
Option 2: Fix api to work with task-specific emails
Jul 4 2022
Jun 28 2022
Jun 20 2022
Would need answer from developers to: "Which UI framework was used to build the UI?". We then could see what styles are predefined for errors, notifications and provide a mockup to a developer to implement the feedback.
Jun 14 2022
Jun 13 2022
I think we would need to hardcode a place for impressum anyway, since the link should be always visible in the footer, which users currently can't config themselves anyway, which would ease both solutions as we would know where it is.
I think that providing a note next to "create wiki" is not very helpful for users. They can't act on it there and just get the info to create something they probably never heard about. If we do this, it will also stick around and will lead to it "not being a serious problem" despite its sub-par usability.
Possible solutions mockups:
Jun 8 2022
Is there some way for users to know how many Wikis they still can create (a counter or so?) Or do they need the documentation to find that out?
May 30 2022
I looked into this to find out what this function does. Here is what I currently assume:
May 24 2022
Thanks – I approve!
May 17 2022
disagree; wikibase.cloud is a WMDE product, and technical documentation for our products lives on mediawiki.org
I assume the link to the documentation should be easily accessible for people who want to get information on WBStack in general and for people who are logged in.
May 11 2022
Apr 26 2022
Apr 19 2022
Apr 11 2022
I wouldn't mind if an engineer/UX/Designer did letter-by-letter check that the other two parts in the linked change already have the intended text.
Apr 6 2022
In case the HTML is too messy, you could try piping it through pandoc – download as .docx and convert to HTML. Use pandoc inputdoc.docx -o outputdoc.html. I gave it a try and it works well, aside of the original docx having some sections in tables and headlines being manually set to bold, which are quirks that carry over. But I guess it is still a good start for resolving these quirks. (You could write a pandoc script that resolves these issues, but you are probably far faster doing it manually)
Mar 23 2022
- We could not include all content from the suggested text, since there are no FAQ yet (and we did not want to create a dysfunctional link)
- We went with the not-a-waitinglist text-version for now, but we can easily add a link to the the get considered for closed beta form (we probably should be clear likely it is to get in the closed beta)
Feb 9 2022
Just to check: Mere CNAME is sufficient, we do not need A and AAA records set?
Feb 7 2022
Jan 4 2022
Here some background on what we talked about:
Oct 18 2021
sure sure, go ahead :)
What about:
Aug 17 2021
Aug 2 2021
Thanks, super interesting! Some things are beyond my data-skills, thus, I look forward to feedback from other people!
Jul 28 2021
Seems also relevant: https://eprints.whiterose.ac.uk/140352/1/evolution-wikidata-editors.pdf "The evolution of power and standard Wikidata editors: comparing editing behavior over time to predict lifespan and volume of edits"
Jun 16 2021
Jun 15 2021
May 31 2021
From: "How Long Do Wikipedia Editors Keep Active?"
Some new pointers (via @MGerlach ):
May 25 2021
Barrier to entry: Two thoughts on this.
I believe TypeScript's JSDoc mode does support defining full shapes as well. Right?
I am beginning to think that we might need to readjust the definition of when we consider the editor to has left Wikidata as I have proposed it. What do you think? Any ideas?
Also, I have a vague and anecdotal memory that Wikidata has a lot of users who are semi- or fully-automated bots but are not registered as such. Is this the case? If so, is there some other heuristic like overly rapid editing that we can use to filter out these users or analyze them separately?
May 11 2021
May 10 2021
People at Wikidata worked on having a part of the API possibilities accessible via REST but we also explored a bit of GraphQL and other ideas. If you are interested, @Silvan_WMDE and @Addshore can probably tell more.
This report has some survey results concerning skills in various API standards of the people from the Wikidata community who answered the survey.
@daniel maybe "refactoring Mediawiki" might be more descriptive? I looked at the title and wondered what you want to decouple Mediawiki from.
Apr 17 2021
Apr 14 2021
Yes, looks great! Thansk
1 swapped
Mar 29 2021
So, as I learned from a team member the WMF has put up their modal design. They use a right-upper corner x.
Here is the text from the mockup above:
Mar 23 2021
It is relevant that the "Assess Quality"-button is in the "box" that also contains the items or SPARQL, respectively; otherwise we might suggest, UI-wise, that the button is bound to all inputs not just what is in the currently activated tab.
Mar 22 2021
There is no x to keep it easy to use (aka hit with your fingers and find it at an expectable position) on mobile. I could try to find out what Wikit is doing with popups and if they change between mobile and desktop and suggest a matching behavior here.
Mar 15 2021
Looks fine to me!
Mar 10 2021
Plotly already provides for that: if a user zooms in the diagram, an overlay message should pop up …
- If it is possible to give "human" labels to the variables, and if I understand them right it might be useful to do the following
- current_year → over last 12 month
- current_snapshot → over last month
- history_to_current_snapshot → all time
- For the diagram it would be great to have a reset button somewhere in case one creates a mess by zooming in or panning away from the graph. Hope that is just a config option.
One variable I did not ask for: current_year – is this from beginning of the calendar year to the current snapshot or from the snapshot 12 months ago until the current snapshot?
Mar 3 2021
This would look like this:
Is there some (implicit) standard where the logo should be?
Currently is it as big as on Wikidata itself, on the right side and linked to Wikidata. So currently is has undue weight.
I am generally fine with not providing them but afaic we make at least two mathematically dubious steps so I would have the tendency to be transparent. We could also explain how the score is created in the help file, though.
Mar 2 2021
Discussion about error messages to T276236
Can we distinguish the problems? Cause then we could have:
I considered the flyout, but it turns out to be harder to integrate in existing layouts, so I went ahead with a popup.
Isn’t the most likely reason for an error that the WiFi is flaky?
Where should the links go? Wikimedia Deutschland e.V.,
Github project and github issues?
If our primary target group is editors, then we could just show the whole table directly and I put all relevant information and action above the table so nothing is pushed into invisibility.
We could have a "How is this score calculated" flyout and put all info about ORES, difference between the things items refer to and the content of the items themselves etc. inside there.
Lets split the "other developers should be able to report problems" in a separate ticket; as we should do with "have a error message that provides helpful guidance to problem solving (for non-developers)"
Mar 1 2021
This may be problematic for users who don't have Github but would like to get your thoughts anyway.
Currently we have
Not yet. I think we should solve this with T275993.
That makes sense.