Published

Designing for the wrong target audience (or why Drupal should be a developer tool and not a consumer product)

As you may know, I spent a few months this year working with Mark Boulton and the Drupal community to try to make Drupal 7 (their upcoming release) a Great User Experience. I’ve spent the past weeks reflecting on that experience and trying to understand what we learned from that project and with any luck this will be the first of several reflective posts.

It is all to easy to make excuses for why designing in an open source community can be tough. Certainly there are lots of communication challenges and we don’t necessarily have the right tools. Some people focus on the relationship between designers (minority) and developers (majority) in these communities – I think to do so is to focus on a symptom of the problem and not the cause.

We faced many challenges with the D7UX project, but the greatest of all was to convince the community that the changes we were suggesting were actually going to result in an improvement to their project. There are many who steadfastly resisted our approach and who continue to do so.

It would be very easy to take this personally and to argue about the details of the way the design works (and I most definitely include Information Architecture when I say design). This would also be a fairly typical Drupal thing to do. Actually, I think almost all the issues stem from a much more fundamental place – defining the real purpose of Drupal and it’s real primary target audience.

From the very outset our goal with D7UX was to make Drupal more accessible to people outside of the Drupal community and less technical people – people who didn’t even know what PHP was let alone how to code it. Verity and Jeremy who emerged as part of this definition embody the target audience that the design work that Mark and I were doing in this project. This approach is representative of the goal to make Drupal more of a ‘product’ – an out of the box CMS solution that non-technical users can drive. This is key to the goal to increase the reach of Drupal, as Dries outlined in his keynote at the recent Drupalcon.

There is one big problem with this approach, particularly if it touches the very core of Drupal. The changes that are required to the interface to really achieve the goal that we were tasked with – to really make Drupal understandable to Verity & Jeremy has the consequence of making Drupal a less efficient and enjoyable place for Drupal developers to build cool stuff.

Drupal developers (and some designers!) who want to build cool things with Drupal are the core of the Drupal community. They are the people who make Drupal the incredibly vibrant community that it is. Without these people, Drupal becomes a shadow of it’s current self. These people are more than an important audience, they are the most important audience. What this audience wants is not Drupal as a product that Verity & Jeremy can use out of the box, they want a developer toolkit that gives them more and more flexibility and capability to build cool stuff, and to push Drupal way beyond the realms of a simple Content Management System.

And so we have this tension. Drupal as a ‘Consumer Product’ and Drupal as a ‘Developer Framework’. Currently, the official direction is that the project is going to attempt to be both. I think this is a serious problem.

The target audiences for each of these objectives are so far removed from each other in terms of their tasks & goals, their capabilities, their vocabulary, their priorities. An attempt to devise an interface to suit both will result in an outcome that I expect we’ll see in the release of Drupal 7 – that is a compromise to both parties. Verity is still going to need a lot of support to get anything done in Drupal 7. If Drupal 7 had been designed primarily as developer tool, it would be a much more focussed and efficient tool for developers. As it is now, it is hopefully an improvement on Drupal 6, but certainly not the best that it could be for developers.

For Drupal to really succeed, a decision has to be made, and I think there is only one decision that can be made. Drupal 8 should be designed with developers as the primary target audience and the language, tools, interface should be designed to support them in their goals of building really amazing stuff using Drupal.

That doesn’t mean that there is not still a lot of work for the User Experience people in the Drupal community to do – there is still an enormous learning curve even for those new to Drupal who have great PHP and other technical skills. It’s going to be much easier to address that learning curve with a more finely targeted audience in mind – or more importantly, with the right target audience in mind.

So what of Verity & Jeremy? How will they ever come to know and love Drupal?

There are a number of ways that we can address the experience of non-technical users of Drupal and to ‘productise’ Drupal as a content management system. The most obvious is to design and develop an admin theme that is specifically targeted at these end users that can be applied by developers once the development work is done and the site is being handed over for administration.

I’m not sure where the incentive to design and develop this theme comes from (given that it doesn’t exist today it strikes me that there is a problem here incentive-wise).

There are also opportunities to be explored with installation profiles (see above though re: the fact that they don’t really exist now and no one seems motivated to work on them, where is the incentive?).

And, of course, we have the emergence of tools such as Buzzr from Lullabot and Gardens from Acquia, perhaps also products like Open Atrium from Development Seed can included in this list.

A tough decision but a necessary one

I know that for many people the idea of making a Drupal that Verity can love, making something that can actively compete from a UX perspective with the likes of WordPress, is a grand aspiration. So it is, but unfortunately I also think it is the wrong aspiration for Drupal core.

The sooner we focus on the core target audience of Drupal core – the developers – and commit to making a user experience that supports them in their use of Drupal, the sooner we’ll really have actually achieved a really Great User Experience for Drupal.

If that is really our goal, then let’s get focussed, let’s re-write the design strategy and principles, and let’s take the work we’ve done already and refocus it more tightly on the community we know and love. Focussing on the strength of Drupal and then looking for new and innovative ways to create and motivate the Drupal community to do a better job of looking after our Verity’s and our Jeremy’s.

Published

104 Comments

I think the broader point here is that Drupal (or any other system or product) cannot reach out to new audiences at the expense of its current audience. That’s a sure-fire way to end up with no audience. (See also: Star Trek under Rick Berman.)

Drupal really cannot continue to get away with the answer to “framework or application” being “half and half”. That results in two half-assed answers. We’re at the point where Drupal needs to either become just a CMS application (meaning a single application workflow with add-ons kinda on the side) or just a content management framework (with a lot of flexibility and extendability, but more up-front configuration to make it work).

Or does it?

There’s nothing about being a first-rate framework that precludes building a first-rate application on top of it… in a secondary layer. That secondary layer can do all kinds of stuff, if the framework underneath it has been built properly, as a framework. If the framework underneath was built as just a support for the application, then it’s going to be a half-assed framework which leads to a half-assed application.

So yes, I agree emphatically. The focus for Drupal 8 should be to make it a first-rate rock-solid content framework… on which can be built awesome applications such as “Drupal Default”, Open Atrium, Gardens, Buzzr, etc. But we have to keep those layer separate in our heads, and in our code.

Drupal-the-framework being awesome is a prerequisite for Drupal-the-application being awesome.

There’s no reason Drupal needs to lose its heart (framework) at the expense of becoming an application. If we make it easy to download and install an installation profile (http://drupal.org/node/596488), Drupal the application can be awesome without having to make limiting concessions.

While I understand where you’re coming from, I’m deeply troubled by this post. To a large extent, I feel that this strategy would practically abandon an important constituency of very technically-oriented designers who aren’t technical enough to be full-blown developers. These folks are the mainstay of other CMS communities such as WordPress. They’re also key evangelists for Drupal to gain acceptance in many industries, such as advertising, nonprofits and academia, where developers don’t rule the roost.

I also have a hard time equating Drupal core with Drupal out-of-the-box. I think it’s a semantic mishap that both have become synonymous. I think that the future of Drupal lies both in smallcore and a strong out-of-the-box experience, but that they’re essentially two very separate goals. The path to achieving these is to separate the UI from Drupal’s kernel. Developers will have the minimal, flexible small core that they want, while the user experience can come closer to that of a well-supported product.

Without separating these into two layers, the current D7UX strategy has been a bit of untangling a hairball. I think internationalization, UI customization and other areas will see a huge improvement from a separate UI layer.

As for theming, I think the biggest obstacles right now are the Great Wall of CVS and the Issue Queue. Drupal’s contribution methods include many technologies that are utterly foreign to the design community:

Designers don’t use CVS or SVN
Designers don’t use command line of any sort: not drush, nor Linux shell
Designers rarely if ever code PHP at all
Designers don’t touch databases

And yet, all of these are requirements to be able contribute to Drupal. Those designers who are every active participants in the community have shown their agility in adapting to foreign ground.

These requirements imply that any design contribution requires a pairing of designers with developers, which typically won’t happen without funding or corporate mandate of some sort. A Drupal admin theme will either require major funding and participation — or a rogue approach from a small empowered team, as we’ve seen with Open Atrium.

For me and for many other designers, I’m sure another round of developer-centric design strategy would spell the end of our participation in the Drupal community.

1) Yes, a clearer separation between Drupal the plumbing and Drupal the UI/application is critical. That’s the point Leisa is making (as I read it) about making a developer-centric workflow and then putting an admin theme on top of that once the build is done.

