Recent Changes for "Feature Requests" - Wiki Spot

Feature Requests

exerciciosresolvidos — 2009-09-13 04:14:59

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 425:	Line 425:
	+ + ==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. --["Users/exerciciosresolvidos"]

Feature Requests

Alderman — 2009-09-09 20:27:34

(quick edit)

Differences for Feature Requests

No differences found!

Feature Requests

Alderman — 2009-09-09 20:06:00

(quick edit)

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 424:	Line 424:
- * 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! --[[Users/Alderman]]	+ * 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! --[["Users/Alderman"]]

Feature Requests

Alderman — 2009-09-09 20:05:42

(quick edit)

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 424:	Line 424:
	+ * 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! --[[Users/Alderman]]

Feature Requests

JabberWokky — 2009-09-09 17:09:58

Quick, dashed off reply.

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 423:	Line 423:
	+ * 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. --[wiki:gnome:]["Users/JabberWokky" Evan 'JabberWokky' Edwards]

Feature Requests

Alderman — 2009-09-09 16:57:35

2 or 3 Column FootNote Macro Request

Differences for Feature Requests

No differences found!

Feature Requests

Alderman — 2009-09-09 16:54:58

2 or 3 Column FootNote Macro Request

Differences for Feature Requests

No differences found!

Feature Requests

Alderman — 2009-09-09 16:50:52

2 or 3 Column FootNote Macro Request

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 419:	Line 419:
	+ + ==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. --["Users/Alderman"]

Feature Requests

queerbychoice — 2009-06-12 00:48:19

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 417:	Line 417:
	+ + * 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. --["Users/queerbychoice"]

Feature Requests

JabberWokky — 2009-06-09 19:39:21

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 415:	Line 415:
	+ + * Most linked doesn't really mean the most viewed. You're basically looking for a sitewide {{{[[linkshere]]}}} that works like {{{[[WantedPages]]}}}?

Feature Requests

queerbychoice — 2009-06-09 19:11:05

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 412:	Line 412:
	+ + ==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. --["Users/queerbychoice"]

Feature Requests

TonyFinnis — 2009-03-23 02:11:54

Differences for Feature Requests

No differences found!

Feature Requests

TonyFinnis — 2009-03-23 00:17:58

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 316:	Line 316:
	+ * 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 +

Feature Requests

RyanMikulovsky — 2009-03-14 17:05:42

I like a certain feature request.

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 212:	Line 212:
-	+ * ''I like this idea. A lot.'' --["Users/RyanMikulovsky"]

Feature Requests

BrentLaabs — 2009-03-11 08:32:57

new request

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 78:	Line 78:
	+ + * How about adding {{{gopher}}} support for viewing the wiki? --["Users/BrentLaabs"]

Feature Requests

Mwanner — 2009-02-20 19:48:30

Differences for Feature Requests

No differences found!

Feature Requests

Mwanner — 2009-02-20 15:21:44

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 405:	Line 405:
	+ + ==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. ["Users/Mwanner"]

Feature Requests

JasonAller — 2009-02-01 18:27:31

Photo gallery macro? When I get coding maybe I'll tackle this

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 310:	Line 310:
	+ ==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)]]}}}. +

Feature Requests

IDoNotExist — 2009-01-25 07:36:52

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 50:	Line 50:
- * 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.	+ * 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. --["Users/IDoNotExist"]

Feature Requests

IDoNotExist — 2009-01-25 07:36:21

In page change highlighting

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 49:	Line 49:
	+ + * 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.

Feature Requests

Mwanner — 2009-01-16 16:35:21

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 25:	Line 25:
- * 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.	+ 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. --["Users/Mwanner" MarcWanner]

Feature Requests

Mwanner — 2009-01-16 16:33:29

(quick edit)

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 24:	Line 24:
	+ + * 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.

Feature Requests

JasonAller — 2009-01-09 06:49:17

This should be a priority, along with fixing the stats bug!

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 131:	Line 131:
	+ + * 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.

Feature Requests

JasonAller — 2008-12-26 01:51:33

(quick edit)

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 60:	Line 60:
	+ + * 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.

Feature Requests

JoeWells — 2008-09-21 09:39:19

