Hey all,
The following is the compiled 'Problems to Solve' list of issues we would like a wiki version of the EG to fix or improvements we think it might offer.
In some respects, we may have somewhat moved on from this already, but since we had set it in motion, I wanted to continue with it/finish it up. This list was already posted to the Editors for review, comment, and suggesting any additional ideas. Now posting it here for the same. My apologies in advance if I've missed or mis-stated something - and if I have, please say so and we can get the item added or corrected.
Ok, here's the list, divided by the different posters who posted/responded on the matter:
OA - Conversion to a Wiki - Problems to Solve - List:
Selden -
Being able to generate reports about page accesses (e.g. # of accesses, sources of accesses)
Avengium -
1. Having more people capable of fixing things and creating things (on the frontend) and not depending so much on a limited amount of people with the knowledge to do things. I think this remains true for backend issues.
2. An ability to create pages and features that can be done by page editors without knowing the programming language in which the website was made.
3. I want to change the "logout" time that happens when you are logged with your password on the EG site and it unlogs you if you are inactive for a long time in OA website. In general this does not happen in a wiki if you click the "keep me logged in" button.
4. The ability to be able to apply blocks of content as excerpts on another page. I call these "templates." These can be done by yourself or another person without programming knowledge, since it is pasting the body of text from one page to another. These templates can have alterable values that make them customizable on different pages.
5. Another pain point could be the classification into Categories, that I think could be made easier. Categories have: /eg-topic/ and articles have /eg-article/ I think this feature was coded into the website but, when on the forums, we talk about merging or changing categories and converting that category into an article, that requires us to make a new page with the article on a page starting with /eg-article/.
On a wiki articles have different "namespaces". These could be equivalent to the spaces /eg-topic/ and /eg-article/ but with differences. The categories in a wiki can carry text and content like the rest of the pages, but they are usually used only to make lists of topics and the rest of the namespaces would be where the pages that are categorized are located. I think this is much more clear and could speed the classification of pages of the web.
6. Making a better file manager / image manager. In my opinion the image manager is pretty old and could be better. For example, when you search for images, there are titles. And you have to click on the image title to know how it looks, every time. There is no visual gallery. In contrast, the wiki system has a file manager that makes thumbnails and has several added file search criteria. Apart from that, wiki-categories can also be added to file and image pages to speed up your search.
7. Image CMS features like "orphan" images or files. The list provided is in plain text. So you have to do another search on the file manager to know how that image looks or where you could include it.
8. Something I want to change too is the thing that we editors are the only people who can access to the links of "minor articles" that appear as footnotes with black title instead of blue title. Readers can think these are no articles and just mere footnotes. As we can see with the articles that Andrew P has proposed in the forum. He thought it was footnotes and suggested footnotes on his forum threads. I think making minor articles clickable again while maintaining their preview text would be beneficial to give readers evidence of how many minor articles we have that need text added or consolidated.
All wikis that are made according to the mediawiki structure have a predictable structure, so it is very easy to find their short page list. Here's a test:
https://strategywiki.org/wiki/Special:ShortPages
This way, ordinary users, even those without writing permissions, could easily find short articles and propose extensions or merges.
9. Having lots of special pages that can be checked by any user or reader of the web. For example:
https://strategywiki.org/wiki/Special:SpecialPages
This page works as an index and changes dynamically if more features and extensions recognized by its mediawiki core are added.
10. Having the ability to create links to pages like <{link|visible text}> like mediawiki. Having redlinks too. Current EG allows to link pages but one has to know the alphanumeric code and I think it could be easier to link to a word. That could make the work of "connecting pages" on the website easier.
11. The possibility to use DPL (Dynamic Page List):
https://community.fandom.com/wiki/Help:DynamicPageList
As a tool to create more complex subsets and lists of items that the ones that can be done with Mediawiki Categories.
This way, anyone who has read the instructions on how to use the DPL pseudocode could create a page with a list of articles with a specific criteria. Without having to know how to make scripts.
12. Bonus points for other extensions or features coded for a wiki framework like page statistics, What links here, Related changes, Printable version, Permanent link, Page information, Page logs, number of views that receives the pages:
https://yourcreatures.miraheze.org/wiki/...:Analytics
or any other that are already coded and we only need to implement them if we need them.
1of3 -
As a reader, I'd like to read the EG comfortably on my phone. Whitespace left and right waste space, subcategories are too small.
As a reader, I'd like reader mode to work reliably in my browser. Does not work in Firefox 128.0 Android and Desktop.
As a reader I want the timeline up to date. And well filled.
As a contributor, I want to produce articles in a format that can be used by the platform to minimize further editing.
As a contributor, when reviewing articles, I'd like to make suggestions inline.
As a contributor, I'd like to get notified when an article I worked on gets changed. I'd like to disable notification for certain articles.
Drashner1 -
Control-1 - Right now changes to the website/EG beyond a certain point have to go through a single person (Trond) and somewhat through me (because I've historically played something of a project manager/volunteer in connection to them). The downside of that has been that it creates a bottleneck in terms of time - both Trond and I are working as volunteers, have lives outside of OA, and for various RL reasons (which I'm not going to get into here) have not had the time or bandwidth to move things along as fast as anyone (ourselves included) might like. My sense is that a wiki format would be (or is believed to be by its proponents) a way of fixing this problem as it would push a lot more control of the EG (format, reporting, appearance) down to the level of the Editors and/or a subset of the staff/membership who are familiar with wikis and how to operate them and so hopefully make changes and such happen much faster along with opening up new capabilities we don't currently(?) have. I'm not clear if there are ways to make the CMS based EG more accessible to change by people other than Trond who don't have a very solid programming background.
Control-2 - From a contribution and editing perspective, our current approach of doing everything in the forums and then porting the end result into the CMS is both time consuming and struggling to keep up with the current high influx of new articles/article updates we have been seeing for some months now. My sense is that a wiki is seen as a way to possibly streamline this process - which it very well might - although this may be something where changing the permission structure of the CMS might also work (or not, I don't know for sure). A possible issue here is that this seems likely to pull the current EG article dev process out of the forums, although - depending on the details - I can imagine some ways to possibly make that work and perhaps the pros of the process would outweigh the cons.
Responsive Design for the EG so it automatically adjusts when viewed on a tablet or phone.
The following two items are me paraphrasing Trond (accurately, I hope) -
Having the code supporting the EG be more recent so doing updates/changes in how the EG works doesn’t risk breaking older code originally created when the state of the art was less advanced or otherwise done differently from modern coding and code structure.
Having updates to the coding underlying the EG be handled by a large scale/likely to be around in the long term source such as Wikimedia so we just have to make sure we stay current on updates to keep the coding current.
Steve Bowers -
Some way of connecting to anchor points within an article
ProxCenBound -
1. Linking. I want to just use simple symbols to create an inline link, not highlight it and then scroll through the whole list of articles for each once. Something like this: [[Solsys]]
2. Handling article drafts in the site itself, with change diffs automatically generated with each change instead of needing to copy-paste and bold changes manually. The latter is very time-consuming and annoying, and probably contributes to why reviewing is such a slow process. We should speed up revising and reviewing as we are already commonly generating large backlogs and the project is likely only going to grow from here.
3. Access to every past version of a page, for easy reversion of issues.
4. Being able to distribute permissions more widely without increase in risk, enabling more to share in the work of fixing typos and uploading articles. Point #3 reduces the barriers to entry, as anyone who takes excessive liberties can easily have bad changes reverted and permissions revoked if needed (ability to view a user's contributions/edits would be helpful with monitoring this as well). Perhaps all forum members could have editing access to the Draft: namespace, enabling them to work on their drafts, while a smaller group of reasonably trusted Editors could edit the main/article namespace. Admins can revoke (or restore) Editor permissions as needed.
5. Converting pages to redirects - the ability to convert articles we no longer want to be separate into redirects, rather than needing to manually delete them and hunt down and fix links to them.
Stellar Regulator (from a DM conversation on Discord) -
The visual design of the EG/OA website is outdated and looks like it dates from the 2000s.
