Pieces

Views 2 module concept model

My first concept model
diagram showing the main objects and their relationships in the views module architecture

The redesign for version 2 of the essential Drupal module Views was one of my first impactful contributions. Much of the functionality is (still) over my head but somewhere in 2008, after many long conversations in IRC I arrived at a diagram that clarified a lot. I didn’t know of the term concept model then, hence the “sitemap” title.

In simple terms, you use Views to create lists of things. It lets you define what kind of thing to list, where to present it, how to format the list and how to format each item in the list.

What this concept model achieved was mapping the system objects to these simple what, where, how questions. It helped many people understand much better what this new version would be able to do.

I love to do this kind of visual clarification.

Incrementeel FTW

Ken je dat, dat je dan klikt op die button in het screenshot?

We bouwen geen websites om websites te bouwen maar om digitale dienstverlening te bieden. Meer dan ooit moeten strategie, ontwerp en techniek als elkaars input gaan fungeren om dat potentieel waar te maken.

Conversie, klanttevredenheid, resultaat zijn niet geholpen zodra het definitieve photoshop document op dropbox staat.

IT teams die hun agile en continuous delivery op orde hebben en van daaruit design expertise toevoegen aan hun arsenaal zullen beter toegerust zijn op wat komen gaat dan de designbureau’s die IT aan hun expertise toevoegen.

Designing delivery

Clarify and make actionable. Repeat

I'm reading the book.
Always been fascinated by complexity and how to navigate it.
Noticing that as a designer, that's what I like to do. Clarify and make actionable.
Using design to make a strategy concrete, using design to iterate on shippable services.
Continuously.

A scenario for using content workspaces

Preparing the launch of a new campain.
Hand drawn diagram of how workspaces enable preparation of new content items

An example of how to use content workspaces to prepare multiple content items that you want to publish.

Say you want to launch a new campaign (product launch, a sales promotion, a fundraising drive). This means creating new content, updating existing items to link to that new content and maybe archiving some elements of a previous campaign as well. With content workspaces you can create, review, test all these changes on a copy of the live site. When everything is in place and ready to go live, these changes can be published to the live site and you've launched your campaign.

  1. Setup: create a workspace
  2. Create (add, change, archive, delete) content as needed
  3. Review your work. While working inside your workspace, the content on the live site will likely have changed. Blog posts were added, products were updated, typos got fixed, etc. So, you can import (“pull”) these changes into your workspace. Maybe these changes interfere with your own work. Now is the time to fix those conflicts.
  4. Happy with your work you set the workspace to “needs review”. This sends a notification to your team lead or editor who reviews your work as well. If it needs works till, she can set it back to “needs work” which means you’re back at step 2 to make the necessary changes.
  5. All is well and ready to be published. First a final “pull” of any changes from the live site to make sure there are no conflicts, then the actual publishing of all the new items and changes you prepared in the workspace get “pushed” to the live site.

Content workflow initiative: what is a workspace?

Similar to git branching but for content
Hand drawn diagram

A workspace is a copy of the live site, that exists in parallel to the live site.

Use a workspace when you want to prepare multiple new content items, that you want to go live at the same time, in a controlled manner.

Pyramid of MVP

Provide user facing goodness right from the start
Slicing

Avondzon

Add the smell of rain
Tags: 

UX meeting format is evolving

50/50 on new ideas and reviewing work in progress
Detail of an abstract etching called Escape Velocity I

After a couple of weeks of setting up with mostly free-format meetings in IRC we’re going to try a more structured format for our weekly UX meetings:

  • First half hour: people can introduce a problem + proposed (possible) solution
  • Second half hour: we review any work that has progressed over the past week. Often a core committer will be around to provide guidance or even actually commit changes that are good to go.

We did a first ad-hoc version of this last week, including a hangout with screen sharing. It worked really well, was productive and a lot of fun. Seeing the same thing in action is helpful when discussing user interface changes!

Next one is coming up and people from Acromedia will present on a topic and outline their proposed solution. For the second part I’m hoping we can review the “Place block” experimental module patch.

The meeting will take an hour. Here’s a calendar for the date and time.

Want to join? Join the UX channel on drupal.slack.com. Get an automatic invite here. We’ll link a hangout from there and make sure we’re broadcasting live so at least everybody who wants can follow along and use Slack for background chat.

See you there!

10 places to explore visual & structural hierarchy on Drupal admin screens

Your ideas for how to put first things first, please.

One of the critical Drupal UX issues is the lack of visual and structural hierarchy on admin pages. Can you suggest ideas, sketches, mockups for any of the following?

