“As a software, I need to know the data model so that I can provide a corresponding UI widget”
Drupal UX can be problematic. Many of the big conceptual issues have their roots in a user interface model that maps the UI directly to the underlying technical model. There is no translation made to map functionality to how people expect things to work. Currently, Drupal UI follows how the system works. Turning Drupal outside-in means making Drupal UI work like people expect it to work.
Example: adding fields
The capability to define different types of containers for your content is a core Drupal strength. For example, you could have an Event content type for your workshop or conference. Suppose lunch is included and you want to let people choose some options for lunch, like vegetarian, vegan, no preference, thanks but no lunch for me.
What people expect to do
- Lets add some checkboxes for lunch options
- So that I can capture lunch preferences when people register for this event
People usually start from the specific form widgets they want to use (text field, date picker, select list, checkboxes) and (after realising out that those checkboxes don’t work automagically) then configure more specifically what those checkboxes should do: storing some pieces of data.
What Drupal asks you to do
- Define the type of data you want to store
- Define which user interface element to use for the input of this data
Drupal enforces a flow where you first have to think in more abstract data storage format terms. For this lunch options example, you first have to specify that you want to store a list of text items and only then do you get to choose “checkboxes” as the way to present these options.
This is a great example of “the UI is the application”, and turning Drupal outside-in means exactly that: finding ways to expose all the great functionality in a way that maps to people’s expectations. Otherwise, for many people the functionality might just as well not exist.