Meeting on 27 May 16:30 BST. Attended by @emma-horrell @rkoller @worldlinemine @AaronMcHale
Notes here:
Drupalisms meeting progress log
Summary:
- Updated the issue to log introduced terminology in the Drupal core new issue template to include link to controlled vocabulary spreadsheet so all can view to assess whether terms are new.
- Continued noun foraging from admin UI to ensure we have a complete list of terms. Made some adjustments to the collection process to ensure terms are categorised and more searchable than they were previously.
- Discussed ways to link this work to the impetus to make Drupal more inclusive and a more attractive proposition to CMS deciders. @emma-horrell to investigate requirement for user testing of Drupal Starshot
Next meeting scheduled: Monday 10 June 16:30 - 17:30 BST
Meeting on 13 May 16:30 BST. Attended by @emma-horrell @rkoller
Meeting on 20 May 16:30 BST. Attended by @emma-horrell @rkoller and @dead_arm
Notes here:
Drupalisms meeting progress log
Summary:
Continued noun foraging from admin UI to ensure we have a complete list of terms.
Identified the need to log introduced terminology in the Drupal core new issue template to keep track of new terms as they come in (issue opened by @dead_arm (3449694)
Next meeting scheduled: Monday 27 May 16:30 - 17:30 BST
Meeting on 29 April 16:30 BST. Attended by @emma-horrell and @rkoller
Notes here:
Drupalisms meeting progress log
Summary:
Continued noun foraging from admin UI to ensure we have a complete list of terms
Next meeting scheduled: Monday 13 May 16:30 - 17:30 BST
lauriii → credited Emma Horrell → .
Short meeting held Monday 1 April 16:30 BST - followed up by an additional meeting on Monday 15 April 16:30 BST. Attended by @emmahorrell and @rkoller
Notes here:
Drupalisms meeting progress log
Summary:
Started examining up-to-date admin UI to ensure we have a complete list of terms
Identified that promoting this issue at DrupalCon Portland through a quiz or a top-tasks-style survey may not be possible given the short time we have left and the limited resource we have working on this.
Next meeting scheduled: Monday 29 April 16:30 - 17:30 BST
Meeting held 18/03/2024 @emmahorrell @rkoller @worldlinemine @AaronMcHale
Notes here:
Drupalisms meeting progress log
Summary (full description and actions detailed in notes):
Further discussed the idea of a survey to gather data about the priority Drupalisms (the terms that cause most confusion). Survey is a good way to raise awareness, however, it may only reach people who know Drupal, and to address this issue we want to capture perspectives of those who are unfamiliar with Drupal and find some of the terminology confusing.
Actions: All to review survey draft and feed in thoughts/suggestions. Ask for Drupal Association's help in circulating/publicising the survey on social media, and investigate how we can publicise work on this issue at DrupalCon Portland
Next meeting scheduled for Monday 1 April 16:30-17:30 GMT
Meeting held 04/03/2024 @emmahorrell @rkoller @AaronMcHale
Notes here:
Drupalisms meeting progress log
Summary (full description and actions detailed in notes):
Idea to run a top tasks style survey (using Drupal social media channels to promote) in the weeks leading up to DrupalCon Portland (May 6-9) to ask the community to vote on the Drupalisms they feel cause most confusion amongst people new to Drupal. The results of this survey would guide a BoF on Drupalisms - for example the BoF could involve attendees writing definitions for the top 10 terms emerging from the survey responses.
Actions: prepare for the survey: identify Drupalisms to include (no more than 100) and draft the survey introduction and question
Results of the survey and data gathered from the BoF could be used to guide developing this issue into an initiative.
Next meeting scheduled for Monday 18 March 16:30-17:30 GMT
Meeting held 5/02/2024. @emmahorrell @rkoller @worldlinemine @AaronMcHale Notes here:
Drupalisms meeting progress log
Summary (full description and actions detailed in notes):
Idea to use data gathered from forthcoming navigation usability tests to help us understand how people make sense of UI Drupal terms in the context of tasks
Focused on actions we could take to build momentum around this issue and gain support/buy in from the community in the run up to DrupalCon Portland
Meeting held 5/02/2024. @emmahorrell @rkoller @worldlinemine Notes here:
Drupalisms meeting progress log
Summary (detailed in notes):
- @rkoller took us through 6 stage process towards a Controlled Vocabulary
- Draft terms
- Evaluate terms based on how challenging they are, how frequently used, etc
- From Evaluation, decide what to include in the Controlled Vocabulary
- Work on multilingual Controlled Vocabularies
- Make a list of ‘words we do not say’
- Keep it alive with governance
All agreed on the approach, starting first stage of the process with ‘noun foraging’ - gathering nouns we encounter with Drupal (not only on Drupal.org but also in Slack, in forums, social media etc)
Plan to do usability testing with novice Drupal users to test which UI terms make sense/are confusing in the context of performing common tasks. First step: come up with a list of representative tasks to use in a test.
Discussion about how to get wider buy-in for this issue in the community. Ideas included taking to UX group at appropriate stage in the process.
Next meeting scheduled Monday 19 February 16:30 - 17:30 GMT
I've added some suggestions in comments in the Google doc. It's looking good!
Meeting held 22/01/2024 @emma-horrell @rkoller @cellear @worldlinemine Notes here:
Drupalisms meeting progress log
Summary: (detailed in notes)
- @worldlinemine helped us define the scope of this issue and define the short term, long term and overarching goals
- We identified where we would like to get to: a controlled vocabulary for all versions of Drupal and a way for Drupal users to be able to understand what terms mean in context - for example in documentation and in the UI, in the language they speak. A process for new terms to be added and out-of-date terms to be removed to avoid confusion
- We identified key next steps: to make an inventory of drupalisms, define these in plainer terms and prioritise drupalisms to change based on evidence
- @rkoller made suggestions of how we may approach the development of a controlled vocabulary drawing on the work of Abby Covert and Erica Jorgensen.
Next steps: @rkoller to draft stages to work through towards a controlled vocabulary for all to review and feedback
Next meeting scheduled Monday 5 February 16:30-17:30 GMT
Attended meeting Jan 18, contributed to designing the platform overview page
Meeting held 08/01/2024 @emma-horrell @AaronMcHale @rkoller @drupalviking @cellear @worldlinemine @ckrina. Notes here:
https://docs.google.com/document/d/13Isn8_BdQK-Ze-A5G5JVTV7GP5b-IpoFXo3f-b-uN70/edit
Summary: (detailed in notes)
- Reviewed information we currently have about drupalisms
- Discussed some of the issues with Drupal terminology
- Considered the criteria that make terms drupalisms
- Began reviewing some of the drupalisms identified to consider alternative terms and ways to describe them
Next steps: Meeting scheduled 22/01/2024 to:
- Review more drupalisms
- Consider how we prioritise which drupalisms are the priority to address (test with novice users? frequency of use? prioritise those that differ from 'industry standard')?
- Discuss pros and cons of changing terms
- Discuss how we could describe them and associated feasibility - use of the glossary? embed descriptions in interface or within documentation?
- Discuss sustainability of solutions based on projected future terminology changes in Drupal
benjifisher → credited Emma Horrell → .
benjifisher → credited Emma Horrell → .
xjm → credited Emma Horrell → .
Summary:
We wanted to test the usability of the following elements:
Top bar
Overall we wanted to find out if the top bar (comprising a ‘More actions’ dropdrown menu on the right, Save and Preview buttons on the node edit page, breadcrumbs and a ‘go back’ option on the left-hand side and the option to collapse the right-hand side panel) was useful, and therefore worth including. Tests focused on tasks requiring users (with different levels of experience) interacting with these top bar elements.
Top bar ‘More actions’ menu (top bar right): We wanted to find out: did users identify the ‘More actions’ dropdown, did they interact with it to find the local tasks, which would previously have been displayed on the page?
Breadcrumbs and go back: Did users notice these options and were they useful to them?
Tablet left toolbar behavior: Were users able to collapse the vertical side bars and was this useful to them?
Content creation menu
The prototype contained a left-hand menu option ‘Create’. Did users find this useful? Did participants go to use it when given tasks to create content in a usability test?
We devised 3 scenarios to test these aspects. 6 usability tests were carried out with 3 content users, one developer, and 2 content user/site builders. All tests were done on desktop devices.
We found the following findings/results to the tests:
Participants did find ‘More options’, but only the experienced developer found it quickly. The others took a while to find it.
Most participants said they felt the actions in this dropdown were important and they wanted to be able to them more easily (e.g. in one click)
Participants’ ability to find the ‘More actions’ dropdown was impaired by the presence of other UI aspects:
A ‘Back to edit’ option (positioned by the breadcrumbs on the top left) - several opted for this instead of ‘More actions’
Option to ‘Turn On In Place Editing’ (accompanied by the ‘edit’ icon) in the top bar to the left of the ‘More actions’ dropdown - several clicked on this expecting it to take them to an editing menu
All participants opted to use the ‘create’ menu option instead of the ‘content’ menu option when asked to create content
All participants took some time to notice how to open/close sidebar on the right, but all did find it
Collapsing the sidebar was especially useful when the participant had a small screen
Several participants expected the text area to expand when the sidebar was closed
One participant expected the sidebar to be draggable
Other observations
Participants were confused by the ‘Back to edit’ and ‘Back to site’ options presented in the top area on the left of the breadcrumbs.
They weren’t clear if this would take them back to a previous page, and if it was a link or not
They didn’t associate ‘editing’ with ‘going back’
Use of ‘Back to edit’ and ‘Back to site’ in this area was inconsistent - participants were unsure if they would go to the site or the administration area
Several participants questioned the order of items in ‘More actions’ - they felt more frequently-used actions like ‘Edit and View’ should be more prominent
All 6 participants felt the left sidebar was intuitive
Some participants said they wanted a solution for +3 level deep items in left sidebar
Recommended actions:
Acknowledging that breadcrumbs might be useful to contextualize in the complex administration, run an A/B/control test with and without breadcrumbs to test their usefulness
Remove ‘Back to edit’ positioned next to the breadcrumb - adopt a consistent approach to include ‘Back to site’ in this position
Review use of the left top bar as a way to go back to parent items
Make ‘More actions’ more prominent, so it’s more obvious to users what it is for. Options:
Review placement and design of the ‘Turn On In Place Editing’ option (remove editing icon?)
Take ‘Edit’ and ‘View’ out of the ‘More actions’ and put these in the toolbar with ‘More actions’ alongside and test again to see if efficiency of the task completion improves
Consider a solution for +3 items as a ‘nice to have’
benjifisher → credited Emma Horrell → .
benjifisher → credited Emma Horrell → .
ckrina → credited Emma Horrell → .
Proposed description relies on you knowing what link tag attributes are, so suggest adding some detail to clarify what link attributes do.
Suggested description
Lets you add in extra link tag attributes (for example ‘id’, ‘class’, ‘target’) to control how links display, function and behave.
Proposed resolution relies on the site builder knowing what 'text formats' and 'field instances' are. People who know Drupal will scan for these terms, but those who don't may need a non-Drupal alternative.
An alternative short description could be:
Restricts the types of text (text format) that can be included in reusable pieces of content (field instances). Helps ensure content consistency and security.
Aaron McHale and Emma Horrell are running a BoF to address this issue at DrupalCon Lille:
https://events.drupal.org/lille2023/session/lets-work-together-uncover-a...
benjifisher → credited Emma Horrell → .
benjifisher → credited Emma Horrell → .
xjm → credited Emma Horrell → .
benjifisher → credited Emma Horrell → .
benjifisher → credited Emma Horrell → .
benjifisher → credited Emma Horrell → .
benjifisher → credited Emma Horrell → .
benjifisher → credited Emma Horrell → .
benjifisher → credited Emma Horrell → .
benjifisher → credited Emma Horrell → .
benjifisher → credited Emma Horrell → .
Done :) I'll also share with our wider development team
benjifisher → credited Emma Horrell → .
pieriwww → credited Emma Horrell → .
pieriwww → credited Emma Horrell → .
pieriwww → credited Emma Horrell → .
pieriwww → credited Emma Horrell → .
pieriwww → credited Emma Horrell → .