I’m going to start with quite not politically correct, yet very much true statement. We, the developers, get sick and tired, as soon as we hear “accessibility”. There is a simple reason behind it. Often times the word “accessibility” is used very wrong. Many people think that accessibility equals aria labels and making you app usable by the blind. But this is only a small fraction of accessibility.

So what “accessibility” is?

Let’s start the other way round and explain disability. We all know disability as a permanent state where a body doesn’t have all motor skills, but that’s again, just part truth.

Looking at the picture above you probably already are aware that at some point of our lives we’ve all experienced some sort of disability. Either temporary (broken arm) or situational (occupied hands). Cambridge dictionary defines disability as “an illness, injury, or condition that makes it difficult for someone to do some things that other people do”. Taking this one step farther, physical disabilities are not the only ones that exist. Any learning impairment, like dyslexia, is also a disability, but again this one in a permanent one. Taking it a step back to temporary / situational mental disabilities as well as definition “difficult for someone to do things that other people do” even not knowing a language well, regardless if it’s due to some learning impairment or that language not being one’s native tongue.

For all this, I want to introduce a better way of saying “accessibility” namely, as the title of this article states, “universality”. To me this is a better term, as we all do want our apps, documentations, articles be universally accessible by as many people as possible, regardless of their physical location and their own ability to access your content.

What “accessibility” really is, is an answer to a question “Can I get access to information?”

Here, I don’t want to focus on good HTML structures or aria labels, there is plenty great articles about that. I want you to improve your way of thinking about accessibility. I want you to make information as much accessible as possible.

Touch

We’ve all seen people, usually older, using styluses to navigate their phone. Some of us might even laught, but have you ever wondered why they do it? It’s simply because they have hard time taping on items they’d like to navigate to. This happens because, as you get older your motor skills worsen, but to be completely honest with you, I sometimes struggle to tap on the thing I’d like to. Why? Mostly because of bad UX. See it for yourself.

Looking at this map, at the first glance you realize that, tapping on the correct map pin is nearly impossible. A very simple fix for this may be grouping some nearly located pins into one that would cause the map be zoomed in to that area with nicely spread pins.

Generally with any touchable / clickable area a great rule of thumb is “could I tap it”. The more touchable area the better, but the minimum should be 48dp (or 48px / ~3rem) [what is a dp?] .

Contrast

Here I won’t say a word about colorblindness, nor any other permanent disability. Just look at the picture below.

Screens get better and better in terms of brightness, but if you never had an issue with sun making your screen unreadable, you probably live in the dungeon. This one is a struggle for every single person in the world every single day. When you create your app with bad contrast or some unusual fonts, you make it a lot worse for your users to get the information they need from you website.

An excerpt from “Refactoring UI” by Adam Wathan & Steve Shoger says:

By designing in grayscale, you’re forced to use spacing, contrast and size to do the heavy lifting. It’s little more challenging, but you’ll end up with a clearer interface with a strong hierarchy that’s easy to enhance with color later.

Leave handwritten fonts for logos, leave weird colors schemes and just make it simple. Simple is better.

Language

Simple is better, but what’s even more better, especially with language, is plain. I left this one to the end on purpose. This is a point relevant not only to copy writers or developers, but honestly to everyone. Ever written documentation? Procedure? Email to employees? A Slack message? You need to understand that plain is better. And now plain language is also an ISO standard.

I said earlier that accessibility is the answer to “Can I get access to the information?” question. What is better for that than a language. A language is the key to get out message across. Regardless of what that message is.

If English is your native language, you are in a better position, as majority of the web is in English, but keep in mind that there are millions of users that either know English as a second language, or don’t know it at all. Think what is easier to translate. I personally worked with an app where where you could have peers instead of friends, principals instead of leaders and articles could be appreciated, not liked. People sometimes think if they do things different, they will be better, but in communication this is not the way.

If you’re happy and you know it, clap your hands.
If you’re happy and you know it, clap your hands.
If you’re happy and you know it, and you really want to show it.
If you’re happy and you know it, clap your hands.

We all know this nursery rhyme, it’s one of the most popular ones that is used in English as Second Language teaching as well. If you look at it again, what do you see? There’s a lot of repetition and simple words.

This brings me back down the memory lane when I was studing English teaching. We were to create a children Christmas story, but the goal was to use no more than 30 different words. Tough challange, but has its point. Same as the nursery rhyme. That’s how we learn and understand language the best. With simple words and repetition.