Post your sketches, plans or ideas to the linked issue or add this folder to your Google Drive and upload there.

Drupal UX process improvements shopping list

Repeatable processes for comparable results
Hand drawn mindmap of ux work aspects

Set a more specific product vision

  • Continuous discovery of user needs
  • Competitive benchmarking (explain please, Bojhan :-)
  • Design principles are good, specific goals even better?
  • After setting the vision: maintain the vision and commit patches accordingly
  • Be clear about who gets to set and who gets to maintain this vision

Increase velocity:

  • Involve more people who want to design
  • Better define what needs to be done
  • Clarity on how we decide
  • Really decide
  • Have a repeatable process for comparable results

Design multiple options before picking a solution:

  • Know what to work on to focus efforts to get broader set of specific ideas
  • Sketches before prototypes. Everybody can draw an idea
  • Lo-fi prototypes before core patches
  • Designer + developer collaboration from the start
  • Have a repeatable process for comparable results

Compare and evaluate design options faster:

  • Know when an informed opinion is enough, know when some kind of evaluation is needed
  • 3 people every tuesday (online usability testing, simplytest?)
  • A format for guerrilla usability testing during camps
  • Have a repeatable process for comparable results

Find the approach for changes that touch all the things

  • Clarity around what can be incremental, what needs to be one big push
  • What will a 6 week git merge look like?
  • Know from the start what the next 6 months will focus on to direct, harmonize efforts

Summary of Lean UX

A book by Jeff Gothelf, with Josh Seiden

3 Foundations

  1. Design thinking (User centered design, using design approaches to innovate and solve business problems)
  2. Agile software development (individuals & interactions, working software, collaboration, responding to change)
  3. Lean startup method (build, measure, learn)

Principles

  • Cross functional teams
  • Small, dedicated, colocated
  • Progress = outcomes not output
  • Problem focussed teams
  • Remove waste
  • Small batch sizes
  • Continuous discovery
  • Getting out of the building
  • Shared understanding
  • Antipattern: Rockstars, Gurus & Ninjas
  • Externalising the work
  • Making over analysis
  • Learning over growth
  • Permission to fail
  • Getting out of the deliverables business

The Lean UX loop:

  1. Declare assumptions
  2. Create an MVP
  3. Run an experiment
  4. Feedback & research
  5. Goto 1

Process

Vision, framing and outcomes

Start with assumptions instead of requirements. Create and test hypotheses:

  • Assumptions: what we believe to be true
  • Hypotheses: morge granular descriptions of our assumptions that target specific areas of the product or workflow
  • Outcomes: the signal we seek from the market to help (in)validate the hypothesis
  • Personas: models of the people for whom we believe we are solving a problem
  • Features: the changes or improvements we believe will drive the outcomes we seek

Collaborative design

  • Everybody gets to design
  • Low fidelity artefacts increase collaboration
  • Build shared understanding

Techniques:

  • Design studio
  • Style guides and pattern libraries
  • Collaboration for distributed teams

MVP’s & Experiments

  • Determine product focus: deliver value or increase learning
  • MVP: Do people need it? Will it provide value? Will it be usable?
  • Prototype: Who will interact? Learning what? Time available?
  • Experiments without prototypes: email, google adwords., landing page, button to nowhere

Feedback and research

  • Collaborative research techniques
  • Continuous research techniques (3 users every thursday)
  • What to test, what results to expect
  • Incorporate the customers voice
  • A/B testing
  • Reconcile contradictory feedback

Lean UX & SCRUM

Making organisational shifts

  • Shift from output to outcomes
  • From limited roles to collaborative capabilities
  • Embrace new skills
  • Create cross functional teams
  • Crate small teams
  • Create open, collaborative workspaces
  • Not relying on heroes
  • Eliminate big design up front
  • Speed over aesthetics
  • Value problem solving
  • Embrace UX debt
  • Shift agency culture
  • Work with 3rd party vendors
  • Navigate documentation standards
  • Being realistic about your environment
  • Managing up and out

An example of current inside-out Drupal UX

“As a software, I need to know the data model so that I can provide a corresponding UI widget”
The handwritten notes for this post

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

  1. Lets add some checkboxes for lunch options
  2. 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

screenshot of add field UI

  1. Define the type of data you want to store
  2. 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.

Notes from Embrace Complexity, Scale Agility by Dave Snowden

If you don’t know the Why, don’t try and scale a How.
Cynefin framework diagram

Notes from a presentation by Dave Snowden: Embrace Complexity, Scale Agility

