Former Designer here, turned Dev, and I used to piss and moan about Web Controls too. Honestly, its MUCH cheaper for a designer to adjust their practices than for a .NET Developer to delve into a custom impelmentation of a GridView because the designer INSISTED that each TD have a ‘rel’ tag (or whatever).

As Arseni Mourzenko very wisely pointed out, the decision to use Webforms is a company choice that limits some of the control over the HTML while granting some efficiencies in coding. Unless the company is willing to re-consider (which they should NOT do just to please the designers), then the designers need to accept this reality. Here’s a few things they can do:

1) Stop depending on ID’s for anything. Even though this felt wrong at first, I found that life was actually a lot easier when I styled everything with classes (and inheritance, of course). First of all, it equalized all my selector weights. In CSS inheritance, ID trumps CLASS. It was actually kinda nice to have everything be a child and/or class selector, and made figuring out the specificity order a little simpler. Same thing in the JS layer, it gave me ZERO pain to swap out my ID-based selectors for class-based ones.

2) Teach them what RadioButtonLists and CheckboxLists convert into, along with Label = span, Panel = div and the other non-obvious control-to-html stuff. The way .NET renders these to HTML was a little weirder than I expected, and it was much easier for me to create screens when I knew how the HTML would come out of those controls.

3) Have them do their designers IN ASPX DIRECTLY, not raw HTML (!important) . Teach the designers the basics of GridViews, ListViews, etc. Give them some code snippets to push an anonymous object collection into a Grid/ListView control. If they can learn CSS then they can learn to copy-paste this code in. They can use the free version of VS Web Express, which is quite good at CSS & JS work now. These dummy web projects will give the designers a chance to enter some controls, then View Source to see how they are rendered.

4) Explain how the FORM tag is used in .NET. Forgot about this one earlier, but another thing the designer has to get used to is that usually, a single FORM tag wraps the entire page. This alters the way form controls behave, and you can’t nest FORM tags without really weird side effects. Make sure the designers understand this or else their form HTML will be a nightmare to make into WebForms.

5) Stay away from Themes and Skin. Even though the .NET framework has these tools to help style controls across an application, they are clunky and weird to normal Web Designers, and I never found them worth my time. They seem like a nice tool to devs who aren’t well versed in CSS, but will only slow down the designers. Let the designers work in their natural environment (html & css files) and they will be happier and more productive.

6) Keep “prototype” projects in your site solutions. To make sure the developers always have a target to code against, have the designers create a fake web project in your real solution to keep their ASPX-only pages preserved and untouched by the real developers. This means the designers can look back to their prototypes in the same solution as the real project to check on how the developers did, and the devs can run the prototype at any time to make sure their work matches the designers’ intent.

Finally, resist any complaints to convert to MVC, unless you are ready to re-train your Devs. I love MVC personally, but if you’ve got a team with a ton of WebForms knowledge, don’t go throwing that away for no reason. If your applications are having ViewState problems, SEO problems, or accessibility issues, then absolutely give MVC a hard look. But it will take a LOT more time to train WebForms devs on MVC than it will to train Designers how to use Web Controls.

At the end of the day, there was NO DESIGN I CAME ACROSS, that I couldn’t personally make work in WebForms, even if I ended up swearing at that darn GridView for an hour before figuring it out.

Are there any tools or applications to provide the designers with the
rendered (html page) of the .aspx pages?

Forget Expression (I never liked it). Get them the free version of Visual Studio (Web Developer Express). It can hook into whatever source control solution you have, and it will let the designers run their ASPX pages and see the rendered HTML in a browser. The CSS and JS tooling is much better than it used to be, and there are some awesome tools baked into extentions like Web Essentials. 1-click transforming of CSS rules into all their vendor-specific deviations, color pickers and palettes right in the VS interface, 1-click embedding of images INTO css files, ‘LESS’ CSS transformations (you can ‘code’ in CSS), F12 ‘Navigate To’ on JavaScript, plus real intellisence, and way more. Its a treasure trove for designers now, FYI, and your designers might not know about it since earlier version of Visual Studio treated CSS/JS as second-class citizens.

There is a solution to your issues but it involves a design pattern change to MVP. This is an up-front investment of time that needs serious consideration before start.

Basically, issues that you are experiencing is not new. In short, you need to introduce a view abstraction through interface that identifies the data model that the view supports.

It is very comprehensive topic which makes sense to see pattern as a life example. You would find this example pretty informative for your case – Better Web Forms with the MVP Pattern.

Edit: If above suggestion is too expensive (in terms of time and resources) to follow, i would definitely advice to work with your designer more close. I do believe that communicating your issues within a team should greatly help to resolve impediments in your (designer’s and developer’s) work. This is a team work and good collaboration of issues to remove all obstacles to perform the work is the way to succeed in a project as a team! This is something that we do in our project.

ASP.NET is a framework, which abstracts the generated HTML code. This means that you can’t be asked to reproduce exactly a given HTML code in an ASP.NET application, unless you have enough budget to rewrite anything which is generated by ASP.NET controls.

It would be up to the stakeholders to decide: either you use ASP.NET controls with their strong points and disadvantages, or you switch to manual HTML (or to ASP.NET MVC), increasing the cost of the current project by thousands of dollars.

