Hello. My name is…
Here we are in N – “what’s in a Name?”, part of the A to Z of Accessibility: Power Platform Edition. In this post we’ll be looking at the importance of Naming in what we develop and build. We’ll consider why naming is vital for accessibility and why it is just good dev practice.
My name is Inigo Montoya, you killed my father, prepare to die!
William Goldman, The Princess Bride
This post is particularly relevant to Power Apps, Power Automate, and Dataverse.
So, what’s in a Name?
Any developer loves building to standards. OK, that’s not true. Any developer picking up other people’s code hopes that it’s been built to a consistent standard. Do as I say, not as I do.
Consistency can be seen as the enemy of efficiency when it comes to speed of development. It has massive benefits though in terms of fixability, handing over, documentation (yes, I said it), and understanding.
Every developer has their own way of writing code, customising objects, creating elements, all that jazz. Along with commenting (I went there again), the naming of everything is so important.
For accessibility naming is even more important. Whether it’s as an end user or as a developer, if you use screen readers then naming is vital.
Call me that one more time…
A point that I’ve made in every talk on Accessibility, is the use of Pascal Case or camel Case within hashtags. This is capitalising the first letter of each word (Pascal) or just every word after the first (camel). The reasons for this are to make them more readable for people with dyslexia, poor vision, or using screen readers. Hashtags that are all lower case are difficult to read, and end up garbled and jumbled.
In the same vein, we should ensure that all objects are named using Pascal or camel Case. The starting point for this is database (Dataverse) naming, including schema names and display names. We then move on to naming within apps and flows – and anywhere else where we apply names to things.
In Power Apps this means variables, screens, controls and components etc. In Power Automate we’re looking at triggers, actions, steps, variables and more. Not forgetting things like plugins, plugin steps, functions, libraries and all those good things.
Mike, Micheal, Michael, Mick… Mark?
My name is Micheal. It’s spelt that way. Do people spell it properly? Rarely. As a result I decided to go by Mike at the age of 19. I get messages where people think I cannot spell Micheal so they “change it for me”. I also get called Mick (blergh), Mikey (only one person gets away with that), Mickey, and regularly called Mark (!). It’s messy, and it’s really annoying.
At one place I visit they have me registered as Mike, Micheal, and Michael. Each one with a different photo of me. It’s a lottery which one I’ll be issued when I go there.
Consistency is NOT the enemy of efficiency. Not when you consider the end game and the benefits. When developing in the Power Platform there are a number of people who have come up with some development standards/guidelines/frameworks. I like a lot of what they contain, but not all. There are bits I would tweak and modify, but that’s because we all have different approaches.
The key is to agree a standard approach. Document it. Review it. Ensure people stick to it. To help with this you can take a look at the following frameworks and sites for some proposed approaches:
- Power Automate Artemis Framework. Written by my good friend Matt Collins-Jones. This framework has just seen version 2 released and presents a great way of working in Power Automate.
- Power Apps Pumpkin Framework. Written by the amazing Keith Whatling. This takes the Microsoft recommended standards and expands on them. It’s not had any updates for a while, but still has some solid nuggets of gold in there.
- Microsoft Canvas Apps Coding Standards and Guidelines. Another one that hasn’t been updated for a while but the fundamentals still apply.
If you work at a consultancy or larger organisation there may be standards already defined. Often I find that people talk about needing them, but not having them. I definitely recommend reading the above links and coming up with a comprehensive guide. One that most definitely incorporates the accessibility elements of course!
Thank you <insert name here> for reading
Hopefully this has provoked some thinking and provided starting points in your naming journey. “What’s in a Name?” is part of the “A to Z of Accessibility – Power Platform edition”. Click here to go to the introduction article which includes a table of contents. You can also check out the Accessibility section of the website from the top menu or by going directly to the category page here.
Content in this series is © Mike Hartley. I am happy for folks to quote or reuse snippets (with attribution) but please let’s not go all Clone Wars on this. This has taken a lot of work to compile so please do not copy whole sections or I may have to set Jar-Jar Binks on you. If there are any corrections or suggestions, then please use my social links to contact me. I am always happy to add additional content and remarks with full credit given. Likewise, these pages will evolve as my learning and understanding grows, so make sure to keep this bookmarked and check back every so often.