During our most recent Lab Day we experimented with App Clips. This new iOS feature, discussed in detail in this earlier blog post, allows potential users of your app to easily discover it and try out a single part of your app, where and when they need it most. In this post I will go into detail on the size limit for an App Clip.

An App Clip should be small, such that it can be downloaded quickly and shown to the user almost instantaneously. To facilitate this, Apple requires an App Clip to not exceed 10 MB, which is not much. At least, it seems so.

To get a better idea of how much this is, I performed a number of small experiments. As a starting point, I followed the Apple guide on creating an App Clip, and created a blank app with a single View Controller (Swift using Storyboards). In its view there was only a single UILabel. The App Clip target shared this View Controller, and based on “Active Compilation Conditions” the label text was set to either “App” or “App Clip”, so that we could determine that the same label yielded different results when shown in either the app or the App Clip.

The size of the App Clip can be determined through archiving the app and then exporting the App Clip, enabling “App Thinning” and “Rebuild from Bitcode”. The result of this almost blank App Clip was only 115 KB. This shows that of the 10 MB pretty much all of it is available for the developer to spend on code and assets.

So let’s pull in Firebase!

We have a number of mobile applications that are backed by this Cloud platform from Google. It provides solutions for authentication, (realtime) databases, storage, serverless functions, analytics, crashlytics and more. The most common and basic dependencies included in a project are Auth and Firestore (database). Without adding any code, I went ahead and archived the and, then exported the App Clip again. Unfortunately this resulted in a very nondescript error message which, despite following various possible solutions, kept popping up.

To avoid spending the entire Lab Day on identifying and properly addressing this issue, I disabled “Rebuild from Bitcode” and finally got the result: 5.2MB! More than half of the budget was spent, and I didn’t do anything yet.

Disabling “Rebuild from Bitcode” could have given an unfair picture of the size taken, so I threw out Firebase and went through the archive/export dance again, disabling “Rebuild from Bitcode”. The original App Clip was still 115 KB, so it might be safe to assume that the App Clip that included Firebase, when rebuilt from Bitcode would not yield a very different result from the 5.2MB.

The exercise of adding Firebase to the project was driven from a need to get some Elevate company data from the Firestore database. That can of course also be made accessible to the app by means of a Firebase Cloud Function called via a HTTP request.

Finally, adding a handful of images and embellishing the UI with some more labels and colors added just a few kilobytes, raising the total size of my first App Clip to a mere 152 KB. Ain’t it a beauty? (disclaimer: this is not the result of an entire day coding 😁)

We just got our feet wet with App Clips and now have some idea of what the 10 MB size limit means. It is very likely that creating an App Clip for one of our apps will not be as easy as Apple’s WWDC videos make it look (it never is) but at least 10 MB is not as limiting as it initially seemed. That is: for native apps. Touchwonders maintains several apps that are built using Flutter, Google’s cross-platform UI framework. As we’ve seen with including Firebase in an App Clip, Flutter too is a framework that claims a considerable amount of space before you’ve even written any code yourself. So much so that Flutter’s current statement is the following:

“This experimental preview currently exceeds the 10MB uncompressed IPA payload size limit and cannot be used in production.”

Let us hope that they find a solution, and one that still leaves some space for our own code.

App Clips Lab Day: The Size Limit was originally published in Touchwonders on Medium, where people are continuing the conversation by highlighting and responding to this story.

Launching an application is often just the first step to success. No matter how well thought out at the drawing board or evaluated and fine-tuned with intended users, it is often only the beginning of a successful mobile application. Many new factors often arise after the initial launch. Users have new wishes, the business is engaged in further optimizing the targets and the usage figures provide new insights. Carefully following-up on these factors can turn a good start into a truly successful app, which is widely supported by users and business stakeholders. Let’s look at an example.

We have developed the Mobile Service Assistent (MSA) for Pon Automotive, which aims to offer incoming customers to car dealers a whole new level of service. Traditionally, service advisors used to serve customers from behind a wall of screens running a plethora of tools. The goal of the MSA was to remove this wall of screens and offer an elegant interface that stimulates customer contact, instead of blocking it. This meant that complex systems had to be reduced to a pragmatic and flexible solution. It also turned out that the perception of quality of an automotive dealership to its customers greatly improves when, during first customer contact, a complete summary of the vehicle status is already captured in a work order, which is the guiding document for all subsequent steps in the service process.

The MSA app was born from this wish. While having a good start, the solution grew into a successful business application last year. You can read how we achieved this below.

How we made the application more effective

We spoke to dozens of dealer organizations, each having its own working process. We analyzed conversations and tried to understand why these differences existed and what values ​​they delivered for the organization. This required a lot of explorations, considerations and iterative research, which resulted in an application that the target audience now loves and wants to use. Below the 5 steps we took to achieve this.

