The Drupal core product needs to become more engaging and useful right out of the box. Usability testing has shown why. Here, we want to look at how we can change our process to be more efficient and effective.
We learned during the Drupal 8 process, that our way of building the product side of Drupal has many challenges. We propose to adopt a different way of working that avoids current pitfalls and enables a fresher, faster way to iterate on the core product.
What exactly are those pitfalls you say? Glad you asked! There are many ways the current process can be stifling, but in general terms:
- Lack of agreement on our target audience makes it near impossible to make design decisions and accept the trade-offs that come with them.
- A lack of reassurance that changes that are worked on will be accepted. This prevents people from even starting to work on changes and burns out the people who do.
- An inefficient, consensus-based process for implementing even largely agreed-upon changes.
This is no fun! This way of working has led us to the point where we now have:
- Significant UX debt in primary site building tools that are hard to use, even for highly technical users (views, blocks, modules).
- A design and development process that requires incredible investment to succeed, putting meaningful change beyond the reach of any single individual or even Drupal company.
- A process that can be completely derailed at any time because much of what we are dealing with here (feature prioritisation, workflow optimisation, user inteface design) is considered subjective.
We’ve been making product strategy decisions on a daily basis for 10 years simply by deciding what to commit. We never articulated these decisions on a strategic level. Target audiences, feature roadmaps, and choosing a position in context of industry trends are ways to provide guidance and transparency we currently lack.
So how do we set priorities, get faster and radically improve our ability to improve?
Tackling the most risky hypothesis first
We have become a lot better at identifying the challenges that can be managed and split up in separate issues. We’ve also defined clearer paths for getting new things added to core. But, to some extent this has also made us risk-averse. "Divide and conquer" has not been a good approach for tackling the really hairy problems in our user experience.
We have to find ways to start tackling higher-level, conceptual problems such as:
- Finding key functionality in Drupal; users are unable to quickly find their way to and around key site building tools.
- Disconnect between what people see (the front-end), and what steps we require to change this in the backend.
- The (lack of) separation between modelling content and its representation, in our site building concepts.
Roy Scholten has a longer overview of Drupal's UX challenges.
It is tempting from a process and resource perspective to avoid these challenges as they require seemingly unrealistic amounts of effort. At the same time, Drupal adoption is held back because these key Drupal strengths are hard to understand and use.
For Drupal to stay relevant and grow we need to tackle the hard problems, and many of our hard problems the hard problems are not about new features.
We often equate output (e.g. new feature X, Y, Z) with value creation. We need to shift to outcome and impact.
However for Drupal to stay relevant, we will have to continue the discussion of who we are targeting with Drupal and which core concepts need to be reinvented and aligned with new technology disruptions.
Decrease the up-front investment: experiment in increasing fidelity
In our current process, the amount of planning, research and design necessary for introducing new or redesigned functionality is too high compared to the impact of the actual change. Any significant change often takes months worth of design, discussion, and code.
What’s more, the impact of these changes is only truly measured after release.
Our goal should be to dramatically decrease the up-front investment necessary for finding out if a design or feature is useful, usable and mature enough for Drupal core.
This means:
- Adopting modern software development methodologies that speed up the process from idea to final product
- Moving from a consensus based approach to an experiment based approach.
One of these methodologies (pictured below) is Lean UX. The basic premise is that you formulate a hypothesis for an idea that you try to validate/invalidate as quickly but realistically as possible.
Our first goal and measure of success would be to prove that we’re indeed validating more ideas faster and more easily.
Provide clarity around priorities
"Scratch your own itch" has long been the driving principle for what people decide to work on. However large changes such as Views in core and adding Symfony were large challenges that got commitment early on.
For the larger community our commitments and product strategies are still mostly invisible. This means that on the more tactical level of day to day contributions, people find it hard to know they are working on the right thing.
Usability testing results on Drupal 8 has already shown what needs work. To be frank, the last 5 usability studies have resulted in few new insights - we know our big weaknesses.
We need to make the implicit roadmap of Drupal more explicit and be clear about which changes, when proven effective and mature enough, will make it into core once. This will provide direction and help attract the new contributors needed to tackle the work ahead.
Tackle the big ones, experiment more, clarity on priorities
Our goal is to establish a more predictable process. A process that gets us to measurable results, faster, with solid insight into the validity of an idea. Individuals and companies will then be able to dedicate their resources to a particular initiative because the risk of getting a design change in core is reduced and more transparent.
Here’s a handy summary of what we’ve discussed in this post:
- Iterative prototyping and testing
- Validating ideas more early on with prototypes of appropriate fidelity for the hypothesis - actively avoiding, jumping straight into core patches.
- Increasing community involvement in the early stages of a concept, instead of when it reaches “needs review” in the issue queue.
- Create room for experimentation in core (experimental package)
- Validating the “market viability” of concepts directly in core, instead of in contrib or in the core queue - providing a more realistic picture of how ready it is.
- Allowing experimental concepts to mature directly in core, will result in a much larger user base to provide feedback and help out.
- Clarity around priorities
- Define a UX roadmap with prioritized changes based on user impact
- Focus contribution efforts around these initiatives
How can we make this change? Your feedback!
Where do we start making this change of process? We are not sure, we need your feedback!
We have already made a lot of progress in the past few months that enables a process that provides more feedback, sooner. We’ve introduced an experimental package; which now includes BigPipe, Migrate, Inline form errors.
The next step is to come up with approaches for improving our process for large changes. We’ve outlined what we think are the first things to work on above.
Some potential topics to discuss:
- How can we motivate more contributors from developers, designers, to project managers and writers to contribute to large UX initiatives?
- To what extent can we have a more top-down - process that allows for direction on hard-felt issues, we’ve been unable to rally around (e.g. improving Field UI)?
- How can our process better support the process of exploration to decision making on discussions like the component based front-end?
- How can we loosen our process, to allow for more experimentation.
We are really interested in what you think, please let us know! :)
Comments
This all sounds good...
I think a new process for usability improvements sounds like a good idea, in principle. But as a developer/contributor, what is presented here is still too vague to be actionable, so I don't know if it is a good approach yet or not. I don't have a clue how it would work as a process.
One other thing... Eventually, any idea that goes through the process outlined here will have to make it into a patch, which will need to get reviewed (with code, standards, and other considerations) before it can get committed. And our patch review "process" is still a HUGE problem -- to me, that is the most discouraging and broken part of our current Core development process. We supposedly have maintainers for most of the parts of Core, but that doesn't help -- they don't review the patches in their areas (in some cases, they don't even if you specifically bring them to their attention). So... We need to solve this problem too -- I don't think it will ultimately help to have a better process around proposing and testing usability improvements, because ultimately they will still have to be patches and have to get reviewed and committed. Which, as far as I can tell, is completely broken.
Drupal programmer - http://poplarware.com
Drupal author - http://shop.oreilly.com/product/0636920034612.do
Drupal contributor - https://www.drupal.org/u/jhodgdon
I couldn't agree more...
As much as I would love to see usability improvements finally be committed to Drupal, the review process is definitely the bigger problem. Not only does it infuriate existing contributors, but it almost certainly prevents new community members from staying engaged for a significant period of time.
With regard to usability issues, just look at the last comment in #2523154.
That was 7 months ago... So even when you do make it as far as getting the design set, implemented, and reviewed for usability, it, like hundreds of other patches, gets stuck in limbo.
That is bad for everyone. Issue reporters end up having to see if the issue exists and/or provide additional information for multiple versions (8.0, 8.1, 8.2, etc) and the patch creators/testers have to constantly re-test. Eventually, people just give up.
Holes in this approach
First off, thank you for writing this post. I am personally pleased to see that there is a continued effort to not only improve the UX of Drupal, but also the process by which UX improvements/requirements are defined.
I for one am a large proponent of the Lean methodology, and have used this pretty extensively within my work. I think it could be a great approach to identify and validate UX improvements for Drupal.
I have a few questions about this proposal that I hope you can answer for me:
1) There needs to be some level of market research conducted to inform hypotheses. Who would be responsible for conducting this research? How will it be performed?
2) Hypotheses in Lean UX are centered around user personas. If there are no agreed upon target users of Drupal, how will those working on these experiments know who to run tests with?
3) One of the core tenants of Lean UX is to fail early and often. How do you envision this being accomplished in core given it's infrequent release cycle and the complexity that may go into prototyping any UX changes in the system?
A few additional thoughts:
For this process to work, there needs to be a greater level of trust within those appointed to determine the UX direction of Drupal. This should work sort of like Congress. People are elected/appointed to represent the community at large in setting the UX direction, and we should trust in their decisions. When a bill is to be voted on, a member of Congress may turn to their constituents for their opinions, but ultimately that member of Congress was elected by the people to represent them and makes a vote based on their judgement.
There also needs to be a real product roadmap set for Drupal which will give focus to this Lean UX process. From my perspective, there is no clear vision for Drupal, and no goals set for what it needs to be and when. That roadmap should be what really drives what UX improvements are made and when.
Lastly, I do not agree that contrib shouldn't be the place where experimentation happens. There needs to be a balance. Part of this process should include a means of identifying innovations in contrib that could add great value to core (informed by the product roadmap), and working with that module developer to make UX improvements that prepare the module to be incorporated into core.
Thank you for your response and raising important questions inde
Correct. Bojhan pointed out the need to do more competitive benchmarking before. At this point, it's through initiatives and priorities defined by project lead Dries. The results from big Drupal product survey will likely inform the short and medium term for new features, necessary changes.
Our research should become a more ongoing process to keep abreast of trends and informing/correcting the direction and priorities derived from a yearly big bang like the product survey.
Correct. Target audience definition is one of our weakest points. We didn't get into it in detail in this post but it's a crucial element for knowing which priorities to set. Do you have ideas around this?
One example of a more generalized approach to persona is how it was done for drupal.org. Initially started from specific roles as we are wont to do (content author, site builder, developer) shifted to skill-levels: beginner, intermediate, skilled, master.
I think it would be good to stay away from content author, sitebuilder, developer persona, because in many cases it is often the same person that switches between those roles. It's in that spectrum between content creator and developer where much of the Drupal strengths are. Maybe it would be a start to simply make our assumptions about who a change is for? We see it now with some issue titles that have for example a "DX" (Developer experience) prefix, so targetted at developers. Maybe it should become part of the issue summary to state which roles are targetted.
That's one of the big challenges we're looking to get ideas for :-) We need to decrease the up-front investment necessary for vetting ideas. At minimum we need to find ways to build, measure, learn things that are not core patches. So paper prototyping, interactive wireframes, frontend-code with mock data… We can't pinpoint the exact details of, say, configuring a date field, but we want to find ways to test lo-fi prototypes to help us validate the more general approach for "adding a field to a content type", before clarifying all the individual details.
4) "Core vs. contrib"
Of course it shouldn't be an either/or for where experiments should happen. But things like a new Field UI or Menu UI or a mix of onboarding and sample content added to the default install profile will be hard to validate through contrib. What I think we want to achieve is at least some room to experiment in core as well.
If you have suggestions on any of the above I'd love to hear them :-)
Thanks again for your thoughtful comments.
How can we motivate more
I can't speak for everyone, but I think one aspect of it is that you have to deal with the entirety of Drupal core even if you want to help on the UX.
One central piece of your approach is an MVP, which be definition cannot directly replace the existing UI. How do you think can we separate the current UI with the new UI gradually, so without adding regressions/impossiblities for the user, while still making it easy for them to check out the new UI. Are experimental modules the solution for that? The example of inline_errors though seemed to not get too much attention these days.
One day I though: Let's truncate
MAINTAINERS.txtand start from scratch. Let's be serious. The way how we work on stuff is fundamentally broken. Both we have MAINTAINERS because of historical reasons, but on the other hand people, which actually want to improve something cannot get anything done as well, because they don't receive any kind of trust. For me a solution is to pull together Drupal core from a collection of external developed pieces, while making that a primary style, so its integrated well into the normal core workflow. I agree this is really vague, but otherwise the problem of late involvement of the community comes up again.We are definitely subject to
We are definitely subject to core process which has many significant challenges. However as insiders, I also want to make sure we are aware that many contributors never reach the queue - as they don't know where and how to contribute.
@jhodgon While I agree with your sentiment, that in the end it will reach a broken process. But I don't think that should hold us from reinventing the path that leads up to this. We have a lot of challenges engaging with enough contributors, before it even reaches the queue.
This core process, is worth a discussion. Although I think that stretches far beyond, what we can discuss here. Focusing on UX, the biggest pain point is not so much the process for creating the patch - but all the discussion that can be incredibly derailing, as its a more subjective matter to some. We want to reduce the impact, of this from our process.
It always troubles me when people say they don't get enough "trust" to make decisions, the purpose of maintainers should be that they are entrusted with a position to set the strategy/tactics on a certain area. I think the Maintainers.txt is a very bad representation of that decision tree. Honestly as a maintainer, you shouldn't stand in the way of change. However being enabling, is an incredible time-hog. Because most times being a maintainer means you spend thousands of hours forming good ideas, with bad execution to good execution. We don't have a good (transparent) process of evaluating, the level of execution needed for a good idea vs. impact on our product.
I am not sure yet, how existing UI's could live next to new UI's. We should probably be accepting, that new features might not be captured in the old. I don't think that Experimental modules are a way of creating attention. It would largely be a way, of having a process for graduating ideas that are not "done" yet - which in to some extent a way to bypass the normal patch process for big initiatives.
Are experimental modules the
Inline form errors is a bit of an odd one since by nature it only affects forms with validation errors, so it's invisible a lot of the time - and even when you get an error, you hopefully shouldn't notice the way the error is presented too much if it's done well.
Something like https://www.drupal.org/node/1781422 (tool bar search) or a new Field UI seem like they're more likely to get testing via experimental modules, and it's a good way to allow the new feature or replacement to be developed independently of what's there currently.
So I agree MAINTAINERS.txt is broken, but there's a split between people who think it's broken because it's not followed religiously, vs. people who think it has no relationship to reality and should be handled completely differently. These can be hard to reconcile.
Minor in the scheme of things, but I started looking at the component list a bit with xjm in https://www.drupal.org/node/2660144 and https://www.drupal.org/node/2702321. I personally feel like the component list doesn't reflect the structure of core at all and doing a serious rethink of that might then enable us to look at component/topic etc. maintainers differently.
top tasks...
I am still rather new to Drupal so I have hopefully a rather objective unbiased look onto things. I’ve made one or two observations. First the admin interface structure is kind of confusing in the general menu, how things are ordered and categorised, as well as in particular core modules to accomplish certain tasks. They are well hidden and or hard to reach.
The whole thing got backed when i took a look over the shoulder of a skilled Drupal user one row in front of me while waiting for the next session on Drupal Camp Vienna last year. Even the skilled user had to perform many many click to get from A to B.
So in my humble opionen it would be more than reasonable to figure out how the whole userbase is actually using Drupal respectively which tasks are the most important for them. So that you are able to restructure the menu as well as the ui of the core modules to streamline the getting from A to B.
And how to accomplish that? I would recommend starting a survey figuring out the customer top tasks for the general admin menu as well as seperate surveys for each core module. So you are able to see what sitebuilders and developer no matter if they are beginners or experts try to accomplish within the admin menu or particular module. You are able to identify then which tasks are within the long neck, important and should be the easiest to reach, then which tasks are withinin the body and important as well and in the end you see which tasks fall into the long tail and dead zone and are not that important overall.
Based on these findings you would be able to restructure the whole admin interface and make things more useable and reachable with less clicks. Gerry McGovern did an excerpt of his book „ the strangers long neck“ as a blog post on A List Apart ( http://alistapart.com/article/what-really-matters-focusing-on-top-tasks ) in case you are unfamiliar with the concept of customer top tasks. But in my humble opinion it would make sense to study which tasks people rely onto the most when working with Drupal and then check if those tasks are already reachable in the current setup with one or two clicks tops.
That would be my recommendation as a first step in the process to get a general idea of the needs and usage patterns of the Drupal user base. If you consider the idea i would be more than happy to help with the creation of the surveys.
Yes, surveys!
Thanks for your input, you make some excellent points.
Yes, we want to run surveys to get a better grasp on what the top tasks are in admin pages.
There's a spectrum from anonymous site visitors to Drupal (backend) developers. We don't have a good image of the people in the middle: users with accounts on Drupal sites and permissions to create, manage, configure things. It's their tool set that has the most severe usability issues.
One idea for a survey that @bojhan has is to run a survey among project managers at Drupal agencies. These people hear all the needs and wishes from multiple clients and help these clients set priorities and make trade-offs in which feature to build and what to leave out.
So yes please, your help in setting up and running surveys would be most welcome. Tweet @drupalux or send me an email if you will: https://www.drupal.org/u/yoroy
Thank you!
Paradigm shift needed
Thank you for the efforts and for opening these clear and relevant issues to the community.
Surely there are significant challenges in this process, but all this approach reflects a paradigm shift that was long ago needed.
This question requires a long discussion, but I would like to share this:
- we need to create new opportunities for informal and indirect user participation, motivating and improving user/designer/developer communication. I don't know which would be the most favourable channels (foruns, chats, workshops...) but this could definitely help us all to identify a target audience and to find ways to start solve complex problems.
Catarina Clemente -- Crafting the web and treating users as individuals
http://www.catarinaclemente.com
https://www.twitter.com/cvclemente
http://www.linkedin.com/in/catarinavclemente
target audience
So agreed that target audience/personas is a problem, it's an issue that comes up either explicitly or as a subtext to a lot of hard-to-resolve UX issues.
For me one way around this is to look at target audience not just as individual personas, but as a venn diagram when it comes to usage, if we do that then that can help to prioritise certain areas over others.
For example mobile-friendliness affects anyone that visits a Drupal website on a mobile device, regardless of what their specific role might be. Also how much, or how well core does it, affects the necessary work for site builders and developers when building an individual site where that's a priority.
Similarly visitor-facing features like the node and comment forms are literally used by every single core developer since they have to post on core issues if nowhere else. Not all sites use them, but if we widen that to entity forms nearly all do.
Then interfaces like the overall admin IA, field, block and views module are similarly used by both developers and site builders. While I've written many field/instance definitions from scratch, I've never done that with a view. Part of that is that raw speed writing field definitions from scratch is quicker for me in Drupal 7 than building via the UI and exporting, whereas for Views it's the other way 'round.
So assuming that people are interested in the change being made, there's a lot of incentive to do that, since you improve your own experience, and potentially save time improving things on a one-off basis for mobile. It doesn't help with getting consensus but it might help with motivation to work on things.
Conversely, hardly any developers (core or not) use the module download functionality of update module. It's specifically aimed at 'site builders who are not developers and don't want to move files around on their hosting'. This might be a larger audience than an API feature only aimed at developers, but it's a much smaller audience than either site visitors or Drupal's core site-building tools. For the core site building tools, often we really want you to use those instead of downloading a contrib module that looks like it might have the feature - more and more true now that views is in core.
For me personally I recently was looking for a 'related nodes by taxonomy terms' module to try to find a views filter, then realised Views does it already via relationships and you just need to configure a couple of settings in a particular way and expand the right collapsed fieldset to find the special option. The only module I know of that definitely has this feature or similar is ApacheSolr, which requires hosting that project browser probably wouldn't be compatible with, and the feature is less flexible than the Views version anyway.
We need to make the implicit
So I think there almost needs to be a step back from this as well.
With release management, we figured out (in the core queue) that we wanted to move to a 1 month patch, 6 month minor release process. We then (quite slowly) started applying that to the way that we prioritized issues in the queue. First of all there is patch eligibility:
some issues are eligible for patch releases, some only for minor releases, some only for major releases. This is not a simple division, we spend a lot of time figuring out the eligibility of issues in regards to semver and our own bc policy, and often gaps the bc policy can't handle and have to add to or revise it.
conversely, issues eligible for patch releases can go into minor releases and major releases, but we don't necessarily commit them during beta or rc.
This is something that only really got settled on early in the Drupal 8 betas.
Then from there, you have to figure out which release a patch can go into. Is it the minor release that you're currently in release candidate for, or the next one that's in six months?
All of these things involve weighing things like who the issue affects (fatal errors for site visitors get higher priority than fatal errors that only affect module authors while they're developing the module), how many sites might be affected, how tricky the fix for it is etc.. It's at this point that a specific issues gets into the 'roadmap' or not - via a 'beta target' tag, or being postponed to the next minor release, or committed to 8.2.x instead of 8.0.x.
Mostly release management is dealing with 'when' and 'how', not 'if' and 'what'. However, establishing frameworks and heuristics for this kind of decision making helps for consistency and predictability in terms of the specific decisions on changes, or helps to communicate where and why decisions aren't consistent and predictable.
Similarly, the six month branches allow for revisions to be reversed - anything committed to 8.2.x now could be reverted in a couple of months. While reverts aren't great, it's sometimes better to commit a patch and revert it later, than to not have committed it at all by this point. I hope we can take the same approach with experimental modules - both in terms of letting them actually experiment and being prepared to let go quicker if they don't work.
Core Initiatives, take 2?
Catch, I'm curious if you have anything in mind for putting a clearer framework around 'if' and 'what' for Drupal core? The question in this post "To what extent can we have a more top-down - process that allows for direction on hard-felt issues," reminds me of the conversation around Crell's Amsterdam presentation. In a comment thread there you said "...something we definitely need more of, is facilitation and communication, not individuals with vested authority telling others what to do.”
I agree with your sentiment and I think an update to the concept of initiatives would help us to that end. The docs page on the subject is literally marked as "needs updating" :) Pre-8.0.0, the initiatives were a helpful framing mechanism for 'if' and 'what'. And the initiatives that most clearly and consistently answered who/what/where/why/when/how, like Views in Core and Multilingual, were more successful because of it. Gábor's blog post out of that 2014 authority conversation is basically a how-to manual for doing big changes in core.
Bojhan, to your next step of "come up with approaches for improving our process for large changes," I think we can draw heavily the lessons Gábor spells out: "show the community there is a (1) shared goal, that (2) it is an achievable goal, and then (3) help people get there." This thread, in-and-of-itself, is a big help toward rallying the "shared goal" piece. Updating the concept of "official initiatives" will help too. We had a bunch of official initiatives each run in different ways trying to make large changes. We saw what worked and what didn't. If there are to be new initiatives, they should reproduce, as much as possible, the successful processes from the first set of initiatives.
Caring about those UX standards that we already got
One thing that strikes me is that even those few standards that we have are not always applied to Drupal core, and therefore are even less likely to be taken up by contrib modules. So site builders encounter an interface that's more messy then it would need to be.
Just a few examples: It is difficult to find something when there is no apparent logic on which pages have menu items in the navigation menu and which ones don't. Drupal 8.1 just got released with a Migrate UI page that is not linked from anywhere and that has no menu item. Comments have a menu item, but Files don't. Permissions and Roles are tabs on the list of users and not something you would find under Configuration.
Similar examples are UI texts on different places: Some texts on the modules page are so long that they become unreadable, and rather should be on the help page anyway. For others there is very few information. So it becomes unclear what information to expect where
Contrib modules then follow these examples, things get more messy and the usability of Drupal as a whole becomes less and less
We have some defaults for module descriptions, help texts or interface text, but few people seem to know about them, and no way of testing whether modules stick to these.
At the same time, as dawehner pointed out, anybody who wants to fix these often deals straight away with much larger issues, and what looked like a simple patch to just change a label somewhere might lead to endless issues that never seem to finish.... (But sometimes they also get committed very fast as well.)
So maybe one way of getting more contributors involved in a larger UX initiative is to show that we also care about those standards that we already have, and that we appreciate those small patches that people are putting forward. Site builders tend to scratch their own itches, and if we can get them to fix those things that they come across then we already involve more contributors.
Another approach might be to make one list of UX defaults that module developers can consult. Similar to having coding standards (and with tests where possible). If module developers, site builders, themers know what we currently consider good usability and can apply that to modules, then maybe they are also more willing to take this a step further to approve this a whole instead of piecemeal here and there.
Site builder and Documentation WG member
Specifically on permissions
Specifically on permissions and roles, there's an issue open to revisit where those are: https://www.drupal.org/node/2695771 it confuses me again and again. These got moved as part of the same admin IA rework/d7ux that created admin/config - so it's not that we had a good structure that got completely broken, it's that we went from one inconsistent structure to another one. Formulating some better guidelines for all this, then actually following them in core would be great though. Also if we were to do a major re-work of the admin IA, that might be big enough to do under a new UX process.
The https link in but
The https link in
does not seem to work
This none secure version does http://yoroy.com/pieces/summary-lean-ux
Module Developer's Guide
From @ifrik's comment above, I feel like a good step would be to put down our decided values for a 'good' module in the Module Developer's Guide. It has things like how to write secure code, how to use APIs, how to maintain a module, but I'm not sure I can see anywhere that these sorts of values are laid out. Perhaps a section "How to design a good UX"?
It would be a great place to put things across across to a wide group of key people. It might even be constructive to get down existing suggestions, and have it as a 'working document' that we can iteratively improve as we move forward?
Even right now, some links to this or other relevant discussions would be good to get people thinking.
Working document for UX standards
Yes to adding some UX standards to the Module Developer's Guide.
Just two simple example: We have a coding standard that sets the length of a line of code, but no information at what length your module description is cut of on the modules page. We have Naming Conventions for code, but not for page and tab titles.
Coding standards are not deciding what the best or only way of doing it but they set a way of doing things so that others can work with the resulting code easier. (And In this case we know who these other users are.)
UX standards could offer a similar guidance, so even if they wouldn't define the best way of creating a good UI, at least they would create a consistent UI.
I like the idea of a 'working document' that for now could just be based on the good examples that we have at this moment without using it to overhaul the whole UI, Then we have something that guides module developers who are working on their D8 modules now, and we might see clearer where we want changes across the board, instead of piecemeal a page at a time.
Site builder and Documentation WG member
Attracting Front End Developers
Just my two cents, but I think this is related to the JavaScript framework question that Dries has been mulling over lately, and to a lesser extent the need to overhaul Drupal's theming system.
How so? Because these issues are barriers to attracting talented JavaScript and frontend developers to the community, who have a much needed knack for UI, even at a basic instinctual level (a la the 10,000 hour rule).
However, there's a danger of falling into a "if we build it, they will come" mentality. We can't put all our UX eggs into that basket.
So, I'd like us to (of course!) address the obvious and glaring UX issues of the current system. There's a lot of low hanging fruit and cruft to clear out if we just clear the way for it.
But I'd also like to see the UI architecture be developed in as much of a front end developer-friendly way as possible. We should be encouraging (in words and code) contrib activity addressing UX, and allow for not just adjusting the current UI but throwing it out and replacing it completely with built-from-scratch UI. (Which is partly why I think fully decoupling is better than "progressive" decoupling.)
Spare a thought for content creators
I'm a writer and photographer [also videos]; set up websites partly to showcase work, also to inform people including re environment.
Heard of cms some years ago. Told of Drupal: looked daunting, I started w Mambo, then to Joomla, got frustrated and to Drupal.
Drupal still daunting, but there was info suggesting users like me were part of target audience, and I figured it would get more user friendly.
Once "in", can appreciate things like Views.
But user friendliness?
I see in mission now: "Flexibility, simplicity, and utility in our product"
Hahaha, simplicity!
To me, simplicity is something like turning on an iMac, and getting going.
After being put off for ages, finally shifted to Drupal 7 [is it great upgrade, other than responsive via Bootstrap? - not for me as yet; some real hassles in the transition]
So I know there's been a huge shift, from blogs to government portals etc etc. Dries off in the stratosphere nowadays.
But still, may be worth considering folks who are content creators not developers. [some may even help in other ways, like advice]
And for all the fondness for high falutin "functionality", there's still a basic that seems astonishing for something focused on websites:
Images! Out of the box, image unfriendly: what's that all about?
Two Words....
"Nested complexity". Or if you want it in four words, "Nested levels of complexity". Each more complex level of access / control should build on the design and familiarity of simpler levels above.