The Orion's Arm Universe Project Forums





EG Redesign - Ideas and Suggestions?
#21
(06-28-2024, 08:13 AM)Andrew P. Wrote: Would it be fiendishly difficult to port the entire EG to a more traditional wiki-style format? Or at least something with better/easier search functionality? Maybe something with fun multimedia functionalities, pop-up windows, etc.?

I agree with previous statements to the effect that the current aesthetic of the EG is great as-is, but I feel like we could make the under-the-hood stuff a bit more streamlined/efficient/etc.

I suggested the wiki style many times too. But admins here are not fond of the wiki format.

As ProxCenBound says in post #19 of this thread, the wiki format has many advantages. We can have lots of special pages with features and lists already coded. We can create "user groups" and put rights and permissions based on user groups and we can limit who can edit or not and who can do comments, likes, and lots of things.

I know a lot about wikis because I manage more than one wiki and all the facilities that a wiki provides are very noticeable when it comes to managing a large volume of pages.

For people who want more customization, there are lots of skins: https://www.mediawiki.org/wiki/Category:All_skins

And local admins can keep customizing the skins with CSS pages.
For example, this one is using Cosmos Skin: https://mystfalllore.miraheze.org/wiki/Main_Page

And these wikis are using Timeless skin:
https://softcell.miraheze.org/wiki/Soft_Cell (dark and neon colors as the basic colors for the wiki)
Lots of features on every wiki: https://softcell.miraheze.org/wiki/Special:SpecialPages

https://lostech.miraheze.org/wiki/Main_Page (Timeless skin but with green background and white letters)
-----Signature-----------------------------------------------------
Quote: "Nature considers all variables".
Reply
#22
(06-28-2024, 08:13 AM)Andrew P. Wrote: Would it be fiendishly difficult to port the entire EG to a more traditional wiki-style format? Or at least something with better/easier search functionality? Maybe something with fun multimedia functionalities, pop-up windows, etc.?

I agree with previous statements to the effect that the current aesthetic of the EG is great as-is, but I feel like we could make the under-the-hood stuff a bit more streamlined/efficient/etc.

So - as one of the admins who has been very resistant to the idea of converting to a wiki - and to throw my 2c into the mix on this:

Taking the easiest bit first - IIRC someone on the discord or here ran a script or the like to do a page count and it came back that we have something around 4500 pages in the EG.

The two biggest issues/concerns I have with the idea of converting the EG to a wiki are:

a) People going in and sabotaging things, possibly with the damage not being noticed for a long time. This was a major concern back when we were first looking to move to site design that allowed multiple people to add/edit/update things w/o the need to know HTML coding. If more recent wiki packages allow security features that prevent this issue, then the issue goes away.

b) The last time we ported the EG to a new platform (the current website/CMS) it took the better part of 3 years, primarily because only a very few people actually worked on the transition compared to the number of people who actually could have or said that they would. This with significantly fewer articles than we have now. To be blunt, this left a VERY bad taste in my mouth. Sad

If some kind of automation can significantly accelerate a changeover to a wiki based EG and/or people will actually commit to doing their part and then do what they've committed to doing and we make some logistical adjustments such as only adding new articles to the new EG-wiki after some cut off date, then this would hopefully become much easier and go much faster and my issues with making such a change would be correspondingly reduced.

Finally - as far as an updated look for the EG - When Trond and I worked on the redesign of the main page and non-EG pages we discussed this and had pretty much decided to go with a slight variation on the non-EG page design (or maybe even use the exact same design), both the keep things simple and to make it more likely that the EG design stayed 'evergreen' since the 'future data interface' look that we went for with the current EG has had issues with being considered dated and required a long long time and lots and lots of debate (think months and months) to come up with. Would prefer to avoid that.

Ok, I think that covers my thoughts on this for now.

Todd
Introverts of the World - Unite! Separately....In our own homes.
Reply
#23
(06-29-2024, 01:07 AM)Drashner1 Wrote: So - as one of the admins who has been very resistant to the idea of converting to a wiki - and to throw my 2c into the mix on this:

Taking the easiest bit first - IIRC someone on the discord or here ran a script or the like to do a page count and it came back that we have something around 4500 pages in the EG.

I wonder how hard it would be for it to measure article length in word count by that same means.

(06-29-2024, 01:07 AM)Drashner1 Wrote: The two biggest issues/concerns I have with the idea of converting the EG to a wiki are:

a) People going in and sabotaging things, possibly with the damage not being noticed for a long time. This was a major concern back when we were first looking to move to site design that allowed multiple people to add/edit/update things w/o the need to know HTML coding. If more recent wiki packages allow security features that prevent this issue, then the issue goes away.

This is 100% do-able and in fact the current setup is a far larger security risk. Wikis do not need to allow everyone to edit; for example the Galactic Library, run by the ToughSF Discord, does not: https://www.galacticlibrary.net/wiki/Gal...ntributing

In a wiki, any damage or bad edits can be trivially reversed by going into the page history and clicking "undo" on the offending edit. "Deleted" articles still exist behind the scenes, they just aren't visible to non-admins, and could be restored if needed. The current CMS does not appear to track history, and appears to have no way of reversing damage. What if someone with editor permissions became disgruntled, perhaps due to some interpersonal drama, and tried to blank or purge a bunch of articles? It seems like a lot of damage could be done.

