During the workshop there was ample opportunity to observe how 80 people interact with the same piece of software.

Of the 80 participants no more than 10 were from the university. While I was presenting my session I asked some technology owned questions and I found out that:

• 2 participants had an iPhone or an iPad.
• 2 participants had an android device.
• 5 participants had blackberries.
• 20 other participants had phones which could get online.
• 95% of the participants were on FaceBook.
• Everyone had a phone of some kind.
• 1 person had Windows Vista.
• The university provided 20 laptops for use at the workshop. These were all Dells with windows 7.
• There were 4 OS X users using virtual machines to run FLEx.
• One virtual environment had Windows XP.
• Everyone Else was running Windows 7.
• Only one participant's computer did not have enough RAM for FLEx.

I want to make a note on some of my observations on user experience and how that interacts with user interface for FLEx. I should say that I am really impressed with the overall features of the program. Including the video helps which are available. I only wish I had a reason to use the software in one of my own projects.

Semantic Domain list

People are dragging semantic domains around without realizing that they are dragging the items out of order. Then when they come back they don't know where the item went.

The issues is not that semantic domains are moveable. An experienced field worker may say that a certain kind of term needs to be promoted or demoted in the numeric list for various reasons. The issue here is that people are dragging and moving the list elements without realizing it. - That makes it a UX issue. However, there is also a theoretical linguistics issue with being able to modify the given semantic domain list: that is that this list represents a typological - cross language - taxonomy of words. There has been work to align this list ordering with other typological works. So if a researcher does change the position of an item as it is referenced by this list then he is moving away from compatibility and interoperability with other synced typological tools (if indeed the number is renumbered and not just graphically out of order for grouping concerns). Most indigenous dictionary workers, and some researchers using FLEx are probably not aware of this synchronization. So by moving items in the list they might be moving the items to a representation of semantics based in the language being analyzed, semantics based in their own head, or in their project work flow. These other orderings of words are not bad or wrong, they just belong in a different taxonomy. One solution to the grouping - UX issue might be to have a button or setting so that the list is returned to numeric order.

Dealing with Different Taxonomies

Considering the above there is reasons to group words in different categories based on different taxonomies. Many languages have these taxonomies they are often cultural ways of lumping things together, like is a tomato a vegetable or a fruit? Doug Fraiser, our co-presenter recommends James P Spradley's 1980 work titled Participant observation. ^[1] Spradley, James P. 1980. Participant observation. Holt, Rinehart and Winston: New York. [Link] This work deals with discovering native taxonomies. Doug was kind enough to provide a Summary of Spradley’s Method for Eliciting Semantic Taxonomies. If this could be turned into a tool for FLEx, it would be a really helpful feature for dealing with semantic taxonomies.