add all my mapping suggestions already discussed on the FAQ page

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 146:	Line 146:
- 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. -	+ * 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 [wiki:wheatfield-backgreen:"Map Problem Report" 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.

Feature Requests

PhilipNeustrom — 2008-08-24 04:34:43

admin contact feature

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 289:	Line 289:
	+ == 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. +

Feature Requests

JoeWells — 2008-08-18 11:36:07

(quick edit)

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 58:	Line 58:
	+ + * Make previewing show the diff of the changes to help in formulating good change comments --["Users/ JoeWells"]

Feature Requests

JoeWells — 2008-08-18 11:35:05

Revert to version 199 (oops, accidentally replaced a previous feature request).

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 57:	Line 57:
- * Make previewing show the diff of the changes to help in formulating good change comments --["Users/JoeWells"]	+ * 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. --["Users/JasonAller"]

Feature Requests

JoeWells — 2008-08-18 10:24:38

(quick edit)

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 57:	Line 57:
- * 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. --["Users/JasonAller"]	+ * Make previewing show the diff of the changes to help in formulating good change comments --["Users/JoeWells"]

Feature Requests

2008-08-10 03:25:00

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 366:	Line 366:
	+ + == Counter == + Counter to see how many people are visiting a page

Feature Requests

PhilipNeustrom — 2008-08-06 19:50:12

added from jw's page

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 309:	Line 309:
	+ ----- + 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. +

Feature Requests

JoeWells — 2008-07-21 17:09:43

(quick edit)

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 222:	Line 222:
- The ability to adjust the {{{content}}} attribute of these elements could be added to the {{{Wiki_Settings/General}}} page.	+ 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.)]]}}}.

Feature Requests

JoeWells — 2008-07-21 16:55:00

(quick edit)

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 218:	Line 218:
	+ + * 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." />}}} + The ability to adjust the {{{content}}} attribute of these elements could be added to the {{{Wiki_Settings/General}}} page. + * It would be good to be able to specify a [http://www.sitemaps.org/protocol.php 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.

Feature Requests

JasonAller — 2008-07-06 16:55:38

Users/ links and the ["Outgoing Links"] page

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 342:	Line 342:
- ------	+ + == 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.

Feature Requests

PeterHogg — 2008-05-26 20:31:46

moved to sycamore website

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 343:	Line 343:
- - ==Code Formatting== - Some markup to turn on formatting/coloring for different programming languages would be useful, like the <source lang="python"> tag in Wikimedia. ~iomesus

Feature Requests

WilliamLewis — 2008-05-25 21:42:32

(quick edit)

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 332:	Line 332:
- Thanks much! I seem to have a knack for fincodeding little bugs as I test out the site's capabilities. When I make my first portals for the [wiki:dnawiki DNA Wiki], I'll make a how-to in the macros help page. -KJM	+ 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 [wiki:dnawiki DNA Wiki], I'll make a how-to in the macros help page. -KJM

Feature Requests

2008-05-25 21:04:21

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 332:	Line 332:
- 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 [wiki:dnawiki DNA Wiki], I'll make a how-to in the macros help page. -KJM	+ Thanks much! I seem to have a knack for fincodeding little bugs as I test out the site's capabilities. When I make my first portals for the [wiki:dnawiki DNA Wiki], I'll make a how-to in the macros help page. -KJM
Line 343:	Line 343:
	+ + ==Code Formatting== + Some markup to turn on formatting/coloring for different programming languages would be useful, like the <source lang="python"> tag in Wikimedia. ~iomesus

Feature Requests

RodneyBlackwell — 2008-04-23 17:25:00

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 84:	Line 84:
	+
Line 85:	Line 86:
	+
Line 88:	Line 90:
	+ + * (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) - ["Importance of Using Your Real Name" see why]" Email authentication is important too. --["Users/RodneyBlackwell"]
Line 257:	Line 261:
	+ + * Is this a feature yet? I would love the ability to add YouTube videos like the above tag. --["Users/RodneyBlackwell"]

Feature Requests

Vijay — 2008-03-03 21:18:28

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 139:	Line 139:
	+ + 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. +

Feature Requests

PhilipNeustrom — 2008-02-03 00:23:29

(quick edit)

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 12:	Line 12:
- * 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.	+ * 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.

Feature Requests

PaulAmnuaypayoat — 2007-12-02 06:34:44

added request for multiple map buttons

Differences for Feature Requests

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

Feature Requests

PhilipNeustrom — 2007-11-08 20:56:12

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 7:	Line 7:
- * 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.	+ * 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.

