Knowledge Commons - Recent changes [en]

Default Wiki Pages

Mshell — Tue, 28 Jul 2026 19:53:34 GMT

← Older revision		Revision as of 19:53, 28 July 2026
Line 5:		Line 5:
	=== Tutorials ===		=== Tutorials ===

	* Examples ~~of many features~~		* [[Wiki Formatting Examples]]
	* Creating and editing pages		* [[Creating and editing pages]]
	* Advanced Topics		* [[Advanced Topics]]

	=== Notes ===		=== Notes ===

Possible Names

Mshell — Wed, 22 Jul 2026 22:57:10 GMT

← Older revision		Revision as of 22:57, 22 July 2026
Line 13:		Line 13:
	* Mywiki.life		* Mywiki.life
	* Lifenotes.wiki		* Lifenotes.wiki
			* myKnowledge.org (available for $4,000)
			* webOfKnowledge.wiki
			* wokwiki.org (wok = web of knowledge)
			* wok.wiki ($150/yr)
			* mywok.org
			* mywok.wiki

Default Wiki Pages

Mshell — Wed, 22 Jul 2026 19:36:30 GMT

Created page with "This page shows the default pages for all newly created wikis: Welcome note at the top. === Tutorials === * Examples of many features * Creating and editing pages * Advanced Topics === Notes === * Household ** Products ** Technology * Vacations ** Bucket List ** Upcoming * Entertainment ** Books, Theater, Concerts * Hobbies ** Photography * Learning..."

New page

This page shows the default pages for all newly created wikis:

Welcome note at the top.

=== Tutorials ===

* Examples of many features
* Creating and editing pages
* Advanced Topics

=== Notes ===

* Household
** [[Products]]
** [[Technology]]
* Vacations
** [[Vacation Bucket List|Bucket List]]
** [[Vacations Upcoming|Upcoming]]
* Entertainment
** [[Books]], [[Theatrical Performances|Theater]], [[Concerts & Live Events|Concerts]]
* Hobbies
** [[Photography]]
* Learning
** [[High School]]
** [[University]]
** [[Self Learning]]
* Career Development
** [[Skills Development]]
** [[Job Search]]

Main Page

Mshell — Wed, 22 Jul 2026 19:26:11 GMT

Project Details

← Older revision		Revision as of 19:26, 22 July 2026
Line 16:		Line 16:
	** Identify members of the [[Board of Directors]]		** Identify members of the [[Board of Directors]]
	** Decide on a [[Possible Names\|name]]		** Decide on a [[Possible Names\|name]]
	** [[Podcast Request to Create a Wiki\|Create a ~~wiki~~]]		** [[Podcast Request to Create a Wiki\|Invite People to Create a Wiki]]
			** Define the [[Default Wiki Pages]]
	* Future Enhancements		* Future Enhancements
	*# Create a System For Community Members to [[Vote on Future Projects]]		*# Create a System For Community Members to [[Vote on Future Projects]]

Possible Names

Mshell — Tue, 21 Jul 2026 22:41:21 GMT

← Older revision		Revision as of 22:41, 21 July 2026
Line 9:		Line 9:
	* knowledgetree.wiki		* knowledgetree.wiki
	* gardenofknowledge.net, gardenofknowledge.info, gardenofknowledge.wiki		* gardenofknowledge.net, gardenofknowledge.info, gardenofknowledge.wiki
			These names need to be added to the voting on the home page.
			* LifeAndLearning.wiki
			* Mywiki.life
			* Lifenotes.wiki

Higher Education

Mshell — Mon, 20 Jul 2026 23:36:04 GMT

