Coursecode: 5ME11EInstitutionforMediaTechnology Level: Master Subject: SocialMediaandWebTechnologies Examdate: May30,2017 Examiner: JennyL Supervisor: NunoO Author: LinneaS -facilitatingthesearchprocessfortheusers MasterThesisDesigningandevaluatingadigita

(1)

Author: Linnea S

TRÅGEFORS

Supervisor: Nuno O

^TERO

Examiner: Jenny L

UNDBERG

Institution for Media Technology

Master Thesis

Designing and evaluating a digital

tool to support online search of

Swedish food recipes

- facilitating the search process for the users

(2)

Abstract

Searching for food recipes online is a common task for many people in an increasingly digitalised society. Sweden has, as many countries, local recipes, seasonal products, cultural dinners and measurement and weight standards that can differ from other countries. However general searches for Swedish recipes at common search engines can pose several difficulties. For example that users can’t filter the search results by recipes and that there can be difficulties with ambiguous semantic evaluations of the users’ search queries. Aspects considered in this thesis are also how the user search process could be facilitated by using recipe labels and graphical visualisations of the information. The ambition of this thesis is investigate how online recipe search can be made more efficient for people looking for Swedish recipes in Swedish.

An initial user survey with a questionnaire was conducted to understand the potential requirements for the development of a tool to support online search of Swedish recipes. More specifically, the survey inquired about users’ current search experience and tried to identify useful search criteria. The results showed that 82.4% of the participants prefer to search for recipes online via a search engine, compared with other alternatives such as searching at specific recipe sites. The main difficulty the participants experienced with that search approach was that many of the search results were not recipes but other types of search results. Most participants preferred to see more in- formative recipe items in the search results list. However at the same time, some recipe labels that were present were not actually noticed by most participants. The survey also investigated further what information that could be more appropriate to show about the recipes. Based on the outcomes from the survey study, a prototype application was then developed that targets for Swedish recipe search. The purpose of the prototype is to implement the search criteria identified from the survey and to provide enhancements. By developing this prototype, the search criteria could be tested by users on the prototype.

A second user survey with a questionnaire was then conducted, evaluating the usability of the prototype. The prototype shows to offer improvements in filtering the search results to only show Swedish recipes, presenting more relevant recipe information and also improvements in visualising the information in the recipes in the search result list.

Keywords: online recipe search, information retrieval, information visualisation, user goal

(3)

Acknowledgements

Even though I find this thesis topic relevant and in need for further investigation, I’ve had many moments of doubts in how to carry through with this research. My supervisor Nuno Otero has given me valuable support and guidance throughout the whole process.

Thanks also to Jenny Lundberg, Ilir Jusufi and Koraljka Golub for their constructive feedback on how to proceed. Members of the Media Department for support and sharing knowledge through this journey of master program studies.

I would like to give thanks to all participants in my user studies, for taken the time to answer all questions. I would also like to thank my near and dear family and friends for your engagement, encouragement and friendship.

(4)

List of Figures

1.1 A recipe search result item presented in a recipe rich card format at the

Google search engine. . . 2

1.2 A wine product presented in a recipe rich card although it’s not a recipe. 2 3.1 Overview of the methodological process and how the research questions were investigated using user studies and implementing a recipe search prototype. . . 14

3.2 The process steps of conducting the user surveys . . . 15

4.1 Front of the prototype search page . . . 20

4.2 Overview of the architecture of the prototype . . . 23

4.3 Sequence diagram of the search event in the prototype . . . 24

5.1 The startpage of the prototype v.1, searching for ’apple pie cinnamon’ . 35 5.2 The startpage of the prototype v.1 with questionnaire button . . . 36

(8)

List of Tables

5.1 Frequency of the age distribution of the participants . . . 27

5.2 Frequency distribution of the results from question 6 . . . 28

5.5 Frequency of the age distribution of the participants in the second survey 36 5.6 Frequency distribution of the results from question 6 . . . 38

(9)

Chapter 1 Introduction

1.1 Motivation

Deciding and planning on what to eat for dinner is a daily activity for many of us.

Searching for food (or drink) recipes online has become common, especially with the current increase of online digital media advancements. New search techniques emerge and software is being constantly updated with new features to support such activities, in line with the growing request for these services.

However, searching online for recipes is not as easy as one might think, especially when considering cultural specificities. For example, in Sweden there are measurement standards that are different from many English speaking countries, where most of the recipes are published. Ingredients in Swedish recipes are specified using metric volume system, for example liter and dl [1]. As other countries, Sweden also have special meals that are not as common in other countries. The meals can also vary from other countries depending on seasonal foods, local ingredients and holidays. What and how Swedes eat could also be related to eating habits due to the Swedish culture and the Swedes way of living [2]. When searching on the world wide web for recipes, the search results returned can be a long list of various search results. The search results could come from other countries but that could also be other types of websites than recipes. Such facts indeed pose difficulties to recipes’ search. As such, this suggests that there could be a need for easing the task of online recipe search for people in Sweden.

Furthermore what recipe publisher it is that created the recipes might also have an impact when deciding what recipe to choose and where to search for recipes. For example whether the user chooses to search at a search engine or whether to search for recipes at a specific recipe site. Search engines can list search results from various recipe publishers so users can choose from a broader search scope. Although filtering options are generally more precise at specific Swedish recipe sites. This thesis is considering both search approaches but is mainly exploring the search engine alternative. This alternative

(10)

Chapter 1. Introduction 1.2. Problem Domain

1.2 Problem Domain

1.2.1 Recipe Search Results

As pointed out in the previous section, searching for common Swedish recipes does not seem to be an easy task. Issues concerning the way recipes results are presented could make it difficult in some cases to find the right recipes. It could for example be difficult to determine from a long search result list which search results that are actual recipes and which results that are not. The most commonly used search engine Google [4] at www.google.com can display recipe search results in a specific food recipe format, so called recipe rich cards [5] [6]. Figure 1.1 below presents an example of one search result item in this format.

Figure 1.1: A recipe search result item presented in a recipe rich card format at the Google search engine.