2) No, that doesn’t mean driving out designers. It means that we need to take the time to really, REALLY focus on the underlying systems so that designers have something to even work with.

The other important aspect here is that “designers” who deal in pure design will never be able to build a site in Drupal. Building a site with Drupal without understanding Drupal (knowing Views, CCK, node types, etc.) is impossible. A pure PHP dev who doesn’t want to learn FAPI is going to be equally lost. I think that’s also an important take-away here. “Developer” doesn’t have to mean “super code ninja”. It means “someone who groks how Drupal works and is put together”. Building a complicated site without that knowledge as impossible as building a complicated static site without really knowing your CSS. (Unless you want to do everything in HTML tables, or manual insecure one-off PHP scripts.)

“Click and drool” site building is only possible in very narrow application-centric systems. Drupal is not a very narrow application-centric system. If we make Drupal-the-framework better, then it could be used to build very narrow application-centric systems, but let’s not put the cart before the horse.

And no, that doesn’t mean chasing away designers. Where you got that idea I don’t even know.

I don’t think the division between designers and developers is so much the issue here. Think of it this way. There are the people who create sites (developers, designer, etc.) and the people who install an application and then maintain the content of the site. That’s the division here.

So, we need to make drupal the best tool for the people who create sites whether they are web designer, web developers, or what ever.

Think of it as making the best tool for site builders rather than being an out of the box application for content maintainers.

I agree completely agree with the division you’ve described here and that is is not about designers/developers. The non-technical designer that modulist describes is actually like ‘Jeremy’ I think, and an audience that needs to be looked after but in a different way.

By focusing on making Drupal the best development tool going, I think this actually supports the argument for making Drupal ‘output’ more standards friendly, and more approachable for designers from a technical standpoint.

I agree tho, the whole idea that a designer should have to understand PHP in order to design in Drupal has always struck me as somewhat nuts.
(however that is a complete tangent to the point at hand).

Leisa–If it is not about designers vs. developers than who are you referring to as “developers” in your original post? I read the post like modulist as not including designers as part of the target audience. It seems natural that “an admin theme that is specifically targeted at end users” would be a project UX designers would take ownership of. If the community alienates UX designers than UIs geared for end users may never be developed, no?

Jeremy (can just about read a bit of code but doesn’t want to write any, not the social networking consultant bit) is me about 4 years ago when I first installed Drupal, and I’m not the only person heavily involved now who came in from that side of things. He doesn’t want a PHP framework, but he does want to get his hands dirty with Views, CCK etc., hopefully with some working pre-configured stuff to latch on to – in fact funny words like CCK and Views are why he’s moving to Drupal away from his current CMS.

Anyone building a site has to undertake the same tasks as Jeremy, so optimizing for him should hopefully not get in anyone else’s way too much, if we massage his personality a bit.

While tangential, I’d really not discount the concept that the way theming is handled in Drupal contributes to the difficulty of UX for various user types.

I don’t think it’s unfair to expect a themer to be able to handle the concept of placing php tags (simple print statements) to direct output, but being able to track down and override theming functions seems to be a bit severe. Furthermore, knowing when to use a theming override and when to use a templating override adds another level of fun. We’re not consistent, and I think this make the system harder to use.

What I’m getting at – in a roundabout way – is that because we’re far from MVC and so much of our theming is interspersed with code our UX is inherently tied to the framework. If we found a better way to theme, perhaps we’d find far fewer troubles between UX and development.

I agree that CVS is a huge barrier to designers looking to participate and contribute. I don’t know a way around that, except perhaps through tangential efforts.

I disagree, however, that this approach would work against the “very technically-oriented designers”. Another word for these people is “front-end developers who also design.” These are people who will be well served, I believe, by a stronger developer-centric effort.

I see a lot of what has happened these past 5 years as being rather developer-centric. One of them was the establishment of the phpTemplate theme engine to replace the Xtemplate engine. Xtemplate was a nightmare. phpTemplate is an approach that makes developer sense, but is also easier to understand for non-heavy php coders.

We could see more of that.

And any developer-centric effort would, I feel, have to include cleaning up the html and rationalizing the ID and class approaches.

I also see this approach as freeing up the install profiles — or better yet, feature clusters — to have end-user-friendly packages for non-tech Drupal users to enjoy.

I’m sure I’m missing something here, but I’m still absorbing some other perspectives at this point.

@maureen I’m not sure how what I’m describing here in any way alienates UX designers from the community. We are always designing for target audiences other than ourselves, and all we’re doing here is shifting the focus from one target audience to another.