← Older revision		Revision as of 23:36, 20 July 2026
Line 1:		Line 1:
	[[File:DukeWEMBAnotes.jpg\|alt=A stack of all my notebook binders from my MBA courses at Duke University.\|thumb\|A stack of all my notebook binders from my MBA courses at Duke University.]]		[[File:DukeWEMBAnotes.jpg\|alt=A stack of all my notebook binders from my MBA courses at Duke University.\|thumb\|A stack of all my notebook binders from my MBA courses at Duke University.]]
			'''REMINDER: I will not communicate to anyone (including Steve & Erin) about any of this until we have over 100 users and are on the production platform. I don't mention anything to Steve & Erin about transparency. For now, limit to Gavin, Elias, and their friends.'''

	In 2011, I graduated from the Executive MBA program at Duke University. For each course, students were given a three-ringed binder notebook with the reading and assignments. We were not allowed to have laptops in class, so all my notes were hand written right on the pages of those binders. I moved to New York City after completing the program to a tiny apartment and didn’t have room for them anymore, so I went through each one and transcribed the most important notes into a digital note taking tool. I took this picture after I stacked them all in the refuse room of my apartment building. Although I had copied the most important notes, I knew that I was losing a tremendous amount of knowledge.		In 2011, I graduated from the Executive MBA program at Duke University. For each course, students were given a three-ringed binder notebook with the reading and assignments. We were not allowed to have laptops in class, so all my notes were hand written right on the pages of those binders. I moved to New York City after completing the program to a tiny apartment and didn’t have room for them anymore, so I went through each one and transcribed the most important notes into a digital note taking tool. I took this picture after I stacked them all in the refuse room of my apartment building. Although I had copied the most important notes, I knew that I was losing a tremendous amount of knowledge.

Flutter Dart

Mshell — Tue, 14 Jul 2026 19:42:09 GMT

← Older revision		Revision as of 19:42, 14 July 2026
Line 1:		Line 1:
	Yes—'''Flutter/Dart could be useful later for the iPhone and Android apps''', but I would not use Flutter as the primary technology for customizing the MediaWiki web application.		Yes—'''Flutter/Dart could be useful later for the iPhone and Android apps''', but I would not use Flutter as the primary technology for customizing the MediaWiki web application as part of the overall [[Production Architecture]].

	The strongest architecture is:		The strongest architecture is:

Flutter Dart

Mshell — Tue, 14 Jul 2026 19:41:33 GMT

Created page with "Yes—'''Flutter/Dart could be useful later for the iPhone and Android apps''', but I would not use Flutter as the primary technology for customizing the MediaWiki web application. The strongest architecture is: <code>MediaWiki remains the core platform and system of record ↓ MediaWiki skin and extensions provide the web experience ↓ MediaWiki APIs expose application functionality ↓ Flutter provides an optional iOS/Android client</co..."

New page

Yes—'''Flutter/Dart could be useful later for the iPhone and Android apps''', but I would not use Flutter as the primary technology for customizing the MediaWiki web application.

The strongest architecture is:
<code>MediaWiki remains the core platform and system of record
↓
MediaWiki skin and extensions provide the web experience
↓
MediaWiki APIs expose application functionality
↓
Flutter provides an optional iOS/Android client</code>

== For the web application: stay native to MediaWiki ==
For the web version, align closely with standard MediaWiki development practices:

* '''PHP''' for extensions, business logic, hooks, permissions, special pages, and server-side features
* '''JavaScript''' for interactive browser behavior
* '''CSS/LESS''' and a MediaWiki skin for visual customization
* <code>extension.json</code> and <code>skin.json</code> for standard extension registration

MediaWiki explicitly supports customization through skins and extensions. Its documentation notes that skins control appearance, while extensions customize how MediaWiki works. Basic skin work can be done largely with CSS, JavaScript, and JSON; PHP becomes useful for more advanced behavior. (MediaWiki)

That approach gives GoalStriving several advantages:

* MediaWiki developers can understand and contribute to it.
* Your code can potentially be distributed as conventional MediaWiki extensions or skins.
* You can reuse standard authentication, permissions, page history, templates, categories, notifications, and extension hooks.
* MediaWiki upgrades will be easier than if you replace the normal interface with an unrelated frontend framework.

I would avoid building the web version itself in Flutter Web. Technically Flutter supports web deployment, but it would make GoalStriving feel less like a native MediaWiki project and could complicate accessibility, search indexing, browser behavior, extension compatibility, and community contribution. Flutter’s cross-platform capability is real, but its strongest role here is as a separate mobile client. (Flutter Docs)