With this search result format it can be easier for users to identify which items that are recipes. The recipes can be displayed with a thumbnail image, a rating score using stars, short description, calories and cooking time. In order for the search engine to recognise this recipe information, each recipe publisher needs to embed metadata with this information in the website scripts. This metadata markup is described in more detail in the next chapter in section 2.3 (Google Recipes on the Semantic Web). Unfortunately many websites publishers can misuse the recipe rich card format and use it for articles and products that are not recipes. Figure 1.2 below shows an example of a wine product that is specified as a recipe and presented in a recipe rich card at the Google search engine.

Figure 1.2: A wine product presented in a recipe rich card although it’s not a recipe.

So when a user first recognises an article in the recipe rich card in the search list, it does not necessarily mean that the article is an actual food recipe. The user might be linked to a specific food product and not to a recipe. When overviewing the search result list

(11)

Chapter 1. Introduction 1.2. Problem Domain

this makes it more difficult to evaluate which of the results are indeed recipes and which are not. In turn, the user might need to visit irrelevant websites before finding the right recipe, which could make the search process more tiresome and less pleasurable.

There can be different types of recipes though that could be valid as recipes, such as drinks and play doughs. There is no regulation of what is a valid recipe or not so this is up to the recipe publishers to decide. However the suggested recipe properties at schema.org (e.g. cookTime, nutrition, recipeCuisine) could indicate what types of recipes that are typically in mind.

1.2.2 Graphical Presentation of Online Recipe Search Results

Another issue that hinders online search of recipes is that it can be difficult to determine what type of recipe one finds by just seeing the recipe abstract in the search result list.

The Google recipe rich card does have a set of predefined recipe attributes that can be marked out specifically in the search result list. This is for example the recipe rating stars and number of voters, the preparation time and the amount of calories, visible in figure 1.1 above. However if a recipe page does not have this information marked out in the recipe web script, it can’t be visualised in a recipe rich card. When overviewing and comparing recipes in the search result list, the user might be misguided by this information (or lack of information). If certain recipes clearly have specific attributes visible in the search result list, it does not mean that other recipes does not have such attributes as well just because it’s not visible. The user would then need to visit each search result item to be sure. All recipe attributes in the specific Google recipe rich card are optional and up to the recipe publishers to specify. So there can be a wide spread of what information that is visible in the search result list between different recipe publishers.

There are also many other optional additional recipe attributes that can be specified in metadata in the recipe web page script [7]. For example recipe cuisine type (Italian, French), category type (entree, appetiser) and cooking method (grill, steaming). How- ever only the limited predefined set of attributes are valid to be visible in the recipe rich card and no other attributes. So the recipe pages may include metadata about many other recipe attributes than what is visible for the user in the search result recipe rich cards. It is considered in this thesis if this some of this ’extra’ information could be appreciated for the users to see in the search result items, as alternative attributes or additional attributes to the predefined set.

1.2.3 User Search Goal

Problematics when searching for recipes at search engines can be in misconceptions of the semantic meaning of the search queries. For example if a user is searching for

(12)

Chapter 1. Introduction 1.3. Research Questions and Hypothesis

to find. Some semantic evaluations of “pizza” could be that the user is searching for definitions of what a pizza is, or for pizza restaurants, for magazine articles about pizzas or for Swedish pizza recipes. So the user might need to refine the search query again depending on what search results are presented. This is mainly a problem with recipe searches with common search engines and usually not a problem when searching for recipes at specific recipes sites. At recipes sites, all search results are generally recipes or there can be a dedicated search for recipes.

1.2.4 Recipes with Swedish Terms

The users of a search engine can’t either know for sure if the search results will be in only Swedish language. For example the search word “pizza” again, it is spelled the same in many languages such Swedish and English. The search results returned from common search engines can be websites in any language containing the word pizza. The user might then get many search results listed that are not relevant. Google search engine has options for filtering the results by various categories, for example by Images, Maps and News. Although recipes is not listed as a category option. Google search engine also have advanced options such as for specifying the search query, for selecting Swedish language and for showing sites in the Sweden region. However this requires extra steps for the user to enter the advanced options panel and to specify those parameters. The settings also would need to be changed back again if the user wants to search for other general searches.

Even though Swedish recipe ingredients are typically specified in the metric volume system (e.g. liter and dl) [1], these measurement units could be converted online. For example with the converter integrated in the Google Web Search (e.g. with the search query ’converter cups dl’) or at Omvandla.nu [9]. But that would be extra steps when preparing the recipe and it might presumably be easier for the users to find a similar recipe that is in Swedish.

1.3 Research Questions and Hypothesis

Given the motivation and problem domain described previously, this research recognises the following research questions (RQ) that seems interesting to investigate further:

RQ1 What are the difficulties people have when searching for Swedish recipes?

RQ1a Are the search outcomes satisfactory? What specifically is satisfactory?

RQ1b If the search outcomes are not satisfactory, what are the problems?

RQ2 What criteria seem more useful to use in order to organise the information available and formatted according to the Google recipe rich card?

(13)

Chapter 1. Introduction 1.4. Thesis Disposition

RQ3 What kind of visualisation seems more appropriate to show the corresponding search results?

I believe that users can more effectively find relevant information if the search results are filtered using appropriate criteria. For example, search results could only show hits that are recipes and in the Swedish language. Furthermore, presenting the recipe search result items with graphical features can further facilitate overviewing which recipe the user is actually searching for.

Summarising, my research will focus on: (a) understanding which search criteria seem useful to people searching for Swedish recipes, (b) provide a solution that will enable an enhancement of current search outcomes and (c) convey these search outcomes in an efficient visual form.

1.4 Thesis Disposition

The thesis is structured by first presenting background knowledge and related work to this research area, section 2. Section 3, Methodology, describes the scientific approach followed and how the results were evaluated. Section 4, Technical development of the prototype, describes the technical background required for the prototype and the functionalities of the prototype search site. In section 5 the results and the analysis of the surveys are presented. Informed by the information gathered, the final prototype for the Swedish recipe site is presented in section 6. In this section the search criteria that was found for the prototype are also discussed. The final section Summary concludes the outcomes of this thesis.

(14)

Chapter 2 Background and Related Work

This section presents background information and conceptual frameworks that are investigated in order to understand user recipe retrieval patterns and to understand how the information can be represented in such way that facilitates the search process. The last sub-section presents the choice of using Google Custom Search API for accessing commonly used recipes at popular recipe sites.

2.1 Recipe Retrieval

