The Tool of an Alternative Today

When we want to transform an image, we often mean one specific thing. Yet to do that, the large working environment that contains the tool opens with it. Broad production tasks require wide workspaces, detailed toolsets, and powerful systems that can support them. Large programs exist for this reason, and they are necessary for many production processes. For the intermediate operations we repeat continuously, however, a specific tool that works at the right moment is usually enough.

The idea of the project begins here. To turn a photo into a mosaic image, quickly view a 3D object, create a GIF from a video, give volume to text or a vector form, compare the colors in a vector file, or generate a grid, we may not need to enter the entire working environment of a large program every time.

Instead of taking over the whole production process, this structure makes the transitions, intermediate operations, and repeated moves within the process more direct.

Some tools speed up a specific operation, some open up a space for creative experiments, and some produce one result without requiring a large program to be opened. What they share is the ability to complete a specific task without entering the environment of a comprehensive program.

Pixelmaxxxing offers options for transforming photos into mosaic images.

Ngon-Junk quickly displays 3D objects, sets backgrounds, and exports outputs.

GIF tools create GIFs from images or videos.

Hot vs Nice compares colors in a vector file.

2D to 3D converts text or SVG forms into 3D objects.

Rooms quickly constructs a 3D room.

Other tools focus on narrower operations such as making grids, applying photo effects, and transformations.

The project brings these tools together within an interface system that preserves the feeling of the same device, looking at creative software from an alternative present. An output processed inside the device can continue to be edited in other programs. A file can be transferred directly from a phone to the device through a QR code, and the processed image can be downloaded again. The tools are not treated as separate pieces of software, but as processing modules inside the same machine. In this way, the same tools are given a different usage feeling and a different context.

Today’s creative software often developed by expanding. More features, more panels, more control, more possibilities. The value of software was often measured by how many things it could do.

If technology had developed as it has today, but creative production tools had evolved differently, what would they look like?

If making tools were this easy, could every operation have its own workspace?

Did users really want everything to be within reach? Or did designers get caught in a feature race carried out between companies through software?

Does opening a program have to take longer than the thing we want to do inside it?

Can a tool be valuable because it does one thing well, even if it does not contain every feature?

Can a web interface remain simple while still carrying the feeling of a device?

Can a creative tool be visited again and again without keeping the user inside?

Can creative software still feel like a toy?

This project looks at the present from another line of development. In this alternative present, creative software has developed as modules that carry specific operations, rather than turning into massive toolboxes that contain everything. The user does not enter the entire universe of a program, but encounters the operation they want to perform. They bring their file into the device, run the process, produce the output; then they can download it, move it to another tool, or continue working on it in another program.

From this perspective, the tools gain meaning because they are more specific. Each one holds a threshold in the production process: transforming an image, giving volume, producing motion, comparing colors, staging, exporting. For this reason, beyond being a functional toolset, the project is an attempt to imagine a present in which creative software evolved differently.

The growth of creative software changed more than the technical side of production; it also changed how design labor is perceived, measured, and requested. As programs offered more features and broader production possibilities, the design process increasingly began to be read through software mastery. As a result, less visible design decisions such as forming an idea, choosing a medium, planning the process, setting limits, and deciding which possibilities to eliminate were overshadowed by executable skills inside a program.

While a designer would first form an idea, choose the medium and material suited to that idea, plan the process, and then begin working, in many professional environments the issue gradually became compressed into the question: “How well do you know this program?” The job market struggles to measure design thinking. But software skill is easy to measure. Saying “someone who can think visually well” is ambiguous. Saying “someone who knows Photoshop, Illustrator, Figma, and Blender” is clear.

In this way, knowledge of software did not replace design thinking, but in the job market it became a measurable stand-in for design ability in general. Knowing every program does not make someone a designer. But for a long time, program knowledge was used as proof of being able to design. This also affected the way designers think. The act of first imagining, choosing the right material and medium, planning the process, and beginning the work turned, in many places, into a race to be the person who uses the program best.

In a job listing, the person who “knows it well” is sought after. So they can do whatever the director says, apply whatever the client shows, and make the desired image possible. As programs made everything seem possible, decision-makers also began producing demands through the image of software that could do everything, without having to use the program themselves. Because there would always be someone who knew how to use the software very well. This pushed the designer away from being the person who forms the idea, chooses the medium, and directs the process, and closer to being the person who makes whatever is shown to them possible.

The same thing appeared in client relationships. The request “make it like this” is not new. Clients have always shown references, moodboards have been made, and the questions of influence, quotation, and style have always existed in art history. But tutorials, presets, templates, and fast digital production turned this request into something more mechanical, more direct, and cheaper.

Telling someone who works by hand to “make the exact same thing as this” still feels rude. Because in that case, the hand, time, style, and personality are visible. But in graphic work, people can say this more easily. Because to someone looking from the outside, what happens on screen often appears not as a considered design decision, but as an effect that can be repeated if the right steps are followed. How-to videos turned visual language into a recipe. As the labor behind the program became invisible, the request “make it like this” became normalized. The designer faced the risk of being reduced from someone who forms their own visual language into an operator who reproduces the appearance shown by someone else.

Design is as much about eliminating possibilities as it is about producing. A designer chooses form, but also decides which tool will not be used, which effect is excessive, which path will damage the work, and which option will scatter the process. Design is not about trying everything within infinite possibility. It is about recognizing limits such as price, time, purpose, and use, and finding the right move within them.

Abundance does not always increase creativity; at times, scarcity triggers a creative solution more strongly. Because in a limited situation, the solution emerges within the defined frame. In the abundance of today’s creative software, when everything is possible, what should not be done can become more unclear; what the program can do can get ahead of how the designer thinks. For this reason, this work treats limitation not as a lack, but as a design decision. Each tool exists to make an operation more distinct.

The project also searches for a present in which advanced technology could move forward without being compressed into uniform, flat, and neutral interfaces. As screen sizes multiplied, flat and minimal design language became dominant as a practical solution for interfaces to work across different devices, be updated easily, be reproduced, and remain maintainable. In many ways, this language was profitable: it was fast to produce, easy to scale, and adaptable across platforms.

But did interfaces have to become this similar in order to be scalable? While software became simpler, faster, and more usable, could surface, light, depth, device feeling, and character have been preserved through another path? This project searches for a timeline in the present where flat and minimal interface language did not become dominant. If narrower operations had not been buried inside heavy programs, and if interfaces had not moved so closely toward uniform flat templates in order to scale, what would creative software look like with today’s technology?

This project tries to build an answer to that question both visually and functionally. Its mode of use also works with the logic of a device. The user can scan a QR code with their phone, take a photo, or choose an image from the gallery and send it to the device. Each tool’s own import and export logic is preserved. An image, model, or output can come from a phone, directly from a computer, or from another tool inside the device.

In this flow, the device does not take ownership of the entire production. It enters the process more often at points of transition. It is concerned not only with producing the final state of something, but also with producing intermediate outputs that can turn into something else.

The change this project proposes is a shift from program-centered thinking to operation-centered thinking. The user first looks not at what the software can do, but at their own need. Every intermediate operation does not have to carry the weight of a large program.

This project proposes a mode of use that does not reduce design thinking to software mastery. By building a structure where outputs can move between programs, and where tools work as parts of the same device, it looks from a present in which creative software evolved differently.

You can try it here:
https://ycswu.co/tools-device/

Other YCSWU Tools:
https://ycswu.co/tools/

Itch project page:
https://ycswu.itch.io/ycswu-tools-special-edition

YCSWU itch.io:
https://ycswu.itch.io/