An average 5–6 year old child knows 2500–5000 different words, by the age they’re 9 their primary set of words is around 5000, and secondary around 10000. If you think it’s more when you’re an adult you’d be wrong. It is basically this for the rest of our lives. We tend to use same words over and over again, and you know what? It is good! Using complex and unusual words does not make us sound smarter. It’s just making us less understandable.

Keep it simple!

Look at the examples below, they both mean exactly the same, but which one is actually understandable?

The recently implemented categorical standardisation procedure on waste oil should not be applied before 1 January 2015.

or

Do not use the new waste oil standards before 1 January 2015.

What is more, when we use longer words (8 or 9 letters), users are more likely to skip shorter words (3, 4, or 5 letters) that follow it. People just don’t read one word at a time. They bounce around, especially online, and anticipate words, subconsciously filling them in. You don’t need to read every word to understand what is written. It is estimated that people can drop around 30% of text and still understand it perfectly. An exception from that rule are people with learning disabilities who read letter for letter, and do not bounce around like other users. However, keep in mind that they cannot understand a sentence if it’s too long!

THIS IS MEGA IMPORTANT

Capital letters are harder to read. By around 13 to 18%.

Capital letters were great when you started learning to read. At first, you might sound out every letter, but you did not understood the concept of lower and upper case by the age of 6. At this point instead of letters, you start recognising the shape of words. This speeds up comprehension and speed of reading.

People do not read words, people recognise the shape of a word and understand it. It is a lot faster that way, and we all value our time greatly.

Online vs Paper

Users read very differently online to paper. They do not read top to bottom or even from word to word. Instead, users only read about 20 to 28% of a web page. Think of a letter F, that is a shape in which users browse content of a web page. they want to complete their task as quickly as possible, so they skim across the top, then down the side, reading further across when they find what they need. So, Keep it Simple. Give access to the information as quickly as possible.

Learnings?

• be concise — simple and shorter is better. Be understood, especially when you write procedures.
• address the user — use active voice
• DO NOT CAPITALIZE — unless it’s logo
• use text version of signs — and is easier to read and understand than &, same with dates use to instead of —
• Be gender neutral — use plural “they”

And make sure you use plain language, see https://www.gov.uk/guidance/style-guide/a-to-z-of-gov-uk-style for full list of words that can be easily replaced. But to give you a few to avoid that I’ve seen use quite extensively:

• collaborate, use ‘work with’
• empower, use ‘allow’ or ‘give permission’
• key (unless it unlocks something), usually not needed but can use ‘important’ or ‘significant’
• streamline, use ‘simplify’ or ‘remove unnecessary administration’

I hope that now you understand better what is the goal of accessibility. It’s simply to allow as many users access the information you want to provide in a way they can understand it as you intended. I believe you want that too.

Artykuł Universality, because accessibility is not about disability pochodzi z serwisu LEOCODE.

We are joining the AI revolution!

At LEOCODE we’ve been building internal tools for last few years. We wanted to simplify processes and address our own needs.

With the chatGPT and AI revolution we decided to go a step ahead. We created LEOCODE AI – a toolbox full of inspirations (tools, prompts etc) for every business owner, where you find a suitable tool, test it in action and apply to your needs in different areas (development, marketing, sales etc).

This site was done in a few hours with NoCode tools like Softr + Airtable. Seriously. No developer was involved. We will add more relevant content every week.

Plans for the future

We would love to gather like-minded people and explore some possibilities together. Join our WhatsApp group and share some inspirations. Let’s sit together in the front seat of this revolution and build some practical tools.

In upcoming weeks we will be adding more micro tools (made by LEOCODE), inspirations and some discussions. We will shape the vibrant community and give people voice.

What’s in it for me?

A lot. Join the ride. We will test and analyze different AI tools, that can boost the business and development. If you have some challenge or problem you would love to address let us know. We won’t build it for ourselves, it’s for you!

So, ready to jump to the Rabbit Whole and explore?

Let us know, we will be more than happy to guide you here.

Artykuł LEOCODE AI is born! pochodzi z serwisu LEOCODE.

Why even bother?

Would you like to be replaced by AI? Well, I assume you don’t, do you? Therefore, better move yourself out of the programming comfort zone and try to understand the business world.