There is no reason why this should alienate UX designers from the community – I’m not suggesting for a moment that because we now focus on a developer audience that the developers suddenly become the designers. UX designers still have plenty to do in terms of understanding this audience (which is not as homogenous as we may first assume, see cpelham’s post below on ‘what do you mean by developer’.

Designers in the Drupal community have a whole bunch of demands, many of which are very worthy. If anything, I feel that the clarification that comes about as result of the approach I’m describing here will actually benefit designers in allowing them to focus on what they most want/need in order to do their work and to know where to turn in order to have those needs met.

As a Drupal developer myself (running 20+ customer websites with Drupal) I could not agree more with you. Training customers to be able to run and administer their own websites ist hard enough in D6 – mostly due to the lack of good admin-themes and poor in-place editing capabilities.
The revamped admin-interface of D7 however made my job harder – many settings-pages are one or two more clicks away than they were in D6. I end up using admin_menu on top of the standrad admin theme. Granted, it’s not even alpha yet, but still.
One possible strategy to address the conflict between “developers” and “users” would IMHO be to even further strengthen the capabilities for in-place-editing in later Drupal versions – because that is the most natural way for laypersons to interact with a site that’s been built for them. Then give the devlopers a really badass admin theme.

yeah, I think you’re onto something here reglogge. Since D7UX I did a bunch of work with The Economist on an admin interface that was almost entirely ‘in place’. Unfortunately it’s not going into development due to time (and other factors) but it tested really well and I’d love to see it developed further. I really think it be potentially ‘game changing’ (which was something we hoped to achieve with D7UX and which I think we’ve fallen a little short of unfortunately).

I think very separate and different treatments for how developers and content creators/administrators interact with Drupal is v important. The more I work with Drupal/End Users/Developers, the more this seems true to me.

I’m not especially familiar with the Drupal community and haven’t used Drupal myself, but this reminds me a lot of the situation at my company, Vyre. Vyre’s main product is an in-the-browser framework for developers to build big, powerful websites on top of. It’s an interface that allows developers to do everything they could ever want to, but it’s not at all meant for non-developers.

I’ve just completed helping Vyre design a new CMS for end users (http://www.tylertate.com/foresight/). It’s built on top of the framework for developers, but it is a completely separate entity. This sounds a good deal like the approach you are advocating for Drupal 8, and I think it’s rock solid.

The benefit of having two separate areas, one for developers, one for end-users, is that you can of course tailor each one specifically for that audience. Developers get all the tools they need for creating and setting up, content contributors get an experience streamlined for creating content. Develops aren’t limited in any way, content contributors aren’t overwhelmed by irrelevant noise. It’s better for everyone.

“The target audiences for each of these objectives are so far removed from each other in terms of their tasks & goals, their capabilities, their vocabulary, their priorities”

That is so telling and so powerful that you were able to reach that point of understanding. Do you think there was anything that could have been done upfront that would have made it more clear then that this sort of decision needed to be made?

well, I think we always knew this, that the audiences were very different. What we did wrong, I think, is to take at face value that designing a UX for Verity/Jeremy/non-technical people was the right approach. That *was* the project, and so as a result of that, we always *talked* about ‘DX’ (the developer experience) but it was never really addressed as a priority because it wasn’t *our* target audience. There were definitely red flags from v early on.

The transformation of Drupal from something a techie person can build websites with to something a highly qualified developer / consulting company can build solutions with is a sea change with many profound and unknowable implications.

Sure the community is already dominated by the developers (Acquia, Lullabot, etc.), but I wonder about the impact on the long tail of developers… how many of them are tied to the “techie person” rather than the “qualified developer”.

Larry nails it, “There’s nothing about being a first-rate framework that precludes building a first-rate application on top of it.”

I think we could rip out a lot of core that is non-essential but very commonly used, and put it in an ‘outer core’ — not abandoned to contrib, developed and released in sync with core, but not part of the core download.
This allows us to simultaneously shrink AND grow core, because outer core could get all sorts of important modules currently in contrib.

Leisa, I always enjoy reading your posts so much! You are always so thoughtful and smart. In this case, I would like to be more clear whom you mean when you say developer because I think there are really two subsets of people here (or not, depending on what you intended!): people who are developing new sites with Drupal, and people who are developing new functionality for Drupal with which they and others can use to make new sites.

I usually think of developer as a programmer hired to program/create additional functionality for a web site or project, e.g. Earl has added Views and Panels functionality. They know their way around so well that the UX doesn’t impact them as much. I could be wrong but I think this group basically relies on Devel module, Firebug, various developer environment tools, Drush. They would most benefit I think from improvements to drupal.org because they are building/extending Drupal code itself more than they are building sites with Drupal.

The next group of people who work with Drupal are I believe like me: we have worked with Drupal a lot, understand it’s workings fairly well, can set up new Drupal-based sites from scratch, tweak modules and functionality and help out a bit in the issue queues, but we consider ourselves to be themers/designers/admin/endusers rather than developers because we create no modules, contribute no major new functionality to the drupal code base. I think most Drupal web sites are created by people like us. Do you consider us developers for the purposes of this conversation?

And then there are the people who don’t know about the inner workings of Drupal or php and just want to set up an out of the box solution, or they are given a drupal-based site to maintain and/or edit.

These latter two groups would most benefit from UX improvements. The last group (which knows the least) would benefit most from a streamlined and simplified and clarified UX just so they can be better led through their work flow without becoming confused or lost. The middle group would benefit from a UX that enables them to build and theme sites faster. Doesn’t the first group just primarily need better developer tools?

i think you’re hitting on a really important point here, cpelham, which is that even though we might say ‘Drupal should be a developer tool’, there is still more unpacking that needs to be done, we fall into the same old trap that by saying ‘Drupal is for developers’ we mean ‘Drupal is for people who are just like me’. There are still a range of different groups within the meta group of ‘developer’ and defining, prioritising and understanding the needs of each of these groups would be part of the job of the User Experience team within the Drupal community.

The danger of saying ‘Drupal is for developers’ is that we make all kinds of assumptions about what this means. It doesn’t mean we need any less rigorous user experience work done. It doesn’t mean we don’t need to think about what goes on the interface. We definitely need to keep thinking about this, we just need to focus on a different audience.

With advertising Drupal I came a similar task and conclusion. For every target group Drupal is something different and different strengths are important. With that in mind you can built a website with different areas targeting the groups like Acquia does. However using the same approach with software is way more difficult and therefore I fully agree with your posts.
Still most of the work done for D7UX is really valuable for the developers as well.

It is not because Drupal is a better tool for developers, that developers will build more usable websites for their customers. In other words, it is important for Drupal core to help — and even force — developers to write code with end users in mind. Similarly, Drupal core helps developers write code with security in mind. With that in mind, Drupal 7 will be a big step in the right direction.

it is important for Drupal core to help — and even force — developers to write code with end users in mind.

interestingly, this was one of the design principles we embraced for D7UX – ‘wherever possible, help people make good design/UX decisions as they build their site using Drupal’ – I don’t think this is something that should be given up just because we’re refocusing the target audience. In fact, there are a few of the design principles I think we should carry over to the refocused interface.

again, I really want to stress that I’m not suggesting for a second here that refocusing Drupal core from Jeremy/Verity to Developers is the same as abandoning the mission for making Drupal a Great User Experience. But trying to be all things to all people is an impossible mission. Making it great for a the right audience is incredibly achievable – both for Drupal core and for the other services that will hopefully layer over the top and look after Verity, Jeremy etc.

I also think that, despite what I’m describing here, Drupal7 is a step in the right direction. It’s a part of the journey – the challenge now is to make sure we learn from this experience and use what we’ve learned to make the right decisions going forward.

Dries: “it is important for Drupal core to help — and even force — developers to write code with end users in mind.”

To me Dries’ statement means that core needs to set standards for contrib, with end users being people who download core and contributed modules and/or build sites with them. Core’s responsibility for user experience then ties in with it’s responsibility for security, performance and scalability – which more or less says that if you use our APIs correctly you shouldn’t have any disasters. An example of our APIs failing from a UX point of view would be the modules page – where implementing the API for categories usually makes things worse.

compared to:

d7ux “wherever possible, help people make good design/UX decisions as they build their site using Drupal”

d7ux reads more that core should set guidelines for site-builders, with end users being people who visit / administer those sites.

Which brings us back to the Jeremy / Verity split. Jeremy is an end-user of Drupal core and contrib (possibly an install profile if and when those pick up).

Verity is an end-user of a specific Drupal website (or SaS) which has been assembled by someone. That assembler of core and contrib can easily be a team of 20 people, or a Jeremy. Even if the assembler files core patches or maintains a contrib module, they’re still an end-user of Drupal and modules when building a site, and have to do many of the same tasks as Jeremy does.

“drupal-core worries about the developer experience. drupal-cms gives Verity & Jeremy a solution they can use.”

This, in a nutshell, is the split that I’ve been leaning towards for some time. At the end of the day the problem is *not* that devs what something nerdy and users/designers want something usable. Devs and designers throughout the community have worked hard together on projects in this community for *years* — the problem comes when any of that UX work gets pushed back into core. With a very few exceptions, it always hits the same roadblock: one product’s elegant solution is another product’s frustrating cruft.

In his reply to the post, Dries says “It is important for Drupal core to help — and even force — developers to write code with end users in mind.” This statement is reasonable, but its weaknesses are apparent when one considers it in the context of the greater Drupal community. Who are the “users” of the new database layer? Or the users of the Field API? The ‘users’ of the Drupal framework are, as Leisa suggests, the developers themselves. The tools that they build on top of that foundation must be user-focused and user-friendly, but what those words mean in the world of wireframes and interaction will differ wildly from site to site, from application to application.

Understanding that diversity and accounting for it — and treating “Drupal The CMS” as a valuable tool in its own right, worthy of UX work separate from the tools provided in the Drupal Framework — benefits the entire community.

“Doesn’t the first [developers] just primarily need better developer tools?”

Not necessarily. A lot of the work involved in customizing and streamlining Drupal for end-users boils down to simplifying those mechanisms and presenting them with just the tasks that they need. That goes deeper than just hiding certain menu items and widgets.

I’ve worked on a couple of projects that attempted to build smooth user-focused workflow and interaction models on top of Drupal’s normal site-builder focused tools. I’d say that *easily* a third of the developer time was spent undoing the default Drupal UX. In many ways, that problem gets WORSE every time the “Drupal CMS” gets UX overhaul: the tweaks and optimizations that improve *that* product’s user experience actually hurt many others — because they need different UX models and tools.

This doens’t mean that the UX work isn’t good! It’s just that often, those changes — because the ‘Framework’ and the ‘Drupal CMS’ are woven together so tightly — end up creating more work for developers who really want to implement innovative UX work. It’s not just a tools issue, it’s about making sure that the UX work for one ‘product’ doesn’t sabotage the UX work for others.

I couldn’t agree more! Working as a developer building sites in all different sizes and complexities, I want good tools that help me do the job. And like Eaton says, I often find myself hiding or removing features from core.

Keeping core compact and tidy as a framework should be, while providing a good UX on top of that, would serve both sides of the spectrum.

I support what I think Leisa is suggesting, and what Larry Garfield described so well, having a “first-rate framework” with a “first-rate application on top of it… in a secondary layer”.

UX is still very much important for Drupal, and shouldn’t lose its momentum because of a shift in focus. On the contrary though, I think having UX improvements as a secondary layer to core would be good for development, rather than having the two worlds collide as they do now.

Jeff: If you are saying that it would be lovely to be able to easily switch on and off (or add or remove) the various elements of the UI, then that sounds like a great suggestion if it can be accomplished. Of course, it is already being somewhat accomplished by various contrib modules.

So then we might look at Drupal as having the following layers:
small core with great APIs
contrib functionality enhancements by way of modules
contrib admin UI skins by way of modules
contrib themes
contrib install profiles

The more we continue to separate content and presentation, the more useable and likable Drupal will be.

We have no shortage of modules and an increasing number of themes and slowly install profiles and out-of-the-box solutions. Based on what Leisa wrote, I wonder if there is a financial incentive for people to develop and contribute admin UI skins. Maybe it is just a matter of clients, themers and developers keeping it in mind and making it more of a priority. My impression is that so far people just don’t want to touch that part of Drupal as much. They make their sites nice for the end user but throw up their arms and tell the admin to just deal with the hand Drupal deals them. If it can be shown that better admin UI will lead to greater productivity (and therefore save money), I think clients can be persuaded to fund work on it. Is that a possibility or likely not?

Dries’ argument (“It is important for Drupal core to help — and even force — developers to write code with end users in mind.”) is compeling. But the User experience is largely determined by the User interface, or at least required some common User interface elements. I’m not completely decided if that’s the responsibility of Drupal core to define those User interface elements.

Adding a form dependency system to FAPI allows x000 contrib module authors to write better forms, drag and drop, batch API, vertical tabs, machine-readable.js do similar. A lot of these are new in Drupal 7 or still in the queue, there’s plenty of things (scalable hierarchy choosers) which aren’t in yet and probably won’t make it until Drupal 8. These kinds of patterns need to be worked on and maintained centrally, somewhere, otherwise they won’t happen (with the very rare exceptions of something like ctools). Whether core ships with implementations is a different matter.

Indeed! Having a solid, robust, powerful set of tools for building forms and complex form logic is a critical component of Drupal-the-framework being as kick-ass as it needs to be. However, the specific forms that get built out to manage, say, node creation using those tools need to be mutable.

For example, edit-in-place is great and wonderful for certain kinds of site. However, I also manage sites in Drupal where edit-in-place would be an absolute show-stopping trainwreck disaster of an interface. That doesn’t mean edit-in-place is a bad UI workflow. Not at all. It just means that it’s a very good workflow for certain use cases and not others. We need to allow site builders to decide whether or not it’s appropriate for their case without having to bend over backward and write 2000 lines of form_alter code just to get rid of it. That’s harmful to site builders, developers, and ultimately end users of any site where edit-in-place is not the appropriate workflow design.

The constituent parts that go into edit-in-place, though? Absolutely expose those to developers and site builders to use in whatever way they see fit.

I found it sad to read that Verity had been abandoned. A more user-friendly Drupal would definitively be welcome.

But that the gap is hard to bridge is also because the Drupal UI has grown, but has never been designed (unlike the technical architecture which always has been appealing). The effort to move it into a different direction is just huge. I participated in a d7ux code sprint, and it was just shocking how much actually would be necessary to make Drupal work for Verity: throw out and start over would be easier.

That said, I think designers can still contribute a lot, but they should do so in a way programmers are used to pick up: why not design the ideal UI in the form of graphics? Not talk, just proscribe the layouts, in photoshop/png format with short descriptions. Very familiar for the typical Drupal programmer who gets these things all day.

I also would love to see the ideal CMS from Verity and Jeremy’s point of view in such format.

I don’t think we’re abandoning Verity – I hope we’re not. We’re just reframing the best way to look after her, and acknowledging that making Drupal Core fit Verity’s needs is not a viable solution – this is as much a community outcome as it is a design outcome.

We need to now talk about two things – what do we do with Drupal core AND how do we make sure Verity is looked after. Both of these discussions are v important, and the Drupal Core discussion is, to my mind, the easier of the two.

Let’s not forget about Verity and assume that someone will miraculously come up with a good admin theme for her and and a good installation profile for Jeremy. There doesn’t seem to be any rush for either of these things to come into existence at the moment – how can we make this kind of effort more rewarding?

I think Drupal is on a reasonable track. I represent a large audience for Drupal. I need a very rich community site that is based on user generated content. My goal is exactly 1 site, not a portfolio.

I am willing to learn the Drupal system to a point as long as my users have an extremely easy way to add content. I will never write a module. What I do need is something like the Features Module or similar packaged solutions by one of the big development houses. I am willing to trust them and live within those bounds. It would be nice to be able to mix and match. A way to combine say PressFlow with UberCArt.

Configuration instructions with double negatives, poorly named modules, descriptions with nothing but a download link makes evaluating modules among the 4000 an impossibility. Better documentation is needed. (Drupal is no worse than many commercial offerings)

In summary, making sites that have the ultimate in end user experience may mean keeping Drupal more of a developer framework. It will make my life a bit more difficult, but that’s OK. Just give me an easier way to utilize it.

I have spent hundreds of hours learning Drupal, and I’m happy with that as long as I in the end can create solutions for my users that look good and *has an easy way of adding content*.

I don’t find it very hard to do theming in Drupal – it’s certainly no better or worse than for instance WordPress or Movable Type. I can do amazing things with CCK and Views. And all the things happening now with Context, Features and Spaces +++ are equally important and really powerful stuff.

Which brings me to my main point: I can do everything but the last thing, which is giving me the ability to let my users *add content easily*.

This for me boils down to one (combined) thing, which is the state of editors and the lacking media library in Drupal.

On this point only I feel Drupal has been way to developer centric. We now have a WYSIWYG API, which is probably great for developers, but is only letting people like me choose from a wide range of different editors, where *none* of them solve what I’m really struggling with: uploading (media) files and putting it in my content. They *all* however solve the easier tasks of making text bold, creating tables etc., and *any* of them would do if that was what we were struggling with.

At the same time we get stream wrappers in core. This is bleeding edge, and it is really cool that I can access my Flickr feed from Drupal, but I still can’t upload and browse the files on *my own server*, and put them inside my content!

And yes, I know I can use file field, upload module, embedded media field, IMCE, SWFtools, FCKeditor (with many different browsers) and a very large number of other solutions, but they all work in their own specific way, and trying to combine the input mechanisms and filters from for instance SWFTools with the different file browsers available, with the possibility to align and *see* these files in a WYSIWYG editor is just plain hell. The Media Library Micro Project looks fantastic, but will we ever see it in Drupal 7, or is it just mockups?

I refuse to believe that I’m the only one who wishes to easily put media in my content, and I would be more that happy if Drupal 7 *only* shipped with this feature. Let it be in core, contrib or a distribution!

So, sorry if this became ranting, I am actually *endlessly* thankful for all the hard work Drupallers do and give to me for free, and the amazing things Drupal lets me do. My point is that you can call it what you will, and please focus on developers! Make smallcore happen, focus on the framework, let me download a lot more from contrib (it’s not that hard), but PLEASE give some love to these fundamental tasks from an end user standpoint. And just maybe chose ONE editor and go with it. You did after all choose jQuery, so it is possible. We really don’t need to choose between all those who exist, we only need one that works.

(..and yes, I believe this is the single most important thing that would make a whole lot of WordPress, Joomla and other CMS users finally make the switch)

IANAD (I am not a developer), actually I’m a client who chose to go the Drupal route for his organisation, and the single biggest obstacle to getting (and keeping!) my content creators and moderators on board, is the lack of a well integrated and robust way of entering and later on managing simple “pages with pictures” type of content. As jodd notes, this is down to a lack of a good media or asset library and seamless interaction thereof with the editor.

ok, first up, there is good news on the media library front in that a lot of great UX work has been going on around this and we should have an excellent Drupal Media Library soon! (there some UI work you can check out here: http://www.flickr.com/photos/mverbaar/sets/72157622536479456/) It’s not going into core as far as I know but it will be a great asset for our content end users.

secondly i want to reiterate again that from my perspective there are definitely two parts to this story: a) who is the target audience for the core UX, and secondly b) how do we create an environment where there is incentive for people to design and contribute themes, installation profiles, whatever it takes to help people like yourselves give your clients/content end users great experiences of using Drupal.

Tackling one of these without the other is not a solution. But tackling them in the same interface is not a solution either.

Exactly. We chose Drupal for all the things it brings to the table that you don’t find in other CMSes. But taxonomy doesn’t quite excite most content editors as much as image management and proper clean-up after a paste from *shiver* MS WORD.

@leisa yes, and sorry if I commented on the side of your main points. To try to answer you:

Media library: yes, I am indeed drooling over the proposed UI for this, it looks great!

However, I’m a bit confused over what this *is*. Is it just great UI mockups, or are there supporting code for it? I really want to enjoy it on my site, not only on Flickr and YouTube :)

