Búsqueda de geolocalización
El usuario desea información que sea geográficamente relevante. Por lo general, no les importa lo que sucede en 3 estados, pero la mayoría de los sitios web se crean de esta manera. Las API móviles y HTML5 nos permiten obtener fácilmente las ubicaciones de los usuarios, pero pocos sitios web lo aprovechan. En el lado de la base de datos, solo Oracle y Postgres tienen soporte de geolocalización maduro. MySQL, MongoDB y algunos otros han estado agregando soporte, pero no es tan robusto.
Búsqueda compleja
- ¿Qué lenguaje (s) de desarrollo debo aprender?
- ¿Cuál es el mejor programa editor de texto para fines de desarrollo web?
- ¿Qué lenguaje de programación es mejor para desarrollar aplicaciones web y móviles?
- ¿Qué es lo más complicado que has hecho con Zapier?
- ¿Por qué alguien elegiría Python sobre Ruby, y viceversa?
El usuario quiere encontrar cosas, a menudo de manera compleja. Mire la Búsqueda de gráficos de Facebook para ver un ejemplo bien hecho. En el extremo simple, tenemos búsquedas de palabras comodín que obtienen muchos falsos positivos. Agregar más complejidad implica múltiples menús desplegables para agregar más contexto. En el extremo tenemos constructores de consultas SQL. Lo que Facebook hizo fue agregar Procesamiento de lenguaje natural para permitir consultas complejas escritas en “lenguaje humano” que se asignan automáticamente a consultas complejas, en la parte superior de su base de datos de red de gráficos. Un sistema como ese permite a los usuarios, pero más aún a los desarrolladores de negocios, realizar búsquedas complejas sin necesidad de conocer los esquemas de la base de datos.
Soporte multiplataforma
Muchos usuarios, en todas las industrias, usarán su teléfono para leer correos electrónicos y buscar información. Luego use sus tabletas para hacer búsquedas complejas y navegar. Finalmente, usarán su escritorio para realizar complejas manipulaciones de datos. La táctica comercial común es crear un sitio web centrado en el escritorio, una aplicación de tableta dedicada de un solo sistema operativo y una aplicación de teléfono dedicada de un solo sistema operativo. El mayor problema es la falta de paridad de características en todas las aplicaciones , pero también la falta de un diseño consistente. El diseño afortunadamente receptivo ha proporcionado una solución conceptual, y los marcos MVVC JS como AngularJS, Ember y Backbone lo están permitiendo. Puede consultar uno de mis sitios para ver un ejemplo:
Botellas – Vino Discover
API RESTful verdadera
Lo bueno de ir a REST completo es que una sola API web puede ser utilizada por dispositivos móviles, websties y sistemas de terceros. En realidad, lea la tesis de Roy Fielding, y se dará cuenta de que el 99% de las API web no son completamente RESTful. Son “tipo RESTO”. Parte del problema es que los detalles de la implementación no están definidos, como por ejemplo: ¿deberíamos usar JSON o XML para HAL (Lenguaje de aplicación de hipertexto)? ¿Deberíamos usar RQL (Resource Query Language) para las búsquedas?