1. Choose some "situation" or "scene," some part of the culture limited by location, participants, and/or activities. (Examples: antang, weddings, funerals, village spring, farming, house-building, daily events in your neighbor's house, the market, etc.).
2. Describe the situation or scene. Describe the broad picture, and then specific parts of it.
3. Scan your description for domains -- i.e., for emic categories. Each domain consists of its cover term (y) and included terms (x). Kinds of domains:
   a. inclusion: x is a kind of y
   b. spatial: x is a part of (or place in) y
   c. causative: x is a result of y
   d. rationale: x is a reason for doing y
   e. purpose of location: x is a place for doing y
   f. function: x is used for y
   g. means: x is a way to do y
   h. sequence: x is a step in y
   i. attributional: x is a characteristic of y
4. Select one or more domains of interest to you, and ask questions which will tell you all the members of those domains. (Examples: What are all the kinds of leaders in your area? What are all the causes for conflict between community members? What are all the kinds of busaw?)
5. Use this data to make a taxonomic analysis -- i.e., to describe exactly what terms are subsets of other terms. See Spadley (1980), p. 120, Fig. 15.
6. Ask questions which will enable you to define the differences between terms. (You can answer these questions from your own observations, from informal discussions with neighbors, or in working with LA's). Types of questions which help are:
   a. dyadic contrast questions: "In what way are these two things different?"
   b. triadic contrast questions: "Of these three things, which two are most alike, and in what way are they different from the third?"
   c. card-sorting
   In all of this, be looking for dimensions of contrast.
7. Select some domain of importance, and make a componential analysis of it. See example of Laotian kinship terms.
8. Look for cultural themes -- any principle recurrent in a number of domains, tacit or explicit, which serves as a relationship among subsystems of cultural meaning" (Spradley). These are aspects of worldview, and are frequently called values, premises, propositions, or assumptions. Areas to consider which may reveal themes are:
   a. social conflict
   b. cultural contradictions; contradictions between values are handled by mediating themes
   c. informal techniques of social control
   d. acquisition and maintenance of status
   e. defining major problems the people are trying to solve
9. Make a cultural inventory -- i.e., an inventory of all you know about the culture, based on your observations and analyses. First make a list of the domains and themes you have observed, and of the maps, taxonomies, and componential analyses you have made. Give the page numbers where they can be found in your notes. Include revealing incidents which you can use as examples to back your observations and assertions. Survey your list of domains to see if any of them can serve as organizing domains, and use those as categories under which to make your inventory. Also index any useful reference materials in your notes.

Defining a Circumfix

Defining morphology as a circumfix was not strait forward. I was able to look it up in the helps menu but the UI was not strait forward on how to enter both parts.

Additionally there is a place in the help which says that I can use ke-...-an as apposed to ke- -an. However, I could not get ke-...-an to work.

What would be strait forward would be if the morphological type circumfix was selected that the user was shown two connected input fields, one for each part.
There was also a an inconsistency in the screen where someone is trying to define the morphological parts - there is no circumfix part.

The issue is not that a linguist with a strong theoretical background could understand that a circumfix is more than a specified paring of a prefix co-occurring with a suffix, a circumfix being more than the sum if its parts. The issue is that persons without solid linguistic training are using this software. Their linguistic knowledge base is impressionable. As humans we are affected by our environments and learning from what a computer shows me is more, and more a factor in the today's education process. So my concern is that through the user interface we are teach bad linguistics (even though that is not our intent). Also by looking at this issue it might drive us to develop a better UI for identifying the morphological parts.

Dictionary Preview

Dictionary Preview does not have auto update. (It does once the style is applied. But there is no visual style editor.)

A style preview panel would be really helpful. Something like what is under the "Show Hidden Fields" box.
This style preview box should show Lorem Ipsum for two full entries (all the fields of an entry). This way someone can see as they are hovering over yellow which parts are going to be yellow of if they are dis-including a part then they could do that. This preview could also be click sensitive so that if one left clicks on an element then they could edit the style for that element.

Two Export Formats

I had two export formats. I wanted to export a .epub file and a Webonary file. Each one was going to have different colors applied and create different displays for readers. I could not figure out how to have two separate output files in one Database project. Consider this workflow requirement: What if I want one set of data (a sub-set of my whole FLEx Database) on the web and another in print, and then want to go back and edit my web output style?

Output and connection to Sort order in the Lexicon Edit view

The output order is based on the sort order in my lexicon view. It makes some sense when one expects this but it doesn't make sense when one does not expect this. In dictionary view it might be helpful if there were a pallet available which could control sorting. This current behavior made things not intuitive to export. It does give a UI for filtering exports. It is just that filtering is different from editing styles.

Import and Export Plugins Interface

During the course of the workshop I had one person ask me how to import items from a spread sheet, I had another person ask me how to export to Open Office Document (ODT). While both of these tasks are feasible neither are intuitive for users. Both require the downloading of separate programs to handle the tasks. So if someone wanted to go from a spread sheet to an ODT the person would need three programs (Sheetswiper, FLEx and Pathway)! I asked a FLEx users advocate who works closely with the developers why the workflow system was engineered to include this level of complexity rather than to include these functionalities as optionally installed plugins. The reply I received was that the development team was trying to build a Bazaar rather than a Cathedral. If I understand this analogy correctly, I understand that the development team is trying to create many small multi-purpose tools rather than one single monstrosity of a program which has every bell and whistle. This is a noble aspiration, and does help to provide focus to the development team, which focus can be translated into simplicity of product and hopefully that is a good thing for an end-user.As I have found the Bazaar-Cathedral analogy used elsewhere, ^[2] Eric Steven Raymond. 2000. The Cathedral and the Bazaar version 3.0. http://catb.org/~esr/writings/homesteading/cathedral-bazaar/ [Accessed: 16 November 2011] [Link] it has been a reference to the mentality of the programers and the management of programers and development programs, not the options for a User Experience. As Raymond talks about the analogy, he uses it to compare the difference between UNIX and Linux development & release environments, whereas musch of the coding for UNIX, though Open Source, was developed in a black hole and then openly shared. In contrast, Linux is collaboratively developed and shared throughout the development process. Sometimes this collaboration significantly alters the development project.

Going beyond the Bazaar-Cathedral analogy, what both projects fail at, is to produce a massive user adoption. Mass user adoption is something that products like OS X, Windows, and Google Search have been able to achieve. (Though Linux has made significant strides in the past few releases of Ubuntu. Note: It is durring this same time that there have been significant improvements to the User Experience in Ubuntu.) This shows that the price point is not the most important decision in user adaption of software. I would suggest that the significant difference between the afore mentioned haves and the have-nots is the projects ability to negotiate users through use of the developed products. It is User Experience which made the iPhone and iPod touch big. Once there was wide enough adaptation of the product there was an immediate need for third party participation in the product. i.e. Not only are users entering the marketplace but now also developers are entering the market place. In terms of management it takes a precise focus on the target user groups and a commitment to adapt the production team to discover and meet the needs of the End Users. However, the problem I have when I go to a Bazaar is that I can never tell which booth is the booth selling the products I need. So I have to go to them all, figure out what they have, how they fit together, and then decide which ones I need. On top of that, I can also never tell which booth is the best deal. Usually I end up buying nothing, or going with some friends and buying whatever they buy. That means that my friends problems are now also my problems. And we have not solved the User Experience problem. However, I can usually see a Cathedral a few blocks away (It doesn't help the analogy to say that most Cathedrals I have been in are mostly empty on the inside, so perhaps the analogy should have used Wal-Mart). As an End User it is the simplicity, as I perceive it, which matters. Not the focus a particular method affords to developers. In many respects this is where the iPod as an MP3 player was so successful. It brought a simplified User Experience to the market, at a time when the market was full of useful, but complex devices.

I think I understand the conceptual model behind the Bazaar analogy, but I would like to present another model which I think users would find helpful. This model is more like an "in app purchase" (but with no financial exchange). I have seen it implemented with original version of Papers. Papers is a PDF and citation Management application on OS X.

People managing PDFs and Citation often need to import different Citation formats and also need to export their PDFs and citation to different formats.

The File menu has menus for import and export much like FLEx does. However, for importing and exporting these options are conceived of as optional plugins.

These plugins are held in a repository online, and users can choose to install them as they are needed. However, their functionality is advertised to the end-user right from inside the app. There is no need for a user to have to go do a google search to see if there is a solution. The developers already know of the solution. And the developers are providing this solution in the logical place for their users to look. The import and export menu.

Attachment of Sound Files

It seems that sound files can only be attached to entries, rather than optionally to senses. Sounds for Re-cord and Record are different, but these entries might be under the same head word.

Show hidden fields check box

A bit tongue in cheek but the Show Hidden Fields check box might be better named Pandora's Box and the activity to check it be called Open Pandora's Box

(This one is a pun guys!)

Other FLEx Issues about using it but not directly about UI

By working with the other members of the staff to make this workshop happen I realized that there is another class of users of this software. There are data collectors with a solid theoretical linguistic background, there are data collectors without a solid linguistic background, and there are users of the software who are just concerned with setting up the software and technical trouble shooting. The end goals of all of these users are very different. It does not mean that FLEx is the wrong tool it just means that the FLEx development team needs to be aware of these issues and think them through and how they are going to service these various users.

What I also learned by watching and preparing for this workshop was that there are four knowledge content areas which dictionary creators need:

1. Knowledge about Theoretical Linguistics to understand the language being described and the categories possible in the dictionary.
2. Knowledge about the language being analyzed and described so that they can apply the appropriate options available to this situation.
3. Knowledge about how to manage the editorial process for the dictionary (including entry submission).
4. Knowledge about how to use the Software to implement the editorial process.

Dev Team Communication Strategy

I noticed that the Dev team really has two different classes of target users. The technical and those who are implementing technical solutions and those who are not technical and are just end users.
They need a technical notes blog for installers at workshops. There were some errors and some issues with operating systems which would have been suitable to post about on a Dev Blog but not a product web page. This is something that I think the SIL.org web team should be able to help the FLEx team implement.

i18n or equivalent

The FLEx team needs to have an i18n or equivalent operation where people can contribute openly to the translation effort. i18n might could even be a list in the program so that people could translate the list and then sent the list to the developers for inclusion in the next build. Translation of helps and help videos needs to be considered as well. This process should be considered as part of the total communication strategy for the product.

Non-Language Database Needs

In terms of the non-technical users as distinguished above and in terms of the four knowledge areas mentioned above there are some things which would be helpful if FLEx could help accomplish. I am not sure how these things would look in terms of UI, but they are tasks in the research and dictionary development process.

Editorial Users

The dictionary development team as an editing team needs:

• They need a dictionary program goals selector (in terms of outputs).
• Decision Tree for the dictionary team (What kinds of things will be included in the dictionary?) What are the fields they are going to gather data for?
• They need an editorial review process generator.

This will give them their dictionary "program of work".
Then they will need:

• a dictionary progress process indicator.
• a stats meter for what has been done and what needs to be done.
• a dictionary decision printout to keep teams in on the "same page".

Academic Research Users

Using FLEx as a research tool in the digital age is a great help to reducing the shoebox down to bits and bytes and into actionable data. However, this is not the only set of bits and bytes bearing in on the research project. There are several other areas of bits and bytes that are very forward in the minds of researchers these include:

• PDFs contain a big portion of the knowledge being handled in the research project
• Speaker Metadata
• Audio and Photo Metadata
• Transcriptions from PRAAT and ELAN

FLEx in its current state does not have the capability to handle these data types. Nor is its bibliography field developed enough to handle a BibTex or RIS record. FLEx might not need to directly manage PDFs if it could partner through a plugin with an application like qiqqa which is designed for PDF annotation and management. FLEx should be able to handle and display (even edit) image metadata. This is imperative as we look at digital distribution of FLEx data. It is important to know what the copyright and licens agreements are with an image so that distributors of content know what they can publish. Looking at putting images in .epub and on webonary sites, one needs to know how releasing these images will affect the public. (That is what can the public do with these images if they want to?) FLEx needs to be able to import or export text with transcription applications like PRAAT and ELAN. Finally, FLEx should be able to access the computer's built-in camera so that if a contributor wanted to add a picture of themselves they could (or of an object in the dictionary).