== For mobile: Flutter is a reasonable choice ==
Once the MediaWiki web application and its data model are stable, Flutter could provide one shared codebase for:

* iPhone
* Android
* potentially desktop apps later

Flutter officially supports mobile, web, and desktop deployment from a shared Dart codebase. (Flutter Docs)

A GoalStriving mobile app could offer a more focused experience than the full wiki interface:

* View goals and current priorities
* Add progress updates
* Complete daily or weekly check-ins
* Receive reminders
* Record journal entries
* Upload photographs
* Work offline and synchronize later
* Display dashboards and progress charts
* Use mobile notifications and biometric authentication

The app would communicate with MediaWiki rather than replace it.

== MediaWiki should remain the backend ==
MediaWiki provides both an Action API and a REST API. The Action API currently offers broader functionality, while the REST API provides newer, more structured HTTP endpoints. Extensions can also register their own REST endpoints. (MediaWiki)

For GoalStriving, you may eventually create API endpoints such as:
<code>GET /goalstriving/v1/goals
GET /goalstriving/v1/goals/{id}
POST /goalstriving/v1/goals
POST /goalstriving/v1/checkins
GET /goalstriving/v1/dashboard</code>
Those endpoints could be supplied by a normal MediaWiki PHP extension. The Flutter app would consume them using JSON.

This separation is valuable:
<code>MediaWiki extension
- Defines goals
- Enforces permissions
- Stores or retrieves information
- Implements workflow rules
- Exposes REST endpoints

Flutter app
- Presents the mobile interface
- Handles navigation
- Stores temporary offline data
- Calls MediaWiki APIs
- Uses phone-specific features</code>

== Important design decision: pages versus structured records ==
Before building the mobile app, determine how GoalStriving data will be represented.

You might store goals as:

# Ordinary wiki pages with templates
# Semantic MediaWiki properties
# Cargo records
# Custom MediaWiki database tables
# A hybrid of pages and structured records

For community alignment, a hybrid is likely strongest:

* Human-readable wiki pages remain the durable content.
* Templates, Semantic MediaWiki, or Cargo provide structured fields.
* A GoalStriving extension provides workflow and API functionality.
* Flutter consumes the structured representation.

For example:
<code>Goal page
├── Title
├── Description
├── Owner
├── Status
├── Target date
├── Motivational priority
├── Progress entries
└── Related goals</code>
The same information could be edited through:

* standard MediaWiki forms,
* a customized web interface,
* or the Flutter mobile app.

== How to remain aligned with the MediaWiki community ==
I would follow several principles.

=== Build standard extensions rather than modifying MediaWiki core ===
Do not directly edit core MediaWiki PHP files. Put GoalStriving functionality into independently installable extensions and skins. MediaWiki’s supported customization model is explicitly based on extension points, hooks, extensions, skins, gadgets, and APIs. (MediaWiki)

=== Keep the normal wiki usable ===
The project should still work through a browser without the Flutter app. Mobile users who do not install the app should be able to use a responsive MediaWiki interface.

=== Use open standards and documented APIs ===
Prefer:

* MediaWiki REST endpoints
* Action API where necessary
* OAuth or another supported authentication approach
* JSON
* standard MediaWiki page and revision concepts

=== Open-source the MediaWiki components ===
A clearly separated collection could be appealing to the community:
<code>GoalStriving extension
GoalStriving skin or skin customization
GoalStriving templates
GoalStriving Page Forms
GoalStriving mobile app</code>
Someone might adopt only the extension or templates without using the mobile app.

=== Treat Flutter as a client, not the platform ===
This distinction will help community acceptance. GoalStriving would remain a MediaWiki application that happens to offer a Flutter mobile client—not a Flutter product that merely uses MediaWiki as an incidental database.

== Recommended development roadmap ==

=== Phase 1: Define the MediaWiki data model ===
Decide how these concepts are represented:

