Want to take part in these discussions? Sign in if you have an account, or apply for one below
Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.
The nLab is a fantastic resource, and I think the experience (save the search) as a reader is generally very good. However, as an editor, the nLab is not approachable. I say this as someone who has made a scattering of minor edits to a number of pages and written a few stubs: enough to be familiar with the experience, but without having become so familiar that I can ignore the issues. I’m sure anyone who has edited the nLab knows the sorts of issues I mean, but to give a few:
I want to focus on the first point, however, because it is hard to overstate just how much more approachable editing becomes with a WYSIWYG editor. If you try editing an article on Wikipedia, for instance, the difference is substantial: there are helpful tools for previewing LaTeX formulae, for creating links (both cross-references and external links), for various formatting options. Editing feels not that different from viewing. I am certain that if the nLab had a similar facility, we would see much more growth: I know I personally have avoided editing the nLab in the past because it takes much longer than it should, I end up making mistakes, and I can’t figure out how to do something — but I’ve never had these problems with Wikipedia. I have spoken to others who feel similarly.
The great thing is that MediaWiki is free and open source. In theory, we could use the same software that Wikipedia uses for the nLab, perhaps with a with of our own extensions to make things like editing commutative diagrams easier, and tweaking the style to look more familiar. I recognise this would be a large task, though I venture that perhaps in the long run it could save time spent modifying the nLab’s custom fork of Instiki. However, it would definitely save time for editors and increase the number of people willing to make contributions.
I am sure something like this has been considered in the past: I am wondering what the main obstructions to doing this are (whether technological or sociological). Thanks!
I should say: if you want to experience MediaWiki’s experience for editing, you can test it out here.
Yes. The idea of moving to another platform has been discussed several times before. (It was much more urgent until a couple of years ago, when the system would constantly crash and misbehave. Now at least it runs stably.) Once we were at the verge of migrating to WorkingWiki – but then both me and the admin at that time ran out of spare time to actually go through with it.
That’s the general problem: time and resources. The Lab is the way it is not because we agreed that it is great this way (it isn’t), but because that’s what we got with the energy that people had invested in the past.
So the problem is not to convince “us” to improve on the software platform. The problem is to find anyone with the required time and energy at their hands to do anything.
Richard Williamson, our admin now, says he is, slowly but surely, working on doing some rewrite of the system. He can say more about this than I can.
Then there was recently the idea of crowd-funding the dedicated service of an IT-company to do the stuff we want to be done. From reactions here and on Twitter it seems that plenty of people would be willing to join in such a funding, some of them with considerable sums. But my last attempt to make this happen, has failed so far due to bureaucratic issues with channeling the payment.
Yes, this has cropped up several times in the past. I am not a member of the steering committee and am simply at the service of others people’s wishes, but I can offer my personal opinion, which is that it is naïve to think that moving to MediaWiki would be an improvement. There are many reasons for this, I can offer a few.
1) It is a big advantage to be able to customise the software; the scope of this will always be limited in any third party solution plus add ons. This is especially important for a large project like the nLab, which will always push the boundaries of the software. Historically, what happened with the nLab before my involvement working on the software (which began about 2 and a half years ago I think) was that the project basically hit the limits of what Instiki was capable of, and became unusable for certain pages; I have done significant work to customise things to make it at least work stably, as Urs wrote, and added some features along the way.
2) I think it is naïve and probably wrong to assume that nLab editorship would signficantly increase on a different platform. This point is usually raised in this context, e.g. Dmitri Pavlov has raised it before, but I doubt it; I think a contributor motivated enough to make regular contributions will not likely be put off by syntax. It may lower the threshold a bit, that is true, but I wouldn’t go further than that.
3) I don’t think the syntax is too bad currently. Take a look at the source of semi-graph that I created yesterday. Apart from the referenceing, this is basically LaTeX with some boilerplate pleasantly removed; I don’t see it as particularly idiosyncratic or inconvenient. The original non-Markdown part of the Instiki syntax was, I agree, idiosyncratic in many places, but there are now alternatives available for most of this. I don’t think there is any problem with Markdown itself. In particular, I do not believe that MediaWiki’s syntax is actually significantly simpler.
4) There are aspects of the nLab/nForum that I think many people believe are superior to MediaWiki. E.g. the use of the nForum for discussion is for some people superior to discussion pages on Wikipedia.
5) Personally I don’t tend to find MediaWiki sites other than Wikipedia look good at all, I think the nLab is superior in this respect. Even for Wikipedia, I don’t the nLab is any worse readability wise.
6) I would be sceptical of third party IT companies doing a great job; it is a big advantage to have software developers who know the project well. I think that funds would be very good, but they should be directed towards cloud infrastructure.
Thus, my personal opinion is that we should simply focus efforts on improving the nLab. We are limited only by the time and ability of people willing to do software development. I personally have never seen a request that I think I could not do if I had time. We also have Alexis who has joined the team and is willing to help out.
Referencing for example is something that we definitely should do properly, it has been on the TODO list for a couple of years. I have even written large parts of the necessary API, it is sitting in development on the nLab server. However, I have postponed all such larger feature projects until what I consider to be the most important goal for the moment is completed: movement to the cloud. To make that move, as Urs wrote, I am slowly working on a complete rewrite of the nForum, and a complete removal of the old Instiki from the nLab, i.e. the code will eventually date from the time of my involvement on. After that, we will be in a good position to do further development, and in a much better position for other software developers to come onboard.
A WYSIWYG editor is definitely something we could consider, it seems perfectly possible, though it is slightly contra to the philosophy of Instiki, in which it is expected to use edits as previews, e.g. changes in the half an hour after an edit will be considered the same edit; referencing we will definitely do; accounts are also something we definitely need and which again has been on the TODO list for a while, and which I have again actually made a small start on.
As I say, this is just my personal opinion. I have only been involved on the software side of the nLab for 2.5 years or so, as I say, though I have followed the nLab/nForum closely almost from the beginning.
PS - I would not really describe my role as an ’admin’. I would say that an ’admin’ role was that which Andrew Stacey was doing at the beginning. I am doing ’software development’ really (this also happens to be my day job), and just happen to be doing the admin role as well in the absence of anyone else to do it; I actually find the admin part of the role somewhat tedious and would happily not do it!!!
Thanks you Urs and Richard: these were the sorts of comments I was hoping for!
That’s the general problem: time and resources. The nLab is the way it is not because we agreed that it is great this way (it isn’t), but because that’s what we got with the energy that people had invested in the past.
This was perhaps what I was angling at and should have been more forthright about. I understand that this would take time and effort and was wondering whether most people would prefer a MediaWiki-based system if someone was willing to undertake the project. Your comment seems to indicate an affirmative, but Richard suggests otherwise (and it’s good to hear both sides!). I should be clear that I’m really just interested to hear the reasoning at the moment: if there was interest in hypothetically moving over, then we could discuss whether it was actually practical. (There’s no point discussing who’s going to be responsible for this if there isn’t interest.)
There are many reasons for this, I can offer a few.
Thank you! I’ll try to give my perspective on these too.
1) It is a big advantage to be able to customise the software; the scope of this will always be limited in any third party solution plus add ons.
I was wondering if you had any specific examples? I say this only because MediaWiki is a much more mature project than Instiki and I would have imagined third-party add ons could be sufficient for the nLab’s purposes.
I think a contributor motivated enough to make regular contributions will not likely be put off by syntax.
I agree that someone who is motivated enough will not be put off, but I argue there are some who are currently put off, who would contribute if the barrier was lower. It is hard to back this up without, e.g. doing a survey, but I know that I personally have made small edits to Wikipedia on occasion, but have often not made small edits to the nLab, simply because the process is much friendlier and quicker on Wikipedia (despite being more invested in the content of the nLab). I have also spoken to several other people who have shared similar experiences (maybe I can persuade them to join the discussion too, to share their thoughts).
I don’t think the syntax is too bad currently. [..] In particular, I do not believe that MediaWiki’s syntax is actually significantly simpler.
I generally agree with this. It’s not too bad. However, WYSIWYG editing, without needing to see the syntax at all, is much simpler. Part of the problem, perhaps, is that even though Markdown is relatively simple, the syntax extensions that a Wiki language needs to support (e.g. referencing, tables, etc.) ends up complicating things (MediaWiki’s syntax isn’t really any better, but the thing is that you rarely need to deal with it any more). Seeing the final content rather than even something simple like Markdown, is much more convenient.
4) There are aspects of the nLab/nForum that I think many people believe are superior to MediaWiki. E.g. the use of the nForum for discussion is for some people superior to discussion pages on Wikipedia.
I completely agree: I’m just interested in the usability of the nLab Wiki.
5) Personally I don’t tend to find MediaWiki sites other than Wikipedia look good at all, I think the nLab is superior in this respect. Even for Wikipedia, I don’t the nLab is any worse readability wise.
I tend to agree with this also. I think for reading, the nLab is completely fine, and we could keep that style or similar even whilst changing the underlying software. That said, I think Wikipedia’s styling itself is also fine, which presumably comes with the open source MediaWiki software.
We are limited only by the time and ability of people willing to do software development. I personally have never seen a request that I think I could not do if I had time.
I do not doubt this in the slightest. However, time is the crucial problem. I would imagine MediaWiki already supports 95% of what we would want the nLab to support; on the other hand, implementing it manually (especially something as complex as WYSIWYG) takes a long time for one or two people. You give several examples of things that have been on your TODO list for years, which are already supported by MediaWiki. If someone undertook the effort to move over, hypothetically speaking, couldn’t this save you and Alexis time that could be better spent on other things?
it is slightly contra to the philosophy of Instiki, in which it is expected to use edits as previews, e.g. changes in the half an hour after an edit will be considered the same edit
I’m not sure if this was meant as a downside or not, but I imagine that any system that has some sort of history would be sufficient.
Thank you for sharing your thoughts, Richard!
Re #4, part 2): One point that I raised previously was that having a TeX-compatible syntax would allow contributors to import whole TeX documents into nLab, e.g., expository sections of an article. Currently, this is not possible without additional extensive editing.
That being said, I now much more happy with nLab’s syntax, the remaining major issue is support for label/ref/bibitem/cite.
Mathematicians are used to typesetting in TeX without any form of WYSIWYG, so I am not sure this issue has any importance.
I don’t have a lot of time to talk about this (again) right now, but let me just mention my point of view. I feel very strongly, contra Richard, that it would be better to switch to a system that has a wide user and developer base as well as a plugin architecture that we could use to customize it. Mediawiki fits that bill… except that its syntax is IMHO execrable. But possibly we could find a plugin that changes its syntax to markdown?
I am dubious that WYSIWYG will matter much for most mathematicians, as Dmitri says.
Re #5: I’ll just reply on a couple of points.
I was wondering if you had any specific examples? I say this only because MediaWiki is a much more mature project than Instiki and I would have imagined third-party add ons could be sufficient for the nLab’s purposes.
I’d rather not go too much into detail here, but just say for example that if one has to do a lot of work to add functionality and much of the core software is irrelevant, I’d rather stick to something which is streamlined and to the point, in a language of our own choosing, without having to continuously have to modify code to cope with breaking changes in the core, etc. This is one issue that was present in Instiki: it had a lot of bloat, was written in an environment that had not been kept up to date and would be a significant undertaking to bring up to date, etc. I have done a lot of work removing stuff, etc.
I can also say that some of the nLab pages are very large. Try opening geometry of physics – perturbative quantum field theory for example in a browser where MathJax is used, and look how long it takes the Javascript to load. No doubt the MediaWiki platform can be made to cope with this page, but it is not a given.
I can also guarantee that if we wish to use MediaWiki and have anything like the current nLab workflow, significant work on customisation/add ons will indeed be needed. Personally, as I say, it is better to have a streamlined platform which meets exactly our needs. It is true that a software developer will always be needed to understand and make changes to the code, but that is the nature of volunteer projects; one hopes somebody always steps up. If not, one can pay an IT consultant to do it.
4) There are aspects of the nLab/nForum that I think many people believe are superior to MediaWiki. E.g. the use of the nForum for discussion is for some people superior to discussion pages on Wikipedia.
I completely agree: I’m just interested in the usability of the nLab Wiki.
My point here was that the tight integration of the nLab/nForum relies on the ability to fiddle with the source code of the nLab. Probably one can do it in the MediaWiki platform too. But if we end up having to recreate everything, possibly in a different and not exactly beautiful language (PhP), again, I don’t see an advantage, and do see disadvantages.
I would imagine MediaWiki already supports 95% of what we would want the nLab to support
This is wildly over-optimistic in my opinion if we wish for the nLab to be anything like it is today; as above, I believe one would need a lot of customisation/add-on work.
on the other hand, implementing it manually (especially something as complex as WYSIWYG) takes a long time for one or two people. You give several examples of things that have been on your TODO list for years, which are already supported by MediaWiki. If someone undertook the effort to move over, hypothetically speaking, couldn’t this save you and Alexis time that could be better spent on other things?
I view the time that I spend on the nLab as supporting a project that I feel is worthwhile. Why do anything? When I got involved (hesitantly), there literally didn’t seem anybody else. Certainly my time is very limited, but that is the understanding I work on: I will fix major issues as soon as I can, and the rest I will do as time allows, which may be several years for non-urgent matters. If somebody else comes along who can offer more time, they are always welcome to take over.
I’m not sure if this was meant as a downside or not
It was not, just as an explanation.
Re #6: Thanks for clarifying! Regarding the following:
the remaining major issue is support for label/ref/bibitem/cite.
I agree, but just wanted to mention that label/ref are supported for theorem environments.
Re #7:
I feel very strongly, contra Richard, that it would be better to switch to a system that has a wide user and developer base as well as a plugin architecture that we could use to customize it.
I have already given reasons above that I think a wide developer base can be a negative rather than a positive when the developers’ concerns are not directly to do with one’s own project. And, as I have already expressed, I am extremely skeptical that a ’bloated core plus heavy reliance on plugins’ is a superior model to the one we have now.
However, if somebody wishes to try it, of course they can do so. Are you offering to try this, varkor? If so, there is space on the nLab server for you to try it out should you wish (in a way which does not interact with the current nLab). I would be unlikely to be motivated to contribute to this myself, as I don’t believe it is a superior solution to the homegrown one in the long run.
As I said, I don’t have time to have this argument with Richard again right now. Let me just point out, for the benefit of those who may not have been present at earlier iterations, that one very important potential benefit of a mature and widely used project is security.
I would agree, though, that its use of PHP is another strike against MediaWiki in particular. But there are other established and widely used platforms with plugin architectures that are written in better programming languages.
As I said, I don’t have time to have this argument with Richard again right now. Let me just point out, for the benefit of those who may not have been present at earlier iterations, that one very important potential benefit of a mature and widely used project is security.
I just wish to correct a possibly misleading interpretation of this, that I am somehow blocking the change. I am not doing so now, and have not done so on previous occasions. I am giving my opinion. This is based on hands-on experience of working on the nLab and of working as a professional software developer on a web platform of a scale many orders of magnitude greater than the nLab, but that does not necessarily make it right; as I say, someone else is willing to try a different solution if they wish.
I also wish to correct a possible dig here that the nLab is somehow insecure in a way that any reader or editor of the nLab should be troubled about. This is not the case. Anyone who believes otherwise is welcome to demonstrate it, I encourage security testing by anybody interested in this kind of thing.
On a different note, I realised that I should probably clarify that it does not take me a year or two to implement features because they require a huge amount of time; it is because I do not work on them for long periods due to other commitments. On the occasions where I am able focus on something for several hours a day in a period, even the largest features only take a few days at most.
I also wish to correct a possible dig here that the nLab is somehow insecure in a way that any reader or editor of the nLab should be troubled about. This is not the case. Anyone who believes otherwise is welcome to demonstrate it
Jacques Distler has demonstrated this privately to my satisfaction (and I have substantial experience of my own with web development). Again, I’m not interested in repeating the argument here, but everyone present should be aware that Richard’s assertions are not undisputed.
I know that I personally have made small edits to Wikipedia on occasion, but have often not made small edits to the nLab, simply because the process is much friendlier and quicker on Wikipedia
I’d be interested to hear you and others elaborate on that point. I have trouble imagining how editing the nLab could be friendlier or quicker than it is: you just click “edit”, make your changes, and then “save”. I’ve also done a bit of editing on wikipedia, and in general my experience is that it’s more difficult than editing the nLab, because it uses arcane template conventions for references and nonstandard syntax for markup (versus the nLab’s Markdown).
Jacques Distler has demonstrated this privately to my satisfaction (and I have substantial experience of my own with web development).
If you mean the email discussion of which I was a part, there was certainly an initial gap when the Tikz diagrams were introduced due to an insecurity in LaTeX, not of the nLab code itself, but this gap was closed, as was discussed publically at the time. Jacques did not demonstrate any other insecurity in that exchange. He sketched various scenarios in his usual manner, but most of those had little substance in the case of the nLab; you yourself tried a few cross-site scripting attack vectors, and found them closed. There may well be some vectors that are open, but the chances of these being found and exploited on the nLab in some significant way without it being noticed is exceedingly small, in my opinion. Everything is a question of balance, and it is true that I do not believe in being paranoid about security to the extent of it being a barrier of progress. But making claims without properly backing them up only helps up to unsettle people needlessly.
As I say, I don’t mind at all people testing security and exposing holes. But I react against an attitude of superiority that Jacques displays in almost all online conversation, and which you are reflecting here. Let’s just openly and constructively work towards making the nLab better rather than pointing fingers aggressively.
If you or Jacques believe there is a security hole, demonstrate it, and we will discuss it and try to close it.
Re. 6.
Mathematicians are used to typesetting in TeX without any form of WYSIWYG, so I am not sure this issue has any importance.
This is an interesting point. While mathematicians are used to typesetting in (La)TeX, I think many mathematicians do not enjoy doing so (or perhaps have a love-hate relationship). TeX is very powerful, but for a wiki, you rarely need such power. Being able to typeset mathematics is the core requirement: as far as I can see, everything else is handled by a simple text editor (you don’t want the control over layout, etc. that TeX gives you in a wiki). I agree that mathematicians can probably typeset mathematical formulae faster directly in TeX than in a WYSIWYG editor, but MediaWiki gives you this ability too.
Re. 7.
Mediawiki fits that bill… except that its syntax is IMHO execrable. But possibly we could find a plugin that changes its syntax to markdown?
I agree that this seems plausible, though hopefully most people would not have to interact with the syntax.
Re. 9.
I’d rather not go too much into detail here, but just say for example that if one has to do a lot of work to add functionality and much of the core software is irrelevant, I’d rather stick to something which is streamlined and to the point, in a language of our own choosing, without having to continuously have to modify code to cope with breaking changes in the core, etc.
This isn’t really a statement anyone could disagree with. But if there aren’t many concrete examples, the time spent in an unfamiliar setting could still be far less than time spent in a familiar setting working on large, complex features.
look how long it takes the Javascript to load. No doubt the MediaWiki platform can be made to cope with this page, but it is not a given.
The nLab already performs badly on this page, so this appears not to be a recommendation of the nLab. MediaWiki has plenty of pages with mathematics, so it’s surely well-suited to this style of page, though I believe the most sensible course of action is to prerender mathematics to avoid having to load MathJax or KaTeX at all.
This is wildly over-optimistic in my opinion if we wish for the nLab to be anything like it is today; as above, I believe one would need a lot of customisation/add-on work.
I would be interested in seeing examples.
However, if somebody wishes to try it, of course they can do so. Are you offering to try this, varkor? If so, there is space on the nLab server for you to try it out should you wish (in a way which does not interact with the current nLab).
It is certainly not off the table. However, I only think it would be worth pursuing this with buy-in from other users, hence this discussion thread :)
On a different note, I realised that I should probably clarify that it does not take me a year or two to implement features because they require a huge amount of time; it is because I do not work on them for long periods due to other commitments. On the occasions where I am able focus on something for several hours a day in a period, even the largest features only take a few days at most.
I wasn’t trying to diminish your efficiency :) We all have limited time, unfortunately. However, it amounts to the same thing: whether a feature takes a long time of dedicated work, or a little sporadic work — it still takes time to develop features. But by making use of systems that already have these features, one doesn’t even need to work on them.
Re. 14.
I’d be interested to hear you and others elaborate on that point. I have trouble imagining how editing the nLab could be friendlier or quicker than it is: you just click “edit”, make your changes, and then “save”.
I have passed on this thread to those I was speaking to, in the hope that they will weigh in too. I think perhaps the main difficulty is getting context: as soon as I click edit and see the mass of unformatted markup, I find it difficult to find exactly which part I was intending to edit. Even with practice, reading source code like this is much harder than reading the final rendered document. Then, whilst editing, I have no feedback on whether I’ve made a mistake, or whether a certain LaTeX command works, or I can’t remember the syntax for an internal link, etc. There’s just a lot more mental overhead when editing. I’m sure with practice this gets easier, but it takes effort to overcome that, which I believe drives people away. On the other hand, if you can see exactly what you’re editing, this problem goes away almost entirely. (One could improve the situation without going all the way to WYSIWYG, by adding facilities mirroring those in code editors, for instance, but it’s still a far way away from something like MediaWiki’s editor.)
I’ve also done a bit of editing on wikipedia, and in general my experience is that it’s more difficult than editing the nLab, because it uses arcane template conventions for references and nonstandard syntax for markup (versus the nLab’s Markdown).
To be clear, when I talk about the usability of Wikipedia, I am referring to the WYSIWYG editor. I agree that the syntax for the markup Wikipedia uses is arcane and more complex than the nLab’s (but perhaps primarily because Wikipedia is much more complex and so the language needs to be much more flexible).
I think many mathematicians do not enjoy doing so (or perhaps have a love-hate relationship).
I am quite certain that mathematicians overwhelmingly prefer using TeX’s syntax to any other existing system for typesetting formulas, e.g., Microsoft Word’s equation editor.
I agree that mathematicians can probably typeset mathematical formulae faster directly in TeX than in a WYSIWYG editor, but MediaWiki gives you this ability too.
My comment was a response to your claim that “it is hard to overstate just how much more approachable editing becomes with a WYSIWYG editor.”
I claim that “not at all” is pretty much the correct answer here.
nLab’s target audience of editors is professional mathematicians, who already are familiar with TeX’s syntax, so adding WYSIWYG adds nothing to approachability. If anything, it makes the nLab more approachable to all sorts of cranks and crackpots, who often do not use or know TeX.
Re #16: Just a quick comment on the following.
look how long it takes the Javascript to load. No doubt the MediaWiki platform can be made to cope with this page, but it is not a given.
The nLab already performs badly on this page, so this appears not to be a recommendation of the nLab. MediaWiki has plenty of pages with mathematics, so it’s surely well-suited to this style of page, though I believe the most sensible course of action is to prerender mathematics to avoid having to load MathJax or KaTeX at all.
My point was the opposite: the nLab does OK on this page. On a browser which can render MathML, it loads more or less instantly. It is possible to edit the page (one may get a 502, but the edit will go through; the 502 is due to a third party proxy in front of the nLab for preventing DOS attacks, and will be able to be removed when we move to the cloud; also the rewritten renderer in progress is much faster). The point with MathJax was that anything involving Javascript, e.g. a WYSIWYG editor, will struggle with this page unless it shows/works with only a localised bit. Probably perfectly solvable in MediaWiki as I say, but it is not a given.
We have experimented with pre-rendering MathJax server side, and it did not work well. It really needs client side input to work well. I am quite interested in this, and willing to try things, but again, it is not a given. This is the kind of thing I mean when I refer to a certain naivety, also in Mike’s assertions by the way, in believing switching platform will magically improve things overall.
However, it amounts to the same thing: whether a feature takes a long time of dedicated work, or a little sporadic work — it still takes time to develop features. But by making use of systems that already have these features, one doesn’t even need to work on them.
I disagree. If a feature actually takes a short time itself to implement, it is just a question of finding the opportunity or a new pair of hands, there is no fundamental obstacle. And in the long run, having control over features oneself allows one to tweak them, optimise them, etc, once and for all.
By the way, part of this discussion is a version of the classical political debate between local vs global. The argunents for handling things globally (by which I don’t mean worldwide, just within some entity with a wider remit) are always ones of greater efficiency, greater manpower, etc. The arguments for handling things more locally are always ones of greater control, flexibility, individuality, preservation of culture, etc. Some things are certainly better handled globally. But many things are not. More often than not the global argument wins out, though, because the local arguments are more intangible, and the global argument typically offers tangible short term gains.
Re. 17.
I am quite certain that mathematicians overwhelmingly prefer using TeX’s syntax to any other existing system for typesetting formulas, e.g., Microsoft Word’s equation editor.
Yes, I already acknowledged this: I was not suggesting using a visual editor for equations. MediaWiki supports LaTeX equation input.
My comment was a response to your claim that “it is hard to overstate just how much more approachable editing becomes with a WYSIWYG editor.”
I claim that “not at all” is pretty much the correct answer here.
nLab’s target audience of editors is professional mathematicians, who already are familiar with TeX’s syntax, so adding WYSIWYG adds nothing to approachability.
With all due respect, I completely disagree. This is like saying that it is more efficient to write in assembly than a high-level programming language simply because “we’re used to it”. I’ve been writing TeX for years, and yet I still find writing long-form in something like Microsoft Word far more pleasant. I use TeX because I have to, not because I want to. I think there’s also the danger of confusing the purpose of TeX, which is typesetting, with the purposes of a wiki. You’re not trying to write a paper or a book, with fine-grained control over layout. You’re writing text, equations and occasionally inputting diagrams. TeX makes one of those easy to do. Everything else is far more convenient in a visual editor.
At the same time, you’re essentially undermining the experiences of me and my peers. I am personally telling you I find editing the nLab off-putting, and know others who feel the same way, and by saying “not at all”, the impression I get is that you think we don’t count. I’m sure you don’t mean this, but that’s the way it comes across.
nLab’s target audience of editors is professional mathematicians
This is an elitist attitude and I hope that’s not the view shared by others. In any case, knowing TeX is not a prerequisite for being a professional mathematician and neither should it be.
If anything, it makes the nLab more approachable to all sorts of cranks and crackpots, who often do not use or know TeX.
This is a dangerous and discriminatory mindset: you’re categorising anyone who doesn’t meet your (relatively high) level of experience as not worthy of editing the nLab. This strikes me as an “ivory tower” attitude. “Cranks and crackpots” can be dealt with by the history and moderating systems.
Re. 18.
My point was the opposite: the nLab does OK on this page. On a browser which can render MathML, it loads more or less instantly.
Most browsers (for instance, Chrome, which has the majority share in browser usage) do not support MathML. I timed it in my browser, and after 5 minutes, it had rendered 6% of the mathematics on the page (the percentage was increasing linearly). Firefox performed better, as it supports MathML, but it still took 30 seconds (and I got a warning that the page was slowing down the browser). I haven’t seen a Wikipedia page with as much mathematics as this one, so we can’t compare it, but I wouldn’t say this was OK. (For a short-term solution, using KaTeX instead of MathJax might improve matters; in my experience KaTeX is orders of magnitude faster than MathJax at rendering.)
Probably perfectly solvable in MediaWiki as I say, but it is not a given.
MediaWiki prerenders TeX and displays PNGs by default. This appears to be a solved problem.
We have experimented with pre-rendering MathJax server side, and it did not work well.
Could you elaborate?
This is the kind of thing I mean when I refer to a certain naivety, also in Mike’s assertions by the way, in believing switching platform will magically improve things overall.
I do not think it is fair to call us naïve: I have been trying to be concrete with my examples. I know it’s not a simple click of a button to switch platforms and I know there will be problems with any platform. However, so far the issues you have pointed out seem to be easily addressed by MediaWiki, and you seem reluctant to give specific examples you think will cause difficulty.
I disagree. If a feature actually takes a short time itself to implement, it is just a question of finding the opportunity or a new pair of hands, there is no fundamental obstacle.
You say there have been features on your TODO list for years, which is evidence to the contrary. The fundamental obstacle is finding time or people.
Sorry I’m late to this conversation - there was recently an unexpected death in the family.
Some thoughts that come to mind:
Re. #10, although it’s certainly true that the MediaWiki is a mature and widely-used project, there are significant caveats on how secure it is as a result:
It’s built on PHP. At the start of last year, it came to light that the official PHP Web site hosted a backdoored version of the PEAR package manager - often used to install PHP packages - for six months without anyone noticing. Later in the year a high-severity vulnerability was discovered in PHP which, depending on the PHP codebase in question, could allow remote attackers to execute arbitrary code in the context of that codebase. Not long after that, there was a vulnerability affecting servers running PHP-FPM on nginx. These are the sort of things that has led one highly-experienced ICT person I know, who currently maintains a MediaWiki instance as a volunteer, wanting to stop using MediaWiki as soon as possible (the information is instead going to be provided via a non-wiki-based workflow).
MediaWiki plugins aren’t necessarily as significantly reviewed and tested as MediaWiki itself; and in particular, interactions between different combinations of plugins can create security issues. (See here for a discussion of how features which are benign in themselves can combine in unexpected ways to create problems.) WordPress plugins are a regular source of significant security vulnerabilities - cf. this Reddit post about significant security problems with two plugins (with over 300,000 installs), one of which seems to have intentionally included a backdoor.
Something that I haven’t seen mentioned so far is that the work needed to migrate wiki content from one wiki solution to another might be significant. Data related to the nLab wiki (content, previous revisions, authors, etc.) is stored in a database, and the database schemas (i.e. how the data is stored in tables and table columns, and the expected connections between those) by Instiki and MediaWiki are highly unlikely to be straightforwardly compatible. Extracting all the data from the Instiki-style database, munging that into the database ’layout’ expected by MediaWiki, and then inserting that data correctly into the MediaWiki-style database would probably be a non-trivial task, with many opportunities for things to go wrong. But maybe there’s a data extraction tool available for Instiki? (The aforementioned ICT person has gone looking for such a tool to get data out of their MediaWiki instance, and has been unable to find anything adequate.)
For better or worse, I do agree that at least a basic facility with TeX is nowadays functionally a prerequisite for being a professional mathematician. On the other hand, I also agree that the nLab is not just for professional mathematicians, and an amateur may not be expected to have such facility with it. But on the third hand, I do think even an amateur mathematician can reasonably be expected to be able to use TeX syntax for mathematics, since this is used nearly universally on mathematics web sites now, and that is all that is required to edit the nLab.
I am very much against WYSYWIG editors. The huge amount of code and effort that would be necessary to make such a thing work and keep it working is not, I think, justified by the potential benefit, which I think is small (though perhaps nonzero). In addition, while I don’t know exactly how it works to have wikitext that’s editable both directly and WYSIWYG, in principle there’s the possibility of a negative effect on the (large number of) us who prefer to edit the wikitext directly, in that WYSIWYG-generated markup language can be “messy” and hard to edit manually – e.g. I’ve seen this with WYSIWYG-generated HTML that has lots of unnecessary garbage like <b></b>.
I do see the advantages of other features such as separate edit buttons for separate sections on a long page, so that you don’t have to scroll through a long page searching for the place you wanted to edit, or a preview feature from the editing page. Jacques’ philosophy has always been that you can just use “save” as a preview, and I think in principle that’s totally reasonable, but I can see that there’s probably a psychological benefit at least to an actual “preview” that nobody else can see.
I’d be interested to hear you and others elaborate on that point.
In my opinion, easy accessibility on first contact matters a lot, so I am rather on the side of varkor. One should also be aware of a potential bias: people answering in this thread are at least semi-regulars, therefor passed themselves the threshold of editing the nLab. A glance to popular application like dropbox, skype, etc. confirms this impression also in a professional context. Dropbox is maybe the best example. The same functionality in principle is often provided by the own institution (though some may not even be aware of it) with e.g. better security. But already procedures like unlocking an account makes people moving to Dropbox, not to mention Git.
I think as for the workflow argument there is also a bias going on, though more complicated one. Workflow and software capabilities influence each other in both directions. WikiMedia provides many pages for maintanance. Maybe in light of new features the workflow would change.
I would like to chime in and add a couple of points that have put me off in the past.
There is a considerable delay after pressing the Submit button after editing a page. Sometimes it takes upwards of 30 seconds, even though I’m on the university network. The browser seems to get stuck on a POST request. I don’t know if this is by design or a server issue, but Mediawiki’s editor is much faster in that regard.
When writing TeX on a local computer, there is a fast edit-compile-preview cycle, but we don’t have a “preview” option when editing markup on the nLab. In particular, editing tikz diagrams without a preview feature is off-putting, since it is very easy to make syntax errors (it is somewhat solved by using online tikzcd editors). Editing a public facing webpage with the possibility of making syntax errors is a bit stressful.
I would not like to use a WYSIWYG editor for text either, but a live preview feature like Mediawiki’s editor would be quite desirable, even if it requires running client-side javascript.
With all due respect, I completely disagree. This is like saying that it is more efficient to write in assembly than a high-level programming language simply because “we’re used to it”.
I strongly disagree to comparing TeX to an assembly language. I’d say that TeX is like C, LaTeX is like C++, and Microsoft Word is like Visual Basic (much worse, actually).
I’ve been writing TeX for years, and yet I still find writing long-form in something like Microsoft Word far more pleasant.
TeX’s killer feature for me is perfect 100% stability. Microsoft Word documents quite literally break when you switch to the next version.
https://tex.stackexchange.com/questions/218567/latex-vs-word-improvements-of-latex-over-the-years/
Another killer feature is a macro system far superior to that of Word, which allows me to avoid most of routine work that Word is so (in)famous for.
For a concrete example, take a look at this document https://dmitripavlov.org/notes/topology.pdf. Open it (say) at page 20 and notice how individual technical terms in the middle of paragraphs, such as “simplicial set”, “Yoneda lemma”, “nondegenerate simplices”, as well as technical notation such as “sSet” are hyperlinked to their definitions.
In TeX, this was typeset as ^{simplicial set}, ^{Yoneda lemma}, $@sSet$, etc.
In the nLab syntax, one would type instead: [[simplicial set]], [[Yoneda lemma]], etc.
How can you do the same thing in Microsoft Word without infinite pain?
I use TeX because I have to, not because I want to. I think there’s also the danger of confusing the purpose of TeX, which is typesetting, with the purposes of a wiki. You’re not trying to write a paper or a book, with fine-grained control over layout. You’re writing text, equations and occasionally inputting diagrams. TeX makes one of those easy to do. Everything else is far more convenient in a visual editor.
But what is “everything else”? As you yourself pointed out, there are formulas, which are easier to typeset in TeX.
I’d say that using LaTeX’s \label/\ref and \bibitem/cite is far more convenient than analogous tools in Microsoft Word. I also gave you an example with hyperlinks above which is all but impossible to do in Microsoft Word or any other WYSIWYG system.
Apart from formulas and references, you have sections/subsections and __emphasis__, both of which have rather trivial syntax.
So I am not sure what functionality such a WYSIWYG system would provide in the first place.
At the same time, you’re essentially undermining the experiences of me and my peers. I am personally telling you I find editing the nLab off-putting, and know others who feel the same way, and by saying “not at all”, the impression I get is that you think we don’t count.
It may be difficult for me to relate to this sentiment, since you are posting anonymously here.
nLab’s target audience of editors is professional mathematicians
This is an elitist attitude and I hope that’s not the view shared by others.
I am not sure why it is “elitist”, but even amateur mathematicians know TeX quite well these days. “Professional” means “highly skilled in mathematics” for me, not “earning money from mathematics”.
In any case, knowing TeX is not a prerequisite for being a professional mathematician and neither should it be.
I think I agree with Mike Shulman on this one. The only professional mathematician I know who cannot do TeX is quite literally over 80 years old.
If anything, it makes the nLab more approachable to all sorts of cranks and crackpots, who often do not use or know TeX.
This is a dangerous and discriminatory mindset: you’re categorising anyone who doesn’t meet your (relatively high) level of experience as not worthy of editing the nLab.
I disagree with a “relatively high” part. One quite literally needs to know TeX’s syntax for formulas, LaTeX’s syntax for \label/\ref/\bibitem/\cite and \section/\subsection, and nLab’s syntax [[…]]. I think you tend to seriously overestimate the amount of syntax necessary to edit the nLab.
Which actually brings me to a point: the help box to the right of the nLab’s edit form definitely needs updating: the [[…]] syntax should be included, \label/\ref should be included, some obscure things like abbreviations could be removed.
Daniel, I was looking for specific ways in which the nLab editing experience could be easier. To me it already feels as easy and lightweight as possible.
Re #21: Thanks very much Alexis, for joining the discussion. Very sorry to hear about your family troubles, my condolences.
The points that you make are excellent. I definitely do not think that security will ever likely be a good reason to switch. The best way to obtain a secure system in my opinion is to have something small, lightweight, modern, and up to date. We are not there with the nLab yet (as I touched on in a previous comment, we are stuck with an old version of the Rails environment), but with the rewrite we will be in good shape.
Something that I haven’t seen mentioned so far is that the work needed to migrate wiki content from one wiki solution to another might be significant
Absolutely, I think it will be a massive job to get right, there is no way it will ever be able to be done in a way which does not cause serious jarring of content for a long time afterwards. I had not brought it up because it is a one-off effort, but still it is very good to be aware of.
Re #22:
Jacques’ philosophy has always been that you can just use “save” as a preview
It’s not important, but this philosophy is not due to to Jacques Distler, it goes back to the original Instiki, which was written by a very good software developer, the inventor of Ruby on Rails, David Heinemeier Hansson. I have commented before that I think the original design of Instiki is not bad at all; it does not scale to the nLab’s needs, but this is solvable (it is the kind of thing I have been doing since I got involved on the software side). Many of the aspects of Instiki that people consider to be idiosyncratic, and most of the things I have removed, were introduced by later maintainers.
Re #23 and #24: I definitely can see that a preview functionality would be a great addition, and would have no problem with looking to introduce that as time allows, I have mused on it myself from time to time.
There is a considerable delay after pressing the Submit button after editing a page. Sometimes it takes upwards of 30 seconds, even though I’m on the university network. The browser seems to get stuck on a POST request. I don’t know if this is by design or a server issue, but Mediawiki’s editor is much faster in that regard.
I completely agree. This is one of the things I aim to fix in the rewrite. The main problem is the markdown parser used by Instiki, which is terribly slow. The situation was even worse before; a lot of the old Instiki code on top of the parser was terribly slow too. My initial focus on taking over was on making a good experience for readers of the nLab; editors, being much fewer in number, were less in focus. But I 100% wish to make submission fast, and I believe we will have a much better experience after the rewrite and move to the cloud. The new markdown parser-in-progress is very fast.
The nLab server does not get stuck on POST requests, the edit always goes through; as mentioned in an earlier comment, what happens is that some proxy for prevention of DOS attacks in front of the nLab times out. This proxy will be able to be removed once we move to the cloud.
In short, I am certainly not claiming that the nLab is in outstanding shape currently when it comes to editing. But we are improving bit by bit from what before was a dire situation, to something which is now stable and for readers not at all bad I think; and I think we will get to a situation where for editors it is not at all bad too. In that case, I think we will be in much better long term shape than moving to a third party platform with add ons.
Re #25:
Which actually brings me to a point: the help box to the right of the nLab’s edit form definitely needs updating
Absolutely, I have been meaning to do this for a long time. I will try to give it a go soon. As I say, I have been postponing most things in favour of the more fundamental changes that will enable moving to the cloud, but this is something I can probably try to do beforehand.
Re #20: I don’t wish to get into a long debate about this. I have already stated my fundamental view on this, which is that a streamlined, lightweight system focused on exactly what the nLab needs and where we have complete control and flexibility is by far the best recipe in the long run. This, as I say, is based on years of hands-on experience of working on the nLab and other things, and it is not an opinion which I am going to change through a debate here. It is not really a question of raising specific difficulties which MediaWiki might or might not solve; this is dealing in hypotheticals, whereas the position I am taking is based on experience of how software development proceeds in general.
For what it’s worth, though, I still do not consider that any of the specific things I have mentioned (nForum integration, rendering/editing of large pages) will be ’easily addressed’. Regarding the large page in Firefox, whilst of course not optimal I don’t think 30 seconds is too bad actually. It would take quite some time for a pdf of this page to download as well, it is more or less textbook length.
MediaWiki prerenders TeX and displays PNGs by default. This appears to be a solved problem.
Server side pre-rendering cannot possibly take into account the font, font size, etc, being used in the browser. As far as I see Wikipedia is using MathML if possible, and SVG images as a backup. These images do not look great to my eye, they are somewhat grainy; MathJax does a better job, because it has client side input on the font, font-size etc.
Regarding more details, I tried in the past rendering LaTeX using MathJax server side; the results were OK, like Wikipedia’s, but not as good as MathJax in the browser, for the reasons I have given. On most pages, it is fine to use MathJax in the browser, and on the larger pages we do have MathML available. I don’t feel that MathJax is really made to be used well server side.
I definitely would like to work on improving this on the nLab, for example staggering the loading of MathML/MathJax items rather than doing it all on page load, or other things. The main point is that I do not think MediaWiki solves the problem; it offers one solution that is not necessarily better than the one the nLab has currently.
Before I reply to some specific comments, I want to emphasise that I really value the discussion here — it can be difficult to come across in the right way online when discussing issues that are somewhat contentious, and I really hope I’m not coming across too negatively! I have some specific replies first, and then a more general one.
Re. 21. These are useful points Alexis, thank you.
Re. 22.
I am very much against WYSYWIG editors. The huge amount of code and effort that would be necessary to make such a thing work and keep it working is not, I think, justified by the potential benefit, which I think is small (though perhaps nonzero).
I would certainly not suggest to write one from scratch, but there exist good editors already.
In addition, while I don’t know exactly how it works to have wikitext that’s editable both directly and WYSIWYG
This is definitely a sensible concern: I agree that in this hypothetical scenario, we would want to make sure both forms of editing were convenient. Save Wikipedia’s idiosyncratic syntax, I believe it does this relatively well: it can afford to be much simpler than WYSIWYG HTML editors, for instance.
I do see the advantages of other features such as separate edit buttons for separate sections on a long page, so that you don’t have to scroll through a long page searching for the place you wanted to edit, or a preview feature from the editing page. Jacques’ philosophy has always been that you can just use “save” as a preview, and I think in principle that’s totally reasonable, but I can see that there’s probably a psychological benefit at least to an actual “preview” that nobody else can see.
This would definitely be an advantage in any case, I agree.
Re. 25.
TeX’s killer feature for me is perfect 100% stability. Microsoft Word documents quite literally break when you switch to the next version. […] How can you do the same thing in Microsoft Word without infinite pain?
Microsoft Word was just an example, and I don’t want to go off on a tangent regarding its virtues versus TeX’s, because I don’t think it’s relevant. I agree that TeX is better for some things. However, I could also list many features that makes Microsoft Word easier to use. I think Mike Shulman’s point earlier was particularly helpful: I don’t think we should replace markup entirely with WYSIWYG. However, I do think having both would be a great improvement.
But what is “everything else”? As you yourself pointed out, there are formulas, which are easier to typeset in TeX.
I would say the most helpful thing with a WYSIWYG editor is the separation of content and function. In TeX (and to a lesser extent, markup), everything is mixed up. This can make it hard to read long-form text, because you have to parse the symbols that have no meaning other than as delimiters. Things like syntax highlighting make this significantly better, though they don’t solve the issue.
Which actually brings me to a point: the help box to the right of the nLab’s edit form definitely needs updating: the … syntax should be included, \label/\ref should be included, some obscure things like abbreviations could be removed.
That would help!
Re. 27.
Regarding the large page in Firefox, whilst of course not optimal I don’t think 30 seconds is too bad actually. It would take quite some time for a pdf of this page to download as well, it is more or less textbook length.
Large mathematical papers load within seconds in Chrome for me. E.g. Leinster’s Higher Operads, Higher Categories loaded within 4 seconds.
Server side pre-rendering cannot possibly take into account the font, font size, etc, being used in the browser.
That’s true. There are trade-offs to be considered here.
The main point is that I do not think MediaWiki solves the problem; it offers one solution that is not necessarily better than the one the nLab has currently.
Yes, it may not be any better. However, on the other hand, I don’t think it would be any worse.
I want to reply to vikraman’s message specifically, because I think it is particularly worth highlighting. While my “ideal scenario” would be WYSIWYG editing, which is really the main reason I suggested MediaWiki in the first place, if the pain points vikraman highlighted were addressed, I think this would go 90% of the way for me. That said, it would presumably still take a fair amount of work for Richard, Alexis and any other contributors, though perhaps they could suggest how plausible these changes would be.
If we had something like, say, Visual Studio Code’s live markdown preview: syntax highlighted markdown on one side to separate content from function; a preview on the other so that you could see everything is well-formed, and submitting an edit was almost instantaneous (with proper authentication), I imagine I would be very happy with the ease of editing :) That, together with an updated help box as Dmitri Pavlov should be enough to make editing the nLab less off-putting for users.
I wanted to offer another “suggestion” (in that I am not seriously suggesting it yet, but would like to hear others’ thoughts).
Kerodon, which is another wiki-style project for (categorical) mathematics, has a rather different approach to the nLab. Although it’s currently only maintained by one person, I could see this strategy extending. In particular, Kerodon is generated from LaTeX using gerby. It would be possible to host this sort of project on GitHub or GitLab (akin to the HoTT Book) and have the nLab generate its pages from the LaTeX source.
Obviously, this is far from my original suggestion, but matches up very well with vikraman’s points: everyone could use their favourite code editor, with all the features they care about, and push (or make a pull request) to the repository. This would alleviate the nLab from the complexities of building a sophisticated editor of their own. To allow people to make small changes without working out how to use git, we could use any online editor.
This is a very different model to how the nLab currently works, but it could be far less of a burden for maintenance; it puts the burden of complexity elsewhere (e.g. authentication), and frees up time to work on things like the viewing experience, which is the most important aspect, as Richard points out. I’d be interested to hear what people think about this (perhaps it’s been discussed in the past)?
Daniel, I was looking for specific ways in which the nLab editing experience could be easier. To me it already feels as easy and lightweight as possible.
OK, here it goes
Addition:
Prerendered equations as PNGs is like curing a disease by chopping off the head. Not everyone can read images, aside from the hassle this causes with even a tweak to the style.
Thanks very much, Daniel! At this point in the discussion, I think we have a very broad agreement on what needs most to be done to improve editing of the nLab. Most if not all of these things are planned or in progress. Thus I suggest that we simply proceed with trying to implement all this. Once that is done, let’s see where we are at that point! I feel that this is likely to be a much smoother course, and leave us in a better state long term, than moving to a different platform.
this old syntax (I think the Instiki syntax) is idiosyncratic as mentioned and should be thrown out from all pages
What old syntax?
this is what people—besides LaTeX—already know
I think you’re making the same mistake that varkor claimed about in reverse. Maybe you already know Mediawiki syntax, but that doesn’t mean that “people” do.
in MediaWiki you can type
[[group]]sto produce (a link with the effect of)[[group|groups]]
But why would you want to, when on the nLab you can just type [[groups]] to produce the same thing (since groups is a redirect to group)?
Re #29: Wow! Github+gerby is an exciting idea. Why haven’t we considered that before? Let’s discuss that in another thread.
What old syntax?
The original Instiki syntax for theorem environments, table of contents, etc. I’m not keen on a one-off attempt to change everything, but it could be done programatically on next edit for example. I don’t mind people using the old syntax personally, but do see Daniel’s point and don’t mind a policy to shift to use of the ’new’ LaTeX-like syntax either.
Just getting back to this, I do not wish people to feel that the nLab is being held back by not switching to another platform. In particular, the tone of remarks like Mike’s #11 here are not very encouraging. If people can agree on another platform, we can migrate to it and I will step down; I am supporting the nLab when I can in extremely difficult circumstances only because it needed some help and nobody else seemed able to, and can continue to do so and try to progress the nLab software if necessary, but only if this is in a spirit of co-operation.
I’m posting again here because I was recently reminded of an issue that discourages me from editing nLab pages, and this thread is already a good source of “nLab editing hurdles”. In particular, I just tried to edit a page on the nLab and ended up breaking it because I made some mistake with the syntax. The nLab doesn’t do any error-checking and doesn’t offer any suggestions when things go wrong, which makes it a little stressful to edit as someone unaccustomed to the syntax, because you don’t want to be responsible for breaking a page on a site that many people rely on. A preview of the page before submitting, with some form of diagnostics, would really go a long way in alleviating this.
Thanks for raising! Just a quick comment that it is certainly not true that the the ’nLab doesn’t do any error-checking’. However, it is definitely true that the error checking does not catch everything. Definitely a preview would help, though as we have noted before, the original philosophy of the software (not my own design choice!) was that errors are OK: there is a window after an initial edit (30 minutes or so) where it is normal that one checks for errors and re-edits the page to iron them out. Of course this does not scale especially well, but it is rare that we have any issues with cross-editing at our current size.
I can note here that for a few weeks in the summer I was able to work quite intensively on ’nlab-core’, the new version of the nLab software which will leave behind Instiki, which can be seen at github. It went well, but for some weeks now I have not been able to work on it. My routine will change again in about a month, which should allow me to get back to it. Nevertheless, if people are impatient and wish to try MediaWiki or whatever, that is OK too; as I wrote above, I wouldn’t wish to hold anything back.
What is really annoying is that nLab often produces incorrect XML files, which the browser refuses to display, without any indication of errors, or what place in the source code causes problems.
Maybe as a provisional measure we could change the doctype to HTML 5 instead of the current XHTML 1.1?
Hi Dmitri, in the new ’nlab-core’ I am indeed using doctype HTML 5, but I fear it may break too many things if we try this for the current version of the software. I agree this is annoying! Let’s maybe see how progress goes in a month or so once I’m able to work on the new software again.
1 to 41 of 41