Topics about the usability of Drupal remind me on the most recent Steve Jobs' speech against Android and Open Source community over iOS and integrated solutions: http://tinyurl.com/steve-jobs-vs-android
I don't know how many of you guys will read this and find it interesting, but I think this is a pretty good question on usability. Steve Jobs labelled here the Open Source solutions as "Fragmented" (which is fairly true), and claims it will clearly lose battle against "Integrated" solutions (which is an argument I hear quite frequently lately in many different forms).
How can this topic be related to Usability? Well, the same logic could be applied to treat a Drupal installation as an integrated solution from a higher perspective (as an out-of-the-box solution) but the deployment of fragments (modules, themes, customizations) are essential for building any serious online platform. An average user is confused, scared and sometimes discouraged (before he/she even tries to dig in deeper) by a learning curve needed to modify those fragments to gain a desired result.
Questions during the setup and development phases like:
- what modules should I use?
- what's a recommended procedure for this?
- how can I resolve issues between contributed modules?
- do I have everything I need for my goal?
... can sound pretty anxious if we combine them with the front-end confusion of a new user of Drupal.
I believe the answer is in integration of special cases within separate projects. Luckily, the Drupal community has already thought of that and the keyword is: installation profiles. Just imagine how many hospitals, charity organizations, human rights associations, and similar non-profit institutions are there that could need our help in providing a tool for a good cause.
This is my first article on GDO. I decided to write this article as a small contribution to inspire some of you to create your own version of an installation profile for any non-profit organization. I'm sure there are many of you who already worked on a similar project. Why would that code be abandoned, forgotten and applied only on a single project, if you could do something good for the community by creating an installation profile with all the "fragments" you've used and publish it as a separate Installation Project. Some of you probably had good solutions, worked really carefully on usability and I believe there are many of us who would like to contribute to those kind of projects with improving it's usability.
Once we'll have a fair amount of Installation profiles with dedicated usability for those non-profit organizations, we could even publish it on a front-page of Drupal.org as a shiny proof that Drupal is ready now to help everyday people out-of-the-box. Those installation projects would be already tested, proven for at least one organization and could be improved further by the community. At the same time, usability could be improved for those separate cases "per se".
I also think we could start brainstorming on using categories within themes and profile installations. Take a look at the TemplateMonster.com, for example. They use separate categories and apply predefined style tags on each template. I would more prefer an advanced search filter with displayed browsing categories just like on a Google Directory, rather than a plain non-creative list of teasers like it exists on many different places within Drupal.org.
I think that could be a nice start to focusing on integrated projects, by keeping all the benefits from a beautiful world of our "fragmented solutions" while doing good deeds.
Happy coding!
Peace,
madjoe
Comments
Apple FUD, nothing new
For the most part, I don't think his concerns apply to Drupal.
Because of how new and active Android is, major changes are being made at an amazing pace. The speed of development of the OS, and how quickly the industry is changing (smart phones are becoming the rule, not the exception, manufacturers are allowed to compete primarily with hardware capability, rather than software) fragmentation in terms of OS and hardware features is far more likely to occur. Additionally, it's up to phone manufacturers and carriers to push updates out to their users, and they have little incentive to do so, worsening the problem.
Drupal, in comparison, is fairly mature; major revision changes don't happen every few months. There are only two supported major revisions at a time.
Additionally, I don't think the problem he outlines here is actually a problem. Android is available on more than one phone from more than one manufacturer. Android lets hardware manufacturers customize the software. Android is rapidly developed. Android allows users to customize the appearance and behavior of their device. Those all seem like good things to me. These freedoms do come with a small price in terms of development for the platform, however Google has done a decent job of managing this. The TweetDeck example Jobs cites is a good one. The developer reported that there was so much OS and hardware variety all running his application successfully because he was impressed, not annoyed.
The blog post that Jobs cited
Developer's tweet regarding the situation
Saying that android isn't an open system because it gives it's users (both end users and OEMs) too much freedom is simply Apple Newspeak.
"Freedom is slavery"
To more directly address your ideas, I don't like the idea of there being many "integrated" solutions like installation profiles running around for cases where they don't really need to exist. I can install several modules on a site, I can't use several installation profiles. I feel like zealous use of installation profiles to solve simple problems ends up actually creating real fragmentation that could otherwise be avoided.
If the goal is to solve the problem of new Drupal developers not knowing where to look for the solutions they need, there are better ways to do this (better documentation, fewer modules providing the same features, etc.) However, there's no real way to completely solve that problem. Those unfamiliar with any system will always be at a disadvantage.
Redundancy
I was just using a metaphor from Steve Jobs' speech to make a parallel by marking integrated as "profile installations" and fragmented as "do it yourself solutions" from the perspective of an average user (non-Drupal-developers). I agree with you that he was using another FUD just to brag about the power of his products.
I'm still not convinced that increasing the amount of Profile installations is a bad idea. For example, recently I tried to re-create a new platform for my projects to cooperate with my various teams. I needed some well known modules, but I also needed to make it look good, because my clients would use the same tool as well. Then I tried Open Atrium for the first time.
I was really impressed with the out-of-the-box solution. It has everything I wanted to install myself, the layout is great, the Features module is shining there and it seems like I could use it for many smaller project management purposes with ease. I could alter the code if necessary to meet some specific goals, but I would say that Open Atrium project is heading to the right direction. The idea popped up to my mind that second. Profile installations could be categorized and improved for any existing "typical" use-case. Why not to include those separate Drupal projects as a part of existing Drupal's "Profile installation" initiative? If we would have similar projects like this on one place, I'm sure the parallel would be like having numerous of Android applications per special purpose. Modules would still have a special place for development, but "Profile installations" could be whole packages picked up from the gallery of installations that would be a great starting point for any specified use-case. Installation categories could be defined and there could be a single profile installation per category item, unlike modules.
The way we should see this is something like: modules are mostly for developers, profile installations are mostly for plug'n'play end-users. Once they install a profile installation, of course they could have various needs to alter some features, but that's the point where developers jump in (if they don't want to consult the documentation and try to do it themselves).
I don't doubt that Open
I don't doubt that Open Atrium is a good project, an installation profile that fits a particular niche very well. Installation profiles like this allow you to polish a certain set of features, modules, and theme to fit together in a much more coherent whole, that can be re-used for what it's designed for. However, it's going to be less than ideal for doing the things it's not designed for.
When I hear you say "create integrated solutions" I hear a temptation to compartmentalize and Tivoize (not quite the word I'm looking for, as it's definition is a bit too specific to hardware restriction) Drupal et al. to match certain use cases. Yes, this makes things very nice for the people that want plug-and-play solutions to specific problems, but I don't think it's healthy.
In general, the default module-style system of reusable chunks of functionality allows for a reasonable amount of plug-configure-then-play, while maintaining enough flexibility and openness that people working on a site that has features X,Y and Z can collaborate with people working on sites with features Q,R and X. An "XYZ" installation profile might be nice to have, but if too much of the effort of developers is spent in improving XYZ at the expense of the modules from which it's been built, projects like "QRX" suffer.
Installation profiles aren't a bad thing, but over-use of them can be.
Over-use
The magical thing of Installation profiles is that the final product is still "fragmented", but acts as a whole. It's still just the core Drupal with pre-installed modules, themes and tweaks. It could be changed just like any other Drupal installation. I don't think we could/should Tivoize profile installations. If it could be handy to someone as a good starting point, why not to start from there - to avoid redundancy of doing the whole process from scratch until the point of completion of that particular installation? Open Atrium is a good example for the thing I had in mind on this topic.
For example, if many various charity organizations would use the same profile installation of Drupal, and if it suit their needs just like Open Atrium suit my needs for building projects, I don't see it as an over-use. I see it like saving time, resources and money while having more time for focusing on their main goal.
Okay. What you're suggesting
Okay. What you're suggesting seems to be well outside of what I was cautioning against.
Heads up
I absolutely love the way Drupal community grows. This is a shiny example of it: http://drupal.org/project/distributions
We need more Drupal Distributions and over time those distributions would need to be categorized properly.