Hey! I’m a UX designer currently reevaluating my toolset. I like to prototype my designs and mostly use Axure as I can go a lot further with complex interactions than I can with Sketch or Figma.
But even with Axure, I come up against limitations, and it’s not very open to adding in custom code.
So I’m thinking Blocs might help. My projects tend to be more “web apps” rather than simple blog/magazine type layouts. So I need to be able to create fixed panels, tabs, scroll areas, modals, accordions, repeating grid elements, etc. It’s also useful to be able to save variables from one page to use on another page (think adding items to a shopping cart and being able to view those same items on a checkout page).
The output doesn’t have to be production code - it’s just prototyping. I’m reasonably familiar with html/css/bootstrap/js but creating a layout from scratch or making sweeping changes to a design takes me too long in a code editor.
Back in the day, Flash hit the sweet spot for being able to draw out a user interface and with a bit of coding there was no limit to the interactions I could mock-up. Could Blocs be that missing tool in my prototyping workflow?
Hi @PatTheDog,
Welcome to the Blocs forum, I’m also a UX/UI designer searching for the same miracle tool. I’m also an Axure user (but looking for a replacement for similar reasons). Though my search isn’t quite over (based on the tools I’m aware of), I came across Blocs, not for this reason. I was actually looking for a web site design tool, but I was also hoping I could use it in this capacity.
I found that the potential does exist but because it was designed primarily for web site design, a designer would need to be well versed in Bootstrap/HTML/CSS/ and JS to stand a chance of using it for this purpose. It’s designed primarily with a developer in mind, though not necessarily an expert. A novice can learn to use it fairly quickly, but again - it follows development conventions more than it does, lets say a visual design tool.
And even with that, you would need to develop your own system of creating components that are not already available in BS (since Blocs is based on that framework), and that might be too much work to be practical - but it’s not impossible.
The only other product that I feel that came extremely close to this need was Macaw which never got past v1. It was purchased by InVision and unfortunately they bought it to kill it. They instead released Studio, which is a direct competitor to XD.
If Macaw were to mature, it would’ve been, IMHO, the holy grail of tools for prototyping. So for me the search continues. As far as I’m concerned, Blocs is excellent for web site design (which is what it’s intended for), but not for app design (not without a bit of manual work, which is more than I thinks it’s worth).
Thanks @MiguelR, this is super helpful. It sounds like the lack of reusable UI components will be a dealbreaker, at least for now.
Macaw looked very promising indeed. I was a Kickstarter backer and beta tester, but was ultimately disappointed that it never lived up to the hype.
I’m curious if you have tried Framer? It appears to offer that combination of visual layout with a build-anything-you-can-code promise. But I haven’t seen any Framer examples beyond slick micro-interactions, while I need to be able to (fairly quickly) build out full flows that can be user-tested and evaluated by a development team.
Yeah, I’ve seen it and I like it, but I quickly turned away when I realized it’s a subscription. Which is one of the reasons I want to get off Axure. They no longer offer perpetual licenses. That is also one of the main reasons I purchased Blocs. While I had other criteria when evaluating Blocs, the perpetual license was the clincher.
What specific areas or aspects can you outline and share that Blocs could improve upon or that it would need to implement for better serving the type of UI workflow you desire? Please be specific in an outline fashion.
The reason I inquired above is because your below statement makes it sound like Blocs could be promising. If * you first took the required upfront time to build things out and get your workflow setup for reuse, modification and production.
These feature might be useful in building out required things
Likewise the following excerpt actually sounds contrary to Blocs general intention.
As it’s made primarily for designers but with far reaching opportunities for developers also. Of course its workflow offers designers entry into various things. Like the box model, custom classes, etc., but in an easy to understand and use methodology that designers can comprehend and utilize.
Lastly the Macaw reference threw me for a loop because in my opinion Blocs is leaps and bounds beyond its abilities and workflow. Blocs is more of the ideal of Macaw’s mythic Scarlet and vastly beyond that even.
I was just trying to understand deficiencies to comprehend in what areas Blocs might improve towards meeting these ends. Blocs has an API that can provide extension to the toolset so perhaps something could likewise be developed to assist the process.
But I truly feel even in its current state that if someone took the time to prep, build and setup required components and interface templates upfront. Then the ability to reuse, modify and produce could likely be accomplished. But yes its not Blocs intention out of the box but with effort the workflow could perhaps be satisfied by users.
One idea I’ve had for a while is to make Blocs more “framework flexible”. Having the ability to create your own framework or use others and then build Brics, Blocs and Page Templates based on that framework would be a powerful thing, but I’m not sure how popular it would be
I definitely see a time in the future when Blocs may offer this as an option just from natural evolution as features expand and evolve.
I’m not sure where in my response do I say anything that contradicts what Blocs is, or does. While Blocs certainly does have tools that look and feel like those found in design apps, having these tools or functionalities, even if they behave the same, does not necessarily mean it’s target user is a designer.
IMO what it does more is introduce a designer methodology into a developer centered work environment. Some can argue that Blocs is primarily for designers, because of the obvious tools it uses, but I find that that is not entirely correct. Instead I find that, while the aforementioned is true to some degree (using ready-made Blocks, Brics, and templates, makes it more attractive to non-coders), but it tends to cater more to developers who want to work more efficiently using visual aids. Which does help lower the learning curve for both - wannabe coders as well as designers that want to also learn more about coding.
But that is besides the point of the original discussion. From the perspective of a person who’s primary task is to make apps easier to use for a living, as well as make it look good (though this is not the main focus when designing ease of use), I find that for what Blocs does, it doesn’t cater to the needs of this demographic, at least not so easily.
As part of what I do, I need to create prototypes quickly for applications (not web sites) that can be fairly deep, with a tool that has specific functionalities that anticipates how people in my field think and work (which is what Blocs does for developers). I could get deeper into this topic, but this is already getting long enough.
Otherwise, using tools not intended for this specific use case can create a learning curve too steep and take way too much time managing assets and design processes associated with it, not to mention it might not be scalable or future proof, since we don’t know the direction Norm intends to take Blocs in the future. Such is the case here regarding Blocs as a prototyping tool for apps. I also made this quite clear that it’s not impossible use Blocs for this use case, but due to how UX designers typically work the amount of work involved may introduce more frustration than it’s worth.
I’ve also said, Blocs does have the potential to be used in this capacity, but it is not designed for it, therefore, until then (again, this depends on what Norm has on the roadmap for Blocs), Blocs is not practical for this use case.
So my comment was not meant to bash Blocs, or sway anyone away from Blocs, or suggest it is not suitable for designers. It was meant to inform someone in the same field I’m in as to the potential of Blocs to serve as a practical tool for a specific use case in this field. Hope this clears up any misinterpretations.
I’m currently part of many offerings which are still in various stages of private / alpha / beta all of which fit the workflow of UI/UX rapid prototyping for apps and beyond. Honestly all of them are more aligned to various aspects of Blocs than that of the common current breed of UI design and prototyping tools.
The industry is in a bit of confusion currently and many of the current UI tools are somewhat stuck without major retooling. So the following could be said for many tools :—).
It’s an interesting time with many exciting things being developed and coming.
Also… my referencing of Macaw was in the context of a tool that had this use case in mind. Meaning designers (non-coders) as well as coders (non-designers) would have one tool that behaves in a way that allowed both groups to truly meet in the middle.
For example, Macaw was not based on any existing framework, it also allowed designers to draw shapes like in PS or Sketch of any size and anywhere on the screen without referring to web conventions. You were also able to create components and save to a library for future use, and output your creations to HTML, just as you designed it.
Of course Blocs is beyond this. It isn’t a fair comparison. Macaw never got past v1.51. The last version, which I still have installed but don’t use, has only rudimentary design functionality, which is unsuitable for design work today, but when it debuted it was way ahead. I successfully used it in multiple projects and was anxiously anticipating new updates, but was disappointed when InVision bought them out.
Some folks were critical of Macaw and criticized it for not generating clean code. But for designers, this didn’t matter. Designers (including me) just wanted an easy to use tool that was familiar, in terms of function and behavior, to produce prototypes quickly with the ability to present them live.
This could then be handed-off to developers to do their magic. This was a particularly suitable workflow for designers working on thin-client, and SaaS, applications.
Unfortunately it didn’t go far enough to fulfill its full potential. I was an early Kick Starter backer (paid around $75 for it) because I saw the potential.
As someone also used to more free-form design I think I would agree with you.
I am used to free - form UI design and then creating links mostly to other pages or modes for prototype demonstration, so that doesn’t fit well with a tool that is built around bootstrap layouts.
There are other tools that support that form of design more easily than blocsapp.
For web page design then I think blocsapp can work very well for a specific kind of design that is compatible with bootstrap layout. So for that sub-genre of design a big thumbs-up for blocsapp as a design tool (and yes I do design web pages directly in blocsapp), for any other free-form application it’s not so ideal.
I can’t imagine using blocsapp as my sole design tool simply because it’s essentially a layout program using customisable bootstrap templates and not capable of general graphical work.
I never used either myself for anything. Aside from part of assessing various apps regarding workflow, UI / UX, output etc., for that sole reason alone.
So I just opened Macaw and drew an element the first thing I see in the sidebar is div.element followed by entry for an #ID for said element. Including a warning for generic semantics asking for a .class name, etc. In addition to :hover, :active, :focus. Sidebar advanced includes overflow:, etc.
The illusion of freeform is not all its made out to be, don’t get tripped up or stuck on that. With interface/app/ui components it becomes nonessential anyway. I feel many core aspects of Blocs were inspired by Macaw. Though Blocs took the torch further up the road and is continuing to accelerate.
So yes even though you can freely draw and place things on the canvas it does not abstract / hide those web centric aspects from instant / clear view. The output was surprisingly actually cleaner than most current visual tools, aside from using floats. Sparkle is one such example of drawing on the screen for creation, but that generally comes with many drawbacks and shortcomings.
This however is the conundrum between disciplines that is currently being solved by a new bread of tools. Instead of a fragmented development cycle we are heading towards actual handoffs from designers for further development. Appeasing both sides of the development cycle. AI and machine learning are coming as well and will alter both sides of the spectrum. This too is why I commented above that the current breed tools will need retooling to compete, some may already be doing so.
I understand the desire and mindset of a designer or someone who comes from a visual design background.
I get it, you want freedom. But it’s a challenge when the end goal is production quality code.
The compromise in Blocs is freehand, small handles to push and pull the design within the responsive constraints. It’s not total freedom, but it’s a step towards. Over time I hope to expand and improve in this area.
Oddly visual design tools like Figma and Sketch are introducing constraints as a feature in order to replicate the natural properties of html and css.
I watched a video the other day of someone creating a text field input simulation in Figma and it just looked nuts and reminded me of the time designers were complaining about using Photoshop for UI design (The wrong tool for the job).
I also remember Macaw, and was very excited to try it. Tom (the creator of Macaw) and I had actually planned to release a book together about UI design, it never made it past a few chats on email as we both went our separate ways to create what would become Macaw and Blocs.
Macaw really captured people’s imagination, it was very ambitious, when Blocs V1 came out, it was almost toy like in comparison.
But over time Blocs has naturally grown as it’s had more time. But to me, it still feels odd to compare it to Macaw and Blocs be in front.
Ultimately it’s browsers that will give us the tool of our dreams, once the code required to make responsive websites and web apps is simplified by the render engines in browsers everything will be possible.
The code underneath is always getting cleaner and requiring less hacks, year on year. But ultimately the ones holding the reins are Chrome, Firefox, Safari etc.
I would love to see this happen. I am very taken with tailwind css! I marvel at your capacity for coding and you are such a nice chap who goes out of their way to help his customers. Thank you Norm. By the way, I know this will be in the future.
Which is one of the reasons I want to get off Axure. They no longer offer perpetual licenses. That is also one of the main reasons I purchased Blocs. While I had other criteria when evaluating Blocs, the perpetual license was the clincher.
I never got a chance to try that one!