1. Research your target audience: The first step we have taken is to analyze the wishes of users in their work environment. We identified the bottlenecks by means of interviews, observing the workplace and doing surveys. The focus was not on the app, but on the daily interactions between the dealership employees and their customers. By understanding the challenges of both user groups, we got a better idea of ​​possible solutions. This resulted in a wish list for both user groups, the communication between the two, and the follow-up during the service process.
2. Validate new ideas: Now that we have an idea of the wishes in communication, follow-up and reporting between the dealership and it’s customers, we united these wishes in various proposals using sketches and prototypes. As many people only form an opinion about a solution when they can look at it, it is important to validate and refine the ideas in time. In this iterative process, the business can also add focus on specific topics like customer satisfaction or process optimisations. When we receive enough positive feedback from the different user groups, we move on to the next step. We also shared beta versions of the application with employees to keep them involved during the development process.
3. Start small and iterate: During development it is important to start small with clear objectives and to continue developing iteratively. By regularly releasing, we were able to unlock business value earlier and speed up the adoption of the updated application, resulting in qualitative and quantitative feedback. This gives the business the opportunity to constantly make adjustments in the pursuit of their goals
4. Monitor user behavior: Another essential element during development is monitoring how people react to new features. By analysing anonymous data in the app and backend we monitor how users move through the application, but it also shows if KPIs are being achieved. To increase the visibility of this data in organizations, we developed a dashboard on which real-time information is visible at a glance for stakeholders to view. In addition, it is important to give users a channel to express themselves. We made the giving feedback option important in the application to encourage users to provide feedback on the latest developments.
5. (re) activate users: The success of a (B2B) mobile application is not only determined by the application itself, but also by the way it is rolled out. Because this application is for internal use, internal channels were used to announce new releases. Interviews and data analyses also showed that many users used very outdated versions as a reference for their opinion about the application. Because the application has been in use for years, numerous optimizations have been made that many users have not seen. For this reason, we created an overview of all invited users who did not log in recently. We shared an extensive activation email with the user group to explain the improvements and benefits of the latest version and invited them to try the application again.

Achievements

With the above methods, we have been able to achieve the following results in a period of 1 year:

• 380% growth in weekly active use
• 300% growth in number of releases per year
• 250% growth on KPI

Conclusion

This application is a good example of a mobile solution in which the application was designed by the business, while not sufficiently involving the target audience. It’s a great example of how user research is not only important in the development of new solutions, but also offers value for existing products you want to improve. Including research and validation in your way of working can prevent development budgets from ending in a disinvestment. By conducting extensive research and adjusting the way of working, costs have been saved while the effectiveness has been drastically increased in this application that has been running for years.

Are you having trouble achieving the objectives of your mobile application? Contact us today and let us help you.

How we increased app usage by 250% was originally published in Touchwonders on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Touchwonders we find it very important to stay informed about the latest developments in our field of work. One of the ways to keep ourselves up-to-date is by organising internal ‘innovation’ days to dive into something new. Here we focus on new tech that we find interesting and want to learn more about. Examples of previous topics are: accessibility on mobile devices part 1 and part 2, voice, low-code and A.I.

No-coding platform AppSheet

The topic for our last innovation day was AppSheet, a no-code platform that looks promising for non-devs to create mobile applications quickly. As we experimented with low-code platform Mendix in a previous innovation day, we thought it would be interesting to see what a no-code platform like AppSheet has to offer.

The goal of AppSheet is to allow people at work to create custom apps that help them to become more productive. Users are enabled to quickly build mobile applications that can be used to collect, update and/or share data more effectively. The platform supports a large range of data sources like Excel and Google Sheets but also will connect with many well-known parties like SalesForce and AWS. The interfaces are built by selecting a sample application or using components that can be selected in the setup process of an application. A nice extra is that all applications are available as a web app too, which allows solutions to be displayed on computers or connected screens anywhere in organisations.

The goal of this blogpost is not to explain how AppSheet works, but to share what type of apps we managed to build in a couple of hours, and what our opinion is about a platform like AppSheet.

Some example apps

During the day, all team members pitched the ideas they wanted to (try) building after an introduction to the platform. After a couple of mini sprints of 90 minutes we managed to build a variety of simple applications.

1. One of the apps we built allows easy editing of a Google Sheet. This Google Sheet functions as the data input / CMS for a mobile application one of our clients is using. The idea was that our client would be able to easily edit their CMS from anywhere by allowing them to do so through a mobile application. The result was an app that showed the product data after selecting a photo of the product in a list. As product photos are not present in the CMS this makes an interesting combination of 2 data sources which allows app users to quickly identify which product data they want to edit.
2. Another application was more focussed on making data visible. At Touchwonders we gather a lot of data, for example from our mobile applications and backend solutions. But this also goes for our marketing efforts, of which we collect data over many different channels. Combining this data in a mobile app in which you can quickly scroll through some graphs makes trends visible and eases identifying if any action is needed. For this application it came in handy that AppSheet also can run in the browser which made the data look like a dashboard. Not as sophisticated as our own dashboard (link to case) of course, but let’s not forget we are just experimenting with the tool here to see what it can do. Also, this app was built in just a couple of hours.
3. For a research application (link) we developed an AppSheet application that does the same as the previous app for marketing statistics; it makes data visible. This time not in a graph, but entry data categorized by anonymized users. The interesting part of this app is that it allows specific user data to be visualized over time for roles within the company that otherwise would not have access to this data. This try-out app sparked a whole new conversation on how to improve our current solution by involving new user roles. For us, triggering new insights and ideas when experimenting with technology makes our innovation exciting every time.

Conclusion

Although we just scratched the surface of the possibilities of AppSheet, the power of the tool is quite obvious. Making data easily accessible on a mobile application in a very short time, without the help of developers has huge potential for improving processes and effectiveness in any type of organisation. The ease with which data can be turned into an application has really surprised us, and with the variety of data sources that can be connected this is where the power of AppSheet lies.

Of course, there are downsides as well. There is very little flexibility in the actual interface and components. During our innovation day most of us quickly set up an application with a data source; but spent the majority of their time ‘polishing’ the interface. As we experimented with a free tier account the distribution of applications was far from ideal. Most importantly there is lot to be mentioned about the user experience of the applications we delivered.