The inability to customize HTML in this context is a constraint like any other. Designers should consider this technical constraint in their job. The case is very similar to if the designer would tell you that a text should be displayed in the exact font with exact size: it’s a web support, not print, which means that the size of the text will vary.

As for the tools, I’m unaware of tools which will convert plain HTML into an ASP.NET template. How would it possibly guess that a specific table must be converted to a specific ASP.NET control?

At my last job, the devs would build the application and then would pass it to the designers so that they could make it look like a bunch of software programmers didn’t make it. 🙂

When we first started this process, there were a lot of back and forth between the devs and designers. They didn’t understand the pages that they were given. Heaven forbid if we were building a page dynamically! It was much the same as the situation you are describing here.

I sat down with each designer and taught them how to install the web application on their local box. I showed them how to run it and everything. I explained to how the asp controls were rendered on the screen. And then we opened it up in the browser and used firebug to see the link between the asp controls and what was rendered.

This helped them, a lot. Once they could see it and run it on their boxes and use their design tools to tweak and play with styles, it made their lives easier.

After I did this, I had a meeting with the developers and let them know that they should be using the CssClass tag and making sure that styles were being defined. And anything that was being put on the screen dynamically need to have a css class attached to it b/c the designers wouldn’t be able to add it.

It was a process. It took some time for both sides to get use to the arrangement. But it opened the lines of communication. Instead of complaining about the controls used, the designers were able to request styles be added to various elements.

So my suggestion would be to sit down with the designers and show them how the page renders. Use firebug to dissect the page and go through how the page if formed.

Here is some useful approaches I have taken in the past with designers when they have to work on an ASP.NET WebForms project that is being developed.

1. Deploy Locally: Developers provide an intermediate version of the project deployed
   locally. This saves time to both. The designer requests an .aspx but
   interacts with the rendered HTML instead of with the server code.
   This approach abstracts the server code from the designer. He
   doesn’t need to know how the HTML is generated or how the javscript
   and css files are delivered to the client. This of course assumes
   that the designers are skilled with browser debuggers/DOM inspector.
   The designer can apply all of his css changes inside the browser
   and afterwards apply them to the css files.
2. Provide Models: In order to make is more sensible for the designers to work with
   HTML, provide them with a model of the HTML rendered by the server
   control. They can tweak that HTML to the point where they like it
   and propose the changes to be applied in the server-side
   implementation. This needs to be done early and often, because you
   don’t want to end-up with an HTML structure which the client-side
   implementation relies on and then for the designer to propose
   changes on that structure.

The designers should in general have as little touch points with the server side code as possible, so abstract it away from them as much as you can.

As a hybrid developer, myself (having done a lot of work in both back-end and front-end roles, often together), I have a long-standing dislike of the ASP.NET WebForms model as well… while its initial design impetus was to provide easy, drag-and-drop design tools to democratize web development (the same way that Visual Basic made app-programming accessible to the non-CS-major), the methods it used to try to force state on a stateless environment (the web) are ham-handed and forced (oh ViewState, how I loathe thee!).

They also violate some of the central principles of markup development and styling, just by the very fact that, by default, ASP.NET takes over the ID attribute, forcing CSS designers to use classes the same way that IDs were meant to be used, layering elements in deep stacks of divs and nested tags that can make styling the controls a nightmare in all but the most simplistic systems.

Given these things, your path is not an easy one, as I assume a rewrite for MVC would be cost-or-time-prohibitive.

Is there any way to provide the designer an environment in which to run the web application, so they can see their CSS changes in real-time? When I’m doing design work in ASP.NET WebForms, I find it invaluable to be able to fire up the web app on my own machine, make tweaks to the CSS, and run it locally to see how that affects the app.

One option might be to set up a virtual machine tailored specifically to ASP.NET development that the designer can run from their workstation, so they don’t have to mix their two toolsets, and if they happen to screw something up in the dev-space, it can always be reloaded from a functioning image.

Yes, this means that the designer will have to learn how to press F5 to run the app. (Or just give them access to FTP to the directories where the CSS, JS and images are, even, on a test environment!) It also means that they’ll see a lot of back-end code, though if you tell them to just ignore your .cs or .vb files, that will go a long way to keeping them from panicking… Of course, that means that you have to be sure you’re not doing things like setting styles from your codebehind files… (but you wouldn’t do that, would you, as that ties data and view too closely, right?).

If your site is structured well, with distinct CSS and JS files, and not a lot of inline styling forced on the markup, it’s possible they can get most of their job done by just having them avoid the <% %> areas. On the other hand, it might also give the designer a little more appreciation for what you have to go through, when trying to translate their static HTML/CSS into something that works for a dynamic app.

You need to make them talk together, understand each others needs and preferences. It’s a “problem” that cannot be solved by software and tools. Don’t try to please both parties, that will never work. They need to compromise – it’s like a marriage.

One way is to arrange f.ex. workshops where each parties get the chance to explain why it is so that they prefer what they prefer. Good communication is always a key in situations like this. Gathering such as these can be seen as investments.

Or simply said, the problem is organization-oriented, not technical and that is where you need to provide solution.

The other option is to raise the pay and tell them to shut up (usually a short-term solution…).