Roadmap sprint para la version 0.1 (primer release) - mgaitan/preciosa GitHub Wiki

Este es un articulo que intenta unificar la info sobre

  • dónde estamos
  • dónde vamos y
  • qué tareas hay que realizar para llegar allí.

En particular, acotaremos a los dos componentes más importantes: API y aplicación mobile básica

Flow de la app mobile

A pedido de un diseñador que ofreció realizar algo de la maquetación web necesaria, acá describí un caso de uso típico de la aplicación movil, y las pantallas/funciones necesarias.

Hay una prueba de concepto y algunos diseños estéticos de la app (1) y (2) . Sin embargo, a priori, no es objetivo que la primera versión se vea "bonita".

1) Pantalla principal: búsqueda de productos

La pantalla mas importante es la que le permite al usuario buscar productos de distintas maneras:

  • a. Escaneando un código de barra
  • b. Ingresando a mano un código de barra
  • c. Buscando por descripción del producto
  • d. Navegando un menú de categorias de 3 niveles

Esto es basicamente análogo a la columna izquierda del sitio http://www.preciosdeargentina.com.ar

La acciones a y b deberían funcionar igual que el buscador de la web, o sea: va dando resultados parciales con autocompletado.

Al navegar por categorias va "entrando" en el arbol hasta que muestra una lista de productos. Ejemplo "Lácteos -> Leche -> Entera". y alli lo que se ve es una lista de productos similar a http://preciosdeargentina.com.ar/507-entera/

2) pantalla detalle

Una vez que el usuario encuentra el producto que quiere pasa a la página detalle, donde se muestra la info basica del producto en cuestion y los precios encontrados. estos detalles se describieron originalmente acá y depende (pero no se completa con) los tickets #107, #108 y #109. Es decir:

  • los últimos precios distintos registrados para la sucursal ordenados de más nuevo a más viejo. En la interfaz el precio más reciente aparecerá más detacado.

  • Si no hay precios para la sucursal, precio más probable para esa sucursal (puede calcularse en función de precios de la misma cadena). Será utilizado de la misma manera que el anterior.

  • Mejores X precios para un radio predefinido. Por defecto, la ciudad en la que se encuentre el usuario. (¿como se configuraría este radio?).

  • Si no hay datos para el radio/ciudad, enviar precio online de la misma cadena

En esta pantalla hay dos botones que sirven para confirmar o corregir el precio de un producto. Si el usuario confirma, no tiene que hacer nada más (en background se envia el mismo precio a la API). Si decide corregir, se le solicita que ingrese el nuevo importe. Una maqueta de esto se puede ver acá

3) Localizacion del usuario

Ahora bien, hay un paso 0 para poder "enviar" esa confirmación o corrección: confirmar el supermercado donde te encontras. La idea es que la app detecte el super más probable (por cercania) al que se supone que está, pero igual hay que pedirle al usuario que confirme. Vista de la API para esto está bastante hecha por Nacho (ver #2)

Entonces esta pantalla de "configuracion" debe mostrar la lista de supermercados más proximos que se encontraron, con un "radio button", seleccionado el primero por default y un botón "confirmar" . Seria piola tambien que se pueda "filtrar" la lista por un listbox con las cadenas de super.

A esta pantalla se deberia acceder desde un botón de configuracion, en el inicio de la app, o bien que se "redirija" si no se configuró, la primera vez que el usuario intenta confirmar o corregir un precio.

Otras pantallas

otras pantallas son forms que le permiten al usuario cargar datos nuevos al sistema. Ejemplo: si escanea un código de barra que no tenemos, la "pagina detalle" dirá "No conocemos ese producto", desea agregarlo?" y entonces redirige a una pantalla donde tiene que poner una breve descripcion y elegir una categoria para el producto.

Otro form de alta es el de sucursal, que deberia accederse desde la configuracion de sucursal con un botón de "agregar nueva" y deje elegir: Cadena (desde un listbox), una dirección y un checkbox que diga "estoy aquí".

Login/registracion (opcional)

A priori se acordó que un usuario no necesita autenticarse y trabajará anónimo. Pero sería deseable tener la arquitectura y una prueba de concept de registracion/autenticación desde al app mobil a traves de la API, idealmente con soporte para autenticación social (ver #73 )

API

La API debe proveer todos los recursos (de escritura y lectura (listados y detalles)) para la APP mobile. Adicionalmente permitirá POST (escritura) sobre otros recursos, por ejemplo, para importar listados de productos o marcas programáticamente.

El listado de recursos/vistas básicas provistas por la API está descripto en #2.

  • Sucursales de super. List + Create. /sucursales/ Filtro por ciudad o posición + radio

  • Categorias. ListAPIView /categorias/ devuelve roots, categorias/<pk> devuelve hijas de categoria <pk>

  • Productos de categorias. ListAPIView /categorias/XX/productos devuelve un LIST de productos para esa categoria

  • Productos. ListView + Create. /productos/[<UPC>] . Debe permitir filtrar por los numeros UPC (istartswith) y palabras, similar al buscador que tenemos. El post (crear instancia) requiere UPC y categoria de nivel 3 como obligatorio.

  • Precios para sucursal + producto. List + Create /sucursales/<pk>/productos/[<UPC>] . Si no se especififica el UPC devuelve la lista de productos mas frecuentes (con más instancias de precios relacionadas). Para POST requiere el UPC y el dato obligatorio es el importe

  • Cadena. List + create

  • Ciudades . List (sólo lectura)

Si se desea, podemos desglosar esta lista como tareas independientes con el tag API

⚠️ **GitHub.com Fallback** ⚠️