A permissions level above mine apparently exists on the CMS, so maybe repair features exist there, but I doubt damage is as easily reversible as on a wiki.

(06-29-2024, 01:07 AM)Drashner1 Wrote: b) The last time we ported the EG to a new platform (the current website/CMS) it took the better part of 3 years, primarily because only a very few people actually worked on the transition compared to the number of people who actually could have or said that they would. This with significantly fewer articles than we have now. To be blunt, this left a VERY bad taste in my mouth. Sad

If some kind of automation can significantly accelerate a changeover to a wiki based EG and/or people will actually commit to doing their part and then do what they've committed to doing and we make some logistical adjustments such as only adding new articles to the new EG-wiki after some cut off date, then this would hopefully become much easier and go much faster and my issues with making such a change would be correspondingly reduced.

I think automation is worth looking into, given how nowadays people even write computer programs with AI assistance. It may not be hard at all to automate. Personally, I would definitely be willing to help a lot with the transfer project, for what that's worth, though trying to automate it is beyond my personal skill set.

I assume that "only adding new articles to the new EG-wiki after some cut off date" means that during the phase-out of the old CMS, new content would be added only to the new wiki-EG. I agree.

(06-29-2024, 01:07 AM)Drashner1 Wrote: Finally - as far as an updated look for the EG - When Trond and I worked on the redesign of the main page and non-EG pages we discussed this and had pretty much decided to go with a slight variation on the non-EG page design (or maybe even use the exact same design), both the keep things simple and to make it more likely that the EG design stayed 'evergreen' since the 'future data interface' look that we went for with the current EG has had issues with being considered dated and required a long long time and lots and lots of debate (think months and months) to come up with. Would prefer to avoid that.

Ok, I think that covers my thoughts on this for now.

Todd

To be clear I don't really have strong feelings on the style, as long as it is isn't garishly white like Wikipedia. Darker or gray backgrounds are easier on the eyes.

On a somewhat related note, no matter what we end up doing about a wiki, I think we should eliminate the underlining from links if possible. Very few websites do that nowadays (and wikis do not), making it appear like a dated style; links are just indicated by color, with underlining appearing when hovering the cursor over it only.
Reply
#24
(06-29-2024, 05:42 AM)ProxCenBound Wrote:
(06-29-2024, 01:07 AM)Drashner1 Wrote: So - as one of the admins who has been very resistant to the idea of converting to a wiki - and to throw my 2c into the mix on this:

Taking the easiest bit first - IIRC someone on the discord or here ran a script or the like to do a page count and it came back that we have something around 4500 pages in the EG.

I wonder how hard it would be for it to measure article length in word count by that same means.

While I was writing the above comment I asked on Discord, and it was Tasp who did that. They said "Probably pretty easy to get at least ballpark numbers for each article. I'll play with it when I get back to my personal machine". So we might be able to find out soon.
Reply
#25
Another possibility that might reduce the overall number of articles to move is to reimagine how information is organized in the EG.

As a major example - the History Topic contains some 33 sub-Topics - out of around a total of 300 - so something like 10% of our Topics are devoted to just that one aspect of the setting. Replacing all that with a single very large page, perhaps with 'table of contents' links to jump down to specific area, search functions, and possibly other things would hopefully be a better end-user experience (of course all the actual entries would still have to go in....).

Something I would love love love - but don't know that a wiki can do it - is to make a timeline that we can take chunks of and insert into other pages - creating 'sub-timelines' in other articles - that are still linked back to the master timeline. So a change to the master is automatically reflected in all sub-timelines. I'm told this is possible and not all that hard, but it would need Trond to program it up. If a wiki could just do something like that baked in, I would be very impressed.

Todd
Introverts of the World - Unite! Separately....In our own homes.
Reply
#26
(06-29-2024, 05:59 AM)Drashner1 Wrote: Something I would love love love - but don't know that a wiki can do it - is to make a timeline that we can take chunks of and insert into other pages - creating 'sub-timelines' in other articles - that are still linked back to the master timeline. So a change to the master is automatically reflected in all sub-timelines. I'm told this is possible and not all that hard, but it would need Trond to program it up. If a wiki could just do something like that baked in, I would be very impressed.

Todd

Sounds like the Template capability: https://en.wikipedia.org/wiki/Help:A_qui..._templates

I'm not sure how that would work with only selecting scattered timeline entries of a particular topic, but contiguous segments could be templates all hosted in order on the main timeline page, like:

{{Information Age timeline}}
{{Interplanetary Age timeline}}
{{Solsys Golden Age timeline}}
etc.

Oh, and as for table of contents, MediaWiki wikis seem to generate them automatically, another advantage over the current system where they are tedious to create.
Reply
#27
(06-29-2024, 01:07 AM)Drashner1 Wrote: If some kind of automation can significantly accelerate a changeover to a wiki based EG and/or people will actually commit to doing their part and then do what they've committed to doing and we make some logistical adjustments such as only adding new articles to the new EG-wiki after some cut off date, then this would hopefully become much easier and go much faster and my issues with making such a change would be correspondingly reduced.