Sense making: How do we make sense of the world so that we can act in it? And given that you can never know everything you need to know: how do you know when you know enough and what kind of actions can you take based on what you do know?

“All paths up are different. All paths down are the same” - @gapingvoid

Meaning: there is no recipe for success. There is a recipe for failure: repeat past mistakes. Reduce the rate of failure by learning earlier in the process through interacting with users.

Cynefin framework

A sensemaking framework for finding out which kind of approach to use for finding possible solutions in different contexts. The framework has five domains: Ordered, Complicated, Chaotic, Complex and Disorder.

Snowden has a fun routine explaining the difference between Ordered, Complex and Chaotic using the analogy of a children’s party. (This links to a recording of a different but similar talk, check it out).

Ordered

A highly constrained environment without freedom of movement. The relationship between cause and effect is obvious to all. The approach is to Sense -> Categorise -> Respond and we can apply best practice. Highly ritualised way of working, e.g. checklists. The problem is understood, the steps to solve it are known and fixed as well.

Complicated

Where the relationship between cause and effect is not immediately obvious. The situation has to be analyzed with expert knowledge to find out what to do. The approach is to Sense -> Analyze -> Respond and good practice can be applied.

Chaotic

No constraints at all, everything operates independently from everything else. No relationship between cause and effect. The approach is to Act -> Sense -> Respond, and you can discover novel practice. This is a transitionary state because it requires huge amounts of energy to not have constraints.

Complex

A.k.a. daily reality. There are constraints, but these enable and modify behaviour in the system, and the behaviour then modifies the constraints. The approach is to Probe -> Sense -> Respond so that you can discover emergent practice.

Disorder

The fifth domain of disorder is the state wherein you don’t know in which of the above four domains you are.

Complexity is daily reality

A complex system is not causal. Complex systems have propensities (inclination or tendencies to behave in a certain way) and dispositions (an inherent temperament, character), but there is no linear cause and effect.

Complexity can be managed, but only as a flow, not as a static system.

Managing flow in complex systems means you manage the emergence of beneficial coherence within attractors within boundaries. What you’re looking to design is a working boundary that, with the right attractors, produces desired behaviours and outcomes.

Whew! My oversimplified version of what that means: amplify what works well and dampen the negative effects. You can not expect predefined results. You have to manage the evolutionary potential of the present moment in time and adjust as you go. Again: check out the children’s party analogy.

Solving problems in a complex world means focussing on running multiple smaller experiments that are safe to fail instead of working towards one fail-safe design. Smaller experiments, faster, in parallel. (This is why Scrum is not a true complexity technique because it does one thing in a linear way)

Through the experiments (prototypes of newly designed constraints?) you move from the center of complexity towards the boundary with the complicated domain. Once the new constraint is replicable and produces repeatable behaviour, you have moved it from the complex to the complicated domain and you can start to scale it.

If it does not produce repeatable behaviour, you move back into complexity and initiate more (different!) experiments. The trick is getting the cadence right of moving things from complex (unpredictable) to complicated (mostly predictable) and back to complex where necessary.

A bit of cognitive science

  • Fact: you only scan 3 to 5% of what’s in front of you. You match that input against previous patterns (from recent memories) and make decisions based on that.
  • Fact: after 3 interviews you start to form a subconscious hypothesis and then only pay attention to the things that match it. So you can’t really trust the analyst (or design researcher) to really understand what users need. And users don’t know what they need either.

Scalable ethnography using human metadata

  • Reduce granularity
  • Distribute cognition
  • Disintermediate decision makers

If you don’t know the Why, don’t try and scale a How.

  • Micro narratives or observations are the basic unit of sense making
  • Meaning does not reside in text. It is provided by human actors, in context
  • Abstraction is the key to interpretation and reuse
  • Description opens up more possibilities than evaluation
  • “More like these, less like those”
  • Navigate landscapes

Manage vector, not velocity.

  • Complexity does not scale by aggregation
  • Reduce granularity, distribute cognition, radical recombination
  • Scale by finding new patterns across the whole domain
  • Engage the real C-level & ecosystem
  • Learn early, fail less.

Redesigning the content creation page for Drupal 8

Drupal 8 has a redesigned content creation page. This is how it came to be.

We want to be faster and bolder in shipping design improvements for Drupal 8. But how? Lets have a look at a relatively big (but not super huge) design change built for Drupal 8 during the development cycle and see what we might learn from it.

Redesigning the content creation page

Drupal 8 ships with a significant overhaul of the content creation page (“node form” for intimi). It’s design process and subsequent implementation are extensively documented on drupal.org. This is a high level summary of how this redesign come to be.