Rose and Levinson [8] suggests a framework for categorising users’ search goals when retrieving information using common search engines. The authors clarify that with a user ’search goal’ they mean the reasons for why the user enters a particular keyword (or set of keywords) in relation to the type of search results the user expects to find. In other words, the framework correlates the users’ search goals with the search queries and the retrieved results. Rose and Levinson suggest that with such framework search queries can be better understood and in turn generate more appropriate search results.

Their framework proposes a search goal category, that seems particularly relevant for this present research effort, which they called "resource-seeking" and that, according to the authors, did not draw sufficient research work. As the term indicates, the purpose of this type of user goal is to find a resource (such as a recipe, downloading a file or using a measure converter). In three tests they found that this type of user goal is about 14.7%, 11.7% respectively 13.5 % of all user search queries, a significant amount of all common different types of search goals. However, searching for recipes is presumably a smaller subset of this "resource-seeking" category and searching for Swedish recipes most probably be an even smaller subset.

The search results that users retrieve can also be very diverse and consequently be clas- sified in various categories. Research suggests that the variety of search results can expand the users’ perspectives on the search topics [10]. However, at the same time it could perhaps also be frustrating and time consuming for the users not distinctively find what they actually search for. One possible cause for the wide range of various search

(15)

Chapter 2. Background and Related Work 2.1. Recipe Retrieval

results can be if the search query is not specified enough. Another possibility could be that the search engine ambiguously evaluates the semantic meaning of the search query.

As Golub explains [11] some reasons for why search engines does not retrieve wanted information is that a particular topic could have many different names (synonyms), a particular word could have different meanings (polysems) or a particular word could be used for completely unrelated topics (homonyms). For example the Swedish word for ’pie’ (Swedish: ’paj’) could in Swedish mean the noun pie like an apple pie, or it could also mean a verb for that something is broken. Another example (similar for other languages as well) is if a user is just searching for ’fish’ (Swedish: ’fisk’), the search engine can’t know if the user means recipes with fish, restaurants with fish in the menu, companies selling fishes, suggestions on where to go fishing, fishing equipment, people with fish (Fisk) as a surname etc.

So searching for Swedish recipes could imply several difficulties, in many cases due to that general purpose search engines are rather designed and optimised for handling other requests about more common types of search goals [3]. It seems reasonable to consider if a dedicated search engine that filters recipe search results could be more useful for Swedish recipes. So that search for recipes becomes a more efficient and pleasurable experience for the users. When using the Google Custom Search Engine (CSE) for retrieving recipes, the semantic evaluation of the user search queries are also processed by the Google CSE. So evaluating and processing natural language in search queries is not handled further in the prototype. There can still be linguistic misinterpretations of the user queries, although with the CSE the search results can be limited within the scope of Swedish food or drink recipes.

2.1.1 Site-specific Search Engine Versus Dedicated Search Engine

In contrast to a general purpose search engine, a site-specific purpose search engine is usually hosted on a certain website and it is the website publisher that provides the local search feature [12] [13]. The search scope is then usually within the website domain in where the search resides. For example www.ica.se has a search option where users can search for content available within ICA’s own site. The Google CSE can for example also be used to create a site-specific search functionality. The developer then specifies to only retrieve search content from a specific site domain. Another example of a site- specific search engine is mail clients where the mail users can search for their own content within their private mail boxes. Here the search is limited to each users own mail domain.

The term dedicated search engine is meant in this thesis a vertical search engine that can search through the entire World Wide Web (WWW) but is specialised in a specific category [3] [14]. A site-specific search engine could also be considered as a type of vertical search engine but is then specialised in a specific website or enterprise. A dedicated search engine can also be called specialised search engine [15] [3] or domain-

(16)

Chapter 2. Background and Related Work 2.1. Recipe Retrieval

but only content in a certain topic field. In this thesis, the topic field is Swedish recipes and the content is retrieved using the Google Custom Search Engine (CSE). Similar approaches, using the Google CSE, in other research projects are for example a project called FindZebra, where the Google CSE is used to develop a dedicated search engine for finding rare diseases [3]. Another example is a research project using the Google CSE to provide health information in foreign languages [18].

2.1.2 Categorising the Search Results

Heast [19] suggests that dividing recipe search results in groups by category, helps the user to overview and structure the search results. The recipes are then labeled with categories. For example recipes with only vegetables can be grouped in the category

’Vego’. Golub [11] explains that such methods and for example hierarchical indexing of the search results, could also provide orientation for the user in the terms of how the search item can be defined. This is effectively adopted in Knowledge Organisation Structures (KOS) systems. This could address the concern about ambiguously evaluated search queries, by showing the user the categorical context of the search results. An example could be when searching for ’pie’. The user could see that a pie can be used both as a dinner meal and as a desert. The user can then select a category of choice and filter out irrelevant categories.

A problem when reading results from Google Custom Search API is that each recipe publisher declare their own recipe attributes, if any, and in a custom way. So there can be different names for the same type of category that makes it difficult to group the recipes automatically. The recipes can also be updated and changed at any time by the recipe publishers. New recipes are added and some might be deleted, in a dynamic process. The number of recipe search results return from the API is also only 10 (which is motivated in the section Google Custom Search API below). So grouping the recipes in categories with such methods might not be as useful in this case. Although common recipe sites usually have options for such groupings and hierarchical trees of the categories in their own recipe banks. Whereas searching for recipes at search engines, this is generally not an option for Swedish recipes. Further user surveys in this theses intend to investigate this further, where and how most users generally prefer to search for recipes.

For example if it is at specific recipe sites or if it is by using a search engine. Also where the users are more satisfied in finding the right recipe. Offering advanced filtering mechanisms and accurate hierarchical structures might be an advantage for a recipe site but it maybe not necessary fulfil other user search criteria that are as important for the users. For example being able to compare recipes from different recipes sites with different type of recipe categorisations.

2.1.3 Labeling Recipes When Providing the Search Results

Labelling each individual recipe with attributes could be valuable feature to consider in order to give a better overview of the characteristics of each recipe. Hearst also provides

(17)

Chapter 2. Background and Related Work 2.2. Visualisation of the Recipes

perspectives in her research on possible risks in determining contradictory categories to recipes. For example the category labels ’salad’ and ’grilled’ to the same recipe can be seen as confusing, even if it might be true for recipes such as a chicken salad.

