ux

An experiment in removing friction

Roy — Wed, 07 Feb 2018 22:28:07 +0000

Sub title

A smoother path to posting pictures from phone to site

/sites/default/files/styles/large/public/form-display.png?itok=heIg7oII

An experiment triggered by Dries’s blog post To PESOS or to POSSE? and my comment there about the friction in the UI’s for the POSSE approach. The Drupal content creation UI is not as optimized as the ones in native, mobile apps for Twitter, Instagram and the like.

I was curious how far I could take things just by stripping down the default Drupal content creation UI, optimizing it for posting an image + caption as an entry to this here blog.

What I did:

Create a custom, stripped down content creation form
Use evil CSS to hide superfluous items

Custom form mode

The first step was to remove most of the fields that are not required to create a post. The Form Mode Manager module lets you do just that. I set up a “Minimal piece” form mode which hides the fields for inputs like a separate summary, tags, file attachments, url alias, author, date, sticky and the “promoted” checkbox. These are optional (not required) fields that can be left empty or provide sensible defaults (me as the author, use “now” for the publishing date).

This alternative form comes with its own URL I can go to to create that new post.

Evil CSS

The stripped down form still shows bits and pieces I don’t really need to be reminded of every time I go to post something. Nothing a few display: none; CSS staments couldn’t fix. But, I’m using the default Seven admin theme here, which does not provide a body class to uniquely identify a specific page. I couldn’t add my CSS hacks to that theme’s (or sub theme’s) stylesheet because those would then apply to all admin pages.

I use the Firefox browser on my Android phone. Stylish to the rescue. We’re definately in proof-of-concept territory now! Stylish lets you define custom styling for all sites, a site or one or more specific URLs. I made one specifically for the URL where the minimal entry form lives to clean up that screen even more: hiding the header, breadcrumbs, form field descriptions, etc.

And, does it work?

Yes. It’s far from elegant but it’s already a much more focussed and faster experience. I think I already knew but was happily surprised to see that the regular image field does provide access to both the camera (for taking a new picture) and the gallery (for choosing an existing image).

What could be next

One thing that makes the Drupal approach feel old school is the required title field. Twitter, Instagram, Tumblr all let you just type something into what basically amounts to a “body text” field. In Drupal it has to at least be just like email: a subject and a message: a title + a body. I can make the body optional but I want my text to go in there. Hiding the title field is not straightforward, I think because it is tightly coupled with the unique ID for that content item. There’s modules that let you hide the title input field but those still automatically generate a (gibberish) title.

Still, my focus was on smoothing the path for posting an image to my blog from my phone. That “Browse…” button is old school too, but it does provide access to camera and camera roll. Saving a bookmark for this comes with the option to create a shortcut icon for it on the phone home screen for quick access. Not bad for an hour or two of experimenting without coding :)

A couple of years ago swentel created Drupoid, an Android app that let you save an image from your phone as a content item on a Drupal site. It would be an interesting exercise to recreate something like it with React, Drupal’s (future) JavaScript toolkit of choice and figure out how smooth and snappy we can make it there.

Tags

Drupal

drupalplanet

process

Do more usability testing

Roy — Tue, 23 Jan 2018 22:13:58 +0000

Sub title

While still uncomfortable is when.

Do more usability testing. Do it earlier in the process. When you feel uncomfortable about it, because the thing is unfinished, that's exactly the time to do it. Very likely people stumble on something fundamental in one of the first steps.

You had a scenario that you wanted to test. This initial prototype may not work for how people expect to handle that kind of task. When that happens, shift to more research based interviewing, probing for stories about when people tried to do something similar before. This may lead to a point where you can pull up another screen relevant to that part of the story and explore from there.

This is likely a symptom of not having uncovered actual user needs in the first place. It happens. So forget about the prototype then and shift the focus of the conversation towards learning more about those wants and needs.

Tags

usability testing

First things first

Roy — Mon, 08 Jan 2018 22:05:14 +0000

Sub title

Get a grip on the whole before diving into details

/sites/default/files/styles/large/public/20180108-first-things-first.png?itok=c6JIU2IX

The architect designing a house does not start with choosing and arranging the furniture in the living room. Even if the client really wants that one specific large corner couch.

No matter how custom the eventual design, for each house there’s some basics that need to be taken care of. A way to enter it, some holes in it to let sunlight in, dedicated spaces for cooking, sleeping, washing up, etc.

Any tool or app that is not super small can easily be as complex as building a house.

Establish foundations first

Don’t get lost arranging details on a single screen if you’re not yet clear of the fundamentals. How can you enter? How many different types of rooms do you need? How are they connected?

