Site programming

From Wise Nano

Jump to: navigation, search

This page describes planned software changes.

Contents

Programming notes (war stories)

The code is levels within levels. Web programmers may be used to it, but as a former embedded programmer, I wasn't!

Programming notes is the record of what I did to make the fixes, and more importantly, how I learned what to do.

Make sections first-class objects

Currently sections are labeled/numbered on the fly. This creates several problems/limitations:

  • Section numbers can change with editing.
  • Sections can't be appended to.
  • Section references may go away.

This will require some thought: How will editing a whole page work if sections are essentially pages?

It'd be nice to be able to transclude sections of pages, like a summary or intro section. This might be special-coded.

This idea seems related to the comments/annotations idea bounced around, where hidden notes can be shown within an article. Peter[1] is also looking at how to deal with article separation for dealing with code separation. Their idea is that they dont want "<tag>lotsofcode</tag>" to be an obstruction. Templates might be a workaround, and their usage and flexibility might be diversified to include other uses, like those youre thinking of.
For example this comment could have been added as a template message from a subpage, (/comment1) which can be the target of a redirected templage at Template:Site programming/Comment1. Showing this in a tag (<nowkiki>Template:Site programming/Comment1</nowiki>) could be made easier. Like with a /subpage syntax that resembles the template syntax. Maybe a simple fork of the existing template code to link to a empty subpage (instead of a new Template:page) like {comment} might create a {{comment1}} tag which links to a [[/comment]] link on a subpage. Ideally these would be in an optionally shown or hidden div. -Estha 13:43, 1 Dec 2004 (CST)
This is an interesting approach. But I don't think it solves the problem of how you can edit a whole page if sections are templates. Chris Phoenix, CRN 15:19, 1 Dec 2004 (CST)

Handle editing vs. logins better

Currently, if logged-in users only are allowed to edit, the site may log them out in the middle of an edit job, and unless they're competent with the [back] button they lose their work. This is unacceptable. Conversely, if anonymous users are allowed to edit, there's no incentive or even reminder to log in.

Proposed fix: Modify the userlogin and edit-error screens so that they preserve the edit text fields (and reassure the user that they have done so!) This allows several new options:

  1. If anon edit is not allowed, and an anon edit is submitted, they can log in and continue editing smoothly.
  2. If anon edit is allowed, we can bounce anon submissions through a screen that says "We encourage you to log in, or click here to submit your text anonymously."

Show all system messages in Special:Messagediffs and Special:Allmessages

If I add new system messages by editing new pages, they don't show up in the message list pages because those pages use the list from the Language*.php file rather than searching the namespace. That should be fixed.

Newbie help links

  • Make big "How to use this page" links (part of the skin) for all types of page
  • Let them be turned off in Preferences when the user doesn't need them anymore

Email notification of changes

Code is being developed; see http://meta.wikimedia.org/wiki/EmailNotification

Integrate this code once it's released. (User:Cphoenix is working on this.)

Add "Mail me my username" button

Some people use lots of usernames on lots of sites, and they may forget the name they used, but they'll remember their email address. So put a "Mail me my username" next to the "email" box. DevRandom: I'm working on this

User rating scheme

See http://www.thesearchforwisdom.com/tour/tour.html - he has ratings in BB and is adding them to Wiki.

Require preview and summary

  • Help people do the right thing
    • Don't put "save page" on the first edit form, only "show preview"
    • Don't accept edits without either summary or minor-edit

The first task can quite easily be accomplished by editing the EditPage.php file - just comment out the "save page" button. The second task can also be done in EditPage.php with a little commenting out of the mediawiki code and adding your own php code.

Help starting pages

Goal: Make it really easy for people to create new pages

Done: Add "Create Article" boxes to all category pages

Todo:

  • Probably add namespaces e.g. for project pages
  • Change instructional text for editing new pages depending on type of page (e.g. category)
  • Insert text into initial new-edit boxes depending on type of page
  • Help-wanted messages shouldn't have to type all the ['s and Category's
  • Make it easy to extract/export sections to new pages if they're getting too long (esp. for discussions)

Help Wanted

Goal: Let people ask for specialist help by including something like a category statement; display on the main page the number of help-wanteds in each category.

Accomplished: Subcategories of HelpWanted show their search keys in the "articles" list rather than the article names. So you can say [[Category:PhysicsHelp|Do tachyons really go faster than light?]] and the question will be displayed under the PhysicsHelp category page, and clicking on the question will go to the article where the question was asked.

Todo:

  • Make a nicer text interface that will be parsed to the Category statement
  • Add code to count the number of articles included under each HelpWanted subcategory, and display all categories on a special page that can be included in the main page by template.
    • Specify a way to say a question has been answered (maybe just removing the Category link).
  • You can't template-include a Special page. Hack it so this one works.
  • If this is going to be expensive, cache it.
  • Think through all category-cache and other cache issues.
  • If a category appears twice on one page (e.g. two physics questions) display both in the category page. Currently only one is displayed.

Talk Page

Goal: Make "talk" more like a discussion list (more threaded, less editable)

Accomplished:

  • Allow only "section=new" editing for users
    • Change UI (skins) and section-edit-link displays to indicate this
      • (the skin does not need to be changed for this, instead a condition for adding the "Edit" link based on whether the page is a Talk page or not can be put in SkinTemplate.php (around line 570))
  • Auto signature/date inclusion (in header/subject)

Todo:

  • Add "section=new" editing for subsections:append to that subsection
  • Use the diff function to show what's changed recently
    • It shouldn't be a normal complex diff page--just display the page normally, but with the changed paragraphs in a different background color. (Is this a good idea for all pages--show diffs since last time I edited the page?)
    • UI to specify the date to compare with:
      • Last login;
      • Last time I edited;
      • Last [ ] days
  • Add a user-editable section (0?), e.g. for help-wanted questions that must be removed later; don't allow section headings in this section
  • Optional: When editing a section, display the "preview" in the first edit window
  • Optional: When showing a talk page, put an edit window at the bottom

Category follower

Goal: This site will make heavy use of categories to show connections between pages. These links should be followable.

Todo:

  • Define a set of categories for indicating causal and rhetorical links. See site taxonomy under "Meta tags" for a more complete list.
    • Causal
      • A causes B
    • Rhetorical
      • A supplies information on B
      • A disagrees with or contradicts B
      • A supports B
  • Maybe define an interface for entering them between articles.
  • Invent a UI to browse from one article to another. Something like the Prev/Next template.
  • Invent a UI to display causal chains.
  • Think about ways to show effects, like importance of an issue, building/propagating along a chain or web. For example: What's the biggest risk of nanoparticles? It should be possible to see that. Or at least: What are the risks of nanoparticles (even if it goes tech -> product -> effect -> risk).
  • Think about reputation, contradiction, other ways to indicate that an article is affected by other articles.
(In Wikipedia this is handled by a big user community that keeps each other in line. We'll be smaller at least at first, and also the disagreements will be matters of theory that may not be resolvable. An unresolvable disagreement ought to be explicitly trackable. (This may use the same infrastructure as the previous point.)
  • Optional: Display article links differently (e.g. in category member lists) depending on their status.

(maybe) per-page edit controls/whitelist

People working on projects may want to allow only a few contributors/editors. A per-page list of who can edit would enforce this.

(later) Tracking between multiple article versions

  • Make an association between multiple articles with the same content but different languages or levels of explanation (grade school, undergrad, specialist)
  • When one is edited, flag that the others need to be updated. As they are updated, clear the flag.
Retrieved from "http://wise-nano.org/w/index.php/Site_programming"
Personal tools