The architectural changes underway for Drupal 8 via WSCCI and related activities present UX designers with the non-trivial task of working out a new approach to Drupal administrative and content management tasks. UX design is a complex matter under any circumstances but when the technological ground is shifting dramatically under the feet of the designers then it is all the more challenging. Here are some brain exercises to help us limber up for the task!
As I see it, there are two ways to design user interfaces: to solve for individual problems based on a set of identified requirements and assumptions; or to design a systematic solution, incorporating many individual problem scenarios, based on agreed-upon principles and an overarching interaction strategy.
I prefer the latter.
To that end, I’m sharing a set of assumptions about UX design for the Drupal platform that we may or may not be currently building upon. Alongside each of these I’m also presenting an alternative assumption which, at the very least, could provide a way to look at aspects of the overall problem from a different perspective, and perhaps may be the basis for some agreeable design principles.
We are generally aware of the concept of design patterns. I see these alternatives as leading to ‘meta-patterns’ which could potentially help coordinate all our efforts in the various problem areas. My hope is that by consciously working with rationalized principles we can get the most out of the exciting architectural changes in store for D8 and minimize the ‘mid-air collisions’ where one UX solution becomes another UX problem.
This initial tabulation is far from a complete explanation of the various ideas but I wanted to get them out there for consideration and as seeds for discussion. These items are not solutions but reframing of problems and may be small steps towards possible solutions. I realize that I may need to add follow-up clarifications in many cases.
Given the design activities that have already taken place for D8 UX, this level of discussion may seem like a step backwards. But, as I mentioned, Drupal 8 requires a systems level design approach and so far I’m not seeing that layer being formally defined yet. Systems approaches require that we dig a deeper foundation to support more ambitious ideas, so a bit of patience is required before we can see visible results.
The other intent behind this post is to help integrate the efforts of the UX designers and the core developers. The items listed here can be reviewed by either group and ideally we could use them to identify a set of principles that are agreeable to both perspectives. I should add that none of the alternative perspectives that I’m presenting here would be possible without the changes that WSCCI brings to the table. There is a chance that I’m misreading some of the WSSCI assumptions – if so, please point that out.
Designs built on solid conceptual foundations can be truly remarkable and I think we all want Drupal 8 to be remarkable. We have an exceptional opportunity as a community to make a historic mark on the web platform landscape.
So take a look and think about which assumptions (listed here or not) you would like to turn into design principles and the reasons for your position.
Let’s see what we can do to build a solid conceptual foundation…
| Possible Assumption | Possible Alternative |
|---|---|
| 1a. All URLs are created equal. As long as they produce predictable results we don’t need think about how they are used or structured. | 1b. URLs can be classified into groups that relate to tasks. The main groupings are 'front end' (all the places that the end user can visit) and 'back end' (using the term loosely to describe any page related to site building or CMS tasks). |
| 2a. Web sites are sets of content pages with additional administrative interfaces used for site building and content management. | 2b. Web sites can be seen as collections of defined locations in IA Space that are identified by URLs. There are 2 primary divisions of IA Space (the 'front end' and the 'back end'). |
| 3a. URL semantics are not important for UX strategy. E.g. ‘node/123’ and ‘node/123/edit’ is an acceptable semantic for both ‘front end’ and ‘back end’ contexts. | 3b. URL semantics can reflect the intent of the task and thus help formulate a UX strategy. A key objective in such semantics could be to help distinguish between a definition context (where a content resource is created or edited) and a usage context (where it is presented for end user consumption or as part of another back end task such as a component library). |
| 4a. Nodes are digital representations of documents and therefore a ‘natural’ basis for web pages. | 4b. Nodes are one instance of a web resource that can supply information to the user via HTML, JSON, XML, or other formats. There are other types of resources that can satisfy the needs of a given page including other entities defined on a given site as well as other external data sources. |
| 5a. The content on a web page is determined by the content of a node. | 5b. The content of a web page is determined by the task intended for that location (such as business intent for front end pages or admin tasks for back end pages). The task is made possible to the user via data from one or more nodes or other entities. |
| 6a. Content is ‘pushed’ into the IA via menu assignments on the node creation/edit form. | 6b. Content, and other data or control UI components, is ‘pulled’ into IA Space locations through some sort of Page Manager or Layout Manager mechanism. These management interfaces are based on administrative usage contexts for predefined content and data resources. |
| 7a. A web page is a node display, often decorated with other peripheral components. | 7b. A web page is a specific location in one of the 2 key IA Spaces (either the ‘front end’ url grouping or the ‘back end’ url grouping). Nodes are not ‘decorated’ but ‘harvested’ for use in supporting the intent of the given page. |
| 8a. The UI for back end ‘management’ tasks (e.g. node creation/editing) is derived from the properties of the entities (e.g. nodes) and is therefore the same for all ‘management’ tasks. | 8b. The UI for back end ‘management’ tasks can be structured around specific task groups that support specific goals. The UI for any given location can potentially change according to Role, workflow and workflow state. |
| 9a. All ‘front end’ web pages are based on content display – either directly from the node or indirectly via Views etc. | 9b. The ‘content’ of a front end IA Space location is dependent upon the active user Role and the state of the content itself. The content states relate to workflow and therefore could be used to capture such things as the intent of the ‘page’ as well as the status of the content development. (This is a way of taking the In Place Editing concept a step further to incorporate Role-oriented workflows.) |
| 10a. Web sites are like digital books and are primarily intended for use as information resources. | 10b. Web sites are increasingly treated as applications which, by definition, exist to facilitate data creation and manipulation. |
| 11a. CMS UIs should be designed to follow ‘traditional’ web interaction models. | 11b. Where appropriate, CMS UIs can draw heavily from the application interaction model. |
| 12a. UX designs can be resolved as separate design challenges. | 12b. An overarching UX design strategy, based on agreed-upon design principles and assumptions, can help ensure consistency and minimizes ‘mid-air collisions’. |
Note: for a more 'internal' look at the concepts mentioned here, check out this post.