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).
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.
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.
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?
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!
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.
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!
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.
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.
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.
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.
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).
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.
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
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.
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.
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.
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.
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!
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.
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.
124 comments
[ 2.9 ms ] story [ 175 ms ] threadIt's a lot easier for Adobe to squeeze in browser simulation, button states, etc. then it would be for Easel to emulate all the features in Photoshop.
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!
Just, wow.
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!
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
http://www.w3.org/Amaya/
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. :)
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!
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.