Individual screens are easy to create in isolation but if you start there, you’ll have a hard time arranging them into a coherent structure. At the same time you’ll likely need a home screen, listings, detail pages, forms and the like. Establish the main paths, flows, scenarios as guides for stringing those basic page types together.

Get a grip on the full set of things that your new design needs to accomplish. It’s easy to get lost in polishing the details of a particular screen component when working in high resolution tools like Sketch. First establish that you need a list of items on this given screen because of some search or navigation action on a previous screen. Only later figure out the specifics of what to show for each item in the list.

Sitemaps and flows before wireframes. Pen and paper before digital. Not having an undo is not a bug but a feature. Redo instead of undo to get a grip on the whole.

Some resources

Luke Wroblewski has an older talk about this: Parti & the design sandwich
Page description diagrams are an old school, more text based version for creating the big picture
Haven’t tried it but looks like Flowmap wants to provide that sweet spot between global (sitemap) and local (wireframes). (You should still start on paper though.)
Think of your app like a collection of hubs and spokes
You’ll probably need these types of pages

Tags

sketch

process

Drupal UX notes week 45

Roy — Tue, 07 Nov 2017 17:05:39 +0000

Sub title

10 weeks left until Drupal 8.5 hits alpha, which is the deadline for new features

Help system

How do you currently provide your clients with documentation, guidelines and how-to’s for creating content, managing their site? An improved system for writing topic based help instead of the current per module approach is seeing a flurry of activity.

UX meeting

During last weeks hangout we discussed ways to clarify the reset password process. Of course there’s always at least one related issue.

We were able to close “Add status and workflow state to page title block”. Finding out that an issue has been made redundant because of changes introduced elsewhere is progress too!

React it is, for now

After one of those special, extra passionate discussion threads the core JavaScript team will proceed using React as the framework to experiment with.

It’s useful to keep in mind that the goal is not to put a JavaScript framework in core. That is just a means to an end. The goal is to improve our administrative user interfaces.

How might we improve or redesign the Views UI? Fields UI? Design a scalable, performant UI for permissions? A more flexible toolbar? How might we let people create a new block or view from inside Settings Tray?

Would be good to start exploring possible designs in parallel to this technical discovery.

Core product

Core itself ships with a set of features of which only a subset is enabled by default. With some brand new features now marked stable we can choose to offer them right out of the box:

Enable bigpipe. A turbo boost for loading and showing pages faster.
Enable inline form errors. Indicates exactly which form input is missing or wrong, instead of generic message on top of the page.

Where are all the issues?

Just so you know, all issues that change the interface or otherwise impact the user experience are tagged “usability”. Proposals for new features and plans for big changes can be found in the Ideas queue. Here’s another post with links to where you can find the action on all kinds of topics.

Tags

Media entity UI review

Roy — Mon, 02 Jan 2017 23:45:51 +0000

Sub title

Drawing the thinking

Tags

Drupal

review

Talk talk in Dublin

Roy — Wed, 14 Sep 2016 22:15:08 +0000

Sub title

Looking forward to meetings

/sites/default/files/styles/large/public/20160914-talk-talk.png?itok=7oCq30fM

I think in between the conversations with people I’ll talk with some other folks and have some chats besides that.

Very likely topics

Media
Content workflow
Data modelling
Sample content
Core ideation

I’ll make sure to share any visual notes fast this time…

Tags

Drupal

product

Drupalcon

Drupal UX meeting, 13 September 2016

Roy — Tue, 13 Sep 2016 22:35:14 +0000

Sub title

“Kevin, talk sample content to me”

/sites/default/files/styles/large/public/20160913-ux-meeting.png?itok=anOfYLz8

Another fun live hangout with Drupal UX peoples. We review and discuss current issues and provide feedback or guidance where needed. These hangouts are recorded and available on YouTube. I try to link to the right segment in the recording when updating issues with team feedback.

Discussed today:

A separate queue for Ideas

I marked Agile process for bigger changes in core (Part A: Ideation) RTBC today. It’ll be open for final thoughts for a few more days. Looks like we’ll have a dedicated place to work through ideas soon.

Sort of like a Display Suite lite in core

Or as we say: Add ability for entity view modes to switch between two hard-coded layouts.
Eaton called it, this is very inside baseball, but adding layout options for arranging the fields in your content type is super exciting.

Media library design

We have an issue going that collects examples of media library features in other systems. Super useful. We (you!) can start sketching out Drupal specific user interface screens and flows now and post them there. (This is one of those issues that would start in the above mentioned Ideas queue).

Sample content

There’s Lee’s post about what it means to provide the tools that enable you to add your sample content to your flavour of Drupal installation. And then there’s adding some (hardcoded?) sample content to core itself, because, well, onboarding. Starting with the latter, that means figuring out what sample content to add in the first place.
The brand new Drupal user guide uses the example of a website for a farmer’s market. Wouldn’t it be great if our sample content and configuration would support that scenario? Yes, yes it would.

Tags

Drupal

product

drupalplanet

Hire me to work on Drupal core

Roy — Wed, 07 Sep 2016 22:27:26 +0000

Sub title

Evolve Drupal 8, faster

There’s an unprecedented opportunity to quickly add and evolve critical features and usability improvements to Drupal 8. We can ship new things every 6 months. The amount of change we accomplish depends for a large part on clearly defined goals and a clear path to get there.
I volunteer about 4 to 8 hours a week on Drupal core ux work doing just that. Would love to do more.
If you are waiting for Drupal 8 to have things like better media capabilities, content workflow tools, a better Field UI, a smoother onboarding process and the like, I can help make that happen faster.
The deal: a €3000,- per month retainer gets you a solid 30 hours of design making, decision taking, issue wrangling, people connecting, task defining and all that’s necessary to get things done. Contact me if that sounds like a plan.

Why me?

Close to 10 years of working on Drupal UX. Experience helps moving things along.
I translate and clarify, bridging and translating between different perspectives, roles and priorities
Which helps make the necessary design trade-offs and provide direction
Clear design direction frees developers to actually go for it, reducing risk of working on the wrong thing.
Rebooted twice weekly UX meetings, productive on both strategic and tactical levels, getting more people to succesfully contribute.

No really, why me?

Bootstrapped Drupal UX team in 2007, contributing ever since
Top 30 contributor to Drupal 7
Helped redesign content creation page in Drupal 8.0
Helped ship the Place Block MVP for Drupal 8.2
Clarified what’s happening in the Workflow Initiative, designed some critical parts of the user interface so that content moderation tools could ship with Drupal 8.2
Helped define, refine and implement the new approach for shipping new features in Drupal 8.x

What’s in it for you?

Together we’ll define a plan for what to work on. You get what you need in Drupal 8, sooner
I’m sure we can figure something out around issue credits so that they are in your name
Bragging rights for doing the right thing!
I’ll write 2 blog post per month, crediting you and reporting on achievements and progress.

All in all, I can help ship more Drupal goodness, faster by clarifying and designing what’s next. If that is something you want to support, contact me and lets talk.

Tags

Drupal

Answering the Drupal Why

Roy — Thu, 01 Sep 2016 21:47:41 +0000

Sub title

Something something usability testing

/sites/default/files/styles/large/public/uxtasks.png?itok=U0Q-7DUp

The basis for knowing what to focus on for evolving Drupal core is learning about what people want to do with it.
Testing the initial experience of core as a whole has had our main attention so far. Now with focussed initiatives (content workflow, media handling, outside in, layouts,…), we’re adding experimental features with the assumed requirement that we validate and improve them trough feedback from usability testing.
So, we could (should!) create a more regular schedule of more smaller instead of few bigger usability test sessions. What’s our version of getting out of the building and increasing our exposure?
What would it look like if we did test every 6 weeks?
Produce testing scripts for each initiative. These can be reused, eventually updated where needed. Every 6 weeks we run those tests for each initiative. We learn what works, what needs to be improved. Initiative teams can prioritize fixing UX bugs. All things are connected anyway so we’ll learn about overall issues as well.
Feedback from the test participants can feed into ongoing persona work: what are people trying to achieve? Voilà, we’re learning about the Why.
Of course this requires planning, recruiting participants, having a setup for remote testing, getting access to a usability testing lab once in a while, observation, analysis, designing possible solutions, reporting back to the community, creating actionable issues to work on etc. But wow, we’d learn so much about where to focus our efforts.
Who wants to help make this happen? Mail, Slack (get invite) or lets talk at Drupalcon Dublin.

Tags

Drupal

usability test

drupalplanet

See you in the followups

Roy — Mon, 29 Aug 2016 21:31:30 +0000

Sub title

Note to self, mostly

We have the outline of potentially useful new features directly in core now. Now, to not only run off and add only more new goodies.There’s the job of validating and improving what we added already as well. I remember discussin with Alex Pott in New Orleans. Making it in as an experimental module is a “not no” kind of answer. To get to a real “yes”, lots of work left still.

Tags

Drupal

process