Author Topic: Discussion of CMS suggestions for the DC software directory (Read 46881 times)

mouser · « **Reply #25 on:** March 02, 2011, 03:04 PM »

gothic sent me this link to people working on code for treating wordpress as a library for a cms:
http://andy.wordpres...ress-as-library-cms/

Veign · « **Reply #26 on:** March 02, 2011, 03:15 PM »

That link is way too old - 2006.

Wordpress is leaps and bounds beyond when that article was written.

Gothi[c] · « **Reply #27 on:** March 02, 2011, 05:09 PM »

Yeah, but it's still what would be ideal.
I wish there was a CMS LIBRARY instead of a CMS webapp. This would make life so much easier in terms of integration. And not just for DC, but for umpteen other projects i have going

40hz · « **Reply #28 on:** March 03, 2011, 11:13 AM »

Since this is basically a reference book you'll be creating, perhaps the best CMS for this might be a Wiki.

Wikis use a reference book or catalog metaphor; allow for customization while still providing a recognizable format for most people to navigate; allow you to embed links to anything (blogs, email addresses, software, downloads, images, media, etc.); and, once set up, are very easy to use - and most importantly -maintain.

Best of all, you won't need to reinvent the wheel. Wikipedia has a very good summary box for software that could easily be copied. Example1. Example2.

Discussion of CMS suggestions for the DC software directory

Even more important, they've worked out the taxonomies. Link here.

Coming up with good categories and subcategories is the most difficult task you'll encounter when creating a reference directory. So whenever possible, steal a good one from somebody else, and modify it as needed.

Running the category main links down the left column (ala Softpedia and many others) is a terrific help for users. Try to do that if possible.

Discussion of CMS suggestions for the DC software directory

Most people don't think of wikis for a curated directory because they keep thinking in terms of everybody being given write/edit access. It doesn't have to be that way. You can restrict feature access however you like with most wikis.

We set one up for a client that has an extensive library of documents, media, and software assets that they wanted to provide their employees with ready access to. There was a ton of good stuff in there. But nobody knew half of it existed, let alone how to get to it.

After looking at several CMS and 'document management' products, we went to WikiMatrix, ran through their choice wizard and got these recommendations:

3F Wiki, bitweaver, BusinessWiki, Clearspace, codeBeamer, Confluence, Corendal Wiki, Daisy, Drupal Wiki, GeniusWiki, IkeWiki, iKnow - a tiny wiki, Incentive, JSPWiki, Luminotes, MediaWiki, Midgard Wiki, MindTouch, MojoMojo, PAUX, PhpWiki, ProjectForum, SamePage, SharePoint Wiki Plus, ThoughtFarmer, Tiki Wiki CMS Groupware, Traction TeamPage, WackoWiki, Wagn, WikiDoc, WikkaWiki, XoWiki, XWiki and Zwiki

In the end, we didn't need to do a lot of comparative studies. One of the company's employees already had extensive experience setting up and managing MediaWiki. Since they had in-house expertise to fall back on, and it was already on our short list, we thought it best to go with MediaWiki. It was installed, populated in relatively short order, and became a "big win" for everyone involved. The employees love it. And in the true tradition of wiki-thinking, it continues to improve incrementally through subsequent additions, edits, and updates. So what was once "90% right" is closer to "99.9% right" now that the company has grown into it.

Note: MediaWiki might not be the absolute best choice we could have made. But it was definitely a good choice for them. That's something to keep in mind when doing a platform search. Don't let the natural desire to find the absolute best solution keep you from implementing a good solution. My software selection rule is: Something that's 85% right and working - is preferable to something that's 100% right and perpetually in planning.

Rule of Thumb: Apply the finishing polish as it goes out the door, not as it comes into the shop.

app103 · « **Reply #29 on:** March 03, 2011, 12:32 PM »

Before I started this thread my idea was to do something like I did with my book directory, using Wordpress and a DC theme that would make it blend in with the site.

The plan was to use some of the same plugins I used in my directory:

Popularity Contest to put a list of the most popular apps at the top
A table of contents page
User star ratings, which would not require anyone to register on the site.

Categories going down the left, and a search box at the top, just like my book directory has.

And after the discussion of PAD files and Veign's links to PAD plugins for Wordpress, That's how I thought I was going to do this.

