Development Log

From Salish Sea Wiki
(Redirected from Development)

Technical Pages[edit]

Click this book to return to the Development Log Page

See Introduction Pages

See also Development Roadmap and Development Backlog

This page documents platform improvements. Most changes are continuous and with the platform live.

2024 Q4[edit]

  • Style Guide Enforcement - as a tool for flagging pages that need work we have a set of tags memorialized at the bottom of the Style Guide page. By throwing one of these on a page, it creates a warning note, and puts the page in a category. Later an administrator or an editor can see all the pages and go make them better. This is the beginning of strategies for increasing conformity.
  • Renovation of River Delta Content - There were a lot of surplus pages surrounding the River Delta category from the early days of development. I have reworked River Delta and established a set of Architecture and Content pages, and started conformity with the Style Guide.
  • Category Cleanup Complete - All categories now use standard capitalization, and scripts were established to update category counts. Replace text was used to standardize category use. All categories are now in a single hiearchy.
  • Page Content Templates - Existing templates that create summary information were gathered onto Content Templates and to some degree standardized and explored. A final sets of page content templates will be developed over time, and ultimately associated with Page Type templates and sidebars to provide a continuously updated system of crosslinking. This may be better accomplished once all data are avilabel in cargo, and the potential of Dynamic Page Lists should be compared to Cargo Queries will need to be made.
  • Page Formatting Templates - templates used to control formatting (responsive multi-columns etc.) are gathered as Formatting Templates.
  • Technical Section Cleanup - To make introductory pages cleaner, a new section was developed around Category:Technical that includes all pages associated with the internal operations of the wiki, which is distinct from Category:Introduction which is oriented towards new users and editors.
  • partial diagram of core pages to be developed as introduction?
    Introductory Page Cleanup - All redundancy in introduction pages was removed and consolidated, with establishment of The Big Picture as the starting point for introductory information after the home page.
  • Establishment of Product Page Framework And Picture Template - Originally all products on the wiki were "Documents", however many other types of Effort outputs have accumulated on the site in addition to pictures used to supplement page text. Document pages occured both in the main namespace as well as the file namespace, creating some complexities over time. The WikiWorks SOW#1 included complete resolution of this issue, with all Products moved to the main namespace, and four sub-types of products identified, including Document, Websites, Datasets, and Graphics. Quality Assurance is not provided by form-based editing and enforced naming conventions. All files that are not worthy of becoming products are identified as Pictures of various kinds, and are left in the File namespace. All existing pages were sorted into a Product sub-type or picture.
  • Deployment and Testing of Product Page Forms, Templates, and Structured Data - Form:Product is now available to create new Product pages, with a link to the form on all Product Page sidebars. This page form results in Product pages that have Cargo attributes that are equivalent to standard categories. The form also provides a user interface to increase the consistency and quality of page structure. Default page content can be offered (DefaultProductText) consistent with the improved Style Guide. This prototype will be expanded to all five page types shortly. Ultimately there are now three elements of this system:
    1. Template:Product - The template is run every time you open a page with the template Product, it reads any data on the page, constructs the page with instructions based on those data, and creates a set of categories based on those data.
    2. Form:Product - The form lets you edit a Product Page that has Cargo Data. The form reads the page, including its structured data, and lets you edit page content using a form that controls the input for the data. The Form provides QAQC for the page data.
    3. The Cargo Table - The declaration at the end of the Template adds data to the cargo table named "Product". Thus the page is the "source of truth" while the table contains whats on each page. You can then query the table to generate query results that consider all product pages.
  • Scraping and Attributing Product Pages - finally all product pages were queried, read, converted to the new data structure, and in addition all product pages located in the File namespace were moved to the main namespace, with a direct link to media.
  • Cargo Data Test using Products - With all pages now imported into the Products template in the main namespace, we now have structured data to play with Cargo Queries which are more powerful. As we build out all page attributes, we will be able to associate pages and conduct relational queries.
  • Initiation of Architecture Pages and Content Pages - Initial efforts are underway to identify two new sub-categories of all Pages Types: Category:Content Pages and Category:Architecture Pages. This replaces a early concept of "Master Topic Pages" where high-level topics (e.g. Biology or Geophysics) would have their own pages that organize more detailed topic pages within a category, or at the intersection of a couple categories. This is a continuation of the conversation around information architecture and will evolve.
  • Nation State Subdivisions - A single category hierarchy now contains all subidivisions of nation state, to describe a specific scope of interest of various Workgroups. A distinct set of categories are used to describe levels of governments starting with Category:Jurisdiction. This creates two complementary category systems: one that describes interest in a particular jurisdiction in the Nation State system, and the other descriing the type of institution (Federal, State, Local, Tribal).
  • Standardized Regions - In preparation for page edit forms, we also developed a working framework for Regions that encompass both US and Canadian sides of the Bioregion.

