WikibaseIntegrator
WikibaseIntegrator copied to clipboard
LeMyst
GUI
@LeMyst, there is a growing demand for GUI in WikibaseIntegrator in both Wikidata & Wikibase communities. What do you think about making a simple prototype for that?
@shigapov What do you base this on? I see very few who requests for a GUI besides the standard PHP/Javascript based one. I have used WBI and advocated it a little in the Wikidata community, but seen very few interested in it to be honest. Heard very little talk of a new GUI there as well.
A GUI is a big undertaking IMO. I recommend doing these things that has to be done before any coding starts:
- finding out who the users are (Wikidata editors like me? Someone else?)
- decide whether to work on it as an agile project and whether to do Sprints 2.0
- collect demands and write user story map with user steps and user stories
- make/improve a user journey map or similar to visualize how the flow is through the application
- make/improve a prototype in Figma or similar tool
- test on the users
- iterate
After a few weeks/sprints a good working prototype should be ready for coding and the next phase is to survey the market and see if any projects already implemented some features, like e.g. Daty (written in Python and GTK3/4)
After that, coding can start from scratch or based on code already written.
I recommend doing something similar to youtube-dl and keeping WBI and the GUI completely separate.
I saw many requests about making batch uploads with GUI especially from people in GLAM. Currently they use mainly OpenRefine and QuickStatements, but QS receives lately too many complains. I expect that WikibaseIntegrator can make uploads faster than QS.
I saw many requests about making batch uploads with GUI especially from people in GLAM. Currently they use mainly OpenRefine and QuickStatements, but QS receives lately too many complains. I expect that WikibaseIntegrator can make uploads faster than QS.
Interesting. I use QS to and fro and have not experienced any issues during a long time. It has a Rust backend and runs on a separate instance in the cluster, so it should be as fast as the API can handle (while honoring the maxlag). I have not seen WBI be faster than QS with my tools. It's the same AFAICT. I recently learned OpenRefine also, and it was also fast. Unfortunately it did not support Lexemes so I choose to write my own tool with WBI to get a job done. When it comes to communication WBI is way better than QS, there issues remain unresponded to and unacted upon for months. Here it is very easy to interact and pull requests and issues are handled within days. Kudos to Myst!