Research | Fiona MacNeill | Macknowlogist

Magical Meetings - A Review

Sun, 17 Oct 2021 00:00:00 +0000

This post relates to of thinking about what makes an online space inclusive. I decided that UX Brighton’s monthly Show and Tell events are a good way to set mini deadlines for myself. Sometimes I use these events to present new tools or UX methods that I am using. This has now branched out to presenting the occasional book review. My review of Magical Meetings was presented at the August 2021 Show and Tell, where I fed forward my learning in an abbreviated 15-min summary. The book also got me thinking broadly about my own experiences of working in education and the soft skills involved. So, I decided to give the information some breathing space prior to writing this longer form blog post.

About the Book

The book, Magical Meetings was discussed by one of the authors, Douglas Ferguson on . Ferguson founded Voltage Control a company that focuses on facilitation including meetings, workshops, and team dynamics. They also look at workflow and transformation, considering for example how to optimise agile sprint cycles within different organisations. All of this sounded fascinating and quite different from my current work in Higher Education.

Title: Magical Meetings, Reinvent How Your Team Works Together
Authors: Douglas Ferguson & John Fitch
Publisher: Ideapress Publishing
Copyright Date: 2021

Summary

This is my own summary of the book to give you the gist.

Magical Meetings reframes the act of facilitating, attending and reporting back from meetings. It aims to empower facilitators to prevent bad meetings from taking place. It also provides strategies to support human creativity and productivity when meetings do happen.

Setting

Where did it happen?

The tips, advice, workflows and templates provided in Magical Meetings were validated through Voltage Control’s day-to-day work as an agency focused on the facilitation side of business process for software development.

When does it apply?

Magical Meetings is not talking about all meetings, rather it forcuses on: Workshops, Sales Meetings, Presentations, and Conferences. Any of these meetings can take place in-person or online.

An excerpt to give you the flavour

This is one of my favourite elements of the book, a test to establish whether a meeting should take place. In the table below, if one or more of the questions between 1 and 4 are ‘yes’ then the meeting is worth having. If question 5 is yes, then a written report, an email, or an update in a project/task management tool, such as Jira, Trello, or Microsoft Planner would be better.

The table below is a direct quotation from p. 24 of Magical Meetings.

#	Should we even have a meeting?	Test
1	Is there a clear purpose for gathering people to meet?	Y/N
2	Is there an artifact/prototype to review?	Y/N
3	Is there going to be an artifact/prototype that we can create after workshopping in the meeting?	Y/N
4	Will decisions that alter the direction of the project be made?	Y/N
5	Is this essentially a status update in disguise?	Y/N

Note

Once you start using the table above it may lead to existential unrest. It led to my own sudden realisation that many meetings, beyond my control, were indeed “status updates in disguise”.

What worked for me

There is a lot to like about this book, to summarise my key takeaways…

Meeting Purpose

The book presents ways to think about meetings as an edifice of the working environment. Turns out there are a lot of company-cultural hang-ups related to meetings and emotional needs as part of that, so it is useful to split up meeting planning and communication into sections. First is the purpose of the meeting, for which the authors provide the following criteria: “Informative, Explorative, Generative, Decisive” (p. 26). I have found these criteria useful for reflecting on my own meeting experiences, considering clarity of purpose and whether it was clear to participants what the purpose was in advance. Essentially for a meeting to be truly successful, participants must understand why it is being called, what the expectations are for their input and what is in it for them personally or as part of team working towards shared objectives. From an inclusivity perspective, the key aspect is expectations for participant input. Being able to mentally prepare beforehand for collective and group focused work is crucial for some neurodiverse people. It is also important to plan out aspects of the meeting which could be worked on individually, yet still together, to unlock ideas and to provide space for the less dominant yet equally valuable voices in the room.

Meeting Outline

The second is a meeting outline. This is essentially an agenda or schedule listing what will happen when, including activities and breaks. These elements should be mapped to the meeting purpose and objectives. The authors provide the Nine Whys¹ questions to focus in on the purpose. They suggest asking the questions at the beginning of a meeting or workshop to help get everyone on the same page. A helpful tip for communications planning was to share the meeting outline with not only with the group of participants, but also with individual participants ahead of time (p. 40). Then follow-up with a group reminder the day before. Although this is quite labour intensive, it is certainly worth it in terms of getting the most out of the meeting time.