2024 Q3[edit]

  • User Experience and Landing Page Review - we completed an evaluation of UX and landing pages and made some adjustments with notes available here.
  • Icon Improvement - add transparent corners to Iconography so they look good on colored backgrounds.
  • Page Type Revision - We are reviewing and adjusting page type, to encompass the heretofor central Document page type with an expanded and coherent Product page type. This involved a reworking of the category schema below. We are rebuilding a more coherent Places system that is less centered on the Landform system, and deploys a bioregional scale nested standard system of places, using a five-scale framework, described in Places
  • Category Review and Categorization - We reviewed the entire category framework, ensure all in-use categories are part of a coherent hierarchical category framework that can be expanded over time, and use this framework as the basis for a transition to structured page data using Cargo. A number of decisions around hierarchical structuring of categories came into play.
    • Removal of any multitopic categories in favor of discrete categories that can be used in queries (replacing "delta rearing by salmon" with "delta", "salmon", and "life history".
    • The complete revision of categories into hierarchical framework can be viewed at Category Update and Page Editing Forms.
    • This includes development of a Template:Category for styling categories. redirects were removed from all categories so that categories can now be browsed freely.
    • A top level Category:Categories is now used for all categories used to organize pages, while a top-top level Category:All Categories is used to capture all categories in use on the platform including for organizing templates, iconography, introductory pages, etc.
    • Clear separation between a political place structure (Category:Jurisdiction) and a ecolgoical place hierarchy Category:Place that follow separate, and not intertwined hierarchies, but that can each be used to categorize Place pages and thereby allows for sorting of places by a physiographic or a political framework.
    • Develop Category:Purpose as a Workgroup modifier to capture descriptors of efforts, including development of a Category:Social Change used to capture a range of project types that all aim to modify socioeconomic systems.
    • Separation of Category:Legal describing existing legal structures from Category:Legislation which describes groups and efforts that aim to pass laws.
    • Development of a Category:Scale to generate a set of categories that replace the Site concept and develop a five-scale definition of place, with development of a hierarchy of categories for regions and catchments. Categories for Landform Scale places are optional based on user work. A variety of templates (now described at Formatting Templates, are still used to identify landform scale places based on their dominant landform.
    • Development of a Category:Bioregion that is being used to capture place categorization for locations outside the Category:Salish Sea. Some policy decisions need to be made to determine how to consider "surrounding lands". Now and into the future.
  • Multi-Column Templates Using Flexbox - Template:TwoColumn Template:TwoColumnLeftPicture Template:TwoColumnLeftPicture are increasing responsive page layout options. This needs to become more systematic and available through edit windows. These and other features are now described at Formatting Templates
  • Introductory Page Overhaul - We have initiated a revision of the Introduction pages, removing or consolidating pages, particularly into the Big Picture page a Governance page, and a new Style Guide page. This resulted in identification of technical pages now using the Category:Technical. This work will likely continue piecemeal to consolidate and make more coherent.
  • Email stopgap - we lost email functions with the installation transfer, and have not yet moved the domain to its new final registrar, and so we established a google account as a temporary email instrument. This can be changed to a salishsearestoration.org domain once the transfers are complete... no hurry.

2023[edit]

  • SER has assumed stewardship of the wiki under an File:Operating agreement.pdf with WDFW, NOAA, and SERNW as the first supporting partners.
  • Under that operating agreement a contract with WikiWorks included a significant upgrade, including:
    • A new wiki was developed on a server managed by WikiWorks, and the historical wiki content was loaded.
    • The new wiki was loaded using the canasta package with many embedded extensions. https://canasta.wiki/documentation/#extensions-included-in-canasta
    • Adjustments to the old wiki formatting were made and the default skin reset to Chameleon, with development of a mobile-responsive formatting.
    • WYSIWYG editing
    • Update of all extensions to maintain functions

2022[edit]

We initiated a major upgrade, set up a governance system, brought in agency and private partners, and shifted ownership to SER.

  • Developed cost estimates and identified preferred vendor
  • Established WDFW-SER relationship for management and upgrade
  • Completed update and scope development
  • Category Changes
    • CANADA/USA - Build out the Canadian integration in the wiki, and check for coherence in workgroup categories. There is USA-centered residue from development. "Federal" could refer to both US or Canadian national government. State clearly refers to Washington State, while "Provincial" can be used to refer to British Colombian. "Local" could be either. It makes sense to have a "USA" vs. "Canada" category to differentiated between federals and locals. Should we have the same with state, and change it to state/provincial? Should we be able to selectively search at the three strata of government either across or excluding the national border?
    • TOPIC CATEGORIES - We have some organic category structures. This could be refined, and we need to figure out if there is a reliable heritable category system we want to use that allows for heritable categorization within a hierarchical structure. At minimum we need to ensure that all categories that organize topics are in the topic category.

2015-2017[edit]

  • Google Analytics - set up an account using info@ecosystemguild.org
  • Reviewed WYSIWYG editing options
  • We lost functionality for QuickLink (http://www.mediawiki.org/wiki/Extension:QuickLink) in the last upgrade. This was very useful because unlike the edit window link function it can search for any text string in page names rather than the first characters in page names.. it would be good to get this back.
  • Creating off-site links is worrisome as agencies are unreliable managers of PDF locations. A fast archive solution would bring a link target onto the wiki and link to it, while allowing for later development of document pages in the future (or automated development of a bare bones document page).
  • We had talked about quick categorizing using pick lists in the edit window... the SelectCategory extension had lots of bugs. Don't know if there is an alternative to our current static approach.

2013-2015[edit]

  • NEW ACCOUNT PROCEDURE - We need a vandal proof mechanisms for allowing the creation of new accounts. It needs: 1) minimum steps, 2) maximum autonomy, 3) no workaround.
  1. User privilages reduced to read only - 'fulluser' privilages created.
  2. Set up email authentication and notification - http://www.mediawiki.org/wiki/Manual:Configuration_settings#Email_settings
  3. New user sends email to site administrators
  4. Site admin promotes account to 'fulluser' privilages using special:userrights page
  5. Site admin notifies user of confirmation by adding template to userpage that requests information

