Difference between revisions of "Folksonomy Engine/Mobile use cases"

From Open Food Facts wiki
Jump to navigation Jump to search
(Page creation)
 
(Categories)
 
Line 109: Line 109:
 
* The system shows the languages available.
 
* The system shows the languages available.
 
* The user select a language.
 
* The user select a language.
 +
[[Category:Folksonomy Engine]]
 +
[[Category:Mobile]]

Latest revision as of 11:49, 14 December 2021

Rendering and collecting rich data is really difficult on mobile devices, and we have to find some ways to integrate part of the Folksonomy engine freedom to mobile usages.

Massive crowdsourcing made simple

A new product currently requires 4 or 5 minutes to be completed: more than 30 fields have to completed in Open Food Facts.

On the one hand, we know that some users do not want to follow this complete process. On the other hand, many usages would only need a few fields to be completed. We can also look at the success of very simple interfaces to crowdsourcing some data in diverse collaborative projects.

In OpenStreetMap, for example, we can see many "vertical" apps or some apps with an easy way to collect data:

Zooniverse also propose dozens of projects to let people complete classifications based on very simple UI.

Like all those easy to use vertical apps, Folksonomy Engine allows to create vertical apps for very simple usages. Here are some examples.

1. The (name your place) inventory

Here we can find 2 mains use cases:

  1. making a whole inventory of every product: 5 XXX, 6 YYY, 3 ZZZ
  2. making an inventory of types of products: XXX, YYY, ZZZ

Use case (1) allows to manage stocks (of a shop, ...).

2. The (name your property) inventory

In this use case, contributors want to collect a certain type of data. Each time you identify the data, just scan and confirm. Here are some examples.

  • Fresh fruits with a plastic packaging.
  • Products seen on TV.

This use case has endless usages and types of usages:

  • journalists or people interested in a particular topic
  • people fighting against something
  • researchers identifying some kind of products
  • collectors who hoard certain types of products
  • people who are bored and are just looking for a way to have a good time.

Is my product (... fill your need ...)

Many users do not want to know all the data from Open Food Facts. They just want to know if this particular product is:

  • still eatable
  • suited for children
  • suited for a pregnant woman
  • not recalled by its producer
  • suitable for particular allergy
  • not using palm oil
  • not made by a brand or company they dislike
  • made in a particular country (my country in many cases)
  • not containing any meat
  • sexist
  • not bad for biodiversity
  • a local speciality
  • made by hands
  • needs to be baked or reheated
  • requiring a microwave oven
  • recommended to be prepared with a microwave oven
  • doesn't need any machine
  • artisanal
  • needs a fridge
  • etc.

Just scan and get the answer. Sometimes, the mobile app will have to ask you a short question, but the overall goal is to get the answer as fast as possible.

This use case is not only interesting for food products. Open Beauty Facts, Open Products Facts could also play well with this.

Is my product:

  • able to be repaired
  • need electricity

TODO: belongs to fridge or cupboard.

Functional use cases for mobile usages

As a first prototype to explore mobile usages, we are going to launch a very simple app allowing both collecting and providing data. Here are the minimum functional use cases for a first version.

The user scans some products

  • The user asks the system to launch the app.
    • If it's the first time, the app ask the user the profile he wants to select.
    • If it's the first time, the app detect the current language of the phone or browser.
    • If it's the first time, the app ask the user to fill his OFF credentials (see dedicated use case).
  • The system display the barcode scanner and a menu to select the language.
  • Eventually, the user change the current language (see dedicated use case).
  • The user scan a product.
  • The system display its name and its picture
    • or an invitation to enter it via Open Food Facts.
  • The system either ask or answer the specific question it has been made for.
    • [answer] E.g. This product needs to go in your fridge.
    • [question] E.g. Is this product should go in my fridge or in my cupboard.
  • If it's a question, the user can answer:
    • by clicking on the different choices, including "I'm not sure"
    • by entering a value in a field

The app asks the user to fill his of credentials

  • The system shows a form with the username and password, and a submit button.
  • The user fill his credentials and submit them.
  • The system verifies these credentials are ok.
    • If it's ok, the system display a message to confirm it's ok.
    • If it's not, the system display a message to ask the user to retry to enter his credential.

The user changes the current language

  • The user select the menu to change the language.
  • The system shows the languages available.
  • The user select a language.