Get our free book (in Spanish or English) on rainwater now - To Catch the Rain.

Appropedia:Site development/Desired features

From Appropedia
Revision as of 00:34, 2 March 2008 by Writtenonsand (Talk | Contributions) (Wikipedia links: possible problem)

Jump to: navigation, search

This is just a wishlist. It includes things we'd like but don't know if we can do.

Those who help with the tech side of things can decide whether they can grant our wishes (and they together with the community can decide if they should grant them.)

Suggestions will be considered, but responses may take days, weeks or months, depending on the request, how critical it is, and available time and expertise.

The Priority tag doesn't necessarily mean much - it's just a guess at how much it's worth spending time on something (considering how easy or hard it is, and how valuable).

Enable Firefox users to add an Appropedia search to their toolbar

Currently if viewing Appropedia, and you select "Add Appropedia (English)" from the search menu, it comes back with the warning:

Download error
Firefox could not download the search plugin from http://www.appropedia.org/Opensearch_desc.php

--Chriswaterguy · talk 19:05, 6 March 2007 (PST)

Wohoo! I think it is fixed. The code is somewhat undeveloped, and I think that there may be some functionality built into mediawiki (since there is already atom and rss feeds) that we are not using. For now the additional fix came just from excluding the rewrite of opensearch_desc.php, by adding to .htaccess the following code-
RewriteCond %{REQUEST_URI} !^/opensearch_desc.php
--Lonny 17:27, 11 May 2007 (PDT)
Only just noticed your answer - very cool! No time to play with it now, but would be good to make sure it's easily available, easily installed, and linked from our homepage.
Also, instructions for other browsers would be good. Opera shortcuts are dead easy (though if we want to build a search box, that would take some learning.) For IE and Safari, I have no idea. --Chriswaterguy · talk 01:29, 4 November 2007 (PDT)
Please add to the instructions linked from the front page - Help:Using_OpenSearch. Thank you, --Lonny 07:14, 4 November 2007 (PST)

Add bigger edit toolbar

Add bigger edit toolbar, like Wikipedia now has. This includes a redirect button, which I'd find useful. There might be other useful things to add as well, in future, so it would be good to document here. --Chriswaterguy · talk 17:34, 30 April 2007 (PDT)

Note WikEd. Note also that there seem to be some bugs with WikEd... --Chriswaterguy · talk 00:19, 4 November 2007 (PDT)
This is done. I still have one more to add to the toolbar... which will be the most basic version of the ref tag. --Lonny 23:28, 3 December 2007 (PST)
Thanks! I'd noticed this when editing and was meaning to leave a thank you note. --Chriswaterguy · talk 16:55, 10 December 2007 (PST)

List poisoning for the wiki and/or forum?

Only if it's easy... Is it worth doing list poisoningDEPRECATED TEMPLATE - PLEASE USE {{W}} INSTEAD. on the wiki and/or forum? This could possibly reduce the impact of email harvestingDEPRECATED TEMPLATE - PLEASE USE {{W}} INSTEAD. by reducing the value of any list of email addresses harvested from the site. Not sure if it would actually make a difference... It also assumes that some people will not adequately encrypt their email addresses - a safe assumption, especially if we assume that sophisticated email harvesting bots can figure out basic encryption (e.g. fred AT domain DOT com, or use of NOSPAM as part of the address). The relevant lists of email addresses would need to be somewhere that's not noticeable/obtrusive to a human web surfer.

It would also be a bit of a contribution by us to the global spam problem. --Chriswaterguy · talk 22:46, 17 May 2007 (PDT)

Image upload...

License warnings

Image uploading needs a wizard, or at the very least some prominent warning notices. Images are being uploaded without license and attribution info.

At the Wikmedia Commons upload page, Commons:Project:Upload, questions are asked in large font. Hard to miss. And on clicking through (if logged in) a further warning in red stands out from the other text, saying "If you do not provide suitable license and source information, your file will be deleted without further notice. Thanks for your understanding."

Note MediaWiki.org has a prominent notice for text additions as well. We should think about whether to be a bit more prominent than we currently are (though maybe not as loud and red as MediaWiki - it feels unfriendly).

--Chriswaterguy · talk 07:48, 2 November 2007 (PDT)

Mass upload

Is there a way of uploading multiple images at once? HTML doesn't allow this, I think, so we need to look at other options. I've heard of an email setup being used, emailing the images to an address where they're automatically uploaded.

If this is done, there would still need to be a prompt regarding images. Perhaps encouraged for use only when all images uploaded at once are the same license, so a single choice applies to all images. --Chriswaterguy · talk 04:28, 5 November 2007 (PST)

Special license namespace(s)

Special namespace(s) for valuable material only available under non-GFDL licenses. In particular for non-commercial licenses - e.g. FAO content falls under this category.

We need to get legal advice, but we're thinking that non-GFDL licensed content would:

  • have a clear notice at the top,
    • highlighting that "this doc is controlled by non GFDL licensing"
    • naming and linking to the applicable license
    • warning against copy/pasting content from the non-GFDL content into GFDL pages.
  • be protected from edits because "all contributions are GFDL", and the other license may not allow divs. (If the license does allow divs but is non-commercial, one option is to allow edits, with contributions falling under that license. My - Chriswaterguy's - initial thoughts are to maintain the focus on the more open pages, i.e. GFDL. We could just suggest that relevant info be quoted, but not excessively, and cited. Paraphrasing and taking the ideas are also acceptable - again, its by far the best approach to cite the source.)

Note, if it's protected, with a warning against copying large sections, then there shouldn't be any derivs being made, and the "no-derivs" versions shouldn't be an issue. I.e. don't need a separate namespace for CC-nc-nd-sa and CC-nc-sa.

Name: NC: for non-commercial?

PDF creation extension

Priority: Low (not urgent)

If we install mw:Extension:Pdf Export (or something like that), will that make it easier for someone who wants to print/publish our material? --Chriswaterguy · talk 13:09, 3 November 2007 (PDT)

Hi Chris, We do have the printable version link at the bottom of the nav bar. I think that combined with the plethora of print to pdf programs like cutepdf should take care of most of our visitors. --Lonny 02:28, 4 November 2007 (PST)
Okay... a simple how-to page would be good at some point, for people who don't know where to start. --Chriswaterguy · talk 02:43, 4 November 2007 (PST)

When someone visits from a partner site, a cookie (or link script) tells Appropedia to display a banner for that person. The banner helps co-brand Appropedia by providing backlinks to the partner site, and Appropedia links related to the work or area of focus of the partner. This way partner sites can turn their resource area into a redirect to Appropedia without fearing a total loss of branding or visitorship. This idea gets very positive feedback from potential partners, and should be doable in a variety of ways. One is to use an ad server (suggested by Kate Stohr) that only serves ads from partners, but this would also have to recognize which partner site a visitor came from. Partners will also have Appropedia landing pages that contain basic information, links, RSS feeds and other calls to action from the partner site. --Chriswaterguy · talk 00:23, 4 November 2007 (PDT) --Lonny 02:51, 4 November 2007 (PST)

FlaggedRevs

mw:Extension:FlaggedRevs, when it's ready, looks like a more efficient way of doing stable versions...? --Chriswaterguy · talk

Showing (top) on recentchanges

Priority: Med (= nice, not critical)

The (top) notice next to changes on my contributions page is handy. Can we make it show on Recentchanges? --Chriswaterguy · talk 01:44, 4 November 2007 (PDT)

Setting who needs to be patrolled...

Priority: Med

This might be a question for MediaWiki.org. The red exclamation marks show me a page that is unpatrolled. I'd like to be able to turn this off for editors that I trust, to help me focus on monitoring changes made by editors I don't know well yet. It's not about how long they've been editing, but about their track record, which is a quesiton of judgment.

This might be a bit discriminatory - who decides if someone is trustworthy? - so the ideal would be if I could choose who I regard as trustworthy.

Even nicer (but probably completely unrealistic) would be if I could choose to have joint list with one or more other RC patrollers, if I trust their judgment on new editors. Something for MediaWiki version 4.0 perhaps :). --Chriswaterguy · talk 01:44, 4 November 2007 (PDT)

