
Show HN: Moebius – HTML5 Canvas Drag and Drop Website Builder (macOS Alpha) - jamarante
http://moebius.io/
======
joshribakoff
I built an editor based on canvas and DOM, eventually you run into problems
with canvas that the dom already solves. At that point your options are
reinvent the wheel (for example write logic to draw tables with lines and the
drawing API), or float DOM elements over the canvas. The latter gets hairy
with z index as canvases block mouse and touch events from "passing through"
to elements behind them. There are of course hacks like invisible dom elements
that toggle pointer-events on the canvas, but you have to ask yourself if the
problem you're trying to solve is really worth these hacks/reinventing the
wheel. If you're not letting users draw with a paintbrush, you probably don't
need canvas but that's just my opinion. Canvas is also a bit of a leaky
abstraction in some cases. For example it essentially uses the same text
layout algorithms as HTML, deciding on its own where to line wrap. Line wraps
can jump around when resizing the browser. It is not vectorized text so it
doesn't work for all types of designs

~~~
jamarante
"but that's just my opinion", Good opinion regardless.

To keep the line wrapping consistent with how the designer sees it in the
application, wrapping is handled by the app itself, it doesn't rely on the
text layout algorithm HTML uses. Consistency is the priority.

~~~
mwcampbell
> To keep the line wrapping consistent with how the designer sees it in the
> application

From my perspective as a low-vision person who often uses magnification, this
is an unwelcome invasion of the one-size-fits-all mindset from print design.
Let my device reflow the text. Designers just have to embrace this newer, more
dynamic medium.

Edit: Besides accessibility, what about the variety of screen sizes we have
these days? This isn't the 90s.

