[Wikidata-bugs] [Maniphest] T272203: Evaluate UI after x months of development and x user stories implemented

[Amire80]

Amire80 added a comment.


  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.

TASK DETAIL
  https://phabricator.wikimedia.org/T272203

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Amire80
Cc: Amire80, So9q, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, Mahir256, 
QZanden, LawExplorer, _jensen, rosalieper, Bodhisattwa, Scott_WUaS, 
Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T272203: Evaluate UI after x months of development and x user stories implemented

[So9q]

So9q created this task.
So9q added a project: Wikidata Lexicographical data.
Restricted Application added a project: Wikidata.

TASK DESCRIPTION
  So here we have the Workboard of our Lexeme namespace UI userstories and 
bugstories.
  https://phabricator.wikimedia.org/tag/wikidata_lexicographical_data/
  Has anyone evaluated how the process has worked from a user perspective since 
the Extension was started?
  I see that someone took a design decision to go with
  
  1. Vue js
  2. async code that *magically* updates in the background and does *all* kinds 
of advanced tricks to avoid a page load
  3. KISS and YAGNI is generally not used as design principles it seems
  4. the complexity of the code is pretty high
  5. now a couple of years down the road we still have a lot of weird UI bugs 
like
  
  5a) "Error message when adding senses does not go away after saving using 
enter"
  5b) "Page title not updated after editing lemma"
  5c) "Lemma box too narrow for longer words"
  
  I'm not interested in blame, but an honest evaluation whether the road taken 
given the budget, time line and resources available has given the results we 
wanted.
  
  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.
  
  see also https://t.me/c/1325756915/3976
  
  I encourage you to invite the uses to help in the evaluation e.g. by asking 
them for their editing experience and how satisfied they are with the current 
system.

TASK DETAIL
  https://phabricator.wikimedia.org/T272203

WORKBOARD
  https://phabricator.wikimedia.org/project/board/2292/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: So9q
Cc: So9q, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, Mahir256, QZanden, 
LawExplorer, _jensen, rosalieper, Bodhisattwa, Scott_WUaS, Wikidata-bugs, aude, 
Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs