This is a static copy of the main site, preserved for historical purposes only. Please see this page for more information.

Feature Requests

InfoInfo TalkTalk MapMap

Post new features you might like in wikispot here.

Editing & Viewing Changes

  1. Editing & Viewing Changes
    1. Adding an auto wiki link button when editing a page
  2. User metadata, registration, and authentication
  3. Wiki structure/organization
  4. Mapping
  5. Events
  6. Misc
    1. Minor CSS/Stylistic requests
    2. Adding an RSS button to each page
    3. Edit Comments For Mini-Editor
    4. You Tube
    5. PhotoGallery Macro
    6. Rename User account
    7. Admin contact
    8. Sortable Tables
    9. Searching stuff
    10. Spam plan
    11. Portals
    12. Mobile CSS
    13. Separating out Users/ links
    14. Counter
    15. Included pages aren't Orphans
    16. Incoming Links Macro
    17. 2 or 3 Column FootNote Macro
    18. Collapse and Expand lists
    19. Better handling of large images
    20. Outgoing Link Protocols
    21. A stunning alternative to footnotes
    22. No Re-Submit in the Browser History
    23. Ability to cover up "Spoiler Text"

Adding an auto wiki link button when editing a page

User metadata, registration, and authentication

Wiki structure/organization


Note that the ability the put arbitrary HTML in wiki pages would allow working around all current mapping limitations, but there is currently no way to do this, even by the wiki administrator. If you try, the angle brackets get quoted automatically.



Minor CSS/Stylistic requests

Another thing that would be awesome is the ability to change the background color of included subsections, this may seem pointless but it is done in most wikis' if CSS 3 worked, I could use nth child to work it in a general case, but having the ability to add colors is good right? then again, it would be also awesome to have minor css capabilities for each page that was translated through, that is a bit too complex though...

Adding an RSS button to each page

Edit Comments For Mini-Editor


So it seems like people want comments for quick edits, but I think that by stuffing another text box in there we may be clogging up things. How about a link that says "Comment on change?" that then creates the comment area?

You Tube


<object width="425" height="350"><param name="movie" value=""></param><param name="wmode" value="transparent"></param><embed src="" type="application/x-shockwave-flash" wmode="transparent" width="425" height="350"></embed></object>

Maybe [[Revver()]] or others?

PhotoGallery Macro

[[Gallery]] placed on a page would look at the files section of the page and display any photos that were marked using a checkbox on the files page as display-in-gallery. There are a number of galleries to choose from. Potential options include [[Gallery(slideshow, 5sec)]] or [[Gallery(random)]].

Rename User account

Some people change their names in their lifetime (for instance, a SarahHillard might want to become a SarahEdwards).

Admin contact

Each wiki should have an email address in the wiki settings. Some kind of 'contact admin' feature is probably needed. I'm not sure where this should be displayed, but a generic form, filled out when someone is logged in, that gets routed to their email should be good.

Sortable Tables

The || table coding could use a sortable tag that would allow a table to be sorted by the user on the page. It was the movies filmed in SF page that made me think of this. Right now it is sorted by alphabetical order, but if it were turned into a table and year filmed was added then the user could get both a chronological order and alphabetical order just by clicking on the appropriate heading.

||<sortable>Movie Title||<sortable>Year Filmed||

This could also be used in comparison sets like lists of restaurants:

||<sortable>Restaurant Name||<sortable>Price Range||<sortable>Offers Vegetarian options?||

Searching stuff

(10:40:37 AM) Phillip: If you mean searching for like "Dogs" brings up search results and doesn't immediately take you to the "Dogs" page
(10:40:43 AM) Dave: yes
(10:41:01 AM) Phillip: the reason is that if we did that we'd then have to provide another search button (and we don't even have one button right now — we have a tniy icon), and it would look kind of lame
(10:41:51 AM) Dave: or you pull up the page and have a link to a forced search page at the top..
(10:42:12 AM) Phillip: that's a good idea maybe
(10:42:15 AM) Dave: also, it would be cool that the partial pages presented by the search were processed into includes.
(10:42:27 AM) Dave: thus i could actually see the page
(10:42:29 AM) Phillip: add that to feature reqs because i won't remember it otherwise

The global search box on the front page of the hub should search for wiki names as well.