Feature Requests

PhilipNeustrom — 2007-11-08 20:55:59

link format incorrect

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 7:	Line 7:
- * 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.	+ * 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.

Feature Requests

Graham.Freeman — 2007-10-22 11:22:34

(quick edit)

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 298:	Line 298:
	+ ---- +

Feature Requests

KarlMogel — 2007-10-21 07:09:52

temp. solution

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 8:	Line 8:
-	+ * 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. -["Users/KarlMogel" KJM]

Feature Requests

andor — 2007-10-21 05:36:50

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 6:	Line 6:
	+ + * 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.

Feature Requests

JabberWokky — 2007-10-19 14:54:27

(quick edit)

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 326:	Line 326:
	+ * ''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

Feature Requests

Graham.Freeman — 2007-10-19 07:41:37

threading my response to Philip's spam plan

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 296:	Line 296:
	+ ''2007-10-19 07:40:12'' [[nbsp]] 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. + --["Users/Graham.Freeman"] +
Line 304:	Line 321:
	+ ------ +
Line 308:	Line 327:
- ''2007-10-19 07:40:12'' [[nbsp]] 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. - --["Users/Graham.Freeman"]

Feature Requests

Graham.Freeman — 2007-10-19 07:40:12

Comment added.

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 307:	Line 307:
	+ ------ + ''2007-10-19 07:40:12'' [[nbsp]] 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. + --["Users/Graham.Freeman"]

Feature Requests

Graham.Freeman — 2007-10-19 07:18:54

