Wiki Community/Future/Software Features/Talk

The features page got off topic with critiques and arguments. That content is copied here so those side issues can continue while continuing the survey on the features page.

In coming up with future plans for the wiki, software is definitely going to affect how we interact with information. We already have a page on this on the Wiki Spot hub, Feature requests, but that page is long and is just a list of ideas.

This page should be a survey to figure out what the greatest software needs are for our community are. Just list the top two changes that you'd like to see in our wiki, so we get an idea of what's important to people. See also Wiki Community/Future/Gnome Features.

(If you're actually interested in doing some of these software changes, check out sycamore or email <sycamore-dev AT T wikispot DOT org>)

General tools that don't trap people into specific processes and possibilities. Many proposed system tools were oriented toward one way of wiki. —jw

I'd like to see (1) An Events Board that doesn't suck, and (2) A categorized mapping system. —BrentLaabs

I would like to see (1) an event board that doesn't suck and (2) A description of your edit for the quick edit Daubert

As far as user features, (1) a smart WYSIWYG editing system would be terrific for getting people away from comments. (2) An event board that doesn't suck would be nice, too. —WilliamLewis

• I like your #1 but it's a bit vague, I'd like to hear some specifics on that. It's tough to decide what to build, and how exactly it will work, I think my facebook suggestion below would be a good, extremely simple step in this direction. —GarrettGallegos
  

• Facebook like button?! Put down the social media koolaid!-wl
  

(1) An effective notification system for messages. Ideally, both an on-screen thing and an email notification (with the option to change what actually shows up in user settings). (2) Some sort of threading system to view a back-and-forth conversation between users. Any time there are more than about 3 back-and-forth comments on people's pages, it's virtually impossible to track the course of the conversation. Possibly have an ability to show the "info" page for multiple pages at once, select multiple edits, and "View Threaded Edits" to see the source of each edit in sequence. —TomGarberson

• I like how both of your requests have absolutely nothing to do with any features that would benefit the wiki in any way. E-mail notifications? Threaded conversations? Sounds like both things that would benefit you, since you watch the wiki like a hawk, but provide nothing to the greater community. That is all a lot of effort for very little payout. The way it is designed right now is SIMPLE, and simplicity is the key to all software. There needs to be additional SIMPLE features that do new things for the wiki, not complex re-designs of existing features. If this wiki or the local wiki was getting as many users or editors as wikipedia, this conversation would be different, but at this point those are "niceties" at best. Also, I don't think encouraging back-and-forth conversations is best for the wiki - as conversations between you and myself and proven. The wiki needs features that make it easier for users to Contribute and Share information - ie. A Request Queue. —GarrettGallegos
  

(1) Same as TG's #1 (improved notification, both on-screen and via email). (2) Coming soon. —CovertProfessor

(1) File history shown in the edit history of a page like it is in Recent Changes, and the size of the differences of edits in the info page and Recent Changes. (2) Better mapping system without Google. —NickSchmalenberger

(1) Comment-linking capabilities in the user pages, and perhaps (2) a more “native” way to link to specific sections of a page (using hash anchors) —EBT

(1) A better socialization process for bringing new editors into the community and up to speed. (2) A change to the comment macro so that comments are no longer stored into the text of the page, but are directed into a separate database. Allow them to thread, be voted up or down, filtered, sorted by date either way, allow responses and quoting. Turn it into a real page specific forum feature, or get rid of it. —JasonAller

• I like your #1 but it's a bit vague, I'd like to hear some specifics on that. It's tough to decide what to build, and how exactly it will work, I think my facebook suggestion below would be a good, extremely simple step in this direction. —GarrettGallegos
  

(1) A "Request Queue" - such that any person can go onto this page - and enter any Text/Images into the queue, and a more experienced contributor can take items from the queue, properly format them, and place them on the wiki (so that less experienced users can still contribute, without having to spend time learning the nuances of the wiki or get heckled for formatting or something) - also I think this would just allow people to enter information in when they don't have much time, and other contributors could "claim" an item so no-one else will claim it at the same time, and then remove it from the queue once it's done, pretty simple concept, pretty easy to build (2) - facebook integration - to get more people viewing the wiki - because in many ways - just viewing the wiki is contributing, and the more views, the more editors you'll get. a "LIKE" button on every single page I think would be a WONDERFUL, EASY, SIMPLE way to do this, and would immediately have an effect on the wiki traffic. (3) Checkbox next to comments box for "discussion" so that discussions can be excluded from the main page, as we need not bother other wiki members with our petty differences. ps: if this was PHP (or Perl, I miss you Perl) i would be more than happy to build some of these features pss: i bumped my comments request down to #3 and replace it with the facebook thing, because comments don't have much to do with a wiki anyway. if anything, i would like to see it harder to place comments in the first place, so more energy and focus is put on content and contributions. —GarrettGallegos

• How would the "discussion" pages be different from the "Talk" pages we have now? That's what the Talk pages are for — discussion about the page. —CovertProfessor
  

• I never said anything about the Talk page. This is so comments/responses to comments can be "hidden" from users. In other words, it's a really simple way to get the most important comments to display. Don't know if you realize this, but the Talk page isn't exactly heavily used if you get my drift. This was sort of a play on JasonAller's #2 request above, except his request was extremely overcomplicated, and that amount of effort should be put into other areas of development - not comments. A checkbox is pretty darn simple - lot of ways to integrate that feature without separating comments into separate DB fields/rows. Threading comments, voting up/down, sorting by date, all "niceties" and honestly completely unnecessary. Need to take "baby steps" - put small features into place to gradually improve the software, not put tons of effort into one feature like that - that's just my opinion - which is only about 11 years of development experience. If there were unlimited development resources, this would be a different conversation, but there aren't unlimited development resources. -gg
  

• True, but we just gained two paid developers, which is part of the reason this was asked. We have a grant that enables us to rewrite the software from scratch (overhauling and taking into account what we've learned), and that's why this community input is being solicited. -jw
  

• I knew about the grant, but didn't realize it was re-writing from scratch - oh my god that sounds awful. Non-rhetorical question: Is that really necessary? I'd honestly love to know why. ps: i'm not trying to dis you, but i've been developing for a "while" and unless you have some major problems (or built a system on Plone and need to ditch it asap), it's better to just focus on building end-user features. I'm honestly trying to figure out the reason for a rewrite. -gg
  

• The request queue is a terrible, terrible idea. The whole point of the wiki is that all editors are equal. This feature would simply encourage the wiki to be written by the anointed few and would discourage people from becoming full contributors. —wl
  

• HAHAHA, then you are a terrible, terrible, inexperienced developer, end-user, or neither. That's not the whole point of the wiki. The whole point is to get average community members to contribute, such as my mom, who would be scared off by having to write one, single character of code. You guys seem to want to build this around yourselves, it's just selfish. -gg
  

• Nobody is saying that we want contributors to write any code at all. Hence the WYSIWYG editor, which is going to be a core part of this rewrite. —wl
  

• I compared WYSIWYG to a "Unicorn" because a good one just doesn't exist, and if you want to spend the next 10 years waiting for a good one - by all means go ahead. I wonder what the 100's of 1000's of users who rely on me would prefer? I build new, awesome, simple features for end-users every day, and I've worked with enough developers to know that most of the just like to develop - as a hobby - with no end-goals in sight. I prefer to make my end-users happy. It's worked out pretty well for me so far, since I have to turn down calls for new projects almost every day. -gg
  

2010-10-11 12:56:37   Almost all of the suggestions above are Editor-related features, and almost none of them would benefit the common end-user. I think a focus on ease-of-use for the average user, rather than niceties for the most common editors, would be a good thing to take into consideration before making suggestions, and before putting time into building any of the above. Very little has been done to make it easier for the average user, who may not be computer literate, to contribute. This may not be a business, but it needs to start getting run like a business in many respects. —GarrettGallegos

• There is a full, major rewrite by full time developers devoted to the project. That's a fairly big change from the past. -jw
  

• That's great to hear, I really don't follow sycamore. Can you provide me a link to some more information on this re-write? Although I have to be honest, "major rewrite" and "full time developers" scares the life out of me. Major rewrites are something developers usually like to do because they are unhappy with various technical problems unrelated to the end-product, in the real business world - major rewrites are a big no-no unless you are on a system that is in dire need of a re-write (ie. ASP). Since this isn't a business, it's probably easier for developers to get away with doing whatever they feel is necessary. I think baby steps are a lot more important. Major rewrites can take so long that by the time they are ready, they are already outdated. If the wiki cannot make small, gradual changes (baby steps) as needed, I don't know if they will survive. In other words, should we really have to wait for a full-rewrite to get a "Like" button or a Request Queue or whatever other features we want? No features mentioned on this page would require a major rewrite, they could all be handled by developing individual features. -gg

"Rewrite" is probably the wrong word. We're working on new wiki software for local communities — a major part of the LocalWiki project. This development work is being funded by a grant from the Knight Foundation. I've read countless rewrite/don't-rewrite arguments (jwz, mozilla, etc). In our case, we do not have an actively developed or maintained piece of software. Sycamore, the software powering wikispot.org projects, has had minimal outside contributors (for various reasons) and isn't and hasn't been actively maintained for years now. I wrote a good deal of it (years ago) and the thought of hacking on it now is really off-putting to me, even! If you'd like to get more info as we have it, put your email into the "help out & get more info" box at localwiki.org. We're literally just getting started really this week and we'll be sending info on tech stuff out shortly if you'd like to help. —PhilipNeustrom

• Philip, I would like to say thank you. This is perhaps the most useful information any of the other users have provided, on any subject on this wiki. I am very thankful for your contributions. I did sign up on the link you sent me. Are you dead-set on using Python again or will you/have you already considered PHP? For practical reasons, and I mean that in the most literal sense - practical, real world necessities - I only write PHP/Mysql these days. I've dealt with enough other languages/db platforms to not have any desire to touch them. I may be willing to contribute for free if the "weather" is right. —GarrettGallegos

• Why does Wiki Spot need to be run like a business? And how would it be run like a business? —wl
  

• I didn't say it needs to be run like a business, I said get run like a business "in many respect" - big difference there WL. FOR EXAMPLE: don't complain to users about formatting or too many edits (ie. treat them GOOD - LIKE CUSTOMERS - don't complain - don't treat them just like WoW users who are pissing you off - it's quicker for you to fix mistakes than to complain to other users about their formatting). Also, focus on EASE-OF-USE - ultimately what you want is IDENTICAL to many goals of a business - MOST # OF USERS - EASY AS POSSIBLE TO USE - Maximum payout from the website. This has a LOT in common with a business, once you get a reality check you'll realize why. The end goal - $$$ - is different, but that shouldn't affect your website goals. But apparently some developers just want to focus on development for the sake of development, not easy-of-use and features for end-users. -gg