Edit 2: To jamarante and others that think a canvas-based tool like this is a
good idea, I recommend this article for a different approach to web design:
[https://www.chenhuijing.com/blog/a-better-web-design-
process...](https://www.chenhuijing.com/blog/a-better-web-design-process/)

I don't like being negative, but, having given it a day's thought and read
more of the comments, I firmly believe that what you're doing is a step
backward for the Web. That doesn't mean that I think Web designers should
write HTML and CSS by hand. Do give them better tools, but don't try to turn
the Web into a new PDF.

~~~
jamarante
"I don't like being negative" That's fine that article was a good read. If you
pay attention to how the breakpoint system works it allows your designs to be
fluid. What I meant when I mentioned that text wrapping is consistent is that
it will be consistent at the breakpoints (I like to think of them more like
snapshots of the current layout that is being constrained at a specific
width), outside of the breakpoints the text and other elements in the page
will adapt accordingly to containers. In that case it will not be perfect
outside of the breakpoint lines. Hope that answers your question.

~~~
mwcampbell
Thanks, I didn't know about the breakpoint system. I'm glad that "consistent"
in this case doesn't mean fixed width, like PDF or bad 90s websites. I'm sorry
I over-reacted.

~~~
joshribakoff
Right, its not the 90s but lots of people still print & still will for a long
time. Plus consistent designs doesn't have to imply print, maybe you're
targeting another fixed height medium like a giant electronic billboard.

------
jbob2000
This is a tool for prototyping, at least, I hope that's all it will be used
for. Otherwise, this is a step backwards. No large company will use this in
production because it completely kills accessibility. You have no idea the
lengths I go to for accessibility, at least 50% of my development hours is
programming for accessible users.

Also, canvas will kill mobile batteries because canvas rendering taps the
hardware more than normal DOM rendering.

Kill this now, it's flash all over again!

~~~
mwcampbell
Thank you. Of course, small companies and startups should care about
accessibility too.

~~~
jamarante
I agree.

------
two2two
This looks promising.

I'm surprised there has been no mention of Adobe Muse in the comments thus
far. Adobe Muse is a similar WYSIWYG website design tool. One which I've used
extensively; both pre-responsive and post-responsive versions.

Adobe's Muse has been a blessing and a disaster for me as a designer. I've had
to, on two separate occasions, refund deposits for projects I couldn't
complete because I reached bugs in the software that would prevent my designs
from working properly. Once an "update" is released, sometimes fixing these
bugs, new bugs are introduced. I have walked away from the software altogether
because it literally reduced my net pay due to unforeseen hours spent chasing
issues outside of my control. Not a great feeling when you're stuck in
subscription model.

With that said, I welcome and support software competing with Adobe's design
tools.

~~~
jamarante
Ouch! That hurts. I have been there too I know how it feels. Thanks for your
feedback and support. Means a lot.

------
baus
> Moebius is built with Javascript. All rendering is done through the canvas
> element.

Does this mean the entire UI is drawn using the canvas element, which then
outputs a standard HTML/CSS webpage?

~~~
jamarante
As of right now the GUI you are looking at is built with HTML and CSS (later
on this will change). But what renders the page in the application's canvas
and the published webpages is all within the canvas element.

~~~
afandian
You mean the _text_ renders on a canvas in the final page? How do you deal
with, for example:

\- partially sighted users with screen-readers

\- resizing text and/or zooming in?

\- keyboard controls. E.g. can I find / highlight / copy text? can I tab
between links and elements?

\- scrolling, especially on resource constrained browsers. Do you have a
massive framebuffer? what about long pages? animation and region invalidation?

\- script blockers

~~~
jamarante
Wow, these are some good questions.

\- "partially sighted users with screen-readers": For example, the final
interface will expose a set of controls to set attributes that help screen
readers do their jobs. The HTML structure is pretty much determined by the
order of elements inside the content panel.

\- "keyboard controls. E.g. can I find / highlight / copy text?": The canvas
piggybacks from the generated HTML. So for example if the user presses the tab
key to alter the input focus in the page, with a listener the changes can be
reflected on the canvas depending on which element is focused. DOM elements
are linked to the entities being rendered in the canvas. Text picking with the
mouse would be handled by queying the scene graph and mirroring how text gets
highlighted in the browser. Copy and pasting would be handled by the Clipboard
API.

\- "scrolling, especially on resource constrained browsers. Do you have a
massive framebuffer? what about long pages? animation and region
invalidation?": While the amount of elements in the page will correlate
directly with the amount of memory that page is consuming. We have to keep in
mind that most (if not all) of the things that are rendered are being treated
as quads. This isnt a 3D mesh. Infinite scrolling is a feature I do have in
mind implementing, but I don't have an specific answer for that yet
unfortunately. Region invalidation (I'll assume you mean with space
partioning) would be handle with the scene graph. Could you tell me more
specifically what you want to know about animation?

\- "script blockers": If the user is blocking scripts in the browser then all
he will get to see is plain HTML unfortunately. AFAIK this is something that
cannnot be stopped.

Thanks for the feedback! If you have more questions keep asking them.

~~~
afandian
Thanks for the answers. This raises even more questions!

It sounds like you're allowing a hidden DOM to be rendered by the browser and
then you're going to render it again in a canvas element? Is the DOM "live" in
the browser, so to speak? I am very interested in seeing more details!

The reason I was asking about scrolling / invalidation was just to try and
guess how you're doing it. Like, if you are rendering all the text in a canvas
and you have a hover or click state that requires a change to what's on
screen, are you re-rendering the whole canvas or working out the minimum
clipping rectangle or what.

Broadly, my concern is this: When people re-implement stuff that already
exists in the browser or operating system, they miss things. Or they make it
work the same in every browser, when browsers and operating systems are
different, and people choose them for a reason. Off the top of my head:

\- If you render text yourself then you don't get the subpixel / hinting
behaviour or kerning that's distinctive to the OS (or browser engine). This
looks out of place, and you discard a lot of hard work and performance tuning
that has gone into making the text look good.

\- For example, maybe you hijack the command for "find". Do you hijack ctrl-F
and F3 on Windows? cmd-F on Mac? What about Linux? What about "find in page"
menu item on my Android phone? On a Mac, cmd-G is "find again". That may be
different on Windows.

\- I use shift-space to scroll up. Cmd-up to scroll to the top of the page. On
Windows that's the 'home' key. Did you think of that?

\- If I double-click I can use shift-left and right to select characters.
Shift-alt-right to select words. Shift-page-up to select to the top of the
page. Triple click to select a paragraph. Right-click to read a paragraph out-
loud with speech synthesizer. Command-click to bring up a context menu.
Double-click and drag to select multiple paragraphs.

These are standard Mac OS things, nothing special.

I am not asking "have you thought of these?", I am pointing out that they are
different from platform to platform, and exist for a reason, and you will find
yourself reimplementing a platform-in-a-platform. And it's a constant race to
copy and maintain compatibility, when the purpose of an OS and browser
platform is to allow the creator to focus on building on top of those
abstractions, not to re-implement them.

Or you will be removing functionality from end-users and making the sites
_worse_ to use.

I hope you don't find this too negative. These are big issues, and your
project touches on them.

~~~
jamarante
1) The DOM is hidden and never rendered, plain HTML will only be rendered if
the user does not allow Javascript to execute.

2) Yeah the scene graph would tell the renderer to only render the bare
minimum with a clipping rectangle. Re-rendering the whole canvas is only done
when some sort of "global" change like scrolling occurs.