Steps in the process:

  1. Research
  2. Sketch
  3. Design
  4. Test
  5. Implement

Who were working on this? In the earliest design stages primarily 3 people: Bojhan Somers, Jared Ponchot and moi, Roy Scholten. Many more helped with finetuning design elements, usability testing, writing and reviewing code and all the other little and not so little things that go into getting a big design change committed to Drupal core. Thanks all.

Research & sketching

We didn’t spend much time building the case for a better content creation page. No problem because most were already aware of the big room for improvement.

The research was two-part: “what does Drupal do?” And “what are other systems doing?” For the Drupal aspects, we looked at how and where contributed modules add functionality to this screen. We reviewed other systems looking for patterns in how functionality was grouped and arranged on the page.

That input was then translated into very generic concept sketches, comparing and contrasting several arrangements of the three basic feature groups: content, settings and actions. From there, we proposed to pursue one specific direction in more detail. Before we did that, we opened up the work so far for feedback: http://groups.drupal.org/node/214898

Design

Starting from that very rough initial layout we started exploring the details of that arrangement. Which items belong in which area and how would they behave? How would it work on small screens? Which items to call out, which ones to push back?

Then Jared Ponchot stepped in and pulled all that sketching together in high-definition mockups. And on these we iterated again a couple of times, detailing the arrangement of interface elements, the use of color and other ways to (de-)emphasise certain parts of the whole. A comparison with the then current state of the Seven admin theme identified how we would have to extend its visual language to accommodate this new design.

And that’s where we opened up for another round of feedback: http://groups.drupal.org/node/217434

Test

A working prototype of the design proposal was coded and made available on a test site. A usability test plan was drafted and several people used that script to test the prototype with people both new to and experienced with Drupal. One of the few times we actively pushed for community driven usability testing actually. Results from the testing were reported in the implementation issue and individual issues were opened for the necessary changes.

Usability test plan: http://groups.drupal.org/node/223959

Implementation

The prototype for testing was created in context of the implementation issue. We spent a lot of time translating the design proposal into actionable tasks.

The distinction between rough prototyping code and actual core worthy implementation was a bit unclear at first but we very quickly got to a usable demo. The overarching “meta” issue has over 300 comments. Which is usually a sign of a large undertaking that’s not sufficiently broken down in seperate actionable tasks. But, we got there in the end!

Implementation meta issue: https://drupal.org/node/1510532

Lessons (not? :-) learned

  • Good: working with a small team. It allowed us to focus on what needed to be done and move relatively fast.
  • Good: Publicly documenting the research and sketching phases was a lot of work but worth it. Pulling a finalised glossy photoshop design out of the hat would not have created the same engagement and constructive feedback
  • Good: counter to the previous point but also a good thing was that the initial sketches and design mockups were shared only within the very small team of 3 to 5 people. This kept momentum up but more importantly allowed us to focus on the actual design work. A broader discussion would very likely have shifted towards discussing implementation challenges, which is not what you’re after when still exploring multiple options.
  • Not so good: we prototyped only one working version quite late in the process. Only after a lot of time invested did we get to see and feel a somewhat working version. This narrowed our bandwidth for subsequent changes, which were relatively small tweaks, keeping the basic paradigm intact. We never really pitted two or more radically different approaches against each other. This was mostly a time and energy issue: we only had the bandwidth to work through one design direction.
  • Not so good: Doing the design phases outside of the issue queue (where implementation happens). This was a necessary but difficult trade off. The issue queue doesn’t lend itself to explorative work with lots of ambiguity so the design work wasn’t tracked there. Many core developers did not closely follow the process as it happened on groups.drupal.org, so when we brought the design over to the issue queue with the proposal to go build this, much of the earlier discussion points got brought up again.
  • Not so good: Not having a primary code architect as part of the team. We could have prevented at least some of the rehash in the issue queue if we had had a knowledgeable core developer on the design team. Having somebody who could answer to the technical implications of the design and help break down the work into manageable tasks the would probably have gotten us off to a better start with implementation.

A quick tally of the number of comments across the main discussion threads and issues for this project: more than 1200. And that doesn’t even include huge additions like the WYSIWYG editor and the improved previews. Not to say that this doesn’t happen in other initiatives, but you can see how demanding it is for anyone who wants to keep track, especially if you want to make sure that the big picture doesn’t get lost in the myriad of details.

How to get better, faster?