I’m eagerly following the development of the media module, but as far as I can see (and I actually checked yesterday for both D6 and D7) the only working thing here as of now is the stream wrapping part. I also know there’s an upcoming code sprint for this later this month, so I’m eager to see the outcome there!

Not least: does it integrate with any WYSIWYG? As far as I’ve seen so far the answer to this is no.

a) target for UX core: very good question. For my part my goal is that I’m the only one who should need to go to admin/*, and I believe my users only should need to access the parts they need to access directly through the main site UI (typically create some content, or tweak minor things). Very much like Open Atrium has done it, and this I pretty much can solve today.

So is it better to target core UI towards developers? yes probably, but as more people have asked, who are the developers here? people like me who stitch things together and fine tune site settings, permissions and workflow, or people who create modules? if the latter, don’t they really need better APIs more than better admin UI? If you make it better for people like me, cool! But what I really need is not that, it’s *functionality* that doesn’t exist (or doesn’t cooperate) in either core or contrib.

Will this functionality come easier if the UI is targeted towards developers, and Drupal is focused as a framework / smallcore? If so: go!

b) for my specific issue: I *think* it would have been better if Drupal had made a choice with regards to editors and stuck with that for some time! And also, to have a proper media library (with API). If this was in core we would know what to go with.

I don’t want to bring it up as I probably will be accuses of comparing apples and oranges, but WordPress went with TinyMCE years ago, then made it work with their input and output filters, their permissions, then created a media library and integrated it. Today it just works great, the users love it, and they won’t switch until Drupal can offer the same.

The problem we have internally is that we have developers, and can even pay externally for this, but we don’t know which module(s) to start to help out with. Media? FCKeditor + plugins? TinyMCE + plugins? WYSIWYG API? IMCE? Custom file browser?

I suspect we will end up with choosing an editor and create a custom file browser solution that we integrate for our site, with plugins to this editor. This would be a lot easier to share for us if we could tap into a standard file browser and a standard editor, but we can’t yet. And that is bad for Drupal.

I completely, 100% agree with Leisa. When I got into Drupal I didn’t know any PHP, I’d never built a website before, I knew nothing about what to expect and I didn’t even really understand what a CMS was. I picked up Drupal easily, within about 1-2 months. I was doing this only in my free time, not more than 1-2 hours a day, but within 6 months I was writing my own modules.

It didn’t happen that way because a great UI guided me into it. It happened that way because I am technically minded, and Drupal is a great developer framework. With this in mind, I think each successive iteration of Drupal should strive to improve that developer framework so that developers can write simple end-user interfaces for specific tasks. Because really, Verity is not one person: Verity is a thousand people, each with slightly different needs that require slightly different solutions. It’s companies like Acquia that will create Ning-in-Drupal, and *that* is the friendly CMS that verity will use, not smallcore, developer-centric Drupal.

it may seem early, I guess. At the same time, there’s been a lot of work done, a lot of thinking done, a lot of testing done, a lot of iterating done on Drupal 7. We know a *lot* already about what has worked and not about Drupal 7. Also, if we’re going to act on feedback – not just listen to what people in IRC have to say about it – we need to think about who we want to gather the feedback from and how we’re going to prioritise that feedback.

Good UX is strategic not reactive. There’s no reason why we can’t get started on that strategy now and allow it to be continually informed by feedback from Drupal 7 as it become more available.

I strongly believe you need both out of the box: you need ‘Drupal for developers’ and ‘Drupal the CMS for more and less experienced end users’ to be all they can be.

They have to be both there out of the box because a good user experience for the end users is way too important to leave up to individual developers, however good they may be. There will be too many shabby and/or unintuitive user interfaces that will ultimately hurt the credibility of Drupal as a CMS.

So, I’m in line with the commenters who say: more separation between layers and tailor the UX to the target audience. But the base Drupal install should accommodate both audiences equally well.

a good user experience for the end users is way too important to leave up to individual developers, however good they may be.

I completely agree with this and this is definitely part of the overall picture that I’m trying to describe here. There needs to be a strategy whereby developers can easily provide a good experience to end users (Verity’s). However, I do think they are two separate challenges – equally important but separate.

Who in the community is going to spend their time developing this interface for Verity to go into the ‘out of the box’ experience? What’s in it for them? These are really important questions we need to think a lot more about and get some real, workable answers to. Just saying ‘we’ll make an admin theme, we’ll make an install profile’ doesn’t cut it in my opinion. Otherwise they’d be there already. Where’s the incentive?

The developers that’s who! We already spend time on each site tailoring the UI for Verity – mostly turning off and overriding all the generic UI elements that make no sense in the context of a site.

You seem to be falling into a trap of thinking developers don’t care about end users and it’s just not true. It’s just that we see the very best UX coming from custom per site, per application, per task development.

At the same time we’re sick of constantly re-inventing the wheel, so anything which gives us better UX out of the box is a good thing.

I think the community does have an incentive to make that OOB experience better, but we need the right setup and tools to do it first.

I definitely *don’t* believe that developers don’t care about end users – during the course of D7UX I saw lots and lots of developers trying to customise Drupal so that it works better for their end users, but as Jeff Eaton pointed out above, trying to hack the standard Drupal interface so that it works well for Verity is a time consuming and low reward task.

Making a UX that can be reused that is optimised for the use of content creators/administrators is a big job – it’s not a matter of making minor modifications to what fields are displayed or not. I don’t see who is going to make that big effort and then share it with the entire community – as much as I see that the entire community and beyond would benefit.

D7UX was entirely based around this entire objective – to make OOB better for Verity, and we were far from overwhelmed with offers of help from within the community to do so. This may have been because there was a perceived detriment to the developer experience in doing this work, but I also think the ‘what’s in it for me’ factor was heavily in play.

I agree with Leisa: yes, I know, developers _do_ most of the time care about the end users and work to make their solutions fit the Verities of this world. But then, they have to, because the standard Drupal UX for Verity isn’t all that great.

And sometimes, most of the time I’d wager, client budget simply doesn’t stretch to include major UX reworking in the content entry/management department. So what you get OOB needs to be ‘good enough’ for 80% of the work and flexible enough for the developer to stretch it for the last 19%.

I think you have a jaundiced view of the community, probably understandably so given d7ux :)

Or perhaps I’m too much of an optimist.

As i said in a different comment, much of the community had pretty much reached the same conclusion as you outlined in this blog post *before* you started d7ux. There was a perception that d7ux was just going to be more stuff to turn off, work around – more low reward tasks. Because as far as we can see generic UX is poor UX.

I think we’re largely in agreement and I think given the right focus the community can come together and “make that big effort”.

@adrinux: well, with my client glasses on I’d say that I don’t care much where UX improvement comes from, whether from smallcore or generic improvements. Right now UX improvements for my content editors come from my pockets and some of the things I need to fix are things that I feel I shouldn’t have to fix on a CMS. (But it’s a balancing act, because there’s stuff in Drupal other CMSes don’t provide.)

With my ‘hey I like Drupal’ glasses on I’d say that all UX improvements, especially in the media/asset library and the editor department, help. Smallcore is one solution, but there’s also still more than enough to win going along the lines of D7UX and refine and rework for D8, especially if changing the user interface is made easier by separating the layers more.

The one thing I like most about Drupal and the Drupal community is that rarely if ever the easy road is taken. Changes are fiercely discussed on what is fundamentally the “most right thing to do” and then they are made so. Maybe it’s not so bad to slap some easy pavement down while still working on the fundamentally better road next to it.

The challenge with “out of the box” for Verity is that Drupal is too versatile. There are way way way too many kinds of sites you can build with Drupal to have an out-of-the-box solution for the end user who doesn’t know how to or doesn’t want to download and use contrib modules.

The answer, as I see it, is to make Drupal a rockin smallcore framework, and focus the Verity experience on installation profiles and Features (as in http://drupal.org/project/features) and what evolves from there.

The fact is that everyone needs to extend Drupal core for their purposes. It’s the extending that’s the barrier for non-tech people. With an improved method and workflow for extending Drupal with contrib modules/profiles/features/whatever, the Veritys of the world have Drupal opened up to them.

Just taking difficulty of extending Drupal as a given, and trying to focus on making core be everything to everyone, is a mistake, imho. Core cannot be everything to everyone. In fact, I would argue that core cannot be everything to anyone.

To make that extensibility easy to execute means that Drupal really has to be as robust as possible a developer framework, so that contrib efforts have all sorts of great ways to plug into and leverage the power Drupal core brings to the table. In the end, everyone benefits, imho.

To me, that’s why #smallcore. And that’s why I think Leisa has stirred up so much conversation in this thread.

I’m not sure I would want to see _exclusively_ an atomized collection of feature servers serving up a broad range of Drupal user experiences. Open Atrium is compelling because it is the first… what happens when there are 40 of them? All with different project websites only loosely connected to drupal.org?

I think there has to be “one ring to rule them all” which is a generic CMS (perhaps a community management system or just a content management system) that is Drupal for Verity.

It is maintained along side smallcore and is released with smallcore releases.

And interestingly enough, would basically be the “contrib stamp of approval” that Boris was talking about for the Drupal community years ago and Acquia is currently providing.

To clarify, I was speaking to Features as a way to package configured feature sets, which are easy to install, easy to distribute, and package more than just one module’s offerings. I did not suggest that such Features should only be offered through distributed feature servers hosted all over.

+1 to Leisa, Larry, Robert and Jeff.
Pretty much all the people I talk to on IRC now think this is the way forward – and have for some time, probably even bere Leisa and Mark started work. Different terms get used ‘smallcore’, ‘distributions’ etc but the end result is the same thing – separation of the core developer framework and the UI layer on top AND specialization of the UI for specific groups of end users.

It’s a credit to Leisa that she’s grasped this so quickly. I’m dumbfounded by Dries though, but perhaps that’s vested interest, if Drupal goes the way the developers want Aquia will have to in effect create and maintain it’s own distribution and have more competitors to boot :)

Drupal 8 is either going to be the release where Drupal gets completely rewritten and refocused – or the point where the community forks.

It’s hard to solve big-picture problems in the Drupal community. I thank you for trying, but think the project would have been more successful if it were focused on smaller goals and style/framework/pattern guidelines.

Regarding guidelines, Drupal suffer’s from too many interaction model’s. Defining standards would have given developers a framework which could have resulted in common interactions for users, e.g., Verity & Jeremy should expect an alternate view of the same data if they click a tab. Without such a framework in place, I already see the current use of tabs being used in too many ways.

Regarding smaller goals, I still like the previous admin menu better. It has problems, but IMO those problems could have been fixed by articulating a pattern (helping to arrive at the right IA). Instead we reinvented the wheel.

“Focus on a developer toolkit that gives them more and more flexibility and capability to build cool stuff,” suggests we focus on things like style guidelines and improving the framework – which I clearly agree with. However, there’s more to this than just creating a developer toolkit. For example, Macromedia Flash had the designer/non-engineer market cornered, but could not attract developers. To fix this, they converted Flash into a toolkit for developers. The result… a growing developer community, a shrinking non-developer community and an overall shrinkage in penetration.

So to be clear, we shouldn’t JUST focus on a developer toolkit. We should focus on a developer toolkit that promotes good experiences. But we should also check our solutions against Verity & Jeremy and make sure we’re not moving backwards.

Jeff, the only way that taking small steps is ever going to work from a UX perspective is if we all have a common vision, strategy, of what the end goal is, which we clearly don’t have.

I fail to understand this assumption that refocusing the core of Drupal negates a focus on good experience. Quite the opposite – it *allows* us to deliver good experience because we can know, understand and support our end users.

But refocusing the core of Drupal on developers *will* negatively impact both Jeremy & Verity’s experience of Drupal core because core will no longer be intended for their viewing pleasure. This is why this is a double pronged strategy – refocusing the target audience of the Core of Drupal and finding another way (a great admin theme, install profiles, commercial service offerings) to ensure a good user experience for Verity & Jeremy.

If we persist in the belief that we can serve both audiences well from the one interface we’re perpetuating a delusion that is doing Drupal absolutely no favours.

I’m not saying smaller steps is the solution, I’m saying THIS particular project would have been more successful if smaller steps were taken.

There’s a big gap between what Drupal is today vs. a perfect solution for Verity & Jeremy. You were up against a tight time line and hefty learning curve. Given those constraints, I think the project would have been more successful if you stuck to smaller problems that had big impacts vs. a redefined vision of drupal that required a ground-up rebuild.

I agree with Jeff. I’m guessing we could have accomplished more, if we focused on the problem areas that were previously discovered through formal usability testing.

In part this is because I over-estimated (no offense) how much you and Mark knew about working with Open Source communities based on your experience with the drupal.org redesign project. Despite all the good intentions and hard work, it took a long time for you guys to break out of your comfort zone and to learn the Drupal-way of getting things done. Better understanding of how Open Source communities work, would have helped bounding the scope of the project, would have brought you closer to the community, and would have let to better focus and velocity.

And yet, this was a really interesting journey. It does seem clear in retrospect that the project was overly ambitious (given the time constraints and less productive than it might have been (at least in terms of getting more practical improvements into the Drupal 7 release), but I think having an “outside” set of eyes critique everything now and then can be very helpful in helping us determine where we are at today vs. what Drupal could be someday (what does perfect look like?). Open-source projects, Drupal included, tend to develop in such a piecemeal fashion (and most of us involved understand why). Still, I think there is room for mixing in some big picture analysis and long term road mapping. And I am thankful that Acquia (and Mark and Leisa) has begun facilitating some of that.

1. Not meaning to be a told you so, but in retrospect, which part of the D7UX design processs would you change/improve for you to reach this conclusion earlier? Or, how could the community have made that point clearer, earlier? A lot of these insights were already emerging in the community. As much as D7UX has helped in advocating the importance of UX design, it has clearly also enstranged people from it. As you say, some clear red flags were raised from the beginning. What was missing there to really acknowledge them and adjust the strategy accordingly? Again, not a told you so but a question on the lessons learned there. Because overall my impression is that it has been really hard to get you to adjust things. And no playing the “insider” card here please! :-)

2. Because it’s exactly through educating the insiders that we can start building the right experiences for outsiders. Verity is furthest away from the people currently using/building Drupal. Whereas ‘super-Jeremy’ is often the person who shapes core and contrib into the custom solution needed by the client. It remains true that every first time user of Drupal starts out as a Verity, developer or not. Maybe Verity can still inform the first 30 minutes use scenario, but after that focus the experience on (super-)Jeremey?

3. I would certainly think that providing a richly useful UI layer is a task for core. It may be important to mention again that we’re not in the business of building UI for web sites but UI for applications (that let you build web sites or web apps). I see Seven, the theme, as the first steps towards a unified skin (theme) for exposing these application widgets. So, yay for seperating front-end and admin theme by default, it’s one of the biggest wins of D7UX.

… And now just before posting I see Jeff making similar points so I’ll stop here.

Thanks for another good post, the one that triggers great feedback ;-)

1. I think the crux of the problem here is that the brief for D7UX was, effectively, to design for people outside of the community – to extend the reach of Drupal. Research that we were doing with these end users indicated that we were on the right track.

Feedback from within the community indicated that there were issues with the approach that we were taking from the developer perspective. But here’s the issue – it was almost symptomatic of the fact that we were meeting our brief that we were getting this feedback, it almost confirmed the fact that we were doing some things right. This definitely made the red flags re: wrong target audience difficult to spot.

It is certainly not my recollection that there was a clear message from the community that the stated principle of privileging the content creator (Verity) was actually not the right approach. Perhaps we should have been able to interpret this from the wide range of feedback we received – but to be honest, I’m not sure that any of us really knew exactly what was fundamentally wrong. It is a shame that this has resulted in estrangement, and I think it is because we were coming at the design almost at cross purposes. I hope that if we are able to come to a united vision for the UX then this is something that we can avoid in the future.

2. Hrm. I’m not sure about this anymore. I used to agree with the idea that educating ‘insiders’ will help them build better experiences for ‘outsiders’ but I think there is a limit to this. I think we can definitely help ‘insiders’ build good experiences for ‘people like them’ who are new to Drupal, but I’m not sure I expect the majority to be interested in building good experiences for Verity (although some definitely will).

I also don’t feel that every first time Drupal user starts out as a Verity. Verity and Jeremy are not two points on the Drupal learning curve, they represent two very different experiences of Drupal.

With any luck, most Verity’s will never see Drupal before it has been finessed by developers, will never have to do anything but create and manage content and perhaps users in Drupal. Verity doesn’t want to move along the Drupal learning curve, she just wants to get the part of her job that involves interacting with Drupal done as quickly and efficiently as possible and then to move on to the rest of the things she has to do with her day. At least, that’s the end user I intended when I sketched out Verity.

3. I don’t think I’m suggesting no UI in core, that’s not my intention. I also see Seven as being the first step in the journey and I agree that separating front end and admin is a major win, yay indeed.

thanks for the thought provoking questions, yoroy, I hope I made a reasonable attempt at answering them , and I hope we continue to talk more about this in the coming months.

It’s easy to say make the small core a terrific developer framework and then leave all the out-of-the-box magic to contrib packages like profiles, distributions, packages, and spaces etc, but that does turn its back on what I understand to be Dries’ primary directive for Drupal, which is to eliminate webmasters and developers from the site-making process, to allow anyone to throw up the web site they need simply through UI settings. Dries’ last keynote was in part about how Drupal will become more and more of a product. He didn’t say developer only product, did he?

So fine, let’s have our brilliant small core but let’s also create a developer mechanism on drupal.org and in the drupal roadmap (OK so there is no roadmap…) that will ensure that finished, polished packages are part of the product offering are not just left willy-nilly to contrib.

If we are really to embrace small core and a multiplicity of UX solutions (that are all or mostly at least guided by good UX principles and where possible by common UX principles), then the various profiles, packages, distributions, etc. or a select subset of them should be in core, too, or perhaps in a second layer of core, so that they can in fact be sure that they will be developed subject to an agreed upon big picture UX philosophy.

So when someone goes to download Drupal, they don’t just download core (unless that’s all they way). They also check off which features they want installed and which UX pattern and which admin UI skin and which theme, and then the installer just pulls in all the desired parts and turns things off and on as needed. This would probably do more to make Drupal usable for non-developers and make Drupal more nimble for developers than anything else.

Core already ships with an ‘expert’ and ‘default’ install profile. What we can try to do is make sure those profiles, and any others, obey the same rules that contrib profiles would, without necessarily punting all ‘CMS’ functionality to contrib.

For me, node.module wouldn’t necessarily have to be part of the ‘framework’ – since it’s only a few patches away from being an optional module as it is. However I don’t think anyone wants to remove node module from core, since that’s a 99.9% use-case for core, not 80%.

Core already ships with an ‘expert’ and ‘default’ install profile. What we can try to do is make sure those profiles, and any others, obey the same rules that contrib profiles would, without necessarily punting all ‘CMS’ functionality to contrib.

This approach, IMO at least, is the responsible way forward to a developer-oriented framework and a user-oriented ‘default product’. The key is making sure that the modules, solutions, and tools in the ‘default product’ don’t take advantage of their privileged position in core to shortcut the (currently frustrating) process that contrib profiles and distributions have to.

Unraveling the tightly coupled portions of the core product, and making it flexible enough that other distros can do everything that core’s “product” does is a long-term goal, but I think it’s worth considering as we deliberate on directions for Drupal 8.

Right, right, right. I think so much of the of the reaction to the smallcore movement is based on fear that the goal is just to remove things. But Jeff nails it here. The goal is to decouple the core from the default product. Having that separation will, unfortunately, make the default product harder to create. But the payoff will be huge, in terms of the ability to create custom products that people want to use.

None of what I like to add belies your statements.
End User UX and Dev UX are not exclusive. They can and should be complementary.
A layered framework is only possible if the layer is the core of everyone’s focus. Otherwise we’ll end up with java.
Developers and designers have similar wishes:
A wiki and threaded discussions on drupal.org. Sketching. Improvement of the issue que. t(). Standardized ux libraries.
Developers and designers have similar problems:
No seperate view for the content administrator. Lack of a default setup. Lack of content. The issue que.
Inline editing would have launched drupal further than iis support.
Primary focus should be on (better explaining) drush, rules and features as well as on the ux project. Developers need this stuff just as much as the large crowd does.

“The most obvious is to design and develop an admin theme that is specifically targeted at these end users that can be applied by developers once the development work is done and the site is being handed over for administration.”

That, as a developer, would be first prize.
The biggest issue I’ve faced is that the clients I build Drupal sites for are scared of the admin interface. Even adding a single page seems to confuse them. I’ve resorted to a help menu for some clients.

To be able to cut the amount of options down to the bone would be ideal – I see this as being part of user role creation, possibly selecting each content type and filling in default values for specific fields. Those fields would then not be presented to that particular role.

I think every client I’ve ever built a Drupal site was scared of a full-fledged admin. Paring down the available options helps, but the permissions system doesn’t completely map well to the interface options. Perhaps this is another area where UX might actually help to drive improvements in the overall Drupal framework.

I don’t see, why Drupal cannot evolve towards both target groups. Of all OS-CMSes, Drupal is the best to evolve in several directions because of it’s great code basis. Why not have two Backends?

Or to use Dries’ metaphor of Drupal as a Linux for the web … Linux exactly done this … Linux started as an awesome powerfull tool for developers, and then a few people of the Linux Community started to develop things like KDE an Gnome … ok, ok Linux Distribution are not the perfect Example for great UX and Usability, but the division of labour and target groups works.

So, if we pursue a vision of small core framework + product distributions, how do we fit (some of) the product distributions into the official release cycle and how do we choose which distributions to develop and include as “official”? And do we keep them on the same release cycle (eg Drupal 8 would include smallcore8 + one or more polished distributions) or do we release and maintain them separately?

If, on the other hand, we leave all product-oriented distributions to contrib, do we sanction/recommend some of them more than others? What gets mentioned on the drupal.org homepage? What gets promoted? How best to continue Dries’ vision that Drupal be(come) among other things a product that non web people can use to put up sophisticated web sites? Would there be incentive/money for developers to develop and MAINTAIN/UPGRADE these distributions? Or would these product distrubtions increasingly only be available through commercial programs like Acquia Gardens?

Since Dries (I think) appoints the code czar for each release, I would think he ultimately would make or help make a decision about whether commercial packages would be included in the core release schedule and whether the same person would oversee both smallcore and distribution code, or a second person/team would be appointed. It doesn’t seem like it (transforming the current core model into a smallcore + core distributions model) could happen/succeed without high-level decision making and infrastructure commitments to support it.

I’ve been having the idea of a KDE or GNOME for Drupal – and I think Leisas Outline goes in this direction.

How can we build the inner core onion skins to separate out the interface as much as possible?

This would enable people passionate about the interface to build it according to a coherent and streamlined vision that makes it easy to use in the end.

As the community grows bigger and – hopefully – Drupal 7 and some – also hopefully to come (Baris, Yoroy, Dries, John Albin, Maarten and some others know what this is about :) ) – will attract some more Designers and Interface architects to the Drupal Project.

So a separate and yet close with the core core people interacting team could be built, consisting of Designers, IA Architects and Developers who like that stuff. Dream the dream…

Totally understand the essence of this post, but have to admit I’m bummed by it *if* Drupal does take a developer-centric direction. I’d hoped I’d soon see the ease-of-use of WordPress with the bullet-proof, fast and solid Drupal core.

With small business continuing to be the engine of growth in both the developed and developing world, are you not seeing the need for personal, media and social publishing solutions like everyone else is? In some respects, this post was hauntingly similar to arguments made by television broadcasters about the crappy user generated content with Flip and other so-called “HD” cameras and that only “real” journalists and photo-journalists should be the ones creating and delivering visual stories.

Should this accelerating trend be ignored because the makers of video cameras currently make huge dough on broadcasters and that’s where the energy is at the moment?

Same arguments happened with the printing/publishing/prepress crowd when “desktop publishing” emerged…but we know how THAT story ended since you can’t find ONE publisher that doesn’t use Quark or InDesign to create printed products and those products are almost always delivered from digital presses.

There simply are not enough developers in the world to create and deliver the hundreds of thousands of web assets that the world desperately needs. I should know: I pay them on projects, subcontract to developers, and am personally deep in the bowels of Drupal, WordPress and PHP.

So focusing solely on developers is great if the goal is to deliver an open source project that will see a few dozen web assets per month released and be ones Dries can showcase on his blog. But to get to scale, Drupal MUST move beyond developers and deliver a poweruser-centric framework that makes it simple to deploy a web asset and then hand the reins to users who need to create, edit or modify content.

To do otherwise gives WordPress incredible runway to take their incredible ease-of-use and huge momentum and create a core that rivals what Drupal delivers today.

@sborsch you’ve completely missed the point of both Leisa’s post and half the comments here. No one is talking about making Drupal developer centric, rather we’re talking about making a split in drupal, with a #smallcore that is developer centric and distributions built on top that are user focused. And not generically user focused but focused around more specific tasks – community site, blog, newspaper etc etc.

What we’re talking about here is making it *more* user focused *and* easier for developers to build on. The latter actually helps with the former.

I think what I’m really suggesting here (and the title of the post admittedly doesn’t do me any favours) is that Drupal *core* is for developers but that the Drupal community has a great opportunity and perhaps even responsibility to look for ways to ‘package’ Drupal in a way that is a much better experience for the non-developers amongst us who would love to have much better access to, and a much better experience of a tool like Drupal.

For us to have only one part of this conversation and not the other is – I agree – a major bummer. Let’s not let all of the talk about small core and designing for developers take us away from the other challenge this position presents which is: how do we look after these other very important end users (who represent so much potential to us), and how do we create the incentive for people/companies to create these tools/experiences so that we stop talking about it and actually get to work doing it.

So I am confused, I astraid from commenting on this issue especially as yoroy asked most of my question. This reply seems somewhat, diffrent then the tone of voice of your blog post – which to me seemed far more provoking.

Basicly, you purpose a distrubtion of core? Wich is friendly to a “Jeremy” ? But not core itself, core itself beign developer only?

Thanks for writing this. There is surely need for both better UI for developers (for building and making things better) and better UI for actual users of running website (from the point of content management).

Thanks for this, Leisa! Both your initial post & the discussing following it have been very thought-provoking. “#smallcore + distributions” seems to be the best way to get Drupal out in the wild for the largest number of people.

For example, I work as a Web developer at a nonprofit, and am also currently developing a website for my church. Both are in Drupal. But I’ve had to undo a lot of the work of the D6 admin UI to make them usable for people approximating the Verity role. yhahn’s Admin module (which is an approximation of part of the D7UX vision) has made my work a lot easier, but there was still much to be done.

I think things like Features will help us move forward to a place where the initial site builders can go through a kind of wizard-like install process to create the site platform, and then the ongoing site admins/content creators can step in. But in order for this to be possible, we should make core development focused on APIs while leaving the UI innovation to contrib. Design by committee is rarely effective.

Again, Leisa, thanks for your insight, and I appreciate you having the grace to recognize publicly some of the initial missteps of the D7UX project. I still support the vision of broadening the reach of the Drupal community, but we need to ensure that the UI work of people like merlinofchaos & sun is supported by core. If core has too many defaults that they have to override, it can only be discouraging for their future development work. Drupal 7 will still be a great release even if D7UX didn’t achieve all its initial lofty goals. But refocusing for D8 (and a roadmap?) will hopefully that release even better.

I think that installation profiles can (and perhaps should) be the bridge between Drupal as a tool and Drupal as a product. This allows developers to tweak Drupal as they see fit, while people without the skills, the time or desire to to that to still use Drupal with a click of their mouse.

Apart from radical changes there are also still a lot of things that can and definitely should be changed that do not alter how Drupal works, but that do make Drupal easier to use. Think about nodes and Taxonomy. Complicated descriptions and difficult terminology that stems from Drupal’s abstract code architecture make Drupal’s workflow unusable for a lot of potential users. We can change this, but as a lot of discussion proves, not all developers agree with such changes (see node versus content).

@Bart Feenstra
Install profiles? You mean the technology that has been in Drupal since 4.7 and only just started being used? Before such a thing could happen, people and teams would need to mature to demonstrate that there are people willing to maintain broader general use profiles. These technologies would also need to mature distribution methods from drupal.org or they will die out and disappear.

It’s not just about the neat technology, it’s about the people, infrastructure and processes that will maintain those distributions going forward. There are people working to build this infrastructure but they are few in number. If you want to see this vision, get involved in the issue queue sooner then later to resolve these issues.

As a developer, I want a product (so I don’t have to spend my developer resources developing common functionalities and utilities. I want the basic site up and running with most community functionalities in a few hours without the need to do a lot for the overall design and appearance. I then want to turn my attention to powerful development tools that will let me develop great applications that easily tie into the Drupal user interface shell.

What does this mean: I would like to see 3 parallel development streams:
1. a small core framework that is rock solid and infinitely expandable via modules
2. packaged suites of modules that provide common functionality and utilities for targeted audiences (including modules to help build social communities, communication, content management, etc. such as blogs, forums, newsletters, comments, image management, articles, file uploads, import/export utilities, etc.)
3. development tool sets for customer development to extend the core functionality in impressive ways. These could include web service interfaces, database tools, complex data entry and validation tools, version management, test platforms, etc.

By making the core framework as small and solid as possible, a solid version should be able to be available quickly. Then different audiences can get the packages of modules either on the design, appearance and basic functionality side or on the complex development side.

One of the best investments you’ll ever make is the RushCard prepaid Visa. Which means no overdraft fees, ever. You can build credit history and even transfer money to someone else’s RushCard. I got my RushCard at http://www.edigitalonline.com.