Improve workflow & UI by making a Entity Reference View with multiple fields

User story: Help editors pick the correct representation of an article when connecting it to be displayed in a new department.

Background: We noticed that editors where picking the wrong representation of an article as there can be many of them. The reason for this being that we let editors customize the representation of their article depending on the department where it is being used.

Solution: Change the Entity Reference (usually a simple entity selection field) to a Entity Reference View.

Step by step: 1. Go and create a new view, add a Entity Reference display, and add the fields (filters etc just like a regular view) you want to display to the editors. If you select more than one field you will need to specify the ”Search fields” (Format –> Settings). In our case we added the date and department title. We are also thinking of setting a sort criteria DESC as it is likely most editors are looking for recently published content.

2. Go to your content type, and edit the field that is a Entity Reference. Change the reference selection to a view, and then pick the view you created. In ”View used to select the entities” select the display you made.

Entity reference

3. This is the end result with some additional CSS work:

Styled entity reference

Just adding the fields would have improved the editorial workflow, but just a little bit of CSS helped to make it even more usable. I removed the default wrappers and added some custom CSS classes for the fields. This way I was able to adjust the styling of the title, date and department.

.reference-autocomplete {
  border-bottom: 1px solid #f1f1f1 !important;
  padding: 3px 2px;
}
.reference-autocomplete:hover{
  border-color: transparent !important;
}
.reference-autocomplete span.er-node-title {
  font-weight: bold;
}
.reference-autocomplete span.er-post-date {
  color: #555;
  font-size: 0.8em;
}
.reference-autocomplete:hover span.er-post-date {
  color: #f1f1f1;
}
.reference-autocomplete:hover span.er-promo-parent-subject-page, .reference-autocomplete:hover span.er-kicker, .reference-autocomplete:hover span.er-content-type {
  background-color: #f3f4ee;
  border-radius: 3px;
  color: #0072b9;
  padding: 1px 2px;
}
.reference-autocomplete span.er-promo-parent-subject-page, .reference-autocomplete span.er-kicker, .reference-autocomplete span.er-content-type{
  color: #555;
  font-size: 0.7em;
  font-weight: bold;
  text-transform: uppercase;
}

Decided to style all Entity References in the admin theme with a bit more padding and a border-bottom line as it improves readability.

When trying to inspect the autocomplete div I noticed it was quite difficult to grab it via the inspect element function, but grabbing it via ”Copy as HTML” worked. This is what the basic markup looks like on a regular Entity Reference Simple field.

<div id="autocomplete"><ul><li><div><div class="reference-autocomplete">Österbotten</div></div></li><li><div><div class="reference-autocomplete">Kontakta Yle Österbotten</div></div></li><li><div><div class="reference-autocomplete">Lyssna på Radio Vega Österbotten!</div></div></li><li><div><div class="reference-autocomplete">Valet i Österbotten</div></div></li></ul></div>

The class-name of the line you hover on is named ”selected”.

Thanks to Olli Vesslin.

Användargränsnitt: Hur det underlättar ditt jobb och ökar antalet läsare

Inom Drupal talar utvecklarna ofta om att beställarna inte förstår att prioritera användargränssnittet för de interna användarna. Det är en av Drupals akilleshälar, eftersom om det ofta inom beställar-organisationen inte finns en förståelse för att med Drupal så får man ett system som man bygger sitt eget system med. Då är det inte lika enkelspårigt att se till att användargränssnittet är sådant som slutanvändaren önskar sig. @pixelmord höll ett bra presentation gällande ämnet på Frontend United.

Ett användargränsnitt som inte stöder användarna leder till förluster eller förlorade möjligheter. Läs t.ex. ”The $300 Million Button”. Små insatser kan vara värda stora summor.

På svenska.yle.fi har vi tagit detta i beaktande på flera sätt, t.ex. så finns det en ”föreslå termer” knapp som automatiskt föreslår taggar/termer/kategorier till artiklar. Det ersätter inte att en människa läser igenom och bekräftar de relevanta förslagen. Däremot så underlättar det och snabbar upp redaktörens arbete då de inte manuellt måste söka efter varje ord de vill tagga artikeln med. Då finns det tid att söka efter de relevanta taggar som automatiken inte förstod att lägga till.

Ett annat exempel är att varje intern användare kan ha en egen lista på ”favorit-ämnessidor” dit han/hon* skickar sina artiklar. Utgående från ämnessidor visas artikeln till slutanvändaren.

Därför är viktigt att en artikel som är intressant för både ”Inrikes” och ”Österbotten” skickas till båda ämnessidorna – annars kommer inte användarna som huvudsakeligen väljer att läsa ”Inrikes” vs. ”Österbotten” inte att hitta och kunna läsa artikeln. Ett annat exempel kan vara ”Sport” och ”Västnyland”.

Vi har märkt att denna funktion inte används optimalt inom organisationen, så jag passar därför här på att visa hur man gör för att ställa in sina egna favorit ämnessidor:

Gör så här:
1. Gå till din profil (klicka t.ex. på ditt eget namn i en artikel du skrivit)

2. Klicka på ”Redigera”

3. Rulla ner till ”Favorit-ämnessidor”

4. Skriv in de ämnessidor du önskar (sätt ”Första sidan” sist i listan)

5. Spara

Så här ser det sedan ut då du går in och skall skriva en artikel:

Funderar du på vilka ämnessidor som skulle vara optimala för dig? Sätt till alla sidor du någonsin brukar använda, dvs jobbar du inom nyhetsorganisationen är exemplen ovan åtminstone dem du behöver – detta eftersom de också fungerar som en undermedveten påminnelse då du skall välja vart du skall skicka artikeln.

Ett traditionellt sätt att lösa detta skulle ha varit att tvinga den interna användaren att söka efter varje ämnenssida manuellt, eller att lista dem alla (ca 50 st) åt alla användare. Ingendera är särskilt optimalt eller användarvänligt, speciellt inte på en plattform som skall stödja ett snabbt arbetsflöde för allt från Strömsös recept, vanliga artiklar, bloggar till nödmeddelanden.

* Det är vid tillfällen som detta man kan tycka att hen vore ett praktiskt ord att använda.