3) I agree with you completely on this one. There are ways to do it for sure
but they require some tinkering. Like I said in another reply, one of the main
goals is to keep everything consistent. And actually, with the newer browsers
the text rendering has actually been really good canvas.

4) For the set of questions with hotkeys, I do not intend to remove any
functionality from end user. I never really thought about these things so
thanks a lot, now I can keep them in mind. I cannot give you a specific answer
as of right now, but I do know there are ways of capturing text selection and
keeping that selection independent from how the user tries to highlight text.

I don't find any of this negative, on the contrary I am thankful for the
feedback.

------
thrownaway954
the look and feel reminds me of GrapesJS:

[http://grapesjs.com/](http://grapesjs.com/)

~~~
jamarante
Ah, have never seen this one before. Thanks!

~~~
thrownaway954
I could only imagine what you and the grapejs author could come up with by
working together. You both are extremely talented and instead of working on
separate projects, maybe there could be some sort of collaboration between you
guys? In the era of electron applications, maybe just wrapping grapsjs inside
electron could give you the platform version of an editor that you are trying
to achieve?

In any event, I wish you all the luck in the world.

~~~
jamarante
As of right now there are no plans to integrate this app with others. Thank
you for your feedback! Means a lot!

------
gvoncheap
An absolute gem of software. Please take note to the issues listed in the
comments and keep moving forward. Sign an NDA with another developer and get
some help. This can very well open a new door for web design. I would also
consider the costs of upkeep and extensions and factor that into your price,
$50 is very cheap. Great Job!

~~~
jamarante
Thanks!

------
afandian
> Everything is design centric

What kind of design? Poster design? Graphic design? Industrial design? ... Web
design?

> designers with no previous web development experience

I don't want to sound elitist, but I would argue that designers should learn
about how the web works, or they're not qualified to design for the web.
Issues like pixel-perfect vs flexibility, the constraints of a browser vs the
freedom it gives to a wide audience. The fact that it's not just for able-
bodied people using off-the-shelf browsers.

If designers can learn all about typography and layout, they can surely learn
about DOM and CSS (or some sub/superset). Even if it's a bit messy.

> in a code free environment

Knowing the mental model is not the same as writing code. I've worked with
some great web designers, and the ones that produced the websites that looked,
felt and worked the best were the ones that could prototype their designs in
CSS.

I've only had a brief play with this, and _it does look very cool_. But you
can give a non-developer a good experience by creating an explicit and mental
model that reflects the model of the web. The "content" view does look like it
has a well thought-out consistent hierarchical semantic model (i.e. not just
smushing lots of things onto a page). But if it isn't a superset of the
Document Object Model, you're going to be fighting the browser, not working
with it.

If you're doing this, you're on the same trajectory as designing in Photoshop
and exporting image maps. Or Making Macromedia Flash sites. Or distributing
pages as PDFs or PNGs.

~~~
mwcampbell
> not just for able-bodied people

To expand on that point, my concern with WYSIWYG tools of all stripes is that
they lead designers (at least inexperienced ones) to assume that what you
_see_ is all that matters. Has the developer addressed the accessibility of
these websites with screen readers, or even with large fonts?

As for the "off-the-shelf browsers" part I didn't quote above, AFAIK, only a
very small minority of blind and low-vision people do not use mainstream
browsers these days. The overwhelming opinion among blind and low-vision
computer users seems to be that adapting mainstream applications, via screen
readers and magnifiers, is much better than designing alternative applications
just for us, because those alternatives can't keep up with mainstream
developments. In other words, we don't want "separate but equal".

Edit: Thanks jamarante for addressing the accessibility concern elsewhere on
the thread.

~~~
jamarante
No problem!!! :D

------
afandian
I'm intrigued by the HTML output of this, especially given the "no CSS"
promise and scare-quotes around "standards". I'm not sure if the "save" or
"publish" menu items are meant to do anything, as it's alpha, but nothing
happens when I click them.

~~~
jamarante
Yeah to be honest, the demo is more of a vertical slice of the application
itself. I still have not exposed that feature in the demo, it is like 80%
finished. There is a HTML Export video that shows a demo of that feature.

------
amelius
Nice, but does it allow multiple people to work on a website simultaneously?

~~~
jamarante
As of right now, no :(

~~~
Gys
Sounds as a good feature for a team or enterprise subscription.

------
pjmlp
Yet another step forward to Web "Delphi", good luck!

~~~
jamarante
Thanks! :)

------
GEBBL
Just want to say this looks fantastic and keep at it :)

~~~
jamarante
Means a lot thanks!!!! <3