Touchwonders believes that details make all the difference when creating experiences our users love. We have been doing so for our customers for 10 years now, of which the majority of solutions is used internally or in a B2B setting. However, companies can now move from no-app to an app easily and quickly and experience the power of mobile. For some companies AppSheet will be a welcome tool to improve internal processes. For others, it will show the potential mobile has for their business and some of these apps will outgrow the platform and will be taken to the next level by a company like ours.

If you’re wondering if an app can improve your business or if you want to take your mobile app to the next level, contact us.

A closer look into AppSheet was originally published in Touchwonders on Medium, where people are continuing the conversation by highlighting and responding to this story.

Learn how to report test coverage of Swift packages without using Xcode. By running tests in a Linux machine, you can integrate the process in your CI/CD system using a Docker container.

If you use Xcode, Swift packages are the easiest way to include reusable components of Swift code in your project. You can easily add a Swift package to your project using Xcode, which uses the Swift Package Manager to manage dependencies automatically.

Writing your own Swift packages is a good way of organizing your code base in reusable and easy to maintain libraries.

Think about an API that you access from more than one of your apps. Rewriting a Swift wrapper for each of your projects, without sharing code among them, is not only a waste of work, but also a way to add confusion to your team, which is now switching between different implementations of the same concept. It increases the chance of bugs in your code.

By moving the common code into a Swift package, it becomes the only source of truth for that code, making it easier to maintain.

Testing a Swift package

You can work on a package directly in Xcode, and you can write tests and test your package, as you do with your apps. It is also possible to collect coverage data, using Xcode.

But you do not need Xcode, or even a mac, to work on and test a Swift package. In fact, the Swift ecosystem is open source, and it can be used on Linux to build and test Swift libraries and application.

In case you are not using Xcode, you need a different way to collect coverage information about your test suite, and that is exactly what I will show you in the rest of this article.

Enable test coverage

Test coverage information can be gathered easily. Open your terminal, or console, and change directory to the one containing your package. Then run swift test --enable-code-coverage. After tests are executed, you are greeted with an output like

But where is the report about coverage? The swift test command does not specify it:

You need to search for it, I found mine in [PROJECT_FOLDER]/.build/x86_64-apple-macosx/debug/codecov, and it is in a json format.

Change the output format

If you prefer a different output format, unfortunately the current version of the swift test command does not allow you to change it. But the tool it uses might allow it.

In fact, it does. If we run

swift test --enable-code-coverage --verbose

we notice that it uses the export command of LLVM-cov.
According to its documentation, llvm-cov export has a -formatoption:

-format=FORMAT Use the specified output format.

The supported formats are: text (JSON), and lcov. We can run the same command swift test uses, and change the format:

[PATH_TO_LLVM-COV]/llvm-cov export \      
       -format=lcov \      
       -instr-profile=.build/x86_64-apple-macosx/debug/codecov/default.profdata \      
       .build/x86_64-apple-macosx/debug/[TEST_PACKAGE_NAME].xctest/Contents/MacOS/[TEST_PACKAGE_NAME] \      
       > lcov.info

You can find the correct paths for you when you run swift test --enable-code-coverage --verbose. You also might need to install a version of LLVM-cov.

Generate reports for your boss

From the lcov.info file you exported in the previous section, you can generate a collection of HTML pages to show to your boss. You will need to install lcovfirst. On a mac you can use Homebrew: brew install lcov and then you can run

genhtml lcov.info --output-directory ./coverage/

which produces a 2003 looking website:

What to do with the report

We use the result from the code coverage report to update our GitLab project, both for the merge request

and for the project itself

and, because we do not need Xcode or a macOS machine to collect the information, we can do everything from a Docker container launched from GitLab CI/CD, or using an external CI/CD service, like Bitrise.

Read more

If you want to know more about test coverage for Swift packages, the Swift Dev provides some additional options to the content of this blogpost, while BrightDigit extends the topic to integrating CodeCov.io.

Do you want to know more about our expertise in Swift? Read why we are using Vapor as a server side Swift framework over Kitura.

Reporting test coverage for Swift packages without Xcode was originally published in Touchwonders on Medium, where people are continuing the conversation by highlighting and responding to this story.

Accessibility, is your app / website usable by everyone? (part 2)

At Touchwonders, the apps that we create are never “finished” — we constantly strive to improve them. For one of our latest apps, Elevate, we were wondering if it was accessible for everyone. We tested it with the focus on 7 disabilities: Blindness, Dyslexia, Autism spectrum disorder, Physical or motor disability, Deaf or hard of hearing, Low vision and Color blindness. I wrote this article in two pieces, this is the second. For the first part I would like to direct you to my first article. In this part I will focus on the last four disabilities: Physical or motor disability, Deaf or hard of hearing, Low vision and Color blindness. At the end I will also share our free accessibility cheat sheet.

Disabilities

Physical or motor disability

A physical disability is when a person has an injury or physical deviation that hinders normal physical functioning. This can be very varying, someone could have an arm with a stump instead of a hand or have no legs.

Motor impairment means that you have a loss or limited function in muscle control, movement or mobility. This can affect a person’s ability to walk, control hand movements, maintain a steady posture and more.

These disabilities can limit a person’s independence, especially in a society that routinely designs physical structures without regard to the concerns of people with disabilities. The digital applications can be a way for them to easily connect with the world. We as designers and developers could make our products more accessible for all these users. Physical or motor disability tend to present similar challenges for users who use digital applications.

