Feature Requests

Post new features you might like in wikispot here.

Editing & Viewing Changes

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

• Cross-page anchor: It would be nice if there's cross-page anchor. For example, link to the "end" anchor in Help with Linking page using something like ["Help with Linking#end" The end of Help with Linking] or ["Help with Linking"#end Blahblah]. Thanks.
  

• You could link to the page with a URL directly to the anchor, such as [http://www.wikispot.org/Help_with_Linking#end] as a temporary measure. I don't know if its possible otherwise, someone could correct me, though. -KJM * This feature or linking to header would be good JonPatterns

• Make the Interwiki Recent Changes page appear on every wiki spot wiki.
  

• If you use firefox, there's already a solution: see Greasemonkey Scripts for a script that will do just that!
  

  (Friday 3rd Aug '07) I second the Interwiki Recent Changes link request. Greasemonkey is a Firefox add-on, and I've found that Firefox grows less reliable with each add-on. I'd rather not install it just for this one function. -Graham
  

• This clashes with the idea of wiki autonomy. Individual wikis can add a tab that links to the Interwiki Recent Changes if they want to. Personally, I think it would be ill-suited for placement on the Davis Wiki, for example. Maybe there should be some other UI element that points people back to the hub / interwiki rc, but I don't think having a tab is the right idea.

• Make diffs smarter. For example, look at this edit. Deleting a period highlights way more than it should.

• It would be nice if headers actually could be linked to from other pages. This is especially useful for long documents (See ["Friends Urging Campus Kindness Platform"] Of course, this would mean we'd need to get rid of the head-77aee41aea1129a7874c737d037b65ab8d0042a8¹ annoyances as id tags.
  

I agree. —PhilipNeustrom

• As for commenting it would be nice if there was a way to refer to a section of the article and link it aside from creating an anchor point etc, perhaps a macro along the lines of see:($s) where $s is a search phrase that would be run through for the headers, list items, etc. This is probably unnecessary but might be a nice feature if there is enough talk/commentary on a page to justify it.

• I still want [[Image("Example Page":example.png, ...)]] to work, so I don't have to upload an image multiple times. Just sayin'.

Seconded —JasonAller

Thirded. Also, we would like to have a page associated with an image page, that could be used for recording things such as: who took the picture and when, the source of the image, and any other known info about the image. We'll be uploading historical images, and not everything that needs to be recorded with the image belongs in the image caption. —MarcWanner


On a related note (moved from To Do) "on files button allow a "move" and or "copy" function for uploaded files? it would allow moving mystery pictures over to the mystery picture history page without a download and another upload? — maybe next version?"

• Just making sure people know that you can reference an image anywhere by uploading an image to page called for example 'myimagepage'. Then to insert image anywhere [[Include(myimagepage)]] I didn't realise this to begin with. jonpatterns

• When event board listings get added. show the relevant date on the Recent Changes page in addition to the event name.

• The Comments macro should figure out if it is the last item on the page, if it is the first comment should skip the ------. Or, in a better world... the comment macro should put a button on the page. When pressed the button should reload the page in comment mode, which would feature text boxes throughout the page (after each existing comment and one at the end) that could be filled in, and it would format the input as either replies to existing comments or as a new comment?

  The comment bar should width adjust on wider displays to take up more of the page? It is fixed width now, but should be relative to window size? For extra bonus points if the page is less than x pixels wide make the comment bar 2 lines instead of 1?

• I'd like to see the comment tree work more like the pseudo-WYSIWYG mode reached by double-clicking in the page body. But instead of Edit|Cancel, the choice is New Comment|Reply to Comment|Cancel, and the new text box is opened below the double-clicked comment. Then previewing can be added to this mode as well as the existing P-WYSIWYG mode by adding a Preview button to Save|Cancel. The preview can show up as another colored box above the multiline text field. —EricTalevich

• Okay, I took the first step of "making it work more like.." by having it be a small expanding text box, much like how quick edit works. This extra room will hopefully lead to longer comments. —PhilipNeustrom

• If possible set the width on differences (fix the spelling of this in the code too, error shows up in page title) pages of the div that holds the deletions and additions so that it is the same width as the page. Long URLs currently cause this box to go far past the right hand side of the page. Examples include Aggie urls on Steve's page.

I'm not sure how to fix this. Last time I looked into this it seemed impossible to fix. If we could make long areas of text wrap then that'd fix it, but I'm not sure how (or if it's possible, even). I think that the CSS3 word-wrap property is what we need, but no browsers support that right now.. —PhilipNeustrom

Perhaps you could split long strings before printing them to the page? Splits could happen at: . , ?  & - _  This could be done using JavaScript, even.

• Or, optionally: For continuous words of length at least N+K chars, insert a break at the last non-alphanumeric character before N characters, where N is something fixed like 80 chars and K is around 5 to make the next line look reasonable. —EricTalevich

• There should be a confirmation step in the delete page process that shows you all the pages that link to the page that you are trying to delete. The idea being that you wouldn't delete the page until you had fixed all those links first, but that it wouldn't be mandatory to fix those links first.

• Extend the [[Comments]] macro to allow comment expiration. [[Comments(365)]] would display comments on the page for 365 days. This should also generate a link if there are expired comments to "Old comments" or "Comments archive" or something so people would still be able to view them if they like. —Brian Gingold

• Change highlighting: You can see where changes were made in the info view. But it would be really useful to see readable changes since the last time *you* viewed the page faintly highlighted in some color. Currently, changes can be hard to pick out, even in the info view, esp. if the changes were made in the middle of the page. This change would make new changes immediately obvious. Change tracking could use the same technique as recent changes. —IDoNotExist

• Uploading a file: an image/file macro without a file uploaded shows "Upload a file/image.." as it does now, but when clicked — instead of opening a popup window with lots of instructions — will show something like this:
  

• I've noticed that new users often unintentionally do damage to the wiki because they are not aware of wiki norms. To alert them to standard protocol, gnomes create user pages for them, but if the user doesn't know about the Recent Changes tab, I can't imagine how they'd discover that someone is trying to communicate with them. After a user changes a page, can a link come up that says, "Thank you for your contribution. You can view it and other changes in Recent changes." It sounds pretty obvious that someone would check recent changes, but I've spoken to multiple people who've made a few edits that were unaware of it's existence. Such a feature would give new users a better sense of inclusion, and could potentiall prevent embarrassing exchanges. —CraigBrozinsky

• Would the user notification idea (as discussed on this page) solve this issue? Update: user notification is now up and running.

• Under the "User's Info" tab in User page, have a list of the first or last few pages (or both/all) the user created listed. I can see the list getting long for some people (so perhaps have the page link in bold or italics if it was originated by them?), but it would be nice to see what pages users felt strongly enough about that they had to create it. Currently pages —KevinChin

• I'd find it useful if when you paged through "previous edit" and "next edit," that the comment left by the person who made the edit could be displayed (i.e., so you could see the edit and the comment about the edit at the same time). —CovertProfessor

• On Recent changes one other option that would be nice is for every X number of edits to have a "trim" rather than "clear" Recent Changes. That way one can start at the bottom of recent changes and work their way up, trimming some off, but still using refresh to see new changes. This is only an issue when there are many edits per day on a wiki. —JasonAller

• Make previewing show the diff of the changes to help in formulating good change comments —Users/ JoeWells

• When a page is used as an include it shouldn't show up on the Orphaned Pages list, and every page that includes it should be listed on the info/links section as either an include link, or a link to the page.

Adding an auto wiki link button when editing a page

I would like a button just to the left of the B which adds [" and "] to the highlighted text in the edit box.


Turning for example: A Page in The Wiki into ["A Page in The Wiki"].

By pressing something like the E Button pictured here:




—HimySyed

• How about adding gopher support for viewing the wiki? —BrentLaabs

User metadata, registration, and authentication

• (26 Sep 07) Allow default security settings to be specified within template files

• (3 Aug 07) OpenID support. At least Relying Party, but maybe even Identity Provider if/when we feel very good about our stability and security. —Graham
  

• Can you / anybody else take a stab at proposing a UI here? This is a big deal, as user authentication is already confusing for some people. How could we add in support for a separate authentication method without both cluttering and confusing our existing UI?

• Rather than only reporting the cumulative statistics for a user account, it might be useful to also see weekly statistics (can be pulled from recent changes) to watch user activity, this could be fun and useful for community buildingness.
  

• Disabling accounts should be harder to do accidentally. Have a confirm page for "Disable this account permanently." Have a button [ Disable ] with two checkboxes: [] (confirm) [] (seriously). And even then, perhaps there should be a way to reactivate within 30 days with username/password, as for deleted wikis.

• (3 Aug 07) I'd like it if the User Statistics macro could be extended to specify a given wiki. It'd be cool to have my Davis Wiki, Santa Cruz Wiki, and Wiki Spot edit stats all on my main userpage. -Graham

• The new user page only says "Name." Hence users like Lauren and Jessica. I guess this problem will solve itself once enough people sign up, should we be mentioning the FirstLast convention used on dwiki?—ArlenAbraham

• What should it say? "Real name?" "Full name?" It doesn't allow spaces, so we have to be somewhat specific here. Suggest a wording and I'll throw it up. "Full Name (No spaces. Please do not use nickname or business name.)" ? Brevity is very important here.

• (3 Aug 07) I suggest the following two lines (note the link):
  

Your Real Name


Example: Firstname.Lastname (Please do not use a nickname or organization name.)

• (23 Apr 08) I second the above suggestion. With just "Name", people may just add Firstname Lastname. It should be clear that this is a "username" that will be publically displayed. In the login boxe at the top of the page it's called "User name" but on the registration form it's called "Name". That can be a bit confusing. The text (Please do not use nickname or business name) should be hyperlinked to the Importance of Using Your Real Name page so people can see what is expected of them. Another option is to add more "helper" text to the right sidebox on the registration form that shows info on the wiki community that the person is trying to register for. In that blue box could be info like "your password should be over 5 characters in length" and "please use your real first and last name with no spaces (ie. JohnSmith or John.Smith) - see why" Email authentication is important too. —RodneyBlackwell

• (15 Aug 07) I would prefer two name boxes. The first one asks for the person's first name, the second box asks for the person's last name. Regardless of upper or lowercase entered by the new user, the first initial in both names could then automagically be capitalized. For instance, FiRSt name LAst name becomes FirstLast as a username. The person can then accept or modify the proposed username. Also, what do I tell people who have already registered using just their first name and created pages and begun active editing...? Do we tell them to re-register with a new FirstLast like username? If so, why did we permit the original first-name-only username in the first place? Also, I don't think numbers should be in usernames. —HimySyed

• (3 Aug 07) I think the new user registration process should include mandatory email address confirmation. I think this would help cut down on trolling and abusive editing. It'd also lesson the support load with regard to users who forget their passwords but never used a valid email address in the first place. -Graham

• It would be great if the wiki could direct a user to a specific page (other than the front page) upon login. Also, a useful feature would be tags that allow part of a page to be invisible to guests, but visible to logged-in users (or specific groups). Perhaps these features exist as macros or something, but I've been unable to locate them.

• New account creation: redirect back to home wiki after account is created: the main reason we don't outright redirect back is because of another usability issue: letting people know that there /are/ settings for their account and they can change them. Things like timezone and remembering your login are good to set.

  I think it might be best to just display that information /on/ the home wiki, in a similar message. That way if they don't read the message it's no big deal. If they read it then they can figure out what the hub is and that they can change their settings. Something like:

  "Welcome, PeopleHeartsPeople! We made your account and you're logged in now.

  Want to [change your account settings?]."

  The issue still comes up when they go into the settings area for general stuff, though. We could redirect back to the home wiki as soon as they press "save", but then it's confusing because they don't see on-screen confirmation that their settings "went through".

  So, I think it'd be best to do this for the new account stuff. These are people who are completely unfamilar with the system, so they need to be given direction that they can't mess up. Someone who's interested in "changing their user settings" is probably someone who's going to take time to read dialogs more carefully, and is not as liable to get confused because they've already had some time to get used to the way the UI works.

Wiki structure/organization

• Chronological lists of pages for page creation, and last edit/update, this would be nice for reviewing when pages should be looked at etc. E.g. what "abandoned pages" was.

• In thinking about the logistics of southern Californian urban sprawl and localized wikis, two things come to mind. Firstly, the use of interwiki include() macros, which are a big security deal and kinda complicated probably, and the organization of wikis into groups to allow limited interwiki searching, ergo to search within the OC wikis only.

Interwiki includes are left out intentionally for a couple of reasons which you may have thought of: wiki autonomy as well as implementation headaches. If it's highly requested down the line then we should do something about it. I'm interested about your 'grouped search' idea, and it wouldn't be hard to add support for that. Can you give a bit more detail of what you're thinking of in terms of the OC? I'm imagining a sort of umbrella OC wiki that has a search box searching all oc-associated wikis, and the individual wikis are each run by different groups of people? How about if the "Search all Wikis" box, after doing a search, had a toggle to "narrow search to my watched wikis?"

Indeed interwiki includes could be a pain, though it may be beneficial to make a more interlinked wiki community(ergo davis denny's including the entry on dining's denny's, but this is what links are for!), but that is not terribly necessary, really it's quite the opposite. However, are umbrella wiki's possible which include other wikis? I think it would be beneficail if you could add a search bar that searched a set list of wikis rather than simply all of them, thus removing the need for users to watch wikis and the like (I assume people are lazy, and might not take notice if a new wiki just pops up), also it would be just a nice feature, perhaps a macro or something of the like.

• So currently this is done with [[search(global)]]. I think you're suggesting that would search only particular wikis, such as [[search(davis, roc, beer]]. This would be hot if it worked. Each community might have a different view of each page. For instance, a Davisite's view of Java California might be quite different than a Dixonian's view. So I could see wanting different pages — interwiki redirects might just be an excuse not to develop new content. -bl
  

• Hmm I guess this all will work, though it will lead to redundant articles. However, n this case it is rather a bit annoying as it would force someone to search muliple wiki's by hand if they didn't know which community wiki has the claim to the article (though admittedly this is only a problem when people are lazy), I suppose the solutions are to either rely upon gnomes, or create a massive wiki for the larger community instead of the smaller, which then gets a bit frizzy. Will tags on articles be implemented having that sorting feature may be a bit useful.
  

• Another searching idea, suggested by Users/JamesSchwab is that we should have interwiki search in the title bar along with the local wiki search. I took the liberty of making an image mockup of what it would look like:
  

• 

• The idea is that this search would be the "Search all wikis" search that's found on the front page of the hub?

• Wanted Pages should pick up interwiki links? Or interwiki links should check to see if they need to be formatted as wanted links?
  

• The process of creating a wiki needs to capture the reason for creating the wiki and put it somewhere automatically on the new wiki, perhaps even on the front page. Looking at Recent Wikis it is hard to identify a purpose or scope for some of the wikis that appear to have had no edits made since they were created.
  

• Orphaned pages shouldn't list pages that have been [[include( )]] ed on other pages.

• Talk pages should be generated from a template that individual wikis can set. Wiki Settings/Talk Template or something like it. This will allow them to decide if they want to include the comment macro, and if they want a link to a common page that can then use the linkshere macro to list all existing talk page.

Mapping

• The address macro needs to have an element that draws that attention up to the presence of the map button, or provides another element that performs the same action located either before or after the text of the address?

• Ability to use macro like address to point to lat long coordinates. Useful for non-address locations on wikis like hiking, geocacheing, fishing, etc.

• Add functionality to the map feature to allow a map to be placed in a page similar to an image, and add functionality. [[map("scope link",[menu/float],[right/center/left],[size in px or %],map title,caption text, etc?)]]

I agree, this is something I have been thinking about for while. Having the map tied to the title_table seems out of place. What if I want to put a map way down here (200 Cortland, San Francisco, CA, 94110)? I have to scroll back up to the top? Also, let's throw in "all points on the wiki" into this feature request, too.

• Add [[ShowMap]] to distinguish from the act of plotting with [[address()]]. Possibly add a scope=link option to specify the scope of the address plots.

• Allow a default map zoom level to be set within the address macro. Good if the page uses two (or more) addresses; the editor could set zoom level to make sure all locations are visible upon loading. The map currently focuses on the first address listed with a radius of roughly half a mile.
  

• I concur - this would be a very useful feature for larger cities. -KJM

• Ability to have separate buttons for each instance of the address macro used on an entry. An example where this would be needed is Fry's Electronics, where both the Sacramento and Roseville addresses use the macro, but when you hit the "map" button, it shows the Roseville map only. In this example, the previous suggestion about the map's zoom level does not work because Sacramento and Roseville are 2 separate cities each covering a very large mappable area. - Paul Amnuaypayoat

• Tag map markers with a name other than the page's name. "Currently map markers are linked to text with the page the macro is placed on. This works well for pages dedicated to a business, but for a page with a list of business, there is no way to distinguish between businesses on the map.

• It would be better to be able to have a map show up automatically without requiring the user to first click the Map button.

• It would be better to be able to have a map show up already configured to have a satellite picture overlaid (if the mapping service supports this).

• The current support for Google Maps does not allow configuring the font used in the balloon text inside the maps. As a result, the user's default font is used for the balloon text and various display problems result when the user's default font is big. One problem is that if the balloon is too large to fit in the map view pane, Google's JavaScript scrolls the map pane to center the balloon.
  

  Fixing this requires the ability to set CSS for the iframe used to display the map. The CSS style sheets used for the wiki pages have no effect on the embedded iframe, and there is no support for getting any CSS (or HTML) added to the embedded iframe. Possibly an additional CSS style sheet is needed just for such iframe elements.
  

  For an example of the problems, see a screenshot. Notice that the green arrow and red balloon have almost scrolled out of the map view pane. When the map comes up, they are in the center, but then get scrolled to the edge as the balloon pops up. Notice also that the balloon text is too big to fit in the map view pane.

• It would be better to be able to have the balloon text not show up automatically, but instead only show up after a marker in the map is clicked by the user. (This used to be the case, but the Changelog indicates that on 2007-08-07 a “fix” was added to automatically pop the balloon up by simulating a user click.)

• It would be better if the size of the map pane could be adjusted.

• It would be better to be able to have multiple maps on a wiki page.

• It would be better to display a nice message to the user when JavaScript is disabled and they try to use the map. See the bug report “Map button fails silently with no explanation to the user when JavaScript is disabled”.

• There is a bug where the cached computed map details on other pages are not flushed when a page they depend on is edited. (I don't remember the details. The workaround was always to do a dummy edit on the other page to force recomputation of the map details.)

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.

Events

• (26 Sep 07) Ability to alter the text within the "Events" macro to arbitrary strings i.e. "Post a new event:" to "Post a new repair:"

• (26 Sep 07) Allow for event pages where the event is added on one page and displayed on a separate page i.e. There could be a page for "Adding A Repair" where a user could request a repair/alteration but that list of alterations would be on: "Pending Alterations" for example.

• (26 Sep 07) Allow for multiple separate event pages i.e. Cheese Eating Events would not have the same contents as Wine Drinking Events etc...

• (suggested at the davis Wiki BBQ Summer 2007): increasing the font size of the event title so it's easy to see where one event ends and the other begins.
  

• (suggested at the davis Wiki BBQ Summer 2007): making thumbnails for images so they don't come out huge and disrupt the flow of the page.
  

• Automagically Recycle/Re-use expired events listings into a timeline page or history page listing of all past public events.

• We hope to build up our city wiki on a neighbourhood by neighbourhood basis. Can there be more than the current single page of all events listing and macro? Right now it is a catch all, perhaps [[Event]] could remain, and [[Event(Neighbourhood Name, or Sports, or whatever category)]] could list their own category specific events which also feed into the All Events listing? A checkbox of available events categories could be alongside the Add Events box, and submissions can be ticked off in any of the applicable events listing.... — HimySyed

• Duplicate the functionality of Events. Create something very much like upcoming.org's event listings before Yahoo took them over. Each event listing should effectively be a landing page for each event, a comment board, and a list of yeses and maybes from wiki community members to say whether they'll be attending. The main difference being the way user profiles matter. For Upcoming.org it's all about the events you've gone to or are going to, whereas WikiSpot user profiles centre around reviews and perhaps lists of favourite places and local community building. —HimySyed

• A macro that will allow pages to populate links to the events page automatically. [[Event("Date Time", length)]] would cause a listing that would link back to the page that had the event macro. The "Date Time" would either allow specific one time entries, or repeating schedules. 2007-02-28 18:00 or 2nd Sunday of the month 9:00.

• Consider Event Tags. It would allow the events board to be filtered and searched by tags. Useful for very diverse communities. Separate out concerts from sporting events and audience things from participatory things? Modify the [[Event]] macro to allow tags like [[Event("2nd Sunday of the month 9:00", "6 hours", "Shooting, Solano Targetmasters, Yolo Sportsman's Association, USPSA")]]
  

• Even better to expand this to include the ability to make a calendar via macro..

Misc

• Ability to add a "Contact Form" allowing for text to be sent via a simple form on the wiki to a specified email address.

• On a wiki specific basis is there a way to edit the default behavior for a newly created page when the user doesn't select a template? I'd like the option to have all new pages include the stub macro for instance.

This seems like a pretty cool idea.

• Maybe some kind of macro that lists the children of a page. Something like [[SubPages(Wiki Settings)]] would print out ./CSS, ./Security, etc.

• (Export doesn't exist yet. This is a note relevant for later on.) On a deleted wiki, provide a link to download an export of the deleted wiki for a temporary period of time, or something to that effect. —Rob Roy

• Macro that can be used in the Quick Wiki Tips page that will pick a random wanted page and present it to the user: "pagename is a wanted page, if you know about it, why don't you create the page?" Maybe [[RandomWantedPage]]?
  

• I like this idea. A lot. —RyanMikulovsky
  

• Ability to edit the default formatting of comments, and a macro to display the number of page edits for a user, sorta goes together. ~Dave

• In Wiki Settings/Images display the logo twice over a black rectangle and a white rectangle. That way if an image is white with a transparent background, or black on a black background, you'll be able to see it. At the very least put a border around it so you know something's really there. —Brian Gingold

• Make [[Include()]] behave the same way [[IncludePages()]] does for nonexistent pages. If an included page doesn't exist, display nothing, rather than displaying the title and no content.

• I would like to see a link on the top of every page (maybe under the username) that allows you to navigate back to the Interwiki, or the wiki directory. When I am on the DavisWiki, for example, and I follow a link to the SacramentoWiki, I find it troublesome in navigating back to the DavisWiki without using my back button, or going thru several pages, or using a bookmark. I know what I am doing, but someone who doesn't use the web that much might find it easier to get around with a top-level link.
  

• Another possible way around this is to allow your wiki bookmarks to persist across sites. For example, I can see all of my bookmarks while on the InterWiki, but I can only see my DavisWiki bookmarks while I am on a DavisWiki page.

• Suggestion. Change "No recent changes. Quick — change something while nobody's looking!" to "There are no recent changes, why don't you see if random page needs an edit?"

• When someone is not logged in, and they enter a non-existent page name, they still get to the 'create this page' screen with the list of templates, and then when they try to create the page, they see what can be construed as a rude message "You are not allowed to edit this page." Where/How can I change this message to something friendlier like "You can edit this page once logged in....click here to log in..." something like that.
  

—HimySyed

This is a good suggestion. This is pretty easy to add. What we can do is just give people different messages depending on what they can do if they're logged in. For instance, we can say "You can edit this page once logged in....click here to log in.." if they can edit the page when they're logged in, and "You aren't allowed to edit this page..sorry!" when they can't edit it even if they were logged in. The current message isn't friendly because it doesn't give the person a clue that they can edit the page — they just have to create an account! —PhilipNeustrom

• User page defaults: There needs to be a quick way to check whether a negative commenter is a one *it wonder, or has left at least one balanced view hither and thither. When a new user signs up for an account, can that wiki automatically create an alias page that points to their user info page? That way, people can instantly check out anyone who's left a comment somewhere. To ensure that a real userpage ultimately gets created, the userinfo page could include a "user doesn't have a page yet— please create one!" type of link. When the link gets clicked, an actual page can overwrite the link. Such a system has another advantage— it would obviate the need all the gnome created "UserX likes salamanders" types of pages.
  

• Also, with increasing cross-wiki traffic (daviswiki users making sacwiki edits and vice-versa), it would be nice if our userpages persisted regardless of what wiki we are editing. Currently, if you make sacwiki edits as a daviswiki user (and don't have your profile pointed to a wikispot user page) your sacwiki edits will point to a blank sacwiki userpage. I heard about a suggestion for a "home wiki" which could be set via settings, this would be great! Also, new users should could have their "home wiki" setting defaulted to the wiki they register their account with (someone who creates their account from the daviswiki will have the daviswiki set as their home wiki). —VladLoscutoff

more on this:

I love the idea that wikispot allows for community cross-over (ie. what is currently happening between SacWiki and DavisWiki). However, the way our user accounts work doesn't led itself to this. Having started on DavisWiki I created my profile there, but when I started making SacWiki edits I noticed that my profile was gone (it's a new account on SacWiki). Shouldn't my profile follow me regardless of the community (wiki) I'm in, as long as I'm in wikispot? I'm tempted to try making my SacWiki profile redirect to my DavisWiki profile, but that seems rather hacky. —VladLoscutoff

This should be more intuitive, and we've been thinking of ways to make it more obvious. There's some discussion about things related to this on the Feature Requests page. You can set a "home" wiki in your settings, though. Then your name will link to that wiki no matter where you edit from. Did you know you could do that? Do you think that a "home wiki" should be set by default if the person only has a page on one wiki? If that was the way things worked, do you think people could figure out how to make a page on a different wiki for themselves?

CraigB comments on the Feature Requests page that he thinks when people don't have a profile page that we ought to show something different (not the normal "Empty page, create this page" message). He suggested just showing the "User Info" area. Maybe we could show something like:

"This person hasn't created a profile on this wiki yet — please create one (link).

<Name> has profiles on the following wikis: <list of things>. <normal user info area below this>"

This way there'd be an easy way to see information on people when they edit elsewhere without them having to do anything special, and people would be able to set a "home wiki" as well as create profiles on a variety of wikis if they want to. —PhilipNeustrom

Update: this is now implemented. How does it do? Let's try it out for a bit and see if it helps..I think it will. —PhilipNeustrom

• Could we have a move-page functionality, just noting the number of folk creating a page on one wiki that they want on another, perhaps we should have it backwards and have an import page function? I dunno, just an idea given the recent wiki development.

• Can we please have a way to communicate metadata to search engines? There are two specific mechanisms that it would be good to provide access to:
  

• It would be good to be able to set the keywords and description for each page. This is done by adding meta elements as children of the head element of the page. The XHTML inserted in head would look like this:

  <meta name="keywords" content="xyzzy, foo, blarg, bang" /> 
  
  <meta name="description" content="The xyzzy wiki is about foo blarg bang." />

  
  

  Adjusting the content attribute of these elements for a page could be done with macro uses like [[keywords(xyzzy, foo, blarg, bang)]] and [[description(The xyzzy wiki is about foo blarg bang.)]].
  

• It would be good to be able to specify a sitemap. This needs two things. First, one must add this line to the robots.txt file:

  
  Sitemap: sitemap.xml

  
  

  Second, one must then provide the sitemap.xml file in the standard format. These look like this example:

  <?xml version="1.0" encoding="UTF-8"?> 
  
  <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  
   <url>
  
    <loc>http://WIKINAME.wikispot.org/</loc>
  
    <lastmod>2008-07-20</lastmod>
  
    <changefreq>monthly</changefreq>
  
    <priority>0.8</priority>
  
   </url>
  
  </urlset>

  
  

  I suppose the sitemap.xml file could be an uploaded file on the Wiki_Settings/General page.

---

• Wiki Admins: Ability to toggle display of logged-in user's IP addresses. Some wikis want to show the IP of every user, some don't.
  

• Would this back propagate to the InterWiki Recent Changes page as well?

• Option in Wiki Settings to change the default "front page"

Minor CSS/Stylistic requests

Heyo, okay, I was thinking that it would be awesome to have the ability to have first and second tr classes incoperated into the wiki-tables, though I can currently make the first child a different color, I rather have the ability to easily set two colors for alternating table rows, and have this feature apply to all tables created, including the userstats one, etc. not important, just nice for later on, by css inheritance rules the color written in later should be dominant to the css. ~Dave

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...

• This can be accomplished using tables.. they are amazing.

• Using pseudo class tr:nth-child(2n+1) and tr:nth-child(2n+0) can make alternately colored table rows - but not for IE 8, maybe 9?

Adding an RSS button to each page

• Along the top bar of every page, we see the buttons: Edit Info Talk and sometimes Map.
  

• I think it should already be possible to create an RSS button for any page.

  The RSS would be a feed for any recent changes on that page. It would be optional, similar to how the Map button only appears if there is a properly formatted address macro on the page.
  

  The reasons for doing this is so people can pull in wiki page changes onto their blog feeds and news readers etc.
  

  Also, combined with the existing comment macro, each wiki page itself does become a single page / single entry blog, kinda sorta. Allowing an xml rss feed to easily be bookmarked, allows regular blogs to see that wiki page.
  

  What Think? —HimySyed

Well, we don't show an icon for RSS (because there's not a great place to put it), but every page does have an RSS feed. Most (all?) of the modern web browsers detect this RSS link and will do something "special" to indicate that the page has a feed available. For instance, here's what firefox does: .

Clicking that icon will give you the feed (or the URL to it). It's similar in Safari and Opera. I don't know what IE does, though (I suspect similar?) —PhilipNeustrom

Edit Comments For Mini-Editor

This!

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

[[YouTube(WB1_RSNJjDM)]]

<object width="425" height="350"><param name="movie" value="http://www.youtube.com/v/WB1_RSNJjDM"></param><param name="wmode" value="transparent"></param><embed src="http://www.youtube.com/v/WB1_RSNJjDM" type="application/x-shockwave-flash" wmode="transparent" width="425" height="350"></embed></object>

Maybe [[Revver()]] or others?

• Is this a feature yet? I would love the ability to add YouTube videos like the above tag. —RodneyBlackwell

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)]].

• I would completely support this request. I am currently changing from a MoinMoin wiki to Wiki Spot and the Moin Gallery (macro), Gallery2 (parser) and Slideshow (action) have all been used. Could something similar to the Moin Gallery (macro) be made available as it would be of considerable help to me and I believe a number of others. - Tony Finnis

Rename User account

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

This will have to be done by a system-admin. Letting people rename their own accounts is..hectic to say the least.

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
Enjoy.

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:

• captcha on user account creation.
  

• captcha on all non-logged-in edits.
  

• ui — in editor it's easy: just redirect to captcha on "save", then save page as normal.
  

• ui — in revert (page): embed captcha in "really revert? reason:"
  

• ui — in delete (page): embed captcha in "really delete? reason:"
  

• ui — quickedit — redirect to captcha on save — then save page as normal.
  

• ui — file uploading screen: when not logged in, don't POST the file content — instead redirect to captcaha — then back to file screen with the stuff we want.
  

• ui — file delete: captcha on "really delete..."
  

• ui — file revert: captcha on "really revert..."

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.

—Graham.Freeman

Portals

• My wiki goals are a little different from everyone else I think, as one of my projects is intended to help people learn about genetics - and I have noticed that for certain subject areas in Wikipedia, that they will have handy "Portals" on the right hand side of the page. See the Wikipedia page on Mutation to see what I mean. I suppose that I could create portal-type pages and insert them in as includes in a cell of a table (without borders so as to make it invisible), however, when you navigate the wikipedia portals they show what page you are on within the subject area. Would something like this be easy to create, or involve too much background work? If there is an alternate solution that someone could suggest, I'm all eyes! - KJM

This kind of thing can be achieved using an include macro. You can make a "portal" page and include it on the relevant pages. The "what page you are on" can be achieved by just linking to the page names — links to the current page don't render as links, so the effect should be the same². Putting things in a table would allow you to provide colors and CSS styles (using the tableclass="namehere" attribute and adding something to your style.css file). If we added the ability to give provide a CSS class to an included page you could style it directly, too — but that isn't possible at the moment.


Thanks much! I seem to have a knack for finding little bugs as I test out the site's capabilities. When I make my first portals for the DNA Wiki, I'll make a how-to in the macros help page. -KJM

---

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

• Very minor side note... the site looks good on a Palm TX (I was at Staples the other day and poked at dwiki and the hub with it) —jw

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

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

• Most linked doesn't really mean the most viewed. You're basically looking for a sitewide [[linkshere]] that works like [[WantedPages]]?

• Yes, something like that. Most viewed would be a useful page to have too, but I thought most linked would be easier to generate and much better than having neither. —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

• CSS is the way to do it, IMO. You can easily set the footnotes to have a given width, which means that if you have your browser set wide, they will have several columns, or if it's narrow, they drop to just a few columns. You can also simply "tighten up" the vertical spacing of the footnotes and/or drop the font size, so that the block of footnotes is smaller. I can't help you until this weekend (I don't know the footnote classes off the top of my head, and I'm guessing you pretty much need a tested solution rather than just a bit of direction), but anybody familiar with CSS can give you a working solution. —Evan 'JabberWokky' Edwards
  

• Thanks for the quick reply. I'm guessing the change has to be made in the common.css file. I figured out how to change the width of the list (50%, for example), but can't seem to get the content to wrap around in two columns. Before I screw something up, I think I'll just wait until you can spare some time. :) Thanks again! —[Alderman]
  

• I've found a (IMO) decent temporary workaround for this, in case anyone is interested. Feel free to contact me for details. —[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

Stunning alternative my ass! Anything that uses onHover or relies on tool tips is evil, evil, evil. You're assuming people have cursors. That's a bad assumption in an era where more and more people access the internet through mobile devices. Most of these devices are touch-based or keypad-based. There is no hover! You'd be locking people out of content. Sure, some editors may want to use such functionality. That doesn't mean they aren't wrong to do so. —WilliamLewis


I did not consider that indeed and, I am not aware of web support for cursor presence identification. Nevertheless, is it ok to call some functionality "evil" just because you cannot exploit it? If we have normal and printed versions of pages, why not to have the intermediate, mobile one or "expand footnotes" button :)? Will it make things to complex? It is much easier to implement than I thought - <a> tags have "title" attribute that is designed for this functionality! —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

Can you give a more detailed example - I'm not quite sure what you mean? —jonpatterns


I think he's upset that his web browser is causing duplicate posts when he's using the back button and the browser submits a form again. Meh. —WilliamLewis


Exactly! http://en.wikipedia.org/wiki/Post/Redirect/Get —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?
— emilymonaghan

A work around is to use text the same colour as the background - views must highlight text to be able to see

the text ; -)

—jonpatterns