💾 Archived View for jb55.com › ward.asia.wiki.org › safe-and-familiar-welcome captured on 2022-01-08 at 13:51:07. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-04)
-=-=-=-=-=-=-
We could provide an "index.html" style template in the server that would present a more familiar welcome page before easing visitors into the new world of federated wiki.
We could have several options for look and feel including project-look with definition and three sub-activities, or, the blog-look with a few recent articles and sidebar with archive and blogroll.
Folks who bother to get a domain want that domain to fit in and feel modern. Various templates could be updated frequently to match evolving contemporary style.
Mike Caulfield has pioneered this approach without actually integrating his work with the existing server.
An open question is how one might gracefully transition from one mode to the other. Opportunities to delight and/or confuse abound.
Another open question is how to get authors started making a professional looking welcome from existing wiki pages when this is now one more step indirect.
Could revisions here address the infinitely confusing usability trap of unrecoverably forking unwanted content over the welcome page?
The Assets plugin now provides a place to store alternative implementations of a site landing page. We reserve the subdirectory "home" for this purpose.
See About Reserved Asset Paths
With this pull request we enable site owners acting individually to customise the welcome page for their sites using normal html and css without privileged access to the server or cooperation with any other user. github
I personally struggled to make an attractive and responsive replacement for wecome for the start.fed.wiki page and was not at all happy with the result.
See Making the Welcome Page
See Catalog of Custom Home Pages
I noticed the Wikimedia Research group created something like this recently and though I might copy it.
It turns out many services they inherit from wiki aren't available in the static site generator they used. These include language translation as well as simply being able to correct punctuation.
In email to the research-list Dario explains, "Due to production requirements, all code needs to be on Gerrit, but asking people who want to suggest typo fixed to go through the developer access instructions is a usability nightmare. Jonathan's suggestion is a temporary solution, I'd like to work with Baha to figure out if there's a possible workflow that allows us to receive PRs and issues on GitHub, have them synced with Gerrit, before they are reviewed and, if +2'ed, merged there. This may take a while so we appreciate your patience."