Furthermore it leads to questions whether if the recipe should be placed in the group salad or grilled or in both. If it is placed in both for example, then the meaning of the groups does not seems as relevant. If only one label is chosen out of perhaps even more other labels, then there could be difficulties in evaluating which label that is the most descriptive of the recipe. If not the recipes are correctly placed in the groups, then the groups would probably not either give an accurate overview of the recipe results.

The research refers to usability tests that shows that users do not like such disorderly groupings of categories [20] [21].

In could be important to consider how many categories to attach to the same recipe, which categories to choose and how to choose the most appropriate labels. That is, in order to not give inconsistent and contradictory labels to the recipes that might rather be confusing than clarifying. In the case of finding labels for recipe categories in the Google Custom Search API, there are several possible types of categories to choose from. For recipes marked up with structural metadata using the schema.org vocabulary, there are for example the three attributes recipe category, cuisine type and cooking method. Although the recipe cuisine type and cooking methods are very rarely declared properly in most common recipes. Furthermore, in some cases the cooking method and the recipe category are also mixed up and same terms can be used in all groups.

It could be considered to only suggest the label recipe category in this case because it is most commonly specified. The user surveys in this thesis intend to explore this further, if there is a request for more information about the recipes and which attributes to choose.

2.2 Visualisation of the Recipes

The impact of the graphic presentation of information is widely researched in the area of information and visualisation (InfoVis). Even though not as much about specifically online recipe search results. Aspects that this thesis investigates is how the visualisation of the recipes can facilitate the search process for the user. InfoVis methods can utilise the capacity of the human visual information processing when presenting the information [22] [23] [24]. So that users intuitively can perceive some information graphically.

For example the eyes have the ability to quickly overview a data set and find patterns and recognise graphical differences in features [22].

Shiffrin and Schneider [24] further distinguishe two levels of information processing, automatic detection and controlled search. Automatic detection takes place in our first impression of a target and it can be easy learned in our long-term memory. This is for example visual properties such as colours and positions. Automatic detection is also considered to be parallel in nature. In other words we can focus on other information

(18)

Chapter 2. Background and Related Work 2.3. Recipes on the Semantic Web

and we process this information more consciously and in sequence. This is for example related to how textual information is visualised. Controlled search is learned in our short-term memory and is more dependent on load. So we have more limited processing capacity for this information compared with automatic detection [23].

2.2.1 Distinguishing Labels

Rodden et al [21] shows in user tests that when searching through images that are grouped by similarity, it could be more difficult to distinguish differences between images in the same group. They declare that different groups could be easier to find but the images within the same group could be more difficult to search through. Then more randomly placed images were a better choice for distinguishing differences between ad- jacent images in juxtaposition. In the case of recipe design, having different graphic design for different labels within the same recipe could presumingly also make the different labels stand out more so that they are easier to distinguish when overviewing each recipe. Likewise when comparing different recipes based on a specific attribute, such graphics could presumingly help the user in easier finding other recipes with the same characteristic type of label.

This could be applied by for example highlighting certain attributes using background colours. So that the eye catches that a certain background colour represents a certain attribute [25] [26]. This could also be an example of information that is processed with the before mentioned automatic detection. The label preparation time could for example be displayed with a certain background colour and the recipe meal type category with another background colour.

2.3 Recipes on the Semantic Web

The specific Google recipe rich cards that can be visible in the search result list, can be displayed as individual cards as in figure 1.1 (Introduction section) and multiple recipes from the same recipe publisher can also be displayed in a host carousel. The recipe rich cards can be created by the Google search engine if the recipe developers have marked up the recipes with structured data [5]. The structured data can be embedded in the recipe implementations with for example RDFa or JSON-LD encodings and by using name and type conventions from the schema.org vocabulary [27]. With additional structured data in AMP, the Rich Cards can also be rendered efficiently on mobile devices [28]. The Google search engine can then find this metadata markup in the semantic web [29] and generate the specific recipe rich cards. Certain markup items are required for proper rendering of a recipe rich card but the names of the attributes and how the markup is implement, can also vary between different recipe publishers.

(19)

2.3.1 Google Custom Search API

The Google Custom Search API [30] can be used for retrieving Google search results for custom purposes. In this case for gathering Swedish recipe search results. With this API, a user search query can be included in the API call and the search results returned are gathered using a Google Custom Search Engine (CSE). The developer initiates the CSE and can then specify to only retrieve search results that have been marked up as recipes and in Swedish language [5]. The procedures for setting up this environment for this thesis are described further in the Prototype Development section.

Recipe search information available in Google Custom Search API:s is free for developers to apply in new software solutions. Using these API results, developers does not need to write own recipes or need to have access to a proprietary recipe bank in order to build a recipe search site. A new site can be built reusing already existing popular recipe resources. Thus the development process becomes more effective, focusing on refining a recipe search for more specific purposes.

The full recipes can be read at the recipe publishers own sites, but there is much information about the recipes that is accessible via the API and that can be presented in a customised search result list. All the information that is presented in the search results list at google.com, is also included in the response from the Google Custom Search API.

There can also be more additional information included in the response from the API than what is shown in the search results list at google.com. Most information about the recipes from the API are gathered from the recipe metadata on the semantic web. So how much information about the recipe that is included in the API response depends on how much information the recipe publishers declares in the recipe script metadata.

However not all information about the recipes needs to be presented to the user in the search result list. Presenting more information is not always better [31] [32]. The problem is rather in understanding what information that is most relevant for the users in the context of searching for recipes. Furthermore facilitating for the users in finding the information they want to know. The users surveys in this thesis are intended to continue investigating this, what attributes that seems most useful and if alternative visualisations of the attributes could be more appropriate.

2.3.2 The Search Result List

The results listed from the Custom Search API can vary from search results at the Google Web Search at google.com. This is due to how the CSE is specified by the developer but even if the CSE is set for the entire web, the content could vary between the searches [33]. This is due to the conditions for how the Google Web Search is run- ning compared with the CSE. For example the CSE results does not include universal search, social features, or personalised results, as the Google Web Search does. This can effect which of the search results are more prioritised to send back in the Custom

(20)

The number of search results returned from the Custom Search API is also limited to maximum 10 per request [34] but could be extended by multiple calls. Donald O. Case writes in his book Looking for Information: A Survey of Research on Information Seek- ing, Needs and Behaviour [31] about the decision making process when we evaluate search alternatives. He writes that if the number of alternatives and their attributes ex- ceeds above 10, we can experience overload. We then tend to choose simpler and less reliable rules when making our choices, so our search time can be shortened. An ex- amples of such ’rule’ can be to only examine one of the attributes. That is the attribute that we decide to be the most important. This is a type of lexicographic rule, where all other attributes does not matter in comparison to the one chosen attribute. In the case of recipe search, one attribute to choose to compare with could be the recipe preparation time. The user then focus on finding only this time attribute in all the recipe information. So the user does not takes the time to process other attributes or information about the recipes. To instead facilitate for the users in processing and evaluation multiple attributes about the recipes, reasonable amount of attributes and search results could be preferred to be presented. As work by Donald O. Cases suggests, showing maximum 10 recipe results listed could be appropriate. This could presumingly increase the likeli- hood in more effectively finding the right recipe. That is if more attributes can be taken into consideration more easily at the same time. So that the recipes can be compared by more factors, before making a decision to choose a specific recipe.

(21)

Chapter 3 Methodology

3.1 Methodology Overview

To investigate the research questions in this thesis (section 1.3), two user surveys were conducted and a recipe search prototype was developed. Figure 3.1 below illustrates an overview of the methodology process. The first user survey attempts to explore research question 1 and 2. The purpose of this survey is to understand the users’ current experiences when searching online for food recipes. For example conveying problems and possible improvements in user experience and design.

Based on the outcomes from the first user study, a set of useful search criteria were identified. The search criteria describes potential requirement when developing the site to support search of Swedish recipes. The search criteria were then implemented in a first version of the recipe search prototype (prototype v.1). The purpose of prototype v.1 is to provide an enhanced search solution to the current user search experience.

Research question 3 is explored by a second user survey. In this survey, the user experience of prototype v.1 is inquired. The results from this study is used for evaluating if the developed design features are efficient for the user in finding Swedish recipes. Poten- tial points of improvements could then be refined in a second version of the prototype (prototype v.2).

(22)

Chapter 3. Methodology 3.2. Data Collection with Questionnaires

Figure 3.1: Overview of the methodological process and how the research questions were investigated using user studies and implementing a recipe search prototype.

3.2 Data Collection with Questionnaires

3.2.1 Questionnaires

Questionnaires is one of the most popular research methods for gathering user data [35][36]. Some of the reasons for why questionnaires have been chosen as a data collection method in this theses, is that they can give an overview relatively fast of what general opinions a large number of users have and of what problems users may have with a certain technology [35]. Compared with for example verbal interviews, questionnaires can be performed at low costs, relatively time effective and with less effort for both the participant and the person issues the test. The questionnaires can be sent to many users at the same time and the users can perform the test at times that they prefer.

There can also be less interviewer bias, since the answers otherwise could depend on how the questions are asked [36]. The answers to closed questions can also be coded and analysed relatively quickly.

(23)

There are also aspects with user surveys with questionnaires that needs to be considered in order to improve the validity and generalisability of the survey. Such as considering the sample size and selecting a random sample. Furthermore asking relevant questions and not take the participants time with many questions that does not provide the research with any relevant information. The process steps are illustrated in figure 3.2 below.

Figure 3.2: The process steps of conducting the user surveys

(24)

3.2.2 UX

Evaluating the User Experience (UX) of recipe search sites is a broad field involving many aspects. Hassenzahl describes UX that it shifts the attention away from technical aspect of a product (or website) to the users and feelings, taking into account more subjective sides when using the product [37]. That is focusing on the drivers for a satisfying experience, meeting both pragmatic and hedonic user goals [38]. UXnet.org defines UX as "the quality of experience a person has when interacting with a specific design" [39]. These perspectives on UX are considered when designing the questions about of the recipe sites in the questionnaires.

3.2.3 Pilot Tests

Pilot tests were be conducted in the design phase of the questionnaires [36]. The pilot tests were used for pre-testing and evaluating the questionnaires, before the real actual user study was conducted. The pilot testers filled in a preliminary questionnaire and tried out the online tool in which the questionnaires were written. Afterwards, the testers were asked verbally a set of questions about the questionnaire. Those questions are listed in Appendix C. The questionnaires were then amended and refined in consideration to the feedback.

3.2.4 User Group Selection

The questionnaires were conducted in the city of Helsingborg in Sweden. This city was chosen for practical and monetary reasons since this thesis is written in this city. The questionnaires were given to people at the city library, the central station, the University campus, at busses, shared on social media and some questionnaires were sent to persons by mail. The questionnaires were delivered in this way to select a random and diverse group of users in various ages and genders.

3.2.5 Design of the First User Survey of Current Recipe Search

The purpose of this user survey was to understand users’ current experience of searching for Swedish recipes online. The questions were designed to bring information from the users regarding the research questions 1 and 2. The pre-test of the questionnaire gave feedback on several aspects. One pilot tester had questions about the options to the first question of the gender. The tester thought that the options ’trans*’ and ’Other’ could be discarded because the tester found no reason for having those options. The tester suggested to only offer the options ’male’ or ’female’. That suggestion of removing

’trans*’ was discarded because if a user is trans* then that user would not have any right option to choose from. So then the answers to that question would not represent a correct response from all participants. Contrariwise the option ’Other’ was removed as the user suggested because this option seems unnecessary and covered by the other

(25)

Chapter 3. Methodology 3.3. Developing a Prototype

options. One pilot tester suggested to change the order of question 10, to its current position from order number 11. This suggestion seemed reasonable since then the next question 11 could be refined to be a follow up question to that question. Two other questions were also suggested to be clarified further. None of the pilot testers thought that there were to many questions, they thought it took reasonable time to answer. The final questionnaire can be seen in Appendix A. The questionnaire translated to English can be seen in the section A.1. The original questionnaire in Swedish is in section A.2.

3.2.6 Design of the Questionnaire of the Prototype

The questions in the second questionnaire are designed to bring information about if the users find the visualisations in the prototype to be more appropriate for showing the resulting search results. That is if the search criteria implemented in the prototype are found to provide improvements on the problems found in the first user survey.

