Understanding User Context

This section is about defining the user context for FLEx. I look to the UX background and then I also look to the workflow and needs of linguists and language development practitioners.

When designing software it is important to define things like the target user. In UX we might call these personas. We give the personas a name and then some imaginary tasks and a context. We then develop imaginary senarios that each one will do and push those senarios through the software to see how the software will meet the needed tasks. UX work is then a lot of research to make accurate personas, and a lot of research to find real people that fit said personas and then to test the software with real people.

Personas

What I present here is some detailed background on one type of persona -- the language researcher. Sometimes this person might be also known as a language development worker or even a linguist. This person may be from within or from outside the ethnolinguistic community of the language being studied.

In contrast to this kind of persona, another kind of persona exists deeply engrained in the pschy of SIL International operations -- including software development. It comes from a emic-etic distinction, an insider-outsider type of distinction, an in-the-know vs. not-in-the-know type of distinction. I understand how this distinction came about socially and historically but I think that the distinction is not helpful to us at this juncture in time any more. How we (the larger "western" academic community) reference this distinction through time has changed, so I am going to describe the distinction in the next section which is taken from a blog post of mine written on 4 June 2014.

The OWL and the Rice Farmer

In a recent email I was asked by a European Linguistic Professional and SIL Colleague about the ease of use of ELAN.

Is ELAN easy enough to use, so that an Indonesian rice farmer can use it?

I am am a bit offended with the 'rice farmer' terminology which is prevalent in SIL discourse (and 'the OWL' (ordinary working linguist) term used previous to it). I am not making this up [I find the term 'rice farmer' 14 times in the wiki]([https://www.wiki.insitehome.org/dosearchsite.action?queryString="rice%20farmer"&startIndex=0&where=conf_all) and [I find "OWL" 83 times]([https://www.wiki.insitehome.org/dosearchsite.action?queryString="OWL"&startIndex=0&where=conf_all](https://www.wiki.insitehome.org/dosearchsite.action?queryString="OWL"&startIndex=0&where=conf_all)\). These terms surface mostly among SIL computer app developers, but I also hear them used by SIL policy and procedures developers, SIL program planners, and SIL educators. To me this term comes off as a class distinction term (and maybe there is nothing wrong with class distinction; I mean the Jews had class distinctions at the time of Jesus, the Cretans had classes at the time of Titus, the British have it, and castes are alive and well in India, etc.). However, as I find the term being used in SIL, we might as well just use the term 'low socio-economic and low educational capacity individual'.

The problem I have with this poropsotion and this discourse is that in my work with Steve Marlett in Mexico, I worked with ethnolinguistic monitory language users who were not 'low educational capacity individuals' rather they were high educational capacity individuals. They were teachers and educators in their communities. They were computer users and content producers. When I went to Malaysia and worked with Sean Conklin, the same thing, ethnolinguistic minority language users were not low educational capacity individuals. When I went to Nigeria and worked with people like Becky Paterson and David Rowbory, the people doing language work with us were not low educational capacity individuals. In fact the Nigerian rice farmer/pastor/student/translator/cultural guide who is on our language development team can and does use ELAN after some training (and uses Facebook without training to boot). The countires in which these ethnolinguistic monitory language live and work may have infrastructure and water supply problems, but the language development workers carry iPhones, Android phones, and tablets -- and use them. So, why then do we use terms like 'rice farmers' when we talk about designing software for users? Something seems to be wrong with this picture. My guess is that there is a real reason that we use the term, but it is not the reason that we attribute as the causation of our observation of "low educational capacity individuals" - as we observe dark skinned colleagues who try and use our software and don't intuitively know how to use the tools. My guess is that the reason that we use the term is because it is part of our corporate ethos. We use (or at least have in the past) our educational courses at various SIL training events as filters to find the 'best and brightest students' and recommend those for various field service within SIL International. Then in our advanced classes we obfuscate the materials just to make those classes harder, to see if those same students are able to still keep up. So, as I see it, there seems to be this undefined class difference in SIL's corporate sociology preferring those who can distill obfuscated communications under stress and dis-preferring those who can not distill obfuscated signals under stress.

So for the following four reasons I strongly dis-prefer the terms 'rice farmer' and 'OWL' as they often appear in SIL discourse:

1. I don't think the 'rice farmer' terminology is actually very useful for professional reasons. Software design is about communicating. It is about communicating relational concepts in a visual context. It is about connecting new analogies with salient concepts. User Interface (UI - what a software user sees and interacts with) is the gateway to User Experience (UX - the emotional, logical, task based context of activities that are attempting to be facilitated by the software designer and accomplished by the software user). Therefore what UX is really about is communicating ideas and creating positive and successful interactions. If the UI fails to create the designed UX then it doesn't matter if the user is a rice farmer or a Ph.D. candidate from an Australian university. The end result is that the user is frustrated and will not use the software willingly. Therefore, singling out the 'rice farmer' from the white guy is not really a useful construct because all users, whether black, white, tan, farmer, or stockbroker, are subject to the same constraints and frustrations of software which is not intuitively implemented. It is my experience that programmers (not just SIL programmers) usually do not intuitively know how application users think or behave. UX design is an art and a science that takes experimentation and a solid grasp of information design principles.
2. Let's not forget that, at least in software design we are talking about the 'rice farmer' with a computer, an iPad, or an android device.
3. We never use the American Corn Farmer, or the Norwegian Reindeer Rancher as analogies, and I am a bit tired of singling out people from tropical areas because their skin is darker, or their average height is shorter, or because they grow rice in their backyard. The focus on the 'rice farmer' does not help us deal with the white guy's problem with the software and robs us of a balanced view of the real problem -- people are not getting the visual analogy as it is presented to them.
4. Using the term 'rice farmer' seems to put the ethnolinguistic minority language users and nationals in a sub-standard class relative to 'real linguists' or 'real missionaries'. Yes, my African colleagues who do have their own farms and families, also use SIL software; I first drove a tractor at age 13 and grew up on a farm, so what is the difference? By making the 'OWL' or the 'rice farmer' as some uninitiated or limited capacity person, the "reason" for our new design (i.e the reason that WeSay was created to work with FLEx) doesn't solve the fact that even for white guys FLEx is still confusing. The issue is a communications issue not a smarts issue. Linguistic concepts can be communicated about simply in both in the classroom and in software.

My point here is that in SIL we need to take a deeper look at User Experience issues in the software tools and websites we build. A UX culture needs to be intergrated into our management of IT projects. We in SIL need to adopt the UX industry perspective on communication tools all rather than the perspective of "successful communication to some".¹ In my experience, the project management and project commissioner need to be sold on the need for UX testing before engineers will take steps to integrate UX considerations into the development of products. Sometimes this is why a single developer can sometimes make a more intuitive product than a team of developers (but not always).

In this way I argue against the dividion between the "linguist" and the "rice farmer" and for a singularity which I title "The Language Investigator".

The Language Investigator

So, regardless of how one gets into the business of describing languages, or the people who use those languages, we need to understand and work from a point of view which helps our software users walk through their investigation. Product production, be it a new literacy primer, or a Ph.D thesis, is more about successfully working through the process of task management than it is about studying a linguistic fact. So, what does that task management workflow look like? What should we be assuming about our software users, and what should we be helping them through in terms of successful task management?

The following diagram is a flowchart of how the language researcher should be investigating the language. Not from the perspective of the linguistic facts, but rather from the perspective of tasks to do in terms of interactions and data management.

From the perspective of the various kinds of data and what kinds of tools exist to investigate and manage that data on a per linguistic community basis we need a different kind of diagram. The following diagram introduces us to the kinds of data and the various tools which might be used to approach the ecosystem of data use in the various tasks of the language researcher. We can see that SIL has made several products which approach several different points in the ecosystem. In a later chapter I will argue that these tools need a better integration to solve the data needs of language researchers.

With these prosonas then do we need to do our marketing for a product like FLEx or do we need to market a successful ecosystem of data uses of which FLEx is on componet? Even just FLEx has an ecosystem of tools arount it's use.

¹. I am not saying that there are not reasons to use market segmentation principals, and make products for certain markets or audiences in those markets, but in terms of our software I have serviced just as many people from G8 countries as from "developing nations". The questions are generally all the same. ↩