I have no relevant programming or other experience that could help with automating the process, but for what it's worth, I have a virtually infinite capacity for carrying out tedious and repetitive tasks (especially if it's in the service of something I am passionate about), so if you find yourself in need of someone to help with the (I assume, if it isn't automated) extremely laborious process of copying articles to the new format, I would like to submit my name for consideration.
We are not simply in the universe, we are part of it. We are born from it. One might even say we have been empowered by the universe to figure itself out... and we have only just begun.
-Neill DeGrasse Tyson
Reply
#28
If the admins and editors decide to duplicate the EG articles in a wiki format, i volunteer myself to help too.

1. About automated or semi-automated process, I don't know about. Something exist but I don't know how to operate it. Some people in wikipedia uses bots coded in programming languages like Python or Lua. For example: https://www.mediawiki.org/wiki/Manual:Pywikibot

----------
2. One advantage in doing a free wiki in a wikifarm (like Miraheze, for example) is that they have some pre-installed features and pages and you don't need a resident tech expert to put online your own wiki if you choose to have one hosted by the wikifarm instead.

After that, if you want a different URL, you can request a name change to another address. If you do not want the name of the wikifarm to appear in the URL.
For example, the LGBTQIA+ Wiki is hosted on Miraheze but the name of the wikifarm does not appear in the URL:
https://lgbtqia.wiki/wiki/LGBTQIA%2B_Wiki

The page wikistats that is used to check some statistics on mediawiki:
https://wikistats.wmcloud.org/

Can also be used to check wikis on Miraheze in:
https://wikistats.wmcloud.org/display.php?t=mh

You can see the LGBT wiki is on position 36:
36 Name: lgbta Main articles: 7715 Total pages: 48603

-----
3. Another advantage is that, once you have a wiki, the content of that wiki can be ported easily with a feature called a "datadump". That is formating and packaging the text into a single file and downloading that file into your machine.
For example: https://yourcreatures.miraheze.org/  is a wiki
and the datadumps of that wiki appear on: https://yourcreatures.miraheze.org/wiki/...l:DataDump

If there is some backup online, it will appear on that page, and you can see the contents or save a file.
This file is also formatted in a way that if you want to put it on another wikifarm or in a different server can be used to recreate that wiki.
----

4. About Timelines. There are templates, but templates are written in wikitext and can be limited in features.
Wikipedia has lots of templates in general: https://en.wikipedia.org/wiki/Category:G..._templates
The thing about templates is that you can nest one template inside another and make the second one easier to use.

And you can try extensions written in LUA, HTML or other languages that have more features.
https://www.mediawiki.org/wiki/Extension:EasyTimeline
https://www.mediawiki.org/wiki/Extension:Graph

But if the timeline we have on orionsarm works, i think there is no need to change it and is better to keep everything in the orionsarm website meanwhile we create pages on the wiki.
-----Signature-----------------------------------------------------
Quote: "Nature considers all variables".
Reply
#29
(06-29-2024, 06:36 AM)ProxCenBound Wrote: Sounds like the Template capability: https://en.wikipedia.org/wiki/Help:A_qui..._templates

I'm not sure how that would work with only selecting scattered timeline entries of a particular topic, but contiguous segments could be templates all hosted in order on the main timeline page, like:

{{Information Age timeline}}
{{Interplanetary Age timeline}}
{{Solsys Golden Age timeline}}
etc.

Re scattered timeline entries - if we had the information in something like an Excel spreadsheet (which is just a database of course), we could in theory have a 'Subject' column with options similar/the same as the six main Topics at the top of the EG. You could class new inventions as 'Technology' for example and then run a filter for all Technology classed items in the database. Or Culture or Sophonts or whatever.

Building sub-timelines from disparate entries might be trickier but might also be outweighed by other positive functionality that a 'one timeline to rule them all' could give us.

Todd
Introverts of the World - Unite! Separately....In our own homes.
Reply
#30
I would like to ask, does the OA CMS have any sort of backup system? Or is our only way of restoring lost/damaged articles to use web archiving services?
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)
https://www.orionsarm.com/forum/showthread.php?pid=79531
www.orionsarm.com
CC-MAIN-2024-33
74121
application/http; msgtype=response
sha1:5AUWZHJ4DH54VBE4YEFED44RB7TP57QE
<urn:uuid:5c570635-6b2d-46da-8261-5245434fdf02>
2024-08-07T15:02:15Z
205.134.255.228
application/xhtml+xml
sha1:ZZY546BX4KKAZD7X3UJUW2AEVAUGCAWV
<urn:uuid:2ca2ad1f-c96e-40ca-9516-d78dcb6e0cac>
https://www.orionsarm.com/forum/showthread.php?pid=79531
response
<urn:uuid:92cc9291-6d72-4fec-b024-4f67324dc5d3>
isPartOf: CC-MAIN-2024-33
publisher: Common Crawl
description: Wide crawl of the web for August 2024
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-188
software: Apache Nutch 1.20 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.5-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/