The pre-test of this questionnaire was carried out with the same procedures as the first questionnaire. Three testers participated in this test also. The questions asked to the participants after the test were also the same, listed in Appendix C. One pilot tester thought that the Swedish word ’etikett’, that is ’label’ in English, was a bit confusing.

So these questions containing ’label’ were clarified. Otherwise all pilot-testers thought that the questions were easy to understand, they had no other specific suggestions for improvements and they thought that there was a reasonable number of questions in the questionnaire.

The final questionnaire of this second 2 is presented in Appendix B. The questionnaire translated to English can be seen in section B.1. The original questionnaire in Swedish can be seen in section B.2.

3.3 Developing a Prototype

The results from the studies were used to inform the development of the prototype.

The prototype is a website application targeting the search of Swedish recipes. It was developed in an iterative and cyclic process approach. A basic structure of an initial prototype was first created in an early phase, to explore the technical settings and to get practical knowledge to some of the background material that was investigated. The prototype was then developed further in accordance with the theoretical base of this thesis and with the outcomes from the surveys. The prototype is applying the search criteria found and the criteria could be tried out by the users on the prototype. The user experiences of searching for recipes at the prototype site were evaluated in the second survey with a questionnaire.

(26)

Chapter 3. Methodology 3.4. Scientific Approach

3.4 Scientific Approach

The scientific approach of this thesis is mainly inductive. The research idea has emerged from own experiences and from observations of other how people are search for Swedish food recipes online. From these observations, the research questions were formulated.

The research questions were further investigated with literature review and by using user studies with questionnaires. With the questionnaires both qualitative and quantita- tive information could be gathered from the users. The questions in both surveys were formulated with emphasis in exploring the user experience of the search sites. That is to find preferred search patterns and possible points of improvements in order to support common online Swedish recipe search.

3.5 Analytical Methods

The collected data from the user surveys were analysed using descriptive statistics. With this type of statistical tools, the information from the surveys could be organised and summarised to describe the main features of the information [40]. For example for determining which types of recipe labels that seemed most appreciated for an average user. Descriptive statistics can also be useful when comparing data across domains, where domain specific details are not as significant [36]. For example when evaluating and comparing the results from the first and the second user study in this thesis. Ex- amples of statistical tools that were used when assessing the responses are measures of central tendency, spread and frequency distribution. The analysis of the results are further described in more detail in the section 5, Results and Analysis.

(27)

Chapter 4 Development of the Prototype

A prototype is developed to apply the search criteria found in the user studies. The final result of the prototype recipe search application can be seen in section 7 Proposed Swedish recipe search. This section describes the underlying development process and the technical background of building the prototype.

4.1 Website Functionalities

The prototype website is to be used for searching for Swedish recipes. The search results are refined to only show recipes and only Swedish recipes. Some recipes may be written in English but then the measurements are usually translated in Swedish, for example that 1 cup = 2,4 dl. The search queries can be a recipe name, ingredients or other optional search words. The search results are listed with maximum 10 search results, depending on how many matching search results that are found. What information that is shown about the recipes in the search result list, is based on the user responses that are gathered from the user surveys. At the start page of the application, there is also a top menu tab labeled ’About’, where the user can read more about the background of the project.

Figure 4.1 below shows an image of the top of the prototype start page.

(28)

Chapter 4. Development of the Prototype 4.2. Technical Environment

Figure 4.1: Front of the prototype search page

4.2 Technical Environment

The prototype website is implemented in the server side framework and runtime environment Node.js [41]. This environment is chosen mainly for its effective event-driven execution flow and for being able to handling multiple concurrent I/O operations [42], for example to external API:s. Also for using the JavaScript language from the server side to the client side. This subsection further describes the motivations and background knowledge for the choice of using the Node.js runtime environment.

4.2.1 Event-Driven

The Node.js framework is event-driven, starting from the server level when setting up the application [43]. So it is events that triggers the execution flow of the process tasks in the application. An event can be triggered for example when a user enters a URL request to see the prototype site in the browser, or when the user clicks on the search button on the site. The events are handled in a single threaded event loop. The event loop handles the events in order by which event that has highest priority importance [43]. So if there are many events, they are piled in a queue while waiting for the event loop to accept the next event.

(29)

Chapter 4. Development of the Prototype 4.2. Technical Environment

4.2.2 Asynchronous Execution Flow

The execution flow of the process tasks in Node.js is asynchronous [42] [44]. So the execution of the source code is not run from the top lines of the code to the bottom lines as in synchronous environments. In Node.js, one event could trigger the application to make an I/O request to an external API. The event loop thread is then free to continue executing the next event, even if the API has no responded yet [44]. When the API has responded, a new event is triggered. The event thread can then ’go back’ or rather continue with executing a callback function that handles the API response data. The asynchronous behaviour makes the single threaded event loop in NodeJS non blocking, continuously executing code and available to receive new events.

4.2.3 Concurrent Handling of External API Calls

The non-blocking behaviour of the asynchronous event loop, makes Node.js effective for I/O intensive operations [43] [44] [45]. Such as in this theses, the operation of con- necting to the Google Custom Search API. The single threaded event loop can continue executing other events while waiting for the API resource to respond [44]. Events that can be executed faster, can be executed in the meantime. So the whole process thread doesn’t have to be idle and wait for the I/O response from the external API, as in synchronous environments. This means that the event driven system of Node.js can handle several concurrent connections to external API:s [42] and make use of the CPU time more efficiently.

4.2.4 Handling of CPU Resources

The single threaded event loop is not as efficient when occupying the thread with CPU intensive operations [45]. The single thread would then be busy computing that processing intensive task so it would be prevented to execute other events. The thread would still be busy executing the CPU intensive task, so it wouldn’t be blocked in that sense but all other events would have to wait until the CPU intensive task is performed. If there is a need for processing more CPU intensive tasks or when scaling the usage of the prototype further, other solutions for concurrent execution and load balancing could be preferred. For example distributing clusters of Node processes in different processor cores [43]. So that all cores in multiple-core processors can be utilised.

The single threaded event loop in Node.js has also offers possibilities in using the CPU resources more efficiently. As in the example of receiving many I/O requests from many users [45] [43]. Then the application does not need to allocate a new CPU runtime scope or memory for each new thread process, as in multithreaded solutions. In the case of I/O related requests there is no need for allocating unnecessary extra CPU or memory resources to each new request to an external API. The overall I/O waiting time would