The nature of design changes like these is that they touch many aspects: backend & frontend, php & javascript, visual design & performance, accessibility & multilingual, etc. If we want to go faster we might want to consider replacing the research intensive work with building multiple (rougher) prototypes earlier and testing those for viability. That might lead us to a general direction and a plan for implementation faster. As for the actual core worthy implementation, we might win some time if we can provide a design spec together with an initial plan identifying the technical challenges and strategies to overcome those.

The amount of work will always be huge. I think the gains are in finding a better balance in:

  1. Feeling free to write quick throw-away code in the initial explorations so people can get a feel of what might work and we can test it.
  2. Reducing wasted efforts (in code and discussion) during implementation.

Understanding the distinction between these two, and being clear about when the first ends and the second begins will already be a big step forward.

Further discussion: Determine process for big UX changes

Particle trajectory

2016 printmaking has started

Drupal UX, the conceptual criticals

Where Drupal does not meet people’s expectations of how things are done:
bubble diagram showing how small first time users perceive Drupal to be.

Where Drupal does not meet people’s expectations of how things are done:

  1. Using unfamiliar words for basic concepts. Naming things is hard. Understanding weirdly named things is even harder.
  2. Lack of wayfinding, onboarding, getting started instructions make people feel lost. They are not guided towards quick successes that instill confidence.
  3. No visual hierarchy in how features, options are presented. Everything is presented as equally important which makes it hard to make choices, it doesn’t help people “guestimate” and “satisfice”, which is the default mode of operating, especially when exploring something new.
  4. People are never really sure they are doing the right thing. Depending on previews to check if they’re on track makes for inefficient workflows.
  5. Order of how to do things is backwards. People are forced to create abstract placeholders first before being able to do the actual thing. Having to put a menu in a block in a region on a page whereas people want to click the spot on the page where they want to add some navigation links.
  6. The standard installation is too sparse, making Drupal appear limited in functionality.
  7. The ‘river of news’ model for the homepage is outdated and causes confusion after creating the first post.
  8. All of the above lead to a reluctance to explore and probe functionality. The impression people get is that Drupal is limited in what it can do.

One of the D8UX design principles was to connect the dots. It obviously still should be a, if not the guiding principle because the above list makes it clear that the lack of guidance, presets, and hierarchy/prioritisation of functionality is what makes people stumble.

No solutions offered in this post, just compiling the list :-)

Hardcore for life

Stijlvaste gabber in de Apenheul
Tags: 

Bosjesfestival 2015

Hilversums best kept secret?

Content café 13: Agile!

En andere buzzwords.
Collage van 3 snelle schetsen van het publiek, spreker en een scrum sprint diagram

Dertiende editie content café. In Voorburg, over agile. En andere buzzwords.

Mary Beijleveld verzorgde een inleiding op agile als waardensysteem en een rondje langs de vele verschillende manieren waarop je een proces wendbaar en iteratief kunt maken.

Dat lekker scrummen echt vies moeilijk is bleek uit het praatje van Anton van Fabrique. Goed verhaal, smakelijk gebracht. Viel wel een ietsiepietsie door de mand toen op de slides de schrijver/redactrice ontbrak in het scrum team :-)

De invalshoek van Mariëlle Roozemond was corporate marketing-communicatie. Aanstekelijk enthousiasme en verfrissend om te horen vertellen over iets waar je maar weinig van af weet. A bit sceptical about “framedoctor” and the “content strategy radiator” though!

Ja maar wat dan en hoe dan qua agile en content?

De vraag is of we het wel over agile content strategy hebben gehad die avond.

  • Hoe kunnen content strategie en content productie onderdeel gemaakt worden van een agile team?
  • Kun je wat je nodig hebt aan content vatten in user stories?
  • Moet je dat willen?
  • Hoe zou je kunnen itereren op content?

Want: als ux designer en informatiearchitect zet ik flows en structuren klaar met allerlei sjablonen en mallen waar dan later een keer de echte content in gegoten mag worden. En die past dan meestal niet echt lekker. Dus aanpassingen nodig, dingen overnieuw doen, en dit hele stuk is wel gebouwd maar hebben we niet eens nodig! All very wasteful.

Vorm en functie krijgen buitensporig veel aandacht, de inhoud blijft te lang onderbelicht.

Hoe maak je content strategie onderdeel van de conceptontwikkeling? En kun je dan daarna tijdens design en development ook de content in parallel mee ontwikkelen? Wat misschien meer gaat over hoe content en design beter zouden kunnen samenwerken. Omdat agile meestal uitgaat van cross-functionele teams zou ik juist daarover wel meer willen horen.

Oftewel: content café, van harte aanbevolen.

Ink + ink

Drawing, then printing
Tags: 

Pages