Not sure where is the good place to put my feedback of this kind... I'll put it here as a comment, but if there's a better place let me know.

TLDR:

1. The need to view edit a whole item every time is a practical problem. It is often useful, but not always. It is this paradigm that has to be addressed before discussing the web development frameworks used to implement it.
2. Wikidata is too generic as a data entry and storage mechanism, and it leaves all customization and tailored processing to external tools, which are too diverse and unstable in practice.

In more detail:

A general problem with both Wikidata and its Lexeme feature is that it provides a rather feature-rich data entry mechanism, but it's too generic and not targeted at particular types of data. It's also oriented more at data entry than at data display.

Wikidata developers' response to this usually goes along the lines that in their vision, Wikidata is a generic data storage, whereas tailored solutions for adding and displaying particular types of data should come through other tools. It's a sensible response, but it doesn't really solve the problem. The current world of Wikidata tools has a lot of engineering brilliance, but it's also a bit too "wild wild west" — the tools have strange names, I always find it difficult to find the tool I need, their UI design and usage styles are too diverse, their localization is not done according to Wikimedia's standards, they are unstable and often get neglected and broken, and so on. Of course, they do have many dedicated users, but evidently, this doesn't scale as much as it could. If Wikidata developers don't want to make Wikidata too complex by filling it with too many features for particular narrow use cases, they could address this problem by developing a richer library for tool developers, which would promote stability and uniformity.

Another consequence of the "generic data storage and entry" paradigm is that Wikidata doesn't have its own mechanism for convenient adding of multiple pieces of data. Just to enter a small piece of data, the user has to open a whole editing form for an item or a lexeme, and to enter it for several similar items, the user has to open multiple browser tabs, sometimes dozens. The most obvious example of this problem is translation of multiple labels (T64695). Translation of multiple lexemes is another. It's also a huge missed opportunity for mobile contributions: translating short labels or lexemes with a convenient UI could drive literally millions of quick contributions, especially from very diverse countries and languages where desktop usage is low.

For translating the software UI, we've had translatewiki since 2006, which became even better designed for translating multiple strings in 2012. It's well integrated with MediaWiki and successfully used by thousands of people, and a similar paradigm could also be used for Wikidata (although I'll readily admit that it's not nearly as good on mobile devices as it could be). People recommend that I use Tabernacle or some other tool for doing multiple translations, but I never had any success with it—I found it confusing, unstable, and not integrated with the MediaWiki UI.

A frequent, but wrong piece of criticism of Wikidata design is that it has tight forms replacing the ultra-loose format of wiki pages. Some Wikipedians criticize it as being too tight and too different from wiki pages, to the point of "not being a wiki at all". This is wrong: a wiki is not necessarily a website with a huge blank textarea that has to be filled by free-form markup, but a website that anyone can edit, and Wikidata is very much a wiki in this sense. It's the need to edit a whole item every time that is the problem.

I rewrote and moved my personal notes down here:

Since the Lexical data extension is a subpart of Wikidata it would be interesting to find out if that is also successful from a user perspective and if not, whether to do something about it or not.

My personal notes on the design decisions are here:

I see that someone took a design decision to go with

• Vue js
• async code that *magically* updates in the background and does *all* kinds of advanced tricks to avoid a page load
• the complexity of the code is pretty high because the
• the buttons for save/edit jumps around as the page loads in the beginning and after an action that triggers the async stuff in the background. The only other 2 UIs in existence for WD does not have these "jumping" unpredictability problems: daty and wikidata-cli.
• now a couple of years down the road we still have a lot of weird UI bugs like
  • "Error message when adding senses does not go away after saving using enter"
  • "Page title not updated after editing lemma"
  • "Lemma box too narrow for longer words"

As you might have guessed I'm not a big fan of JS browser UIs and I would like to have this project and the greater Wikidata UI project evaluated so we can *avoid* the same pitfalls in the UI design of Wikifunctions. I'm a big fan of the KISS and YAGNI principles and use them in planning and programming my own hobby projects, see

• https://www.wikidata.org/wiki/Wikidata:LexUse
• https://www.wikidata.org/wiki/Wikidata:ImproveWikidata

see also https://t.me/c/1325756915/3976