The new Drupal release cycle allows us to bring some big usability changes such as workflows and a new settings tray to get to the configuration.
But at the same time, lots of the old problems exist and we still lack guidance or UI standards.
This session will be about UI Standards, restructuring the admin interface, and having different variations of the same admin menu for different personas.
At Dev Days at Milan, we looked at a range of these issues and fixed them individually, and we discussed a different way at organising the Admin interface. This session will give an update on where we stand: an idea on how to improve the admin menu in a sustainable way, taking core and contrib modules into account.
Even within core choices are made = or re-made - based on a particular use case. This is then exacerbated when contrib module developers, with little guidance, try their best to interpret the unwritten rules (or just give up).
We should develop straightforward UI standards, just as we have coding standards. They can be used to guide core and contrib developers, making decisions easier, and making it clear when a different decision has to be made.
How can we best decide on these standards, without getting lost in a bikeshed conversation? How do we write them so any developer can easily follow them? How do we then promote these standards?
Every user installing a site gets the same experience, no matter if this is their first time or their thousandth. When users get overwhelmed the only answer is to reduce visible complexity, and so hide the power and flexibility of Drupal administration. Can we have different variations of the admin UI that fits different persona instead of trying to find the one perfect solution? Can we give users different role permissions if its one of their first installs? Can we present different language use for different target users (new, advanced, developer...)?
This session follows previous session at DevDays and a Core Conversation at DrupalCon Dublin.
All examples and ideas in this session have issues to work on during the sprints.
(Track: It's a cross-cutting issue UX and sitebuilding, so it can be moved to the sitebuilding track as well.)