Findings and improvements

• Provide large clickable buttons
  Small hit areas are hard to press, depending on which physical or motor disability you have. When you have one hand it is harder to reach certain parts of the screen. I have a friend who has an impairment, but that doesn’t mean that I am faster at typing when we’re both using a phone. She uses her nose and stub (arm) to type and my fingers can’t keep up. A touch screen is usable not just for fingers, so to make it easier hit areas should be big enough to be easy to tap.
  
  Xcode already has an option to look at the accessibility of your app, for example the space of a hit area. On the image to the right you can see how to access it, for more information on the Accessibility Inspector click here.
  
  For Elevate, the tool showed a view with a lot of warnings about small hit areas. In the image you can see that, amongst others, the hit area around the About button is too small.

• Think about spacing between text fields
  In a form there should be enough space between text fields as that gives a clearer overview and leaves more space between interactions. As a designer make sure you leave enough space between objects. As a developer make the hit area of textfield’s big enough for easy interaction.

• Have a look at iOS 13
  We tried a feature of iOS 13 that could be useful for people with physical and mobility Impairments. It’s called Voice Control and it allows you to control your phone with just your voice. We were surprised by how well it works and had quite some fun with it. I did not find a similar functionality for Android yet.
  
  If you have a device that runs on iOS 13 you have to give it a shot: go to Settings > General > Accessibility > Voice Control

Deaf or hard of hearing

Deafness refers to an individual who can’t hear anything. Hard of hearing refers to an individual who has a mild-to-moderate hearing loss. They may communicate through sign language, spoken language, or both.

There are a variety of assistive visual technologies including visual alerting devices, technologies to convert spoken language to text, and technologies to support making phone calls.

Findings and improvements

• Add Closed Caption to your audio content
  We currently don’t use videos in our app, but it was still interesting to look into.
  
  To provide subtitles in videos is quite some extra work. It takes considerable time to write clear and concise subtitles for the spoken words and captions for the background sounds. Even though it takes more effort I think we should make video content accessible for everyone. What we noticed by looking at multiple disabilities is that it is important to have options. So don’t show just text or videos but provide the user with options.
  
  We want to add a closed captioning button, just like Youtube and iTunes do, to give the option for subtitles. They hide their CC button under an inline menu but we don’t have as many options so we would like to put it in a more prominent place and hide it after the movie is playing for a while.

• Think about your communication channels
  Don’t make calling your only means of contact. Adding a chat function or offering an e-mail function to your website / app would make it possible for everyone to contact your service.

Because Elevate is a visual app which isn’t using videos to communicate information it is already accessible for deaf or hard of hearing. There are some smaller issues to consider but we didn’t focus on it during our innovation day.

Low vision

Low vision is a condition caused by eye disease, in which visual acuity is at best 70% (but commonly as low as 20% or even poorer) or poorer in the better-seeing eye and cannot be corrected or improved with regular eyeglasses.

Many people with low vision give up reading altogether, because what used to be an enjoyable and easy experience now requires effort. There are assistive tools for low vision like: magnifiers, reading glasses, reading telescopes, video magnifiers and portable electronics.

Findings and improvements

• Allow for dynamic font sizing
  In iOS & Android there are settings that lets you change the text size. This will make all texts in every app bigger, or so we thought. In Elevate our font size didn’t change, why? Because we hardcoded the font size, instead we had to use size categories and then it scaled.
  
  But it turns out that was not the only change we needed to make. When you increase the text size a lot of the text is now either offscreen or truncated. So we wrapped our text blocks in a scrollable view to make sure all of our text was visible.
  
  You can easily try it yourself: Go to Settings > General > Accessibility > Larger Text.

• Combine color, shapes and text
  Don’t just use color to communicate when something went wrong but combine it with shapes and text. The error messages in Elevate already make use of color and text.

• Zoom or Magnification
  A really nice feature of iOS is zoom, on Android it is called Magnification. It will magnify a part of the screen. You can alter the amount by which it zooms in. I introduced this feature to my grandma and now she is using it.
  
  You can easily try it yourself: Go to Settings > General > Accessibility > Zoom (or Magnification on Android).

Color blindness

Color blindness is the common term for a condition where individuals often mistake shades or lose their ability to distinguish colors at all. Women are less likely to have this disease, while for men approximately one in twelve is prone to it.

There are different forms of color blindness. People with deuteranopia can’t see green tones, protanopia takes away the ability to see red tones and tritanopia the blue tones. Whereas people with monochromacy can’t see red, green and blue tones which means they only see gray tones.

Findings and improvements

• Check your design for color blindness
  I was scared to test our color pallet but it turns out that our app is still really usable.

• Try the Sim Daltonism or Stark tool
  A really helpful tool to use while designing is Sim Daltonism, which you can use on your Mac and iOS device. Sim Daltonism lets you visualize colors as they are perceived with various types of color blindness. The window can easily be moved around your screen. We are now using it to check quickly if our design is accessible for people with various types of color blindness.
  
  An old classmate recommended me to Stark (iOS & Android), which is a plugin for Sketch, Photoshop and also Figma, it checks your designs contrast, color simulations and recommends a more accessible color. Both these tools will help you when making a digital product.

• Think about text links
  We sometimes use primary colors to highlight our tappable links. But for people with certain types of color blindness they look exactly the same as the rest of the text, so we should distinguish them more like buttons.
  
  Our links have a primary color so you can see that there is an action linked to it. In grayscale mode it is hard to see that there is an action associated with it. So make your links descriptive.