(30)

Chapter 4. Development of the Prototype 4.3. Architecture

4.2.5 One Language, JavaScript

In the Node.js framework all code can be written in JavaScript. Together with additional web frameworks such as Express.js, the JavaScript language can be used for setting up a web application environment on the server side as well as for creating the client side frontend. The runtime execution of the JavaScripts is performed by the fastest JavaScript compiler [43], the open source Google Chrome V8 engine [46].

4.3 Architecture

The frontend of the prototype website page is created using the Express.js template engine EJS [47] together with HTML, JavaScript, jQuery, CSS and Bootstrap. The design of the website is described further in the section 4.5 below. An overview of the architectural design of the implementation is presented in figure 4.2 below.

The prototype application has a router that first receives all HTTP requests to the site.

The routing mechanisms are implemented with the Router tool that is built in with the Express.js framework [48]. The router can for example receive URL requests from the user’s browser URL address bar to see the start page. Or there can be requests to server services that are triggered from the application. The router then directs the requests to the controller through a RESTful interface. This interface is chosen to provide an additional abstraction for separation of concerns for easier maintenance and scalabil- ity. Different types of functionalities also share the same interface in a more coherent and structured way. The server side functionalities are not either exposed directly for external users.

(31)

Figure 4.2: Overview of the architecture of the prototype

The controller deals with logics related to the requests and delegates tasks to server side modules of the application that executes the tasks. The server modules handles information from the external service Google Custom Search API and processes the search results.

Figure 4.3 below pictures a sequence diagram that illustrates in more detail the event flow after a user presses the search button and searches for a recipe key word in the prototype site. The website then makes a jQuery call to request information from a server side module. A HTTP GET request is then sent to the router which redirects the request to the controller. The controller passes on the request to the server side module that makes the connection call to the external Google Custom Search API. The response data is in JSON format and returned to the controller. The controller delegates the search results to a second server side module that processes the response data further.

(32)

Figure 4.3: Sequence diagram of the search event in the prototype

When the search results are processed, the selected data is sent back to the controller.

The controller passes on the data to the router which returns it to the jQuery function that initiated the request. When the website frontend has received the search results from the website backend, the recipes can be presented for the client user.

(33)

Chapter 4. Development of the Prototype 4.4. Design

4.4 Design

The layout of the prototype is created using Bootstrap framework at the frontend side.

CSS is also used for additional custom styling of the prototype webpage. For example when creating the recipe labels. Different types of recipe properties are considered to be designed with different label background colours. For example the recipe property preparation time has a certain background colour and another recipe property has another background colour. So that the labels with certain type of property is easier to distinguish. What labels to include, if any, is decided later or after analysing the results form the first user study.

4.5 Recipe Search Results

The search results are retrieved through the Google Custom Search API [30] by using a Custom Search Engine [30]. In the CSE the developer can specify what sites on the web that are included in the search scope. In this case all domains with .se and .nu are included. Sites can also be included explicitly, such as the common Swedish recipe site at www.tasteline.com. In the same way certain sites can also be excluded. In the CSE it can also be declared to only retrieve search results from sites that are hosted in Swedish, in Swedish. Furthermore it can also be specified to only search for web pages that are marked up with structured metadata as recipes. Although as mentioned before the recipe specifications can be misused for types of websites that are not actually recipes. There can also be some sites retrieved that may still be written in English.

So additional filtering and processing of the search results are needed to implement programmatically. The results are also checked manually while developing, to include at least all the most common Swedish recipe sites, blogs and recipe publishers. The recipe site can be accessed at https://swedish-recipe-search.herokuapp.com/.

(34)

Chapter 5 Results and Analysis

5.1 Initial User Survey Concerning the Use of Common

Search Engines for Recipe Search

The first survey is considered as the initial attempt to understand the requirements users could have when searching online for Swedish recipes. The survey results are presented and analysed in this section in order to grasp user search patterns and common difficulties with current search solutions. The requirements that are found are formulated in a set of search criteria that are suggested to be useful when developing a tool to support Swedish recipe search online.

5.1.1 Demographics

The first survey was conducted in Helsingborg city in Sweden, at public places such as at the library, at the central station, at busses and some also sent by email. 41 persons participated, whereof 60.0% females and 40.0% males. Their ages were quite evenly distributed as shown in frequency table 5.1 below. Most participants, 24.4 %, were in the age group 25-35 (median 35-45, standard deviation 1.82).

(35)

Chapter 5. Results and Analysis

5.1. Initial User Survey Concerning the Use of Common Search Engines for Recipe Search

Table 5.1: Frequency of the age distribution of the participants

Age group Frequency Percentage

under 18 1 2.4

18-25 9 22.0

25-35 10 24.4

35-45 6 14.6

45-55 4 9.8

55-65 5 12.2

65+ 6 14.6

5.1.2 User Recipe Search

In the third question the participants were asked how often they search for Swedish recipes online. This question was asked to find out if there is any request for searching online for recipes and how common it is. The results show that most participants, 37.5%, search for recipes online a couple of times a month, 30.0% search for recipes a couple of times a week and 25.0% less than once every 6 months. These results show that most of the participants search for Swedish recipes online quite often, on a monthly or weekly basis. The participants ages does not correlate to how often they search for recipes online. Their experiences of their recipe searches are investigated further with the results of the following questions.

The main reason for why 60.0% of the participants search for recipes online is to find a recipe to cook. 17.5% answered that they search for recipes mainly for inspiration, not primarily for cooking the recipe. 17.5% for finding information and advices, not either primarily for cooking the recipes. The participants that did answer that they search for recipes for inspiration and information, it may indicate that it is not only the recipe instruction that is important for those participants but presumingly also how the recipes are presented. The results from this question show that a clear majority of the participants seems to search for recipes that they can cook and are not as interested in other types of related information about the recipes. When searching at search engines it then might be considered negative if many of the search results returned are in a variety of different types of websites. Following questions later on will examine this further, when inquiring the users about searching for recipes at a search engine.

(36)

The next question regarded how the participants usually search for recipes. If it is by using a search engine first or if it is by going directly to a specific recipe site and search for recipes there. The results shows that the most common way for the participants to search for recipes is by searching via a search engine first. A clear majority of 82.5%