Meeting Rules

The third is setting meeting rules. This is something, based on my own experience, that is oft overlooked but can make all the difference to making sure that all participants feel respected and that their opinions are valued. So, for example, a rule I could get behind is not speaking over people. It is something that happens frequently in web calls and can be circumvented by writing in the chat or having a notebook to hand, “save that important thought, don’t interrupt someone else’s flow”. Of course, folks can run on too long, so I have always found it helpful when chairing forums to ask that contributions are limited to two minutes. Sometimes there are technology focused rules like putting your smartphones away, as suggested by the authors (p. 29). I am less of a fan of this, as if folks are tempted to look at their phones, then this tells me that the flow of the meeting is not optimal. I take note of this, move on and improve the next iteration of the meeting.

Online Meetings and Workshops

The authors, Douglas and Fitch also note that online meetings and workshops take double the preparation time and this is certainly true based on my own experience. However, it is also possible, like a real room to be a “Meeting-Room Architect” (p. 31). In a real room this can be about arranging furniture or creating zones, something I worked on in the past through the likes of practice sharing café events and a la carte style technology taster sessions. In the virtual space this can be about the interaction between tools, so Microsoft Teams might be the room, Mural might be the participant’s own desk, Word Online might be a flipchart. As I have talked about in previous blog posts and as is starting to emerge in tools like and , the idea of a fictitious floor plan can also be a helpful McGuffin (or trigger for the plot) for an online meeting. As part of this the Douglas and Fitch propose a video orientation for online meetings and workshops, which participants watch in advance. Having tried this out, the best approach was to create a TikTok-style video with very brief steps and lasting no more than 90 secs. Otherwise, folks won’t watch it. Creating annotated screenshots or short video clips with a voiceover is a good way to stay on track.

As an aside, one of the most transformative sessions I ever attended involved sitting on chairs looking down as a single iPad on the floor and imagining it as a window (kudos to at UX Camp Brighton circa 2015 for this one). This proves that it is not always about furniture and stationery but also about imagination.

This online orientation video is too long (3:37mins). Just an example.

Do the work in the meeting

One of the key messages in the book is the idea of doing the work in the meeting. This is something that has always been a facet of my own approach when running any type of meeting, large or small. Another key concept is ensuring that the people in the room want to be there, so that the people in the room bring the right kind of energy. Therefore, making meetings optional, but providing clear communications prior to and after the meeting helps to counteract what the authors call, “FOMO” or Fear of Missing Out (p. 132). I have tried one of the recommended methods, providing a story of a meeting as a debriefing method using a story spine, number 4 on the as devised by a former artist at Pixar. It was inventive, but a little bit tricky to tweak for my meeting (which was a nationwide accessibility meeting), but certainly quick to digest and celebratory in tone.

Extra Features

The and the on the Voltage Control site are very helpful. I used the with UXUp meet-up group participants. The activity involves asking participants to recommend books, write a mini-review and upvote other folks’ suggestions. I also added a final element which was to ask participants to indicate which book they would try to read soon. I will use this as a sharing exercise again and next time I will allow podcasts and videos in addition to books, to get a fresh list of materials not only the staples. You can view the here to give you a flavour.

What did not work for me

As an educator, some of this book felt like reinventing the wheel. This is because a key idea in contemporary education is “constructive alignment” (Biggs, 1999), this is the notion that in order to stoke student motivation learning needs to be mapped to the learner’s goals. Thinking back to the , mapping activities to a set of objectives is very similar to creating a lesson plan which maps to a set of learning outcomes. Learning outcomes are essentially an educators’ objectives for their students, which sit under the larger umbrella goals of a programme of study. This book made me want to get educators and facilitators into a meeting design face-off, who would do it better? My guess is that a good facilitator from a design background and a good educator have a lot in common, something that Diana Laurillard so eloquently explored in her seminal book, Teaching as a design science: Building Pedagogical Patterns for Learning and Technology (2012).

This got me thinking about all the hidden work that educators do, or the soft skills, and I started to list them. Once I had a sizable list I thought, maybe every design team could benefit from having a former educator, or career-break educator, on their team because this hidden work yields demonstrable value. If you would like to see , I have included it below.

Conclusion

Ultimately this book succeeded on several levels. It helped me consider best practice, it helped me reflect on my own practice, it enabled me to try out new methods, and it stimulated an emotional response of very mild irritation.

I give it a solid 4 out of 5 moons.
🌕 🌕 🌕 🌕 🌑

I recommend this book for a variety of workplaces and contexts. It provides actionable strategies for iteratively tweaking team and company culture.

“…restructure the world we live in in some way, then see what happens” Ferguson and Fitch (2021, p. 158) as quoted from , a Science Fiction writer.

References

Biggs, J. (1999) ‘What the student does: teaching for enhanced learning’, Higher Education Research & Development, 18(1), pp. 57-75. doi:10.1080/0729436990180105.

Ferguson, D. and Fitch, J. (2021) Magical Meetings, Reinvent How Your Team Works Together. USA: Ideapress Publishing.

Laurillard, D. (2012) Teaching as a Design Science: Building Pedagogical Patterns for Learning and Technology. London: Routledge.

Fiona’s List

Or why a talented educator may be a boon to your design team.

A good educator aligns every session with bigger picture goals.
Educators usually have at least three back-up plans.
Educators are used to being challenged. There is an art to knowing when to deflect, acknowledge and move on, and when to challenge an idea which is unreasonable or may mean that others in the room are excluded or made to feel unwelcome. Educators have to deal with these scenarios every day.
Who is in the room? The session, whether led or facilitated, needs to work for the people in the room. Understanding participants’ needs and motivations is key to success. An educator will think about who is in the room and why they are in the room.
A good educator spends a lot of time thinking about the language they use and adjusting it for the audience.
Educators are expert at subverting time and space. A good educator is a storyteller, a challenger, and a sounding board rolled into one. An educator can set the scene for a space and therefore get people into a more flexible mindset, ready to explore.
Educators are driven to learn, by a desire to share what they have learned.
Educators have many methods to draw from to breakthrough even the toughest shells.
Educators persistently innovate and learn from failure. A core facet of any educational training is learning how to reflect on your own work.
Educators have had to learn the hard way about when and how to take a step back. So facilitating group work is a key example where you need to provide the core ingredients and then let the group mix them together themselves.
Educators communicate in advance to ensure that people feel included and forewarned of the task and expectations.
A good educator pilots or tests a task themselves before asking students to do it.
A good educator can also wing it in a situation where preparation has not been possible. An educator’s version of winging it is based on a wealth of experience. In fact you won’t even know they are winging it. Sometimes these are the best sessions for participants as over preparation can be a ’thing’.
Educators can read just about any room. Reading between the lines in terms of empathy. An educator can tell when something else is getting in the way of the task and can find a way to help.
A good educator can build a rapport with anyone, to find out what their motivations are and what they want to learn.

A really helpful page on using the . ↩︎

Striving for accessibility - Eval pt 1

Thu, 19 Jan 2017 00:00:00 +0000

Part 1 of my final evaluation. This entry outlines key decisions that I made regarding accessibility towards the end of the development period. I am writing and publishing it retroactively as it as represents a very large amount of thinking and work, which I kept notes about as I went along.

Based on observation

Based on looking at a large number of NHS and governmental sites, referenced in former posts I realise that accessibility is crucial, perhaps even more than your average portfolio site. For example, looking at NHS England (2017) site I see that they offer a text-to-speech service. Based on experience in my day-job working with software vendors, some of these solutions can be quite expensive. It was however important to me to make the site as accessible as possible and that has meant some sacrifices along the way.

Keystone texts

While engaging in this in-depth investigation into the accessibility, I found myself referring to the following keystone texts.

- UX accessibility specialists an amazing resource
- a frequent go-to of mine