How can we reduce the number of steps and actions by admin?

2011-2013[edit]

  • I am getting a error when I upload JPG or PNG -- In addition, when a image file does upload the page formatting gets screwed up.
    • issue resolved.
  • SPAMBOT DETERRENT - We are starting to get spam-bots developing user accounts. We need to add the http://www.mediawiki.org/wiki/Extension:ConfirmEdit extension and a CAPTCHA routine... i'd defer to your choice.
    • CAPTCHA was installed, but there are live vandals that are stil causing problems. We need to go to some kind of verification routine involving email, and perhaps manual promotion of users to privilage.
  • We should create a super user group for the ‘moderator team’ and revisit the permission for our ‘standard editor’. Resolved, ADMIN and BUREAUCRAT user groups meet needs of moderator team.
  • I’d like to have more deletion authority as we get this set up. I think we should allow file deletion by the file owner as well. Media wiki recommends redirects for deleation. [1] if we still want users to be able to delete pages they have authored (even though others may have updated them) we may be able to modify [2] or allow all users to delete, and add a hook to check if the user is an admin, or the originator of the article [3] Resolved for now... ADMIN user group can delete
  • Please change the logo. I have uploaded an exciting image. logo now lives at nw_logo.png - now racier than ever.
  • Can we change the font color for the page title something like maroon #800000. In addition I’d like to take a look at the CSS file governing page formatting for some minor tweaks to the box model.
    • Resolved -- in http://estuary.cs.wwu.edu/skins/monobook/main.css I added to the #firstHeading section #firstHeading {color: #800000;}
      For skinning changes you might look at http://www.mediawiki.org/wiki/Manual:Skins (excerpt below) Customization Users familiar with Cascading Style Sheets (CSS) can customize the current skin's file by creating a subpage of their userpage and naming it after the skin plus a .css postfix, "User:Yourname/monobook.css" for example. CSS placed in this sheet overrides the skin's CSS. This requires your site admin to have enabled this feature — if it is enabled, you will see advice text at the top of your custom CSS page about clearing your browser's cache. This can allow you to test what you want uploaded.
  • It would be also useful to setup this extension that allows for greater control of page appearance based on template..http://www.mediawiki.org/wiki/Extension:CSS
  • Add Embedded Video - http://www.mediawiki.org/wiki/Extension:VideoFlash - It would be useful to setup this extension that allows for embedded video links back to youtube orother services. - INSTALLED, the code looks like this for YouTube links: <videoflash>iTVI7c4bEXQ</videoflash>
  • http://www.mediawiki.org/wiki/Extension:User_Merge_and_Delete - lets us lump all vandals into a single user account, allowing us to clean house more efficiently - INSTALLED

a unit of government with specific authorities, or the area in which those authorities can be legally exercised

Retrieved from "https://salishsearestoration.org/w/index.php?title=Development_Log&oldid=25976"
This page was last edited on 8 November 2024, at 00:01.
The Salish Sea Restoration Wiki by salishsearestoration.org is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Privacy policy
Disclaimers