Last updates

Over the last month, we have had several meetings in which we had to take some important decisions concerning both the interface and the internal architecture of the app.

During the last meetings, we realised that the number of functionalities to be included in the app was increasing sharply, which could have a negative impact in the usability of the app. Additionally, we would like to keep the interface as user-friendly as possible and not fill the small screen of the smartphone with too much information. However, we also wanted to offer the user the possibility to customize his search as much as possible. This led us to introduce two different modes to use the app, a basic mode and an advanced mode. While the first will work in an implicit and simple way, the latter will allow the user to customize the search formula in order to obtain a certain kind of results. Some of the possible options that we talked about are:

  • Select a particular set of keywords.
  • Decide the language of the keywords.
  • Choose between including the full name of a language (e.g. German/Deutsche) or the code (e.g. de).

Regarding the interface, we also discussed what options should the user have once the results are presented. Although we still have to decide whether the link will be opened by creating a new tab within the app or by launching the default browser, we already came up with some ideas that we wish to include in the results screen:

  • Order results by a property (date, star-ranking…)
  • E-mail results
  • History of results
  • Download results (?)
  • Meta-tagging
  • Star-ranking

As regards the internal architecture, our testers reported back on the keywords and search engines (results available in the wiki, at the bottom!). All tests seem to confirm that the most suitable set of keywords is group 2: dictionary, glossary, thesaurus. In all cases, the least useful was group 3: term bank, term base, word bank, wordlist. As for the search engines, according to the testers, Bing and DuckDuckGo did not return appropriate results, so Google remains the best option.

A table of languages has been automatically generated by means of a tool that used Google Translator to perform a great number of consecutive translations (63×63 = 3.969 translations o.0). Additionally, it contains the translation of the keywords that will be included in the search formula. A Google doc has been created so that anyone can revise the spelling of the words (please do!). This will save us some time and will also allow us to include languages that could not have been covered otherwise.

Next year we will have to go into more detail in order to define more precisely the workflow and send our plan to the IT department. Let’s do it!


Game Plan

In the famous words of Benjamin Franklin, ‘by failing to prepare, you are preparing to fail’. With this in mind the App Team started by researching existing approaches to terminology searches before we began to put together a concrete model for the app.
In order to gain an understanding of the functions of terminology search systems, four group members researched the following websites:,, and Assessing the advantages and disadvantages of these websites, we began to share ideas of what we felt would be suitable and unsuitable for our Smart Phone app TermSeeker. Through these findings, we have compiled a list of priorities for the project – some areas, like precise function, have come earlier on in the process and others, like appearance and design, will be decided later on. In terms of how this research relates to our app, we will draw on the positive features of the websites, remedy the slightly less helpful elements and find what it is about our app that will make it unique. The priorities below will be addressed and the following questions answered as we work our way further into the project:

• Efficiency: Surely one of the characteristics paramount to the making of TermSeeker will be speed. In order to make an app worth using instead of a website, the process must be quick and painless. What’s the point of an app if it could be quicker to get out a computer, power it up, sign in and search for a term over a bigger screen? How can we make the app quick and easy to use?

• Accessibility: While most of our potential users would be language or translation aficionados, they may not necessarily be particularly technology-literate. There is no use in presenting a user with an over-complicated, confusing app that they can’t relate to. Using our app should be a stress-free experience – what might we need to put in place to ensure this?

• Variety of language: We haven’t decided for definite which languages will be used for TermSeeker but we are in the process of doing so. Having compiled a list of the collective languages spoken by our main module students, we hope that there should be a decent language variety on offer – watch this space!

• Fairly large database: In order to offer users a range of valid sources, we would need to be looking at a database that wouldn’t limit our search options unnecessarily. Further research will need to be done into this area.

• Possibility of searching for results in a particular category: This may be something that won’t possible until further down the line but it is something interesting to bear in mind: if users could customise and filter their search for their own needs (for example, searching for the term in using a certain country code), this would add to the flexibility and personalisation of the app. Which categories would we want to prioritise in our search options?

• Neat, slick design: Later on in the project we will work on the appearance and the design of the app. We will need to remember that, on the smaller screen of a Smart Phone, the priority would be not to overload the user with written information and to keep have a tidy, concise design. What will our logo look like? What will the layout and colour scheme be?

We hope that, as we continue on our app-making journey, the above questions will become clear!