Please read the previous post if you have’t already, so you can understand the context.
Once Squishy was up and running on the server, we used Codex to create the WordPress plugin. The idea behind the plugin was no longer to compress images itself, but to connect WordPress with Squishy. The workflow became much clearer:
- the user uploads an image to WordPress,
- the plugin sends it to Squishy,
- Squishy optimises it
- and WordPress receives a lighter version.
This means the site can use AVIF or WebP images without placing too much of a strain on the server where WordPress is installed.
We also improved the workflow within the media library and Elementor, so that users would receive more feedback and wouldn’t be left staring at confusing statuses like ‘queued’ or ‘processing’ without understanding what was happening. We have to go through a series of iterations to refine the product step by step. Detail by detail.
Why This Approach Was Better
Because it separates responsibilities. WordPress handles the site, the content and the media library. Squishy handles the heavy-duty optimisation.
If we had left all the compression within the plugin, each site would depend on the quality of the hosting where it is installed. Some servers might handle it well, others might fail, and others might not support AVIF at all.
By running Squishy on our own server, we have better control over the environment. This allows for more consistent results, less load on WordPress, and a tool that can improve over time without relying so heavily on individual hosting providers.
The Interesting Thing About All This
The interesting thing is that Squishy didn’t start out as a brilliant product idea. It arose from a concern directly related to productivity in my work, namely how to automate a process that is currently done manually. (This is where that UX Law comes in—I can’t quite remember the name…).
And that is, having to deal with images that are far too large.
But in trying to solve that problem properly, the natural progression was to create:
- First, a local tool,
- then a web app,
- then an API
- and finally an integration with WordPress.
In other words, a small need ended up becoming a tool of our own with real potential. I think that as we’re in the midst of a revolution, the full picture isn’t yet clear, but by taking part in the process we’re creating value, albeit organically, based on our own needs.
If You Want to Create Your Own Apps Too
If you’re a designer, a freelancer or someone who builds websites, I think this path can open up a whole host of possibilities. It’s not about suddenly becoming a full-stack developer or knowing everything from the get-go, but you can deliver value by creating your own tools, and that shifts the paradigm of what designers have traditionally been.
It’s about identifying repetitive processes, time-consuming tasks or problems that your clients might also face. From there, you can start small: a simple app, an automation, an integration or an internal tool.
The important thing is to change the way you look at your work. Don’t just ask yourself “how do I design this?”, but also “what tool could I create to solve this better and thus deliver value to my clients?”
The New Era of the Designer-Toolmaker
For me, Squishy embodies an idea I want to continue exploring: designers no longer need to limit themselves to designing interfaces, brands or websites. They can also create their own tools.
Tools that arise from real-world experience, from specific problems and from a sensitive understanding of how people work. That blend of design, judgement, technology and craftsmanship is what I’d like to call The New Era of the Designer-Toolmaker.
Como creé un plugin para WordPress
Por favor, lee la entrada anterior si aún no lo has hecho, para que puedas entender el contexto.
Después de tener Squishy funcionando en el servidor, creamos con Codex el plugin para WordPress. La idea del plugin ya no era comprimir imágenes por sí mismo, sino conectar WordPress con Squishy. El flujo quedó mucho más claro:
- el usuario sube una imagen a WordPress,
- el plugin la envía a Squishy,
- Squishy la optimiza
- y WordPress recibe una versión más liviana.
Así el sitio puede usar una imagen AVIF o WebP sin exigirle demasiado al servidor donde está instalado WordPress.
También fuimos mejorando el flujo dentro de la biblioteca de medios y Elementor, para que el usuario tuviera más feedback y no se quedara mirando procesos confusos como “queued” o “processing” sin entender qué estaba pasando. Hay que ir pasando por una serie de iteraciones para ir perfeccionando el producto paso a paso. Detalle por detalle.
Por Qué Este Enfoque Fue Mejor
Porque separa responsabilidades. WordPress se encarga del sitio, del contenido y de la biblioteca de medios. Squishy se encarga de la optimización pesada.
Si hubiéramos dejado toda la compresión dentro del plugin, cada sitio dependería de la calidad del hosting donde está instalado. Algunos servidores podrían hacerlo bien, otros podrían fallar, y otros directamente no tendrían soporte para AVIF.
Al tener Squishy en un servidor propio, controlamos mejor el entorno. Eso permite resultados más consistentes, menos carga para WordPress y una herramienta que puede mejorar con el tiempo sin depender tanto de cada hosting individual.
Lo Interesante De Todo Esto
Lo interesante es que Squishy no nació como una gran idea de producto. Nació de una inquietud relacionada directamente con la productividad en mi trabajo, y es cómo automatizar un proceso que hoy en día se hace de forma manual. ( Aquí hablar de esa UX Law que no recuerdo el nombre…).
Y esto es, tener que lidiar con imágenes demasiado pesadas.
Pero al intentar resolver bien ese problema, lo natura fue hacer:
- Primero fue una herramienta local,
- después una web app,
- luego una API
- y finalmente una integración con WordPress.
Es decir, una pequeña necesidad terminó convirtiéndose en una herramienta propia con potencial real. Creo que como estamos al medio de una revolución aún no tenemos completa la película, pero tomando parte del proceso vamos creando valor, pero de forma orgánica, basándonoslos en nuestras necesidades.
Si Tú También Quieres Crear Tus Propias Apps
Si eres diseñador, freelancer o trabajas creando sitios web, creo que este tipo de camino puede abrir muchas posibilidades. No se trata de convertirse de golpe en desarrollador full stack ni de saberlo todo desde el inicio, pero si puedes entregar valor creando tus propias herramientas y eso cambia el paradigma de lo que los diseñadores habían sido hasta ahora.
Se trata de detectar procesos que se repiten, tareas que consumen tiempo o problemas que tus clientes también podrían tener. Desde ahí puedes empezar pequeño: una app simple, una automatización, una integración o una herramienta interna.
Lo importante es cambiar la forma de mirar el trabajo. No solo preguntarse “¿cómo diseño esto?”, sino también “¿qué herramienta podría crear para resolverlo mejor y así entregar valor a mis clientes?”
La Nueva Era Del Diseñador-Herramentista
Para mí, Squishy representa una idea que quiero seguir explorando: el diseñador ya no tiene por qué limitarse solo a diseñar interfaces, marcas o sitios web. También puede crear herramientas propias.
Herramientas que nacen desde la experiencia real, desde problemas concretos y desde una mirada sensible sobre cómo trabajan las personas. Esa mezcla entre diseño, criterio, tecnología y oficio es lo que me interesa llamar La Nueva Era del Diseñador-Herramentista.