* goals
* projects
* progress updates
* habits
* motivational priorities
* users and groups
* privacy
* relationships among goals

=== Phase 2: Build the web experience natively ===
Use:
<code>PHP MediaWiki extension
JavaScript
CSS/LESS
MediaWiki skin or skin customization
Page Forms / Semantic MediaWiki / Cargo as appropriate</code>

=== Phase 3: Create an API boundary ===
Do not let the future app depend on scraping HTML pages. Expose stable structured API responses from the GoalStriving extension.

=== Phase 4: Build a small Flutter proof of concept ===
Start with only:

* login
* list goals
* view one goal
* add progress update

This will expose any weaknesses in the API and data model before you build the full app.

=== Phase 5: Add mobile-specific value ===
Add features that justify installing an app:

* notifications
* offline access
* quick check-ins
* camera uploads
* widgets
* biometric login
* calendar integration

== My recommendation ==
Use this technology allocation:
{| class="wikitable"
!Layer
!Recommended technology
|-
|Core platform
|MediaWiki
|-
|Server-side customization
|PHP extension
|-
|Web UI behavior
|JavaScript
|-
|Web appearance
|MediaWiki skin, CSS/LESS
|-
|Structured data
|Semantic MediaWiki, Cargo, custom tables, or hybrid
|-
|API
|MediaWiki REST API plus extension-specific endpoints
|-
|iOS/Android
|Flutter/Dart
|-
|Authentication
|MediaWiki-compatible OAuth/session approach
|}
Flutter is therefore a good potential fit, but '''only after the MediaWiki application, data model, and API are stable'''. Your immediate learning investment should probably remain PHP, MediaWiki extension architecture, JavaScript, and MediaWiki APIs. Dart becomes worthwhile when the mobile client becomes an active development phase.

Production Architecture

Mshell — Tue, 14 Jul 2026 19:40:30 GMT

Environments

← Older revision		Revision as of 19:40, 14 July 2026
Line 45:		Line 45:
	=== Email and Productivity Suite ===		=== Email and Productivity Suite ===
	We will use Google G-Suite. Each account will be about $8 per month until the nonprofit has been formed and we can apply for a grant from Google for free accounts.		We will use Google G-Suite. Each account will be about $8 per month until the nonprofit has been formed and we can apply for a grant from Google for free accounts.

			=== Smart Phone Apps ===
			The GoalStriving project uses MediaWiki as the application platform. I intend to do some customizations to the UI and the application, but previously I was thinking that would be done in PHP, but I had not begun planning. Once the web version is stable, I would like to create an iPhone and Android version. Would Flutter/Dart be useful on this project? I want to remain aligned with the MediaWiki community, because I think that community would all be potential users or supporters of the project. [[Flutter Dart\|View Response]]

Page Sets

Mshell — Sun, 12 Jul 2026 15:10:28 GMT

← Older revision		Revision as of 15:10, 12 July 2026
(2 intermediate revisions by the same user not shown)
Line 7:		Line 7:
	** Journal: write a journal while on vacation, upload your favorite photos		** Journal: write a journal while on vacation, upload your favorite photos
	** Future: bucket list of vacations you want to take one day		** Future: bucket list of vacations you want to take one day
			** Packing: if my friend and I both have the Packing page set installed (it probably should be by default) then when I browse anyone else's similar page, there is a plus sign next to each content section where I can add it to mine with a single click! And you can see how many other peopel have added that content. Instead of copy/pasting, we encourage you to Link the content Block and it will display that content block whereever you want in your wiki and by default you can either have it show this snapshot in time, or whatever the current version is based on teh owner's updates. That allows one user to "Subscribe" to a Content block of another user.
			** You could have a content block called Status with a value that changes based on your calendar "in a meeting, busy, whatever level you want to show", and make that available to other groups dynamically and you can write rules to change it automatically based on time or events.
	* Products		* Products
	** Purchase information, warranties, maintenance logs, usage notes, links, and support history		** Purchase information, warranties, maintenance logs, usage notes, links, and support history