Our next step: validate our findings with real users.

Now we want to see if all of our changes actually made a difference. We are currently in conversation with a user group that covers these disabilities to test our adjusted application. Subscribe to our channel so you won’t miss out on our next post on this subject.

Cheat sheet

We made a cheat sheet for ourselves and we’d like to share it with you. Our free cheat sheet is a great way to quickly analyze the accessibility of your mobile solution or website, or you can use it as a set of guidelines when designing your product. You can find it on our website at the bottom of the article.

We can also perform an in-depth accessibility check on your mobile app and/or website, if you need help contact us.

Accessibility | Is your app / website usable by everyone? (part 2) was originally published in Touchwonders on Medium, where people are continuing the conversation by highlighting and responding to this story.

Accessibility, is your app / website usable by everyone? (part 1)

At Touchwonders, the apps that we create are never “finished” — we constantly strive to improve them. For one of our latest apps, Elevate, we were wondering if it was accessible for everyone. We tested it with the focus on 7 disabilities: Blindness, Dyslexia, Autism spectrum disorder, Physical or motor disability, Deaf or hard of hearing, Low vision and Color blindness. I will describe how and why we did this testing, our findings on each disability and our next step. I will post this article in two parts, this is the first, in which I will focus on the first three disabilities: Blindness, Dyslexia and Autism spectrum disorder.

How we did it?

We used the accessibility posters made by the UK Home Office as a starting point to research. These posters contain a list of do’s and dont’s to keep in mind when designing for accessibility as well as some more general guidelines. For each poster I added some basic information about the disability and made a persona to help us better understand what it is like to live with that disability.

After some research into the daily lives of our personas and how they use various digital platforms we moved on to our own app Elevate to see how they might experience the app through their disability. We were amazed by how iOS makes an app a bit accessible by default, and how differently you experience an app when looking at it through a disability. It was surprising to find out how poorly the app was with respect to accessibility.

Why we did it?

At Touchwonders we have innovation days to do a deep dive into a subject we currently don’t know enough about, or that we simply find very interesting. The goal is to improve one of our products or processes during the same day. The subject for this innovation day was accessibility.

Why accessibility?

When you create a new project you put your target group at the center and mostly don’t consider disabilities (in my experience). Especially working on a client project where there is a budget and a small window of time. It’s something that gets cuts as first and never gets addressed again. This means that you risk excluding 25% (estimate) of the dutch population.

We as Touchwonders are aware of this lacking and see a necessity to know more about it, so we can make it easier to address it in the future, and work on it from the start of a project. That’s why we chose to do our innovation day about accessibility.

Disabilities

Blindness

Blindness is strictly defined as the state of being totally sightless in both eyes. A blind individual is unable to see at all.

A screen reader is a form of assistive technology which is essential to people who are blind. Screen readers are software applications that attempt to convey what people with normal eyesight see on a display to their users via non-visual means, like text-to-speech, sound icons, or a Braille device.

Findings and improvements

• Test your app by turning on VoiceOver
  It will read out to you everything that is on the screen from the top to the bottom, you can use gestures to control it. VoiceOver has a steep learning curve when using it for the first time.
  
  People who use it everyday commonly set the speaking rate to it’s fastest setting. We couldn’t make any sense of what was being said, but our ears aren’t as trained.
  
  This is something you have to try for yourself! Go to your Settings > General > Accessibility > VoiceOver.
  
  VoiceOver is only available for iOS, for Android you have Talkback, which is similar to VoiceOver. Elevate is for now only available for iOS, so I will mostly describe iOS accessibilities features, but will mention Android as well.

• Prioritise your content vertically
  A screen reader or VoiceOver reads out everything from top to bottom. When designing for non disabled people you emphasize data by using color or making the element bigger to make that content stand out. Because of this you don’t always put the most important content at the top of a vertical list. This way the screen reader won’t read the most important information first; think about this when you design. An interesting method for a designer to prioritize the content on your page is priority guiding.
  
  For a developer, it is possible to provide an explicit order in which elements should be read by VoiceOver.
• Describe images and use transcripts for videos in your code
  We noticed that our buttons weren’t labeled correctly. When you hear “button” you don’t know what will happen when you press it. VoiceOver even completely skipped our graphs and images due to the lack of accessibility labelling. There were a lot of changes that we needed to make so that our app would be accessible for blind people.
  
  Down below you can see an example of how our About page button is spoken out loud before and after we made some changes.
  
  To make this work we had to add descriptions to the buttons in code. In the image you can see what we changed. We as well as Apple and so many others, really recommend you to walk through your own app with VoiceOver and check your buttons and error messages.

Dyslexia

Problems may include difficulties in spelling words, reading quickly, writing words, “sounding out” words in the head, pronouncing words when reading aloud and understanding what one reads.

Findings and improvements

• Think about which fonts you will use and your typography (e.g. line spacing)
  We found out that our app would be difficult to read for someone who has dyslexia because we use all caps titles and, as you can see in the images, our line spacing doesn’t have that much space. We added some line spacing and that already makes it much easier to read.
  
  When choosing a font for your design think about the readability. We found out that there is a special font to help people with dyslexia, called OpenDyslexia font. It would be awesome if iOS and Android could switch to a similar font in the accessibility settings. We personally found the font harder to read so we decided not to change it. But we did assess its impact on our designs.

