drupalplanet

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

Implementing IndieWeb on your personal Drupal site, part 1

Roy — Sun, 10 Jun 2018 21:53:30 +0000

Sub title

Laying the foundations for POSSE

/sites/default/files/styles/large/public/20180610-indieweb.png?itok=bFJfMCXu

This is my version of the steps you need to take to make your site part of the indie web community. Swentel helped me getting it all setup on this here Drupal site using his indieweb module. It’s all a bit complicated still, so this is mostly me trying to retroactively understand what’s going on.

As it says on the site, the IndieWeb is a people-focused alternative to the corporate web. Its main tenets:

Ownership – your content is yours, it should not belong to a corporation.
Connection – starting from your own site you can share your content to all other services.
Control – post what you want, in the format you prefer, using your own URLs that you keep permanent.

While 1 and 3 are essential and relatively easy to achieve (use your own domain and post your content there), it’s number 2 that is the most alluring.

Owning your stuff and being able to share it across multiple platforms combines ownershop with reach. This is what “POSSE” is all about: Publish (on your) Own Site, Syndicate Elsewhere. Drupal lead Dries Buytaert has written several posts outlining his POSSE plan.

Getting started

This “Connection” part of indieweb publishing is also the most complicated. There are quite a few moving parts to getting it all up and running.

For Drupal sites, the setup for the community/sharing/syndication parts of indieweb publishing has gotten much more accessible with the release of the IndieWeb module created by swentel. It doesn’t necessarily reduce the number of things to set up, but it provides a centralized UI for all of them: Webmentions, Microformats, Feeds, Micropub, IndieAuth and Microsub.

Before going over the details of configuring the indieweb module itself, we have to take care of some basics first.

Introduce yourself (right on)

To own your content on the web, you have to establish that you are in fact, you. That’s why IndieWeb starts with having your own domain and posting some initial content there. Important part of this initial content is a specific bit of HTML that establishes you as the author and owner of things published on this particular domain:

Roy Scholten

The specific part here is that “h-card” class added to the anchor tag. This “h-card” is one of a collection of so-called microformats. With microformats you give more structure and semantics to information presented in HTML. In this case, h-card is the microformat to use for publishing information about people or organisations. We’ll need to add other microformats to (blog) posts you publish on the site, but that’s for later.

To do in Drupal

The indieweb module does not (yet?) handle adding this information to your site. Add your version of the HTML snippet above to a (new or existing) Drupal block. Place that block to be visible on your homepage. The site footer or maybe a sidebar are obvious places you can put it. Mine’s in the footer below.

You can check if all is fine with https://indiewebify.me/validate-h-card/. Enter your domain name there and it will report back with what it found and suggest additional elements you could add to enhance your h-card.

Even without posting any other content to your own site, you now have your own space on the indie web and setup your identity in a way that you own and control.

Next: add links to your existing social media accounts

You’ve seen those signup forms that let you create an account by using your existing Google, Facebook or Twitter account details. In this step, you configure your own domain to be your IndieAuth identity. This lets you use your own domain to sign in to other sites and services.

There are not many sites outside the indieweb circles itself that offer this, I think. It’s still useful to do this though. You’ll likely want to use some of these indieweb services, especially to automatically share (links to) your content on other platforms like Twitter or Facebook.

To do in Drupal

Detailed instructions are here. In short:

Add links to your other profiles and add the rel="me" attribute. Might as well add this to that h-card block you created in the first step. For example:

@royscholten on Twitter

If you have a Github account, that’s also a good one to add.

To do on the external sites you link to

Link back to your homepage from your profile page on these services. The indieweb wiki has direct links to edit your Twitter and Github profile.

Then, try logging in to indieweb.org to see if it all works.

So far, so good,

So what? By establishing your identity on your own domain you stake out your own spot on the internet that you control. With this set up, you have created an environment for publishing on your own site and syndicating elsewhere.

Next time: configuring the indieweb module to start sending and receiving webmentions, the indieweb catch-all term for comments, likes, reposts and the like.

Tags

indieweb

posse

drupalplanet

Design system principles

Roy — Wed, 02 May 2018 22:18:41 +0000

Sub title

Defining aspirations and the building blocks and guidelins to achieve them.

Reviewed a list of design system sites today.

Google’s Material
Lightning for Salesforce
Fluent by Microsoft
Polaris for Shopify
Photon for Firefox
IBM design language
Australian Government Design System
Nachos for Trello

Not super strict, but mostly these are design systems that aim to support multiple apps, tools and services on multiple platforms.

I specifically looked at:

The guiding design principles: which ones and why
Top level sections for exploring the full system

Top level sections

Can be short on this: a quite consistent pattern of entries for "Getting started, Styleguide, Resources/downloads. What’s behind there varies a lot in depth and quality, mostly depending on the size of the organisation behind it. IBM goes very deep, Nachos understandably less so.

Design system principles

The most common pattern is to list a noun or short statement that expresses a characteristic of the type of designs the system wants to support. “Clarity”, “Empower but dont’t overwhelm”, “Universal”, “Engaging and immersive”, “Approachable”, etc. Material only lists 3 high-level ones but has more per section below. Nachos maybe goes a bit long with 10.

Not many of the systems listed mention content, text, words as an important part of a design. Shopify says: “Thoughtful, consistent interface content is a core element of a well-designed user experience.” IBM puts “Defer to content” as the first guiding principle for their visual design guidelines.

Even less mentions of designing for people. This may be inherent to what these sites do: describing the aspects of the system itself. Most of the times the human centered part is put under a usability or accessibility section further down the hierarchy.

One interesting outlier

IBM design language takes a different approach. Instead of listing the high level characteristics the systems aspires to, it defines 6 universal experiences:

Discover, try and buy – Meet users where they are. Show, don’t tell. Create a seamless transition from “try” to “buy.”
Get started – Invite users in and show them what they can do.
Everday use – Users should get personal value every time they interact with your product.
Manage and upgrade – Upkeep and receiving the newest improvements should be as elegant and predictable as using the product every day.
Leverage and extend – Everything wants to be mashed up. Each part of your offering should be available as an API.
Get support – Support users in the ways they want to get help. Expand their knowledge and encourage them to share.

These put user-centered design center stage, using a life cycle approach. It acknowledges that there are different stages in familiarity with the product and identifies different clusters of scenarios and tasks. Everyday use is something else than Manage and upgrade. Different frames or lenses for looking at the same product(s). This also implies that the same app, product, or even a single new feature has to worked on from all these perspectives.

Thinking about first time use (getting started), regular use (typical tasks), advanced use (extending, customizing) and managing/upgrading are all very relevant perspectives on how people work with Drupal. One example: “Getting started” currently gets special attention, see improving the Drupal evaluator experience.

Tags

drupalplanet

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 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

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

Core strengths

Roy — Mon, 05 Feb 2018 23:28:07 +0000

Sub title

“Plan and model digital products for today and tomorrow.”

/sites/default/files/styles/large/public/20180206-designing-connected-content_0.png?itok=wYpEKMo_

The Designing Connected Content book has arrived. “Plan and model digital products for today and tomorrow.” I have yet to dive in but I see Drupal screenshots and lists of field types like entity reference, long text (formatted), boolean, number (float), etc.

Today a content strategist collegue asked me about that list builder thing in Drupal. Show items of type x, filtered by y, sorted by x and only show fields 1, 3 and 6 of each item. And is it available for Drupal 8 as well?

Yes, that’s 1. Field UI and 2. Views module, which are both part of the Drupal core package.

We take Drupal core features for granted that other systems are still struggling with. They are also features people struggle with in Drupal because of hard to use user interfaces. I would love to see research and design work happen around how we can improve Field UI and Views UI.

Tags

book

designing connected content

drupalplanet

content modeling

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