Does wrongly choosen features lead to softwares slow suicide?

Some time ago I looked into Bitweaver. It uses in line administration wich makes it very easy to set up a basic community. Just install, choose skin and go! (almost). But try to impement your own CSS into it - Possible for pros or semi-pros, but impossible for every one else.

Ahaa! If you want a basic small or even big site inline admin with a Bitweaver style skin /template-system can't be beaten. Simply!

This means that other CMS's can put power into skins and template systems, but they actually can't beat the standardisation in a inline-adm CMS anyway.

Should all non inline-admin CMS's go for smartest and fastes custom site building? Yes, perhaps!

Other traits /features that are cheerished on websites and articles I read is:
# Self explainatory administration pages (and well organised)
# Easy installation (there are monsters)
# Modules /blocks that installs well and work as they should.
# high degree of standardisation (plain CSS and HTML)

Often mentioned weaknesses :
# bad, missing or too limited subject handling (no tree, sub-folders or indexation)
# unusable features
# difficulties to implement creative templates because of limitations.
# modules that do not install


Just a couple of reflexion

MrG

.
Talking to myself...

So what do the last years GNU CMS winners aim at?

MODx: MODx is definitely one of the last years runner-ups! My analyzis say that MODx go for #1) maximum standardisation and #2) Over all high quality. What U see, U get.

CMS Made Simple: Looking at CMS Matrix (website for CMS detail comparisons) tells that CMSMS is a very small package, definitely less admin features compared to the big packages. Dispite of that it makes an impact among webdesigners (pro-amateurs!?). Straightforward, organized and a few, but well choosen modules and features makes it small but usefull... and naturally also easy to use.

One more thing. Both MODx and CMSMS seem to put effort into easy implementation of higly personalized templates. ...which makes U wonder if it is the software it self or a optimized /minimized step-by-step dummies tutor:
"My first website with Xoops" that make the unbeatable winner? Most people have experienced how one (1) ambiguos text line can make a complete part impossible to understand.

SPIP: One of the cms loosers in my oppinion is SPIP, which in some ways seem good but has a strange implementation of the website and has a "dummies tutor" that is outdated exactly where it hurts newbies the most. People who learned it the hard way seem to love it though...

Ehhh... and by the way. One of civilizations problems is that optimization and "house-keeping" (which I hate) is undervalued and building more and more often gets all the stagelight.
.
.

.
Bla... bla... bla....

Can any one know if a nice software needs a total remake, if:
# 50% documentation is outdated
# new examples are mixed up w. old
# less good modules /blocks not removed
# resources are not steadly renewed

Does support, software-homepage live after the same hard quality rules as the development team? Why? Why not?

If sites, texts and contents where vacuum cleaned and remade, perhaps 70% of all mistakes and newbie questions could be solved automaticly.

A completly new application version may solve 30% of the problems, but will also remake some of the old problems.

In that case most would find a rebirth of the support community more "profitable".

I have tryed a couple of different CMS-systems, but think XOOPS is the easyone.
I really think that the admin-interface is selfexplaning and the permissionsettings is the best I have seen.

I can't really se what You want - sorry for that.

I agree with Anderssk. I don't really get what you're trying to say either.
Xoops is the nearest to 'best' (subjective, no doubt) CMS as far as I'm concerned. I've tried others and while their websites and documentation and other trimmings appear more polished at first glance, it doesn't change the fact that XOOPS itself just makes more sense to me.
I can live with the dusty xoops.org pages and vague documentation (you should see my desk) and still run a number of sites that do all I want of them. That alone speaks volumes for xoops.
I should add that Mamba et-al have been doing a great job of dusting things off around here recently, and I'd hazard a guess that if people wanted things more tidied up, they'd probably find a way to get on with doing it.

I can see MrGrey's point to some extent.

The software has moved on a lot very recently. We have a spanking new version of XOOPS and the add-ons (modules mainly) need to catch up.

I suspect that MrGrey's substantive point is that we need to make things a little clearer as to what add-ons are intended for which version and which modules work with 2.3.x rather than (or as well as) the former 2.0.x and 2.2.x branches.

Old modules and themes need to be either "pruned" or moved into separate sections/areas so it's clear what will work with what, etc.

Gradually, as the user-base moves to 2.3.x and thence to 3.0 and demand/need for the older modules reduces then perhaps we can remove them. However, it's far to early to do that in my view as many XOOPS users are happily using the older versions. We must continue to support them.

I agree, too, that the documantation and FAQs need an overhaul. These are most likely to be needed by new users and they will be on the 2.3.x branch, so perhaps this could be done more quickly

What I will say is that MrGrey is fairly new around here and if he thinks that things are bad now he should have been here a year ago.....

I agree with sailjapan..... Mamba et al have been working really hard behind the scenes to get this site up to speed and it's been done with a very positive and focussed attitude that is reflected in the generally positive nature of the site and posts in the Forums. We haven't had an e-fight for months

It's been a while since I have been interested in commenting on a question - but I took this question to mean something different than the answers given thus far...if I am wrong, delete and move on!

If you look at what the commercial industry is doing in general with software development, they are moving towards the "appliance" phenomena - that means, tightly integrated software solutions that are small and fast. in many cases, can stand alone as a complete solution. When I saw "slim or fat" this was my thoughts behind the question. I am a developer and solutions provider for large banking and financial based commercial applications.

Slim can be looked at in a couple of ways - does it mean low on feature set? Small in footprint? Fast on execution? I think that if a "Slim" approach is the direction, you have to look at the overhead involved in the amount of code required to complete a task. Simply put, the number of iterations of code required to perform a task.

I am sure that if all code was reviewed in any solution, you might find complete blocks of code that are many years old and still performing a job. And over time those blocks have been modified, and to a certain extent bloated beyond original recognition. This is how code gets "fat." Developers are too lazy to rewrite - they just add on.

It's not a bad idea to simply throw away code from time to time, and recreate! This can be applied to a database table approach as well.

How many times does a module that relies on some database transaction get modified to the point that the original table structure is no longer recognizable or efficient? Database rewrites, although painful, can produce a "slimming" effect on code. By gaining efficiencies where table space is either no longer needed, or no longer being used in the way it was intended, you may find ways to maximize return on code.

The bottom line is, don't be concerned with what your competition may be doing, but rather concerned with how you can maximize the strengths of what you have or need to produce. In the case of many of these CMS's, you are relying on an interpreted code that relies on a compiled object based tied binarily to a specific O/S and chipset on a server of some sort. That in and of itself is inefficient. Sometimes "slim" does not equal fast, and "fat" does not equal inefficient...just continue to challenge the way development has been done and innovate!

Good Luck!

Quote:
Quote:
Thank you guys for the kind words - I am glad to see that the changes we're trying to implement in the "new XOOPS" are being appreciated! There are a lot of people involved in this, including both of you, and we truly appreciate everybody who is coming here to XOOPS and is trying to help: our XOOPS Innovators and XOOPSers of the Month, and all those community members who didn't get their award yet, but are on the way there!!!

Of course, we need more help, especially with upgrading the modules, and the documentation, but little by little we'll get there. XOOPS 2.3 is the starting point where we can finally consolidate our modules, themes, and documentation. Please be patient with us while we're doing the reconstruction!

But you know what? Cancel that! Be VERY IMPATIENT - and JUMP IN and help us making this transition faster! Get involved in testing modules, re-writing documentation, submitting questions and answers to our FAQ, and in making XOOPS up to date. There are still too few of us, and with only 24 hours in a day, it's sometimes overwhelming.

I'm very happy with every XOOPSer who is coming back to XOOPS and getting re-engaged again. It was the best community in the past, and we're on the way to be great again, so please help us in making this happen!!!!

In the end we are all winners - because with your help XOOPS will remain the best CMS out there, and we'll have no need to transition to anything else.

This is an interesting thread. I'll just think out loud as well.... :)

Discerning the new from the old is a huge headache. And trying to do so retroactively is nigh impossible with a project like Xoops. I've seen some nice changes lately though that would be great to see made official and required.

Module logos. There was a discussion on changing the logo colors from yellow to blue. It's so simple but also amazingly effective! You KNOW that module works with the BLUE version of XOOPS (and possibly earlier versions which should be listed in a section on compatibility). We should change the logo color every major release.

Module and theme lists. Each new release there is a flurry of activity as people try to figure out compatibility. Can we require that modules/themes need to be re-released each major update if they want to be added to the compatible list? If something works with BLUE XOOPS and has its logo updated and code checked by the module dev, it gets re-released and added to the BLUE list. Even if nothing was added/changed, this lets users know that it should be compatible.

Over time, lists would be compiled so that users of legacy versions of XOOPS would know what works on their install.

This approach has the nice side effect of letting people know which modules have been abandoned.... One of the biggest hassles for users of XOOPS is trying to figure out whether a module is still being maintained or not. Module developers could also see what modules need to be adopted to continue development.

Starting fresh.I see some projects create a whole new forum section, news section, download section, etc with new releases. This works well since users KNOW that stuff in the most recent branch of the forums is applicable to the current version. But it also fragments the development process and old topics keep reopening as new people reinvent the wheel. You lose historical perspective when you start fresh with each new version.

I'd like to extend a big thank you to the site maintainers. They have a thankless job trying to organize literally mountains of information. While us users can filter most content based on date to determine relevance, there is a lot that is still useful that is years old -- fixing white pages, embedding html in a XOOPS site, creating custom blocks, etc....

.

Change with words or
Words that change


We humans are not perfect, non of us. Interesting enough some of the most intellegent people is regarded as retards, somewhat roughly expressed...

Sometimes a boss say, "lets change our work!". In 90% of the cases the coworkers keep working exactly as usually anyway. This is even shown by behavioristical science. People do not change and even old companies /factories have always some culture remaining from the time when it was born.

From packpub.com about Xoops:
"Though started as a portal system, XOOPS is in fact striving steadily on the track of Content Management System. It can serve as a web framework for use by small, medium and large sites."

So XOOPS has moved from a portal system to a CMS.

Then I read, under forum startpage about XOOPS 2008:
"Next generation XOOPS 3.0; XOOPS as "Social Network in a box"."

Xoops history is a move from Portal System, to Content Management System and now into the future will be a Social Network in a box. Wow! But what became of the system part? Actually, "in a box" implies that v3.0 shall be an integrated "box", not a module system.

Someone above said that it's not interesting to follow competition... and that's a fact... but they are interesting to look at (how far behind they are )

"Social network in a box" isn't that what Drupal ...or even Wordpress and LifeType use to say? Isn't Drupal smaller and uses a completly different approach to cms compared to Xoops!?

..and Wordpress and LifeType are MODULES IN XOOPS system. Hmmm, interesting

In my magination a social network must include double communication between one or many parties. Actualy it implies that "just adverticing portals" gonna be banned in future (probably not intended).

So, XOOPS is suitable for small, medium and large websites. Who would use XOOPS for a small, very basic blog? Would that be wise? Okay, if it's a small site with big ambitions, then it starts to sound realistic. Is then high ambitions a reason for people to choose Xoops?

here it starts to form a kind of picture. Is XOOPS maybee possible to identify by?

# Overall: big, versatile and powerful
# Power with fast learning, php not a demand (?)
# Somewhat not so "in detail" as some other cms with steeper learing curve.

Would U accept the 3 points as important characteristics for today?

.

---------
[size=x-small]At cmsmatrix.org is something like 900 (?overwhelming number) cms and blogware registered. CMS's should not be afraid to aim at certain parts of websites building and /or management. In this competition no one can be best at everything
.[/size]