• An image says more than a 1000 words
  In elevate we could use more images and videos to support text. You should add visuals to your app to support your text but do not replace text with images or videos, otherwise your app won’t be accessible for people with other disabilities.
  
  Sometimes a big block of text is unavoidable, like in a Privacy Policy or Terms of Service page.

Autism spectrum disorder (ASD)

ASD is a neurological and developmental disorder that begins in early childhood and lasts throughout a person’s life. It is a very broad and varied problem, primarily they are bothered by unfiltered signals coming in and have difficulties structuring them. Social communication and emotions is also difficult to interpret and thus find concepts as irony and “figure of speech” hard to understand.

To really understand, watch this video. It really helps to fathom what it’s like to see the world when you have ASD and what kind of stimulants there are in our environment.

Findings and improvements

• Don’t use figures of speech
  A figure of speech is hard to understand when you have ASD. We used them more often than we thought in our app, for instance: “Elevate your fitness by taking your office stairs more often” or “track the number of stairs you conquered”. Figures of speech can give your text a bit more flavor, but after removing them, it was more clear and still fun to read.

• Color “50 shades of gray”
  Bright contrasting colors are stimuli, so it is best to use mat colors. This lead to some discussions because contrasting colors are really important for people with low vision or color blindness. We tried to tone down our color scheme but in the end we chose to keep it as is because of the grayscale functionality iOS offers. Android also has a grayscale function but enabling it differs from different phones models. We checked if our app was still useful in grayscale and it was.
  
  Go to your Settings > General > Accessibility > Accessibility Shortcut > Colour filters.

What are your thoughts about accessibility?

I am really interested in what your thoughts are on this subject or what you are doing in your projects. Do you make your products accessible for everyone?

Next up: part 2

These were our findings on Blindness, Dyslexia and Autism spectrum disorder during our innovation day. In the next part I will go into details on Physical or motor disability, Deaf or hard of hearing, Low vision and Color blindness and I will tell you what our next step is. Subscribe to our channel so you won’t miss out on our next post on this subject!

Accessibility | Is your app / website usable by everyone? (part 1) was originally published in Touchwonders on Medium, where people are continuing the conversation by highlighting and responding to this story.

Why did you want to apply at Touchwonders?
When I was looking for internships in the summer, I was specifically looking for companies that had unique specialisations or values that matched with mine. 2 years ago, I had an internship at a company that designed and developed for SMART TV applications. Designing for SMART TV’s is different than designing for mobile. There are different things you need to take into account. The reason why I wanted to apply for an internship at Touchwonders is that they specialise in iOS and I was drawn by their approach to a mobile solution. It was slightly different than the methods we were taught at the university, so I was intrigued by how this company could help me improve as a designer.

What do you do at Touchwonders?
My favorite part of being a UX designer is to think of solutions how to make things better. I like to work together with the team and do some brainstorm sessions because you get inspired by other people’s ideas and you can come up with better versions of your first solution. At Touchwonders we organize multiple innovation days where we emerge experiment with new technologies to stay updated about the latest in tech and design methods. Some of the subjects of the workshops were “Design Thinking”, Voice Technology and AI. I admire Touchwonders for being so pro-active with educating themselves. As a student, I hated reading all the educational articles that were mandatory for some subjects. Now that I’m actually in the working environment as a designer, I acknowledge how important it is to know as much as you can about your own field.

How is your experience so far?
Every morning we start with a daily stand-up. We do this to keep each other updated on the things we do. It’s easy to lose track of what your team is doing because you are so focused on your own tasks. During the daily stand-up, we also have the opportunity to ask for help from our team members. I love the fact that this team genuinely cares about one another. When I first met them, I told them about my wish of wanting to travel to Japan and South Korea and that I love K-pop. During my internship, each of them came to me to tell me little things they have found out about either K-pop, Japan or South-Korea, and I really appreciate this because they really made me feel like I was part of the team. I have weekly meetings with my supervisor, and we always discuss how things are going with my internship and if there is anything I have to do for my education. What I appreciate so much about Touchwonders is that they are really prepared to help you achieve the learning goals you have set for yourself. You’re equally as important as any other member of the team.

What have you learned at Touchwonders?
I feel that I still have a lot to learn and to have the opportunity to be able to learn from this team is a chance I can’t let go to waste. The things I want to improve as a designer is to be more mindful of how consistent my design is, to be more focused on details and to be able to put together a good style guide. One of the things Touchwonders values is chasing details, and I admire that a lot. In the past 20 weeks, I have learned that there are more useful ways to use the tool Sketch. If you are skilled at using your tool, it will be easier to focus on the details of your design. Another skill I didn’t expect to improve here is my visual design. My personal goals were mostly focused on being a better UX designer, and the team was very encouraging when I was a bit insecure about my visual design skills. There was never a moment in which I regretted my choice to do my internship here. I would recommend other students to apply for an internship at Touchwonders if they want more than getting better at their personal goals.

What’s next?
I’m supposed to stay for 20 weeks, but I found an intriguing project that I would like to work on for my graduation project. I’m pleased to tell you that I will stay here for another 20 weeks. The project I will work on is a concept Touchwonders created a few years ago, but it never got picked up to be fully developed. You may have heard that sitting too long can be dangerous for your health. We are all guilty of sitting too long behind our desks, and it has gone so far that the Dutch are declared the European champion of sitting too long. Our application ‘Elevate’ will hopefully encourage employees to take a break more often to walk around and take a stair or two. My research will mainly focus on how the app can motivate the employees to take the stairs more often. I will look into different technologies and methods to use for the app so we can be healthier together.

