Show HN: Easel, web design in the browser
alpha.easel.io
alpha.easel.io
Some good things in Easel, but I have lots of problems with all the tiny little controls. Also it's an interesting decision to use a canvas element instead of the DOM. Without solving the overall page layout issue, this is a nice drawing tool like others have mentioned, and kudos to the technical and design effort, but in the end if you're not using the DOM, you're making pictures of web sites...
Therefore, it's my responsibility to let you all know about Edit Room, my project as an independent developer, http://www.edit-room.com/
Edit Room is also a 'web design in the browser' app, but it uses the real DOM, not a canvas, so whatever you can build with Edit Room is what is truly able to be built with HTML and CSS. It's only a slight limitation due to the unique way I've handled absolute/relative layouts. Edit Room still gives you incredible design and layout freedom, without floats.
Edit Room doesn't do fixed widths at all. Documents created with Edit Room flex naturally. Everything you layout and design with my app is based on a flexible grid, and it has a built-in width preview, so you can design at any screen width.
Edit Room exports the full HTML and CSS for your entire layout, or you can copy individual elements' CSS, it's adaptable to your workflow.
Edit Room also supports linking Typekit and Fontdeck accounts, so you can use Web Fonts in your exported designs.
You can try out the demo here: http://www.edit-room.com/screens/13/edit
Oh, and one more thing: You can animate your layers with visual keyframes and Edit Room generates CSS3 Animations.
- draw vector shapes
- export images on the client side
- filters/effects in the future
- pixelated zoom (not implemented, yet, though)
It's very common that I iterate by doing very messy things, like say, breaking menus apart into two just to see how it will work. A DOM-based tool will probably have a nightmare with this, and even if it manages to account for this elegantly, I know from experience that having too many iterations that actually mess up the code can only be a bad thing.
I like Easel's approach. I want to paint a "picture," then build it with hand-made CSS. I don't want some tool being smart about my workflow. Easel exports just the right building blocks so I can implement by picture into a webpage the way I want to.
It could be a really useful though if it had support for more than absolute-positioned, fixed-sized elements, and used the browser's layout engine instead.
Today's biggest problem is that web designers use Photoshop for coming up with mockups and then they just expect content to fit on their fixed-sized design, when the web exactly the other around - content is king.
We could build an entire product just trying to generate semantic, reflowable markup from a design.
I do both design and development and I find I use very different parts of my brain when doing one or the other. For me, it's important to stay far away from any kind of code until it's actually time to start implementing. Otherwise, I fall back to predictable habits.
We think (right now) that the best way around this is some kind of constraint system, like CAD apps have. We're not sure what that looks like yet, though.
True, and the even harder part is building a system that treats that as a feature rather than a bug.
As a user, I want the designers to be limited. Scaling by percentages and using constraints sounds like an improvement. On the other hand, I like your minimalistic tools.
Web design is all about limits. The designer has to understand, and ultimately play along, the constraints the media imposes on him - otherwise he's not a web designer, he's just a guy coming up with pretty mockups.
(...) Or they would have to know about floats, and how to use them.
Sincerely, if a web designer doesn't understand how floats work, what are they doing working with the web in the first place? Web designers != Photoshop pilots
A bit like a wiki but more rich.
My only comment is that the UI was confusing for me. After 60 seconds of playing around, here are a few ideas to consider (if you wish):
1) The "inspector" window on the right seemed to change a lot. I know contextual "inspectors" are standard UI practice, but as an Easel noob something about your implementation was confusing to me. (For example, why when I click one of the rounded buttons does the inspector say "Rectangle" and when I click another one it says "Element?")
2) There were a lot of icons that I couldn't understand at first glance. Icons are okay, but too many unfamiliar ones makes me confused. (i.e., What does the "lightning bolt" mean?)
3) At one point I had the menu bar at the top, the tools bar on the left (a la photoshop), the contextual inspector on the right, and another floating window open on the bottom left. It just felt overwhelming having so many controls open. (That was when I instinctually closed the Easel window.) Maybe you could anchor all of the floating inspectors into 1 group on the right, like Photoshop does.
4) The circles for the 2 colors is confusing to me. (What does the number inside of the second circle mean? Why do many other graphics app use 2 squares instead of 2 circles?)
5) Fields in the inspector weren't labeled. For example, when I select the "easel.io" logo at the top of the page, one of the fields in the inspector says "Lobster." As a font nerd I know that must the "font" field, but do you expect every user to know this? Some labels, or icons like Photoshop's font inspector, would help me understand what each field does. (http://i.imgur.com/CAY88.png)
Overall the UI just felt overwhelming. There was too much "unfamiliar" stuff and not enough "familiar stuff."
A good article is "Interfaces for Staying in the Flow" by Bederson/UMD HCI. On the first page there's Figure 1 (http://hcil2.cs.umd.edu/trs/2003-37/2003-37.pdf), which shows how flow is derived from a balance of skills and challenges revealed over time. My feedback is there were too many challenges in Easel at first. In terms of Figure 1, that would be a low x-axis value and a high y-axis value. This would indicate the UI may create "anxious" users.
If I may, I'd also recommend a little bit of "convention over configuration" for the UI. Although DHH talks about this in re: a codebase, I think the rule applies equally well for the UI. If there's a standard way that apps do something, try and stick with it. For example, canvas size isn't something you usually find directly embedded into a menu.
In short: I would suggest making the "basic features" more "familiar" looking at first; this way, people can get started making sites right away. Then, bury the "detail features" further in the UI so that if you want to do more complex tasks you have to spend more time learning the program. Benderson's article does a great job explaining all of this.
On a totally separate note, "Easel" is an excellent name for this product... and in this business, the name matters a lot.
As for the circles, we thought they looked better than squares.
We've been getting tons of response on the number in the middle of the circle; it is the stroke width.
The 'inspector' (good name, btw) needs work. It definitely needs better layout and labeling.
Re: challenges. Noted.
Overall, thanks for the feedback. Know that we are integrating this into our todos. :)
Can Easel output an entire web page? - meaning can I layout an entire page then get a zipped download of the page plus any CSS and JavaScript resources?
Those who don't program would love it.
Actually for developers like myself there's several use cases where having access to the complete generated source would be awesome:
1. Separate the positioning/layout styles and the color/font/design styles into separate CSS files. That way I can include all the designs created with Easel easily instead of copy/paste one at a time for each element generated.
2. For showing a mockup to a client or knocking out quick interface for a side project using absolute positioning can be acceptable.
Thank you for not trying to dumb down the UX with an 'easy to use' UI. It's clearly an 'easy to learn' UI and I can't wait to get that invite.
In Chrome 19.0.1084.52 on Ubuntu, I'm getting told to use Apple command key shortcuts.
There is no scrollbar. The scroll wheel works, but the site captures the middle mouse button (without using it?), so grab and drag (with the chromeTouch extension) doesn't work.
The little instruction sequences would make a lot more sense if they said what was happening. E.g. instead of "hold shift, click the text", "hold shift and click the text to frob the whatsit".
Grids and columns seem limited and too much work for aligning things. Check out what Inkscape can do.
There seem to be functions that are inaccessible if you don't know their keyboard shortcuts, or perhaps just not working for me, e.g. selecting multiple objects (not shift, control, or alt?!), making a group.
The apple keys are part of the design so sadly wont change.
Shift should work for selecting multiple items, so thats a bug. We admittedly haven't done much testing on other platforms.
Grouping and making elements should definitely be in the right click menu. There are some (probably esoteric) icons on the inspector/property panel for these functions.
We'll look into the chrometouch extension and see how we can make it work with the app. I didnt know it was capturing the middle mouse button. Will fix.
Thanks again for the feedback.
Two notes:
- I'm not on a mac so don't give me mac shortcuts
- Control+Shift+E is already bound in firefox (and it's a very handy shortcut)You can check out the mock I've been working on via my Dribbble site (http://cl.ly/HOrs) and the larger version is attached below that shot as well. If anyone is interested we should definitely sync up and tackle this problem.
I think you you have here is off to a good start but is definitely too basic if you are intending it to take over PS. Would be great for simple prototyping sites though.
What I'd personally like to see is a JS in-browser page editor that is (a) built on top of Twitter Bootstrap (b) open source and (c) integrate-able with other sites much like rich-text editors are.
I think you could still tack on a paid service to it, but starting with the above would be gold, Jerry, gold!
Also the Element window gets stuck on my cursor when I try to scroll through it.
Really looks great though.
Ah, ok. Will fix the stuck issue. That's a nasty one.
Edit: I'm on firefox btw.
As a mock-up tool, it's great.
We'd love to know what you might need as far as code generation.
I think by far the most time consuming (and frustrating) part of "easy" web design, at least for me, is getting the floats, clears, block vs inline, etc. stuff working perfectly without resorting to absolute positioning or other shortcuts.
If I could quickly throw together a page layout - navbar on top, image on left on main box, text lined up on right, etc. define a few properties (fluid vs fixed width), this element centered, that element indented, etc. and quickly get a working page layout system in place, that could save people hours. I'd pay for that in a heartbeat.
Like I said, I know this isn't an easy problem to solve and I like the idea of getting the per-element / style code generation done first, but do keep this in the back of your minds. Keep it up!
It wasn't until I read the comments here that I realised that this doesn't actually export html/css. It's still a downright slick mockup tool.
One of my pet peeves is getting mockups from designers that clearly fail to take the actual abilities of browsers into account. Hopefully, this can change that, while still giving them the design freedom they want!
That said I agree that, as cool and well delivered, it's against the fluid/responsive web we're in.
Web design mockups that include these things should be done in HTML and CSS. WYSIWYG editors are crippling for professionals and poison for amateurs.
Just, wow.