Repository navigation
UX Writing (and Copywriting) Foundations for Clear & Concise Language #53
Replies: 3 comments 4 replies
|
Pinging @NoRi2909 in here as you may find this also interesting |
|
Hey @felinusfish . Thanks for the discussion start! Not sure if you saw these discussions around the same issue. Here and here. To address these myself and Marcin have started an audit of where the dialogues live, what we expect to do and what they do. We have opened a ticket here #52 Currently Marcin is running a review of where we can add an 'escape' to close and how that would change behaviours. I am doing a review on 'enter' to confirm. As for what help is needed - literally finding the examples where it hurts the most! |
|
But I considered creating a separate discussion that's far more general, as a way of organizing the initial push for a uniform rewrite, rather than inconsistently improving parts of the interface that may eventually end up needing to be redone anyway because the writing standards have changed. So if anything, I should actually probably create a new issue in the GitHub regarding the introduction of writing guidelines, and we can all work through building a document collaboratively that can eventually become the "standard of quality" for future reference. |
|
I'm pretty sure some of these chunks fall into the areas of HA+OHF that are my responsibilities. Immediately the User Onboarding Process. I'm wondering if there's guidance on UX writing we want to follow? I've used accessibility guides before and also https://www.oecd.org/en/about/programmes/piaac.html as a standard but should we have a list of what we use for UX writing? |
|
Right. The onboarding process is copywriting. It's probably more in your ballpark, but I don't think you should entirely shy away from any feedback even if that's the case. 😁 As for guidelines, I think we should define it as we go based on our needs, e.g. how we should refer to the user, alongside language used depending on who is interacting with a particular part of the interface. And of course, we could totally still use parts of other guidelines to fill in for how we should write. |
|
There are some documentation guidelines written on de developers website |
|
This is a good starting point. 😄 Perhaps we should make a new page in the developer documentation then, for the UX writing style guide? |
Uh oh!
There was an error while loading. Please reload this page.
To make it easier, we can refer to this concept as "CCL" (which just means "Clear, Concise Language"). Some work has already begun; an example of this is the new delete dialog for deleting an entity. We spent some time ensuring that it was more comprehensible for the average user, including how its surroundings may be affected. This sort of improvement is constitutional to an interface that will be used by individuals, many that may not even have intimate experience with technology, to be able to configure their smart home experience.
Initial plans
Starting small is the correct decision here. Taking existing text within the interface, and re-establishing the writing direction (by defining strong guidelines) in order to improve the user experience. UX writing is the difference between good and great interfaces.
We can begin with chunking into smaller areas. Here are a few "chunks" of rewrites which we could focus our attention on.
However, this is not a final judgment of how the UX writing tasks should be designated, and it could look far different to this, such as a task for UX writing being entirely replaced by a full UX overhaul. There may also be more that may need to be considered in this list that I was not initially aware of, in which case, it will also be worked on.
If everybody does not have any concerns with slowly tackling the mountain of workload, I would be willing to start with rewriting parts of the Settings page, such as the descriptions of each subpage, like the "Automations & scenes" which has the not-very-descriptive description of "Automations, scenes, scripts and blueprints."
All reactions