It’s about inclusion

I just realized that a lot of my current thinking converges on one concept: Inclusion. Topics are as diverse as poverty, support for assistive technology, gender and browser/device support.

Accessible with VoiceOver and other assistive technology
When we build apps and web services it is easy to make them inaccessible for persons who use assistive tech such as JAWS and VoiceOver. However, it is almost equally easy to build with accessibility in mind. The coolest thing is that VoiceOver can be used on any iOS device – just turn it on and you will be able to hear how persons with less eyesight then you experiebnce your app or service.

Gender
In most services the gender of a person is completely useless data to collect. Are you building a web shop? No need for gender. Are you creating a community? No need for gender. Are you building a tool to be used for understanding social issues? Quite possibly a need for gender.

To me gender is just one of many demographic and sociographic aspects that influence a persons standing in society, I.E. I have some variety of an intersectional perspective. So if you ask me to identify my gender it better be in a service that can use it well. You also need to ask me about income, home town or any other set of aspects that is needed for your analysis. And I want to know how you will be using the data I give you.

BTW: if you are asking for gender, make it an open text field where I can write my own gender or leave it blank.

Browser and Device support
It is expensive as hell to develop web services and apps that work on old devices and in old browsers. But if we do not we are once again using technology to exclude persons. I work with kids and among them many devices and computers are inherited from parents who get new devices. That mean that my audience has a lot of first generation iPads, old Android devices and less able computers. Poor families will have extra problems buying new devices and will need a phone to work 3, 4, perhaps 5 years.

Web instead of native – with wrapper/manifest for distribution in app stores
As soon as you develop an app specifically for one or a selection of mobile platforms you exclude all persons who do not use that platform.

Statens medieråd is a government body that, among other tasks, investigate device usage among kids in Sweden. Their latest report, from early 2013, said that 62% of 9-12 year olds in Sweden have a smartphone. If you add tablets to the percentage it grown by a few points. Internal SVT stat’s say that almost all of them use Android or iOS. 81% of the kids has their own computer and 19% shared one with their family.

At SVT we are currently debating how a service for 9-12 year olds should be built. The service, as used on a phone, is quite personal so borrowing someone elses phone would be awkward.

The current plan is to build it for iOS 5 and newer and for Android 2.3 and newer. That means that if the app had been released in early 2013 it would, from it’s choice of platform, have excluded ~25% of the audience. However, the app will be released during summer 2014 and be used for a few years and during that timespan a lot more kids will have smartphones. However, kids in poor families might be over-represented among those who are excluded throughout the service’s life span.

If the service was built for the web almost 100% of the kids who where 9-12 in early 2013 would have been able to use it on a computer. The 62% that had a smartphone would be able to use it in their phone’s browser.

If the service was built for web and a wrapper app or manifest was developed, the service could get the extra marketing push that app store distribution means.

Building services that target phones with web tech require you to choose concepts that do not rely on native functionality or the extra performance some features have in native apps. This can feel like a sacrifice, but there are always constraints in all projects and you can see web tech as just an other one of those constrains and use it as a positive thing – the web tech will force you to be more creative!

Leave a Reply

Your email address will not be published. Required fields are marked *

Foundations for better restaurant sites

Part 9 of 9 in the series Deliverables.

Plate with food

To design better restaurant sites I interviewed six persons. From the discussions I got eight insights. Among them are that sites are used by newbies and regulars, that reviews are super valuable, that we want to imagine the restaurant visit before it happens, and more. The insights can help when building new sites/apps or evaluating existing ones. 8 things the site needs to enable

News article + Elon Musk + Tim = a landing page

Part 8 of 9 in the series Deliverables.

I was asked to suggest improvements for the product promo page for Artbutler Cloud Websites – a tool for building websites for artists and galleries. My recommendations boiled down to experimenting with CTA's, mixing up the imagery and using a combo of content structures.