Difference between revisions of "Site Conversion Progress (2019-03-01)"
Greg.Fuller (talk | contribs) (→Blueprints) |
Greg.Fuller (talk | contribs) (→Content Conversions) |
||
| Line 64: | Line 64: | ||
=== Content Conversions === | === Content Conversions === | ||
| − | The reason I have not been | + | The reason I have not been doing content conversions is because if you do the conversions before the ground work is done, you will end up redoing a lot more content pages. Having a small number of representative pages makes circular, iterative refinement easier. |
Content conversions will resume soon. | Content conversions will resume soon. | ||
Revision as of 00:33, 1 March 2019
Context
The conversion of the WordPress site to a Wiki platform is coming along at a rapid pace. I've been working in a newly staged development environment so that my antics would not be disruptive. A good deal of progress has been made and I wanted to report that here, as well as what's around the bend.
Site Improvements
The following site improvements have been completed and moved from development to the provisional production environment, hereafter called the production environment or just simply production.
Automatic Generation of Plaintext for Fact Sheets
I have rewritten the automatic generation of plain text for Fact Sheets, and made it much less fragile. Conventions must still be followed for the text to be generated properly, but the algorithm is no longer dependent on specific H3 heading names. I want to eventually implement automatic plain text generation for page types other than fact sheets.
The Social Sharing Box
Check out the new share box at the top of any non-listing page in the Main namespace—particularly pages that have plain text. I still have a little skinning to do, but I'm it's come a long way, is more user-friendly, and is much more reliable. It needs to be tested across a variety of hardware and software platforms, but so far it works with everything I've tested it on.
What Facebook and Twitter pull from the site for a description can sometimes be ugly, but that will be corrected with the {{jfa-meta}} template discussed below.
The social sharing box is what has taken the longest, partly because of all the workarounds I had to do to get the copy to clipboard capability to work with iOS (because of that operating system's tighter security). I also had to do workarounds for Grammarly, which interjects itself into HTML text areas in the Document Object Model. I did not want to disable Grammarly for the entire site, or require the user to do the same. I like using Grammarly when editing with the source editor; I have not tried Grammarly with the visual editor.
A New Top Template
A new template will take the place of the three templates you may have seen at the top of pages in the Main namespace. These have been replaced with {{jfa-top}}.
If you look at the source for {{jfa-top}}, you will see that it just contains {{jfa-start}}, {{jfa-share}}, and {{jfa-toc}}. You can still use these templates separately in unusual circumstances.
Automatic Indents
Heading levels H3 and above now automatically indent, as well as the text that is under them. I believe this substantially improves readability. Currently, the indent for each level is set at 20 pixels, but it can be adjusted.
Far Fewer Templates
Because of the automatic indents, the {{jfa-top}} template, and smarter parsing, template usage has been tamed. You will find far fewer templates in the pages now. I have edited every (I think) page in the Main namespace to clean them up.
Expand/Collapse Buttons are to the Left Now
I thought it was annoying to have the [Collapse] button jump to the far right when the user hit [Expand], so I floated the button left and added some padding to separate it from the subsequent text.
Styling Improvements
I've made dozens of small tweaks to the styling of the site, and will continue to do so.
Development Workflow
This is not of particular interest to anyone but me at the moment, but after familiarizing myself with the MediaWiki's back end, I was able to develop a sane workflow. This by using a cloned version of a skin, and a special extension that will hold all non-skin software modifications, yet segregate them by feature or fix.
On the Horizon
New Meta Template
I have created a new Meta Template which will feed the SEO meta tags, as well as the title, description, and image that is used when a user posts to Facebook or Twitter. The template is smart enough that you only have to enter title and description once, and it will use those as appropriate for SEO, Facebook, and Twitter. Also, a separate image for each page will not be necessary.
This will really improve sharing, as what the user will see in the Facebook and Twitter link box should always make sense because it does not depend on Facebook and Twitter's imperfect parsing to pull these values. Also, we can control it.
The Meta Template is not yet in production. I will move it there soon and edit all the pertinent pages.
Blueprints
I will be creating blueprints (the word template is taken in wiki land) for our standard page types. I have already edited all the Main namespace pages to reflect that, except for adding the new Meta template near the bottom. The layouts are getting closer to being in their "final" form, pending the new Meta template, discussed above.
Content Conversions
The reason I have not been doing content conversions is because if you do the conversions before the ground work is done, you will end up redoing a lot more content pages. Having a small number of representative pages makes circular, iterative refinement easier.
Content conversions will resume soon.
Style Guide and Other Documentation
Isaac has been working on the style guide and it's a work of art. It will make our site more professional and consistent. There's lot's of documentation that needs to be written on standards for external (and internal) authors and editors. As with content conversion, if you do too much of that before the groundwork is done and the conventions are in place, you will be subject to a lot of rework.
Moderation and Approval Control
I continue to test extensions for preventing trolling and vandalism, and for requiring and/or allowing approval. I believe we will eventually be able to open up the Wiki to anonymous, minor edits. After the content gets converted, my current thinking is to produce "stub" pages with a title and some blueprint text, then invite certain people to participate in writing those specific pages.
Page Listings
The title listings on the home page and each of the section pages are now being entered manually, but in the future, they will be done automatically by an extension.
More Later
More later, but I feel the project is on the right track. There's a lot to figure out when you move to a different platform, and it needs to be as good as it can be out of the gate.