Following DDD will help you to develop yourself into becoming a Technical Business Partner. Technical Business Partner is an IT professional, who fully understands the business she’s building. This means not only re-actively producing software according to business needs, but also being business-proactive. Thanks to this we are able to advice our clients regarding new business opportunities, build ubiquitous language and find inconsistencies in the existing business processes. With the advent of solutions such as ChatGPT, transformation from developer to Technical Business Partner has become more important than ever before.

At Leocode, we hire only the best Technical Business Partners that strive to fully understand true business requirements of our clients.

Domain – the problem space

Domain is the problem space of the business we are creating. Think all the complexities you usually experience when building software, but without any technical details.

Domain is what business is talking about all the time.

Solution space

Model we are creating belongs to the solution space. Defining strategic boundaries between modules, writing code that speaks business language, designing components according to true business requirements – it’s all part of the solution. Even sticky notes or tests are part of the model.

Ubiquitous Language

Our model should speak the same language as business. However, business rarely speaks exactly the same language. The same concept in accounting department might mean something entirely different by sales. It shouldn’t surprise you, though. Business is usually way more complex than we initially think. Context is the king.

Unfortunately, often naming is not consistent in the same context. It might work well up to some point for business, but is unmanageable when writing actual code. Therefore, we should aim to define the common language, used both by developers and business, given we are talking within the same context.

For example, let’s imagine we are working for a tree plantation. Within the “Growth” context, a Christmas tree is just a tree that needs some specific requirements regarding watering, soil, space, sun etc. At the same time, “Sales” department talks about number of orders and might be aware of an increased demand in December, so they can apply special Xmas “discounts”. On the other hand, for marketing, Christmas tree is nothing more than a product that should be aggressively advertised starting from late November.

It might happen that the “Growth” department inconsistently names important business concept. Some use term “tree”, others “Christmas tree” while for someone else it’s just a plant. They all mean the same thing, but name it differently. While it might be acceptable for human beings, it definitely messes things up and therefore is rather unsuitable when writing code. In such case, we should create the common language, that is being consistently used by business in everyday communication, documentation, tests and production code.

This common language is often named “Ubiquitous Language”.

Strategic patterns

In the previous section we’ve talked about language and contexts. Now, these contexts need to communicate somehow. With the growing number of contexts, it can be hard to manage all the relationships. This problem can be solved by applying DDD strategic patterns.

There are multiple strategic patterns we can apply when integrating contexts. For example:

• Customer-Supplier

• Open Host

• ACL

• Conformist

• Separate Ways

• Shared Kernel

• Partnership

• Published Language

We won’t cover all the details here, as it’s out of scope of this article. We can use Context Maps to draw all the relationships between contexts of our domain. That’s how the context map looks like.

However, strategic DDD is more than just context maps. It’s equally important to organize teams around contexts identified in the map. Thanks to this, we can explicitly define relationships and boundaries between teams. For example, we might notice we are overusing the conformist pattern, while we should follow Customer-Supplier between specific teams.

Strategic thinking can also help us to identify layers in our domain model. Again, this is something we should cover in a separate article.

Tactical patterns

Strategic patterns help us to understand why and what we are building. Tactical patterns, on the other hand, are useful to answer how we want to implement our model.

Tactical patterns are usually easier to understand for developers, as they can be applied immediately to the code. Some popular tactical patterns include:

• Aggregate

• Domain Service

• Domain Event

• Policy

• Repository

• Domain Factory

• Module

You probably might’ve heard about these patterns already and maybe even tried some of them. These patterns are usually the first thing developer tries when learning DDD.

However, based on my experience, we shouldn’t be forced to look for these patterns immediately when we start a new project. When you start facing some problems, the need for these patterns will become evident.

Also, don’t forget about strategic patterns – these often have much bigger impact on the project.

DDD vs OOP

Some might say that DDD is the OOP done right. I can’t agree with this. DDD doesn’t enforce you to use OOP. You can implement most of the tactical patterns using FP, for instance. When you follow DDD, you are concerned about behaviors, not structures. For example, aggregate is nothing more than something to guarantee some business invariants. It doesn’t have to be a group of objects. It might be implemented as a function, simple CLI application, database procedure/constraints or even as a completely separate service. It doesn’t really matter. The big idea is the behavior.

However, one thing remains true. If you decide to use OOP, then DDD will definitely help you to make the best out of it.

Summary

Hope you enjoyed the article. It’s just the first installment of the DDD series. Stay tuned for new content coming up pretty soon!

Author: Mike Wojtyna

Artykuł Domain-driven design pochodzi z serwisu LEOCODE.