I feel like I have only scratched the surface with the WAI-ARIA roles, but based on testing I feel that the site is accessible as I could get it within the allotted time. In the end I found a blog post on the subject by a rather brilliant developer, Aaron Krauss (2016) who did a great job of how to practically use certain ARIA labels and roles. What I did find is that there is quite a lot of redundancy in the code, but you need to have it there as the screenreader doesn’t necessarily pick up the semantics in the page construction as you might intend. Here is a video of my screenreader testing in action with tab key only - tabindex (Mozilla Developer Network, 2017)

What the font?

I conducted some reading (Nielsen, 2002; Martin, 2009; Franz, 2014; ) around legible fonts and font sizes and optimal line height. I have tried my best to work with the best practices, although that does get tricky with the mobile screen size. However, the attention that I have paid to optimising the CSS stylesheet for plain readers should help those who use accessibility features on mobile devices. Added a fix to the superscript I found a very helpful snippet for fixing line height for superscript (used for references) and subscript. Thank you to the -ever helpful- CSS Tricks site (Coyier, 2009a). Contrast As much as I loved the white headers along the timeline the contrast was not sufficient. The colour scheme is themed around blues and purples and unfortunately white on blue doesn’t comply with WCAG 2.0 unless the blue shade is very dark or the white font is very large (Snook, 2015; WAVE, n.d.).

The accordion had to go

Upon testing the tab-key only navigation I realised that there was no accessible way (that I could muster anyway) to navigate the accordion (Mary Lou, 2012) and for that reason it had to go. I added two simple tables, which I was trying to avoid, but as they area features comparisons this use us permissible. I was not using the tables for layout, but for the display of information in a standardised way. After the fact I found this accordion example at codepen.io which might have been better, but not without a lot of work:

Sprite fun

I got my sprite on and added sprites for the device images. The device images were drawings that I created in Adobe Illustrator based on photographs. All the photos were apart from the image of jeans, which I have listed below. This was added as an image through the CSS and aria-labelled for descriptive purposes.

The complete sprite for the devices in all of its glory. Photograph used as the basis for illustration of fasten/clip wearable - by is licensed under CC0 images sources from Pixabay:

Fixing the tab svg

I replaced the svg tab to be a proper thing rather than the Frankenstein’s monster-like CSS creation . Once again I referred to the excellent CSS-Tricks (Coyier, 2013) and Mozilla Developer Network resources (2016c), as well as the Implementing Responsive Design book from the reading list (Kadlec, 2012).

Asking myself questions