I did also consider using a CMS specifically designed for software download sites, and the one I found could not only serve as the software section of the site, but with some modifications to include some content from the forum (mouser's blog mod), the front page of it could very well serve as the main page of the site.

I don't think I ever mentioned how much I hate wikis. I have never seen a wiki that I didn't think was ugly or that I actually enjoyed editing. If it wasn't for the content on Wikipedia, I'd never visit their site. My last job required me to edit a Google wiki with support info, for internal use. I really hated that part of my job, almost as much as I hated making Quickbase reports.

If I had discussed this in private with Veign, instead of posting here on the forum, this project would be finished next week. You have no idea how much I am itching to do this. I was ready to stop talking and get to work 16 posts ago.

But with mouser's leaning towards Drupal, it doesn't seem as though this is going to be the job I volunteered for. Seems like it will end up being one of those "call me when you need help adding the content" projects. And while I would be content to do that if that is what would be best in the long run (I don't have a problem with stepping aside and letting better, more experienced coders perform their magic), I also know it means we will be here next year with the job still not done and this will be one of those discussions that didn't exactly go anywhere.

wraith808 · « **Reply #30 on:** March 03, 2011, 12:49 PM »

^ This is one of those times where design by community decision leads to more indecision and no work done. I think that a real priority needs to be established, even if just as general as (a) work towards immediate benefit or (b) work towards a long term goal, i.e updating the platform and such. I don't think that either is wrong, but it should definitely frame any conversations, and reduce such frustrations as app is experiencing.

Veign · « **Reply #31 on:** March 03, 2011, 01:05 PM »

IMO if App had done a Wordpress based website it would probably work great for years and bring much joy to the community instead this being in discussions for months, development for a year (if a solution is chosen where solid development work is required) and in the end maybe have something that works but is difficult to maintain by a non-developer.

If someone is ready, willing and able to provide a solid solution what's the harm on taking them up on it. Put your trust in what they will deliver and be happy to have something better (maybe perfect). Hell, just getting someone to volunteer to complete an entire project is difficult, don't pass it up.

Think of it this way: what ever is delivered probably buys you years to work on other things.

Just my .02

wraith808 · « **Reply #32 on:** March 03, 2011, 01:31 PM »

IMO if App had done a Wordpress based website it would probably work great for years and bring much joy to the community instead this being in discussions for months, development for a year (if a solution is chosen where solid development work is required) and in the end maybe have something that works but is difficult to maintain by a non-developer.

If someone is ready, willing and able to provide a solid solution what's the harm on taking them up on it. Put your trust in what they will deliver and be happy to have something better (maybe perfect). Hell, just getting someone to volunteer to complete an entire project is difficult, don't pass it up.

Think of it this way: what ever is delivered probably buys you years to work on other things.

Just my .02
-Veign (March 03, 2011, 01:05 PM)

He has a point. And not just the ones on his avatar.

40hz · « **Reply #33 on:** March 03, 2011, 03:02 PM »

echo wraith808 on +1 w/ Veign

Better something workable now than perfect someday.

cranioscopical · « **Reply #34 on:** March 03, 2011, 03:26 PM »

app103

I think your selfless willingness to undertake this is something for which we all should be grateful.

As long as what you propose does not create any problem for the way DC runs (how could it?) I think we should urge you on with enthusiasm.

Thou waitest for the spark from heaven: and we,
Light half-believers of our casual creeds,
Who never deeply felt nor clearly willed…
Who hesitate and falter life away,
And lose tomorrow the ground won today —
Ah! do not we, wanderer! await it too?

mouser · « **Reply #35 on:** March 04, 2011, 07:51 AM »

Agreed with what everyone says, but with one major caveat, that relates to this project and others: Some of us have very different attitudes about creating something that does not get used.

If you are the kind of person who works on things like this and enjoys the experience and is happy to have spent the time on it even if it does not get used, then there is no reason not to work on it.
But if you are the kind of person who would be upset if you spent days/weeks/months on a project only to find out that it's not quite the right solution and won't be used, then you need to be MUCH MUCH more careful about coordinating the time you spent with others, to make sure that you are working on something that will in fact get used.
The middle ground here is the person who will be upset if it doesn't get used, but is a gambler and is banking on the gamble that their work will get used when it's finally unveiled in it's finished state. This is almost always the worst choice you can make.

So figure out which kind of person you are and coordinate on that basis. Doing research on different possible solutions is *always* helpful. I'm just cautioning against spending too much time implementing something specific at this point, because i think there are quite a few tricky details about getting this right, and if we're going to go to the trouble of fixing this deficiency on DC, I'd like us to find a really good solution to it.

Veign · « **Reply #36 on:** March 04, 2011, 08:17 AM »

mouser, maybe you should clarify. What it sounds like is someone, like App103, may deliver something that DC chooses not to use. Is that the case?

Also, no offense, but you're never going to get things right (or done) if you allow everyone to have an equal voice in what does or doesn't get created. Design/development by committee just never works.

wraith808 · « **Reply #37 on:** March 04, 2011, 08:21 AM »

Design/development by committee just never works.
-Veign (March 04, 2011, 08:17 AM)

Again, point.

mouser · « **Reply #38 on:** March 04, 2011, 08:23 AM »

I'm not a huge fan of development by committee -- but I am a fan of getting tons of input from everyone and then having one or two people try to put together one coherent solution that addresses the important concerns raised.

Regarding the software repository I was simply suggesting that because I don't yet have a feel for what a coherent solution would look like, I am a little bit hesitant to have app or anyone go spend a lot of time on something that may not get used, unless they are very comfortable with the idea that they are just implementing something for us to look at and consider, and not necessarily use in the end.

40hz · « **Reply #39 on:** March 04, 2011, 09:59 AM »

To Mouser's point about a coherent solution, perhaps it would be beneficial to get some better understanding of what the goal(s) of having this directory is/are first? Because it starts sounding a little vague once we get beyond what looks to be unanimous agreement that it's a great idea and we want to do it.

So if this discussion is meant to be anything other than a general brainstorming session, maybe we really need to take a small and short step back.

It would be very helpful if Mouser, and/or those who make up DC's equivalent of a steering committee (if there is something like that for DC

) could help by clarifying what "The Big Win" would be for this project?

Once that's done it becomes much easier to talk shop, debate platforms, and decide which people are best able to make it all happen.

The reason I mention any of this is because the only time (ok, four times

) I've ever had a project fail on me was when I went into one without a clear set of goals and a definition of what would constitute a successful completion.

Just my two and thinking out loud.

mouser · « **Reply #40 on:** March 04, 2011, 10:08 AM »

Yes, let me give some thought and write up a little post reply later today about what I think are the key features it has to have. I think my concerns are almost entirely around making it easy to maintain and update the content.

Renegade · « **Reply #41 on:** March 05, 2011, 06:15 PM »

Yes, let me give some thought and write up a little post reply later today about what I think are the key features it has to have. I think my concerns are almost entirely around making it easy to maintain and update the content.
-mouser (March 04, 2011, 10:08 AM)

That's why I suggested PAD. An extension would easily allow adding whatever content you want in addition to the basic specification, and it would automatically work in PADgen, which would give you an authoring tool immediately with zero work. On top of all that, publishing would simply be updating the PAD file. It doesn't get much easier.

app103 · « **Reply #42 on:** March 06, 2011, 09:45 AM »

I have talked this over with mouser in private and have decided to start by creating a real widget ready DC wordpress theme. Even if it doesn't get used for the software directory project, it will not go to waste, as it can be used for the member server WP blog project, and with a change of the banner graphic in it, to be used by any member that wants to use it for their own site on the member server.

After the theme is made, it would be trivial to snap together a software directory site with it and a few WP plugins. Then it's just a matter of chasing down all the devs and getting them to make PAD files for their projects....

But we can cross that bridge if/when we get to it.

If nothing else, we'll have a good WP theme, ready to use for whatever WP powered projects we may have in the future.

wraith808 · « **Reply #43 on:** March 06, 2011, 10:30 AM »

^ Sounds like a good compromise. Thanks for taking this on app!

mouser · « **Reply #44 on:** March 06, 2011, 12:09 PM »

Ok so I promised to post my thoughts on the Software Repository idea. Here goes:

First a summary of what I think are problems with how we currently do list software on DC:

There is a complete dichotomy between "main/official" DC software and things like coding snacks, which is often artificial. The "main/official" software listing page is here, and it has links to my software page and the Coding Snacks software page, and a few other people's pages who are prodigious releasers on DC. Coding Snacks are the other major kind of software created by DC members and they have their own page here, which is presented in a completely different way.
The main reason for this dichotomy is based on the mechanism to maintain these lists; the main software page i edit by hand and ftp up to the server when it changes; the coding snacks are handled by a kind of in-house blog system that i wrote a while ago. A secondary reason is simply a matter of having some kind of organization that isn't overwhelming to users in terms of them distinguishing between bigger apps and smaller utilities that are more suited to experts.
Both of these software listing mechanisms are a pain in the ass to manage, nearly impossible to search.
They also are not amenable to making an automatic list of recent releases, providing an rss feed, etc. The home page list of recent releases is again manually edited (part of the reason i only update it for "major" releases).

So what do I think we would benefit most from:

A unified systematic way of maintaining and presenting ALL software on DC (big apps, coding snacks, etc.)
A system that let's select moderators have control over which authors can create new entries in the software repository, and then let mods and authors create and update and maintain their own entires, with little difficulty.
Automatic creation of "recent update" lists/rss feeds.
Ideally it would allow authors to both upload their new releases to be served from the site, or link to external releases.
Well integrated into the look and feel of the site. However it's important to note that I think the site should move to a proper CMS -- so i'm not arguing for the software repository to tie into the CURRENT hand coded html / theme of the site.
Multiple ways to present the software repository organization. Some people have stressed the desire to have software logically arranged as a hierarchy of categories (Utilities, Clipboard Tools, etc.); while i do not deny the value of this, i think it's important to realize that this approach is most useful for sites which are comprehensive software listing sites, like a freeware site that aims to include every free utility in a class. Then it makes sense that people will go to that site to BROWSE for the best such tool. But for us, i think MOST people will land on a page through a web search, and not because they have some interest in seeing all the clipboard utilities that DC members happen to have made. So, while i think such an organization would be useful (and more so the more apps our members release), i do think perhaps more importantly would be a way for mods to be able to also make collections of items arranged by author, or by event (NANY?) or by some editor's choice recommendations, etc. One of the things i see on many big software listing sites is that programs/projects get "lost" in the forest.. And i think we need to have some way of making some things easier to find, perhaps at the expense of some of the more esoteric, specialist, small utilities. Maybe.
Something with an attractive image-centric layout for overview of programs (something like this).
Support for screenshot galleries and videos.

Some concerns I have about a new system:

I think one of the biggest unresolved issues on community sites like ours is the problem with redundant information. We have a forum where the hardcore dc members hang out most of the time, and where we prefer to talk about issues.
The forum is ideal for ongoing discussions. But then for casual software users, they may benfit most from a simpler more restrictive comment system on a software repository page. And bugs might be better tracked on a dedicated bug tracking page, etc. Some pages like a FAQ may be best handled with a wiki like system.
We tried this once, incorporating a serious bug tracking system, and using wiki system for some info. The serious problem here is the need for users to coordinate these redundant and incompatible ways of discussing things.
My general feeling is that redundant information is the root of all maintenance evil, and needs to be avoided at all costs. That makes me hesitant to add any features or content to the software repository that would be duplicated independently by forum content. I want us to be wary of this when thinking about software repository features -- it may mean not using some common features (ability for users to leave comments, track bugs, etc.) -- or it may mean adopting a convention that we not do such things on the forum.
I worry about over-complicating this and trying to make something too powerful and complicated; this site needs more simplicity and less complexity.

Armando · « **Reply #45 on:** March 06, 2011, 01:47 PM »

Thanks for sharing that. I think it's good stuff.

Some complementary thoughts:

- Multiple ways to present the software repository organization : Couldn't all software titles be put in a DB and then, through different filters/queries and sort methods, we could see just what we want in a table/grid like interface ? I'm thinking of Something close to Mantis in terms of functionality, but maybe simpler and nicer (aesthetically).

This would be integrated within the site. It would be easy for the admins to see exactly what needs to be updated, when it was last updated , etc. But maybe is this a terrible idea...

(This wouldn't have to be the only interface : DB data could be formatted differently in other pages where organization would be more static (standard web page))

- Redundant info problem (especially regarding bug tracking and suggestions, I suppose...) : as far as bugs and features suggestions are concerned, I think that all that is needed is a relatively strict way to do things. But since it's hard to force users to adhere to specific (even simple) rules, it needs to be mostly implemented by the admin's/mod's responsibilities. This doesn't mean that the users shouldn't adhere to a couple rules (e.g. : if you want your bug to be discussed, post in the bug section and tag it as a bug...)

In the InfoQube forum, we've implemented a simple way using the forum and Mantis.

Mantis is the developer's turf, but it can be browsed and issues can be added by anyone there. In reality, only a few users do take the time to do so and it's not a problem.

Anyway, the procedure goes like this :

1- Everything is discussed in the forum.

2- When something is "confirmed" (issue, important feature...), a- it's entered in Mantis with the thread's reference (hyperlink). Mantis isn't a place to discuss things (some discussions take place there, but they are extremely limited and focused)
b- a code is entered in the forum's threads title (so that's obvious that issues have been filed), c-the mantis issue ID is entered in the last post of the thread. (Obviously the mantis Id could just be added to the forums title thread too, so it would be a 2 steps process : a, b)

It looks complicated but it's not. it just means going through all bug reports and suggestions once a week (probably not much more than 10-20), and copy paste info from the forum to Mantis. Some of it could even be scripted (steps a, b). Once that is done, one can forget about the forum, and maybe just update the related threads with info when a serious bug has been fixed. But even that is generally unnecessary.

I think redundancy is probably not as bad as you make it sound.

E.g. : as you know accounting systems are based on efficient redundancy, and so is data security, etc. We just need a way to control it so that it doesn't become chaotic. Redundant material used as a "history" for verification purposes needs to be identified as such and then... forget about it, "archive" it (i.e. : let it sink in the forum's abyss).

No idea if this has any value... Sorry if I'm repeating the obvious or wasting your time.

40hz · « **Reply #46 on:** March 06, 2011, 01:54 PM »

I think by going with a moderator/curated type approach you have the best chance of avoiding redundant information spread over several areas of DC.

I'd suggest that any comments/discussions/announcements/bug reports for any software in the directory also be moved over to whatever system (blog?) is being used for the directory. That would gather all relevant info under the actual software titles, which should make the directory a much more focused and relevant resource.

For continuity in the main forum, you could leave the existing structure in place, but include a polite note under each title that says all info and discussions for 'XYZ' have been moved over to the new software directory - and provide links to go there. Might not be a bad idea to lockout new entries being made to the old forum area by people that choose to ignore the notice.

Agree too on the recommendations for using PAD files. They not only provide a standardized info format, they're usable by many other software sites that might also be interested in listing a DC member's creation. That could help gain some additional exposure for DC by making its software collection more visible to search engines by virtue of being listed on other sites.

Just another

mouser · « **Reply #47 on:** March 06, 2011, 02:30 PM »

Multiple ways to present the software repository organization : Couldn't all software titles be put in a DB and then, through different filters/queries and sort methods, we could see just what we want in a table/grid like interface ? I'm thinking of Something close to Mantis in terms of functionality, but maybe simpler and nicer (aesthetically).

I worry this kind of thing would lead us to over-complication.. Let's try to keep this as simple as we possibly can while trying for most of the functionality we think is important. I don't think we have so much software that we need to get crazy with letting people filter and sort entries, etc. A good compromise might simply be a simple tagging system, and a way to present a page of software with that tag -- then we could create arbitrary collections using tags.

JavaJones · « **Reply #48 on:** March 06, 2011, 02:54 PM »

Much as I dislike it for general CMS use, it seems like Wordpress is actually a legitimate option here. It can for example support the kind of tagging and tag-based presentation that mouser is looking for (and which I agree is needed). Apparently there's also PAD file support, and perhaps even more importantly the person most motivated to work on setting it up has WP experience.

The only thing I'm personally not sure of is how to implement the feedback process and systems. Comments in e.g. WP are more amenable to reviews (e.g. "love this app!"), not so much to bug reporting or tracking. One thought was to have a full sub-forum or even just a single discussion thread for each app in the forum and just link from the app's directory entry. That gives us the full capability of the forums for formatting, discussion, etc. I don't think a formal bug tracker is needed for 90% of the software that will be listed. The rest can use our existing Redmine setup that devs have access to. The question remains though whether a simple "commenting" functionality is enough, or if we should continue to rely on the forums for at least the major part of the actual *discussion*.

- Oshyan

40hz · « **Reply #49 on:** March 06, 2011, 03:16 PM »

Might also not be a bad idea to initiate some dialog with the DC's software authors and get a feel for what they think about all this since it may change how things currently work for them.

With the additional exposure a directory may bring, some of the old "publish & forget" days may be coming to an end. Since most of them do this for free and in their spare time, it may get to be a "job" staying on top of the comments. Especially if a title gets popular due to wider exposure and generates a lot of feedback asking for responses from the author.