Drupal

No one-offs

Roy — Fri, 10 May 2019 14:05:23 +0000

Sub title

Things seen here are configured there.

/sites/default/files/styles/large/public/things-shown-here-configured-there.png?itok=qSZb6N0L

An elaboration on underlying considerations that make simple suggestions as this one not so simple after all.

An important consideration when deciding whether to “add something to core” is that generally speaking, core doesn’t do one-offs. The underlying principle is not “make it do X” but “make it possible to make it do X (and X2, X3,…)

Linking from a create context to a configuration context

In this particular case we have a proposal to link to the screen where you can add new content types from the page that lists available content types to create content with. Or, in url speak: on /node/add, put a link to /admin/structure/types. Or once more: on the screen that lists existing content types that you can create content with, add a link to the screen that lets you define new content types.

Notice the distinction between “create content of type X” and “define a new type of content Y”. The first is a content creation task, the second is a content definition task (in Drupal jargon usually captured under “site building”). This distinction then should clarify why a link to define a new content type should not use the “blue + button” pattern on a screen that is in service of a content creation task.

Back to the “no one-offs” principle. Where and how can we add a link of this kind? To answer that question we should look for possible patterns. Is there a more generalised definition for the type of problem that this single link to elsewhere wants to solve?

The example is: put a link to the content type definition area on the screen that lists already available types to create content with. Restated more generally: link to that area of the Drupal admin where the things on this screen are configured.

Connecting the dots is important

You know those links at the bottom of product pages in an online store: “people who bought this item also bought X, Y and Z”. In our case it’s more like “Things seen here are configured there.

I noticed a sort of similar pattern in the Android OS settings pages, where the screen ends with suggestions of related topics to the ones already shown. It’s a way to provide meaningful next places to go if the current page didn’t offer what you were looking for (and is of course a symptom of how many settings there are in the first place).

“Things seen here are defined there.

If we can find more examples of where this would be meaningful and helpful then we might have a good case for introducing a new user interface pattern. See image for some initial examples.

Tags

Drupal

drupalplanet

Drupal UX call, june 12 2018

Roy — Tue, 12 Jun 2018 21:04:54 +0000

Sub title

With live sketching!

Today about how to handle buttons you don’t want people to click, indicating global changes, pager behaviour and standards for UI texts.

Tags

Drupal

design

Idea: a data & content modelling UX sprint

Roy — Thu, 22 Feb 2018 01:19:16 +0000

Sub title

Who’s in?

During this weeks UX meeting we explored what it would mean to redesign the core Field UI. It’s definately in need of an update.

Currently all mashed together in a couple of tabs on Field UI:

Data modelling – Define data types and storage formats for individual fields & their relationships
Content modelling – Compiling individual fields into appropriate content (entity) types and configuring the input form for creating content items
Display modelling – Configuring different ways to display these created content items

One of the first steps towards a new and improved user interface for Field UI would be to unbraid these different types of tasks. Take it apart and put it together again in more user friendly ways.

Would be nice to kick this off with some kind of (virtual) UX design sprint, no?

Tags

Drupal

content modeling

drupalplanet

Tweets starting from here

Roy — Sun, 18 Feb 2018 22:55:07 +0000

Sub title

Tweet-sized notes posted as content on yoroy.com that get pushed to Twitter via RSS and Zapier.

/sites/default/files/styles/large/public/20180219-notes-ui.png?itok=4rNLWr49

My previous post inspired Joeri to some improvements on his site. Nice!

I built another step towards POSSE this weekend: tweet-sized notes posted as content on yoroy.com that get pushed to Twitter via RSS and Zapier. Here’s how:

Create a new content type “Note”. This one needs to only have a text area. And here we run into Drupal always requiring a title. We can’t create entities without giving it a title. The title itself is always a text field, so not ideal for writing 280 char bits of text. Two contrib modules to work around this:

Auto entity label to define an automatic pattern for the title of these Notes. I set it to use a simple timestamp.
Exclude node title to actually hide the title field on the Note creation form and on display.

Next I defined a new text format that does not use CKEditor but allows tags and automatically transforms URLs into links. I set this to be the default text format for the text area on the Note using the Better Formats module (sadly currently only available as an old development release). This step is optional, it helps remove user interface clutter. This gives me a content creation form with just a single plain text text area, a “published” checkbox and a Save button.

I updated the views that list blog content on this site to also include content of type “Note” and configured a Notes RSS feed as well. I use this feed as an input on Zapier where the Notes body is extracted and posted as a tweet.

Tags

Drupal admin tasks

Roy — Sat, 17 Feb 2018 23:31:34 +0000

Sub title

lets talk task groups, not roles and certainly not personas in this context

/sites/default/files/styles/large/public/admin-ia-workshop.png?itok=F_7KCIHt

A late summary of one of the two BoFs on Drupal admin UI improvements that we held at Drupalcon Vienna. An inventory of tasks for three main task domains: create/manage content, build structure/configure functionality and build functionality. Yes, these domains map to the types of roles we often use: content creator, site builder, developer. Problem with that is those role based labels make it too easy to forget that the same person often switches between multiple roles. Somebody who’s developing part of a content API will build a content type and create content in order to check their work.

Not complete and not in any particular order:

Create and manage content

View content
Review content
Inline editing
Schedule content
Create revisions
Link to external media
Publish
Search content
Content relations
Layout content
Update site content
Translate content
Optimise SEO
Revert a revision
Delete content
View content in context
Import/export content
Manage revisoins
Moderate content
Edit media
Choose layout template
Upload media
Manage menu
Manage content structure

Build structure and configure functionality

