The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Separation of Content/Design - who has priority?

I recently became involved with a startup in which my primary responsbility is to do the scripting/backend database development of a ecommerce site.  We have hired an associate of one of our partners to do the graphic design.  This is my first experience in a "Team" environment; the previous sites I more or less did all the graphics and scripting myself.  All the html was script generated; programs such as Dreamweaver were not used. 

The graphic designer more or less developed the main page in Photoshop and then imported it into Dreamweaver.  Needless to say there is a lot of html code with tons of nested tables.  I then took this main page with all its graphics and styles and went from there.  Now this is a highly dynamic site with login, reservation system, etc.  So it entailed parsing his main html page into separate scripts which function differently based on the current state of the site and embed Fat urls for state management in all Posts and anchor tags. 

Problems arise if we want to change the overall appearance of the main Home Page.  The graphic designer says in his other team efforts he was able to provide a new HTML file and the scripters simply "plugged" it in.  Easy.  But for me it isn't this simple.  The site it toally script generted and doesn't use a base html file.  So it forces me go to each script and make necessary adjustments.  This has proved time consuming and difficult.

In some regards I feel like I am the author of a Novel and am forced to change the way I write my content based on how the illustrator is doing the front cover.  I know this is the classic separation of content/design.  And in this case I feel the designer's high reliance on Photoshop and Dreamweaver is making it difficult. 

I would like to hear anyone else's input on how they work in such an environment.
web Scripter.
Wednesday, January 16, 2008
You definitely don't want to be continually copying changes from the designer's HTML prototype into the actual system.  Either the designer works on the system directly (many designers aren't comfortable outside their chosen tools), or you need to fully separate system behavior from presentation so you can each work in your own area independently. How to do that depends on the technology, e.g. with ASP.NET you might look at what you can do with HttpModules.
Mike Stockdale Send private email
Wednesday, January 16, 2008
First of all, accept that you're not going to be able to get the designer to use different tools or to stop changing the appearance of the site. Focus on making it easier for you to apply the designer's changes. That means:

* Anything that generates HTML belongs in a separate presentation layer. You might have to edit code to change the HTML output, but you shouldn't have to go anywhere near your business logic.

* Separate out the common, repeating bits of HTML from the stuff that's different on every page. There are a variety of ways, depending on your platform: include files, super/sub templates, etc. If you're on ASP.NET, use Master Pages and look hard at the navigation controls. If you're still on 1.1, it's worth upgrading to 2.0 just to get Master Pages.

* Encourage the use of CSS wherever possible. This isn't something you can dictate to the designer, but if you can get buy-in it will make your life much easier. At a minimum, you should use CSS to style text. I can't overstate how much easier it is to change fonts in a styesheet vs. a million font tags wrapped around every bit of text in the system.
Wednesday, January 16, 2008
You've already recognized the problem - your content and design aren't separated. If there are ongoing design changes, that is going to be a huge issue. Nasty nested table layouts sure don't help, but that's just exacerbating the real problem. The HTML needs to come out of the code.

You should be able to slowly refactor things to use a templating system. I would approach it by first identifying chunks of code that return or output individual components (eg. this function handles the menu, this one handles a product.) For each of these, create a template that handles a discrete element. Eventually you'll have each element moved to a template and will have reduced days of error prone fussing with your scripts to hours of splitting up a template and replacing a few chunks with variables.

If these elements aren't already in their own functions, now is a good time to do that, too. If I'm guessing correctly about how the code is structured, this is just the first step on a long road to getting things properly separated, but it's a good starting point. (clcr mentioned business logic and presentation layer above. If you're not already doing that, you will definitely want to. I might leave that for step 2, though, after the templating.)

If you can convince the designer and management of the advantages of good CSS based markup, that will make your life easier, but it won't have as a dramatic an effect as getting the HTML of the code.

(To answer the question in your subject - neither of you have priority. The designer is there to create effective designs, and provide markup that's as easy to work with as possible. You are there to make the process of integrating these designs with site functionality as efficient as possible. Notice that these two areas should have very little overlap.)
dwayne Send private email
Wednesday, January 16, 2008
Perhaps you could surreptituously slip a book on Smarty into his cubicle.
Wednesday, January 16, 2008
Either designer works with your code, or his job stops once he hits 'save' in photoshop- him turning it into html seems like a waste of time here.

Saying that though, if you're having to change things in multiple places, then there are probably ways you can improve your design.
G Jones Send private email
Wednesday, January 16, 2008
Find out which of you is in charge, and act accordingly. If neither of you have any authority, then find the person who does and get some assistance with negotiating the conflict. It doesn't actually matter whether the artist or the coder has "priority" as long as both people are working with the same assumption. Either way, one of you has to adapt to the other.

If you're working at a startup and the people in charge understand the difference between your viewpoint and the artist's viewpoint, you'll be fine, decisions will be made, and you'll be able to get on with your job. If they don't understand then the entire business is doomed anyway so you chould leave before the funding dries up.

Thursday, January 17, 2008
> Either designer works with your code, or his job stops once he hits 'save' in photoshop- him turning it into html seems like a waste of time here.

Not necessarily. It depends on the relative HTML/CSS skills of the designer and programmer. A good web designer (as opposed to a graphic designer who can operate Dreamweaver) will be able to implement a design and iron out browser compatibility issues more quickly than your average programmer. On the other hand, there are a lot of people marketing themselves as web designers who don't know an angle bracket from their elbow.

Politics is also a factor. Making things work within the existing division of labor is always easier, because then you're not taking part of somebody's job away.
Thursday, January 17, 2008
If you want to take part of someone's job away, make it the part they hate and make sure they get to do more of the part they love without the stress of dealing with the crap. If you get a workflow that lets the artist concentrate on creating artwork, theymay be grateful that they don't have to deal with the "mucky" coding crap. Of course, that generally requires mutual respect, which can be a little tricky.

Sunday, January 20, 2008

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz