The Drupal Disadvantage in 4.7.3 Version
Improve Drupal!
This section must be read carefully, no offense, but this section is my point of view in Joomla/Mambo, PhpNuke and Wordpress experience compare to Drupal. Hope this can improve Drupal.
- NO WYSIWYG Editor by default
First, you may say that my article layout is good enough: contain bold text, there's a page break, a list of number, header text, code tag and etc. BUT, do you know that I must type these tags MANUALLY?
Yes, sometimes i use <br/> which is not meet HTML standard then I must edit again to <br /> with a space. How to make you see the list of number in my article? I must manually type: <ul>, followed by <li>, closed by </li> and ending by </ul>. Sometimes I am forgot to close with </ul> then my article look like ... you know that.
This is the disadvantage of Drupal 4.7.3, which I think easy to solve but I don't understand why the Drupal team doesn't provide it. You may say that I can use third party module called TinyMCE. But, TinyMCE is very basic Editor compare to FCKEditor or mosCE for me. Simple thing like add image to article by mouse click can not provide by TinyMCE! You must know the image URL. You can not browse to find the image you want.
How come a CMS doesn't have a built-in WYSIWYG Editor?
Adding built-in editor required 300 KB - 1.5 MB. If size is matter for Drupal than Drupal can put the editor modules as separate downloadable file, but still as official Drupal module. This built-in or offiicial module also avoid repeated/conflict of language parameters if any. Also, since this module is built-in then the size will be smaller because Drupal can use existing function, language string and image.
Again, how come a CMS doesn't have a built-in WYSIWYG Editor?
Drupal and Wordpress doesn't have a textarea to insert Introduction of Article (introtext), known as Teaser in Drupal. I am not surprise, since I know that Wordpress table has no separates field for introtext, but after I look into Drupal table, drupal.node_revisions, i surprise that Drupal has "teaser" field for introtext and "body" field for maintext.
Drupal people is one of talented user in the world, I believe. But, the installation process is very-very difficult. I say very-very difficult in the point of view of CMS. What people need is Drupal can be installed by webbased, mean no manuall work to create database, run sql script, edit any php file, etc. Drupal can look example from Joomla/Mambo. First, I am thinking to provide the webbased installation to Drupal, since this is very easy just provide a web site to collect some data like: database base, username, password, prefix, etc. Then run sql script according to selected database. But, I see that Drupal 4.8 will be using Webbase installation, great! I will take a look this webbased installation and give any comment to improve this webbased installation if needed.
I think this is very important. Drupal has no pre-installation checking like Joomla. What is pre-installation checking? The pre-installation checking will avoid users fail to install and run Drupal. This pre-installation checking will do these:
- Database: check which database was installed
- PHP: check the php configuration, such as: Display Error and Magic Quotes. This needed to meet PHP setting compatible to certain Drupal requirement. This page also show any suggested value by Drupal
- File permission: is settings.php writeable?
- Versioning: do all s/w have right version? Such as: subquery does not run in MySQL earlier than 4.1, PHP has different function on certain version, certain Apache module need to load to support SEF of Drupal, etc.
Drupal support limited tabbed: view and edit. I think better add new tabbed under edit, such as: Content, Publishing and more. Content-tab will holds: teaser and body. Publishing-tab may contain: Published, Promoted to front page, etc.
Drupal has no backend. This makes difficult to see what exactly show on the frontend without logged out from admin access user.
Since Drupal has no backend then we can not avoid to translate certain administrator string. But the Drupal structure of language file is the best that I have found, compare to others CMS. With Drupal language file we have 2 advantage: easy to find the original text and easy to find/measure which text that not yet translated (that's why we can show how many percentage the translation was made).
Go to add category page then you will find category list but you only see add vocabulary. The "add vocabulary" mean "add category name", why noy just using "category" rather than "vocabulary"?
Another example: localization. Why not use "language" rather than "localization" ? Also: string. String in Drupal language not a "string" in database, but it's "vocabulary". It's look like Drupal developer come from outside this world :) don't worry.
I imagine that one day Drupal can use Joomla/Mambo way to install module and language. Just login as "admin" select "compressed module file" (in .tgz) then click "Install this module"!
This list is not stopped, I will show you any disadvantage and make revision if I am wrong, such as information that version 4.8 already has Webbased Installation with its limitation.
The result is to tell Drupal developer in detail so we will have better Drupal version day by day. I am ready to help Drupal in coding to improve Drupal and especially to show Drupal developer how such things run in Joomla/Mambo if they need more detail.
[Moved out of the handbook - Heine]
The TAXONOMY is superior in
The TAXONOMY is superior in categorizing content. Unlike other CMS which is like: News, Sections, Articles, Downloads, ....
It is not strictly a category, it is the fine art of Taxonomy, and Drupal is excellent in this. No, it must not be called other names just because newbies cant grasp it.
Example: If I have a Sports website, I can have soccer, cricket, ..... the world of sports - and the nicest thing is that I can lump all `Soccer' items (pictures, articles, news, blogs, videos, etc) in Soccer category. Can you do that using other CMS? Hardly.
And Drupal SEF URLs is default - you dont have to BUY plugins / Mambots crap that will wreck your site
And I can go to other soccer website and I can post a nice link that looks like this
http://mysports.com/soccer
Instead of
http://mysports.com/modules.php?op=modload&name=News&file=article&sid=45...
The above URL is a PostNuke URL, which will ensure I will get KICKED OUT of the other soccer site :)
Whoever likes long and unfriendly URLS nowadays? Even Google has changed its policy toward non-human-friendly URLs.
And Drupal SEF URLs is default
Joomla/Mambo has default SEF too. I just try Drupal default SEF and find that Drupal can not create something like this: www.domainname.com/my_first_article.
Where the "my_first_article" is the subject of "my first article". I can create such link but using user contributed module: path_auto.
I think better Drupal come with this path_auto by default or am I missing something?
core stays slim
@thenicespider - a few of your points, such as the complaint about the WYSIWYG editor and the path_auto functionality, come down to the issue that there is a conscious effort to keep Drupal core slim and small. Not just in the size of the download (which is really irrelevant), but in terms of functionality. In fact, we're taking modules out of core faster than we're putting them in. The general consensus among the developers is that Drupal core should be a framework that provides basic services (user authentication, filter formats, menus, etc), and that every other specific feature should be in a contrib module. This is why there is no WYSIWYG editor in core and no path_auto.
At the same time, we're building the next release of Drupal in such a way that you can create install profiles. This will let people make distributions of Drupal core plus modules that serve specific purposes. This is where people like you can decide that a WYSIWYG editor and path_auto should be in every installation of Drupal and you can make an install profile that lets you have it that way, by default, when you install. This is a good solution because it saves Drupal core from having to have the answers for everybody's websites all the time.
- Robert Douglass
-----
My Drupal book: Building Online Communities with Drupal, phpBB and WordPress
Another idea
Since Drupal support Blog, which usually blogger is not familiar with html tag, then I think better to provide simple WYSIWYG editor to keep the Drupal size as small as possible. TinyMCE editor size is 542 KB, but when I remove the docs and advanced theme then the size become 260 KB. This size can be reduced again. The idea is if we can make blogger write blog easier why not provide WYSIWYG editor in Drupal core? this is important, becuse editor is one of the leak module that caused security issue, bad editor can cause Blogger adding bad script and even alter the website look like.
another way is create a section of Drupal website called as: Official Modules (but still provided a page called as User Contributed Modules). And put the WYSIWYG editor module into the Official Module page (or any module that signed as official one). This keep Drupal core stay slim but provide user with "trusted, proven and good" module in the official page.
Since the pathauto is very usefull SEF then I think better this module integrated to Drupal, because when we use Drupal SEF then use pathauto then all hyperlink that has been created will be broken. This is a common issue of implementing different SEF component as you know.
Bad ideas...
Pathauto is very usefull for you ; but not for me, not for everybody...
Drupal support Blog, but it's not a blogging tool like WP... Sure everybody is not familiar with HTML tags (i am because it's my job). In another hand, not everyone wants TinyMCE (or even NanoMCE) : all my pages -for example- are converted from LaTeX or writen using BBcode...
I think i wouldn't come to Drupal if it had all the advantages you mentionne.
Now, that's a good idea; with what criteria will determine the so called Official Modules ? :/
hey path_auto is useful for
hey
path_auto is useful for everybody.
WYIWYG is useful for everybody.
some kind of image management is useful for everybody
some kind of link management is useful for everybody
some kind of document management is useful for everybody
period.
the first two exist but are not included in core
the last three dont't exist or aren't really usable
note:
joomla! has all five (four are integrated)
Drupal may be better in "every way" but these five are the dealbreakers for 90% or more people
I must be in the top 10% then...
I don't need path_auto, I don't need a WYSIWYG editor, I don't need img, link, or document management as I'm extremely capable of such all by my lonesome...
a "real" dealbreaker for most people is the lack of integration with major forum software packages (Vbull, phpBB, IPB, and SMF). What people consider dealbreakers is completely dependant on what you are going to use the site for ... and even then it takes time, effort, and a spot of work to make a *GOOD* quality site instead of some regurgitated out of a can thing. Course, if everyone were to actually bother then I would be out of a job, eh?
Joomla is bloated, and slow... their last upgrade or so *BROKE* the image management plugin (mosImage) and Joomla *STILL* doesn't have *ANY* kind of configureable ACL.
There will *never* be a book titled "Drupal for Dummies" ... and thank God for that.
Top 10 percent
I'm no evangelist, but I've felt a bit smug this past decade with my decision to use Macs instead of Windows machines. And the reason for that is that Macs are more intuitive and simply easier to use. Why am I parroting what you've heard Mac people say for years? Because when someone boasts that they're proud their tech choice will never have a 'Dummies' book, I think that sort of arrogance is counterproductive ... and dangerous. The 'Dummies' line exists because there is a demand for the software that is featured in each title. Interest in a product -- even interest from neophytes -- is a good thing.
The fact that I didn't even think to mention Linux in that first graph should tell you quite a bit about me. I don't make tools for the computer, I use the computer as a tool for to make newspapers. And in journalism we preach to keep it simple and easy to understand -- we often are criticized for our work, but most of us manage to do that regularly. If a reporter buries the most important information at the bottom of a hard-to-read story, few people will read stick with the story to the end to be rewarded with the important news. I have a big ego and want every article of mine to be read top to bottom, so I make it as easy for readers to do so by using clear grammar, common words that everyone understands and sentences that are short -- in short, I don't give readers an excuse to not read me. All computer programmers who want their software to appeal to a large audience should have a similar mindset.
It's one thing to not "dumb down" or "water down" a good product to reach the least common denominator, but to resist user-friendliness merely because a system wasn't necessarily user-friendly when your mastered it is (and that's the impression I got from this post) is absurd. Easy (or, easier) is not evil.
About three weeks ago I was told that my college newspaper's budget was to be halved and as a result we would drop our print edition and migrate to the web immediately. Not everyone using a CMS has the luxury of time to fully learn its ins and outs... If I waited 'til I got myself up to speed with Drupal, my students would waste the better part of a semester without publishing a thing. So I've posted some extremely basic questions in the forums and have felt a bit red-faced (not because of the tone of the responses -- they've been most helpful; rather, because I hate to be a newbie who has his hand out so often) as I try to rush our site online while armed only with half-remembered HMTL experience from more than a decade ago. If I could afford to keep you employed by hiring you to do my site, I wouldn't be in this situation to begin with.
While I appreciate streamlined, elegant technology, the fact that Drupal requires so many add-on modules to make a website unique also makes its management confusing at times. I've been puzzling over image issues the past couple days because there are so many third-party image modules that sort of do the same thing (or at least sound like they do to a neophyte). I downloaded and added a bunch of them and am now trying to figure out which ones to deactivate, which ones are necessary to require which other ones and so on. Had comprehensive image management been tackled in the Drupal code, it would likely have saved a few days worth of my time. I know I'm severely undereducated in CMS, CSS PHP and all thos other web acronyms, so I'm not faulting the devleopers in the least. I don't know enough about CMSs to even be able to chime in on if the suggestions in this discussion are worthwhile.
So what AM I saying? Don't take a request to make something easier to use as in insult against the product. As someone who is more often than not scratching his head over basic things like trying to figure out how to reduce the amount of white space between my site slogan and logo, I can say Drupal hasn't been easy to learn, but it has been worthwhile. Yet if not for the answers I've gotten in the forums on here and from a newspaper webmaster who uses Drupal, I probably would have tried Joomla or some other CMS. And that would have been a shame because -- even though my test site still has a ways to go -- I am really impressed by how well Drupal organizes content. Some 30 nodes of test-site gibberish later, I'm excited at the prospect of my regional campus newspaper having a better structured data system than our sister paper's website being housed on main campus.
Thank You!
I could not agree with you more!! I have a Joomla site, and it will soon be Drupal. Drupal is as straight forward as it gets. And the best feature is that it actually works. I don't have any idea what this guy is talking about. . .
Craig Cooper
craig@craig-cooper.com
www.craig-cooper.com
WYSIWYG is *not* useful for
WYSIWYG is *not* useful for everyone. I don't use it in any of my sites, just because it doesn't necessarily apply. For example, on a few of my sites I make heavy use of custom content types, and custom templates for these content types. To put it quite plainly, if users started including all types of random HTML in their contributions, it would break my site, o at least make it messy etc.
I think you also missed the point, stated by someone else above, that the point of Drupal is *not* to be everything to everyone. They don't *want* to have every little thing under the sun included in the core. Yet all five *do* exist in some form or another. If you want them, you just have to go download them.
That was one of the things I hated about Joomla! - without getting into the whole broken-mambot thing, it just tried too hard to be everything to everyone, and didn't do anything well.
---
Some Drupal Pages I've Designed:
http://www.free-journal-articles.com
http://www.outfrontps.com
http://www.infohatter.com
My Blog: http://www.infohatter.com/blog
Period?
No, path_auto is not useful for everybody. For some people, it's worse than useless. Those people include folks who want to use Drupal as a publishing or content management system, rather than as a blogging tool. If it's "in core", it should ABSOLUTELY be off by default.
Similarly, WYSIWYG is worse than useless for some applications. It needs to be off by default, even if it's included in "core".
Your other points are well taken, but none of them are literally true -- and in fact, they're clearly literally false. You won't win friends around here with that kind of hyperbole.
I have my own disagreements with the choices that are made by Drupal developers, but in the end I think the profiling approach is the right way to go. Let people pick and easily include the features they need. I just hope that it doesn't use the nasty nasty Civicspace installer code.
there is a conscious effort
This makes loads of sense to me, and the install profiles in 4.8 might alleviate some of the criticisms that get thrown about (will there be install profiles available on drupal.org or via fantastico? I reckon that'd make a lot of sense since most new users will get to it via one of those routes, and it's new users who'll benefit most from a profile).
Having said that, it can take a lot of time looking at the contributed modules list to work out 1. what they do 2. how 'close' to core they are. Some of the contributed modules are equivalent to core in terms of how well supported they are, compatibility, quick upgrade paths etc. Unless you follow the progress of ones you're interested in, there's not many ways to know that though.
In other words, stuff that many people would expect to be in core based on other CMSes can be hidden four pages down the contributed modules screen, in amongst a load of other modules. If you know what you're looking for that's fine, but for those who don't (who are likely to be confused by over 100 modules when all they want is what wordpress does) it's probably confusing.
In other words, stuff that
True. But I also think that when the install profiles are finally available, there will also be (hopefully), courtesy of the drupal gods, a list of recommended contrib modules that will make each install profile truly functional. This is perhaps an area where users like us could help Drupal.
a list of recommended
Yes definitely, the documentation is great once you work out where to look, but in terms of getting started more work could definitely be done.
With the idea to keep drupal
With the idea to keep drupal core lite (and I fully approve this idea), the install profiles should be a must!
The question is why?
Robert, as a newbie to Drupal, I must ask the question, "why take that position?" If the purpose of Drupal is to provide a useful CMS for the easy production of social websites, why artificially hinder the program with "intentional" limitations? One of the big problems with Drupal is the dizzying array of modules that sometimes overlap one another. It's also hard to determine if a module is fully debugged and ready for common use.
If more of this functionality was included in Drupal core, then new users could get up to speed much faster. Users that don't need a certain functionality can just turn it off. Disk space is the LEAST concern for most web developers.
And I've got to agree that Drupal needs a wysiwyg editor built in. Virtually every CMS needs the ability to post articles and upload images. I'm currently struggling to find a way for my users to EASILY upload images through the editor interface without needing to understand html and links.
So, again, WHY is it Drupal's philosophy to only supply basic services in core? What's the upside?
Flexibility
Your basic statement, that "the purpose of Drupal is to provide a useful CMS for the easy production of social websites", is not correct. Most developers see Drupal as a platform for building web applications, a much more general description. As I stated, with the install profiles, we hope that there will be many Drupal distributions in the future, all using the basis of install profiles of core + contributed modules. This will let there be a "Drupal for social networking" sites that has the WYSIWYG editor and other social website niceties included.
- Robert Douglass
-----
My Drupal book: Building Online Communities with Drupal, phpBB and WordPress
Because...
Of course, Drupal aim is to be a powerfull and flexible CMS. So it offers choices via modules and let everyone set it's site according to his/her needs.
In another hand and first of all, Drupal is developpement framework.. You have to compare it with Linux Kernel : you can't say the kernel is arificialy hinder with intentional limitation because it doesn't come with a wordprocessor... By the same way, don't confuse the core with a distro with all your desired modules.. A core is a core and no more; that's why it's called core: it's the system core, not the system itself :) And according to that, Drupal core don't supply basic services. As web consultant i every day found the value added of Drupal environment and will always say it's great (far less limited than other Joomla or WordPress believe me).
kernel vs distro
to use your analogy
a CMS is like a linux distribution (comes with kernel and wordprocesssor, etc)
thus drupal is NOT a CMS, but just a part of one - the core part (like the linux kernel)
:(
civicspace is the only drupal core based CMS that is distributed
the rest of us have to roll our own drupal distro!!
...imagine having to roll your own linux distro :o
that's the crux of the problem
people want the word processor to come with it!!
what would be wrong with having an offficial drupal distro
(with wysiwyg, images, weblinks, events, pathauto, cck, views, etc.)
so users could have two downloads available per release
eg
- Drupal 4.7.3 Core
- Drupal 4.7.3
the first one is the core only (i.e. what you get now)
the second one is the core plus some modules
now i hear everyone asking "but which ones to include"
i am sure if you held a poll that asked
"check off the modules you have installed"
and found that 99% have tinymce installed, etc
the choice becomes fairly easy
Simple question, simple answer ...
What would be wrong with an official Drupal distro? Simple ... I, as well as many many others, want the Core Development Team to be doing *JUST THAT*; developing a secure, stable *core*. I think you will find the majority of Drupal users are rather happy with it that way. I believe most of the ones crying as to otherwise are the ones who are still using PHP-Nuke or Mambo/Joomla.
People need to pay attention...
Not just you, but a lot of people saying Drupal needs this or that need to pay attention to what's coming. Install profiles are being worked on so that there can be various Drupal "distros".
Michelle
--------------------------------------
My site: http://shellmultimedia.com
Automated install profiles
The install profiles is a very good idea!!! Should be possible to select the modules directly from a list on the drupal website and download a .tar.gz with only the selected files? ...a sort of cusomized installer?
The Xaneon guys who
The Xaneon guys who abandoned Mambo to go work with Drupal said very technical things about Mambo SEF URLs wrecking the site
And this Xaneon guys further elaborated that:
1. Drupal SEF URLs is superior
2. MULTI-SITE capabilities with just one click (I mean not click like Mambo noobs think)
3. MULTI-LANGUAGE - with i8n thingy and locale modules - superior
*And he said - poor Mambo, it is hard for a developer to develop `extensions' and if succesful, the cost is high and he/she has to charge people in order to recover the cost, and the time lost instead to earn a living
And the way Mambo development is messy and it infected Joomla development
And since when SEF URLs is default package with M/J - since a very recent time, and during that time, Drupalized sites have been hitting Google top pages easily
Drupal path alias has been available (path.module) since I think 4.6.3 and that hooked us newbies since then
It wasnt default Editor that we liked (we used Xoops with its own built-in editor but that was it)
*Google wise:
A URL using - instead of underscore _ is preferable to Google, am I correct, SEO experts aplenty here and they are impressed with Drupal SEO capabilities
*Dries - keep it lean and mean - no need to include Editors (bloating the basic package)
Read what others think about
Read what others think about Drupal
http://apc.org - search Drupal
The organizations which benefit mostly from CMS and Internet - say Drupal is the way to go.
Installation is tricky, but that is only a small hurdle - thats why they provide Drupal system installation and setup for their members so that members use the best CMS, for free or for low cost
And I cant stand Mambo/Joomla advertising (screaming and prodding) - buy themes, buy plugins, AdSense everytime I visit the site and forum
Do you find any eyeprodders in Drupal.org?
No one's questioning Drupal's advantages
The BIG question is why factor in intentional disadvantages? Drupal can maintain it's superior structure and scalability, and yet also be easy to use, can't it?
Not to be too controversial here, but I see most defenders of Drupal's current philosophy as established developers who have already gone through initiation in the Drupal way. I doubt you'd find many newbies supporting the idea of "thin core."
You are absolutely correct ...
Noobs don't support the idea of a thin core... nor do they want to learn how to do it for themselves. They want everything handed to them on a silver platter and don't want to earn it.
Can Drupal maintain it's superior structure and scalability, and yet also be easy to use ... Well, lets think of this in term that everyone can understand.
Linux, Windows.
Nope... Not going to happen.
Distros aka Install Profiles
I've also avoided getting into the mix here so far. Just going to extend the analogy, and make it very clear: please, someone sit down and do the module selection, configuration, UI work, and documentation required to make the "Ubuntu" of Drupal install profiles.
It certainly *is* possible...it just takes a lot of dedicated work. So...get to it :P I want to see CMS Pro bundle, with WYSIWYG editing, nice_menus, an admin theme, etc. etc.
Oh, and "easy to use". For whom? If I spend 2 weeks configuring a site, then the users of the site will have some node/add screens to interact with, from dedicated menu items (i.e. get rid of create content menu), and that's about it. A highly complex system will have a complex admin backend. Most things are "do once" operations that can be captured in an install profile.
(Dixen -- just sort of inserting my comment here...I basically agree with what you're saying)
I disagree with that. Even
I disagree with that. Even from the start I preferred how Drupal was managed. It wasn't easy at first but Drupal tends to reward those who are willing to learn and have some patients. As you learn the system, you'll see how open ended it is. Definitely not for everyone, but the Drupal team is working to make things friendlier.
The "thin core" works because the API's are in place and it attracts developers. Throw all your friendly features into core then the next guy will want what they think are the real friendly features. Keep piling them in and everything gets bogged down.
Anything to help manage development I'm all in for. If you want everything out of a single download then go work with Joomla. -well, until the install profiles gain momentum.
–joon
http://www.dvessel.com
#4 is a good suggestion
You might want to help out with this issue: http://drupal.org/node/75002
Testing the patch there and adding your feedback will definitely help us remove the "Drupal Disadvantage".
- Robert Douglass
-----
My Drupal book: Building Online Communities with Drupal, phpBB and WordPress
Nice article!
Hi Robert, it's a nice article, but what I mean in a Preinstallation-Checking is:
- when install Drupal, user run www.domainname.com
- Drupal will found that this is fresh install and showing the "Preinstallation checking" page
Note: the web base installation in 4.8 already has feature to detect fresh install.
*show Drupal developer how
*show Drupal developer how such things run in Joomla/Mambo*
Its like telling Drupal.org to go berserk, messy, and blurred vision - just like the way J/M go, well, messy and conflicting
Drupal codes are clean and its core is stable and no need to hack/patch
Even us non-PHP can open a Drupal.module file and learn from its clean PHP coding and change stuff if we dont like the wordings and defaults (like changing a link in aggregator.module to have target=_blank )
With modules, dont need to patch/hack core files
And Profiles, lets talk about profile.module - no such thing as a respectable and extensible user Profile module that is free from J/M
you may missunderstood
Hi Muslim guy,
this sentences "show Drupal developer how such things run in Joomla/Mambo" must be read completly as "to show Drupal developer how such things run in Joomla/Mambo if they need more detail."
I mean if Drupal developer need "what do you mean by web based installation? can you explain more, so we can improve Drupal if needed?" then I will help to explain what is the web based installation complete with step by step if needed.
Also note that this article is not to discredit Drupal, since I am using Drupal too as my powerfull CMS. I didn't add the advantage of Drupal because this article is talking about the opposite. And I hope some improvement to make Drupal better.
your vision is to limited
Your article seems to assume a very limited view of sites that deploy and use Drupal.
1. The amount of sites that would use an editor are small. Very very small. Of the 15 sites I setup for people, none of them use TinyMCE, etc. Not including them on purpose allows base flexibility for you or the community to choose the superior solution that you or the community works on.
2. Use the break tag. That's what it's for. If you need more, there is a contributed module which I don't use or need.
3. It is not hard to install. That's a myth propagated by people who don't want to learn the basics of the technology they are using. In any case an installer has been having the foundations laid for two Drupal versions. This has been a comprehensive vision. Not 'just an installer'. The next version already has a web based installer.
4. Shrug. See 3 and Robert's patch link.
5. I think this is to vague to actually count. If you are going to try and write specifications you should write detailed specification.
6. No clue what this is about. Unless... Of course. You don't like the integrated administrative functions do you? I think this is what makes Drupal superior to the others. It's all of a piece.
7. huh?
8. huh?
9. ummm... no. Drupal runs nicely on Windows. See #3 and the evolving future.
Sooo, what now. You seem a little confused. You say 'Drupal developer' like that has a specific meaning. Perhaps you can expand on what you think the phrase 'Drupal developer' means.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
2. Use the break tag.
Or CCK/contemplate does the job very nicely now. I even found a php snippet hidden in a forum discussion somewhere which limits the teaser to a set number of characters automatically.
I'd gone through
1. trying to get non-techie contributors to my site to use the break tag
2. using the excerpt module
before I realised this was possible though.
Maybe your vision is the one that's too limited
Steven, with all due respect, I sense a bit of "Drupal arrogance" in your post. Most of thenicespider's suggestions are valid, and unlike typical complainers, he offered comparisons and suggestions for improvement.
I'm certainly no great hacker, but I've been involved in the computer industry for over thirty years, and one tendency I see is that the truly talented programmers sometimes WANT their systems to be complex and obtuse. It's seen as a badge of honor to their abilities.
But if a program is being designed to do a job, versus being an artistic hobby, then programmers need to think more about how the average user will see their creation.
I've struggled for several weeks to learn enough about Drupal's strange ways to start being productive. I can see its tremendous potential, but as a systems designer I also constantly ask myself, "why did they make such-and-such so difficult?"
Can't we be both powerful and easy? Is there some unwritten law that a program can't exist in both worlds?
sigh.
Your sensing unit needs work. Lots of work. I am tired of people immediatly implying that those they disagree with are arogant. Like that helps the conversation.
I responded to his points that I understood. It's nice that you have been involved in the computer industry for 30 years. Thank you for your implication that those contirbuting to Drupal are going out of their way to make things complicated. They are not. They do not. They publish api.drupal.org which is taken from the very source code you are using. They publish example code for people to use and learn from. They do this so that people can learn from and share their use of this stuff.
Stop saying or thinking that what Drupal does is simple. It's not. Putting together a system to safely and securely manage and display information, users, roles, display of information, work on Windows and *nix, IIS and Apache, MySQL and PostGRE is not simple. The tools required for flexibility are not simple tools. The concepts required to understand such are not simple. As complex as this is, I was able to get my first Drupal site installed on Windows IIS in less then a week with no previous CMS experience.
Your rhetorical question, "Can't we be both powerful and easy?" Here's an answer. If you have a focused specific purpose system where you can control and determine the parameters and environment it is used in, then you can simplify it at the cost of power and flexibility. If you want powerful then no, there will be some degree of complexity. This is why I could replace parts on my old 78 Chevy engine and cannot on my current 98 Dodge truck The newer more powerful one is just more complex.
How's this for you though.... after almost 3 years of using Drupal successfully for a variety of sites, I finally learned how to use a php if.. else statement. I, a NON-DEVELOPER, have been using Drupal for almost three years without php knowledge. Without much SQL knowledge. Successfully. For several sites.
Unlike virtually every other CMS out there, Drupal has no roots or relations to the Nuke series which formed the basis of so many others. Drupal from the ground up had a different goal and philosophy that caused it's evolution and development to be different. I have recently come to suspect that the biggest stumbling block to new people is that those roots are so different that peoples own assumptions from their previous experience gets in the way.
Drupal core is a foundation starting point. Out of the box, core can be a CMS. But it's not meant to be 'The CMS' or even your whole site. It's meant to be the starting point for you to develop and build your site to your tastes. That so many have found this to be true and contributed hundreds of modules to extend and enhance the base functionality is a testament to Drupal's flexibility.
When so many do not need something, why put it in? With core you start with a light weight system that you customize to your needs and desires. You do not have to include a link to Drupal.org (in fact if people can't tell you used Drupal as your base then so much the better). You do not need to have a GUI text editor but if you want, you can choose your favorite (TinyMCE, FCKeditor, HTMLArea).
You choose or write modules for YOUR site's needs. Which you use depends on if you are running a corporate brochure, a blog, an artists portfolio, a podcast, an interest forum or any combination of those. The components of core are meant as the base. Some are there for historical reasons, others are not there because that will limit the flexibility that is continually being built into core.
Drupal has a learning curve. Every complex system has a learning curve. Whether you find it suits your needs or not is entirely up to your goals.
By to limited, I was refering to the focus on the specific sites that would use such a feature. Previous mention/polling/discussion show that while some features valuable to one group are in no way useful to others. Drupal core runs in 8MB of php memory. That's an incredibly small amount. Some sites run in 16 MB, but it depends on their needs. Drupal is one of the few CMS that with careful selection of modules, you can run a modest site on modest hardware.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
Granted
Well, I can certainly see some truth in your statement and I apologize. It wasn't my intention to start an argument, rather to point out a few issues. In fact, I'm in your debt for helping me through some Drupal issues. (see my post near the bottom of this thread)
However, I must point out that many of the responders to this person's original post seemed to be a bit oversensitive as well. This "ease of use" issue seems to be a touchy point for many Drupal developers. It's certainly generated a lot of posts on this thread. And I'm speaking as a BIG FAN of Drupal and the people who volunteer their time for the cause.
What's wrong with being self analytical? Shouldn't we be trying to improve things on as many fronts as possible? I think it's natural for programmers to "forget" how difficult something was in the beginning, by the time they have the power to do something about it.
I am no programming guru by any stretch. But the mention of my 30 years experience points out the fact that I've seen this ease-of-use issue revisited time and time again. Frankly, it's a low priority for most programmers; always has been, always will. It's ironic that the most brilliant minds are usually the ones who have the toughest time with making something both powerful and easy. It's possible to do both.
For programmers, a program is a work of art and they take great pride in its eloquence. But for users, it's a tool made to solve some other problem. If Drupal developers can make that tool quicker and easier to use, why not?
I'd love to get your feedback on my post below concerning improvements to Drupal's ease of use.
Again, I'm a big FAN of Drupal. (and thanks again for your help) :-)
Non-Nuke Philosophy: A Better Mission Statement
I'd say you are right. What initially drew me to Drupal a few years ago was that it does have a very different design philosophy:
* Drupal's database abstraction layer (node system with taxonomy)
* emphasis on developing a system to promote community-building and roots in social software experimentation
* very clean, efficient code (I wouldn't say I know PHP either, but I can read through much of Drupal code and have hacked at a module or two)
* Drupal as a flexible development platform instead of do it all CMS which makes extension difficult
* lean core download (to facilitate clean, efficient, working code)
I was initially torn between Plone and Drupal (plone has a very different emphasis from the Nuke family), but went with Drupal largely because of these reasons and what this philosophy encourages.
I think what we need is a mission statement featured at the beginning of the About section as part of the first introduction to Drupal that makes clear this is the design philosophy; the current mission statement is a rather vague, general thing which doesn't help that much. Then there wouldn't be so many people making suggestions for new features and changes to Drupal which don't match this mission. Furthermore, I think this is why long time members come across as having bad attitudes when discussing why changes to Drupal that new people suggest aren't useful--people don't understand that it really *is* about the central philosophy and focus of this community. It takes a lot of convincing people that they can't change that by making a few suggestions. If these things were codified in a mission statement, that would help a lot.
-----
Charlie Lowe | cyberdash
Tips for posting to the Drupal forums
I rambled my thoughts on
I rambled my thoughts on this as a starting point a little bit ago. We can work on it on the docs list.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
I've not seen this here
If you've seen this elsewhere I challenge you to find it here. I've not seen this attitude even once. What I see from reading the issue queues (you can read them too.... there's an issues link in the upper rh corner) is a constant quest for better code (no bugs, runs more efficiently), more features, more flexibility, easier to use, and better documentation. Seems like we all want the same thing. There are also not so many "artistic hobby" developers as you might think. Most of the developers who've responded here are full-time Drupal developers who earn their living making Drupal sites.
A better question would be "how could this be easier while retaining the flexibility and power that is currently there?"
- Robert Douglass
-----
My Drupal book: Building Online Communities with Drupal, phpBB and WordPress
Well said
If anything, I hope this thread will help raise awareness of the ease of use issues. As I stated in one of my other posts, it's not that programmers (of which I am one) INTEND to make things complex for casual users so much as the very act of writing efficient code draws programmers away from the needs of "ignorant" users. (meant in a good way)
All I'm hoping for is that the programmers ask themselves as they are coding, "is this the best way to do things not only for the program structure, but for the casual user as well."
There are many ways to attack a problem. One way may be good for flexibility and structure. One way may be good for users but bad for the program. And others ways may bring a fine balance between the two. That's what I strive for when I design programs.
I think most of the Drupal contributers here are outstanding: extremely open, caring, and willing to take input from several sources. I guess that's why I've been so verbose. :-)
#8 is a valid point
#8 is a valid point
the terms used by a software product should be intuitive
the Drupal terms are simply not intuitive even when they try to be
eg
adding a "node" of type "page" to a page that is created from a "taxonomy" "term"
could be worded as adding "content" to a "webpage" but it's not
while
eg adding a "node" of type "story" to a page that is created from a "taxonomy" "term"
could be worded as adding "an article" to a "webpage" but again it is not
and that's the problem
the user does not care what the underlying mechanism is!!
this should be abstracted away you can still have nodes and vocabularies but the user shouldn't have to know about them
allowing for new users to get going quickly and for advanced users to do advanced tagging and categorization
just wondering
why oh why is usability so so hard to explain to people
AFAIR endless rants never
AFAIR endless rants never improved Drupal. Patches did. Some of your suggested changes are however no improvements in my book.
--
Drupal services
My Drupal services
Anwsers
--
The news is Now Public | Drupal development: making the world better, one patch at a time.
Hi chx, nice to share idea
Hi chx, nice to share idea with you, below is my idea behind the article:
1. If we can make Drupal easier and more integrated then why not take this idea? And start doing an integrated editor to Drupal.
2. Ok.
3. Just a idea to make it easier.
4. Drupal 4.7.3 contains 2 mysql scripts: for 4.0 and after 4.1, so Drupal must check which mysql version installed.
5. This point to reduce user scrolling page. I think better using tabbed, you can see other example: customize Firefox advanced settings.
6. -
7. It's about translate string/vocabulary for frontend and backend.
8. Just a idea to make it easier.
9. Just a idea to make it easier.
Something i read here...
While reading the site's posts i found a mention that drupal is a "CMS kit"
That is, a CMS builder, maker or development kit.
I find this a very good quote to repeat whenever comparisons arise.
The core is only the engine and modules must do everything else.
I was previously using xoops and mambo and found drupal a far, far more advanced system.
My definition of module crashed at first, with cultural shock, but now modules for me equal functionality.
With an advanced system things are bound to be different.
Hopefully, with the advent of the installer scripts i expect to be seeing more distribution packages like civicspace.
These will include all that it is expected on a CMS and currently left to manual installation.
The editor, the preconfigurations, the installer and frequently used modules could be included.
Perhaps drupal.org should have a whole page of a handbook explaining the comparative advantages.
Something like a migration FAQ. That way no one would miss the goodies.
I can still see some points that could be hard to relearn from other CMSes to drupal:
1. Integration = Distribution. I suggest a FAQ file specially targeted for new drupal users.
2. Covered by modules.
3. Covered by the installer.
4. I can think of this as an useful helping tool for the person doing the install.
I suppose the install files already checks for the mysql version to use, done automatically.
I can see many posts of people not checking permissions and apache stuff before installation, despite being elemental steps.
Since the core can't cover these helpers, can the hooks and API let you develop those pages in a modular way?
As far as i checked the installer on CVS i think it can, making configuration pages and such things.
5. You mean javascript tabs? i can see that would be useful, i use those things a lot.
The jstools module has that covered, altough not made to place the node functions there.
The fieldset collapsible feature does the job and i like it better than to follow the tabs separately as in Mambo.
6. Is the mentioned difference for frontend and backend only to languages?
Someone just did an admin page revamp, but it's not in 4.7.3
There's also the control panel module to have icons.
When i used mambo found hard to navigate to the components and items.
In drupal i find the admin pages less cluttered and not grouped by content type.
However, these differences are merely for the pages organization.
Any customizations would not be in the core.
7. I think the i18n module covers language selection, altough not sure if this related.
That way the admins and staff could select its own language.
8. Covered by the category module. Takes a while to configure.
9. I guess there a module for gzipped uploads could be developed. That wouldn't be part of the core.
But more than for modules i'd like it for themes, because that way users could be promoted and demoted from a role instead of having to give ftp access every time.
Edit:
As for learning curves i didn't find it easy.
I picked up 240 modules to use on various sites, counting the core modules.
Not all of them are used at a time, but must keep track of all the updates and versions.
Fortunately, the update tracking improvements are already in the news.
Why the anger?
thenicespider's suggestions were respectfull, and you have to attack him?
When you stop listening to constructive input from others, you are doomed. Why not think about what he's saying instead of shooting off some smartass answer? Maybe there are a few good ideas there.
welcome idea
hi all, I think my answer is not an attack. I just explain more of my idea, this is covered in Drupal handbook :) apologize me if you feel any attacks but I really want to share idea.
FYI, some of this Disadvantage has been solved on Drupal version 4.8/5.0. Especially for Web Based Installation I try as much as possible give Drupal developer inputs because Drupal has no experience provides Web Based Installation before, unless developer think they didn't need my idea.
Not to mention serious bloat
First of all let me say that I agree that core shouldn't include a wysiwyg editor. That said, would this really be 'bloat'? I mean, it wouldn't really slow Drupal down, as other than serving a couple static files, the editor is entirely client-side. And while HTML input isn't right for all sites, it's certainly one of the fastest options. You could argue that wysiwyg editors are slower for the browser to load, but nobody said it couldn't be disabled, possibly as a user pref. Download size would be a bit larger, but as robertDouglass said, that's largely a non-issue.
I am strongly against
I am strongly against including an EDITOR because the size of the basic Drupal package and `modules' will be big
Understand that some some organizations dont even afford a decent internet access, and USB Flash Drive to store the downloaded packages, and I know many still depend on cybercafes (public Internet access) to operate a portal / website
I have given diskettes for free for small organizations and webmasters which are less than 1300 KB (basic + additional modules)
And also, to make things easier, small size is easy to attach in emails. That saves them from having to visit Drupal.org to download - honestly, it is confusing for a non Drupal user
One of the reasons many stick to Drupal is because the basic installation is only around 1.8 MB, while other CMS like Xoops are 5 MB or more, and that doesnt include aditional modules, what more, it is very confusing to browse Xoops.org `module repository' for what functionality you want, either by name, by A-Z, or by searching
MuslimGuy: Is your only
MuslimGuy:
Is your only objection because of size?
Mike
An included WYSIWYG editor
An included WYSIWYG editor would be serious code bloat
If drupal would come with one of the many many many options there will certainly be people who don't like our choice... so we would dissapoint probably just as many people as we are now by not including any.
Instead you have the choice to install one of the great options that are available like quicktags, TinyMCE, FCKeditor or htmlarea...
Or maybe you want to have filter like in most forums you might try filters like textile, bbcode or even pirate
--
I work for Ontwerpwerk
I see this post coming from
I see this post coming from lack of knowledge and frustration and do understand it. I too had these doubts on my starting journey with Drupal.
Some of the terms were confusing, it was annoying finding i had to source out modules that i assumed would be default and i had a learning curve to master.
I actually remember posting that i thought terminology etc was needless but i'll take it all back now.
Drupal is not a CMS like PHPNUKE (thank god) but a framework for which you build out. Think of it like Linux if you will, it comes with core functionality and then you add your programs to it to build it into something that is unique for you.
This is why a WYSIWYG editor isn't included as default as there are choices here to be made. Some sites won't need them, some would rather their users use something like BBCODE, some might only need the basic editor in drupal. some may require DRUTEX etc. Then some people may prefer HTML area, FCKEditor or TintMCE, all of which you have options to include.
SEO's are not every sites goals either so pathauto has to be enabled etc. Its your choice.
Forums are the same, it comes with drupals own forum module which you can customise the way you like, however if you don't like it you can use PHPBB, Vbulletin and a few others in its place. Some sites may not even need or require a forum.
Taxonomy and the terms that come with it are confusing when you start your journey and you'll likely not understand the need or indeed what it does for sometime. I know i was in this boat for a very long time until one day it all clicked into place and my website became something rather special. Now i could never live without Taxonomy and have readily accepted the terms.
Drupal is about choices and you can, given time and knowledge, pretty much build any site from it. Spend some time with it, play locally with various modules and see how installing one very often gives functionality to others, play with Taxonomy and various settings and then return to PHPNUKE or JOOMLA and see if they live up to the same functionality. If they do and your more confortable with those platforms then your choice is clear. If they don't then welcome back Drupal with open arms, shes a forgiving beast :)
Power and ease of use can coexist
As I've made my journey through the Drupal jungle, I've gained a tremendous respect for its approach and potential. I'm looking forward to the day when all its eccentricities become second nature. But I also don't want to forget where I came from: that is, the domain of the novice.
Why can't Drupal make it a goal to preserve its power, and also become easy to use at the same time?
This was Ubuntu's philosophy toward Linux, and looked what happened. Ubuntu may introduce Linux to a whole new audience of users. With economies of scale, the most deserving packages will win out.
(And I certainly see Drupal as being very deserving!)
Knowledge and learning are
Knowledge and learning are key aspect of "ease of use" and many just arn't willing to put in the time to come to that part of the drupal journey.
Drupal itself isn't hard to use when you have it installed, and with the new installer that will not be difficult.
However its when your imagination takes over and you want more out of the basic distgribution than you currently have that you may run into issues and a learning curve. This is the same with everything. Macromedias Dreamweaver is easy to use but hard to master for instance, same can be said for Drupal.
Linux itself is far easier to install than it used to be, could be classed as "easy to use" out of the box until you wish to add to stock programs and get into the potentials of compiling etc.
At the end of the day there is no skipping over the knowledge you'll need to learn to use ANY system. PHPNUKE, Joomla, MAMBO, DRUPAL, and countless blog applications all have a learning curve and once mastered are all classed by the learnee's as easy.
Granted things can always be improved but if uploading a module to the modules directory and clicking a checkbox to get it activated is deemed hard then i'm sorry to say that i doubt an expandable CMS system is for you.
Also remember that out of the box you can install drupal and tap in content straight away, producing pages almost immediately.
Drupal is as easy as you make it or as hard as your imagination takes you. And regardless of ease of use an admin still needs to learn html, css, some basic javascript (at least as far as cutting and pasting), php and countless other techniques to make his site unique.
If this isn't what the admin wants to do, doesn't feel he can commit to learn and adapt and wants a standard (to his standards, which may differ from person to person) then maybe Drupal as a platform may not be for him. If he wants flexability, a system that will grow with his ideas, a very powerful development platform and a constantly evolving programe then he'll have to commit to learning some of its underbelly, its really as simple as that.
I hope I'm not belaboring the point
But I find it interesting that core Drupal developers all seem to defend Drupal's current state (quite eloquently I might add) rather then stopping and asking themselves the hard question: "have we really made this package as easy as it can be?" I think it's unfair to say, (and I paraphrase) "if you can't handle Drupal's interface, perhaps you shouldn't be developing websites in it."
When any group spends resources defending the status quo, rather than asking itself the tough questions, then progress slows down.
I say this respectfully, because I'm greatly indebted to you, Robert Douglas and Steven Peck. You three among several others, have taken the time and effort to answer my newbie questions on many occasions. I'm grateful. But there are many times I ask myself, "why am I having to ask these stupid questions?"
As a productivity consultant, I also ask myself, "why are these talented individuals having to answer silly newbie questions over and over again? I'm sure they have better things to do."
If Drupal developers would focus more attention on ease of use (as they keep developing tremendous power and flexibility) then the need to answer so many newbie questions would be reduced, and we all could spend more time coding and customizing.
I agree its important to
I agree its important to look around sometimes and see if improvements can be made and i don't think you'll find a single person in the community that wouldn't agree with that statement.
Drupal isn't perfect, as is any software, and your perfectly right that improvements should be sort and where feasable should be implemented.
However we also need to put some efforts into these projects ourselves.
I'm 17 weeks into the project now and i've learned a huge amount about what goes on and enough to take me forward 7/10 times. I still need to ask questions but then i do try and answer as many as i can as well.
I'm not part of the development core (god i wish i was that good) and like you am just a lonely old Admin that spends far too much of his time tweakng and improving his site.
I looked back over the post i made 17 weeks back when i voiced these very same concerns
http://drupal.org/node/61086
Its interesting to note that through lack of knowledge and understanding i was facing the same frustration. However 17 weeks on now i'm finally get most of it and i'm in a position to generally try and help others. Through the learning curve i have managed to grasp an underlying knowledge of the project and carry that forward to my own website.
Webmastering isn't a pickup and use job for the most part and again i must stress comes with a learning curve. Granted there are online systems that enable this learning curve to be slightly easily than say this platform, but they do so over flexability. Many of the frontline blog services all allow their members to post content quickly and easily but the trade of is in the fact that they all look pretty much the same.
Drupal developers do listen however and do adapt. The installer for instance has been a long time coming but has been developed and will be implemented soon, making Drupal easier for the masses.
New users will always ask the same questions and in reality we should help write better help handbooks to ease them into the Drupal world. Then again this too requires the user to read and find those pages and so it goes around again. Teaching them to teach themselves isn't an easy task.
Theres no getting away from the learning curve amd its an important part of understanding the system.
However your perfectly right that we can always discuss ways of improving the system and this is why discussions such as these are equally of great importance.
If I had to name Drupal's biggest needs
IMHO, this would be my list of most important improvements:
1) Integrate image upload into a wysiwyg editor and eliminate the need for 3 or more add-on modules just to accomplish this feat.
2) Add a "How do I do this"" section to the handbook that covers the "common" website designs most desired by users, such as blogs, forums, and news sites. The problem many users have with Drupal terminology could be easily address here with conceptual explanations of what each term means. Robert Douglas did an excellent job with some of this in his book.
3) Use the web install option to offer pre-packaged installs that duplicate the above mentioned website designs.
4) Reduce overlap in contributed modules. This might be done by combining some modules together and perhaps offering a "Drupal certified" moniker to those modules that do not duplicate features with core or other modules.
5) Build a PHP based theme generator module that would allow wysiwyg customization from the admin interface. PHP stylesheets would allow for easy application of color, layout, box, and menu themes.
6) Continue with the approach made possible by CCK, to integrate node customization into core. This would reduce the need for small, specialty modules for some tasks.
hahahaha
I enjoyed reading your earlier post. I recognize much of my current frustrations in the tone of your message.
I guess Drupal is really a fraternity, and we all have to go through "initiation" and "hazing" before we're allowed into the club. :-)
Its more of a different
Its more of a different approach of doing things :)
As you can see i was frustrated too but through knowledge, learning and a hell of a lot of help from fellow drupalers i started to see what they were on about and how it was my lack of knowledge and not theirs that was hindering me.
As we progress we owe it to people who step up to line to take the journey to try and teach them what we have in turn been taught. This makes a community, and this is what makes drupal so special.
I hope i'm playing my small part in the bigger picture and will pass on any knowledge i have learned willingly and eagerly.
No other CMS i have ever used has had the same feeling as Drupal, so yes we have room to improve and a hell of a lot to be proud of. :)
BTW your already in the club, its only through time you'll learn to be comfortable enough to take your shoes of and sprawl all over the leather sofa :)
Why not have an opt-out of 'fat' modules?
I totally agree with zoon_unit about WYSIWG and nicespider on pathauto and 'teaser'.
If Drupal is to be a club for techies: carry on looking after techies first. If Drupal is to mean 'CMS' like Google means 'search': make it as easy as possible for non-techies to have and use the functions they want.
Modules documentation is worse than said here: it's almost trial and error and next to useless to non-techies, ie the very people that will want to find non-core modules like pathauto and a WYSIWYG.
Robert talks about keeping core "slim and small". Fine. And he mentions 4.8's profiling solution which still sounds unnecessarily complicated to me. Why not let those who know what they are doing, eg, all those who want 'slim and small', simply turn off unwanted modules? Or allow them to opt out of unwanted modules on installation. Is that possible? Any down sides to this?
It is beyond me why some people are getting defensive, angry and rude. What's happening? Even the debate against a spammer trying to rip off the Drupal community with a drupal domain was more polite! It is really sad and takes attention away from any point you might have. Nobody insulted your mother. Nobody even insulted Drupal. Questions have been asked in an intelligent and as zoon says, respectful, way.
PS: Drupal is not as SEO friendly as you might think. I'm an SEO pro and after much discussion with established Drupal experts, I can't get what I want with taxonomy. I have to use the Category module.
It is beyond me why some
Really?, even killes was quite polite.
You might be confusing frustration with rudeness though. Each time one of these uninformed checklists of things the rest of the community MUST do comes along it can be frustrating - especially when the person has no idea of the current situation let alone what is in the works or how much effort is currently going on.
They all seem to have this attitude that the Drupal developers (whatever that means) are deliberately trying to make things difficult, or at the very least don't care about making things easier. Following the development or documentation mailing lists for a while should put that silly notion to rest.
Another thing they all seem to have is this idea that somehow a few of their special 'ideas' will spark this massive mobilisation of development effort to achieve them. As if there is this army of developers just sitting around twiddling their thumbs waiting for the right idea to work on.
Drupal obviously isn't hard enough to stop the community growing faster than the project infrastructure can keep up with. In this situation Drupal doesn't need more non contributing users, it needs more contributors (eg coders, writers, donors, testers etc). Most Drupal contributors are overloaded enough as it is - if someone wants their 'special idea' implemented they will either have to do it themselves or sponsor the work. If anyone wants to shape Drupal they need to become a contributor not a commentator.
--
Anton
New to Drupal? | Forum posting tips | Troubleshooting FAQ
Example Knowledge Base built using Drupal
Why can't outsiders have ideas? And why we want outsiders ideas
Rereading, I think you're right.
Opinions on some of the subjects raised are more valid from the uninformed - once informed you don't need many of the suggestions made. Not understanding this is missing the point.
The implication here is that because people are working hard nobody else can raise questions. That can't be right, can it?
Groups of people do exactly that - without realising it they develop their own languages, accents and other means of communication, the aim and results of which is to exclude outsiders. To do the opposite - reach out beyond the 'in group', requires a continuous conscious effort.
Of course not all ideas will start a mobilisation but all "mobilisations" start with an idea.
Depends what's wanted of Drupal. If you want Drupal to be 'bigger' and more popular it needs more users, if you don't, it doesn't. I want Drupal to be bigger and more popular to help it get better and create enough momentum for it to continue and continue to improve.
That's fine if you want an in-group-serving club (a valid opinion that looks after football supporters, youth 'tribes', nationalism and religions). But if you want more than that - eg, a CMS that appeals to the outside world (both techies and no-techies) - then you need to do the opposite and listen to non-coders, non-writers, non-donors and non-testers.
thenicespider was offering to be a contributor. Personally, I commission and submit modules and I'm writing guidelines for those who want to SEO with Drupal. But this doesn't make our opinions better than if we were just commentators.
Not at all
I was talking about uninformed as to the philosophy and direction of Drupal (the project) and what efforts are already underway - not uninformed as to how to use Drupal (the product).
Chances are that a suggestion has already been debated to death and decided against, or is being worked on. Wouldn't you get frustrated with people bringing them up all time without looking into the situation more beforehand?
No that wasn't what I was implicating. I was meaning that before making long ranty suggestions, people should at least inform themselves of what is going on and why it is going on. As well as why certain things won't happen.
A more constructive approach would be to search out more info about why things are the way they are, and if not finding anything asking why first. There are usually good reasons, and coming across as someone willing to learn rather than just dish out orders will be more productive.
There is a long history of people popping up here and squawking a lot about what Drupal developers need to do for Drupal to succeed, then not doing anything about it themselves. It is usually just recycled noise. You could forgive the developers for getting annoyed about that.
--
Anton
New to Drupal? | Forum posting tips | Troubleshooting FAQ
Example Knowledge Base built using Drupal
This thread got sadder the
This thread got sadder the more I read.
I thought the Drupal dev-community was a tad more grown-up than some of the other bitchy dev communities I frequent... Luckily, I still cling onto the belief that not everyone here feels the need to bare arms at the mere whisper of a "competitor", or the sight of a "stranger", AKA: a new user.
... sheesh!
Desmon:
Macromedias Dreamweaver is easy to use but hard to master for instance, same can be said for Drupal.
Yet it's one of the most successful website packages out there. So why do people use it? Because it has a comprehensive help manual (one of the best IMO).
... which shows that you can have complex apps that people will use if the help system is there.
I often read about the documentation system here being improved - which is great - but that only covers Drupal ass. Far worse are some of the modules - Some of them have a one-line statement and that's it!! It's like the author is thinkin, "Oh they'll know what it is and how it works!"
Same with commented code (if any!).
If Drupal confines itself to core activities, then it will be the modules that undermine it if quality doesn't at least meet a minimum benchmark which addresses the "whole" experience of using a particular module.
Yes, documentation is a pain in the arse but if you release sommat to the public, presumably you want it to be used.
(Even (at least) one of the Summer of Code's finished entries I tried out earlier had a total lack of documentation and even failed to specify the need for an external component... I find that quite amazing TBH but put it down (I hope) to time-constraint and hope it will be put right soon. It deserves to be put right 'cos it's an amazing piece of work, but again, what is the point if no one can use it?)
DESMON:
Also remember that out of the box you can install drupal and tap in content straight away, producing pages almost immediately.
I note you guarded that statement with the word, 'almost' ;) But the thrust of it does suggest that you "expect" people to know HTML to qualify using a CMS... which is wrong unless you only allow Drupal to be used by geeks, pure and simple.
This is all reminding me of products that were ground-breaking and brilliant, but quickly superceded by imitators who understood KISS and the user. Personally, whether Drupal has a WYSIWYG or not won't stop me using it - It would surely make my life a lot easier however, and yes, it defo should have one as part of the install. Afterall, it's a Content Management System, is it not!
I'm 17 weeks into the project now and i've learned a huge amount about what goes on and enough to take me forward 7/10 times.
17 weeks?
... 17 weeks!!
Trust me when I say: I'm not taking the piss! I am purely emphasising - I first came to Drupal last year and immediately recognised its potential. Life butted-in and I came back again about 6 weeks ago... I'm STILL moving an existing site over; hacking away, learning and tweaking. I too have started to ask,:Should it be this "awkward" and "fiddly"?
Additionally:
Would I persevere if I didn't enjoy doing it (or had no self-interest)?
Would I persevere if I didn't currently have the luxury of time I do ATM?
Developers (here), do enjoy working on it and have a self-interest. They most likely will make the time and we love "awkward" and "fiddly" processes/systems because without them, there'd be nothing to do. (BTW, I'm not suggesting that the devs here deliberately make things "awkward and fiddly").
And therein probably lies the juxtaposition between dev-heads and users and some of the dev-head answers above.
... which leads me to this...
STYRO:
In this situation Drupal doesn't need more non contributing users, it needs more contributors (eg coders, writers, donors, testers etc).
And that leads me nicely to the final point I wanted to make:
Drupal's name is getting out there. Even since last year when I first came here, I see a diifferent class of user on the forums. IMO, Drupal will hit a point of critical mass fairly soon (if it hasn't already started). Before bemoaning the non-contrib users it might be pertinent to ask: Whose fault is that?
Drupal front page:
Nowhere have I seen a phrase that say's words to the effect, 'Drupal is a CMS made by developers, for developers".
Your reasoning is not unreasonable IMO, But it is what it now is. You equally leave yourself open to the counter-argument of; if you don't like non-contrib-users, form your own closed-community and build your own.
I've read Dries' articles on the need for a better UI - To my mind (and he may well concede the same), it was a bit late, but welcome nonetheless. This thread is all about just that... and I do mean, ALL.
Mike
Sheesh
Maybe my writing sucks - another reply that missed my point(s).
I'm not bemoaning non-contrib users. If I was anti new users, I wouldn't have a few dozen pages full of forum support for newbies in my tracker. In fact I would guess that around 90% of my 'contribution' to the community has been newbie support.
My point was that Drupal is gaining new users anyway. There is no shortage of them, but their experience is only going to get worse if we can't ramp up the number of contributors we have at at least the same rate - support, documentation, testing, development etc will suffer. Drupal might very well want (and I do too) new users, but it doesn't need them as such the same way it needs more contributors.
A bit late? I can remember usability discussions as an ongoing thing for years now. The desire to improve usability has always been there. People on the development list have been designing and running usability surveys etc.
There is ample scope for people with all kinds of skills to contribute to that. From what I've seen newbies are very welcome on the documentation list.
Regular ranting on the forum without looking into the situation isn't contributing in my opinion. All it does is mask the real work that is happening by drowning it in noise, and giving a false impression that Drupal developers don't care about usability. Rebutting that false impression draws developers out to correct the misinformation, which then creates a response of complaining about their defensiveness and arrogance. All very predictable and preventable if the original ranter had bothered to look into (and even join) the ongoing efforts to improve the situation.
--
Anton
New to Drupal? | Forum posting tips | Troubleshooting FAQ
Example Knowledge Base built using Drupal
Again i must state that i do
Again i must state that i do agree with your points for the most part. However what i don't agree with is the need not to know some basic HTML.
We have all made a choice here to run a website in whatever state and size this would be. We have opted for a CMS development platform that grows with us, is flexable and very powerful. With this, and i've stressed this again and again, comes a learning curve.
Drupal is more a Content Management Platform than say a Nuke CMS and i think this is where some of the issues raise their heads. Nuke can be installed quickly and out of the box can create some pretty impressive sites. However Nuke has limitations and you'll meet them head on very quickly if you develop your site away from a standard. But, again i must stress, even Nuke comes with a learning curve.
Theres no getting away from having some HTML knowledge and you a WYSIWYG editor will only hide the need for that. Sure for the most part you won't need to know what is going on under the belly of the editor but they'll come a time when you'll need to learn more to achieve your goal.
PHPNUKE itself for instance comes with BBCODE that you're going to have to learn. Without that knowledge its no where near as easy to use or get the results you require.
Vbulletin, probably the most successful commercial BBS system in production comes with a learning curve and an Admin interface that will delight and confuse you.
We are admins and have made a choice to develop a website, not a quick journal. Granted Drupal can be used to create a quick journal as well but its not its sole intentions.
I understand peoples frustratration and yes there is a huge need for better documenation and more info for the people starting their journey. However it all comes back to resources. Who will create said manuals ? Who will quality check them ? If a developer doesn't develop and writes manuals instead, wheres the new code coming from ?
This is where we all need to pull together. Stephen has mentioned many times that if you see a gap, fill it, your part of the community and are in the box, not outside looking in. If the manuals are weak, help write some new ones, if support on the fourms is lacking, jump in where you can.
The point has been made here, and rightly so, that some modules have less than adequate information and readme files that are next to useless. This is frustratrating but totally understandable as we must remember that for the most part a module developer develops that module for his or her own needs and then, generously, release this module for the benefit of others. He or she may not have the time to write extensive manuals to help introduce users to his or her work as they are busy implementing new features, fixes and the like.
However we never, myself including, see others step up to the plate and help these developers out with writing the help files for said modules. We'd sooner moan they don't exist in the first place (i know i've done this myself from time to time).
Suggestions are great and are a part of getting involved in the project, however actions are better and this is where we are letting the project down somewhat.
Those that have the power to develop the code for core and modules are already likely to be working their ass of doing just that, we as the benefactors of this work should ease their burden as much as we can by helping to write better manuals, issue proper bug reports, agreed offer new ideas for the project and helping out with issues others have in the forums. We too, being admins of our own websites, have likely got busy schedules, but we can all help here in a limited fashion.
I hope that point gets across to everyone in the community and that we all understand what is being achieved here. We all have a part to play.
Yes and no
Yes
I'm totally with you on all your points about documentation and going beyond moaning to helping.
And I too am 'guilty' (if that's the right word). Eg, I commissioned page_title module to fill a big gap in Drupal's SEO potential but haven't documented how and why to use it for effective SEO. I intend to correct this.
I'd add that encouragement and clear signposts are needed to get a newbie from talk to action. Shooting them down with defensive irrelevancies doesn't help.
No
Back to the debate.
Free CMSs more powerful and flexible beyond our current discussions and a joy to use for those without any techie knowledge will exist. This is inevitable and WYSIWYG editing is a small part of this.
For Drupalers the question is do we want Drupal to be one of those systems?
If not, Drupal will remain a techies-only club left behind by systems providing what users want.
I hear the term "techies"
I hear the term "techies" come up a lot here on Drupal. However i certainly wouldn't class myself as a "techie". I can't code thats worth a damn, my html and css knowledge is enough to get my by but certainly not "techie" classed. javascript (well don't even go there).
My point is that i'm no "techie" and learned to use most of the system relatively quickly. Granted i asked lots of questions, read lots of forum posts, navigated around the help files and more than likely stumbled onto a few solutions that i hadn't even realised i needed on the way.
Its not a "techie" system or a nerds system, its a platform for you to develop your website. How easy or complicated this site becomes is down to you.
Please don't get me wrong here. I do see your points and i know for sure everyone who is involved either as admin or coder does too. We should always look to make things easier, but then the user should likewise always look to learn to help himself somewhat too.
I think the responses here show that people are interested in discussing the debate at hand and are genuinely up to help make changes where needed. Steven Peck has just opened up a huge new message about the Documentation update so people are listening.
Now we all need to knuckle down and help make debate a reality.
Better documentation is paramount to the project and as steven has stated, not many contribute, myself included, to that area. Hopefully through the advent of this thread we can shake a few cages and get more people involved.
I'm not sure i'm confident enough for doc pages yet, but i'll continue to help in the forums wherever possible.
Well put, timely advice
Yes! Intellectually mature: able to recognize useful information, even when it comes in a form you don't like. Emotionally mature: able to glean something positive and useful from what the other person says, by not taking their form of expression personally.
Yes! On the one hand, the way the modules work is the coolest thing. When I installed my first module, I understood what is so great about Drupal.
But it's really shocking and (sorry to say) unprofessional that so many of the modules have to be installed before you have any idea what they do! Why shocking? Because conflicts between modules are not uncommon. Because these problems require expert knowledge to troubleshoot and resolve. Because that expert help ma