fixing my comment; attribution on David's

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 302:	Line 302:
- ''2007-10-17 03:10:07'' [[nbsp]] The time zone should be made obvious - ideally each timestamp would indicate the UTC off-set. --["Users/Graham.Freeman"	+ ''2007-10-17 03:10:07'' [[nbsp]] The time zone should be made obvious - ideally each timestamp would indicate the UTC off-set. --["Users/Graham.Freeman"] +
Line 305:	Line 306:
- 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.	+ 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

Feature Requests

DavidPoole — 2007-10-19 06:44:40

(quick edit)

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 302:	Line 302:
- ''2007-10-17 03:10:07'' [[nbsp]] The time zone should be made obvious - ideally each timestamp would indicate the UTC off-set. --["Users/Graham.Freeman"]	+ ''2007-10-17 03:10:07'' [[nbsp]] The time zone should be made obvious - ideally each timestamp would indicate the UTC off-set. --["Users/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.

Feature Requests

PhilipNeustrom — 2007-10-19 01:56:43

removing some dead/duplicate suggestions

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 121:	Line 121:
- * I'd find an equivalent of Google's "I'm feeling lucky" button useful for searching, so that (for example) if you searched on "Feature Requests," you would be taken directly to the "Feature Requests" page, instead of getting a list of titles and pages that match. --["Users/CovertProfessor"]
Line 182:	Line 181:
- - * Make all pages intended to be used with the include macro in other pages under the Includes/ or IncludePages/ hierarchy, similar to Templates/ . - * What would be the purpose of this? Can individual wiki admins decide whether or not to do this (meaning: is this a software question or just a convention?) Note that in the [wiki:default] wiki there are no pages intended to be used as for an include -- this was intentional because we couldn't figure out whether or not they were useful for everbody, and we hoped that if someone wanted them they'd know how to create them. In the future we might make it so you get a few of these by default, but I digress. I think you're referring to things like "Stub" or "PhotoRequest?" - Yes, and I think it would just be a convention. I suggested it to Jason because he did the Templates and he said to say something about it here. If you think it is a good idea, I or somebody can just do it. --["Users/NickSchmalenberger"] - - The reason we needed to do it for Templates was so we could automatically generate a list of templates. Prior to doing Templates/Name we had the convention "Name Template" and the list would be generated by looking for pages that ended in the word "Template." - - * I vote no on this, because it makes includes harder to use. Do we {{{[[Include(Seed)]]}}} or {{{[[Include(Includes/Seed)]]}}}. How do we include normal pages? Do we have to put them in the Includes namespace? Seems too mediawiki and not sycamore. We don't really need that level of complexity. --["Users/BrentLaabs"] - * Why would the macro not first look in the Includes/ directory for a page with that name, and if not found then look in default pagespace? It would allow include pages to be excluded from orphan and outgoing link lists.

Feature Requests

PhilipNeustrom — 2007-10-19 01:48:31

renamed section, removed graham's comment (plan is different)

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 289:	Line 289:
- == Non-exciting features ==	+ == Spam plan ==
Line 304:	Line 304:
- '''NO!!!!!''' - Captchas suck, but spam sucks more.	+ "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."
Line 313:	Line 312:
- ''2007-10-11 09:26:23'' [[nbsp]] The comment spam is getting worse, and it'll never get better unless we do something about it. I suggest using [http://akismet.com/ Akismet] from Automattic, as it's free for our use and does a fantastic job. --["Users/Graham.Freeman"] - ------

Feature Requests

Graham.Freeman — 2007-10-17 03:10:07

Comment added.

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 314:	Line 314:
	+ ------ + ''2007-10-17 03:10:07'' [[nbsp]] The time zone should be made obvious - ideally each timestamp would indicate the UTC off-set. --["Users/Graham.Freeman"]

Feature Requests

Graham.Freeman — 2007-10-11 09:26:23

Comment added.

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 312:	Line 312:
	+ ------ + ''2007-10-11 09:26:23'' [[nbsp]] The comment spam is getting worse, and it'll never get better unless we do something about it. I suggest using [http://akismet.com/ Akismet] from Automattic, as it's free for our use and does a fantastic job. --["Users/Graham.Freeman"]

Feature Requests

PhilipNeustrom — 2007-10-03 18:48:37

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 286:	Line 286:
	+ + The global search box on the front page of the hub should search for wiki names as well. +

Feature Requests

KarlMogel — 2007-10-03 14:09:15

thx

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 308:	Line 308:
	+ 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 [wiki:dnawiki DNA Wiki], I'll make a how-to in the macros help page. -KJM

Feature Requests

PhilipNeustrom — 2007-10-02 18:09:13

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 307:	Line 307:
- This kind of thing can be achieved using ["Help with macros" 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.	+ This kind of thing can be achieved using ["Help with macros" 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[[Footnote(It looks like they do render as links. This is a bug)]]. 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.

Feature Requests

PhilipNeustrom — 2007-10-02 17:57:39

reply to KarlMogel

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 306:	Line 306:
	+ + This kind of thing can be achieved using ["Help with macros" 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.

Feature Requests

PhilipNeustrom — 2007-10-02 16:24:27

Revert to version 167 (you can add it yourself to the Interwiki Map page).

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 225:	Line 225:
- - * Request to add [http://openwetware.org/ OpenWetWare] to the list of interwiki-linkable-wikis. -KJM

Feature Requests

KarlMogel — 2007-10-02 06:38:21

openwetware

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 225:	Line 225:
	+ + * Request to add [http://openwetware.org/ OpenWetWare] to the list of interwiki-linkable-wikis. -KJM

Feature Requests

KarlMogel — 2007-10-02 06:32:31

portal menus

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 303:	Line 303:
	+ + == 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 [wiki:wikipedia: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! - ["Users/KarlMogel" KJM]

Feature Requests

Roja — 2007-09-26 11:04:44

(quick edit)

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 138:	Line 138:
	+ * (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:" +

Feature Requests

Roja — 2007-09-26 11:03:17

(quick edit)

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 158:	Line 158:
	+ * Ability to add a "Contact Form" allowing for text to be sent via a simple form on the wiki to a specified email address. +

Feature Requests

Roja — 2007-09-26 11:01:51

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 142:	Line 142:
- * (suggested at the davis [wiki: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: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.

Feature Requests

Roja — 2007-09-26 11:00:59

(quick edit)

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 142:	Line 142:
- * (suggested at the davis [wiki: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: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.

Feature Requests

Roja — 2007-09-26 11:00:48

(quick edit)

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 138:	Line 138:
- * (suggested at the davis [wiki: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.	+ * (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: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.

Feature Requests

Roja — 2007-09-26 10:55:53

Allow default security settings to be specified within template files

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 70:	Line 70:
	+ + * (26 Sep 07) Allow default security settings to be specified within template files

Feature Requests

KarlMogel — 2007-09-25 19:32:48

Bump feature request on map zoom level (Steep & Brew on madisonwiki prompted it)

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 133:	Line 133:
	+ * I concur - this would be a very useful feature for larger cities. -["KarlMogel" KJM]

Feature Requests

PhilipNeustrom — 2007-09-20 23:09:46

feature was implemented

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 185:	Line 185:
- - * There should be a way for administrators to leave messages for users. When a user logs in, they'll see an administrative message. For instance, if you notice that someone is adding lots of content, but in a consistently bad way, an administrator should be able to give them suggestions on how to do things better. e.g. "The following is a system message to you, JoeUser: When you add a new business, please use the business template to maintain consistency across this section. If you add an address, please use the Address macro. For an example of how to use this macro, see the following page.... Thanks! -BrianGingold" The only way now to leave a message for a user is by commenting on their use page, which they may or may not see. I propose a message box that comes up when they log in if there is a system message. This could be extended further to allow groups of people, or all users to receive a message from the admins. e.g. "The system will be down for about two hours on Saturday night for a server upgrade." --["Users/BrianGingold"] - Messages that need to go to everyone can be put on the front page. As for messaging individual users, a notification that your user page has been edited should be sufficient. --["Users/WilliamLewis"] - I don't agree. If you're scolding a user for doing something bad, or trying to tell someone to do something in a different way that might embarass them, a private message that only they can see is much more appropriate than a public message on their use page. --["Users/BrianGingold"] - - Here's an idea from Wikipedia. - - [[Image(message-example-pedia.png)]] - - We have a bookmarks functionality that we should probably use for this. Perhaps the user's page should get automatically added to their bookmarks when it's created? When a bookmark has been modified since being seen the bookmarks tab becomes bolded. This good enough for now? - - Preliminary implementation discussion: Split out a header in Interwiki Bookmarks for "My profile pages". User pages will automatically be members of the users bookmarks (convert script will add in user pages for each user at first, when user pages are created / deleted they are added / deleted from bookmarks). A tiny mail icon / notification thinger appears next to "Welcome, UserPerson" when bookmarked user pages have been modified. Clicking on notification symbol takes you to the "My profile pages" section on Bookmarks. This leaves people the ability to: turn off notification on particular wikis by removing them from their bookmarks (user pages only added to bookmarks on creation) - - Preliminary mockup: [[Image(new_user_page_modification.png)]] - - '''Update: this is now implemented. How's it look?''' - - I really really found this useful. It's quite acceptable and easy on the eyes. --["Users/HimySyed"]

Feature Requests

DavidPoole — 2007-09-18 17:44:08

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 283:	Line 283:
-	+ == 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.

Feature Requests

JasonAller — 2007-09-13 03:31:46

Trim in addition to Clear Recent Changes

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 54:	Line 54:
	+ + * 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. --["Users/JasonAller"]

Feature Requests

HimySyed — 2007-08-30 13:49:56

added upcoming.org like functionality request.

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 139:	Line 139:
	+ * 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. --["Users/HimySyed"] +
Line 143:	Line 145:
	+ +

Feature Requests

HimySyed — 2007-08-22 16:30:22

added an image to better show the requested wikilink button

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 54:	Line 54:
	+ + == Adding an auto wiki link button when editing a page == + + [[Image(formatbuttons.png)]] + + 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: + [[Image(formatebuttons.png)]] + + --["Users/HimySyed"]
Line 283:	Line 295:
- - == Adding a autolink button when editing a page == - - [[Image(formatbuttons.png)]] - - 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{{{"]}}}.

Feature Requests

HimySyed — 2007-08-22 16:25:05

Upload of image formatebuttons.png.

Feature Requests

PhilipNeustrom — 2007-08-22 16:21:29

reply to himy re:rss

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 230:	Line 230:
	+ + 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: [[Image(firefox_rss.png)]]. + + 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?) --["Users/PhilipNeustrom"]

Feature Requests

PhilipNeustrom — 2007-08-22 16:21:05

Upload of image firefox_rss.png.

Feature Requests

HimySyed — 2007-08-22 16:14:04

added feedback to new message feature and added request for autolink button

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 183:	Line 183:
	+ + I really really found this useful. It's quite acceptable and easy on the eyes. --["Users/HimySyed"]
Line 277:	Line 279:
	+ + == Adding a autolink button when editing a page == + + [[Image(formatbuttons.png)]] + + 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{{{"]}}}.

Feature Requests

HimySyed — 2007-08-22 16:02:07

Upload of image formatbuttons.png.

Feature Requests

HimySyed — 2007-08-22 15:24:52

(quick edit)

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 226:	Line 226:
- Also, combined with the existing comment macro, each wiki page itself does become a single page blog, kinda sorta. Allowing an xml rss feed to easily be bookmarked, allows regular blogs to ''see'' that wiki page.	+ 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.

Feature Requests

HimySyed — 2007-08-22 15:23:25

(quick edit)

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 218:	Line 218:
	+ + == 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 blog, kinda sorta. Allowing an xml rss feed to easily be bookmarked, allows regular blogs to ''see'' that wiki page. + What Think? --["Users/HimySyed"]

Feature Requests

PhilipNeustrom — 2007-08-22 05:24:21

replied to user notification / user page information requests -- implemented

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 49:	Line 49:
- * Would the user notification idea (as discussed on this page) solve this issue?	+ * Would the user notification idea (as discussed on this page) solve this issue? ''Update: user notification is now up and running.''
Line 182:	Line 182:
	+ '''Update: this is now implemented. How's it look?''' +
Line 199:	Line 201:
- Hi Philip, thank you for the reply. I did not know I could have my profile link to a wikispot user page, I'll update that so my sac and davis wiki edits have the same profile. I do like the "home wiki" idea as-well, because this shows which community a user is belongs to. For setting a default - if a user signs up for an account under a wiki, shouldn't that be set as their home wiki? (ie. If I create my account when looking at the daviswiki, then the daviswiki becomes my "home wiki"). It seems like this would take less work than checking for a user's first page edit. --["Users/VladLoscutoff"]	+ '''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.''' --["Users/PhilipNeustrom"]

Feature Requests

CovertProfessor — 2007-08-20 20:23:56

two unrelated suggestions

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 52:	Line 52:
	+ + * 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). --["Users/CovertProfessor"]
Line 103:	Line 105:
	+ * I'd find an equivalent of Google's "I'm feeling lucky" button useful for searching, so that (for example) if you searched on "Feature Requests," you would be taken directly to the "Feature Requests" page, instead of getting a list of titles and pages that match. --["Users/CovertProfessor"]

Feature Requests

PhilipNeustrom — 2007-08-18 21:46:28

added ted buehler suggestions

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 118:	Line 118:
-	+ * (suggested at the davis [wiki: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:davis:"Wiki BBQ Summer 2007"]): making thumbnails for images so they don't come out huge and disrupt the flow of the page.

Feature Requests

PhilipNeustrom — 2007-08-18 04:46:33

added note from old email w/charles

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 55:	Line 55:
- * (3 Aug 07) [http://iwantmyopenid.org/about/openid OpenID] support. At least Relying Party (RP), but maybe even Identity Provider (IdP) if/when we feel very good about our stability and security. --["Graham.Freeman" Graham]	+ * (3 Aug 07) [http://iwantmyopenid.org/about/openid OpenID] support. At least Relying Party, but maybe even Identity Provider if/when we feel very good about our stability and security. --["Graham.Freeman" Graham]
Line 71:	Line 71:
- * (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. -["Users/Graham.Freeman" Graham]	+ * (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. -["Users/Graham.Freeman" Graham] + + * '''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.

Feature Requests

KevinChin — 2007-08-17 07:21:23

feature suggestion: pages created list

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 50:	Line 50:
	+ + * 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 --["Users/KevinChin"]

Feature Requests

HimySyed — 2007-08-16 00:37:13

(quick edit)

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 66:	Line 66:
	+ + * (15 Aug 07) ["Users/HimySyed" 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. --["Users/HimySyed"]

Feature Requests

PhilipNeustrom — 2007-08-14 05:06:17

(quick edit)

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 158:	Line 158:
- Preliminary implementation discussion: Split out a header in Interwiki Bookmarks for "My profile pages". User pages, when created, are auto-added to the user's bookmarks. A tiny mail icon / notification thinger appears next to "Welcome, UserPerson" when bookmarked user pages have been modified. Clicking on notification symbol takes you to the "My profile pages" section on Bookmarks. This leaves people the ability to: turn off notification on particular wikis by removing them from their bookmarks (user pages only added to bookmarks on creation)	+ Preliminary implementation discussion: Split out a header in Interwiki Bookmarks for "My profile pages". User pages will automatically be members of the users bookmarks (convert script will add in user pages for each user at first, when user pages are created / deleted they are added / deleted from bookmarks). A tiny mail icon / notification thinger appears next to "Welcome, UserPerson" when bookmarked user pages have been modified. Clicking on notification symbol takes you to the "My profile pages" section on Bookmarks. This leaves people the ability to: turn off notification on particular wikis by removing them from their bookmarks (user pages only added to bookmarks on creation)

Feature Requests

PhilipNeustrom — 2007-08-13 13:09:01

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 10:	Line 10:
- * This idea 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.	+ * 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.

Feature Requests

PhilipNeustrom — 2007-08-13 13:08:21

reply to interwiki rc everywhere suggestion

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 8:	Line 8:
- * ''If you use firefox, there's already a solution: see [wiki:gnome:"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. -["Users/Graham.Freeman" Graham]	+ * ''If you use firefox, there's already a solution: see [wiki:gnome:"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. -["Users/Graham.Freeman" Graham] + * This idea 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.

Feature Requests

JasonAller — 2007-08-11 17:49:34

(quick edit)

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 85:	Line 85:
	+ * Orphaned pages shouldn't list pages that have been {{{[[include( )]]}}} ed on other pages.

Feature Requests

PhilipNeustrom — 2007-08-08 05:24:09

(quick edit)

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 47:	Line 47:
	+ + * Would the user notification idea (as discussed on this page) solve this issue?

Feature Requests

CraigBrozinsky — 2007-08-08 04:29:49

making people aware of recent changes

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 46:	Line 46:
	+ * 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. --["Users/CraigBrozinsky"]

Feature Requests

PhilipNeustrom — 2007-08-04 01:37:27

reply w/q

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 50:	Line 50:
	+ * 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?

Feature Requests

Graham.Freeman — 2007-08-04 01:29:49

OpenID

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 47:	Line 47:
- = User metadata =	+ = User metadata, registration, and authentication = + + * (3 Aug 07) [http://iwantmyopenid.org/about/openid OpenID] support. At least Relying Party (RP), but maybe even Identity Provider (IdP) if/when we feel very good about our stability and security. --["Graham.Freeman" Graham]

Feature Requests

Graham.Freeman — 2007-08-03 08:37:01

revised

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 56:	Line 56:
- * (3 Aug 07) I suggest: - '''["Importance of Using Your Real Name" Your Real Name]''' ''(Please do not use a nickname or business name.)'' - (note the link) -["Users/Graham.Freeman" Graham]	+ * (3 Aug 07) ["Users/Graham.Freeman" I] suggest the following two lines (note the link): + '''["Importance of Using Your Real Name" Your Real Name]''' + ''Example: Firstname.Lastname (Please do not use a nickname or organization name.)''

Feature Requests

Graham.Freeman — 2007-08-03 07:30:26

email address confirmation request

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 58:	Line 58:
- (note the link) -Graham	+ (note the link) -["Users/Graham.Freeman" Graham] + + * (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. -["Users/Graham.Freeman" Graham]

Feature Requests

Graham.Freeman — 2007-08-03 07:28:15

Map location(s) modified

Feature Requests

Graham.Freeman — 2007-08-03 07:28:15

minor org.

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 47:	Line 47:
- = Users' information =	+ = User metadata = +
Line 52:	Line 53:
	+ + * The new user page only says "Name." Hence users like ["Users/Lauren"] and ["Users/Jessica"]. I guess this problem will solve itself once enough people sign up, should we be mentioning the FirstLast convention used on dwiki?--["Users/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: + '''["Importance of Using Your Real Name" Your Real Name]''' ''(Please do not use a nickname or business name.)'' + (note the link) -Graham
Line 78:	Line 85:
- 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 ([[address(200 Courtland, ["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.	+ 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 ([[address(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.
Line 111:	Line 118:
- - * The new user page only says "Name." Hence users like ["Users/Lauren"] and ["Users/Jessica"]. I guess this problem will solve itself once enough people sign up, should we be mentioning the FirstLast convention used on dwiki?--["Users/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. - * I suggest: - '''["Importance of Using Your Real Name" Your Real Name]''' ''(Please do not use a nickname or business name.)'' - (note the link) -Graham

Feature Requests

Graham.Freeman — 2007-08-03 07:24:40

suggestion for new account name registration wording

Differences for Feature Requests

Deletions are marked with - .	Additions are marked with +.
Line 114:	Line 114:
	+ * I suggest: + '''["Importance of Using Your Real Name" Your Real Name]''' ''(Please do not use a nickname or business name.)'' + (note the link) -Graham