Create entity types for information architecture
Structure each entity type
Define display options, globally
Define display options, individually
Create content curation(?) - views, lists, blocks
Configure language options for translations
Prepare site for themer/frontender
Provide/improve user interface for other users
Create roles
Create permissions
Access & read help/documentation
Access reports
Debugging

Building functionality

Build the business logic
Build integrations
Create layouts
Build data structures
Provide APIs
Write documentation
Define permissions
Provide configuration options
Create forms
Define lists of components
Migrate content
Fix bugs
Update code/features
Deploy
Define cache rules
Extend functionalities

Tags

Drupal

Drupal admin revamp UI research

Roy — Wed, 14 Feb 2018 21:56:58 +0000

Sub title

Some links that might help sketch the outlines of what a “Drupal admin UI revamp” might involve.

/sites/default/files/styles/large/public/20180214-admin-revamp.png?itok=cQvydZqz

At Drupalcon Vienna there was a lot of interest and preparation work done around modernizing the Drupal administrative interface. I wrote up a high level summary here. As a result this initial issue was posted.

My previous post with a small concept for the editor UX triggered some interesting discussion on Twitter.

We also discussed this topic during yesterdays UX meeting.

As a result, ckrina now proposes an initial round of research to learn and get inspiration from other systems. Mind you, this is the woman that brought us the redesigned status report page and is a member of the team that made the Umami demo that’s now in core. Good things can come from this!

Your help in researching these topics is very welcome. Have a look.

Tags

research

Drupal

drupalplanet

Sneak preview of the new Drupal UI for content creation

Roy — Sat, 10 Feb 2018 23:56:19 +0000

Sub title

No it isn’t. But maybe it should be.

/sites/default/files/styles/large/public/20180210-content-creation-ui-preview.png?itok=DbU7bNKf

I declared separate title and body fields old school in that previous post about removing friction. In the mean time, I’ve installed and tested a few Android applications for taking notes. There too it was an immediate turn-off to see a separate field for the note title. Let me write something first, I might think about naming it later. Often (in this note taking context) it’s not even really necessary. And so the first few words of the note becomes the title on the notes listing screen.

Even simply showing a label with, and a border around individual form fields is emphasizing the implementation model. Of course these elements are sometimes necessary affordances to show, but still:

Using the first line in a body of text as its title seems like a sensible default. No need to be so literal and explicit about it and present separate input boxes for both.

Tags

Drupal

author ux

sketch

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

17

Roy — Mon, 15 Jan 2018 21:34:28 +0000

Sub title

years of Drupal

/sites/default/files/styles/large/public/20180115-17.png?itok=5WAijQuS

Drupal is 17 years old today. Quite an achievement for a web software to stay around, let alone stay relevant for such a long time.

I’ve been around for 12 years. Quite a stretch as well. Getting involved in this open source project as a designer has taught and brought me a lot. I put quite a bit into it as well.

I get a lot of benefits from things I learned in Drupal that I can apply in other contexts.

Provide rationale for design decisions. So much typing in issue queue comments!
Help people see the other’s point of view and then come to a shared decision.
Or agree to disagree, then still make a choice.
An appreciation and at least a “gist of things” knowledge of the complexity of software development. It helps with clarifying scope, finding a good place to start, and understanding what is difficult and what can be relatively straight forward.
Pragmaticism over purism
Edge cases are important
There’s a difference between patience and stubborness
Accessibility, multilingual, extensibility, modularity are hard but worth it
If you can’t imagine why somebody would want do do X, it’s always from a lack of imagination from your part
There’s always so much more to do
There’s only so much you can do
When you start taking things personal it’s probably time to take a break
It’s amazing what people can get done when driven by a passion for doing a good thing and doing it well.

… and many returns!

Tags

Drupal

drupalplanet

open source

One to many or one to one, an example of a Drupal UX design decision

Roy — Tue, 02 Jan 2018 22:57:07 +0000

Sub title

Short recap of an interesting discussion during today’s UX meeting.

/sites/default/files/styles/large/public/media-upload-sketch.png?itok=ar3pBxzP

About inserting media items from within the WYSIWYG editor. These could be different types of media files, like images, video and audio. You could even have different flavours for the same file type. For example with images, you might want to store different information and metadata on product images than on images used in press releases or for the company blog posts.

The question was how to provide the starting point(s) for this. Of course the goal would be to make this as transparent as possible, reducing the amount of administrative busy work to the required minimum. But, structured content does not yet create itself automatically, we do have to provide forms that present the required fields to fill out when adding a media item.

We discussed two basic approaches

There are likely more and there’s room for subtle variations inside these two as well.

Option 1: start with a single button to add media

Click 1 generic “add media” button in the WYSIWYG editor that launches a media upload form
Upload the media (image, video, audio, …) you want and save
Figure out the media file type and present the corresponding form with the required (meta)data fields in a second step
Save and return to the editor

Option 2: choose from multiple buttons to add a specific media item

Find and click the add button for the media you want to create. There would be separate buttons for inserting an image, a video, an audio item
Because the type is known we can directly show the form for the required (meta)data.
Save and return to the editor.

(Although this list only goes to 3 instead of 4, there is a bit more work for the user to do in step 1: finding the right media button to click)

After a bit of back and forth we chose option 2, because:

A one-on-one relationship between WYSIWYG button and media type to create is easier to understand
The upload process can be contained within 1 step because the system knows upfront which form to show for the required info.
With this one-to-one relationship, per media type permissions can be handled more elegantly (you either have a audio upload button or you don’t)

The trade-offs are:

it’s not super elegant to require the user to do the upfront work of explicitly choosing the type of media to create.
With multiple types of media available we’ll have to see how to expose all those different options in the WYSIWYG editor toolbar.

Tags

Drupal

drupalplanet