A Real Web Design Framework
July, 27th 2010Before you do anything else you should all read Jason’s excellent article A Real Web Design Application. It’s an eloquently worded plea for an application tailored specifically at screen design. Jason asserts that the current crop of tools doesn’t do a good job simulating the end result of designing for the screen. They’re plagued with font discrepancies (from typefaces to kerning to antialiasing) and layout issues.
The comments are filled with mostly intelligent (but some ridiculous) counter arguments. The one that stuck with me, though, was from Derek Jones:
…Look at Interface Builder for Xcode as an example – this is really the end game that I’d like to see. A tool with the front end chops that Jason describes for design and semantic markup, that intelligently hooks into server and client driven application architecture. One team of developers and designers using a single tool set to produce fabulous web sites and web applications.
If you haven’t used Xcode + Interface Builder before, Derek is right on the money, it’s a beautiful symphony of code and design. Design is done in Interface Builder, code is done in Xcode and all it takes is one click to connect the two. Intricate layouts can be created in a matter of minutes using simple drag and drop controls. Even the positioning of those elements can be controlled via a few clicks in the inspector. You set, based on one of the corners of the window, where your element should be anchored and you’re off and running.
In the following screenshot I’ve positioned an NSTableView based on the top left corner.
This is where it all breaks down. The web isn’t built according to the top left corner, it’s built around words. Words that grow, shrink and wrap. Jason’s own article is a great example of this difference:
If that image were 400px higher or 400px lower it wouldn’t make any sense, but besides the “CSS-esque styling” paragraph, it makes perfect sense. Interface Builder simply can not create this kind of layout. Sure it could get close, but resizing text, adding a paragraph or even changing the header style would cause the image to fall out of alignment.
So, no, unfortunately, I don’t believe that the current incarnation of Interface Builder is the silver bullet for web design. Might some mystical future version of Interface Builder for Web Design get closer? Possibly, but I wouldn’t bet on it.
So, where does that leave us? It leaves us hoping for an application that somehow incorporates the CSS layout paradigm into the app. For any editor to create Jason’s design the user must be aware that all the text is enclosed within some sort of container and that either that container has some white space on the left or that that container tells each child to have some whitespace on the left. Each image, then, must be told to move over to the left the negative amount of its width + ten or so pixels. Finally, if image has a caption that caption has to also be told to move over and take the width of its parent… Yuck.
Most of that last mess of a paragraph can be better summed up as:
#content p, #content h3 { margin-left: 230px; }
.illo.left { float: left; width: 210px; padding-right: 10px; }
Sure you can abstract out CSS and build inspectors and sliders for it, but in the end you’ll probably just end up with Dreamweaver.
From what I understand, the goal of starting a design in Photoshop is to free yourself from the constraints of thinking in margin-lefts and floats allowing you to focus on the design. Many of the commenters in Jason’s article took this too far and advocated a monolithic all in one web design+development app. I’d take the opposite approach: leverage what people love, Photoshop’s excellent pixel precise tools, while incorporating WebKit for rendering. Think Photoshop’s tools pallet with WebKit rendering the document view.
Comments
A great analysis, as always, Mr. Huot.
I would be interested in a more web dedicated direction for Photoshop or Fireworks. When I say that, I mean that elements of a design can behave more like they would for the ends that we’re designing for: the browser.
Posted at 12:25 PM on July 27, 2010
It makes perfect sense Jason. I hate to say it, but Pages.app is probably the closest yet in that respect… eek.
Posted at 12:27 PM on July 27, 2010
In my opinion this would not solve the needs of designers. You can’t do any actual designing in Interface Builder, only layout. The design must be done in another application, and then laid out in IB.
I would love to see something like this, but I don’t think it would solve the issue Jason brought up.
Posted at 12:34 PM on July 27, 2010
I like the idea of multiple better components coming together. This included.
Until of course, we can get the Wizzzzzzrd app - that can determine that 4 container divs is the lowest possible amount you can use to get that intricate body background that is designed and supported for browsers that don’t use multiple bg images.
</sarcasm…sorta>
I love big thinking, but I also love realistic half way points that can be used now. Thanks Mark!!
Posted at 12:37 PM on July 27, 2010
Hmm, it looks like I may have misinterpreted what you meant by this article.
I think we’ll need an app that can work outside of webkit for making things like woodgrain, complicated backgrounds, effects, etc. I also fear that if something was based on Webkit, the code it would generate would be terrible. WSYWIG tools are notorious for that.
Tough problem.
Posted at 12:41 PM on July 27, 2010
@Josh, sorry for the confusion. I agree, IB is not the solution here. Rather my hope would be a happy middle ground that incorporates “web features” like @font-face and WebKit text rendering, but leaves the layout to pixels. The idea being that this is not a development app, rather as Jason put it, a screen-aware design app.
Posted at 12:42 PM on July 27, 2010
@Josh, we crossed bits I suppose there. You’re correct, my ideal screen design app wouldn’t generate any code (in it’s first incarnation). Rather it would be, essentially, Photoshop with screen-aware tools/widgets (such as interactive form fields and @font-face support).
Posted at 12:44 PM on July 27, 2010
The problem, it seems to me, is that we are talking about design apps as something independent from semantics. This is the problem with both Dreamweaver (which guesses your semantics) and Photoshop (which couldn’t care less). To me, the ideal app would lead you through the stages of design, at each stage giving you the right tools for the job.
Start with content. Mark it up. I can imagine some helpful GUI approaches to this that keep semantics at the front and help you make sure you have everything in the right place with proper source order, elements and properties. A good tool could even help you apply microformats and ARIA roles at this stage. Of course you will have to come back and make adjustments, but this will give us a strong basis for building design on top of semantics.
Moving into a second stage we start to arrange the content into layouts that move and flow. No tool is going to remove our need to understand how that flow works, but a tool could certainly simplify the application of it. Let me define a grid and align elements to it. Let me determine the units I’d like to use, and how it should react to font/window sizes. An app could have abstracted stylesheets (as per inDesign) and let you assign those styles to any given elements based on the semantics that are already in place. You could select elements and assign them classes if needed for more complex control.
And finally we deal with the design details. We get the tools needed to manipulate css properties, but also an option to ‘insert background image’ (for example), either by pulling in an external file (e.g. ‘place’) or by building it on the spot and selecting the appropriate attachment, scroll, repeat, etc.
Yes, it’s a completely new and different approach than we are all used to from print design. You can’t arbitrarily drag and drop layers all over the place. Layers aren’t arbitrary, they are part of a flow. Dreamweaver attempts to hide that from you, and results in awful code. But that’s the way the web works. Shouldn’t our tools reflect the actual ideas in the technology behind them? The web is based on semantics, with design layered on top of markup. Our tools should take the same approach.
Posted at 01:14 PM on July 27, 2010
Don’t lock up on InterfaceBuilder, look at Dashcode: Dashcode was designed for web apps, and almost entirely built around CSS div structures, not windowed layouts. In particular, look how it handles data sources. Still not a pixel editor, but more dynamic than most layout tools. Still not, but maybe a step closer.
Posted at 01:21 PM on July 27, 2010
Great article Mark.
I think there are certain types of code an app like this could create from the outset, such as text styles and coloring, which would be pretty handy, even if it’s not production-ready code. Perhaps an option that pops up when you right-click on a paragraph that says “Copy text styles”, and it gives you the CSS of the text styles for that element. Or I’d love to see a report generated by photoshop that shows me all the text styles in the document. If the app supports indesign-esque character and paragraph styles, then we might be getting somewhere.
What I’m suggesting here are just handy features that make a developers life easier as they start to figure out how to markup and style a page. A developer can write it how she or he wants, but extracting the data about a document can be tedious.
Little things like that could make a big difference, while not necessarily be as ground-breaking as putting Photoshop out to pasture.
Posted at 01:24 PM on July 27, 2010
I don’t know if this has been mentioned yet, but it appears Adobe is at least considering the idea of adding a html layer type within Photoshop. Check out the blog post here describing the idea.
http://blogs.adobe.com/jnack/2010/06/feedback_please_html5_layers_in_photoshop.html
Posted at 01:24 PM on July 27, 2010
Eric, I’m hardly the one to comment on this but here goes: I think you’re removing one of the best features of Photoshop and one of the reasons it’s universally used for design; the speed with which you can mock up ideas. A CSS editor will never replace the ability to simply drag a blockquote from the left to the right or an image from the header to the sidebar.
Look back at my example of the image in the left gutter. Do you think Jason would have created that if he had to take the 10 extra steps of adding container DIVs, floating content, applying paddings and negative margins, etc? I doubt it, and if he had it certainly would have taken a few extra steps, frustrating steps that probably could have been avoided in Photoshop…
Posted at 01:26 PM on July 27, 2010
Very well-said. Agree completely. Like I said in the comment thread—I do believe the day will come when we have a truly great combination web design and development app. But I don’t believe it’s anytime soon, and I believe the need for a great screen design tool is very pressing. So for now, forget the development and someone build us a great design app.
I will say, though, that the guy you quoted did say, “look at Interface Builder for Xcode _as an example_,” and I think he’s totally right that we should be looking to it as an example. You’re also right that it’s not the perfect tool for screen design, but there’s a lot of great stuff in there, and if someone is going to build a great screen design tool, I hope they take some cues from Interface Builder.
Posted at 01:26 PM on July 27, 2010
What about Dashcode? It works much like Xcode + Interface Builder. You build the templates and later plug in the content through a web service, Json, XML, etc.
It seems to me that Dashcode is often forgotten. The newest version lets you do mobile and full page sites at once. And it mostly spits out cross-browser code. Yes, because of the way the built-in components work, JavaScript is required to view its sites. But it’s definitely an app to consider.
Posted at 01:31 PM on July 27, 2010
@Brian I agree, it’d be great to say, “show me all text styles” or universally apply the same style to all headings, etc. I think that’d certainly be in the cards for a design app like this. Again, probably not for the first release, but some day…
@Jeff Thanks for the clarification. You’re certainly correct there’s a lot to be learned from the interaction between Xcode and IB. I’d love to see a FORM’s ACTION attribute set via drag and drop and INPUT’s NAME attribute applied as an IBOutlet would. It’d certainly make rapid development a bit easier.
Posted at 01:32 PM on July 27, 2010
Eric: Your app sounds interesting, and may be cool in it’s own regard. But for me (and I think for Jason, as well), a proper screen design app wouldn’t have anything to do with markup or CSS, because doing so assumes the final product will be created in markup and CSS. These days, as much of my design work ends up as an iPhone app or a Flash app as it does HTML and CSS. Your app idea is very much engrained in the idea that your content will be “marked up,” and I don’t really think that’s necessary—or even desirable—in a proper screen design app.
Posted at 01:33 PM on July 27, 2010
Looking back, it was the aha moment reading Andy Clarke’s Transcending CSS when I “got” the point of semantics. That insight coupled with a solid understanding of how the box model works differently from fixed dimension layout enabled me to really start designing with web standards instead of in spite of them.
The app that we’re all yearning for has to be built around the box model and semantics, rather than abstracting them away behind a wysiwyg layout tool. The problem with all of the design tools we currently use is that the fixed grid doesn’t translate directly to the web.
Posted at 01:34 PM on July 27, 2010
I remember getting so excited the first time I heard that ImageReady (remember that app?) could export your designs as HTML. That was, until I saw the code.
My dream design app? Photoshop that can export my designs as valid XHTML. Of course, I’d also like a pet unicorn and a million bucks, too.
Posted at 01:36 PM on July 27, 2010
@Erik I think the problem with Dashcode is that it’s too developer centric. It’s too difficult to rapidly create gradients, drop shadows, shapes and graphics. I like the idea, but it’s missing that “Photoshop tools pallet” that I mentioned.
@Jeff I couldn’t agree more:
I think what Jason is going for (and what I’m agreeing with) is that this mythical (in it’s first state) app wouldn’t be for code at all, just a design app that’s aware of the screen and it’s features.
@Joe I’m afraid you’re missing the point of this first exercise. The goal wouldn’t be to “translate directly to the web”. Rather the goal would be to better facilitate the handoff between web design and web development.
Posted at 01:42 PM on July 27, 2010
“It’s too difficult to rapidly create gradients, drop shadows, shapes and graphics. I like the idea, but it’s missing that “Photoshops tools pallet” that I mentioned.”
The latest Dashcode was released before webkit really started throwing its weight behind HTML5/CSS3 capabilities. Because you can edit the CSS directly, you can add such things manually, but there are a lot of us who are hoping Apple includes tools to work easily with these features in the next Dashcode release. (That may be why it hasn’t been updated or discussed in a while.)
Posted at 01:49 PM on July 27, 2010
@MonkeyT CSS3 support will certainly help, but I don’t think it can ever replace the paint bucket, brush tool, gradient tool, layers, vector tools, etc that are in Photoshop.
Posted at 01:52 PM on July 27, 2010
I agree with Eric Meyer.
I have to keep telling myself that it’s futile to be upset with the awful original concept for the web that has resulted in it becoming nothing more than a giant mess of unbelievable proportions and causing untold wastes of time as people struggle with making simple things happen.
Here we are in the second decade of the 21st century and we’re all still struggling. I once made a list of all the web technologies that one can employ in web design, e.g. javascript, PHP, ruby on rails, Ajax, Cold Fusion, etc. The list is unbelievably long. The people that think this is cool and beneficial, well…
But Eric hits on an essential app design criteria—acknowledging the fact that EVERYONE needs to get engaged with web design at some point, but VERY FEW of us want to do it full time, which you pretty much have to do to be able to do it reasonably well.
We might spend a lot of time up front learning lots of details about how to make something happen, but then we return to our regular jobs, and forget most of what we’ve learned. Don’t make me have to remember anything.
I write iPad apps for a living so I can handle technical details, but I have NO TIME to learn stupid esoteric details about how to make a simple effect happen on a web page. I have Dreamweaver, but it’s the Microsoft Word of web design. I have some choice words for IE6 compatibility, for instance. It’s endless.
The ideal app would be like Garage Band, allowing you to create something really impressive in a short amount of time, but all the stuff is there allowing you to tweak further and take over control if you need. Like power steering that still allows manual control. I just want to get in the car and drive. Why can’t I?
Typography is something I always struggle with. Stop only giving me the option of groups of fonts and 7 preset sizes and paragraph behavior that doesn’t match reality.
I’ll stop there, if someone will come along and stop the madness. Sorry, but I’m not alone.
Mark Hernandez
Information Workshop
Posted at 02:10 PM on July 27, 2010
@Mark I’m not sure a seasoned musician would agree that Garage Band is the ideal tool for arranging music. There’s an important distinction to be made: is this Garage Band or Pro Tools. I believe Dreamweaver already has the Garage Band market covered, what people are clamoring for is a Pro Tools for screen design.
Posted at 02:20 PM on July 27, 2010
“I think we’ll need an app that can work outside of webkit for making things like woodgrain, complicated backgrounds, effects, etc.”
Already exists, it’s called Photoshop.
What we need is the equivalent of InDesign for the web.
Posted at 02:21 PM on July 27, 2010
Hey, Steve Jobs himself said two platforms Apple is focusing on are iOS and HTML 5. I wouldn’t be surprised if Apple released a web design app like iWeb, only for professionals. Too far fetched?
Posted at 02:23 PM on July 27, 2010
@AG interesting. I hadn’t thought of it that way, but it makes sense.
Posted at 02:24 PM on July 27, 2010
Interesting thought Scott. I just read on MacRumors or somewhere that iWeb was going to be discontinued from iLife, and a new “Mystery App” was coming.
Posted at 02:26 PM on July 27, 2010
Oooo, the mystery of it all. I’m a little scared though to see Apple enter the ring on this one. Their web support hasn’t been to the same caliber as everything else they do. Javascript and CSS3 requirements make me cry every time I’m directed to one of their MobileMe galleries. I wish they pulled in some of their public website guys to help out in MobileMe.
Posted at 02:31 PM on July 27, 2010
I’m not really interested in the idea of a monolithic app that just turns layouts in to code - websites should be hand coded - it’s the key skill of a good web coder to think semantically and consider how to structure both html and css. But that’s not the problem here, I think. The issue is that Photoshop, whilst an app that in most respects I love, has almost no useful web focussed features apart from slicing up and optimising images.
What I’d really like to see is:
1) a version of layer effects that represents the way browsers render elements and css. I’m thinking strokes that actually are the width that you set them to, gradients that are applied in the same way as css gradients and so on. And then on export, could give you code snippets for the appropriate css for that element only. So if you draw a button with a gradient, stroke and border radius, you could export the css for that element only.
2) Accurately rendered text (ideally with options for different browsers/platforms) with sub pixel antialiasing, which can have styles associated with them so you can quickly change fonts, letter spacing and so on across a mock up. Again, an “export this style” function would be handy.
In these two ways, when you mock your layout up in Photoshop, you’re applying styles. If these styles could better resemble how they’re rendered in a browser it would make creating accurate mockups much easier, and hopefully reduce the duplication of work.
Posted at 02:42 PM on July 27, 2010
Missing the forest for the trees here. What we want is a decent HTML/XHTML interpreter like we have all been spoiled with for 20 plus year (Postscript).
Remember Flash? Flash before all of this mess, when it was fun. when you could place things on a page. pick the font color size, make it move or mouse over or what not. There is a reason Flash was popular for so long.
Interface builder is not the solution but something along those lines is.
This should be very simple we have been drawing to the screen for 30 years now.
I want to draw something. I want to feel my way, I want to visually interact with what i am designing.
Get over this browsers can’t thing, they are tools, they are digits, the must bend to the will of their creators.
Imagine if we harnessed the power of all the frustration with IE6 in a constructive way to create a tool that respected standards and that anyone could use.
I am not looking for magic, I am looking for the computers to start doing their fair share of the work.
Posted at 02:44 PM on July 27, 2010
P.S. I agree with Mark Hernandez. Spot on. Machines working for people, that is what computers are all about.
Posted at 02:47 PM on July 27, 2010
@StuartI like where you’re going with that. I think we’re on the same page in needing a design app that may help with code, but it certainly wont write it (in the first version).
@27ray I think it’s so much more than just drawing to the screen. Look at where we are with Postscript and PDF support. Apple had to write an AI language just to get realistic text selection out of multi column documents… I’m not so sure we were spoiled, just complacent?
Posted at 03:01 PM on July 27, 2010
Some of the issues addressed I totally get, like the option to style your typography much like you would in CSS. However, other wishes stated I feel are less important. At this point I must admit I’m not a designer, so i might be missing the point just a little bit. But still… Let me take text rendering as an example, but I’m sure the principle applies to other design elements as well.
Why is it that important that type rendering is equal to browser text rendering? As we all know, websites do not need to look the same in every browser, and not all web sites do. Text rendering differs per OS, settings, screen and browser, so why not for your design tool of choice? If you settle for webkit rendering, than it’s just one of many rendering possibilities—the type will look completely different in IE 7 on WinXP with ClearType turned off.
I feel that designing for web has more to do with conveying an idea or concept rather than pixel perfect imagery, whether that consists if actual images or a combination of typography, layout, grids, etc. Isn’t having a tool that lets you design for the browser just that—a tool that lets you design for *one* browser?
Posted at 03:04 PM on July 27, 2010
@Low I understand what you’re saying. I’m no designer either, but as I understand it there’s no reason to throw another variant into the mix. Photoshop’s custom rendering is totally different than any web browser, so you’re forced to guess what it’ll look like in Safari/Firefox/IE/etc… If it could at least approximate one of those it would take some guess work out of it.
Maybe a more concrete example is that the underline tool in Photoshop looks like nothing you’ve seen before in a browser. It feels around 10 pixels lower than a standard underline. So, when designing in Photoshop you’re forced to draw in every underline by hand or live with the wacky underline and explain to your client, this isn’t how it’ll look in the end.
Posted at 03:17 PM on July 27, 2010
I was just coming back on to agree with 27ray. he he.
Hey, everyone’s made great and lucid comments here, and all valid points of view. I love it.
The clear conclusion we can draw is that there’s no silver bullet, and there are many competing interests. But I do believe that the “easy, get in and get out” part of the equation needs some attention.
Hopefully things will get easier and smoother, but it will be an uphill struggle…
I have been in computers for 40+ years and have seen tons of great ideas come and go, especially computer languages, but to this day we still have the C language (and all its variants) that most everything continues to be coded in. Like the web, the C languages was assembled in an ad hoc fashion by a bunch of guys in 1972 to fill an immediate need having no idea the universe would eventually be based on it.
One huge dynamic at play here is that those who have invensted an unreal amount of time learning the tangled web of web technologies, and exceptions to the rule, are not too keen on things becoming so simple that anyone can do it. It’s a human thing… we all want to be needed and not become obsolete.
And there are those of us who are so overloaded just managing our own little corner of complexity, that we breathe a big sigh of resentment, and maybe mumble a four-letter word under our breath when we have to stop and go learn and deal with another one.
Mark
Posted at 03:19 PM on July 27, 2010
@lodewijk Just imagine what the world would be like if commercials on TV rendered differently depending on the TV you owned. What if magazine layout rendered differently, billboards, or the type in a book you are reading rendered differently because of some reason (like whether your glasses were made by Microsoft, Google, Apple or Firefox, etc.).
(Please oh please God, do not let this conversation devolve into “open vs. closed/controlled” or we’ll never go home. :-) ha ha.
Mark
Posted at 03:34 PM on July 27, 2010
I wish there was an easy way to get the Typekit fonts into the mockups I show my clients. Right now my options do this are:
1) Copy and paste screen grabs of Typekit fonts from their type tester tool into a PSD.
2) Buy a version of the font to download and use in my PSD mockups, spending more money in addition to the web font licensing fee.
3) Create interactive html/css mockups in the browser that show how the fonts will actually look.
In terms of the final result, interactive mockups are by far better than static PSD comps for a number of reasons including font rendering. The obvious drawback to #3 is the technical skill and added time required.
Much of this discussion has revolved around improving methods #1 and #2. Perhaps the innovation needs to come in making #3 more doable.
Posted at 03:37 PM on July 27, 2010
I actually disagree that webkit should be involved at all—do designers really want to design their work within the limitations of a particular renderer? You want your design to come from your spark or vision. Don’t let it be inhibited by what one engine can and can’t do. I suspect it would quickly become frustrating to drag something to one spot, only to have it snap up to another spot because of the way the design application “sends it to webkit.” I think Jason wants the right thing, but I feel like its implementation needs to be completely decoupled from its target rendering environments.
Posted at 03:49 PM on July 27, 2010
Glad my comment struck a chord with you Mark, but I think the faults of Interface Builder are being highlighted too strongly here. It’s not its design capabilities that I think will be critical to the future of the industry, but rather its ability to directly attach designed UI elements to programmed architecture.
My main point was in response and agreement with Jeff Croft, that the markup experts will eventually become a thing of the past, and there will be tools that cater to firms and technology built around designers and programmers. The web will not forever remain the domain of markup and CSS experts. I’m speaking “end game” - far into the future, not around the corner.
It only sounds like a behemoth all-encompassing application concept now because of that currently necessary focus on the myriad of layers that go into building a complete web site. Eventually technology will hit a point where that can be done without having to expose the programming layer too. Who knows, in the end it’s probably going to requiring something entirely new. Eventually people will tire of expanding and stretching the hypertext concept for delivering digital content.
Posted at 03:52 PM on July 27, 2010
What Derek Jones said is spot on. We don’t need millions of monks illustrating books. We need a printing press for the internet.
Posted at 03:59 PM on July 27, 2010
@Warsaw The way I see it, a big problem in web design today is that design and development are much too separated. So I don’t agree with you that design tools need to be completely decoupled from the target rendering environment. Is the true design the pristine pixel perfect PSD or is it the real site in the browser that people actually use?
As someone who began as a developer and transitioned to being a designer I think what is needed is for designers to learn to think more like developers, and vice versa. Our design tools need more of the web, not less.
Posted at 04:06 PM on July 27, 2010
@Jeff everything I see here seems pretty web focussed (see the title), but I believe you that a more general app would fill other use cases you have. I certainly see the need for an indesign-for-the-screen.
All I’m suggesting is that if we want to deal with things like “flow” we’re talking about flow of content, which means content that we have to label and control. So why not approach it from that direction. Content first. Then label. Then adjust.
I don’t think this would be a garage-band solution, although there’s nothing wrong with making an interface easy enough for people to use. You would still need a clear concept of how flow works, and what a float is, and how to layer backgrounds and on and on, even if you never touched the code.
The only reason hand-coding is the current sign of a good developer is because there’s no tool that does it for you correctly. Frameworks are nothing more than an app writing code for you. Django, Rails, etc. The reason the tools we have dont do it right is because they pretend that you can do design first and ignore the semantics of the content. They pretend that so that you can have your drag and drop. I just don’t see that as an interface that will ever be useful when talking about content that flows.
How would you build a flow-aware design app without some level of semantic marking-up (whether html or otherwise)?
Posted at 04:19 PM on July 27, 2010
As a graphic designer and web developer moving between Fireworks, HAML and SASS, I like both Jason Santa Maria’s inclination towards quick visual prototyping and Eric Meyer’s towards design using web logic, and I don’t think they are mutually exclusive. Think about it: the very nature of visual design is actually a content hierarchy. Wether you like it or not, even a photoshop mockup visually implies its own content hierarchy.
Picture this (I’ll being specific for the sake of illustrating an idea): a structure outliner, a graphic composer, and a dynamic styles palette. On a left pane, an outline of the content structure (mainly text, but also bitmap, sound, video). Any graphic designer should be able to use an outliner. On the center, how those elements appear visually and flow in the page, and the possibility to drag stuff around, group items together, etc; powerful graphic editing capabilities (gradients, possibly built-in image editing); and a contextual inspector allowing to set a class or an id for an element, and multiple visual attributes. On the right, a dynamic style palette, with control on how they are applied into the hierarchy. Select ‘View Source’, and the program hands out a perfectly structured HTML along with - maybe a bit more chaotic - CSS code, all without ever asking the designer to write any syntax.
The left and center panes could be used alone for quick sketching and prototyping. Any attributes created on the center would appear on the right styles pane, which itself could be used once the designer needs control of more than one item at once. Move something in the center pane, or group elements together, and the tool would be clever enough to modify the hierarchy structure: move element one position down a list, or group all elements together inside a container (abstraction for a div), and it would be clever enough to modify the styles. Further, there could be lock buttons on each pane, for specific cases where for example the user wants to drag stuff around without automatically modifying the hierarchy, only the style.
It would be both a mocking tool and a development tool: visual design and markup could be produced without leaving this program.
By following the basic logic of web standards (style on top of structure), this tool could actually help the designer to be more organized, by having a perfect outline of the content hierarchy visible at all times, and at the same time produce a nice separation of content and style (like decorative images in the CSS, when possible). It would be a great tool from quick prototyping of the page appearance and flow, and it could be a great tool even for seasoned developers, who want to be able to abstract themselves from the painful syntaxes and defects of HTML and CSS.
It would be an opinionated tool as far as the best code to output, but has long as it has good taste in pretty markup, I think designers and developers could live with that.
(Eric’s last comment was added while I was writing this, and I think he’s closer to this idea than I assumed after his first comment. But maybe this is a valid answer to his last question.)
Posted at 04:51 PM on July 27, 2010
> Start with content. Mark it up
Me, I always start by building the whole website just in semantic HTML, with no thought to any styles or scripts at all. I separate the sections with named DIVs, but they’re not positioned, they just flow so that they make sense even with no layout. Later they get used for layout, but at first they are just semantically dividing the various sections. Then that is the website that runs anywhere. Everything else after that is progressive enhancement. The CSS and JavaScript are always optional by definition. I’m happy to make this much of the site in BBEdit, there is no need for anything else.
But once the semantic HTML website is built, and it is time to add the CSS and JavaScript progressive enhancements, that is the point when I want a visual editor. Then I’m frustrated by the fact that I have a Safari window full of website and empty Photoshop/Illustrator windows full of visual editing tools. There is a DOM there, but no DOM editor. There are visual tools there, but they edit the Photoshop/Illustrator DOM, not the Web DOM. And so I have to manually keep syncing up those DOMs. Whether by copying content into Photoshop/Illustrator or copying metrics or colors into the Web DOM by coding.
I want an editor where the Safari window becomes my document window, and the DOM I’m editing is the actual Web DOM. I don’t want the browser window to lose any of its features, I still want to be able to browse from page to page as I edit, and I want the HTML to be left alone except for adding or removing external CSS and JavaScript files. I want visual editing tools which enable me to grab any element and modify its properties and see the change in real time with no Refresh. Also I want the external CSS and JavaScript files shown in windows so I can add a line of code and see that change immediately reflected in the site with no Refresh.
A second window that was smartphone sized would be cool also, so you’re simultaneously seeing the full-size and mini rendering as you work. These would be the same at first, but once you put in a media query detecting a tiny screen they would diverge.
Basically, we are making documents that run in a browser, we should be editing in an environment that is centered around a real true Web browser. But we should be able to grab an H2 and change its color via a color palette, or grab a positioned DIV and move or nudge it, or add and edit background images while seeing each change reflected in real time, and establish a grid that positioned elements snap to, and so on. But do not touch the HTML! I definitely don’t want an HTML editor. BBEdit is already that. The part of the site that is not optional is all code, it is best done as code. I just want a CSS and JavaScript editor with really great design tools and the ability to apply that visual/interactive layer to any arbitrary semantic HTML website viewed in real-time in a browser view within the tool itself.
Posted at 05:04 PM on July 27, 2010
@steph I like it. Yes. That is what I’m talking about.
I still think the design tools would have to be built around screen/flow concepts - concepts like boxes and floats that add a logic to changes in the flow. I happen to believe that it could be done smoothly, without slowing down the inspiration and exploration of your design process. It doesn’t mean more complex tools, just different tools and a different way of thinking about them. Rather than movements being arbitrary they are relative to flow. And with a quick outliner handy you can adjust that flow whenever you have to as well.
Posted at 05:12 PM on July 27, 2010
This is for the coders rather than the designers:
I’m often responsible for taking a Photoshop comp to markup and CSS, and I know what I’d like to see: A .psd-reader that can give me something like WebKit’s/Firebug’s “Inspect Element”: Click a visual element in the comp, and you can see its dimensions, offset, fonts, etc.. Not as CSS, but simply as straight information. It’d also be awesome if any element could become a slice-box, so you could quickly see which layers intersect to form its content, deselect the ones you don’t want/need, and export the “slice” right away to use as (background) image in the markup/CSS.
Yes, it’d probably require quite a bit of engineering for this imaginary app to pick out discrete “elements” in a bunch of vector and bitmap layers, but still.
Now combine that nice, clean (and imaginary) .psd-viewer with a sort of 2-up view with the Photoshop comp on one side and a live, rendered view of your code on the other. (And yes, it’d be awesome if you could switch renderer on the fly.) So you use the .psd-view to get some information on the “elements”, you use your human intellect to write good markup and CSS, and immediately see the results side by side with the comp.
Note that the .psd-reader I’m imagining here isn’t necessarily Photoshop itself. In fact, it’s probably better that it’s not. “Firebug for .psds” is a pretty concise description.
This imaginary tool only makes sense in the Photoshop->hand coding workflow, but that does seem to be the norm. It is for me. No, it’s not different from having Photoshop, a text editor, and one or more browsers running; it’s about streamlining the entire thing. Let designers have their “designer’s view” of things in Photoshop as usual, and let the coder have his/her view of the same comp.
Now, if Photoshop only had some better type rendering and styling tools, and maybe some interactive web-like elements, and so on and so forth, then we’re really cooking!
Posted at 05:16 PM on July 27, 2010
@eric I’m glad. Now I feel a bit less ashamed for that mammoth sized comment.
Also that tool could be thought not just as a web design tool, but as a general graphic design tool. A graphic design tool with a different approach to the content hierarchy.
The final format it would output could be something else than web. Print: multiple sizes for a flyer/poster. An iOS book that adapts to landscape/portrait mode. Etc.
Posted at 05:31 PM on July 27, 2010
@Jeff is making my argument over on Jason’s original post better than I am here.
Posted at 06:03 PM on July 27, 2010
I think there are two quite different requirements, that we try and jam into one tool.
One is focused on ‘Content’ sites - good old classic multimedia creation. These may or may not integrate with some kind of CMS on the back-end, but they are low on things like data validation and controls that change based on entered values.
The other is ‘Application’ sites which need to integrate with more complex - and less standardised back-ends. These are generally closer to the XCode model, and what Adobe are aiming at with Flex Builder or whatever it is now called.
One other thought : a lot of people worry about the quality of generated code. You don’t worry about the quality of the mark-up inside any PDF documents you produce or consume. It’s worth reflecting on why (I know the answer is that we are rarely expected to maintain the code inside PDFs or integrate them to something else, but it’s also worth remembering that HTML started out as the internal format of a WYSIWYG tool).
Posted at 06:43 PM on July 27, 2010
@Eric: “Frameworks are nothing more than an app writing code for you. “
This is patently untrue. LIbraries fit this description. Frameworks add a whole lot more than that, and in fact, it’s a framework(s) that seems to be missing here.
Frameworks create paradigms. Frameworks create patterns and program flows.
Everyone seems to be looking only for something that lets you automate your *current* way of doing things, when in fact, what’s likely to revolutionize your world is a new paradigm that a new app will create and then enforce.
Just like Photoshop did with introducing layers. Just like object oriented application frameworks did with introducing responder chains and event handlers. Just like MVC did for separation of division of labor in programming.
Put another way…why did Lightroom adopt the linear “waterfall” paradigm of photography (“Develop”, then “Print”?) in its UI when digital photography does not require chemicals and paper? Aperture, on the other hand, departs from photography and embraces the advantages of digital at the expense of the traditional mapping.
As a software developer, I always have to walk that line between giving a client what they ask for (they don’t know what is possible) and what I can offer them (I don’t know which “game pieces” can’t be moved).
I don’t think there’s going to be a Grand Unification at the level at which things are done now. There may not be a grand unification to be had at all, but I think it’s too early in the game to call it yet.
Posted at 11:55 PM on July 27, 2010
@Mark I’m having a hard time buying the “people are worried about becoming obsolete” argument. The point Jason is trying to make, I believe, is that he’s looking for a tool to assign the design process, not replace the front-end development process. I understand where you’re coming from and see the concern, I just don’t think that’s the problem Jason was trying to solve with his post.
Also, just to be a jerk ;), TV does render differently on each TV’s aspect ratio. That’s why we have TV safe guidelines and OS X has the “overscan” option.
@Joe That’s exactly what Jason is talking about. That convoluted process needs to be simplified. @font-face is certainly one of the obvious problems, but antialiasing and word wrapping needs work too… You’re spot on with your assessment that “our design tools need more of the web, not less.”
@Warshaw The point I was trying to make above was simply to use WebKit to ensure widgets and controls rendered as they would in a browser. I don’t think my proposed tool would use the XHTML/CSS layout engine. Essentially everything would be absolutely positioned (just like Photoshop) so you had that drag and drop ability that you do in Photoshop combined with the realistic rendering of WebKit.
@Derek Thanks for chiming back in. I apologize for the miscommunication, I didn’t intent to highlight IB as much as it is. This thread and Jason’s, as well, took a right turn and became “how do we automate more of the build process” discussions when I don’t think that was the original intent. I agree fully that “The web will not forever remain the domain of markup and CSS experts.” I also agree that the “myriad of layers that go into building a complete web site” will reduce in the coming years. What I was trying to expound on, however, is the fact that the design process (as streamlined as it may become) still needs a tool optimized specifically for onscreen design. That tool doesn’t exist today and I think Jason is clamoring for it to be made.
@27Ray Eek. Really? Certainly there’s some place on the internet for those monks, no?
I’m with you that some day we will have a “printing press for the internet” I just don’t know that the creation of that precludes designers from having a tool to better approximate the final output.
@Steph just for the sake of argument replace a few words in your comment:
/structure outliner/code view/g,/graphic composer/design view/g, and/dynamic styles palette/styles palette/gand I believe you have Dreamweaver… The idea I’m pushing for doesn’t involve code at all, rather it’s a modified Photoshop that embraces screen design.@Eric after reading your comment and Steph’s comment I’m beginning to come around. The following:
sounds quite nice, but seems like a tall order too. I’m not sure you could ever make the current box model/float theory interaction “smooth” but I’ve certainly been proven wrong before.
Posted at 06:16 AM on July 28, 2010
continued…
@Daniel You got there at the end, what I’m hoping/striving for is exactly as you said:
@JulesLt Look at the file size difference between a web page and a PDF though. Not worrying about the source code has left us with a bloated mess of an implementation. I made this point earlier, but Apple had to write an entire AI engine to make sense of text selection is that automated code… I’m not sure that’s where we want XHTML/CSS to end up too.
Finally!
To play devil’s advocate, I suppose, I would have to ask OS X designers if they feel their tools are adequate for onscreen design. My guess is no. Even with Interface Builder designers are still using Photoshop and Illustrator to explore design. I highly doubt that exploration is done directly in IB (if it was there wouldn’t be a need for iPhone GUI PSD templates).
My reading of Jason’s original article is not that he’s looking for the Interface Builder of web design but rather a tool to better facilitate the actual experience of working on a digital screen. A screen-aware tool built from the ground up for onscreen design, not a photo manipulation tool mangled into working onscreen.
Posted at 06:16 AM on July 28, 2010
@Mark: As I said, my suggestion was mostly aimed at the coders, but I too would love to see improvements to Photoshop’s font and type capabilities especially. While it’s not my primary gig, I’ve designed web sites in Photoshop too, so I know the pain. I’ve also often had to tell print designers that their Photoshop comp or PDF simply won’t look the same as a real website.
My suggestion was meant as a sort of compromise and an alternative to a more monolithic app that does everything. There’s no reason Photoshop should be intimately familiar with CSS, and there’s no reason a “website IDE” like Coda should have all of Photoshop’s graphics tools. But something that could go in between and present the information in a .psd in a “context-appropriate” manner would be really useful. The designer retains all the creative freedom of Photoshop, and the coder can view the same file, but with tools suited to his/her context.
The inspiration is something like film editing: Cameras are tools that capture the scene; the editor has the tools to cut the film; the effects shop have a ton of tools for creating effects; the color grader has the tools for his or her job; and so on. The common denominator for all these is the film, not the camera or any specific piece of software. Likewise the comp would be the common denominator for designer and coder, not the tool itself.
Again, none of this absolves Photoshop of its type rendering sins. An improvement to Photoshop would benefit all involved. But at the same time, there’d be no need for Photoshop to become WebDesigner’sShop (if it does, then great, but it’s not necessary).
Posted at 07:50 AM on July 28, 2010
@daniel, you said:
i think you’re on the right track, but i take issue with saying the common denominator for designer and coder is the comp. the film is the final product and the common denominator. the design-in-the-browser argument is based on just this idea. the common denominator should be the actual product, not a facsimile thereof.
personally, i really like the idea of “feeding the app markup”, since we can relate that to the script, in this metaphor. and that’s the starting point for everyone. i build a lot of sites that are more app than magazine (fantasy sports apps), so i do start thinking about the subtle differences that entails. still though, it’s fundamentally about the markup—that’s the underlying structure and meaning of what we make. i know it’s web-centric, so maybe the concept needs modification to make it less so, and more generalized to screen design.
anyway, this has been a great discussion here and on jason’s site. i think a way forward is emerging, and i certainly hope there’s a smart software developer or firm out there that picks up the gauntlet here. panic would be fantastic, of course, but maybe there’s a young hotshot who can make this their claim to fame.
from what i’ve read so far, it seems like the core capabilities of this *design* tool (not code-generation tool, let’s just stay away from that nightmare) would be:
- screen-based resolution settings
- per-document grid settings
- multi-page documents
- common elements across pages (masters/templates)
- style sheets for type and objects (ideally cascading)
- css-based styles (i.e. background repeat)
- vector tools or integration with vector editor
- bitmap tools or integration with bitmap editor
- library of common widgets (form elements, etc.—ideally a plugin architecture to add libraries)
- box flow model for web design (import/edit markup?)
- browser-based type rendering
- interaction states
looking at that list makes me thing two things: people who suggest indesign as a basis are on the right track, and designing in the browser might be as close as we have right now. and by designing in the browser i don’t mean no ps/fw/ai at all.
but if we are to have such a design tool, i agree that a webkit-based solution sounds promising, and it would need to be a mix of photoshops fundamental image editing features with a stronger document/page model and styles, with a dash of dynamic states and interaction capability thrown in there.
what a fascinating thought experiment.
Posted at 08:51 AM on July 28, 2010
Photoshop is already fairly close I think. It works great for designing the header and footer, navigation elements, backgrounds, etc, the ‘designy’ stuff. The problem I always have is when I get to the body of the page, then it’s time for layout, typography, margins, form elements, etc. I’ve tried coding just the body, then take a screenshot and drop it into my design. Less than ideal. I’ve tried doing the body layout right in Photoshop. Doesn’t work great. I’ve tried putting the body layout together in Illustrator and bringing that into Photoshop. Also not perfect. What I need is to be able to switch to a layout engine right in Photoshop. Maybe create a new layer group and tell that group to use the layout engine, then voila I can work with a new set of tools in that layer group, a kind of InDesign meets OmniGraffle maybe. That would make for a very fast, iterative design process. You could also then use Photoshop for wireframes very easily.
Posted at 09:35 AM on July 28, 2010
@eric, you said:
“The idea I’m pushing for doesn’t involve code at all, rather it’s a modified Photoshop that embraces screen design.”
I think you misunderstood, what I was proposing did not involve code at all, only logic, and it’s a logic already implied within graphic design itself. But my writing was probably too confusing, I think I’ve summed up the idea into a more intelligible way when commenting on Jason’s original post (sorry for the back and forth…):
“there is a correlation between web standards (HTML + CSS) and the nature of graphic design itself (communication of a content hierarchy) that perhaps could be exploited to build a graphic design tool that has a built in feature to help organizing the content hierarchy, and such tool could be ideal for prototyping and outputting markup.”
You could maybe think of it as a photoshop with an outliner.
Posted at 11:48 AM on July 28, 2010
@river:
I see your point. However I would say that the comp does - at least right now - constitute a common denominator for designer and coder. At least in the process of turning the comp into code. The app I’m proposing is something that could (hopefully) be created right now. Photoshop wouldn’t have to change, and coders could stick with the text-editor of their choice; the app would be an addition to the workflow, not a replacement for anything.
It’s true that in the filmmaking analogy, the film is both common denominator and final product. It’d be very cool if that was the case for web design too. But as of right now it isn’t. And maybe that’s ok.
Other, more suitable, analogies might be achitectural drawings or CAD models. Both are ways of transferring information between design and production, but they’re not the final product. Industrial designers don’t use a lathe to sketch designs, and production people don’t shape a lump of steel with a pencil and markers. They each have their tools, and a common way of exchanging information.
Since a .psd is the de facto data interchange format between web designer and coder, then why not exploit that?
Posted at 12:22 PM on July 28, 2010
@daniel,
i’m not disagreeing with the concept of a tool that does this. i work a lot in photoshop, and i would be very happy if it, or something like it, had a set of tools that made the job of screen/web design a lot easier and more intuitive. so i’m all for this approach.
on the other hand, we have a final product that can be shared by designers and builders while in progress, is very malleable, and will continue to change throughout it’s lifespan. building web sites is distinctly different from architecture or industrial design. so my point was simply to say that we have to be careful of being too invested in static visual comps, and i find that the sooner i move to actual markup and styles, the sooner i resolve a lot of issues that will inevitably arise.
i think jony ive said it well when talking about creating the iphone 4 (industrial design). there’s no substitute for working with your actual materials. i think this is true of web design as well. working out ideas via sketches (on paper, in ps, etc) is great and necessary. it’s flexible and quick. but again, it’s not the *actual thing*. i bet if architects could construct a rough building, walk through it, move things around to try it out, all cheaply and quickly, they would. we have that power, and i say we use it more.
Posted at 02:12 PM on July 28, 2010
@river,
Excellent points one and all. I was probably too caught up in my own experience of the matter, which - very unfortunately - often involves me being the “code monkey”. I get handed a comp, and that’s it: “Make this here design but like, y’know, on the internets and stuff”. Hence, my desire for the kind of app I’ve described.
And it’s absolutely true that there’s no substitute for making the real thing. But there’s this nagging fear that a one-size-fits-all tool might fit no one quite right. I.e that the tool could become too constricting. You mentioned Jony Ive, and my first thoughts went to all the things his team has done that are really outside the scope of the tools they had at hand already: E.g. new production processes, new materials, etc., even though they already had a perfectly good production line for their existing products. If I made puns, I’d say something about “breaking the mold”. Anyway, I’m just concerned that if the “dream app for web design” already existed, this whole discussion would be about its shortcomings, because the medium can be more flexible than the tool, and (as with software) you’re never solving the same problems.
I know that’s pretty pessimistic, and I hope I’m wrong. Personally, I’d love to see an app with the features you listed. I just hope it isn’t destroyed by nay-sayers like me :)
Posted at 03:27 PM on July 28, 2010
@daniel,
it is a great point about the fact that any tool will invite us to criticize it and dream of how it should be improved, which features should be missing. this is the nature of tools, i suppose, and partly how we got where we are with adobe’s “masterpieces”.
ultimately, we’ll never have the “perfect” app, and it can’t be one-size-fits-all, i think. but i believe with a good team building it, led by an opinionated product manager who is able to say no, it can be done well. if anything has been shown in recent years, it’s that good software is opinionated, and doesn’t try to please everyone. at least it works that way in my mind.
what i think would be ideal in the long run is several apps along these lines, experimenting with different approaches and paradigms. i think there’s a big enough market of screen design professionals to support such a thing.
we can dream.
Posted at 07:02 AM on July 29, 2010
I’m in search of the “WEEKEND WARRIOR MODE” ha ha.
In the early nineties, 20 years ago, I had my own email and web servers in my office with an ISDN digital connection. Yeah, I go way back, and my computer hardware/software design experience goes back 20 years before that. But I’m NOT a web developer. Stuff I don’t need to remember gets flushed to make room for new stuff. We all know how that works.
Fast forward to now. I’m developing an iPad application. And this is very interesting…
If you want to have a page that contains styled text in an iPad/iPhone app, you know, bold, italic, color, various typefaces and font sizes, you must use a “webview” object—a web page. Really? Yes, really.
Now once again I have to fire up Dreamweaver to create content and struggle with remembering how to do ridiculously simple things, and this feels so backward and absurdly unnecessary for this day and age, struggling with the web’s way of doing simple things that we can all do in our sleep with a common word processor that’s been around for almost 30 years.
Why is this happening!!!??? Well, it is, and that’s for another discussion.
With respect to this discussion, what I am putting my vote out for here is for web design tools that have a “weekend warrior” mode, so I can go in and do common tasks without having to switch back and forth between the layout and code views, and try to guess which feature I need to employ to do something mindlessly simple.
And if there ARE existing tools that help me do this, why is a connected person like me unaware of them?
And everyone, please keep in mind that when you work in a space on a daily basis, it gets hard to see what it’s like for a person who doesn’t.
Food for thought. And thanks for listening!
Mark
Posted at 07:50 AM on July 29, 2010
This is what i am talking about “WEEKEND WARRIOR MODE”. Brilliant.
Posted at 09:04 AM on July 29, 2010
So Object C on the server side? How about the following?
http://www.bombaxtic.com/
http://code.google.com/p/frothkit/
http://www.slideshare.net/JulioBarros/web-services-with-objectivec-presentation
http://wiki.gnustep.org/index.php/GNUstepWeb
Posted at 09:55 AM on July 29, 2010
@river,
I assume you’re quoting 37signals’ doctrine when you say “opinionated software”, right? I agree completely by the way; it’s not a criticism. Funny thing is that my idea of a “pipeline app” rather than a full design app was actually based on some 37signals’ philosophy too. Initially it came from not wanting Photoshop burdened with too many web-design-specific features (like others have wished for) like pseudo-interactive form fields etc., because that would detract from Photoshop’s (already fuzzy) focus as an image application. Also, it was the idea of doing less to make it work. Building a new web design app from the ground up would be quite an undertaking, and extending Photohop would be too. So I figured why not leave designers and coders, and Photoshop and web design/coding IDEs and text editors alone for now, and “just” make something to facilitate the design-to-code aspect. No code generation in the app, and no image editing either: Just a .psd parser with some information tools. The idea of having it be a rendering preview app as well is neat but not necessary at all (that’s what browsers are for after all). The idea is in some sense to not revolutionize anything :)
Posted at 09:56 AM on July 29, 2010
Last sentence sounds like CSSEdit to me.
Posted at 01:35 AM on August 01, 2010
Post a Comment