I tried my best to standardise all the units in the CSS although if I were to do it all again with hindsight I think that I might design my grid to work with ems or rems (once they are widely compatible or older browsers fall out of use). I’m sure that I have missed things in spite of several thorough read-throughs. It all validated okay. CSS code block structure: e.g. div class or id - this resembles the layout of a div .div { display: block; position: relative; width: 90% height: 60% color: #000; margin: 2% auto 2% auto padding: 2% 4%; (shortenings used where possible) } e.g. typography class or id - this resembles the layout h2 { font-family: “Helvetica Neue”, Helvetica, Arial, sans-serif; text-align: center; font-size: 1.5em; line-height: 1.25; font-weight: 300; } In the HTML where white-space pre-line formatting was needed for the Goals and the references sections, I included comments to help indicate why the formatting was different in the markup. Also regarding the CSS as I was going through it, to weed it a bit, I asked myself a series of questions to help determine which units to use and such. I have included these below.

Is it text? = ems
If it moves it is em or %. If it doesn’t or cannot move it is pixels
Is it in a column in the grid - then margins and padding are percentages (unless there is a very good reason for them not to be)
Is it in the grid - then margins and padding are percentages
Is it used in the html? No, then get rid of it Could it be consolidated in any way? Does it share the same values as another class and/or id?I would have liked to do more on this, but I ran out of time. Did my best to do it as I went along.
Does it need to be a negative value (particularly in the media queries)? Then it is in ems.

Rationale:

When it is something that needs to have set dimensions such as a button, I am using pixels.
For text I am using ems to ensure compatibility with older browsers
For table related items and blocks which reside in divs I have used percentages.
Used hexadecimal shortenings when it made sense to do so and it did not change the hue of the colour (three digits rather than the standard 6). I prefer digits rather than word descriptions, due to colour precision.

Media queries

Did a lot of work on these, again I found the Implementing Responsive Design (Kadlec, 2012) and the Introducing HTML 5 (Lawson & Sharp, 2011) books particularly helpful. I also added a arrow keys image and tooltip to help explain the navigation of the timeline. You will notice for the tabbed navigation of the site in the screen reader demo that the timeline is skipped over initially and I added to the JavaScript in order to allow the tab key for navigation in addition to the arrow keys. The arrow keys allow for greater freedom though, as once you have started tabbing through the carousel/timeline, you cannot get out of it with another tab press. Thus leaving it to the end and this is something for me to raise with the original developers to see if they can address that in future versions of the widget.

References

Coyier, C. (2009a, August 10). Prevent Superscripts and subscripts from affecting line-height

\[Blog post\]

. Retrieved from

Coyier, C. (2009b, October 24). CSS Sprites: What they are, why they’re cool, and how to use them

\[Blog post\]

. Retrieved from

Coyier, C. (2013, December 4). SVG tabs (using an SVG shape as template)

\[Blog post\]

. Retrieved from

Donut. (2011). Re: What are the most common font-sizes for H1-H6 tags. StackOverflow website. Retrieved 19 January 2017, from

Franz, L. (2014, September 29). Size matters: Balancing line length and font size in responsive web design – smashing magazine

\[Blog post\]

. Retrieved from

Kadlec, T. (2012). Responsive Media. In Implementing responsive design: Building sites for an anywhere, everywhere web (pp. 95–127). Berkeley, CA: New Riders Publishing.

Krauss, A. (2016, September 8). ARIA roles and attributes: How to actually use them | Aaron Krauss Retrieved from

Lawson, B. D., & Sharp, R. (2011). Introducing HTML5 (2nd edition) (2nd ed.). Berkeley, CA: New Riders Publishing.

Martin, M. (2009, August 20). Typographic design patterns and best practices – smashing magazine

\[Blog post\]

. Retrieved from

Mary Lou. (2012, February 21). Accordion with CSS3

\[Blog post\]

. Retrieved from

Mozilla Developer Network. (2015, July 23). Using the aria-describedby attribute. Retrieved January 19, 2017, from Mozilla Developer Network website:

Mozilla Developer Network. (2016a, December 15). WAI-ARIA basics. Retrieved January 19, 2017, from Mozilla Developer Network website:

Mozilla Developer Network. (2016b, November 17). CSS values and units. Retrieved January 19, 2017, from Mozilla Developer Network website:

Mozilla Developer Network. (2016c, December 3). Background-position. Retrieved January 19, 2017, from Mozilla Developer Network website:

Mozilla Developer Network. (2017, January 16). Tabindex. Retrieved January 19, 2017, from Mozilla Developer Network website:

NHS England. (2017). About NHS England. Retrieved January 23, 2017, from NHS England website:

Nielsen, J. (1996, October 1). Accessible design for users with disabilities

\[Blog post\]

. Retrieved from

Nielsen, J. (2002). Let users control font size

\[Blog post\]

. Retrieved from

Snook. (2015). Colour Contrast Check

\[Computer software\]

. Retrieved 19 January 2017, from

Stanford University Online Accessibility Program. (2016, August 1). Screen reader testing. Retrieved January 19, 2017, from Stanford University website:

W3C. (2016, October 27). Accessible Rich Internet Applications (WAI-ARIA) 1.1 W3C Candidate Recommendation 27 October 2016. Retrieved January 23, 2017, from W3C website,

W3C. The Roles Model. Retrieved January 19, 2017a, from WAI-ARIA website:

W3C. WAI-ARIA role definition model - image. Retrieved January 19, 2017b, from WAI-ARIA website:

W3Schools. CSS Tooltip. Retrieved January 19, 2017, from w3schools.com website:

Watson, L. (2014, August 4). Using the tabindex attribute

\[Blog post\]

. Retrieved from

WAVE web accessibility tool.

\[Computer software\]

. Retrieved January 19, 2017, from