The idea behind Easyblocks is quite simple. Today if you want to create a custom text editor for your product you have a lot of options with different abstraction levels: Slate, Lexical, CKEditor, TineMCE etc. But if you want to create a custom PAGE BUILDER there's not much to pick from. There are GrapeJS or WebStudio, but they're based on HTML/CSS (there's a HTML nodes panel on the left and CSS properties panel on the right), which is too hard for most people. There's no abstraction over the HTML/CSS that would make the experience simple and foolproof.
Easyblocks architecture is based on a novel concept called No-Code Components. I personally find it fascinating. No-Code Components are defined with code but are also visually editable. Each No-Code Component can have CUSTOM styling properties which makes it both visually flexible and not overwhelming for end-users (no CSS overhead). It's as if you could build your own visual blocks with Squarespace-level simplicity. You can build the most custom logic out there and yet leave the user with something super simple to use and customised.
Btw, it all started with Shopstory - a visual page builder for headless CMSes (https://www.shopstory.app/). We had a moderate success with it but during the journey we got asked by multiple software vendors if they could use Shopstory INSIDE of their products. Since we had quite an advanced editor and architecture behind Shopstory we thought that we should make it public for everyone.
In e-commerce space you might take a look at: https://theheadlessclub.com/. It's exactly what you're looking for. Quote from about page:
"Most directories tend to put emphasis on shiny and showy hyper-animated web experiments. Unfortunately, many of these projects fail when criteria like performance, mobile, usability, and accessibility are considered. It’s hard to find one single resource on the internet that would combine both the technological excellence and highly polished design in ecommerce space. The Headless Club started as an internal agency tool to foster ecommerce best-practices across our development team. Now we’re sharing our findings with you."
Disclaimer: I'm the co-author (with folks from commerce-ui.com agency). We'll soon make it not specific to headless but to all e-commerce stores.
Headless means that you're using e-commerce platform only via API and build your front-end in whatever tech you want (next, nuxt, Remix, etc). It's different from a traditional approach when e-commerce platform handles front-end (HTML templates rendering). In Shopify can do both.
Funny that headless is now considered "traditional," when that was considered standard for a decade and a half. Relying on the platform was considered amateur.
"Traditional" is just another way to say "what was once the norm", so your comment is a bit pleonastic.
Is relying on the platform no longer considered amateur? If yes, call me old fashioned, because I've never liked those platforms...
Hello, founder and CTO of www.shopstory.app here. None if these arguments apply if you build page builder right. I believe we're on the right path.
First, it works inside of headless CMSes. It means that you get all advantages of structured content and yet add sprinkles of unstructured content when you need on top of that. You can always connect structured data into visual blocks built with Shopstory.
As for design consistency we build everything around design tokens. Not only fonts and colors but also page margins, grid gaps etc. Also, you will soon have permission system where designers can build templates but editors can't modify visual properties.
The bottom line is that I believe in the future we won't need to make a tradeoff between visual vs structured. You can have both at the same time and just fine tune the system to whatever direction suits you better.
> Most web sites are a logical continuation of books, magazines, newspapers, etc. No wonder they actively adopt the time-proven, well-working concepts from the print media.
True, but print media formats got even more simplified in web. The reason? Responsiveness constraints.
Many times I've seen great advanced "article-like" designs for desktop from ambitious designers. It turned out that making them easy to manage in CMS, stable in all possible combinations (or implementing good validators) and at the same time logical and good looking on mobile was extremely hard and not worth it.
This led to further simplifications...
... and then Medium looks like Medium.
There's not much place for creativity on mobile. And this is where most of the "fast content" is read.
If designer is more interested in fulfilling his artistic/creative ambitions than business value for client (making things great looking, stable and reasonably easy to implement -> in budget), he shouldn't even touch digital today. It's too complex and filled with too many constraints.
But if same designer wants to make decent money, well...
Menu on the bottom is obviously pointless, but sticky menu on the bottom would be so cool, most of the mobile apps moved to tabbar.
Why it's not used extensively in web? (it would make it at least a tiny bit less boring).
On iPhone when you scroll down the page, bottom Safari bar collapses and your sticky menu would be still sticky at the bottom. But clicking any button on the sticky bottom menu wouldn't invoke click on the menu. It would make iPhone Safari menu uncollapse -> huge confusion -> potentially less engagement -> retention.
Web today is full of similar constraints. That's why there are usually one or two options that make sense and everything looks the same.
Because on mobile the primary interaction point is your right (or left if you're a leftie) thumb, which naturally falls over a tab bar at the bottom of a screen. Whereas on the Web the primary click zone where your cursor focus is, is at the top of the browser window where the navigation elements are.
There's also the obvious stuff about top-to-bottom reading order making such a layout making the navigation much more obvious when you first look at a site (which is probably want you want for most things, although not all, which is reflected in things like blogs often putting ancillary navigation elements in the page footer).
I don't think this is a broken thing that needs fixing.
I'll also note that it has taken mobile UX designers YEARS to start moving navigation elements to the bottom of their apps, driven by larger and larger screens making elements at the top of the screen quite uncomfortable for one handed use. It's required that to become sufficiently cumbersome that the trade-off in immediate discoverability becomes worth it. And you'll note that the most popular mobile apps such as WhatsApp still have all their navigation elements at the top, regardless.