UX design internship at Touchwonders was originally published in Touchwonders on Medium, where people are continuing the conversation by highlighting and responding to this story.

Here at Touchwonders one of our credos is “Be creative and try new things”, which is why we constantly look into new and emerging technologies. At the WWDC19 SwiftUI was introduced which has a lot of potential for mobile application development. In this post I would like to focus on how I used a tiny subset of SwiftUI in one of our production apps to set up a programmatically constructed view with drastically less code than its UIKit counterpart. The goal of this exercise it to get a first hands-on idea of what SwiftUI is and what it can do.

What I won’t cover in this post

At this point a lot has been written about SwiftUI already so the intention is not to repeat what is already out there or creating a massive link dump. If you’re looking for tutorials or some general info on how to get started with SwiftUI I recommend this article from hackingwithswift.com.

A bit of background

One of the apps we are working on at Touchwonders is Elevate, an application that promotes health in the workplace. We chose to not use interface builder in Elevate because it generates hard to read xml code which makes merge requests a mess and it’s hard to find conflicting constraints (especially if some constraints are created programmatically and some are created in interface builder). So we prefer building our views programmatically. The downside of this approach is that it does lead to a lotof UI related code.

Using SwiftUI

So let’s dive in and examine the difference SwiftUI can make for the following screen which is part of the “create account” flow.

The button in the lower right corner, title and background are all reusable components so they are not included in the code but other than that this is the code using UIKit:

This is where I constructed our custom text fields.

View code in GitHub

let placeholderColor = Elevate.Colors.lightTextOnDarkBackground.ui.withAlphaComponent(ColorConstants.placeholderAlpha)   
let fullNameField = ElevateTextField(style: .light) 
let fullNameFieldPlaceholder = NSLocalizedString("create-account.full-name-field.placeholder-text", comment: "Full name") fullNameField.attributedPlaceholder = NSAttributedString(string: fullNameFieldPlaceholder,                                                    attributes: [NSAttributedStringKey.foregroundColor: placeholderColor,                                                                    NSAttributedStringKey.font: Elevate.Font.h3light.font]) fullNameField.tag = CreateAccountContext.Constants.fullNameField fullNameField.textContentType = UITextContentType.name fullNameField.autocorrectionType = .no 
fullNameField.returnKeyType = .next 
fullNameField.delegate = interactor 
addSubview(fullNameField) 
self.fullNameField = fullNameField   
let choosePasswordField = ElevateTextField(style: .light) 
let choosePasswordFieldPlaceholder = NSLocalizedString("create-account.choose-password-field.placeholder-text",                                                     comment: "Choose a password") choosePasswordField.attributedPlaceholder = NSAttributedString(string: choosePasswordFieldPlaceholder,                                                          attributes: [NSAttributedStringKey.foregroundColor: placeholderColor,                                                                       NSAttributedStringKey.font: Elevate.Font.h3light.font]) choosePasswordField.tag = CreateAccountContext.Constants.choosePasswordField choosePasswordField.autocorrectionType = .no choosePasswordField.returnKeyType = .next choosePasswordField.delegate = interactor choosePasswordField.autocapitalizationType = .none choosePasswordField.isSecureTextEntry = true addSubview(choosePasswordField) 
self.choosePasswordField = choosePasswordField   
let confirmPasswordField = ElevateTextField(style: .light) 
let confirmPasswordFieldPlaceholder = NSLocalizedString("create-account.confirm-password-field.placeholder-text",                                                      comment: "Confirm password") confirmPasswordField.attributedPlaceholder = NSAttributedString(string: confirmPasswordFieldPlaceholder,                                                                attributes: [NSAttributedStringKey.foregroundColor: placeholderColor,                                                                             NSAttributedStringKey.font: Elevate.Font.h3light.font]) confirmPasswordField.tag = CreateAccountContext.Constants.confirmPasswordField confirmPasswordField.autocorrectionType = .no confirmPasswordField.returnKeyType = .next confirmPasswordField.delegate = interactor confirmPasswordField.autocapitalizationType = .none confirmPasswordField.isSecureTextEntry = true addSubview(confirmPasswordField) 
self.confirmPasswordField = confirmPasswordField

And this is where I configured the layout using constraints.

View code in GitHub

fullNameField.leftToSuperview(offset: LayoutConstants.sideOffset) fullNameField.rightToSuperview(offset: LayoutConstants.sideOffset) fullNameField.height(LayoutConstants.fieldHeight) choosePasswordField.leftToSuperview(offset: LayoutConstants.sideOffset) choosePasswordField.rightToSuperview(offset: LayoutConstants.sideOffset) choosePasswordField.height(LayoutConstants.fieldHeight) confirmPasswordField.leftToSuperview(offset: LayoutConstants.sideOffset) confirmPasswordField.rightToSuperview(offset: LayoutConstants.sideOffset) confirmPasswordField.height(LayoutConstants.fieldHeight) fullNameField.topToBottom(of: pageTitle, offset: LayoutConstants.fullNameFieldTopOffset, relation: .equal, priority: .defaultLow)
choosePasswordField.topToBottom(of: fullNameField, offset: LayoutConstants.fieldTopOffset, relation: .equal, priority: .defaultLow) 
confirmPasswordField.topToBottom(of: choosePasswordField, offset: LayoutConstants.fieldTopOffset, relation: .equal, priority: .defaultLow) 
// - ensure there is always a minimum vertical space fullNameField.topToBottom(of: pageTitle, offset: LayoutConstants.minimumVerticalDistance, relation: .equalOrGreater, priority: .required) 
choosePasswordField.topToBottom(of: fullNameField, offset: LayoutConstants.minimumVerticalDistance, relation: .equalOrGreater, priority: .required) 
confirmPasswordField.topToBottom(of: choosePasswordField, offset: LayoutConstants.minimumVerticalDistance, relation: .equalOrGreater, priority: .required)

