Congratulations! Glad to see more people attempting this type of thing. The demo content design is pretty nice.
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.
This is very impressive, nice job! If I can give you one piece of advice though it would be to hire a designer. You need to give people the feeling that they will be able to build a beautiful website with your product and I almost dismissed it by looking at your landing page's design, it was only when I decided to check out the demo that I was convinced.
Agree there are advantages and disadvantages of each approach. I encourage you to keep improving your app, it is indeed an excellent alpha. I always wanted to integrate canvas and SVG into Edit Room but have not done so yet. Cheers!
I've always thought about this idea. After dissecting my own process, I think Easel.io's "picture only" approach is good.
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.
The technique looks good! I feel it could use an 'inspector-like' window for all the variables instead of putting them all over te screen. Clever use of 'star-feature'. (Like Apple does with Keynote or like the flavors.me tool). Prices feel a bit expensive to me. Noticed you don't yet have a logo and/or identity?
Nice stuff man. As other have said it, the design is old school. Looking at your personal site, I know do design work as well. But I think we can all benefit from additional design help. Also, can you include the common grid marks, 960, 1280, etc.
Thanks! I won't be including pixel grids at all, but the width preview tool has some standard breakpoints baked in. I feel strongly that 960, etc are fictions created by web designers and in reality we don't have the luxury of assuming fixed widths on the web.
Absolutely! There's still much to be done, I'll be continually improving this app and keeping up with web standards. Can't wait for wider support for CSS filters for example.
Just a drawing tool in the browser. This doesn't do anything different than Photoshop or Omnigraffle, if the web designer is smart enough to reuse layers / components.
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.
The hard part about using the browser's layout engine is that it is limiting to the designer. We'd have to snap things into say, floating position, etc. And we'd have to know exactly what the designer was thinking when they're dragging some element around. Or they would have to know about floats, and how to use them.
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.
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.
The hard part about using the browser's layout engine is that it is limiting to the designer.
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
That makes a lot of sense: most WYSIWYG tools end up presenting a UI that cares more about appearance than semantics, so if you actually care about building good semantic HTML and complementary presentational CSS, most WYSIWYG tools utterly fail. So if a designer cares about building fluid layouts and semantic content rather than pixel-accurate recreations of Photoshop images, it makes sense that they'd feel very restricted in a WYSIWYG tool.
I think what you have is great and I think you should run with what people are seeing this as "awesome" for, design prototyping. I think making this into anything that generates layout or uses the browser engine is going to be either: much harder than you think, or: will lose much of the functionality that you can allow for now via "do whatever, drag/drop, absolute positioning".
I totally agree. I've been wanting an app like this for the last 6 months (wondering why one didnt already exist), and a lack of fluid layout doesnt put me off at all. The one thing I really want is realtime collaborative use, ala google docs (Firebase should make that easy).
One of Photoshop's virtues is, in my opinion, that it is NOT a browser and does not force one to think in terms of what browsers can do. Like all freedom, such a huge range of possibility does pose certain problems, but it also allows for very interesting, sometimes completely novel solutions.
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.
True, but this is just a different sort of approximation, too. Layouts where all the elements are absolutely positioned don't work in the real world, so the markup and css will have to be 60%+ rewritten and will likely not look exactly as it's laid out here.
The intent at this point is to not generate layout html/css. Humans are much better at this right now than the editor could be. And the assumption is that the programmer will want to write the layout code himself anyway, being careful to place it in nice modules that fit with their dev environment.
We could build an entire product just trying to generate semantic, reflowable markup from a design.
I agree. Let's be honest - it's kind of weird that we rely on a program that is really designed for editing photographs as our main tool for designing web sites. I'm all for exploring this further at least as a tool for doing layouts and design that CSS can handle. For everything else (e.g. designing icons), there are more appropriate tools.
It would be nice to have something that allowed you to use both. There can be so much rapid experimentation in photoshop because we know the tool so well - having that import easily into something like this for the final touchup would be ideal (in my most perfect world) as so much time goes into the touchup and the last few pixels in css.
Very cool interface. Any a very nice usage of keyboard shortcuts.
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?
It can. But things will all be absolutely positioned. The intent is to generate pieces of html and css that fit into your dev environment. The code generation is still very much in-flux, but from what we're seeing, programmers dont want the entire thing generated.
but from what we're seeing, programmers dont want the entire thing generated
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.
Aye, an export function that generates e.g. less-files much the way bootstrap has organized their imports would be killer for this app. It would make it dead simple to prototype buttons or sections of a page, and easily include them in your build process down the line. Having variables separated would also be a plus.
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.
Great idea guys! I can already see myself designing something and building a quick real-world prototype and sharing the url of that with clients.
So much better than designing/wireframing something, creating a 1000-layer mockup in photoshop, sending over a dozen JPEGS to the client and explaining what's what.
As a designer the interface is a nobrainer. I can just step in and get to work. Very easy! Nice to see 960 grids-support as well!
I understand there's no liquid-layout support but thats okay. It's not the most important thing. (And I feel you could always add support for that later).
One tip: I see the vector-drawing tool and an image import tool. How about vector-import?
It's a interesting problem you guys are tackling and your progress is very impressive! I like the UI! And for sure it's good that more people are working to make web design more enjoyable. For some time I was wondering why there are so many new frameworks for coding emerging and way less 'visual frameworks' designers can use.
That's why we are building one – focusing on freedom and responsive websites rather than code, something Photoshop can not handle for sure. More at http://www.froont.com.
Anyhow we are living in very interesting times! Looking forward to see how Easel.io will evolve!
I've tried to tackle this very same problem. I've been doing a lot of UX work for a native Mac OS, which would allow you to design similar to PS but use a preview using a Webkit engine.
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.
Congrats on putting out a great looking alpha. One question I have: The entire layout is being drawn inside of a canvas. Why was this decision made? Since (at least partly) the purpose of your tool is to output css it seems that you have tasked yourself with recreating CSS rendering inside of a canvas. Seems like a huge and unnecessary burden when just outside of the canvas you have this rendering tool specifically designed to render CSS.
You should take a look at Unbounce. While they're targeting landing pages, their page editor does this the right way IMO.
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!
I'm a web application nerd and I really think you're onto something here. As an initial offering this app has a lot of promise and I can't wait to see what else you guys do with it in the future. Everyone will be designing (pretty shortly) in their browsers it's only a matter of time with the advent of cloud computing.
It generates chunks of html. Select one of the buttons, right click, 'export to html/css'. We figured this is the way people work -- they only want small pieces exported, not the whole page.
Then I'm a little dubious about that- given that everything appears to be absolutely positioned. Reminds me of the Adobe web design tool before they bought Macromedia (anyone remember the name of it?)
re: absolutely positioning, definitely not ideal. We're toying around with different code generation techniques. We feel at this point, that generating layout html isn't really a good idea. So we're focusing on getting the colors, shadows, text, etc out out the tool.
We'd love to know what you might need as far as code generation.
This is not an easy problem (and I think nailing the parts you're focusing on first is a good decision) but if you guys could get the code generation part of the overall page layout problem solved, you'd really have something unique.
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!
I was a a bit bummed when I realised that slick scrolling is canvas. It feels outstanding on my mac trackpad. It's a very 'appy' web-app, if that makes sense.
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.
This strikes me as a good mix of Balsalmiq (www.balsalmiq.com) and Photoshop.
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!
The "Make me pretty" section doesn't render properly for me under Firefox 13.0 on Arch Linux, but it looks right in Chromium. Here's what it looks like in Firefox:
My favorite part is the HTML/CSS snippet generation. Many times I've had to play around with the CSS in Chrome inspector to get what I wanted. While it's not hard, I do like to be able to mock something up like this and then get the css.
A minor bug: if you change a value in a text field (such as the Y offset for a drop shadow) and click the OK button, the value is not saved. You need to first make the focus go out of the text field and then click the OK button.
Cool. One of the things that confuses me though are the hotkeys (control+shift+5 turns the div into a button? not very intuitive). Instead of hotkeys, I'd prefer to be told how to do it normally (in some intuitive way).
Have to say this was very confusing for me too. I can't remember a thing like CTRL+SHIFT+5, besides from the fact it isn't even explained what it's supposed to do?
Yes but Photoshop has the tools and buttons to accomplish the same thing. Generally you learn those first, and the hotkeys second. Jumping directly to the hotkeys, especially without any sort of hotkey chart, I find off-putting.
Is that a good idea or not, I wonder? Wouldn't people with Photoshop be using it instead of this? Seems like it might be a good idea to target it at non-PS owners.
As a web designer that primarily uses Photoshop, I'd say it's a great idea. Photoshop is horrible for web design. So horrible that I design purely in the browser now. This is going to be a nice addition to my workflow for when I want to include something shiny.
For standard webpage elements, this would work great. But for more customized styles, you'll still be using Photoshop or pen-paper and then jump onto this.
How is this useful? I can edit colors, border radius, box shadow, line height, font, positioning, and alignment in real time on a real HTML mockup using Firebug, webkit developer tools, even the Internet Explorer F12 tools.
Web design mockups that include these things should be done in HTML and CSS. WYSIWYG editors are crippling for professionals and poison for amateurs.
If you're interested in a library for that effect, there's this: http://ianli.com/infinitedrag/
I've been using it to make an infinite-canvas notetaking app and it works quite well.
Marquee is _really_ cool. But they are aimed at a different audience: non technical users. Our goal is to help streamline the design -> development process. The people making apps need a lot more flexibility than marquee provides.
This is cool. I like the concept. I'm hoping that someone can create a web app that reduces the need for Photoshop. You guys are off to an auspicious start. Great work!
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.
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.