of the participants had selected this alternative. Only 12.5% of the participants prefer to go directly to a specific recipe site when searching for recipes. Two participants had written a free text in the option ’Others’. One participant specified that he/she used ICA recipe site and one participant had answered that it is his wife that chooses where to search. No participant had mentioned about searching for recipes at other alternatives such as at recipe apps, Social Media or at YouTube. There could have been specific options for these alternatives in the questionnaire which unfortunately was thought of to late in the survey process.

5.1.3 Searching at a Specific Recipe Site

When the participants do search for recipes at a specific recipe site, it’s quite common to also search for the same recipe again at other recipes sites. 45.9% answered that they do so sometimes and 16.2% ’yes, often’. They then start the search process again at another site as well. Only 13.5% answered ’No, I usually find the recipe I’m searching for at the first recipe site I go to’. These results show that the participants does not seem so satisfied with the search results when only searching at one specific recipe site directly. Table 5.2 below shows all the results (standard deviation 1.30, mode alternative 1, spread: 4). The next question investigates this further, the reasons for searching again at other recipe sites and if it is something that they are not satisfied with.

Table 5.2: Frequency distribution of the results from question 6

6. Do you usually search for the same recipe at other sites also?

Alternative Frequency Percentage

yes, sometimes 17 45.9

yes, often 6 16.2

no, I usually don’t bother searching again at another site, even if there might be better recipes. I’d rather choose a recipe from the first recipe site i visit

7 18.9

No, I usually find the recipe I’m searching for at the first recipe site I go to

5 13.5

Other 2 5.4

(37)

If the participants had answered yes to that question, they were asked a follow-up question what the reason for that was. The main reason for why 35.7% of the participants searched for the same recipe again at other recipe sites, was to compare the recipe with other recipes at other sites. This indicates that it doesn’t seem to be only one specific recipe site that most participants go to regardless of all other alternative recipe sites. The participants rather look for other alternatives at other recipe sites as well. 28.6% of the participants answered that their main reason was to find alternative solutions and com- plete the recipe. 21.4% answered that it was because they didn’t find the right recipe at the recipe site. 10.7% answered that it was because the recipes they found didn’t seem appealing.

5.1.4 Searching via a Search Engine

When searching for recipes via a search engine, Google is by far the most commonly used. 94.9% of the participants use the Google search engine. Searching by recipe name and by ingredients are the most common type of search queries that the participants use when searching for recipes. 43.3% of the participants answered that search by recipe name and 30.0% that they search by ingredients. 10.0% search by recipe category, 5.0%

search by fast cooked recipes and 5.0% search by recipe site publisher name (mode:

ingredients, standard deviation 1.67, spread 6).

In question 10 the participants were asked how well they consider that their search results match their search requests. They answered in a scale from 1 to 5 where 1 is

’never matches well’ and 5 is ’always matches well’. In average the participants gave the score 3.70 (mode 4, median 4, spread 4, standard deviation 0.72). This result seems to indicate that the participants are quite satisfied with the search results they get but it could be better. The following question investigated this further and the participants were asked if there is something that they are not satisfied with about the search results they get. If so, what it is. The main issue that 37.5% of the participants had selected is that they think that many of the search results are not recipes but links to other types of websites. 25.0% think that it is difficult to see just in the search results list what type of recipe it is. 12.5% think that there are too few relevant search results. Table 5.3 below shows all the results (standard deviation 2.00, mode is alternative 1, spread 6).

(38)

11. Is there something that you are not satisfied with about the search results you get? If so, what are the main issues?

Alternative Frequency Valid

Percent Many of the search results are not

recipes but links to other articles 15 37.5 it’s difficult to see just in the search

result list what type of recipe it is 10 25.0 many of the recipes are not in

Swedish although I search in Swedish search words

3 7.5

it’s generally difficult to search for recipes at search engines. I prefer to directly visit recipe sites that I like instead

2 5.0

there are too few relevant

alternatives 5 12.5

Other (’satisfied’) 2 5.0

Other 3 7.5

5.1.5 Design of Recipe Properties and Labels

On the question about how satisfied the participants are with the design of how the search results are listed in the search result list, most of the participants were quite satisfied. The average rating score is 3.5 out of 5, where 1 is not satisfied and 5 is satisfied (mode 3, median 3, spread 3, standard deviation 0.78).

In question 13, the participants were asked to choose which design they prefer of the recipes presented in the search result list. The alternatives can be seen in Appendix A.

All recipes have by default a name (title), URL and short description. A majority 43.9%

of the participants choose the last alternative where all additional recipe attributes were included. That is thumbnail image, rating stars and number of reviewers, preparation time and amount of calories. In contrast, the second most common alternative with 26.8% of the participants is the first alternative where there is only the recipe name,

(39)

URL address and the short description presented. The third most selected recipe format with 12.2% was alternative 3, with the additional attribute preparation time. The spread results of this question could be helped clarified by the next question asking the participants specifically if there is any of the attributes that they consider could be removed.

The attribute that 43.2% of the participants thought could be removed was the amount of calories. 16.2% thought that the number of ratings and reviewers could be removed and 13.5% of the participants would remove the preparation time. Since most participants choose the alternative 5 with all the recipe attributes listed, it could still be considered that most users agree that those attributes are useful. If one attribute is to be removed it could be considered to be the amount of calories. In question 14 the participants were asked if they had noticed the grey parameters before, that is the number of reviewers, the amount of calories and the preparation time. 42.5% of the participants had not noticed these parameters before. This seems like quite a large proportion of the participants, considering that these parameters are available in the Google search engine which a clear majority of the participants use quite regularly. One reasons could presumingly be that not all recipes have these parameters specified. Perhaps also that the labels are not marked out clearly enough. 35.0% agreed that the parameters were sometimes useful and 15.0% had seen the parameters but usually don’t read them.

The last question was concerning if the participants would choose any additional parameter. Table 5.4 below shows the results from these answers. Most commonly chosen parameter was the main ingredients and recipe category (Standard deviation: 1.18.

Mode and median: "main ingredients". Spread: 5).

16. Had you preferred any of these parameters listed below?

Either as extra parameters to the existing ones or replacing some of them