5 ms·
I'm pretty confident I don't want this. I'd like to be proven wrong, but there was maybe a couple of cases among hundreds when perfectly working UI was actually
by krick 6y ago
I'm pretty confident I don't want this. I'd like to be proven wrong, but there was maybe a couple of cases among hundreds when perfectly working UI was actually improved instead of fucking broken by "getting a new look".
What I actually would like to be improved is how the data is represented internally. Let's face it, it has been a long time since Wikipedia has become the largest and most accessible knowledge base in the world. It was made simple, which is a part of why it is successful. MediaWiki is pretty much a blogging engine, article content and structure is restricted by the guidelines only, not by the engine. This is good, and at the early stages it was the only possible solution, since there is so much that can be useful in an encyclopedia article.
However, now we know a lot of patterns of how data represented in different articles is similar. But wikitext is still basically just a human language with a bit of markup elements. Sure, there are templates, which are slowly improving over the time, but still, it's petty much a collection of free-form blogposts. There is almost no way to separate data from the representation (i.e. to have a table contents as a csv, with a template assigned). There were some attempts to make it possible, but querying (or modifying) data automatically is still very much a pain. A lot of it requires parsing, and (perhaps even more annoyingly) — pretty simple parsing. But you have to do that work for every single problem you have. Instead of, you know, to just query data I know there is. In fact, when you start parsing templates it becomes very clear very quickly, that they are vastly underused. Absolutely the same data, like years of life in bio-articles is still represented differently even in very elaborate and well-maintained articles.
Very little has been done in this regard over the last 10 years, I feel. And improvement does require a lot of work: looking for possible templates, promoting generic data representation among contributors, modifying wikitext to allow for it, improving the API. It they are looking how to spend money, I'd rather want it to be this, because making a lot of data machine-accessible would be literally as huge, as making wikipedia human-accessible was about 20-15 years ago. Sometimes I need to open 500 articles to read a single sentence in each of them, and some python script could've done it for me in a second (a couple of seconds maybe, depending on how wikipedia stores and represents the data).
- exacube 6y agoFriend, they are using data and research to improve their UI. Thinking that "other products didnt do it well so you shouldn't try" is extremely unproductive. It's also not productive to argue for a vastly more difficult and different area, like their data model, during a topic of refreshing UI..
- bawolff 6y agoI think the current efforts in this regard are focused on https://wikidata.org https://wikidata.org and to a lesser extent the new (planning stages only so far) abstract wikipedia project https://meta.wikimedia.org/wiki/Abstract_Wikipedia https://meta.wikimedia.org/wiki/Abstract_Wikipedia . Those are both the opposite of an incremental approach but i'd be curious what you think of them.
- krick 6y agoI don't want to say anything negative about them, because both are fine initiative on their own. But I'm not hugely optimistic about them (yet). Both can succeed, but both are pretty far from what I'd consider succeeding. First of, I want to highlight what you already said: this approach is the opposite of an incremental. Both approaches are fine and have their own value, but they are truly different, and not somehow philosophically "opposite, but the same". This is not a perfect example by any means, but just to be less abstract, let's pretend you want to dig a really big hole. 1. "Disruptive innovation" approach is spending a lot of resources on research without any real output for a long time, in hope that in the end it will produce an excavator, which will surpass the work of 1000 mortal men. These projects are costly and provide no guarantee, they are usually successfully done by small research groups in facilities like "Google X". Any such project is always a huge bet, it either works out or not. And even "almost working out" e.g. producing engineering schemes that will be improved upon in a 100 years to actually produce an excavator, mostly counts as "not working out" for any individual project and organization. 2. More conventional approach would be to motivate 1000 men to dig a hole using shovels and buckets, maybe developing a better shovels and buckets in the process, if possible. The trickiest part here is actually motivating 1000 men: using money, violence, "gamification" or whatever. Wikimedia foundation is not known so much for "disruptive innovation", as it it for crowdsourcing. And even if it was: every moonshot is unlike any previous one. In fact, it motivates hundreds of thousand of people to contribute without directly paying them money, which is a huge feat. Now, let's get to Wikidata. Web 3.0 ideas with OWL and knowledge graphs are older than actual Wikipedia. And maybe if I'll say they weren't successful, somebody will retort by mentioning some projects where OWL and RDF are actually useful... I mean, sure. But are they as successful as Wikipedia? Are they as successful as Web 1.0? This is rhetorical, of course. "Why" can be arguable, but I feel like it's actually pretty clear why: people do not willingly contribute to something they don't understand, and maintaining a data graph still requires a lot of manual contribution and editing. This kind of contribution has to be made an effortless by-product of what they actually want: putting something on the internet they (and other people) can access in a human-understandable format. They don't care about stuff being machine-readable. You may know that they actually want it, because the possibilities it will open are enormous, but most of contributors don't know it. It's easy to see why I should edit an article on the subject I care about, that contains wrong info or is incomplete. It's not as obvious why I should edit some abstract "item" somewhere out there, and care about some "data graph" I've never seen... That is, until I need to access it using SPARQL myself. I'm more optimistic about Abstract Wikipedia for that reason as well: there are plenty of biligual Wikipedia users, and many of them know that sometimes reading the same article in 2 different languages reveals that there exist almost parallel universes, with communities speaking different languages having their own "truth". Sometimes it's actually useful, because you get to see that there is actually "no truth", but it's also apparent why something like "Abstract Wikipedia" may be useful. But that is too early in the concept phase to seriously speak about it, anyway. So, once more: these will either succeed or will they fail. That remains to be seen. What I was talking about is much more approachable, I think. This is not an "all or nothing" undertaking. There are plenty of very real improvements that can be made to the data model of each and every article, and they will remain regardless of whether they help to create "Wikipedia:Web 3.0" or not (and I actually think they have very real prospect in helping with that, because it will literally get people editing the data graph without even knowing about it). They are useful on their own. And unlike my "friend" exacube in the neighbour thread I actually think this kinda is about UI. Because unlike with abstract data graph, people care about approachable, clear and uniform interfaces. A random example, to clarify what I mean. You can look up some "List of birds of CountryX" kind of articles in different languages and different countries. Semantically, all of these are the same thing, there can be a single "best UI" for that, that any given encyclopedic organization can decide on. Wikipedia doesn't have one: sometimes it's a table, sometimes it's a list. Sometimes there are picture of a bird thumbnail, because that's useful. Sometimes (for a table of the same length for the same country in a different language) there is not, because it's obviously a lot of work to make such a table, and person who did it just didn't bother. Yet these photos exist in the `BirdName` articles, so you could prefetch them automatically, if there was a common structure to all of it. Same for many other data. And there are countless examples of this kind.
- sjy 6y ago> MediaWiki is pretty much a blogging engine, article content and structure is restricted by the guidelines only, not by the engine. This is good, and at the early stages it was the only possible solution, since there is so much that can be useful in an encyclopedia article. I wonder whether there is a fundamental trade-off here. The track record of expert systems and structured knowledge bases is not great. Capturing data in these systems is relatively hard and expensive and therefore none of them have become as detailed as Wikipedia (cf. Wikidata). We also know that the task of giving structure to our own implicit knowledge by writing it down, even in a way that is not machine-accessible, is difficult and time-consuming. It may not be possible to create machine-accessible knowledge bases without “front-loading” the work of giving structure to that knowledge. Knowledge bases that require this to be done may never be as detailed and comprehensive as a less structured resource like Wikipedia, just as Wikipedia will never be as detailed and comprehensive as the (even less machine-readable) sum of all human knowledge distributed over the set of surviving brains and texts.
- krick 6y agoI believe that this is absolutely the case. In fact, this is kind of the point. No way we would have Wikipedia if it did demand much structure from the very beginning. I don't see it possible (and, in fact, I don't want it to happen) to enforce structure in articles that cover some abstract concept, idea or new phenomena. But for better or worse, Wikipedia is now also a huge database of biological species, anime characters and car models. It has several million of biographies, which cannot (nor probably should) be simplified for machine comprehension, but (not universally, of course, but highlighting that is a part of the point as well) have very concrete data entires, like DOB/DOD, "simplified characteristic" (actor, mathematician, politician, imperor of Rome), height/weight for many athletes and so on. And (even though this isn't the point), amazingly, all these countless articles already follow roughly the same structure. Like, for each biography you can expect to find the circumstances of death near the end of "Life" section, but before "Legacy", and you'll find "Interesting facts" in the very end. It may seem very natural (and it is!), but the reason I'm mentioning this, is that encyclopedia also is the tool that helps the authors to structurize data. I'm sure that 2nd and 3rd dinosaur articles were very different from each other in structure. But when you are writing a 1001th, it will be pretty similar to 1000th. Even if for you personally it's the first one to write. And it is the point that it's hard for people to consciously produce structured, machine readable data. But we want to have structured, machine readable data. That's why I think gradually modifying Wikipedia itself in a way to unobtrusively trick us to provide this data, is the way as opposed to wikidata. There is an example to get the feel of what I mean in the last paragraph of my response to bawolff, if you are curious.