Subscribe
Share
Share
Embed
A podcast from the ETEN Innovation Lab exploring acceleration in Bible translation. Tune in for experimentation, updates, and conversations about new methods and technologies advancing Scripture accessibility.
Isabella Scarinzi (00:03.668)
Welcome back to the Bible Translation Innovation Podcast, a show brought to you by the ETEN Innovation Lab. My name is Isabella and I am joined here by my friend Clappie and Joel. Joel hasn't been with us for a few episodes, but it's for a good cause. How's the baby at home, Joel?
Joel (00:22.983)
Thank you, Isabella. Good to be back. Yeah, we've had a good time home just settling down with baby. She's Victoria, two months old and full of smiles, enjoying our first few months with her at home. so it's lack of sleep and out of norms for our routine.
enjoying every moment of it and grateful for her.
Isabella Scarinzi (00:56.172)
Yeah.
Well, it's good to have you back here. So today we are going to talk about user experience in our Bible translation tools. We know that different cultures use tools differently. I'm from South America, is from South Asia, Clappy from North America. So we do actually have a few different regions of the world represented between the three of us here in this podcast. So Clappy and Joel are going to help us think about how as a Bible translation community, we can design tools that make sense to
people with entirely different mental models and assumptions. But first, let's get into why this matters. So what do we mean here when we say UI, UX, or user interface, user experience?
Joel (01:42.621)
Yeah, I'll take a quick stab at that. So user interface is a more surface level concept. It's what we actually see. At least that's how I would think about it as is, if you look at an app and the first few things that you notice are like the color palette or the shapes of the buttons or the icons and overall the look.
of the application is more of what the user interface is. And the user experience, on the other hand, is a deeper concept that goes beyond just the surface of the colors and the shapes of icons. It's more of how you feel even after using your app and how something gets
What are the mental models that you have developed within your app for the user to be able to accomplish something? So it requires a little more of thinking, a holistic thinking that's beyond just a screen and more of understanding who the end user is. I'll stop there.
Klappy (03:03.769)
Yeah, that's good, Joel. Yeah, sometimes we, as software developers, sometimes we relegate or task UI UX either to somebody we have on our team or to a team that we work with or even outsource it. When we're looking at user interfaces, sometimes it's easy to just delegate that, have somebody design it. And when you're looking at the user experience, like you said,
It includes emotions and it includes like so much around it. Not just, not just does somebody know where to click and how to use the app, like is it relevant to them and their culture? And you alluded to mental models and I think that's gonna be different for each of the contexts that our tool is used. And I think something that, something I've recently learned to kind of oversimplify user experience.
is what is the journey for the user to complete their objective?
and how happy or how frustrated were they along the way of completing their objective. So first, were they able to complete what they came to use your tool to do? And how enjoyable was the experience? Or how many times did they slam their laptop shut or turn their phone off and just kind of give up and come back to it later after they had to cool off?
Joel (04:36.753)
Mm-hmm.
Isabella Scarinzi (04:38.904)
So now that we have that established on what UIUX is, why do you guys think we so naturally just assume that user experience is universal? And how does that assumption break down across different cultures and different contexts?
Joel (04:58.385)
Yeah, that's a great question. I think part of the reason, at least, again, we can't make assumptions for everybody. But I would think for most people that we relate to or I relate to, part of the reason, I think, is we all end up using very popular apps developed by
big companies on our phones or on our computers that have actually some serious effort behind them in order to get a good user experience. we probably, not everybody pauses to appreciate that or even understand some of complications to be able to get to that point. And so we can take it for granted that
an app should just work and it should just do my job and get out of the way. But there is a lot of effort needed for that to be possible. And this is true for a lot of things. mean, even for physical objects, why is the door handle shaped the way it is? There are multiple designs, but you
Most people, we don't need to always think through why a door handle is shaped like that. We just use it for a minute or a second and get out of the way. Get in or get out of a room and we forget about it. But somebody really sat down and thought through, okay, what are we trying to achieve here? Where should it be placed? What is normal height of a person? And think about children. What is the amount of effort they would be able to put on this door in order to open or close it? And who are we trying to...
keep out is this internal interior door or exterior door. There's so much going on there that needs to be considered. And when we use something that is well designed, we don't always appreciate that. And so it's easy for us to kind of not appreciate good user experience. And that's something that I hope we'll be able to break down for our listeners if they aren't already familiar.
Joel (07:21.008)
in this episode to appreciate better and even give more attention to or even get more involved with, hopefully.
Klappy (07:31.179)
Yeah, Joel, you mentioned the user experience of these well-polished apps made by large companies. And we take that for granted when we use them because they just work and we don't think much about them. But those large companies, sometimes they even make mistakes in their user experience, right? As we were preparing for this, were discussing how one of the examples is Apple had
Joel (07:51.929)
Mm-hmm.
Klappy (08:00.167)
iMovie and they had Final Cut Pro. And those were two well-loved apps on two ends of the extreme of their user base. And they worked really hard to simplify Final Cut Pro as easy to use as iMovie. And in fact their goal was to get rid of iMovie and just have one, Final Cut Pro X.
So they stripped down everything, they started deleting features like Apple tends to do, right? Like they simplify things so anybody can use them. But what they did is they alienated their professional users. They deleted the features that people have relied on for a long time. And so even when these large companies spend all this time and energy in large teams over a large time period,
they can still get it wrong. They can still fail the user experience for their users. Their user base is both people expect simplicity, but also they had a niche user base who still wanted power user features. And trying to serve both of those in one tool, I think it just failed spectacularly. And they've been working ever since then trying to recover from that.
I think I see some parallels in the Bible translation world where we've worked really hard to maintain a lot of difficult complex feature sets and make it easy to use for somebody who's never seen a computer before. Somebody who's first time using a computer and as they're using it, you know, we...
Klappy (09:44.073)
We, sorry, brain just shut down for a second. Sorry, Jake, you'll have to edit this.
Joel (09:56.962)
No worries.
Klappy (09:58.592)
So making tools for a first time user and for the power users or for the experts who've been using Bible translation software for decades, it's almost impossible to make both of those user groups happy. And so there's multiple dimensions to our misunderstanding of.
user experience being universal. It's not just universal as in globally, you know, for each country and region, you know, with people thinking different.
but it's also for the experience level of our users, whether they're new to computers or they've been using computers for decades and they've already been using other software. So there's a stark contrast between our user base, what their goals, objectives are and how happy or how frustrated they get along the way trying to complete those objectives.
Isabella Scarinzi (10:55.928)
So Joel, your team has been building Fluent, which is a Bible translation app focused on serving the global church over the last few months. And you guys are testing it on the field right now. Both you, Joel, and Clapy, you also have experience of developing other apps. So based on that experience, when tools are built around the wrong user assumptions, what actually happens on the ground for translators and for local teams? If you can help us kind of paint that picture.
And what have you learned so far about this from your experience from Fluent and these other tools?
Joel (11:33.762)
Yeah, there's a lot to unpack there. But I'm happy we're talking about this. It used to be, in general, there was a lot less attention given to user experience and user interfaces. It was more about the functionality, that if it existed, that was good enough. But the reality is, until something is actually usable, it cannot become scalable.
You might get niche users for something that works, but is not very easy to use. But if it really needs to scale, you need to think through user experience. And this has become true, this has been true for the experiences I've had in the past. And this is very much our focus with Fluent as we are developing it now. One of the major...
learnings has been for us to obsess over the actual background of our user base that we are targeting. So knowing who you are making your application for is fundamental. And this is a hard choice because in some ways you want to serve everybody. And that's a good desire. But you also need to know that every time you are adding
different sorts of personas into that pool of people you want to serve, you're adding more and more complexity to be able to have a usable app for all of those different user types. And so generally, it's better to reduce scope by saying that we're only focusing on a subset of users from these sort of backgrounds, rather than saying, want to serve
all of them upfront. That's usually a recipe for disaster. So it's generally a good practice to find your focus user group. And this is also a humbling experience because it's not like, I do not believe there should be one app for everything. I really believe that we should work collaboratively to serve the full swath of needs in the
Joel (14:00.81)
in the global church. And that is, I believe, God's desire too, that we all function together in that. and fundamentally it comes down to being able to say no. This is some personalities find that easier to do than others. And I definitely have learned a lot more to say no, but I'm still learning.
This is hard because you feel like you're excluding certain user groups or needs, which are clear needs. But it's actually for the good for the app and the overall people that you are actually targeting to serve. So that's one big lesson from the past that I have learned. And I want to just also add to that that
In a sense, what I just described is what a product manager should do. So that's a role that has become indispensable more and more in successful apps, where a person needs to actually go to the end user that they are targeting, get to know them intimately, and their needs, their background, their ways of thinking through apps, or even just world models, mental models.
and mimic that in the app so that we are cutting out on training time ideally by doing that. Those are a few thoughts.
Klappy (15:37.223)
Yeah, that's great, Joel. Looking at not just fluent, but the other things that we've developed through the years, something we've regularly discussed is how tools influence process and process influences tools. In thinking about all the diversity of our partners, each partner has slightly different process that they follow in Bible translation.
And so it's been a huge struggle. Like how do we choose which processes to either bake into our app or to facilitate, to make easier, to ease the user experience for that particular process. And when we do choose one or two of them, we inadvertently alienate the other processes if it follows a different process. And saying no, who do you choose to say no to, right? Is it partner A, partner B, right? Or if we try to create this
magical tool that could possibly handle multiple processes, every time we go down that road it feels like it just balloons in complexity, like you said before. The more users you try to target and the more use cases you try to fit in and the more you don't say no, it feels like the complexities are almost exponential. There's just too many variations.
Joel (16:45.387)
Thank
Joel (17:02.773)
Yeah, mean, I'll also add, this is kind of relevant to the previous question too, but what we learned also is making a screen look shiny and nice does not cut it. I think that's good and that's important to some extent. But if your screen looks nice and shiny, but
you have to click five buttons to accomplish a task. I don't think that will, that impression of the good feeling of aesthetics will last very long. People are gonna get frustrated. And this is another thing about your tool. you know, the amount of time people spend on your tool is something to respect. If your tool is something that people
use for say five minutes a day, then actually they'll be a little more patient if they have to click through three things. cause they know this is the one time I have to use this and don't have to look at it again for the rest of the day. But if this is something that a person actually works with them for their jobs, like it's say it's a drafting tool for your translation or you spend hours on it on your workday.
then you have to really, really be careful on how you are designing this application, because that makes a huge difference on what the user is able to accomplish throughout that day. So this is also another part of knowing your end user. So in some sense, depending on how much effort that the user is going to put into your app in using it and time, you should
equivalently put that much more effort to improve the UX and UI so as to respect that time. Because time is something that none of us are going to get back. And we want to make sure people who are investing the time in using your app get their time's worth.
Klappy (19:27.034)
Yeah, that reminds me of something we talked about recently about different vehicles being used. know, there's around the world and for different use cases, there's different vehicles that we need. We have bicycles, we have cars, we have airplanes, helicopters, boats. They all serve a different use case for different, slightly different objectives, but they're still transporting us from point A to point B, helping us transport goods.
and products around the world. But when you mentioned how much time somebody spends in that, and earlier you talked about training, there's some things like a bicycle that need to just work where you hop on, you go maybe a mile or two, and then you hop off, and that's about all you need it for.
But then there are times where you need to transport goods and services. And if you're transporting 200 people in an airplane, we can tolerate maybe hundreds of hours of training to be able to use that cockpit. There are two different things on two different ends of the spectrum, all for transportation. And I think sometimes our tools, we got to find that balance of how much effort do we want to put in
training, you know, how many dozens or hundreds of hours does somebody need to be trained to use our Bible translation tools? Or does it need to be so turnkey the way they just open it and it's intuitive? Those are two separate ends of the spectrum and the question is who goes back to some of the fundamentals that you keep talking about, like who is your user, what is their specific task that they're doing at that moment?
and what is the process for that organization. And sometimes our organization handles the training. And how do we create our tools to complement the training so we don't have an additional layer of training for our tools, in addition to process training that are.
Joel (21:34.34)
Mm-hmm. Mm-hmm. Right. In fact, that actually reminds me of a relevant point is...
UI, UX should not be thought of as a static thing that just gets once done and never looked at again. As technology and the circumstances in the world changes, as it will change, we need to relook at how our users' assumptions or their level of familiarity and their normals have changed to match that better. Otherwise, you get
obsolete it because then it wouldn't be relevant to them anymore. An example, think, in the transportation world is, you know, the bicycle is really easy to use in terms of the number of controls. I you need to still figure out balance, which, you know, with some effort, a child can even. But on the other hand, a car.
needs a lot more of awareness. You know, need to, least in the US, need to be at least 16 years to even apply for a license. But then came about the motorcycle or like in some of the developing world, scooters, which we would call scooters as like motorized bicycles.
And now it's a lot more powerful than a bicycle because it can take you much further and has a few more controls, but not so much as a car. And it opened up a new area. still for the motorcycle, you need to be older. But now fast forward a lot more years, now we have battery powered bicycles, which can go like
Joel (23:42.255)
Even 40 miles per hour is kind of crazy. And now even somebody without a license can get much further with just a bicycle. All that to say, probably taking this a metaphor too far, we want to be re-looking at the reality of the world and technology as it changes often to up our UX and change our assumptions.
to allow the user to get further with lesser complications. And as time passes, this becomes more and more a reality. This reminds me even about how AI today is really a big game changer in technology, in software development especially, where we are kind of...
open to the idea of thinking of conversational UIs now. Because now we have the opportunity to actually type and talk to a computer. Now, there was, know, Siri and Google Home, I mean, that still you were able to talk to, but they seemed much less powerful. They had a few set of capabilities that they could do, but it wasn't as anything, anything as close as what LLMs can do today.
But with LLMs, you can pretty much run your computer. And if you let it, you can control a whole app. And all of this is possible today. But it's so new that I don't think anybody has established best practices for this. And so I suspect in the coming years, we'll see a lot more of conversational UIs opening up in different parts of applications that control it.
Now, then on the other side, we need to also get users to get OK with that. This is how humans would talk. We would talk to each other and tell things. But we are not so used to talking to a computer to tell it to do things. That feels weird, at least for somebody who hasn't done that often enough. mean, there are more people doing that now. So don't know, Clappy. You probably feel.
Joel (26:03.974)
No more about this, double the LLMs and AIs more recently.
Klappy (26:10.252)
Well, you the first thing I was thinking when you were explaining that, you need to constantly be revisiting your user experience. And then you went on to talk about Siri and other voice assistants and comparing it to the modern large language model experience of chatting and talking with it and it being able to do so much more.
Well, these voice assistants in our homes right now, hopefully it'll change soon. They're still limited to Siri, Alexa, Google, those tools are still the ones from five years ago. And the user experience is frustrating now because we've seen and tasted large language models, conversational LLMs that can control a full computer. But yet the best we have in our smart homes
is a static thing that hasn't been updated. And the user experience is going down fast and growing frustration there. So that was the first thing I just wanted to kind of touch on is like, what was state of the art, best in class is now frustrating to most of the users. People who loved it and swore by it and rearranged it and like redesigned their entire home around it.
Joel (27:18.744)
Mm-hmm.
Klappy (27:30.322)
Now they hate those devices and just waiting for it to be replaced. But the other thing I was thinking about is, having been using AI recently to help develop user interfaces and some proof of concepts to see what's capable and possible now, one of the use cases I've run into is testing the user experience.
through having a conversation with a large language model. So as I'm working on a tool, asking the large language model to go navigate it and see if the large language model through its vision model can actually control the app and then gauge whether or not a user would be frustrated. And then it doesn't stop there, like especially as we're looking at the conversational.
experience you were talking about with interacting with computers through conversation now and having it control everything. We now have the capacity to control things through or test our applications through conversation. So not only can we use it to control our apps, but it's becoming almost impossible to test deterministically like we're used to.
Joel (28:28.879)
Mm-hmm.
Klappy (28:52.236)
With our apps before, expected when you click this button, it has this result. When you type this into a field, it succeeds, or if you type the number where you're expecting an email, it will fail. Like there's deterministic behaviors that we've had in our user experience that are no longer feasible anymore. Using this conversational interface that we're looking at in the future of our tools, we need conversational testing.
And so being able to use an AI to create personas, different people of different education levels, oral people, not just people who know how to read, like can an oral person navigate this or converse and actually navigate and achieve their goals in what is their frustration level if they can't read. Like we can create these personas and have the large language model.
simulate a human user for us and actually have the AI create this chaos monkey to go use our tool and try to break it. One of the first things we do when we build a tool is we need QA to see if they can break it. And it becomes really difficult when it's conversation. How do you really navigate all the variations through conversation? It's infinite. So the only way to handle that is another AI.
to create personas with different objectives and different permutations of what they want to achieve. And then we just look at the statistics of how often do they achieve their goal? What's the percentage that they achieve their objective?
Were they somehow happy along the way? Like, can we gauge their user experience in that way? Or were they frustrated? Did they have to say the same thing multiple times and realize I'm not getting what I asked for? Like, what is their frustration level when they keep asking for something and our user interface or sorry, our conversational interface doesn't know how to answer it? So those are the types of experiences we're gonna have to figure out how to leverage.
Klappy (31:07.242)
AI as we create new AI-driven workflows for our users.
Isabella Scarinzi (31:16.302)
I like how there hasn't been a single episode of this podcast that we haven't talked about how AI can help make it better. So we're not ready to break that record yet. To dig deeper into something that was kind of briefly mentioned a while back, I've been hearing about this challenge between balancing scalability for tools that still served the localized context. But to get very practical, how would you guys say teams
Klappy (31:22.57)
you
Joel (31:26.647)
Thank
Isabella Scarinzi (31:46.256)
could approach designing translation tools given this challenge. Maybe if there's like a checklist, like these are the five things you should be considering, what would you say they are?
Joel (31:59.971)
That's... But... Yeah, I don't know about five things, but I definitely feel there are a few highly relevant and important things that should be done in order to make your app relevant for local context. And I think what's unique about the Bible translation app space is...
Klappy (32:00.81)
Where do you start?
Joel (32:28.479)
our user base is indeed extremely diverse. Depending on what you're trying to do, Bible translation is focused on the fringes. And so we are talking about some people who probably don't have any access to technology or are only
limited access to technology and familiarity to phones or computers. And so we have a harder task in some sense. And so we should also invest more time and effort into UX UI. Behoves us to do that. Because if you are trying to design an app for the teens in the tech world or in North America,
it would be a vastly different experience of thinking through the UX for them, because you already assume a lot of familiarity for them. That's not our case. so this has been my experience with developing one drafting tool prior to Fluent now. And we started with the basics there. We just tried to see, what is the translator trying to do?
What are they trying to accomplish in this stage? And asking that question is fundamental. It's understanding what are they trying to achieve and having a clear answer to that question is fundamental. Now, not saying that will be the only thing that a tool can do, but making sure that you have clarity on the objectives and the goals for your tool based on that feedback.
will ensure that it's actually applicable for them and it is actually made. And the other thing also we have learned along the way is the users that you may start, who may start with almost no technical background. So one of the apps I was working with initially, and even fluent right now, we want to support church, local church members.
Joel (34:51.124)
in a local community who probably have not used a computer before. They may have used a smartphone. Now you can imagine how challenging it could be for them to show them a laptop for the first time and show them a webpage and use a mouse. Now, what we have seen is that that initial week or two is hard for them to get used to that way of working. However,
almost always they seem to get used to things after that time, say after the first month. They're rather comfortable. So we all also need to think of a ramp up here. So if your tool is only focused on people who've never used a computer before, you might be actually thinking too little about your user. Your user is, you know, how...
how less experienced they may be, it's probably just because of lack of exposure. Given the right exposure and the time, they ramp up and they are able to do much more complicated things. And we have noticed that they start asking for more complicated things. And so that's even surprised us as developers, like, wait a minute, we thought that would be too difficult for you to initially think through, but no, they wanted it. They're asking for it. And that's a really good sign to build something.
at that point. And then again, understanding where do you want to position the tool, because then maybe that is a natural handoff maybe to another tool that can take them further. So it's understanding that you are not only designing to a static end user, that they also learn and are changing and evolve, and also the circumstances are evolving. So it is challenging. The UI UX needs to be revisited often.
And I would say, as part of understanding the problem, being able to also clarify the end goal of what you would like to achieve also. So as much as we want to make whatever the user is doing easy, that's great. But if ultimately if
Joel (37:13.132)
because of technology or something so the user doesn't know already, you are able to shortcut certain paths or certain work for them, then you should be also thinking through how can I actually take away parts of the process and make it automated for the user. You also have to be thinking for the end goal. What are you trying to achieve ultimately? Does the user have to follow this process at all or this part of the process? Can they switch or shift?
improve quality, can that improve speed? And those are all questions that need to be continuously answered and iteratively built on. So start with really small use case, really small feature set, and make sure that that much works on the field, and then build from there. That's usually the right way to go about building an application.
Klappy (38:14.596)
If I can add anything to that because that was a really good list there. I really enjoyed your piece, especially on not underestimating your user. the users are definitely more advanced than we give them credit for sometimes. That doesn't negate the fact that we need to make our tools intuitive.
Joel (38:28.831)
Mm-hmm.
Klappy (38:43.367)
I think so many times we go, we do a field visit, we think we understand the user and the objectives, the context that we're in, and we go off and we plan it for an extended period of time and we deploy our tool. And we have such a long time gap between when we have our touch points with the users and when we deliver solutions.
And I feel like that the most important thing we can do is have tight iterative cycles. How quickly can we get feedback from the user and feed that back into our iterations so we can continuously be improving the user experience? Because if there's one thing I learned about user experience is I have no clue about how to really, truly make the user experience.
Joel (39:27.455)
Hmm
Klappy (39:38.171)
without first building something wrong. I feel like no matter how good I thought I was delivering the user experience, when I watch the user actually use it, that's what they think about that. There's little things you're going to notice once you see somebody, your actual users, not your QA team, not your friends and family or some people that aren't on the field. Once you take it to the field, you start...
Joel (39:41.075)
Hmm.
Klappy (40:07.494)
have a real opportunity to actually see how they use it. And then you iterate and figure out how to tighten that feedback cycle because I think the worst thing we can do is think we can plan it all first and then deliver it. I think the best thing we can do is learn to iterate and fail fast. And failing is scary, right? Especially in Bible translation, people are afraid to say, fail fast.
Nobody wants to fail in delivering anything with Bible translation tools. But how do we minimize the scope of that failure? And we do that as a part of this small iterative feedback cycles. I think it really requires, I've been blessed by having good relationships with partners that are willing to test the user interfaces, willing to test the tools that we've developed together through the years.
Joel (40:56.894)
Hmm.
Klappy (41:04.336)
Believe everybody.
takes that risk of asking partners to test it early and often and get their permission to do the wrong thing. obviously you don't want to purposefully blow things up but you need to be willing to make mistakes along the way because how else can you learn? How else can you have a humble attitude to know? Because I think so many times we just get stuck
and this is what I thought I was delivering and you just keep plowing in that same direction and we're unwilling to pivot. think learning to pivot early and often is one of the best things we can do and it's not an excuse to keep making changes and not delivering product. I think that's a common misconception of fail fast and in that quick iterative process but...
I believe we'll be able to deliver more quickly to the field because we have those quick iterative cycles.
Joel (42:09.982)
I'd like to add a couple more things to what you just said, Clappy. I think that was really insightful. If among our listeners, we don't have, I mean, there are many people who are not developers. And we recognize a lot of this may be more relevant for people who are developing an application. But on the other side, based on what just Clappy shared, think if you are...
making decisions for teams on the field, on different sorts of tools, or are working with technology partners. An encouragement would be to think through setting aside some time for a few of your field members to test and try different tools and give feedback. So it's sometimes difficult to get good feedback, and most of the time it's pro bono.
So people ask, hey, could a few of your teammates try this tool out and give us feedback? And that's the only sort of parameters given. Whatever time they are actually working, they'll have to take time out of that to test something. It's not going to magically appear, ultimately. setting aside some intentional time.
for your team members to test and try and give feedback would go a long way to your technology partners, would be highly valuable for them. On the other side, if you are training or introducing tools on the field, hopefully our discussions today give you a perspective on
on how
Joel (44:07.613)
Some tools may not be a good fit for certain groups of people. You need to think through what was the intention of this tool, who was it really intended for or designed for, and what do I need to do in order to make that successfully applicable on the field? Does the tool require that there is a two-week training period? And if that is the case, I should...
schedule for that. But if it doesn't require that, and if you are already scheduling for that, maybe also not very useful. So overall, Klavi, I just want to reiterate what you mentioned there, that we are being very intentional here on iterating and thinking through and getting
honest feedback often from the field and putting it to good use in designing and developing the applications continuously.
Klappy (45:20.257)
I think, yeah, that's a part of being good stewards together, right? Like when we build tools for our partners and those who are helping fund our tools, right? We want to make sure we're being good stewards that the resources God has given us, both on the tool creation side and the people consuming the tools and using the tools and training people and...
you know, for all the Bible translation projects out there, like there's a large investment in flying people around the world to do training, right? It's not just the cost of the tools. All of this dovetails together and how we're accomplishing, you know, the greater goal of getting God's word around the world, you know, looking at, you know, as the Innovation Lab, you know, our focus is on the all access goals. And as we look at the number of languages that remain,
Yes, they are going down, which is exciting, but the growing percentage of them are oral. So we also have to look at the user experience, not just of the cultures or the experience level of people, but we do have to take into account if this tool is going to be geared for an oral culture, what does that look like?
Joel (46:22.748)
Mm-mm.
Klappy (46:46.144)
The answer for a long time has been, well, we have orthography development and there will be taught how to read. so there is a tipping point to where text-based tools will be leveraged and used, but there's this gap and it's different for each culture, but it takes a while to develop an orthography, minimum of a couple of years, and really up to a decade for somebody to be proficient in it.
but text will never be their heart language. will never be like something that they used, know, intuitively. It'll be that next generation. So we do need to consider oral first tools and not just as an afterthought, but, you know, we have good examples in the Bible translation community of oral tools and of text tools and now some hybrids. And so these are the types of
Joel (47:25.051)
Hmm.
Klappy (47:40.328)
user experiences or users and objectives and user assumptions that we're bringing into the tools we're developing.
Isabella Scarinzi (47:50.71)
Awesome. Well, this has been a great conversation so far. Thank you for listening in today. If you have any questions about today's topic, if you need some guidance, or maybe if you'd even like to share your own experience and learnings regarding user experience for BT Tools, you can send us an email at lab at etanda.bible. We hope this inspires you to have conversations about user experience within your own teams too. So don't forget to subscribe to this show, and we will see you at our next episode.
soon.