While the rest of the world kicks the tires on Drupal 7, the mad scientists who work on Core are already breaking out the whiteboards and starting to plan for the next release. It's a tradition: with the current release in the can, the pent-up energy for new stuff can be released.
After Drupal 7's epic three-year development cycle, though, even the most aggressive devs are taking a moment to consider what areas deserve attention. Some want to push forward with major architectural changes that didn't fit into the 7.0 cycle; others are lobbying for a "housekeeping" release that focuses on API cleanup and performance tweaks; and others want to take the User Experience improvements from D7 to the next level.
If there's one thing that the last several years has taught us, though, it's that we can't succeed by focusing on a single slice of Drupal's audience (or a single subset of the Drupal contributor community). Going nuts with architectural improvements is a recipe for navel-gazing unless it's guided by the felt needs of site builders, day-job developers, and businesses. Pouring our energy into new theming work, new UX widgets, and bold workflow changes will frustrate core hackers who see cracks in the foundation that need repair. And the idea of a pure "fix-it" release, focusing on fixing key frustrations without adding new features, is a non-starter: Drupal has always needed the carrot of new functionality to bait the stick of API changes. If version 8 included nothing but breaking changes, there would be no reason for the majority of users to upgrade. (And if the fixes don't break existing APIs, why not roll them into a 7.1 or 7.2 release?)
Obviously, pitting these different visions against each other is a false dilemma. Drupal's diverse community of contributors can work on multiple projects at a time! Larry Garfield's refactoring of the hook system wouldn't prevent Jen Simmons from adding HTML5 support to Bartik, for example. But as we move forward into the next cycle of Drupal, we need more than "projects that don't collide with each other." We need a vision for what the future of Drupal holds, a path to get there, and a set of realistic priorities for the next release that get us moving down that path. Above all, we need to keep the final goal in mind: making the software called "Drupal" a killer tool for building multi-user, content-driven web sites.
Three Points of Pain
While everyone in the Drupal universe has their own pet demons (has webchick mentioned support for Signatures lately?) several recurring pain points have emerged over the past couple of years. These issues cause lost sleep, missed deadlines, and endless frustration for people at all levels of the comunity; from businesses switching to Drupal, to shops building distros, to hobbyists bootstrapping online communities.
Missing APIs
The tug-of-war over what should live in core and what should live in contrib is eternal. Some foundational problems, though, are impossible to solve efficiently outside of core. Grafted-on solutions to those problems require duplicating large swaths of core, and risk collisions when multiple teams tackle the same problem separately. Identifying these critical missing links in Drupal's APIs and filling the gaps will allow developers to focus on solving their unique problems rather than wrestling over competing standards. Two APIs that are painfully missing are context and web services.
The first one -- context -- is about keeping track of the essentials when responding to a web request. "What page am I on? Who asked for it? Am I in someone's blog, or in a forum?" and so on. These are all simple contextual questions that must be asked before a page can be rendered. In Drupal core and contrib, there are literally dozens of separate functions dedicated to answering these questions. Two competing mechanisms (CTools's Context, and the standalone Context module) have emerged and found an enthusiastic user-base, but neither can reach its full potential as a bolted-on solution in contrib. The Butler project is a first stab at providing a central context mechanism in Drupal core, and getting its skeleton in place should be one of our top priorities.
The second missing API is a built-in foundation for web services. Drupal's early automatic support for standards like RSS and BlogAPI helped push it ahead of competition that required grafted-on solutions. As next generation standards for data exchange emerge, though, we risk falling behind. In Drupal 8, we can build on the foundation of the Entity API: automatically exposing all Drupal entities in a RESTful fashion would dramatically simplify the work of building desktop and mobile apps, complex cross-site publishing tools, and more.
Deployment
Today, most Drupal site-building consists of clicking small pieces together to assemble complex functionality, and storing the settings in the database. The line between site structure, configuration, and user-generated content has never been blurrier; separating the wheat from the chaff to reuse that configuration work is a huge challenge. In addition, the work of content staging -- creating content on one Drupal site and deploying it to another -- is truly difficult. With more large sites moving to Drupal, and the line between configuration and content blurring, these shortcomings are huge.
The first part of the solution is universally unique identifiers -- UUIDs. Today, quite a bit of our content is identified only by serial IDs generated in the database. Taxonomy term 5, node 92, menu item 103, and user 8 can't be migrated from one site to another, because their IDs are only unique to the site they were created on. Adding "machine names" to many entities like roles and input formats has eased some of the pain in Drupal 7, but we need to take it all the way: things we save to the database need UUIDs or machine names instead of a serial IDs.
The second piece of the deployment puzzle is a built-in mechanism for importing and exporting our configuration. The Views module pioneered this approach, allowing users to build out a complex screen, export the resulting View definition, import it on another site, and embed it into a module as PHP code for manageable reuse. This workflow is now leveraged by Panels, the Features module, and even several APIs in Drupal 7. By leveraging UUIDs and machine names to avoid collisions, and allowing the same import/export/override mechanism to be used with all data, we can take eliminate a huge chunk of the deployment problem.
User Experience
Creating a single user experience that works for everyone is an impossible task. The Drupal 7 User Experience team tried, and generated amazing results: a new administrative interface, streamlined tools for content posting, a fantastic new core theme, and more. The essential nature of Drupal, though, is still the same: it's a box of LEGO bricks for building web sites. To continue improving, we need to ensure that UX work focuses on bite-sized solutions that can be leveraged throughout the Drupal ecosystem.
Drupal's toolbox of UI elements conventions has been growing since the day it was first released: we need to document it and expand it. In the 1980s, Apple demonstrated the value of providing clear guidelines to developers on solving common UX problems. Module developers need to know when to use Vertical Tabs instead of collapsed fieldsets, why they should utilize drag and drop tables, and how to hide unecessary information from novice users. In addition, UX tools that are unecessarily tied to specific use cases, like Color module's color picker, need to be broken out for cleaner reuse. Enhancing and documenting UX Pattern Library for Drupal will pay off in greater consistency throughout core and contrib.
Finally, the addition of Bartik as a core theme has proven that Drupal is much more than a sidebar-content-sidebar cookie cutter. We need a complimentary "minimalist" theme in core for sites that require a no-nonsense, nothing-but-the-content approach. Customizable typography, color schemes, and imagery would take priority over lots of regions: we've proven that Drupal can handle complexity, and shipping with a "zero-cruft" theme would help us balance things out with zen simplicity.
The goal: A better Drupal product
So far, the ideas I've proposed aren't very revolutionary. Context and web services, better deployment and export tools, an enhanced UX toolbox and a minimalist theme for core... Several of these initiatives are already in the works, and the rest have generated considerable excitement among developers and designers looking to contribute. They would provide a compelling bullet-list of enhancements for the next version of Drupal, but they feel disconnected. At the end of the day, what greater goal are we working towards?
The flexibility of Drupal has always been biggest selling point: endless expansion hooks, a huge library of modules, and powerful tools for code-free construction. However, Drupal as a standalone download -- a tool that does something useful the moment you install it -- has been stuck in a holding pattern for years. We're trapped between a desire to add functionality and the need to make it as generic as possible. With the emergence of the "Minimal Install Profile" in Drupal 7, we have a safe starting point for the build-from-scratch folks. In Drupal 8, we can free the Standard Profile from its chains.
Drupal's default installation profile should be treated as a genuine product. It should be unashamed to focus on the target audience that already benefits the most from it: small groups of collaborators who want to share their work with the world, and convince their audience to participate as well. This covers a broad mix of users -- open source software projects, online news teams, community organizers, and more. The tools that come with core are already well suited to this use case: multi-user blogging for the team, RSS feeds and aggregation for collection and distributing news, forums and polls for getting the audience involved, contact forms for soliciting direct feedback, and so on.
For the purposes of this post and my subsequent discussions, I'm going to call this focused "Product" install profile... Tsunami. I think it combines the idea of an unstoppable force with Drupal's water theme, and it's easy to work into jokes about drupal.org's issue queue.
Many of the challenges that have plagued the D7UX team can be simplified by embracing Tsunami's focus. Features and workflow enhancements that are controversial for use across all Drupal sites can be implemented in the Tsunami profile -- perhaps even in modules restricted to the Tsunami profile, rather than the framework-wide modules directory. Allowing both developers and UX team to roll out features in Tsunami even if they aren't perfect for every site will make the default experience better, and free us from the impossible task of building an "Everything interface."
What's the most important principle? Drupal's need for ultimate flexibility shouldn't hold back the evolution of the default Drupal "product," and the default "product" shouldn't force its own requirements onto every other Drupal site. If we're willing to draw the line between the two, we can let them grow in tandem.
Who will fill the gaps?
The idea of making Drupal's out-of-box experience rock always sounds good on paper. But If we start tailoring it to a specific use case, what happens to everyone else? Single-user blogs, enterprise intranets, virtual stores, and online magazines all ues Drupal. Would their needs be overlooked?
For the past five years, the Drupal community has gone through waves of enthusiasm and disappointment over Installation Profiles and Distributions. The promise of downloading a copy of Drupal pre-tailored to your use case is hard to ignore, but today's reality is that building and maintaining a purpose-built distribution is hard work. I believe that the priorities outlined in this document will make that process much easier: improved context management and web services reduce the overhead of building great web apps; unique IDs and a reliable import/export framework will make capturing essential configuration in an Install Profile far less problematic; and a good library of UX patterns will help ensure that core tools can be effectively reused.
Finally, I believe that our long-time insistence on keeping Drupal's default download as generic as possible has actually made the difficulty of customizing it far far worse. Useful reusable tools are often left out of core because the "default profile" has no good use for them, and what assumptions are made about Drupal's out-of-box use case must be overridden with complex workarounds for other applications.
If we accept the idea that the default install profile is a product worthy of attention in and of itself; if we begin to implement features in that profile that can't baked into every other Drupal web site; if we commit to using our own core APIs the way other Install Profile and Distribution developers must use them... Then the process of enhancing Drupal's default product will actually clear the way for other products and other markets. That's what Twitter discovered when they built their API: until they treated Twitter.com as a web application built on top of their API, other users of their API would always be second-class citizens.
I Love It When A Plan Comes Together
That was a mighty wall of text. After all that, where are we? Is there a plan to be found? I say yes. In Drupal 8, we should prioritize:
- Missing APIs: Some of Drupal's most pressing blind spots could be filled by providing a unified "Context" system and exposing all Drupal entities via a RESTful interface.
- Deployment: The pain of managing, deploying, and sharing Drupal solutions can be dramatically reduced with universally unique IDs for all Drupal data, and a standard system for importing, exporting, and overriding those items in code.
- User Experience: The work in D7UX can be extended by documenting and simplifying the use of common UX patterns like color pickers and draggable blocks, while a streamlined "Focus on the post" theme would act as a compliment to Bartik's swiss army knife.
- A Real Use Case -- Tailored to an actual audience, Drupal's default install could empower users with no site-building experience, free the drupal UX team from the tyranny of one-size-fits-all workflows, and reveal areas where our assumptions are crippling other solutions.
None of these items are simple -- each one would be a huge undertaking for any development team. Over the past decade, though, our community has proven that it can do amazing things. Teams of passionate developers, designers, and UX experts have already been working on many of these tasks: working with this plan would simply highlight and prioritize the work that's already going on.
In addition, coordinating efforts between these three major areas will help bring balance and a compelling narrative to the Drupal 8 development cycle: outside observers will know what we're shooting for, why it matters, and what the promise is for those outside the Drupal development club.
This is where I'll be focusing. How about you?
Comments
I honestly think the momentum
I honestly think the momentum is finally there for UUIDs in core. Many peopel have been talking about this recently and I pledge to make deployment (for content AND config) functionality in core my personal goal for Drupal 8. If we can get the export and import APIs in place then we can even leave implementation to contrib. There is plenty of room for a Deploy-like solution and a Features-like solution and a 'synch nodes as files through git' solution or whatever other crazy-ass shit we come up with. As long as we have reliably unique IDs and strong solid APIs we can move mountains. Much of this has been worked out in contrib, we just need to bring it home.
As far as Services-like functionality in core, it is ESSENTIAL for mobile growth. This market is so huge i dont think anyone needs convincing, but it is also an enormous opportunity for anyone producing a Drupal product with a public API as well as helping to encourage open data initiatives in Drupal's many government customers.
So... hell yeah. BRING IT. \m/
Holy shit. I bow down to
Holy shit. I bow down to @eaton, the master of synthesis. Great stuff.
I'm really torn about running wild with the default install profile. When the D7UX were (prematurely) committed, the performance went to complete shit. I'm thinking of contextual links and toolbar. It was then up to a few performance minded core devs to stop the slide and cleanup the mess. Thanks to catch in particular. There is a risk that core devs will finally give up and only mind the performance of minimal profile. This leads to a reputation of poor performance for Drupal which is complety inapplicable to minimal profile. It is not healthy for a product to have one name but two very different incarnations. It needs two names.
Perhaps we throw a bone to the "cleanup core" crowd and give them a colored box? In that box I'd include:
- Reduce/rationalize excessive caching.
- Split menu router and menu links. Find alternatives to menu links (too expensive to rebuild)
- More complete entity implementation
P.S. This textrea says "No HTML tags allowed". Grrr.
I'm still poking my way
I'm still poking my way through configuring the new site -- after a little over a decade of dragging around my legacy content, I made a clean break. Of course now there's theme tweaking and setup tasks to finish. I'll get those input formats sorted out post haste. ;-)
I think you're absolutely correct that performance (single server performance especially) needs to get serious love. While I think the stuff I've outlined in this post capture high level priorities, there ALWAYS needs to be a lot of meat and potatoes work on stuff like standards compliance, accessibility, performance, and so on. Larry Garfield has blogged extensively on architectural priorities, and I think it's worth adjusting our 'flexibility vs. performance' heuristic. Traditionally, we've always chosen the former over the latter and we may need to really weigh choices moving forwards.
First of all, excellent post.
First of all, excellent post. I found myself rarely in disagreement with anything you said. I think most of the challenge here is that because of the dual audience we serve it begs the question "Framework" or "Product" - Some argue that distributions fill the need for the product group and that the slim APIs in core fill the needs of framework. I'm not sure I agree with either but I like where you're taking this and look forward to being a part of it however I can. Very well thought out and a worthy adversary to my otherwise non-blog-reading mornings. :)
I thirsty for such texts,
I thirsty for such texts, great read and inspiration.
I agree with your suggestions
I agree with your suggestions about Deployment in D8. In order to make Drupal a more mature publishing platform, this needs to be in place. Regarding the missing APIs, I feel like this will slow down development of new features for said APIs. That's the problem with moving more into core.
Drupal should definitely be an application built on top of solid APIs. I get frustrated when I try to stage some set of functions, only to find that I have to fake a form submit in order to get my changes ported. In my opinion, form submits should call corresponding APIs that can be tested independently.
Fantastic post.
Fantastic post.
The one other point that I find interesting is the shift from CVS to git in the context of D8 development - does git's superior merge mean that working on several parallel feature branches now become a more realistic? And will that help push forward on API changes as well as UX?
It can -- the git migration
It can -- the git migration will definitely remove a lot of pain points for developers who are working on large core patches, and have to sweat bullets over collisions with other work. But large refactoring is still a challenge because of the interconnectedness of Drupal's APIs and subsystems.
A-frickin'-men!
A-frickin'-men!
"if we commit to using our own core APIs the way other Install Profile and Distribution developers must use them... Then the process of enhancing Drupal's default product will actually clear the way for other products and other markets. That's what Twitter discovered when they built their API: until they treated Twitter.com as a web application built on top of their API, other users of their API would always be second-class citizens."
That's the money quote. If we treat "Drupal the product" as simply an implementation of "Drupal the framework", even if they ship together, it makes both better *and* benefits everyone else, too.
To be fair, many of the above target-points are a lot larger than they sound at first glance. That doesn't mean we shouldn't do them, though; it means we need to put a lot of thought into making sure they're done right, because we won't just be building a CMS on top of them but an application framework *and* a CMS application. (Which is as it should be.) This is going to also mean challenging many of our underlying, fundamental assumptions.
I look forward to it.
"If we treat "Drupal the
Larry wrote:
"If we treat "Drupal the product" as simply an implementation of "Drupal the framework", even if they ship together, it makes both better *and* benefits everyone else, too."
Print that sentence in a very large font and frame it.
I'm not a coder (so I won't have to do any of the work) but that really resonates with me.
What makes UUIDs more
What makes UUIDs more suitable than URIs? (or can the UUIDs be URIs?)
UUIDs can be used in
UUIDs can be used in constructing URIs, but don't necessarily have to BE URIs. I'll defer to the folks who work on UUID and Deploy modules for the details; there are lots of different approaches to the problem but the important part for us is: being able to rely on a thing having an ID that doesn't collide. I'd suggest taking a quick look at http://betterexplained.com/articles/the-quick-guide-to-guids/ for some clarification. It also helpfully distinguishes between 'Uniqueness' and 'Global Uniqueness.'
Machine names are one way of achieving a similar goal -- although there is no assurance of global uniqueness, they are human managed and meaningful, and we can spot collisions if the set is small enough. For large pools of identifiers (like node IDs and revision IDs) auto-generated ones still make sense.
Yes, UUIDs are guaranteed to
Yes, UUIDs are guaranteed to be globally unique, and this becomes extremely important when you're doing things like deploying content from a test environment to a QA environment and on to a production environment. I find that it makes sense to use machine names for things whose names we can control in code, e.g. views, taxonomy vocabularies, node queues (very recently - yay!), etc. But for things like nodes, users, taxonomy terms, which will be created in large numbers and exist only in the database, UUIDs are the way to go (I have a feeling heyrocker would disagree here because I have drawn a line where none really exists). And their global uniqueness is incredibly comforting when you're trying to debug some crazy problem with a botched deployment of several hundred nodes in 10 different languages (yes, I have been there :-/ )
Poor D7 looks like it will miss out on Deploy action unless somebody finds time to port the module (maybe I'll be able to help with such a task if I had some willing accomplices...) but I am very excited at the level of support for UUIDs in core for Drupal 8.
I actually agree with you
I actually agree with you that configuration objects and data objects should be different things. I know heyrocker feels the exact opposite, but I think he's wrong in this case. :-) But a more standard mechanism for both is a good thing, especially if it emphasizes good best practices (machine names for config, UUIDs and local serial for data as heyrocker mentions further down the page).
>I actually agree with you
>I actually agree with you that configuration objects and data objects should be different things.
Agreed, but still I think we should build them upon them same API for CRUD -> entity API. I see not point in having two different storage related APIs if both objects end up in the same database.
After long talks with
After long talks with merlinofchaos I actually support machine names instead of UUIDs in cases where the names are useful (for instance if they need to be used for CSS classes.) Honestly as long as it is reliably unique and we can get consensus im basically ok.
Using resolvable URLs as
Using resolvable URLs as UUIDs would also be a big step toward a RESTful API.
Brilliant post, Jeff!
Brilliant post, Jeff!
Moshe and Larry make some really great points, as well.
D8 should be interesting and exciting with this kind of thinking going into it.
Can I have a pony?
Can I have a pony?
Are you coming to DC Chicago?
Are you coming to DC Chicago? I think it can be arranged...
Also: http://whenisdrupal8out
Also: http://whenisdrupal8out.com/
Wow, that image nearly ripped
Wow, that image nearly ripped the fabric of my time/space continuum.
I think that you hit the
I think that you hit the major targets that need to be addressed in Drupal 8, and I believe that significant architectural changes are in order.
I support using UUIDs, building on our own APIs, devising a better configuration management system, and packaging distributions/profiles built on a compact, but capable core.
While there will be a tremendous challenge in choosing what goes in, and an even greater challenge in balancing competing subsystem approaches, we should try to get consensus on those four items while the seas are calm.
The unstoppable rise of
The unstoppable rise of Mobile Web seriously challenges Drupal -- Eaton already mentioned backend part / services, but there's also a frontend part what is pretty much stuck on desktop era. Should contrib take care of that? Looking at the complexity to create a Drupal mobile-ready site right now http://cruncht.com/417/mobile-drupal-groundwork there contrib support is not there. Is it something core is responsible or it's just the lack of mobile culture in our community? Would embracing, say jQuery Mobile and HTML5/CSS3 change our desktop-stuck culture? Or would be another "Ok, we included jQuery UI to D7 but not really doing anything with it" incident?
That's a great question. The
That's a great question. The backend issues -- what APIs we have, what libraries we bundle with core, etc -- solve one part, but the question of actually designing for mobile, and catering to the unique issues that mobile devices face, is another challenge entirely.
I'm interested in hearing what others think about it -- I know that WordPress has gotten some kudos for shipping with a standard mobile theme out of the box, but I'm not sure about the details that went into its creation.
Tsunami might as well assume
Tsunami might as well assume it has mobile customers and do our best to serve them. So yeah, mobile front-end in core.
Great post!
Great post!
I'm really excited, given our previous discussions about #smallcore, about your proposal of Tsunami being included *in core* and not as a separate download. This greatly helps assuage my concerns from wearing my "community manager" hat about the splintering and fracturing of the core development team. Moshe's concerns are well founded, however, and I think we might be able address this to some extent with additional infrastructure—a "performance" bot to complement the testing bot, perhaps?
The only area I find myself in disagreement with you on is Tsunami's proposed target audience. And I imagine honing in on this will be the source of many vigorous debates over the next few months. :)
This might sound good in theory, but the practical effects of this would be a dramatic change in the makeup of our community. It means transitioning from a community of builders, developers, tinkerers, and innovators to a community of users. It means at DrupalCons, instead of having sessions about HTML 5, RDF, Features, building distributions, performance and scalability, etc. we have sessions about "How do I post a picture in my blog posts?" and "How can I ban users?" And even if we decided this was desirable, in order to get from here to there, it also means undoing 10 years of preconceived notions that Drupal is not for end users like WordPress is, but instead for site builders and people with some kind of web development experience (or those with enough of a geek-streak to pick up a few tricks).
So I'd rather not focus on trying to make Drupal an out-of-the-box tool for random janes and joes on the street who want to spend 30 seconds installing something and have a usable site. WordPress does that already, and it's always going to do it better than we ever can because it's not also trying to be a generic web framework that can run IRC bots, issue queues, and automatic testing infrastructure. Instead, I'd rather focus on making the default Drupal installation geared toward our existing target audience, only serving them much, much better than we currently do. Providing more and better site building tools in core. Providing streamlined interfaces, tutorials, and other things that can help guide people through the process of learning "The Drupal Way" and shortcutting a lot of frustration with the current default profile's inevitable, "Uh. Ok, I installed it. Now what?"
I get really excited about Tsunami's target audience being me (or you or catch or...), but 5-6 years ago before we were Drupal experts and trying to evaluate a decent starting point for our projects. But I want to absolutely run away and hide about the idea of Tsunami's target audience being my mom and dad. Let the framework improvements for distributions handle those other audiences. Let's focus on ours.
If I may completely blow your
If I may completely blow your mind...
There is a principle in API design that you never know if you Did It Right until you have three implementations. Specifically, three different implementations.
So, imagine not one but three profiles/applications that ship in core: Minimal (for the high-end site builder who wants just the framework and nothing else), Tsunami (for the newer site builder who expects to follow up with Views, et al), and "Wordpress" for, well, the click-and-drool blogger. Or some other "mere user", or however you want to call it.
If the core framework is able to cleanly power all three, without ugly hacks... then we've done our job well.
And, with the Power of Git, we could actually pull something like that off and they wouldn't have have to all "live in core", because that word means something else. :-)
Well said, everyone! And here
Well said, everyone! And here goes Joel again with that old gem of "modular installation profile wizards". Stand back. :)
INSTALLATION OPTIONS:
1. Install the minimal set of tools (great starting place for Drupal developers)
2. Install a basic Drupal site with features that most people like.
3. Let me customize my installation
- Would you like a blog? [ ]
[ ] Just for you?
or
[ ] A blog for multiple people?
- Would you like forums for your users? [ ]
- Would you like to pull in content from other sites using RSS feeds? [ ]
Keep in mind that this is entirely do-able, and the fantastic people of Gravitek Labs pioneered the "Let's make an installation profile that pulls together a bunch of other installation profiles during installation, based upon what the user wanted" method. Yes, folks, I'm talking about Patterns. :) Use the concept, and you gain an OS-like installation ability *each and every time* you install a Drupal site rather than being limited to three preconceived notions of how things should be.
Let the user tell you what type of site they want? Now that's something I'll bet a lot of people could get excited about!
Thanks for responding! I had
Thanks for responding! I had a feeling I'd flush you out of the brush with this one. ;-)
I think that the idea of the "Tsunami" profile is probably one of the elements that will be most debated. Not its existence, but its target audience. The important thing to keep in mind is that NO install profile could actually cater to you, me, catch, chx, etc., even five years ago.
I'm a big skeptic, actually, of the idea that there is a "generic" site builder out there, the platonic ideal of a Drupal user. All of us, no matter how new to Drupal or how nerdy, are building specific sites with specific needs. While there are certainly tools that can benefit everyone, how we use them in Drupal and how we leverage them varies wildly from use case to use case. We can improve the UI for editing a taxonomy term, but showing people how to do useful things with taxonomy requires a better idea of the final goal.
It's that area that we've consistently failed in, at least with the core experience. We iteratively refine the tools, but are afraid to show what can actually be built with them because we're uncertain about the purpose of the profile itself. Is it a toolbox for professionals who know Drupal inside out? Is it just a nudge in the right direction for people who need to understand nodes, fields, and users? Often, the best introduction for new users is a working example that actually does something useful.
A case in point is the classic "Pet Store" application that was implemented in Java as a demonstration of the system's capabilities. The idea wasn't necessarily that all Java developers wanted to build pet stores, but that it was a useful example that demonstrated how lots of common things (from authentication, to templating, to page caching, to database access) should be done in the language.
It's examples like that that convince me a real use-case-focused Install Profile would be a much better learning experience for new site builders than a purely generic setup.
On using the core install
On using the core install profile as a learning tool -- completely agree. As a solo Drupal developer, I've had trouble finding ways to continue to learn about advanced Drupal techniques since I've mostly left the normal Drupal books behind now. The rise of the many professional Drupal distros in the past year have been a godsend as I've learned an enormous amount tearing those apart and figuring out how different things were done.
webchick: Drupal has NOT been
webchick: Drupal has NOT been a non-end-user product for 10 years. We can argue about the exact level of enthusiast needed, but I found Drupal and got excited by it by installing it and using it as a product. Not as a toolkit that I could *build* a product with.
Just as eaton followed up, what exactly the target market is, is completely up for discussion. But building it for site builders (mythical generic site builder?) is definitely the wrong approach.
If we're not going to make a Drupal out-of-the-box experience targeted at something (which sitebuilding is not, then we can give up now and retreat to framework land.
Just another thumbs up to the
Just another thumbs up to the importance of Drupal the Product using APIs from Drupal the Framework. I know Dries blogged about having two D8 maintainers. Has anyone heard if that is still the plan?
I do worry about the performance hit of UUID's on the database side. I was just reading in "High Performance MySQL" that non-sequential UUID can really slow you down. Has anyone tried replacing the current serial ids with UUID's and done any benchmarking?
The way I would solve this is
The way I would solve this is the way I did in Deploy - keep serial ids in the tables and put UUIDs in lookup tables. That way you can use them when you need them but not much else changes. Also it makes the upgrade path wayyyy easier. I do have a local fork of D7 using UUIDs but it is not quite there yet, and I plan to make it available for this purpose at some point.
I am very happy to hear about
I am very happy to hear about using a "lookaside" table for uniqueness instead of using UUIDs as the primary key, precisely because of performance. On export only the UUIDs are included and on import cross-references are resolved into local serial ids. The UUID to local id translation is also saved in an incoming lookaside table, allowing future merges from the same source to override the previously imported content (e.g. same serial ids instead of new ones). I've been suggesting this idea since... Barcelona, I think. :)
If we can nail it without killing performance, Drupal will have achieved the "distributed version control system" of content staging. Pretty cool.
I'm also not opposed to clearly delineating content and configuration. But so long as the "About Us" node is going to be developed and staged internally, and thus views as "configuration", while user-generated content also lives in nodes, we'll never have 100% separation between content and config from the site admin's point of view.
So Eaton -- is this your
So Eaton -- is this your announcing your candidacy for becoming a Drupal 8 core maintainer :)
I'd hope so. And the glowing
I'd hope so. And the glowing comments are a strong signal to Dries to oblige.
Great analysis! I very much
Great analysis! I very much agree with you that strengthening our APIs is the key to Drupal's success.
While re-evaluating architecturial decisions, refactoring subsystems and polishing APIs won't add any new feature to "Drupal the product", it would improve "Drupal the framework". That way not only anyone building their own product with Drupal benefits from better APIs, moreover it would help to ensure that Drupal the product can evolve. Solid APIs really are they key for being able to innovate fast, and so they are for Drupal's long-term success.
>"Adding "machine names" to many entities like roles and input formats has eased some of the pain in Drupal 7, but we need to take it all the way: things we save to the database need UUIDs or machine names instead of a serial IDs."
Exactly! So we need a common API for all our data -> the entityAPI. Then integrating import/export or deployment capabilities isn't hard any more, e.g. the d7 entity API module already allows one to define an entity type to be exportable (ala ctools).
>"In Drupal 8, we can build on the foundation of the Entity API: automatically exposing all Drupal entities in a RESTful fashion would dramatically simplify the work of building desktop and mobile apps, complex cross-site publishing tools, and more."
Again, agreed! That's really something Drupal should be capable of out of the box (butler++).
I wanted to introduce this in a separate blog post, but anyway it's exactly the idea behind:
http://drupal.org/project/restws
(For more about that, please stay tuned for my blog post)
Thanks for the comment!
Thanks for the comment!
I like entities too -- although there are a LOT of rough edges that need to be filed down before we can build much on top of them, they're a very promising tool for the future. However, we need to be careful that they don't evolve into a clumsy "everything and nothing" abstraction, or even worse a poor man's OOP inheritance.
Entities can't be the mechanism by which EVERYTHING is persisted to the database, or the sole mechanism for data discovery in Drupal. Either our complex cases would be crippled, or our simpler use cases would be weighed down by the complexity of the system.
As with all code, the devil is in the details. I'm looking forward to this year's Drupalcon, when we can all argue about them in person! ;-)
That module looks pretty
That module looks pretty great. Looking forward to the blog post.
>Entities can't be the
>"Entities can't be the mechanism by which EVERYTHING is persisted to the database, or the sole mechanism for data discovery in Drupal."
Yes, the entity API won't be able to cover everything, but it can become our main data API.
Anyway most important, we as the community, need to agree upon what the API *is for*, in order to be able to do it properly. Are entities just more general nodes, or something different?
Personally I'd like to see the entity API becoming our long missed data API, thus having a common API for storing things, while other stuff can be built on top of it.
Two more additions: We need a
Two more additions: We need a real search framework and a better help system in D8.
Search framework: a way for things like Solr etc. to not all have to build the same pieces as the core search module, and for the core Search module to be a framework with pluggable pieces.
Help system: something that documentation writers can maintain.
These are both being discussed...
Search++ Context++
Search++ Context++
Also I'd like to be involved in poor forum module refactoring
Having "tsunami" or any other install profile as usable out-of-box would be great opportunity
This is pretty much crazy
This is pretty much crazy awesome. I nominate this as Drupal post of the year.
What Larry Garfield said up there about 3 profiles/target audiences is pretty tight too, that lines up well with the twitter.com on top of twitter API's thinking...
Also...one of the install profiles should surely be called alltherewebarebelongtous!
Great post, Jeff.
Great post, Jeff.
The one thing I'd like to add is what I think is the most important missing feature of Drupal 7: The fact that it did not exist in 2009. In my view the D7 development cycle was a near-death experience for the entire Drupal project; I think we came perilously close to never releasing at all and only came through due to herculean efforts from our truly awesome community. Let's not take that risk again.
So, my $.02 to this post: It all sounds like good stuff, but D8 should only include what can be developed, tested, profiled, and released on January 5, 2012 ("Drupal Day").
PS: Oh, and let's move every column of the node table into its own separate table for good measure. :-) <ducks>
If we work on product in
If we work on product in parallel to framework, you have a "consumer" that needs APIs to work, flushes out gaps, and it means we don't spend the last three weeks of code freeze frantically deciding on a few defaults in the .profile file.
I don't know if I entirely
I don't know if I entirely agree with this. I do agree that the cycle took a year longer than it should have, in the end, but I see almost no evidence of a 'near death' for the project.
Drupal related activity everywhere continues to rise.
New Drupal-built sites launch regularly, many of them high profile.
New players enter the scene.
New money comes into the project.
If anything, the relative stability of the Drupal 6 platform helped this. The one downside is that anyone who adopted after 2007 does not know the sheer pain of constant upgrades that existed in the years prior.
Do you remember the constant stream of arguments about the drop always moving? I do. Those arguments invariably were harmful. The pain of upgrading pushes existing sites to different platforms. Seeing the pain of upgrading very openly adds caution to people who want to decide to adopt the platform.
I suspect there will never be any such thing as a smooth upgrade from Drupal 6 to Drupal 7.
I'm on the fence on this one.
I'm on the fence on this one. While I certainly agree that the three year cycle was frustrating for people waiting on D7 features, and harrowing for the developers who were neck-deep in the actual development work, the maturity of the 6.x branch shouldn't be overlooked. It's no coincidence that D6's three years in the sun saw a huge increase in Drupal's installed base, a flourishing business ecosystem, massive growth in contrib, and a blossoming list of books that stayed relevant.
Many of the large enterprise clients that signed on during that period have never had to work through a major version upgrade on a heavily customized site. Given the trailing cycle of contrib catch-up that naturally follows every new version, releasing version 8 less than a year from now means that D6 would be EOL'd before many sites can even think of upgrading to D7.
While I definitely agree that another three year long cycle would be painful for the core dev community, I think it needs to be discussed at length and not treated as a pure scheduling issue. A couple of different initiatives -- from elevating the status of subsystem maintainers to allowing non-breaking API additions in point releases -- may be able to reduce the trauma of our major version cycles are.
P.S.S.: Tables? I totally heard they're not web scale. ;-)
Even just in relation to the
Even just in relation to the development of Drupal 7 itself, the three year cycle had tonnes of advantages and disadvantages. Mapping these out is probably enough material for another blog post, but in lieu of that:
We had enough time to put in major API changes like dbtng and field API /and/ to apply these somewhat consistently to large areas of core. This means that several critical areas of missing functionality were added prior to release, instead of in Drupal 8, or not at all. The poster boy for this /not/ happening in Drupal 6 would be actions - where the main patch was committed just prior to code freeze, so there was no time to convert any subsystems, and then people's focus shifted in Drupal 7.
Fieldable users, taxonomy terms, comments - and the massive cleanup required to make those possible, could only happen consistently with sufficient time to work on both the initial field API patch and the followup work in one single release - since nearly every one of the 'make X a field" or "make X fieldable" in turn required bug fixes or performance improvements to the field API. Some things like profile module didn't get done in time, other things like the entity API are rough and incomplete - but 'entities' wouldn't exist at all if we'd had a hard code freeze a couple of months after fields went in, and the code slush and long freeze also allowed things like new hooks and EntityFieldQuery which have allowed for filling out some of the gaps in contrib - along with sufficient momentum that there's a lot of desire to follow up as soon as Drupal 8 opens up.
On the negative side, the two things that contributed most to the release cycle extending beyond expectations (and patience and stamina for many people) were the 'critical issues' backlog, and 'things not covered by automated testing' - there might be others I'm forgetting, but those two really stick out:
The untested
.We added automated testing, that worked for pretty much anything apart from front end (javascript/cross-browser/RTL) and the upgrade path. Hence most of the final remaining critical issues were with: front end and the upgrade path - and the upgrade path only got fixed once we added automated testing for it. This was partly because automated testing limited the range of really horrible release blocking bugs elsewhere, it's also because automated testing almost eliminated any manual testing of core during the release cycle, so bugs without code coverage got overlooked. Another issue with the upgrade path is that this was the second release where Drupal.org didn't run on a release candidate. To an extent this role (of large installation running a release candidate) was being handled by Examiner and Drupal Gardens, but neither of those needed an upgrade path from Drupal 6. Damien did some Drupal.org upgrade testing towards the end, but that was entirely optional and down to his own initiative rather than a requirement for getting the release out.
'Critical' issues
At one point we had over 400 critical issues in the queue - a lot of these were 'add tests for X' during a sprint a few weeks after simpletest was committed, and when Dries was using that as bait for a longer release cycle (I admit guilt for creating some of these). However the focus rightly went away from just adding code coverage to trying to add tests for specific bugs and regressions, so all those issues ended up doing in the end was swamping the /real/ bugs queue.
Having 400 critical issues in the queue, meant that the 150+ issues that were actually critical, were completely obfuscated, so it was only massive manual clear outs of that list, then the addition of the 'major' priority, that allowed us to identify what the actual release blockers were. This meant that there was never a proper list of release blockers until right into the last few weeks or months of the release cycle, and some of the really gnarly ones fell under the radar for a long time due to this.
Since we're entering the Drupal 8 cycle with the 'major' priority, and upgrade path testing, I'm hopeful that critical can be reserved for things that are actually really horribly critical broken, rather than just really critically horrible. If we could then keep the criticals list under control, we'd never be more than a few months from release - we might not want to release with certain things half-done, but it would be feasible to put a release out there without having to spend months (about 12 of them if we count from the end of code slush) cleaning up the previous damage.
How many modules in contrib
How many modules in contrib haven't been ported to D7 yet? In another year, what will that number be? Drupal as a project will fail if contrib can't keep up.
This is a problem whether we
This is a problem whether we have long or short release cycles though:
short cycles means porting more often
long cycles means porting is a bigger task
compare these three pages:
http://drupal.org/node/64279
http://drupal.org/update/modules/5/6
http://drupal.org/update/modules/6/7
Call security. I think that
Call security. I think that Donald Lobo has hijacked Barry's comment.
Great post. It is a good
Great post. It is a good summary of what many of us have been thinking (including myself), what I've been talking about, and what we feel is logical path forward for Drupal 8. Of course, there is a _lot_ of details to fill in ... When I talk about these things to others, I have a slightly different framework to present these goals. I'll try to write it up, either as a comment or as a blog post.
Thanks! One of the challenges
Thanks! One of the challenges is that there are lots of potentially logical paths forward, and choosing between them has always been a weak area for our community. We often fall into the trap of wish lists and feature creep, lacking a coherent narrative for a release's goals.
As you noted, none of the things I mentioned in this post are particularly earth-shattering: it's mostly a filtered list of things that are already brewing. All of the enhancement proposed are complimentary but few depend on the others for success, and in my opinion they would offer tangible, measurable improvements for almost everyone involved. One of the improvements you've talked about numerous times over the last few years -- a Wysiwyg editor in core -- feels like one of the hottest priorities for the 'UX Toolkit' portion of the project.
Of course, I make no apologies for my presentation of it being biased by my own ideas of what would work best. ;-) From our past conversations, I don't think we're too far apart in our ideas. I'm definitely looking forward to your thoughts on the upcoming cycle!
I throw this out there --
I throw this out there -- naively -- because I have LONG wondered why Drupal does not work like this this: Is it not possible to create the ability to write ALL configuration settings to file rather than database, so then we could easily put them all into GIT and copy them into different installations (as we can do with Views)? Then, to make it even easier, it would be great when importing settings to be able to read in the new settings and have them display side by side with the previous settings and then checkbox select which version we actually want to keep (with a global default option selectable as well).
Good question, Chris. To some
Good question, Chris. To some extent we do have that capability -- the settings.php file can include hard-coded overrides of system variables, and the import/export initiative that I mentioned in the post is a tool for doing just what you described. As Views, Flag, ImageCache, and other modules have demonstrated in the D6 cycle, data that can be reliably imported, exported, and overridden can also be embedded easily in a module's code, avoiding the trap of configuration-in-the-database.
The challenge is that lots of stuff in Drupal just can't be imported or exported cleanly. That's where the UUIDs and machine names come in: they dramatically simplify the process of importing and exporting, because they all but eliminate the chance of accidental collisions.
The other problem is writing
The other problem is writing out code. In general you can either:
1) Have your configuration in code, which means it's easily versionable but you have to be able to edit code (or a complex config file that may or may not be in PHP) on disk to change it.
2) Have your configuration in the database, which meas it's easily editable in a nice GUI by anyone with the right permissions but cannot be sanely versioned.
But you cannot realistically have both. There are various attempts to do so, such as strongarm or views exports, but they all run into a key problem: What happens if configuration is in both places? Views et al take the position of "database wins, and it's up to you to move stuff back to code; don't forget." Strongarm takes the position of "code wins, suck it site admin!". Both of those are legitimate answers for some use cases, but problematic in others. (Editing a View directly in code, for instance, is seriously not easy...)
And you cannot have the GUI automatically write back to the disk, as that's a security hole.
Wider use of machine names and UUIDs would make the Views-style export easier and cleaner, but does not yet allow us to have our cake and eat it too.
I don't believe this is
I don't believe this is correct about strongarm (at least, version 2.x). You can override variables in the database, which takes precedent over code - I think strongarm just tries to smartly replace Drupal's defaults.
Correct. Strongarm 2.x
Correct. Strongarm 2.x inserts variables that are not already present in the variables table (or at least the variables array at the time strongarm checks for existing variables).
This post is a great call to arms. ++
If we introduced a "developer
If we introduced a "developer mode" we might re-consider "And you cannot have the GUI automatically write back to the disk, as that's a security hole." Such writing would be an extremely useful tool when developing locally.
We already have those kinds
We already have those kinds of tools to some extent in modules like Views, and the Features module is about as close as it gets to automating the config-to-code process right now.
There thorny problems involve dealing with the bits of configuration in core and contrib that don't lend themselves to this. Data without reliably unique keys, or "configuration" like CCK fields that ripple out to real schema changes rather than simple data value updates. Solving the former will be a big help, and while I'm skeptical about solving the latter in a single release cycle, it would certainly delight me. *grin*
A very thoughtful post,
A very thoughtful post, thanks! I am pleased to see your clarity on how UX plays a role in all this, it's a part often left out in discussion about Drupal 8. I have a lot ideas, but I will start with a bunch of questions first :)
I only have a few comments on the UX part, 1) the UX library, will happen just needs help - I initialized it but with no funding or help, it will happen very slowly. 2) A simplistic theme, I see no reason why not.
The product part is what actually intrests me. Too often do we link flexibility with what can happen in "Standard profile", this shouldn't be the case - and more often than not it's a current technical limitation and implementation mindset that needs to change. I believe this seperation will become far better in D8, it will also make it increasingly harder to justify any UI optimalizations(module or not) that are in both profiles.
I see no reason to call it Tsunami, to me this only adds confusion. However you mention, we have to embrace it's focus - how do you define its focus? What is the experience we want, in say 5 years using this profile? It's a large, seperate discussion - which probally deserves a whole serie of blog posts, but I feel in terms of UX that is the discussion we should be having.
Nonetheless, a big concern is creating a divide - where we lose a whole lot of firepower when the majority of our core developers never see Standard anymore, thus don't care. To create a good UX, reaility is that we need this exceptional firepower - update manager is for example one of them. Creating interface elements that transend profiles, helps with this - but it's a though balance to find, how do you envision we make this work?
Excellent questions, Bohjan -
Excellent questions, Bohjan -- I really appreciate you jumping in, as I know you've been an instrumental part of the existing UX work and you've been able to articulate some really important concerns about the previous #smallcore discussions from a UX perspective.
I agree that the timing of the UX library work will depend entirely on the resources available. One of the reasons I think that focusing on defining and refining key UX patterns can help is that it can be done in a bite-sized fashion. I've talked to a number of people in the community who are interested actually working on the project, and I'm hoping that treating it as an ongoing piece of the Drupal puzzle, rather than a single sprint, will help us in the long term.
I also agree wholeheartedly that there are tons of details to iron out with the idea of the standard profile and what it should cater to. ('Tsunami' was more of an off-the-cuff code name than a suggestion for product branding, btw -- I'm a sucker for code names.) Defining its focus is difficult, and the fear of alienating both new users and old hands keeps us deadlocked many times. I arrived at the (admittedly loose) use case for the profile by looking at the stuff we currently ship with Drupal core and asking, "What kind of web site would be able to effectively leverage all of these different tools, but wouldn't require additional contrib modules to be useful?" The idea of a tool for small groups that want to promote what they create, recruit others, and coordinate amongst themselves seemed to fit the bill.
I absolutely agree that we need to avoid turning the standard profile into a ghetto. Part of the solution is about how we, the people who work on Drupal, treat that component of the system. In many ways, participation is driven by the respect that we extend to those who work on pieces of the system. Treating it as a high-profile opportunity to show off what Drupal is capable of, and a chance to make Drupal more valuable for an often-neglected use case, could help. Treating it as a glorified "test post" would obviously discourage involvement by the people who could make the project thrive.
At the end of the day, though, it's going to need a lot of serious thought and I don't have canned answers for most of the issues you've raised. As you suggest, it deserves its own conversations about both focus, methods, and implementation. I'd love to hear the many ideas you mentioned at the beginning of your comment. ;-)
I think this resistance to
I think this resistance to ghettoisation is why webchick wants to see the core product focus on site builders - i.e. getting the very commonly used site building tools into core and improving the ones that are already in there. As opposed to trying to create a polished distribution in core for a particular kind of site.
While there is no platonic 'site builder', there's also no platonic blogger, community site or any other category, so I'm not sure this poses all that many more problems than trying to fit a profile in core for one of those categories.
I think you're correct that in theory they're not mutually exclusive, however in practice they might be - in terms of resources and focus in terms of getting them done.
This also feeds into the maintenance argument - a lot of people who start out as 'site builders' clicking things are the first to find bugs, test patches etc., and they may also pick up development skills, write documentation etc.
There is a definite path from that kind of end-user from consumer to contributor - and it doesn't matter what kind of site they're building really. This is what webchick means by the 'webchick, eaton, chx or catch five years ago" category. I also know a few other people from that generation of Drupal users (4.5-7 or so) who cite taxonomy module as the main reason they downloaded it, there was a lot of flexibility there compared to other systems, and it was available without writing code. I'm sure CCK and Views have the same pull now - and they also have very limited corollaries in other free systems, even as those started to catch up with taxonomy module a year or so ago.
I'd like to see 'Drupal the framework' matching the needs of current developers better - missing APIs, more consistency etc. - a by-product of this would be an easier learning curve for developers coming from other systems. Even if we retain some of our idiosyncrasies compared to other systems (and I hope we keep the good ones), just having internal consistency would help people learn them quicker. Doing this also means we'll see more projects in contrib that build on core APIs instead of having to replace them or work around/against them entirely - i.e. context and panels vs. block module, entitycache vs. advcache. Doing that will make it easier for new developers to understand things, and easier for contrib developers to chase HEAD (and hence catch limitations in core before they're stuck with them for a release).
Similarly, if 'Drupal the product' matches the needs of site builders better - i.e. being able to build more of a site out without installing contributed modules because many of the generic tools are included, then we might see more people start to actually build sites before final releases come out - supporting head-head upgrades a little earlier would help that too of course.
So this isn't mutually exclusive vs. Tsunami, but there's a huge difference in terms of maintenance and social effect between putting something generic in core like Field API and UI that hundreds of thousands of sites will use, compared to a module in profiles/tsunami that by design will only be used on sites installing the default profile. We're talking a few dozen/hundred lines of code instead of thousands (hopefully) but the principle stands. Now personally I haven't used Field UI for ages, because field_[create/update]_[field/instance]() does everything I want, but it is on a spectrum of usage that doesn't exist for something trying to cater to specific kinds of sites.
This also circles back to Crell's aphorism that the target audience of Drupal is Drupal shops, which is reflected in Leisa's later comment that the target of Drupal core is developers. There are valid reasons to work against those tendencies, but there are also valid reasons to accept them.
I'm totally up for working
I'm totally up for working against the Drupal is for developers/Drupal shops argument but I think we have to resolve the incentive problem first. What will motivate lots of good people to work on features/functionality that they no longer require? As long as we have a realistic and compelling answer to that question, then I'm all in for designing and building an amazing core experience for site builders. (In fact, I have one half designed from D7UX days that was killed off for precisely this reason).
I think saying Drupal is for
I think saying Drupal is for Drupal shops is a bit different from saying Drupal is developers. Or if we say Drupal is for developers, then to a large extent that needs to include medium-advanced configuration as well as actual coding. Didn't make this point well in the original comment so I'll try to clarify a bit.
Just about any Drupal site that can be built at the moment involves at least some clicking around interfaces, because as mentioned already on this thread it's not possible to define all configuration in code - and sometimes defining something directly in code is a lot harder than defining it in the interface and exporting it back out to code - no-one builds views by hand in PHP for example (/me waits for someone to pop up who actually does that).
There are definitely some individual developers who don't spend much time configuring things in the interface, but that will generally be because they work at a Drupal shop which is sufficiently large that their colleague is doing that, because they're working on a large service like Drupal Gardens that's not a site, or because they work on specific areas (migration, performance) across a lot of different projects. Those people probably don't spend all that much time in core/contrib interfaces, but they're still a fairly small group at the moment. For people who are coding all the time, it doesn't really matter too much what the interfaces look like - as long as it's cleanly separated from the API (so they don't have to dive in and out to get anything done) - this is something we need to do anyway and comes under cleanup/better APIs.
However there are plenty of people who build Drupal sites, who likely know HTML, CSS, some PHP and/or JavaScript - so meet the general description of web developer. However when they're building Drupal sites, are mainly clicking through taxonomy, views, cck/fields, workflow, context, panels, rules and the rest. When/if they resort to PHP, it will be in areas like theming, bug fixing, or adding small bits of custom 'glue' code to fill in the gaps that the generic site-building modules don't quite cover. This is a massive group of people, and includes plenty of those who work at Drupal shops, and a lot of core contributors as well.
This post http://nodeone.se/blogg/the-drupal-learning-curve-a-configurators-view describes the learning curve of that group quite well, it also makes this point:
Which is very true - there are a lot of concepts (nodes, entities, fields, taxonomy, relationships) that both coders and configurators need to understand to do their job well, but there's also a point where these converge - but this is at quite a high level for both groups.
So 'configurator', while I don't think it's that widely used even in Drupal, is basically a Drupal-specific sub-category of developer in the same way that 'themer' is. When I think of site-builder, I think of that task - trying to build functionality to meet some kind of goal, from lots of bits of lego like fields and views that are very abstract. Since this isn't a hard role or job-description, it still includes people who only ever use interfaces, as well as those who work on building the interfaces.
As we make it more possible to develop Drupal sites directly in code, and Drupal 7 went a long way towards this, although not nearly far enough, we'll see even more divergence than there currently is between coders and configurators as distinct groups of people with different needs, but that's a long way off, and I think the maintenance issue is moot for a while yet - at least if we're talking about the interfaces of staple modules like Views, Field UI, taxonomy and similar both in and outside of core where currently there's not that much opportunity to avoid them completely even if you wanted to.
"If 'Drupal the product'
"If 'Drupal the product' matches the needs of site builders better - i.e. being able to build more of a site out without installing contributed modules because many of the generic tools are included, then we might see more people start to actually build sites before final releases come out..."
I think this might be a separate question entirely. I arrived at the Tsunami concept by asking myself, "What full-featured, non-blog-oriented site could be built only using core modules?" While i could be mistaken, I think this gets to the heart of what Dries has said before, that the "Drupal Product" must be one that's useful as a standalone download, just just as a starting point for accumulating plugins. That's been the rationale for modules like Book, Poll, Forum, and Blog remaining in core even though many many experienced devs and site builders immediately disable them and more to more flexible solutions.
I also don't think that convincing people to build web sites before a version of core ships is the best solution to our current problems. For developers, having a real-world-use-case install profile built into core can serve as the harshest of automated tests: if that profile doesn't work, or if maintaining it is a Herculean task, it's a sign that something is broken, either programmatically or conceptually.
I suspect that this -- like many of the interesting stuff people have raised in the comments here -- will probably need its own discussion as well. ;-)
Well this is the thing though
Well this is the thing though. If you have blog module in core, then you can build a site that uses the functionality blog module provides. If you have the tools to create blogging functionality in core, then you can still build a site that emulates the functionality of blog module, but you can build other stuff too.
If we call Drupal lego, then blog, forum and poll are currently Sylvanian families houses. You get something with a bit more shape to begin with, but you still need to buy a tonne of accessories to avoid them being empty shells, and it's not remotely as interesting as lego after five minutes of playing around (says the man with the four year old).
So Drupal the framework, and the big areas of framlication like fields, these should be evolving to the point where we don't have modules like blog, forum, poll that do a massive amount of their own heavy lifting, to provide what is in the end very limited functionality.
We might want to keep blog, forum and poll features in core, but they should move towards thin wrappers around the tools that people actually use. This would also increase the educational potential of an install profile - since you could look at the innards and see how it's been set up (whether it's API calls or exported configuration), instead of trying to figure out hundreds of lines of what is still often spaghetti code.
This is an important distinction, because if we do want an actually functional install profile like Tsunami in core, then we need to figure out how to get there. One of the complaints with d7ux, which in large part was down to timing IMO, was that a lot of new features (dashboard, overlay, shortcuts, toolbar) were added to core that didn't bring with them new or refactored APIs, nor expose rich APIs themselves - this means we still have major issues open against dashboard after release due to it having to work around block module limitations that have been there since 4.7 or earlier.
So if we're going to do this, I'd really want to see serious efforts on cleaning up the components that'd make up such a profile, before trying to add new features onto them to flesh things out.
I don't think there's much disagreement here necessarily, but for me the process of how we might meet these end results is a real concern.
" I'd really want to see
" I'd really want to see serious efforts on cleaning up the components that'd make up such a profile, before trying to add new features onto them to flesh things out."
After a few years being convinced that we had to start with framework and end with product, I've decided that I was wrong. We've spent a long time doing that -- as long as Drupal has been around, really. One of the reasons that I would like to see us attempt it from the other direction is the need for something to focus our inherent tendency towards abstraction.
In a way, I'd like to see the Tsunami profile as a challenge -- a challenge to build something useful for a particular purpose (not ridiculously narrow, but with much more focus than 'Generic Site Building') using nothing but the tools included in core. If it turns out that the tools we have in core are insufficient for the task (either from a functionality standpoint or because the APIs are too difficult to manipulate from an install profile), that can directly drive what we know must be fixed. Obviously, not all improvements to core have to be driven by the Tsunami profile. I'm just becoming more and more convinced that using that approach will really anchor the improvements in what site builders are doing in the real world.
I probably got ahead of myself talking about the potential for code and modules specific to that profile; at least at first, especially for the next development cycle, I think it would be a good exercise NOT to do that. IE, to stick to the just-a-profile, just-config approach.
Sometimes the solutions are complex (like gutting the block system and replacing it with something more flexible). Other solutions could be much simpler -- for example, giving Book module a mode that lets it display the teasers of child nodes rather than an unordered list of titles. For small to midsize sites, just that feature would make building dynamic listing pages quite a bit easier.
That's just one example, obviously -- and as always the question of whether a given task should simply be left to contrib is worth asking. The two extremes (jamming the top 10 contrib modules into core vs. stripping it down to a bare, module-less framework) are nonstarters. I'm trying to figure out how to split the baby. ;-)
I can live with coming at it
I can live with coming at it from both ends, but if we want to do that, then we'd need to do 'design first' - so a proper spec for the profile before jumping into implementation.
A big issue with d7ux was the contracted schedule (only 6-9 months at most), meant that there was hardly any time between the first drafts for specific interfaces/features, and beginning implementation. And then only a short period between beginning implementation and freeze- much of the implementation having to happen as code slush exceptions.
But I still agree with webchick on this, when it comes to user experience in core, I would value usefulness first, usability without that just means people outgrow things too quickly. Not sure where the distinction came from but this site has a good overview:
http://www.bohmann.dk/articles/useful_features_are_not_always_usable.html
If we optimize for site features out of the box first, rather than site building out of the box, then we run a real risk of creating something that falls into "low usefulness, highly usable" - and it's that experience that leads to the maintenance burden that comes along with all those bits of core that no-one really uses.
+1 for designing the product,
+1 for designing the product, and then configuring / rewriting components to fit this - it's iterative, people!
This may also be a case for advancing actions or just moving to something like Rules, because any reasonably full-featured profile will have to make some decisions about "what to do when" that don't make a lot of sense being in core modules - which is the complaint about the multi-user Blog and several things that are in (or were removed from) core.
Thank you very much for
Thank you very much for writing this up Eaton.
Context and Services seem like must-haves for a framework with aspirations to being an operating system for the web. Sample product: A hyper-focussed mobile app around node/add: "Tissues – integrates twitter with the issue queue."
Deployment: what a great opportunity for the elephants to really step into the room and help solve the Seriously Huge Website Operations scenario at the core. Big issue for the big players. Sample product: drupal.org
And of course a bit more on the UX part :)
You're right in seperating the UI pattern docs from the Real Use Case topic. The first is about documenting the lego blocks. The latter is about which one of those we put in a nice box together so that you can make a tractor (or bulldozer or forklift), but not a helicoptor or a lawn mower.
A slight semantic nitpick: It would help me frame both discussions better if we use the User Experience moniker when talking about the Product use case. "User Interface Design" might be better words for the whole of patterns, docs and guidelines towards a usable Drupal admin.
Hmm, the Sample Product: yes, something like you are proposing. I like what the Conference Organizing Distribution wants to do (http://usecod.com/cod-features). An profile to run events: sessions, attendees, sponsors, news. Focussed, very much aligned with the Drupal spirit, and a good example implementation for newbies and TCO evaluators alike. What excellent dogfood it would be if a (light?) version of that would ship with core!
It is great to see the discussion moving away from framework *versus* application. Acknowledging the two are different is an important realisation and there's a risk there. D7UX was initiated late in the dev cycle, which was disruptive in good but also bad ways. I'm hopeful the community can see past the bolted-on implications that had on performance & weird new modules in core, and find ways to incorparate a design process for core that benefits both the framework and the apps on top of it. User interface design patterns are framework tools. A tailored UX is for the app/profile.
Regarding the "three implementations to prove the framework": writing the initial spec in the form of the press release for the actual end product is a great way to outline a focussed application. If we can agree on 3 of those, then the framework builders have their spec too! :)
yoroy wrote:
yoroy wrote:
"writing the initial spec in the form of the press release for the actual end product is a great way to outline a focussed application"
I can vouch for the effectiveness of this approach. Even better is writing a fake magazine article from the future: there is no more efficient way to perfect - and to sell - an idea than to write about it (with user quotes and sidebars and supporting graphics) as if the product has already shipped and succeeded.
I'd be happy to help if/when the time comes.
Wow, there are a lot of good
Wow, there are a lot of good ideas here, a lot of personal goals and we'll see more comments and blog posts about this - which is good, don't get me wrong on that, but I feel like we're missing a central place for all this wonderful info and to actually create some sort of roadmap.
I know there's core conversation at DCC which I'll attend too, but I think it might be time to start some sort of solution on d.o. where we can assemble all ideas and prioritize them on a 'meta' level (not sure if meta is a good word). The idea* is taken from the release schedule which Fedora uses, see http://fedoraproject.org/wiki/Releases/15/FeatureList - be sure to also scroll down that page and look at Feature Process.
We're getting bigger and the world is watching at us nowadays, so let's give them a clear overview what we're going todo.
* I talk about this too at http://realize.be/drupal-8-agile-proposal.
nice post Eaton :) two
nice post Eaton :) two thoughts in response:
- writing up and sharing design patterns: it's totally logical that if we want to improve the UX of Drupal one of the best places we can start is to develop, maintain and communicate a great UX pattern repository.
Drupal 7 has shipped with some poor patterns (or in some cases lack of consistency that should be corrected), we need to clearly articulate how and when to apply patterns that we are reasonably clear on. Achieving this will require a considerable effort and will require leadership and coordination. And it's going to be an ongoing job. Some commercial operations have teams of people, fulltime, curating their pattern libraries. We can't talk about it as though an ongoing ad hoc effort is going to create something that will achieve what a good pattern library could achieve. But if we can make this happen, and make it happen *well* the results could be very powerful.
- target audience (my old friend). Taking a clear and achievable position on who each of Drupal's key target audiences are and how we are going to provide them with an optimal experience is possibly the most important decision we as a community can make if we want to *really* increase the uptake of Drupal. I also think that one of the biggest challenges we have when it comes to building good experiences for 'content creators' or 'site builders' in core is incentive. Who has incentive to build and then maintain the functionality that these audiences need?
Perhaps I'm still in recovery from D7UX but my inclination is to accept that Drupal core is for developers (and there is some work to be done to optimise the admin experience for these developers). As long as we make it increasingly easier for people to build services over the top of Drupal we leave looking after these other audiences (with their many and varied forms and requirements) to those who have commercial or other incentives to do so. Really happy to be wrong about this, but it strikes me that this is the most realistic, sustainable outcome.
I'm aware this sounds decidedly un-cheerleader-y. I'd love to see some great UX work done in Drupal 8 but I also want us to be realistic about what we're currently equipped to achieve and where our efforts can best be spent.
Leisa, thanks for the amazing
Leisa, thanks for the amazing writeup. Your experience with D7UX has left me very, very curious about your thoughts on this and I appreciate you taking the time.
I agree that the UX pattern repo concept isn't one that can be done piecemeal, with drive-by tweaks. It needs a consistent guiding hand, even if the individual tasks can be broken up. In your opinion, how much of the work can be broken up into bite-sized pieces? For example, documenting and clarifying how to use vertical tabs doesn't require a WYSIWYG editor (and accompanying documentation) to be in the pattern library. Implementing a reusable color picker, and documenting it, doesn't require that we also have all of the questions about collapsible fieldsets ironed out. I'm willing to accept that I'm underestimating the inter-connectedness of these efforts, though.
I actually think that the UX pattern library approach would be a very easy sell to developers, and getting their support when implementation issues come up would be easier than UX improvements that are perceived as "spit and polish" that won't be used on their own projects.
Regarding the target audience, I definitely agree that it's the most pressing challenge facing the community that builds and develops Drupal itself. It's the classic perspective problem -- by the time someone is neck deep in building core code and refactoring APIs, their paint points start diverging dramatically from someone who just builds web sites with Drupal. I know I suffer from the same problem; the site-builder training workshops that we do at Lullabot has helped keep me more grounded than I otherwise would have been but it takes work not to start thinking in PHP and ignoring the rest.
I think that the question of incentivizing relatively unglamorous stuff (from a development perspective) is a problem that deserves its own post. You've given me a lot to think about. ;-)
So, what I've learned about
So, what I've learned about doing design work for Drupal core (or actually just for the Drupal community in general) is that for every hour of design work you probably have to allow about four hours for communicating - explaining, justifying, proving, iterating your design work. I think at least the same is true for the design pattern library. Having had a teeny tiny pattern discussion on a relatively simple pattern on Twitter (with a fraction of the typical audience/participants) brought this home to me yet again just the other day.
I think ideally you'd have a small team working on this - maybe 3-4 people - with someone taking the lead in terms of setting out the format, maintaining consistency, taking responsibility for making sure the communication work was being done. We could even perhaps set up a system where anyone can submit a pattern and then it voes through a moderation/approval/review process by a team with solid UX experience who are across the entirety of the project (for consistency). We'd also have to allow for ongoing communication/review time for accepted patterns as I'm sure they'd be routinely challenged (which is not a bad thing).
Incentive - I think this is an incredibly important discussion point with regards to design and UX in Drupal. I've been saying for a couple of years now that the lack of incentive to do good design within the Drupal community is the primary reason that good design is as rare as it is in our community. I've raised on a number of occasions some ideas that I think can address this but usually get trashed because I'm asking for a special case for designers... which I am - the community at the moment has incentive built in for developers (a range of different incentives) and very little for designers. This needs correcting.
Oh, and what you're calling unglamorous from a development perspective is potentially incredibly sexy from a design/ux perspective :)
re: communicating – I've
re: communicating – I've heard people say *exactly* the same about the need to promote and push for inclusion of code patches in drupal core. There is nothing special about design/UX in that regard, it's an issue for a lot of the community. Sure, the issue queue + patch + VCS based workflow doesn't really fit and makes contributing design/UX harder. That needs to be addressed but it's a slightly different issue, fixing that won't take away the need to communicate, connive and cajole. Working in a big community is tough.
re: incentive. There is really only one incentive for developers of code and that's that they have a need to use it themselves. It may be because they're employed by a company that builds drupal sites, it maybe they're freelance or it maybe they're maintaining a charity/community site for free – but at the end of the day we all contribute to make this thing we're using better. I don't see why the same shouldn't apply to UX and design. Themes – yes, there's never been much incentive to make nicely designed contrib themes. But drupal core UX and design – if you're building sites with it, using it, surely you have an incentive enough to contribute and improve it?
Contributing design + UX just isn't all *that* different, and that's why it tends to raise hackles every time you ask for special treatment :)
I don't think I'm asking for
I don't think I'm asking for special treatment and I don't think I'm saying this is unique to design. I'm just saying this is how it is for design - I'm not a developer, I will never speak on behalf of developers because I don't know that experience.
Incentive: when I'm fixing the UX of Drupal I'm not fixing it for myself, that's the whole point. I *don't* use Drupal on a day to day basis - I design things that run on Drupal, and am partially responsible for inflicting the Drupal Admin UI onto my client's end users, but I don't use it to build sites. This will be true for most specialist UX people. If there is an itch to scratch in the UX of Drupal core, for me it is almost always a vicarious itch. This potentially makes it easier for me to see and fix problems, but it also means that if I do it, I'm mostly doing it as a Good Deed, and nothing more than that. I feel that must be the same for many others otherwise Drupal's core UX would be an awful lot more amazing than it is.
There is a *big* incentive problem for UX people. It *is* different to developers (although many of the problems we face in getting work done once we're actually doing the work are incredibly similar, we're in agreement there).
What if we run a kick-starter
What if we run a kick-starter type campaign to fund positions/projects that are critically needed but cannot be undertaken without paying staff to implement? If we clearly define the project scope, goals, length, and budget, perhaps we could get a LOT of people to each pledge a small amount and perhaps a few larger corps to kick in also, knowing that the money wouldn't be re-directed or spent if enough people didn't fund it?
My impression is that this works better than chip-in requests.
As a developer, I've been
As a developer, I've been begging for a Drupal HIG for going on two years. :-) Having someone "own" the UX process at a high level can give us the consistency we need, and the direction to build. Once we have a given pattern we know we want, that provides an incentive to developers to make it easier to do. We like the vertical tabs pattern? There's now a widget for it. The "machine name / human name" pattern? There's now a widget for it. That creates a positive feedback loop where "doing it the right (or at least consistent) way becomes easy".
Such an effort can and should encompass contrib, too. Core has its UI models. Then Views has its own design that is internally consistent, but different than anything else. Then Panels has a completely different workflow that is kinda like Views but also very different. Then there's the Features/Feeds UI model that is unlike anything else and confuses the heck out of me. A solid HIG that we can point to, and evolve as needed, and work on as a dependency for such projects, can help bring unity to such systems so that I only need to learn one UI paradigm instead of 4. (Well, 3.5)
Dries' comments on his blog suggest he may be open to the idea of a person or people "owning" such an initiative: http://buytaert.net/drupal-7-development-process-retrospective
And yes, Leisa, I've had that conversation with Mark Boulton, too. The kind of people that are attracted to open source in the first place are the ones who took their toys apart as children to see how they work, and then tried to put them together again with fewer pieces. Ripping apart a proposal down to its base parts and building it back up again to make sure we grok it is simply second nature to open source geeks. That's what makes them open source geeks. Code lends itself to that process more readily than design does, but it's something that open source folks are naturally disposed to do for almost anything. You get used to it after a while. :-)
I just posted some thoughts
I just posted some thoughts on design leadership in the UX community here:
http://www.disambiguity.com/drupalcommunity-model-for-design/
We might not need another D8
We might not need another D8 post. This one could just keep going.
I think that the Drupal product has more in common with the Java pet store than it does with Tsunami/Standard Profile. I believe that most of the folks who download Drupal to put up a blog or simple site never look back. They want a website, and they aren't staying for the community, nor should they. The problem is that they want a simple WP-like solution and even D7 is not at that level.
These folks aren't part of or important to the the Drupal Community because they use Drupal. They are important because they represent a tremendous opportunity to capitalize on the techno-zeitgeist in the way that Wordpress has. Our buzz keeps them coming to us, even though most probably never get a site up. If they were more successful, the world would be our oyster.
Now, even if you think of an oyster (or a world, for that matter) as a hairy rock filled with slime, the fact is that those happy folks, by sheer dint of their numbers can bring more of everything, including talented developers, to our camp, and for that reason alone, it is worth spending our blood and treasure to create a winning product.
This is inspiring.
This is inspiring.
This is a great post, it
This is a great post, it really helps put all the various forces at play developing Drupal core.
I would like to see Drupal 7
I would like to see Drupal 7 be able to provide services to Drupal 8 so legacy modules can continue to work before they have been upgraded. I think of it like binary stars where the older star feeds fuel to the newer star, hopefully without creating supernovas or black holes. Crazy talk? Probably.
Thanks, Jeff, for this very
Thanks, Jeff, for this very insightful analysis of the key pieces still missing from the Drupal framework, and inspirational writing of how solving them will lead to a better Drupal framework and product. But, while I agree with almost all of what you've written, I don't agree with the premise of defining the product based on only those modules that already exist in Drupal core. What if instead we first think through what it really means to be a product, why we care about Drupal-based products, how we can best foster them, and based on that, what modules might need to be added to core?
The term "product" is a bit incomplete. I'm sure that the Lego Group considers a box of LEGOs to be a product. And Photoshop is certainly a product, even if it is intimidating for many people who end up finding other tools for simple tasks like cropping a photo. So perhaps the way we can think of it is how close can a particular Drupal profile get to a finished website, and who is the target audience for implementing the finishing steps? I agree with your proposal that there should be a Drupal 8 core profile that is much closer to a finished website than the default Drupal 7 profile is, and with webchick's proposal that the target audience of that profile should be people not turned off by the need for tinkering with some complex configuration steps to get the complete site built. Such a profile would serve the existing Drupal community well, and help reduce the learning curve for new developers, designers, and site builders joining the community.
But as other comments here have pointed out, that still falls short of Drupal serving the needs of the mainstream. Here's some use-cases:
- It makes no sense for a doctor, hair stylist, or pet store owner to have to learn a bunch of Drupalisms in order to create an online brochure. We developers sometimes scoff at online brochures, because that's so 1990s, but they serve an important communication function. Yeah, they don't foster online collaboration, but so what? They help people find each other in order to then have in-person communication, and that's a good thing.
- It makes no sense for someone wanting to blog about what is happening in Egypt right now to have to first spend a week learning how to configure Drupal into a blogging tool.
- A university may have a web team within their IT department who can do the complex configuration necessary to create their website, but how much arcane Drupal knowledge must teachers and department heads learn before they can manage content or do some customization of their department's section of the website?
In an earlier comment, webchick asks a good question: given that WordPress solves the first two of the above use-cases well, does it make sense for Drupal to try to do so? Above, highermath says yes, for marketing and PR reasons, and all the benefits that come with that. I say yes for a different reason: that last use-case. Not just university websites, but any niche website, whether it's managing local news, organizing activists, organizing a conference, etc. I think that a lot of us in the Drupal community are driven by the same goal that is Mozilla's formal mission: to promote openness, innovation and opportunity on the web. Which means, we would prefer to see these niche needs addressed by free (as in comes with freedoms) software than by proprietary software. But the niche need isn't really addressed until the tool is usable by a majority of the members of that community. So, do we wait for specialized tools built on a custom framework to come along to solve these use-cases the way WordPress has done for online brochures and blogs? We've been saying for years that the main benefit of Drupal is that its framework is powerful enough and flexible enough to support all these use-cases, and that all that's needed is for people in contrib land to build out the necessary distributions/profiles. It's a nice hypothesis, and one I agree with, but it's unproven. Is there any Drupal distribution that has achieved for its niche what WordPress has achieved for blogging? Open Atrium is certainly promising, as are some others, but building something as refined as Open Atrium for other niches is a daunting task.
So, what can we do to make it easier for people to create highly usable Drupal distributions? In other comments here, we've discussed formalizing UI patterns and guidelines. In other blog posts, we've discussed about the need for business models that can monetize distributions to fund their creation and maintenance, but without removing GPL freedoms. But I think one other thing we can do is prove that a usable (by normal people) profile can be built by building one (or several) in core. And I think an online brochure profile and/or a blog profile are likely to be the easiest. I'm sure we will find challenges in this. It's hard to make something usable by the mainstream while staying true to Drupal's spirit of infinite flexibility. But I think that we are now up to that challenge. A lot of extremely talented UI designers have joined our community in the last couple years, and more will come.
So in summary, I would love to see Drupal core come with 4 or 5 profiles:
- Minimal: for the experts building something custom.
- Tsunami (or whatever we call it): for tinkerers and future Drupal contributors to get a good start towards creating the kind of small team website that Jeff describes.
- Online brochure: usable by the mainstream.
- Blog: usable by the mainstream. And possibly split into 2 profiles, Simple Blog and Fancy Blog. I'm no expert on blogging, so I don't know if it makes sense to split in this way, and if so, what exactly makes a blog simple or fancy.
But the challenge with the last two is they require more modules than what is in D7 core. While there is much community discussion that would be needed to settle on the details, I think more or less, we would need:
- Wysiwyg
- Media
- Views
- Webform
- Date
- Pathauto
- Captcha
- Parts of CTools (plugins, exportables, object caching)
Note that these correspond with most of the remaining 20 most used contrib modules that haven't already been incorporated into D7 core (with Media replacing IMCE, a conversation that can be had in a future blog post). But that's not why I picked them. I picked them, because I think these are what are needed to support proper Online brochure and Blog profiles. Given that those are the most common kind of sites, and that more complex sites are usually an extension of them, it's not surprising that these are therefore also the most popular contrib modules.
Ok, now I fear it's time to duck while people swipe back with comments as to why it would be insane and disastrous to try to incorporate these modules into D8 core. Go ahead. Let's get that debate started. But keep in mind that this is all just my opinion. I have no power to make it happen. So let's keep the discussion constructive rather than aggressive. Thanks!
Standardmprofile also allows
Standardmprofile also allows all the modules you need, but you can check by going to the Toolbar »Modules and make sure that the Field, Field SQL storage, File, Image, List, Number, Options, Text is enabled and all. This module will give you some basic types of fields. If you want to reference nodes and users, you will need a reference module, which offers specific port CCK Node Reference field and the user, allowing you to link nodes to other nodes and users and users.
sales process
Hi all,
Hi all,
I've spent the last six months trying to get Drupal 6 to deliver a site to my specifications with no success I'm afraid.
Getting used of addressing content in terms of nodes is a nonsense to the average user and the user interface is bloody horrendous!!!
I'm a competent Java programmer and after the six months of stubbornly trying to get Drupal to deliver the functionality I require I figure I would probably have completed the site using JSP in the same time frame. Fortunately the site is not for a customer and is more of an academic endeavor to learn Drupal on my part but that does not mean I will compromise on the functionality I'm seeking :)
Don't get me wrong, I'm not belittling the work put into Drupal or it's modules at all, nor am I saying that a CMS built using Java would be better. Drupal is an exceptional piece of coding and more importantly it's standards compliant which is a major point for me as it leads to consistency.
What I am trying to say it that Drupal 6 suffered from the same fundamental flaw as Linux has suffered from over the years, A developers mind set.
Over the years the Linux fraternity has ranted on about how Linux is better that Windows and will eventually become the Desktop operating system of choice because it's free and more stable.
Unfortunately what Linux also is is a showcase for Developers to impress other Developers.
The end user experience gets lost in the battle to show who's the better geek :(
Where Windows wins in the battle is simplicity of use and consistency of interface.
It presents a consistent look and feel to users and is reasonably consistent with most of it's applications look and feel.
People just cannot be bothered battling the operating system to install drivers via a command line, windows does all that so the user can just get on with it.
Now I use both Linux and Windows in equal parts but I know that as long as the interface and ways of doing thing remain inconsistent and the complexity of doing things remains high for the average user then all of the power and stability that Linux offers is lost to the average home user because they're confused from day one which ultimately scares them away and leaves a bad impression that lasts!!
(It took me years to return to Linux after my first encounter back in the day ;) )
Drupal 6 suffers from the same issue, it's very developer orientated.
Tasks that should be easy to achieve are immensely complex and require Modules that have poor documentation as to what they do and how they interact with both the core and other modules.
Even a simple thing like "how to" documentation or examples make a huge difference!!!
Bear in mind that not all users are going to be PHP gurus and able to read and understand the source code.
I have just today installed Drupal 7 in a test environment today and first impressions are good, the grouping of tasks make a lot of sense, the user interface is cleaner and a lot less confusing. In my opinion a vast improvement. It's still very texty though, are we afraid of icons?
As for the modules, I know I still have to use the same modules as before with the same ( lack of ) usability and documentation problems. I'll probably just write a single cohesive module to do what I need to do, I was going that route with Drupal 6 anyway.
It's just such a shame that I have to write the module as people who don't take to coding the way most of us here do will go else where in frustration and they loose out for it, all because coders don't think of users.
In my opinion a coder who writes code to impress other coders and doesn't consider an end user is not all that clever or impressive at all. I'm sure other will disagree with my opinion, want to bet they're a coder when they do? ;)
Awesome post. It really
Awesome post. It really clarifies the real scope of the Drupal effort - big picture.
One of the major areas of improvement around UX is to implement proper Forms abstraction, covering both design (layout, mangement & re-use, master-slave, validation, etc). Although CTools adds a lot, there is still no consistent way to graphically layout one/more forms for a specific content type, combine content into a master-slave type of setup, etc. Why have we had user-definable validation in Webforms for years, but not in CCK?
Usability is as much about proper presentation & data layer abstraction as it is about having drag-n-drop and tabs as "standard" UX features. D7 adds proper Data abstraction. Now it's time to do the same for Presentation.
Add new comment