Search improvements

Priority: Med-high

  • a Google site search like at Laptop: is probably the low hanging fruit, to get better search performance. not sure how easy the other stuff is.
    • Note http://www.thinkwiki.org (a MediaWiki wiki for ThinkPad users) - also MediaWiki, and displays Google site search results within the wiki.
    • Having the option of other searches (e.g. Public Domain custom search) as drop-down options for the Appropedia search would be fantastic.
  • autosuggest in the search box would be awesome. This will probably be a little difficult - Lonny has worked on it a few times, but to no avail.

Redirects in search results

If we continue to use the built-in MediaWiki search engine, we should ensure that redirects are searched as well, so if a person searches for a related term, it will show up in the first section, i.e. page name matches. It's best if the redirect results are italicized though.

If we use a good external engine such as Google, hopefully it will all be taken care of automatically. --Chriswaterguy · talk 19:49, 12 February 2008 (PST)

Custom searches

Priority: Med-high for getting something happening, a bit lower for the fancy details.

  • Set up an account e.g. with Google apps, on an appropedia address (ap at ap dot org?) that all admins have access to, so we can have jointly managed custom search engines, like Woody's Appropriate Technology Search.
  • Have a way of showing this search box within a wiki page. Template, to make it easier.
  • Nice things (med or med-low prority):
    • A single search box with options: Search our wiki, our neighbourhood, AT/sustainability info, the wikisphere, the entire web. If we have a number of custom searches, the list could be on the long side, but not a big problem I think, as long as simpler concepts (e.g. "Related wikis") are at the top.
    • Default, if possible, could have "our wiki" results in the first column, and broad search results (on AT, sustainability) in the next.
    • Really snazzy would be to tag results from wikis... different colors or little gif or something. That's probably unrealistic, but I don't know.
    • If Wikipedia goes with Semantic MediaWiki one day, we could include a search of Wikipedia content in certain categories. (Possible to include everything in subcategories, to n levels?)

--Chriswaterguy · talk 22:31, 4 November 2007 (PST)

I second that. I would like something very similar around p2pfoundation.net wiki, and connect with related sites such as the cooperation commons, the sites by Sam Rose, etc..

Michel --61.7.174.173 01:43, 8 November 2007 (PST)

Voting on articles?

Priority: Low. Interesting, maybe.

Check this draft scoring system. (On closer examination, this one seems to be an automated ranking system, which makes a number of assumptions about Wikipedia articles - e.g. counting references as a positive, weighing that against "citation needed tags" - which won't hold here. I'm not convinced they hold at Wikipedia for that matter.)

The social networking approach is another option - but do we even want to go down that track - creating more popularity for the already popular pages?

--Chriswaterguy · talk 04:13, 4 November 2007 (PST)


Moving category pages in MediaWiki

Status: Solved

Priority: Med.

It's not possible to move category pages in MediaWiki. Can this restriction be removed for admins, so pages can be moved with their history intact?

Reason: This would take away one of the problems for our topic/category policy (that's if we continue to use categories for topical info, which is currently up in the air - this policy makes sense in a way, as most of the pages in the wiki are on projects or other content types, and this policy keeps topic content distinct and readily accessible while browsing).

--Chriswaterguy · talk 09:21, 5 November 2007 (PST)

Is it possible to use Special:Export and Special:Import in Mediawiki to move a category page while keeping the history? i.e. export and import to the same wiki.
Not sure if there's an option to change the name for the target (if not through MediaWiki, perhaps by editing the XML?).
If the target name clashes with an existing page (including a category), is a warning given? An option for rename? Must check to ensure there's no auto overwrite. --Chriswaterguy · talk 20:37, 3 December 2007 (PST)
I finally got around to trying this (I'd never dealt with these functions before) and it works. The name must be changed by editing the <title> field of the .xml file before importing.
I'll write up a guide at Appropedia:Moving category pages. --Chriswaterguy · talk 19:34, 9 January 2008 (PST)

Semantic MediaWiki

Priority: Medium-high - this might affect how we approach our categorization, which is something we put a fair amount of work into.

Semantic MediaWiki (see meta:Semantic MediaWiki) offers far more powerful searching and analysis of data in the wiki.

Requirements:

  • Powerful server - Semantic MediaWiki does slow things down. Limiting the number of parameters used in searching/analysis can reduce the load - e.g. no more than 2 parameters, or maybe 3 (depending how people are using it... it may be that not much benefit is obtained from this?) Or require admin status for server intensive analysis (admins could run searches on request, or someone could be given temporary admin status for that specific purpose?)

Questions:

  • Will it replace categories entirely? If so, our topic-category page system will need to adapt.

See Sites using Semantic MediaWiki to check how it looks and works in practice. --Chriswaterguy · talk 07:34, 19 November 2007 (PST)

"Image:" namespace change to "Media:"

"Image:" namespace should be changed to "Media:" to reflect the fact that it's not just images. --Chriswaterguy · talk 05:57, 22 November 2007 (PST)

Currently "Media:" is used to link directly to a file in the "Image:" namespace. For example Media:DoubleDig.swf. Maybe we could change "Image:" to "File:" or something like that. Any other mediawiki sites change the name of this Image namespace?
Thank you, --Lonny 11:40, 8 December 2007 (PST)

Category tree via template

{{Category tree}} would be a nice, relatively intuitive/consistent way of using the category tree code. But it doesn't work - any ideas? --Chriswaterguy · talk 01:12, 27 November 2007 (PST)

Date formats

Priority: low.

If wikilinking for dates could be made to only affect display format, and not to actually create a link, that would make for more consistent appearance.

Rationale: In pages like Upcoming conferences, it would be nice to have a mostly uniform date format. We could have a preferred format (e.g. 20 September 2007 is more international I think, as opposed to 20th September or September 20) - but enforcing it would be hard and a bit unfair. But in Mediawiki, if dates are wikilinked, they can be displayed according to the user's preferences.

However, having the dates wikilinked is one of the less attractive features of Wikipedia, I feel - wikilinks should always be relevant, and links to dates will usually not be relevant (unless we link to events happening on certain dates... but even then, it's not likely to tell the reader more than that there's a clash with another event that might be on a different topic on a different continent). --Chriswaterguy · talk 23:57, 7 December 2007 (PST)

Fan mail

One of wikiHow's cool features is fan mail - see examples at wikiHow:Project:Best of Fan Mail. People leave fan mail for an article, and anyone who has edited the article gets the note on their "User kudos" page, e.g. wikiHow:User_kudos:JackHerrick.

This is presumably one of wikiHow's additions to MediaWiki, which they said (personal conversation) are open source. --Chriswaterguy · talk 07:10, 10 December 2007 (PST)

ParserFunctions

ParserFunctions (see mw:ParserFunctions) to allow optional arguments in templates. I haven't figured out how they work, but several templates I've tried copying from Wikipedia use them, and some ideas I've had for templates rely on optional arguments. --Chriswaterguy · talk 23:12, 22 December 2007 (PST)

Update: Note changes made recently, at Wikipedia:Project:Wikipedia_Signpost/2008-01-21/Parser_changes. --Chriswaterguy · talk 21:21, 24 January 2008 (PST)

Mailing lists

Priority: Medium-high. This would be a bit of a boost for our connectedness to other groups, and adding content.

Set up a mailing list function, archived on the site. This will be:

  • an added service to users
  • a way of identifying Appropedia with the topics of the mailing lists
  • a way of adding open content to the site, by archiving the emails. (A note to this effect, that all emails to the list are regarded as being under Appropedia's license, is to be shown as part of signup, and in the (brief) footer on every email.

See Appropedia:Non-Drupal alternatives for Appropedia forum and blog for some discussion on making this work nicely - though since we're going with Drupal for most of the blog/forum stuff, the mailing lists won't be so demanding.

--Chriswaterguy · talk 22:56, 10 January 2008 (PST)

Permissions on the wiki

These comments have been moved to Appropedia:Permissions as it wasn't actually requesting anything. --Chriswaterguy · talk 17:57, 31 January 2008 (PST)

Widgets

It's already possible to insert certain widgets into pages - (e.g. calendars and maps, as on User:Lonny - are these widgets?) A couple of Google's OpenSocial widgets look useful too. We should make a list of useful ones on Appropedia:Widgets.

Is there something we need to do with Appropedia's in order to have more freedom with Widgets?

Below is an extract from a Wikispaces newsletter, which prompted the question. --Chriswaterguy · talk 17:35, 31 January 2008 (PST)

This month, we are bringing you a bunch of cool new Wikispaces widgets to put on your wiki pages. You can now put your discussion forums, page history, table of contents, or list of top space contributors directly on any page. Click "Edit This Page" and click the embed widget icon (psst...the one that looks like a TV). There's now a "Wikispaces" option where you will see the various widgets you can easily put on your space. For more on this, see our blog post at http://blog.wikispaces.com/2008/01/wikispaces-widgets.html .

Wikispaces' "Vastly Improved Table Editing"

This would be very nice. Is this also just a matter of waiting till MediaWiki developers implement this? (Sounds like it needs WYSIWIG/Wikiwyg.) --Chriswaterguy · talk 17:35, 31 January 2008 (PST)

We also bring you new and improved tables! Most importantly, we have built an easier way for you to edit your tables. Now, when you click on a cell in any table, you can click on the table icon that appears at the corner of that cell. A popup window will then appear which will allow you to add or delete rows or columns, align the text within the table, merge cells, create table headers, and delete your table. You can also place math, source code, and RSS feeds directly into your table. To see how this new tool works visually, check out our blog post at http://blog.wikispaces.com/2008/01/our-simplified-table-editor.html or try it out for yourself.

Rich text editing

See Appropedia:Rich text editing for links and ideas relating to this.

Various options, e.g. Wikiwyg - mw:Extension:Wikiwyg - sounds fantastic, but poses some technical challenges.

Before taking steps, wait for answers to the question at mw:Extension:Wikiwyg #Not used on Wikimedia projects? --Chriswaterguy · talk 17:45, 31 January 2008 (PST)


Diff in notification email

Priority: Low The Laptop wiki has this feature working on MediaWiki. So the email gives the usual notification and link, and then says "Below is the difference between the last two revisions:..."

One downside: If I get such a notice, I possibly don't need to view the page... but as a result, I don't get email notification of future changes, until I do view the page. --Chriswaterguy · talk 15:03, 18 February 2008 (PST)

Extension:ArticleComments

Priority: Med mw:Extension:ArticleComments looks like it could be a good way of getting more input and engaging more with readers. Note that the comments are added with <comments /> - it doesn't apply to every page unless mw:Extension:Header Footer is used, so it's something we could try out and phase in.

I'm very keen to try this, and see what response we get! Even if it's not something we want to use on many pages, I'm sure we'll learn some things. --Chriswaterguy · talk 15:40, 22 February 2008 (PST)


Tag class projects in Recent Changes?

We have a template or templates for identifying articles which are class projects (- e.g. for Engr305), which indicates "Please refrain from making edits unless you are a member of the project team". If possible to do so, we might also want to identify the pages of class projects in Recent Changes, so that people who shouldn't be editing them will know not to bother clicking on them (except for purposes of reading the article, of course!)
(And conversely, I suppose, by so identifying class projects, those who are entitled to edit them will locate them more easily on Recent Changes.) -- Writtenonsand 17:04, 23 February 2008 (PST)


Wikipedia links: possible problem

We have a link style [[wikipedia:Foobar|Foobar]] which produces a link which looks like this: Foobar.

This links directly to the Wikipedia article "Foobar", but is indistinguishable from an internal link to an Appropedia article.

This will cause users to bypass our own articles, whether already-existing, or later created; both missing possibly-useful content on Appropedia as well as failing to realize that we even have various articles.

We may want to eccourage use of {{wp|Foobar}} and/or {{wp sup|Foobar}} and deprecate [[wikipedia:]].

We may even want to write a bot that will list all uses of [[wikipedia:]] on the site so that a human can manually check whether they're appropriate.

-- Writtenonsand 21:34, 1 March 2008 (PST)