There is a lot of constraint-related code because there are two different sets of topToBottom constraints; these ensure all fields remain visible when an error is shown on smaller devices like the iPhone SE.

Now let’s have a look at the SwiftUI version of this code. The entire view is constructed and laid out in less lines than it took to even construct the views in the first place and is much nicer to read.

View code in GitHub

var body: some View {
    VStack(alignment: .leading) {
        ElevateTextFieldUI(placeholderText:
NSLocalizedString("create-account.full-name-field.placeholder-text", 
                   comment: "Full name"), 
                           delegate: interactor, 
                           secureTextEntry: false, 
                           placeholderColor: Elevate.Colors.lightTextOnDarkBackground.ui.withAlphaComponent(0.5),
                           placeholderFont: Elevate.Font.h3light.font,
                           autocorrectionType: .no,
                           returnKeyType: .next,
                           autocapitalizationType: .none)
        .tag(CreateAccountContext.Constants.fullNameField) 
        .frame(height: 32)
        .padding(.top, 23)
        Spacer().frame(minHeight: 7, idealHeight: 27, maxHeight: 27)
        ElevateTextFieldUI(placeholderText: 
NSLocalizedString("create-account.choose-password-field.placeholder-text",
                  comment: "Choose a password"),
                           delegate: interactor,
                           secureTextEntry: true,
                           placeholderColor: Elevate.Colors.lightTextOnDarkBackground.ui.withAlphaComponent(0.5),
                           placeholderFont: Elevate.Font.h3light.font,
                           autocorrectionType: .no,
                           returnKeyType: .next,
                           autocapitalizationType: .none)
        .tag(CreateAccountContext.Constants.choosePasswordField)
        .frame(height: 32) 
        Spacer().frame(minHeight: 7, idealHeight: 27, maxHeight: 27)
        ElevateTextFieldUI(placeholderText: NSLocalizedString("create-account.confirm-password-field.placeholder-text",
                  comment: "Confirm password"),
                           delegate: interactor,
                           secureTextEntry: true,
                           placeholderColor: Elevate.Colors.lightTextOnDarkBackground.ui.withAlphaComponent(0.5),
                           placeholderFont: Elevate.Font.h3light.font, 
                           autocorrectionType: .no,
                           returnKeyType: .next,
                           autocapitalizationType: .none)
        .tag(CreateAccountContext.Constants.confirmPasswordField)
        .frame(height: 32)
        Spacer()
     }
     .padding([.horizontal]) 
}

The spacer with its minHeight, idealHeight and maxHeight properties allows me to do the exact same thing as the autolayout priorities with again a lot less code.

Some additional code was needed to wrap our custom UIKit based text field in a view usable within SwiftUI:

View code in GitHub

struct ElevateTextFieldUI: UIViewRepresentable {     
    let placeholderText: String
    weak var delegate: UITextFieldDelegate?
    let secureTextEntry: Bool
    let placeholderColor: UIColor
    let placeholderFont: UIFont
    let autocorrectionType: UITextAutocorrectionType
    let returnKeyType: UIReturnKeyType
    let autocapitalizationType: UITextAutocapitalizationType

func updateUIView(_ uiView: ElevateTextField, context: Context) {         
        uiView.attributedPlaceholder = NSAttributedString(string:
self.placeholderText,
                                                         attributes: [NSAttributedStringKey.foregroundColor: placeholderColor,                                                                               NSAttributedStringKey.font: placeholderFont])
        uiView.autocorrectionType = autocorrectionType
        uiView.returnKeyType = returnKeyType
        uiView.autocapitalizationType = autocapitalizationType
        uiView.isSecureTextEntry = secureTextEntry
        uiView.delegate = delegate
    }       
    func makeUIView(context: Context) -> ElevateTextField {
        let textfield = ElevateTextField(frame: CGRect.zero, style: .light)
        return textfield
    }
}

The struct obviously cannot have the same name as the class it is wrapping so that is why I called it ElevateTextFieldUI. However if you are all-in on SwiftUI the ElevateTextField would have also been built with SwiftUI and then this code would not be necessary.

Conclusion

One of the SwiftUI claims at the WWDC19 was that it drastically reduces the amount of codes needed. Playing with it hands-on really shows how little code you need to build a view in SwiftUI versus UIKit, which is fantastic. In this example case, around 33% less code was needed and with a more simple layout I think it would be around half of its UIKit counterpart. Also there is almost no constraint related code, which is amazing for applications with a longer lifespan that might require refactoring over time. If all of these pro’s can also help rid us of Interface Builder and it’s overly complicated xml files that make version control a real headache I would be very happy. It will probably take some time before our customers will profit from the SwiftUI advantages as it is only supported from iOS 13 onwards. So it is going to take time before SwiftUI will become fully ingrained in existing mobile applications.

Do you want to know more? Contact us. We’re happy to help!

This article has been published before at blog.touchwonders.com.

A first look into SwiftUI was originally published in Touchwonders on Medium, where people are continuing the conversation by highlighting and responding to this story.