The wiki has grown sufficiently large that information on it is becoming difficult to find, even using the search function. (For example, I just searched for 5 minutes for the wiki talk page, and couldn't find it!) The search feature needs to be able to handle much more sophisticated searching - boolean searching, and metadata searching. ie. I should be able to search for a page that was edited in a certain time range by a certain user or set of users, or the set of pages linking to a specific wiki page. I think that this would make wiki search much more powerful.

It would be really great (at least for the way I use Davis Wiki) if the response for an attempt to load a nonexistant page would offer suggestions from a search (I realize that there is a link to search at the bottom of the page, but it needs to be open and is much less prominent than the rather less helpful invitation to create the missing page anew. Example: the user is looking for the local Ace hardware store, so they try  http://(some wiki)/Ace , a page that doesn't exist. However, there does exist a page called Ace_Hardware, so the wiki's response page offers a link to  http://(some wiki)/Ace_Hardware  and asks whether that is what user is looking for. HenryHouse

Spam plan

Better restrictions on non-logged in editing. Captchas on non-logged in edits, and a captcha on user account creation. The following UI would apply:

Later on we can do fancier things, but this is probably a good starting point and will surely block out nearly all spam.

"Fancier things" would be: showing captchas to only unknown IPs — after passing a captcha the IP enters into "good" status for a temporary amount of time. Showing captchas to users ("good" — logged-in) that show "bad behavior."

2007-10-19 07:40:12   What kind of real-world testing have you done with captchas? From what I've seen, the spammers have been defeating captchas for at least a year now. That's why you see captchas that are increasingly hard to read for real people - especially those with vision problems and/or poor-quality displays - and yet the captcha-"protected" sites get spammed anyway.

Using captchas or any other single technological solution is guaranteed to fail. It may slow the spammers down, but it will do so at a significant cost in developer time while diminishing the user experience. You can't win an arms race against an adversary whose single focus is defeating your protective measures, unless you're willing to similarly narrow your own focus.

I stand by my request/recommendation to use a solution such as Akismet. I've used it for about two years now, and I found it to be consistently and impressively good. Unlike Wiki Spot developers, a service like Akismet has a built-in core incentive to remain effective in fighting spam - either they hold their own in the arms race with the spammers, or they die an economic death because it won't be worth paying for their service.

Philip's implementation ideas make sense, for the most part. I would vary it thus:

Non-logged in users always get their edits screened by Akismet.

Logged-in users whose email address has not been verified also get screened.

Logged-in users who have validated their email addresses (register, Wiki Spot sends confirmation email, user clicks on confirmation link) are exempt from screening.

This still won't completely stop the spammers, but it'll do a great job at effectively zero cost without degrading the user experience.


2007-10-17 03:10:07   The time zone should be made obvious - ideally each timestamp would indicate the UTC off-set. —Graham.Freeman

Mobile CSS

okay, my mobile browser is a nintendo ds with the opera browser, it fully supports css stuff, and is totally awesome that way.
Now, I am going to do a bit of testing, but using certain layouts of css the mobile browser is so much better, it would be good if we could include mobile support in our software, only requiring the addition of a css option (mobile.css perhaps), and something like that and perhaps something with image scaling to preserve bandwidth/memory would also be nice, anyway, just throwing that out there. - David Poole

Separating out Users/ links

Maybe a way to separate out Users/ link to userpage when looking at pages like Outgoing Links to see which pages really have subject to subject links and which pages just have a comment signed with a userpage signature link.


Counter to see how many people are visiting a page

Included pages aren't Orphans

It would be a Good Thing if pages that are Included on another page were not listed as Orphans, as they are at present. Mwanner

Incoming Links Macro

The Outgoing Links page claims to be the opposite of the Orphaned Pages page, but a true opposite of Outgoing Links would be a page called "Incoming Links"—which would list all the pages on the wiki, ordered by the number of times that other pages on the same wiki link to them. I would like to have an Incoming Links macro because it would help me determine which pages are likely to be viewed most frequently. Then I could prioritize the most frequently viewed pages for adding photographs or other features to make those pages look better and serve the public better. —queerbychoice

2 or 3 Column FootNote Macro

I'm just getting started, but I know the articles on my wiki are going to have lots of footnotes, and many of them will be quite short, i.e. APA-style citations [e.g. Brown (2004:65)]. If you have 20 or 30 of those kinds of footnotes on one article, scrolling can get a bit tedious. It would be great if there were variable macros to handle this, like [[FootNote2]] for 2 columns, [[FootNote3]] for 3 columns, etc. That would come in pretty handy for me. I'm guessing there might also be a way to accomplish this kind of thing as a default through CSS, but I'm no pro in that department. Any suggestions for possible short-term solutions would be warmly received. Thanks. —Alderman

Collapse and Expand lists

It's good for having lists that can be hidden or shown with one click. Or for simple things like a spoiler paragraph. —exerciciosresolvidos

Better handling of large images

You should be able to upload whatever twelve-megapixel monstrosity comes off your camera and have it sit on the server harmlessly, given that you're probably going to use it as a 'thumbnail' with a height restriction anyway. The server could make a sensibly-sized rescale to show on the ?action=Files&do=view page, along with a link to download the original if you want. Think flickr's "All Sizes". This might start over-inflating wikispot's disk usage though, I guess.

Outgoing Link Protocols

Why do wikis white-list the external linking protocols, e.g. 'http'? Why not to disable all the colors and text fonts besides the most often used? Why not to limit outgoing domain names or other parts of URL? The stupid limitation creates a problem creating the proper reference in IRC article. —ValentinTihhomirov

A stunning alternative to footnotes

Footnotes are great to cite the linked material and elaborate the ideas underlying the main text. Moving the details elsewhere allows to keep the article clean. But, it is tedious to use in the era of hyperlinking. Instead of keeping notes at the bottom, I propose to keep it right behind the referring text. Hovering mouse over the text would pop-up the attached note. Reader even does not need to click anywhere! The print version would display the subtext at usual footnotes. Do you agree? —ValentinTihhomirov

No Re-Submit in the Browser History

It is annoying to get duplicate posts, once you refresh or go "back" after successful post. From my Web Design experience, this can be eliminated by rendering the view page through redirecting user to the "get" page instead of producing the HTML right in the same "post" command to modify. —ValentinTihhomirov

Ability to cover up "Spoiler Text"

Some websites have the functionality to hide text until it is clicked on. For my wiki in particular - which lists potentially distressing events in movies - this would be very helpful. That way, people could read details if they chose but also not be forced to. Any chance?

This is a Wiki Spot wiki. Wiki Spot is a 501(c)3 non-profit organization that helps communities collaborate via wikis.