Our bookkeeping apps for freelancers
Nuestras apps de contabilidad
Nuestros articulos en español
Nuestros articulos en ingles
Showing UX respect to our non-English speaking users
Léelo en español
How we cheaply localised our indie iOS apps to Spanish, while avoiding common pitfalls that often worsen the experience for many users.
Offering our apps in multiple languages is been a priority since we started our collaboration. While our shared language is English, it's not the primary for two of the three of us. We come from different countries and cultures, so we have spent much time discussing the effect of these nuances in the experience of our iPhone apps Money In & Money Out.
Apple technologies make very easy for developers to structure apps for multiple languages. Xcode supports incremental localisation, so even if you only support one language at launch, you are reducing a lot of the pain of adding additional languages to your app in the future.
This makes possible to launch apps in other languages very fast and cheap, but not necessary taking the time to consider what type of experience the international user is getting. The translation approach varies greatly, from apps that merely replace words with machine translation, to others that carefully interpret the content and context to fit regional mental models. In our case, we opted to provide in our Spanish apps the same clarity and efficiency of use as the English ones.
The translation work per se didn't take great deal of work: content seemed to fit nicely, as well as labels and headings. A few tests and amends later, the app was polished and ready for the App Store in Spanish. It sounds fast and easy because it was. But there was some up-front work we did for this to be efficient and cheap, and it was addressed at the start of the project when Matt, our designer, started sketching solutions.
Our localisations strategy
We didn't want to be just "available" in multiple international App Stores, we wanted to provide an inclusive product, one that fits the needs and expectations of different users around the world, not only the English-speakers. As we were building our English-first apps, we kept this goal in our heads along the way, and it guided many of our decisions during design and development.
1. Design for inclusion
When designing our apps, we always tried to keep "the other" users in mind. We took in consideration how elements such as images, icons, colours, typography, forms, buttons, labels, action sheets, alerts, notifications... would work in different languages and cultures.
We made design compromises to benefit clarity and efficiency in different contexts, and always prioritised accessibility and inclusion over aesthetic choices.
We made sure our interface was adaptable, so elements wouldn't overlap and text wouldn't truncate, to avoid ruining an otherwise good experience. It's important to note that English has larger vocabulary than most languages, including Spanish. So often translations in other languages contain more characters or words to communicate the same thing. Truncation issues are quite frequent in localised apps:
2. Contextual translation of words and user experience
Content is "king" everywhere, independently the language spoken. Our apps speak plain English and are jargon-free. They provide clear feedback, allowing the user to feel in control and confident in the task they are completing.
With the Spanish version, we wanted to keep clarity and ease as the backbone of our user experience, which meant the apps had to hablar en cristiano ("Speak in Christian"- an old Spanish expression which means "Speak to me in a way I can understand"). As you can see with this example, translating words is not the same thing as interpreting them. This sometimes became a challenge when translating to Spanish, as words rely heavily on context to provide their exact meaning. For instance, in Spanish the word contabilidad means both accountancy and bookkeeping, which are two different things.
3. Understanding of iOS regional conventions
Apple localisations save great deal of work, as you don't have to worry about translating the iOS interface elements in your app. Said that, if you care about your users micro-interactions, it is important to get familiar with iOS region-specific conventions, so you can use the right terminology in the user onboarding or in the app settings.
In the case of Spanish iOS conventions, there are some subtle differences to the English ones.
For instance, what in English is known as "Background Refresh", in the Spanish iOS is named "Actualización en segundo plano". However, if you search for background refresh in Google Translator, it translates it as "Actualización de fondo", thus the mistake many developers make when labelling their app permissions. Thus it's super important that the person translating is familiar with the conventions of the regional variations of iOS. Other labelling issues can easily be found with the Photos app ("Fototeca") and the Mail app... Apple themselves can't figure out this one, so they inconsistently use both "Mail" and "Correo" as labels).
4. Translation in Xcode, testing constantly on device
It seems there are two main ways to do the translation work of your localised text files. The common approach is to export the localised files for translation, either by machine (e.g Google Translate), or with a human. The translated files are then imported back into the Xcode project. While this might feel simpler and cost-effective, it carries its own problems, like the translator can't see ad hoc how the translation works on the app, and then things like these happen:
To avoid these issues, we translated directly the localisation strings in our Xcode project (no coding experience is needed to edit the localisations strings, just a little bit of guidance from your developer). This enables the translator to first translate, and then test on device, amending and testing as many iterations as needed, to make sure the experience is interpreted correctly.
All without impacting development time or cost.
Once complete, the translator can push to Github and the developer can simply merge the localisations branch to the project. Then, before submitting to the App Store, try sharing a build through TestFlight with a few users from your target region to make sure there are no holes in the experience.
There is no point in translating the apps and launching them internationally if we can't communicate their benefits, answer FAQs, support users, or highlight our commitment to privacy and security of personal and financial data.
No matter how you deal with your localisations strategy, keep in mind that being available in the App Store is not enough. If you want to have a chance of making money in other markets, make sure you treat your international users with some UX respect, otherwise they will say adios as they delete your app from their iPhone without mercy.
Cruzando fronteras en el App Store
Read in English
Así hemos localizado a español nuestras apps indie para iPhone sin depreciar la experiencia para muchos usuarios
Desarrollar apps en diferentes idiomas ha sido una de nuestras prioridades desde que empezamos a trabajar juntos. Los tres procedemos de distintos países (Reino Unido, España y Rusia) y compartimos el inglés como idioma común a la hora de comunicarnos. Probablemente por ser de orígenes diversos, hemos tenido largas conversaciones en torno a cómo afectan estas particularidades a la experiencia de usuario de nuestras apps Money In & Money Out.
Las tecnologías de localización que ha desarrollado Apple permiten estructurar apps en múltiples idiomas sin esfuerzo. Xcode permite localizaciones incrementables, así que aunque inicialmente tu app indie esté sólo disponible en un idioma, puedes añadir otras lenguas en el futuro sin mayores complicaciones ni impacto en tiempo y costes de producción.
Esto permite acceder a nuevas audiencias en otros App Stores regionales y abre oportunidades para conectar con nuevos usuarios. Echando un vistazo en el App Store en español a la oferta de apps localizadas, nos encontramos con un amplio abanico de estrategias a la hora de traducir el contenido. Estas van desde la traducción literal de la app (palabra por palabra) a través de una herramienta automática como Google Translator, hasta apps que traducen el contenido interpretándolo a su contexto de uso (regional). En nuestro caso, queríamos que nuestras apps en español (y en otros idiomas) tuvieran en esencia la misma claridad y eficiencia de uso que nuestras apps en inglés.
El trabajo de traducción per se duró un par de días. El contenido encajaba sin problemas: títulos, etiquetas y botones se visualizaban correctamente. Después de testarlas e introducir algunos cambios y correcciones, las apps estaban listas para ser lanzadas en el App Store en español. Suena sencillo… porque lo fue. Pero para que se dieran estas circunstancias, tuvimos que hacer parte del trabajo al inicio de la creación de las apps, cuando Matt, nuestro diseñador, empezó a esbozar la experiencia de usuario y la interfaz.
Nuestra estrategia de localización
Nuestro objetivo es ofrecer un producto accesible e incluyente, que cubra las necesidades y expectativas de diferentes usuarios, no sólo las de los anglófonos. Conforme fuimos desarrollando nuestras English-first apps, mantuvimos este objetivo presente, y guió muchas de las decisiones que tomamos durante el diseño y desarrollo de las apps.
1. Diseño incluyente
Durante el diseño de las apps, intentamos tener siempre presente diferentes tipos de usuario, y como funcionaría la interfaz para ellos. Tomamos decisiones e hicimos concesiones en favor de claridad y eficacia de uso, por encima de otras consideraciones estéticas o comerciales.
Tuvimos en cuenta en nuestras decisiones cómo ciertos elementos podían impactar la interfaz y la experiencia de usuario en otros idiomas: tipografía, imágenes, iconos, botones, etiquetas, formularios, alertas, notificaciones…
Optamos por diseñar una interfaz adaptable, para así evitar problemas comunes como contenido truncado o elementos solapados en la pantalla, algo que puede arruinar lo que por otro lado sería una buena experiencia de usuario. El idioma inglés tiene mayor número de palabras que el español, así que frecuentemente la traducción de la palabra inglesa necesita contexto o de más de una palabra para comunicar exactamente lo mismo ("Inbox" vs. "Bandeja de entrada", "Swipe options" vs. "Opciones para deslizar el dedo"...). Así que es frecuente encontrarse con etiquetas truncadas:
2. Traducción de la experiencia de usuario
Nuestras apps para trabajadores por cuenta propia “hablan” un lenguaje directo y sencillo; no utilizan terminología técnica sobre contabilidad, y están diseñadas para que el usuario se sienta en control de la situación cada vez que usa las apps para registrar transacciones o enviar informes. Con la versión en español queríamos ofrecer la misma experiencia, así que hemos intentado que las apps hablen en cristiano, con el contenido, tono de voz, estilo y terminología adecuados.
3. Conocimiento de las convenciones regionales de iOS
El sistema de localizaciones de Apple ahorra gran cantidad de trabajo ya que no te tienes que preocupar de traducir los elementos de la interfaz del sistema operativo. Dicho esto, si te preocupan todos los detalles de la experiencia de usuario, incluidas las micro-interacciones en tu app, es importante familiarizarse con las convenciones del iOS en el idioma a traducir. De esta manera podrás utilizar la terminología apropiada en los ajustes de la aplicación y cuando solicites a tus usuarios permisos de acceso a su iPhone.
Por ejemplo, en español las opciones de Ajustes y Permisos en el iPhone están etiquetados como “Sí”-“No”, mientras que en inglés las opciones presentadas son “On”-“Off”. Google Translator traduce “Background Refresh” (el nombre de una funcionalidad que ofrece iOS) como “Actualización de fondo”, mientras que el término correcto en iOS es “Actualización en segundo plano”. De ahí la importancia de que la persona que realice la traducción esté familiarizada con las convenciones regionales y terminología del sistema operativo, para así poder llamar a las cosas por su nombre. Traducciones como "Actualización en tiempo real" son perjudiciales para el usuario, ya que crean expectativas falsas que no corresponden con la funcionalidad ofrecida.
Errores en etiquetas del iOS son comunes, incluso Apple presenta inconsistencias, ya que usa en español dos etiquetas diferentes para la Mail app ("Mail" y "Correo").
4. Traducción desde Xcode, testando iterativamente en dispositivo o simulador
Cuando se trata de localizar el contenido, hay dos maneras distintas de hacerlo. La más común es exportar los archivos localizables del proyecto desde Xcode para traducirlos externamente con un servicio automático (Google Translator) o humano (traductor profesional). Una vez traducidos, los archivos se importan de nuevo en Xcode. Aunque es un método relativamente cómodo y sencillo, viene con sus propios problemas, ya que el traductor no puede ver ad hoc como encaja la traducción en la app, y si ocasiona cualquier problema. Entonces, errores como estos ocurren:
Para evitar este tipo de problemas, optamos por traducir nuestras apps directamente en Xcode (no hace falta experiencia como desarrollador para editar los archivos de localizaciones). Esto permite traducir y testar directamente en dispositivo de inmediato, con la ventaja añadida de poder hacer cambios y probar alternativas para mejorar la traducción, todo esto sin efecto en tiempo y coste de producción. Una vez completada la traducción, el traductor puede compartir los archivos localizados en GitHub para que el desarrollador los añada de vuelta al proyecto Xcode. De ahí puedes compartir con algunos usuarios regionales un beta de tus apps a través de TestFlight para garantizar que todo funciona como debería.
5. Páginas de producto, soporte y privacidad
No tiene sentido lanzar tu app en el mercado internacional si no puedes comunicar los beneficios de tu producto o servicio en el idioma que hablan tus usuarios. El marketing que realices tiene que tener el mismo tono de voz y consistencia que tu producto. Más allá de la app, puedes y debes localizar las propiedades de la pagina de tu producto en iTunes Connect, incluyendo descripción, palabras clave, pantallazos y video promocional, cuando vayas a enviarla para aprobación. No te olvides tampoco de traducir la página promocional y política de privacidad, ya que el App Store incluye enlaces directos a estas páginas. También deberías traducir tu página de ayuda y soporte.
Independientemente de la estrategia que sigas localizando tus apps, recuerda que para tener opciones de triunfar en nuevos mercados no es suficiente con “estar disponible” en el idioma x en el App Store. Para ganar (y retener) la atención de estos nuevos usuarios es crucial tratarles con respeto y ofrecer un producto acorde con sus expectativas.
This week Apple revealed the new App Store at WWDC17, a first look at what Phill Schiller has been working on since the end of 2015… It all seems very promising, hopefully this will solve many of the issues developers face when trying to make their apps more discoverable.
Apple: “Beautifully redesigned for iOS11… Compelling stories, in-depth interviews, helpful tips and collections of must-have apps and games will showcase Apple’s unique perspective and aim to inform, help and inspire customers every day."
Great! …Especially for popular brands and studios that are already heavily featured, they will benefit even more from full-page curated content, which will attract even more users to their already successful apps. That said, we hope this will benefit less well-known apps and indie developers too. Separating games and apps into there own sections, top charts etc, should also help greatly.
As a small, independent, self-funded team of three, we got particularly excited at: "Search by name, category, developer or topic, and you’ll receive relevant results for specific apps and games, as well as editorial stories, collections and in-app purchases." It seems, Apple has been listening to the dev community over the years, and these improvements promise to improve their search algorithm which, currently, really sucks.
However, Apple has been quite vague about how they're planning on improving search results, but we have great hopes they are in the right direction. While submitting an update to our apps yesterday, we noticed 3 small additions in the iTunes Connect properties:
1. App subtitles
A summary of the app will be displayed right underneath the title, which should solve for the current problems caused by apps trying to include descriptions in their names. It feels a little bit strange though that the character limit for the summary (30) is smaller than the character limit for the title (50). It would be interesting to know from Apple what's the reason behind that decision.
2. Promotional text
Allows developers to highlight any current features to their customers without having to release a new update. The promo text will appear right above the app description, giving developers the opportunity to promote different features over time, test different marketing approaches, without the development time and cost involved with releasing new builds.
3. Include attachments to your notes for the review team
In addition to sending your comments to the review team for evaluation, now you can attach files to help the app reviewer, which hopefully should speed up review times and help apps get noticed by Apple.
Also new, Apple has given a way for developers to offer their apps for consideration for promotion!
We will be definitely be taking advantage of these new features, as much as possible, in order to give our apps the best chance of not getting lost in the App Store.
We launched our first 2 indie apps, Money In and Money Out last September, at the same time iOS10 was released. We delayed release to implement many of the new iOS10 features, trying to get featured with “New apps for iOS10”… However, we knew we were coming from nowhere, as these were our first apps. Having previously worked for big commercial studios, whose clients are big brands, nearly all of which had been featured in the App Store, we knew the importance of being featured.
Matt, basking in the success of The Economist Radio app getting featured in Best new apps, April 2014.
With no marketing budget and zero contacts in the media (it's really hard to do networking when you are working solo and need to pay the bills), we hoped that at least some of the 500 million unique customers that visit the App Store every week, would find out about apps, by being featured, opposed to having to rely on organic search.
We strictly followed Apple's guidelines for designing, building and marketing iOS apps, implemented many of the new features of iOS 10 (Widgets, 3D touch, Spotlight), we prioritised accessibility (VoiceOver, DynamicType), we even got iCloud sync working reliably! We then set to work on the App Store, making app preview videos, pretty screenshots and descriptions. We even made them available for a lower price in a Bundle. We naively assumed we had a good chance.
After submitting… disappointingly we weren’t featured, in fact we were bearly even searchable, pretty much invisible.
While working for large studios and brands our managers had much guidance and assistance from App Store reps. So we got in touch with various people in the App Store editorial team and made a passionate case for why we should be featured, and asked for feedback and guidance… We admit we were naive, and we get it: Apple, no doubt, has to answer thousands of requests a day, we couldn't expect special treatment. But sometimes magic happens, and apps from indie devs do get featured. Of the few responses we got back, no help or guidance was offered.
💩… we had to rely solely on organic search, hoping our target audience would find us when searching for relevant, specific keywords. Even now, search results prioritise the more popular / higher earning apps, mixed with irrelevant apps and games - many of which should have been removed during the purge (did this even happen?).
This is what happens if you search for the name of our app, “Money In”, on the (UK) App Store. We ranked 38th, after apps like Dollar Candy, Texas Hold’em Poker, Bruce Betting, Slots in Wonderland, When the saints go laughing, Bingo Dash Crack, and Supermarket Cashier (all these apps are games, as you can guess).
We truly hope the search algorithm will get significantly better in the new App Store… It really needs to, so it can be more relevant to users, and also, give indie devs like us, the chance to get discovered and make a sustainable living from making iOS Apps. But this is only one part of the puzzle. After nearly 2 years of development, our revenue doesn't even cover the cost of the promo website’s domains, hosting... let alone pay a wage to make a living from making apps for the App Store.
The App Store needs diversity; PayPal is featured 3 times — twice in Finance category and once in Business), this doesn't help users, indie devs, or even Apple(Pay). Apple need to start working closer with indie devs, encouraging the creation of more innovative, accessible, engaging apps, helping them to have a chance in the App Store. This would increase the chances of modest developers being able to earn a sustainable revenue from building apps for their platforms…
If not, it will result in more shady developers making more apps with user-hostile methods of monetisation: intrusive advertising, selling user data… and the good Indie devs will leave, instead creating products for the Web or even Android!
Our modern lives are deeply intertwined with digital technologies. Our data is instantly available on our devices and in the cloud. But when dealing with our business finances, we still have to deal with paper invoices and receipts. Consequently, we have to manually input the data, a major pain point of running your own business, as it takes much time, effort and a decent understanding of accounting to do well.
Money In and Money Out are designed to minimize that pain, by making intelligent suggestions, based on the user's previous activity. When adding a new transaction, after just a couple of letters are entered into the Description, a suggestion is offered, if used, the other fields auto complete, based on the users previous activity.
"In the time than it took for my credit card charge to go through, I had already added it!" Siegfried Grimbeek
What is OCR?
Optical Character Recognition (OCR), is a technology that extract the text from images, like photographs, scanned documents or books. In many scenarios, this can be used to automate the work which have had to been done manually before.
Why we didn't use OCR
Well, creating an intelligent system that could accurately and quickly predict the transaction the user was trying to add, was not our first solution... that would (did) take ages to implement well... We had originally planned to use OCR to capture the information on the receipt automatically, so all the user had to do was take a photo of the receipt...
Variations and lack of standards
OCR works best for reading simple text documents with very standardised layouts or short strings of text. We quickly realised that invoices and receipts do not have a standard format and the contained information is inconsistent. After collecting examples from around the world, we tried to identify common patterns that we could potentially use to recognize the information needed. Unfortunately, the level of variation was incredible, resulting in slower, less accurate results.
Speed & accuracy
There are several solutions available on the market that allow optical recognition, such as Tesseract (open source) or ABBYY Cloud OCR (proprietary). ABBYY Cloud OCR interesed us, as it has a rich selection of options that even allow to recognize breakdowns of purchased goods following the layout of receipt, along with wide range of supported languages. Albeit slowly, expensively and varying accuracy.
While you can sacrifice speed by pushing recognition into background (which isn't an ideal experience), accuracy is paramount when working with financial data. However, none of receipts we tested could be processed accurately enough or in a time which would have been quicker to just manual input.
The cost of the decent OCR is high, which would result in needing to increase the price of the apps or require charging for an on-going subscription, to sustainably keep developing and improving the apps.
Language & region
While different countries and regions have different regulations on what information must be included on invoices and receipts, this does not seem to impact the consistency of the information and the layout. This is made much more complicated by different languages, as translating on-the-fly would be needed, making processing slower and have to rely on Machine Translation, like Google Translate, whic would reduce the accuracy of the data being captured. The consequence was false results, which require heavy editing by the user.
Surprisingly, the currency of the transaction was not included on many of our example receipts, so can't be captured consistently. Our apps supports multi-currency and automatic conversion, to reduce user effort and increase the accuracy. To work around this we could have used 'last used currency' or automatically switch based on the user's current location, but neither produce reliable enough results.
Privacy & security
The financial data and transactions of a business are important private data. To increase speed, many OCR solutions rely on uploading the image to the providers cloud server for processing and the resulting data transmitted back. Dependencies are risky, as it means relying their security, both now and in the future. The potential risks to data privacy were too high for consideration.
Will we use OCR in the future for Money In and Money Out?
Not for now, not in it's current form. There are to many pain points for capturing reliable data from invoices and receipts. It would take significant improvements to the technology or enforced global standards for invoices and receipts.
While it would have been easier just to accept the limitations of OCR and hope it improved at some point, it gave us the opportunity to explore different solutions. After much experimentation, we found a mix of basic Machine Learning and AI to be much faster, accurate and will learn from the user's activity. While this took much longer to build, it means less dependency, cost & security issues of using 3rd party solutions, and allows for a much better experience.
According to a study by You.gov and FreeAgent, independent workers and small companies are missing out on more than £50 million in UK tax relief by ignoring small expenses.
Whether it is £5 or £100 (replace with your local currency), that is money you can claim tax relief on in many countries, and it is money that quickly adds up. However, it is surprising how many of us still dismiss small expenses because it takes too much time to log them. Those expenses can end up being worth hundreds, or thousands, of pounds (replace with your local currency) when they’re all combined.
Think about frequent or repeating business expenses you are not keeping record of: It might be your internet bill, the storage room you rent for your equipment, a portion of your flat utilitites if you work from home, the coworking space fees you pay when you work remotely, the apps and services you buy and subscribe to, the taxis you take to attend client meetings, your cloud storage monthly plan…
You might think that they’re too small amounts to bother with, but the truth is that logging each of them enables you to claim tax relief and as a result, save you tones of money. Can you see the big picture here?
With Money Out, we've focused on ways to make expenses bookkeeping seamless from you iPhone, so logging every single expense become part of your daily routine, even when it's pity money:
• Based on your usage, Money Out learns about your frequent expenses, making intelligent suggestions and predictions
• Logging details is fast, and gets faster the more you use the app
• You can set up repeating expenses and they will be automatically logged for you
• Add receipts to your expenses and they get automatically save in your iCloud
• Your foreign expenses are automatically converted and displayed in your businesses primary currency, and the exchange rate is saved with life data. You don't need the calculator and currency apps anymore
Remember fellow independent workers that, at the end of the day, every penny (replace with your local currency) counts.
As part of the process of handling your independent business, you have to provide recording of your financial transactions (money in and out of the business). That's what a bookkeeper does.
Doing your own bookkeeping is not that hard: all you have to do is log your business transactions accurately and keep proof of records for potential inspections. This makes possible for your accountant to sort your business accounts when your financial period ends. If you don't provide a comprehensive report of your incomes and expenses, their intern will be doing your bookkeeping, and you'll be charged for the extra time.
Money In and Money Out apps provide you with a simple, fast and cheap way to do your own bookkeeping from your iPhone, so you can save money from your accountant's bill.
This is how you do your bookkeeping:
1. Log accurately your business incomes and expenses
Money In and Money Out make intelligent predictions and suggestions everytime you log a transaction, making input very fast. As they learn from your usage, the sugestions will improve, and you'll log faster and faster. Any frequent income or expense can be set to repeat and it will be auto-added for you, which is a big time-saver. You can set up payment due dates for your incomes, and you'll get alert if they are overdue.
2. Keep proof images of records
Cloud access to proof images helps your accountant validate your expenses and incomes... and they will be crucial if you get a tax inspection! US law requires you to keep records for 3 years. In the UK the period is 6 years.
An archive of your income and expense reports and proof images is safely stored in your iCloud Drive. Accessible from all your iOS and Mac devices, even if you stop using the apps.
3. Submit accountant-friendly reports
When is time to submit your bookkeeping records to your accountant, the apps send you a reminder so you don't miss the deadline. Your accountant can open your reports with any accountancy solution or spreadsheet software they use.
Stop paying extra for something you can easily do. Money In and Money Out do the tidius job for you.
We strive to make our visual interfaces intuitive to make it easier for our users to understand and use our apps. However, for users who rely on Voice Over, often the visual interface is secondary or even invisible, within their experience of the same app. Highly recommended by Apple, but rarely done well, it's possible to communicate the visual interfaces, via accessibility traits, labels, values and hints. If done well, a blind person could do the same tasks in the same app, as normally sighted person.
Sounds easy, right? But making sure ever element of the interface and ever step of every flow make sense for many different use case, is difficult and time-consuming. As we are independent team, we choose to spend the time to create an fast, inclusive experience.
The most time is in the details and the details can make or break the experience. Like the adaptive tab bar, which first shrinks labels then entirely removes them after a month... adaptive accessibility could remove certain hints and replace labels with shorter versions letting experienced users to move faster through familiar flows.
Hopefully, more apps will take the time to make their apps more inclusive. To encourage this, we have broken down the main aspects of iOS accessibility and code on how to include them in your apps, and a few tricks we learnt.
Traits allow Voice Over to know the type of element and what interaction it has. So if a user selects it, Voice Over can offer more relevant information at the right time to the user.
All standard UIKit components provide correct accessibility traits, however when building custom UI elements you have to maintain traits manually.
There is one private trait used for back button in
UINavigationController that we found particularly useful when implementing on boarding in our apps, where we use custom chevron button with customised accessibility label. Adding following accessibility mask makes Voice Over to pronounce otherwise regular
UIBarButtonItem as back button:
Accessibility frame defines the focus area for accessibility element.
When used within scroll views, it affects the way voice over scrolls content during navigation between elements. We use extended boundaries for buttons and text fields to make sure that they don’t stick weirdly to the bounds of scroll view, keeping enough space around and providing better visual feedback.
Accessibility frames are calculated in screen coordinates, UIKit has a helper function for that. However, views with custom accessibility frames contained in scroll views have to recalculate their frames on scroll. To do this we need the help of
Trapping voice over within modal view
We use custom modal transitions in Money In and Out, which don’t cover screen entirely, leaving a small transparent overlay to give context to the view beneath. This is the same for action sheets.
What we would expect is Voice Over to be trapped within our modal view, however, it allowed the user to navigate back into the view below... the
accessibilityViewIsModal property should remedy this, but it didn’t work for us.
After some research, we discovered that system
UITransitionView is used as a container for modal transition, and always returned NO from accessibilityViewIsModal, so we made a patch to manipulate it:
UISearchControllers, without dedicated controller for displaying search results, trap the focus within search bar. We use the same
accessibilityViewIsModal trick to allow Voice Over to normally navigate within interface:
Navigation controller & back button
When the layout changes or a new view is shown, frustratingly the standard behaviour of
UINavigationController tends to set focus on back button. So, instead of announcing the name of the new view, when it opens, Voice Over would instead announce the back button. Unfortunately navigation controller does not expose title label, so we had to traverse the navigation bar hierarchy, like this:
At Morphine Apps, we have the goal of making our apps as inclusive and accessible as possible, so any independent worker with an iPhone can do their incomes and expenses easily from Money In and Money Out apps.
It is lack of awareness that most commonly results in products being inaccessible. That's why we've tested regularly the apps with different types of independent workers, some of them with disabilities. Thanks to their feedback, we've been able to tackle the needs of different user types and the scenarios they face using our apps, and then improve some elements for clarity and efficiency.
• Don't worry about the accountant jargon. Our apps speak plain English
You don't need instructions to use our apps.
• They are simple and easy to use. Doing your own bookkeeping is not overwhelming anymore
• We always call things the same way: labels are clear and consistent, so you are in control of what's going on
• The apps provide clear feedback (in plain English) of what's going on. You don't have to be a geek to use them
• Content is legible, our apps support Dynamic Type so you can adjust to your preferred reading size from your iPhone Settings
• The apps support Voice Over, you can access it from your iPhone Accessibility settings
• We've removed some complexity from our initial labels to efficient support Voice Over across the apps
• The apps provide alternative text for accessibility titles and labels
• We've tested the app with colour blind independent workers and also tested with Colour Filters, no issue raised so far, but please get in touch with us if you have any feedback that can help us improving this
• A network connection is not required to access and use the apps, so you can add expenses and incomes from anywhere, at any time
• When using Voice Over, screen titles are announced first, so the user knows where they are inside the apps. For each screen, we've considered the most efficient way to announce the content displayed
• Also, when using Voice Over, action sheets include accessibility titles to help users complete the task they were doing
The above is not a list of “accessibility features” we've included in our apps. The above hopefully means that different types of independent workers, with different access needs, can use our apps, in a similar amount of time and effort as others. That makes our apps inclusive and accessible, and we are proud of it.
The three of us launched Morphine Apps with a clear and ambitious goal: To reduce some of the pain that comes with independent working. We are confident we can help, because, as freelancers ourselves, we’ve experienced the goods and bads of flying solo.
Making a living outside the 9-to-5 cubicle is certainly rewarding, but let’s face it: running your own business can be expensive and time-consuming. We are challenged by uncertain income streams and concerns about lack of financial security. Tracking money in and out of the business is a nightmare, so many of us ignore the big elephant in the room until the end of the tax year. Then we run out of time and panic, opting to pay 30% on top of our accountant’s bill to get the bookkeeping done by their interns. If not willing to pay the extra, you end up spending long evenings (or what’s worse, weekends!) hunting receipts and invoices, filling out Excel spreadsheets and organising records in envelopes labeled by month. Sounds familiar?
So, after a few years of repeating this pattern, we started exploring ways to do this more efficiently.
12 Months later, Money In and Money Out are the first siblings in the Morphine Apps family, and there are the result of an ongoing conversation with our target users: our fellow independent workers.
Thanks to initial research with freelancers, contractors and digital nomads, we confirmed that our experiences were shared by many others, and that something could be done about it. Interviews and prototype testing with independent workers let us explore early solutions with them, and iterate designs based on their feedback.
This ongoing conversation has given us a deep understanding of the pains involved with running your independent business, and a clear vision to tackle and solve this problem in the right way, moving away from what other bookkeeping apps and accountancy software solutions are currently offering.
With Money In and Money Out apps, we hope we help reducing the pain of bookkeeping your business.
Hopefully, this is just the beginning, get in touch if you want to know more about what we do at Morphine Apps.
CoreData has been at the heart of Money Out and Money In from the very beginning. It offers a great variety of features such as data modeling tools, versioning and migrations, object graph with inheritance, powerful API that allows to run complex queries and small memory footprint.
One of the greatest additions of CoreData is ability to store data in iCloud allowing to persist data across devices. Although we read many complains about iCloud support and there is really not much told about it on the web, we decided to give it a try. Deep down we believed that things should have been fixed by iOS 9.
Unfortunately, we found that it was entirely broken. Even on a very simple model, relationships would arrive too late causing validation errors and bringing the entire sync down. Recent deprecation of Core Data iCloud didn’t come as a surprise, what’s surprising that it’s been around for so long.
We started looking for alternatives and discovered Ensembles which guarantees data consistency, multiple transports and offers global identifiers for objects which allow to identify duplicate records across devices and relink them together.
Things we learnt using Ensembles and trying to build a synchronization into our apps:
1. You cannot change global identifiers for existing objects. Instead you have to delete and add new ones, losing all relationships and breaking any references outside of CoreData too, i.e. local notification corresponding to relevant object.
2. De-duplication can be hard because sometimes you want to merge, not to just drop one object and leave the other.
3. App extensions cannot use Ensembles side-by-side with the main app. CoreData should work just fine across processes since iOS 8.2 when used from shared container, but Ensembles may not function properly.
4. Storing user settings apart from CoreData may result in data inconsistency if settings affect the way you populate database. In our apps we create financial periods over time and we re-arrange existing financial periods when relevant settings change.
5. Local notifications have to be managed each time you merge from cloud. I.e. you can’t schedule notification ahead of time and forget about it. You have to make sure it’s still relevant when you get data from other devices.
6. Seed data has to be versioned, your app should be ready to handle different versions of seed.
Over the year of development our data model has been continuously changing and growing, we’ve been spending increasingly more time on data reintegration than actually adding features. We had to make a hard decision to pull out CoreData synchronization from Money In and Money Out.
However, our users can still backup their data using standard iTunes backup or automatic backup built into iOS.