I tried a new web designer for one of my projects. After many tries he build a really nice design for my webpage and sent me the files. Now I wondered a much, because he only slice it in Photoshop - 20 images (very very bad sliced, e.g. borders with content in one image) and all complete 1 table structure HTML file.
When I asked him to do it in CSS, he said he can't, he doesn't know how, he is only a designer. His argument was: In his 4,5 year experience nobody asked for a sliced design, all customers would only have the PSD file and slice and create the HTML on their own.
And - he added - table structures are completly normal in web design.
So, my question: Am I old or is he?
Until now, I have ever build a webpage with DIV and CSS, never used table until you really needed a table structured information to show. That's what I learn.
Please tell me your opinion and how to handle with the actual situation.
His argument was: In his 4,5 year
experience nobody asked for a sliced
design, all customers would only have
the PSD file and slice and create the
HTML on their own.
This I find a valid argument. The creation of a design is one task; the creation a the HTML structure out of the design a entirely different one, and not being able to create the HTML does not make you any less of a designer.
And - he added - table structures are
completly normal in web design.
This was a valid argument in 1999, but is not any more.
If the main job he gets paid for is to design, and he had to create the HTML because you pressured him or because of time constraints or whatever, I'd say cut your losses, pay him, forget about it and have a CSS layout done elsewhere.
If he actually offered to create HTML for you, for money, and delivered a sliced table layout, I'd say that is not good work by the standards of 2009. Personally, I would not accept that if I were the client, and force him to do it again or refund the money.
sounds like a graphic designer, not a web designer
always be specific about the format of deliverables
Tables are very bad and old practice for design. You are correct to use css and divs. A "web designer" should be versed in css in order to produce their designs.
I would look for a different designer.
I'd like to add that in my experience (and this is hardly a rule, I'm sure), Web designers who are not able to code a layout into CSS/XHTML lack a certain understanding of the way Web pages often need to expand and contract based on content. This is especially true when designing for a CMS type system, or for a site that may require variable text sizes. The lack of understanding in these areas leads to issues with the way designs are put together on a fundamental level, and I have often found myself with a design that doesn't "work" in the end.
If he is a real web designer he should know CSS.
In answer to your question - yes, a table based layout is outdated and you need/want a css based one.
However, it sounds like the person you hired is generally just a web designer (Does visual design and layout) as opposed to a web developer (does the coding part of a website).
Many/most people who call themselves web designers do both of these jobs, and he should have explained to you before you hired him if he was only going to do the designing part, however, it does seem that he is a designer, not a developer, which is why his code skills are not so brilliant.
Consider hiring a separate web developer to create the website from the PSD file that your designer gives you.
It seems that your designer is a draftsman, but he can't create HTML layouts. Tables are only for tabular content and will put big restrictions to your layout. My opinion is that you should regard him as somebody that can draw, but don't ask him to do anything else, because he will mess up everything.
Tables functionally will work, and even validate, but they are a terrible practice for layout.
The designer admittedly has little knowledge of HTML & CSS. Perhaps his clients typically use a PSD to XHTML service for code, or something similar. I have not used one of these services personally, but you may want to look into that if you need a quick turnaround, but lack CSS knowledge.
If you're not comfortable turning the PSD file into XHTML, there are a variety of services that can do it for you for a few hundred dollars such as w3-markup.com.
Like most people here, I would concur that tables are not the mainstay of 2009 web layout and I can say that I NEVER used a table for layout - heck I couldn't if I tried. To answer your question - He is old.
Related
To convert from a good design (PSD files) to a good looking web site, it seems an effective approach is to use a PSD to HTML service.
For a Django site (which mine is), you typically need a bunch of templates to dynamically define many parts of the web pages.
It seems to me that converting PSD to HTML is a different skill to coding up Django templates, which are closely linked to the rest of the Django application. And while there may be developers who are very skilled in both skills, the number is probably small. But there are many quality PSD to HTML services, and a reasonable number of Django contract developers.
My question: For best results, should I split the tasks, and get the PSD to HTML done first, and then pass the HTML files to the Django developer?
Or is that likely to be a waste of time & money? Should I just pass the PSD files to the Django developer and hope he/she has the necessary HTML/CSS skills?
(ps. Have looked thru Django & Django-templates + HTML. Question not found.)
Honestly - get someone to do it manually. Those automatic psd to html generators either works based on tables (create aLOT of code and alot of hard to read code) or based on divs, which means ALOT of absolutely positioned elements. Thats what my experience tells anyway. Neither of those cases really produces quality, fluid, reusable code.
You need someone who does not necessarily know django (cause backend framework is irrelevenat to psd to html/css skills), but rather someone who is (very) good with html(5) and css(3).
Also - converting PSD to HTML/CSS is not a simple task, unless your PSD design features all necessary elements. I mean all - like link in content area may be with one design, link in some other area usually has different design, do links in lists have different design compared to links in (other) content? Does your design feature all possible form elements design? Does your psd feature all necessary/possible elements in most areas? If yes, then converting your design to css/html is pretty easy task. If not, then you probably need to keep tab open and use your html wizards services any time you find out that design for element X is missing because your django form.as_ul or form.as_table prints out form in a way that your html guy did not think of.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
It's well-known among teachers that some people can program and some can't. They just don't have mindset for that. In a nut-shell, I want to ask if the same is true about web-design.
I have a friend who is a good designer in general and can produce reasonably good-looking sites with WYSIWYG editor like Dreamweaver. But, since we're starting a common project, I'd like someone who can 'get hands dirty': work with html and css code directly. For many reasons, I'm sure you understand.
Now I'm thinking to incite him to learn, but not sure what're the chances of success.
So, do you also need some 'programming abilities' to profess css and html, or it's just a matter of training for regular designer?
I would especially like to hear particular experience from web designers.
PS I intentionally leave out JavaScript, let's keep it simple
The best web designers I have worked with know a small amount of html but don't use it when they are designing the sites. They do their work in PhotoShop (a minority will use GIMP). The reality is that I would rather they concentrate on laying out eye catching websites instead of trying to code it and lay the site out on the fly.
A web designer is absolutely not the same person as a front end web developer. That person has a skillset aimed towards converting the designers work into a set of working html/css templates.
Let me be clear that I am not saying that there is no cross-over between the two skillsets, but rather that very few people will be excellent at both design and development. If you are willing to settle for less than stellar results, at least be sure you go into the project with your eyes open.
Not at all. HTML is not a programming language, it's a markup language.
It shouldn't take you long to figure it out; I did it when I was 12. I personally think you need to be a better, how do I put it... artist to design websites than a programmer.
Of course websites nowadays are a lot more interactive, and for that you'll need some sort of server scripting (PHP, ASP, etc) and Javascript - and these are real programming languages.
A web designer who can't hand code HTML/CSS is not a web designer. The lack of such skills shows more of an aptitude problem(wanting to improve one's self). the graphic designer + front end developer combo doesn't always work well, because chances are the developer doesn't have the eye for the details in the design, such as margin, line-height, text kerning etc etc. Also it's hard to convert the interactive elements as well.
edit: this topic has been debated within the web design community on and off for a while now. You may find some interesting links in the blog post I wrote regarding this issue.
you are much better to know how to code a website HTML / CSS / Javascript before you go saying your amazing with a WYSIWYG editor. Sure you can use software to create a nice looking site but when it comes down to it how do you solve cross browser issues? How do you add dynamic content (even without server side) a WYSIWYG editor is just like designing a website in powerpoint or word but a lot more smarts. Though without the backing knowledge you are not going to go far.
As for learning plain HTML / CSS is fairly simple its an easy markup to get the understanding of. But then with that comes more, learning how to SEO plain HTML for example. There is always more to a site than HTML / CSS for it to be successfull.
This seems like a life question; I suspect it is true about almost anything. I think it can be hard to guage someone's aptitude for programming without seeing them actually try to program for awhile, however. Many people need to struggle with it for awhile before an "AHA!" moment is reached.
Nevertheless, I don't think design skills and abaility to work with CSS and HTML necessarily correlate to an aptitude for programming, per se. Of course, the two are not mutually exclusive,
It is not important for the designer to be able to program/markup/code in HTML or CSS. However, it is important for the designer to be aware of the current constraints imposed by HTML/CSS. With things becoming more dynamic, it is also important for the designer to understand how things are going to interact with each other. For example, you cannot become a real architect, without being aware of the constraints imposed by civil engineering.
But that's it. It is not important for a good designer to even know Dreamweaver or Photoshop or some other software :)
I am a university teacher, and I have also written both computer programs and HTML. Although I teach math, I understand the point about teaching computer programming. Although it might seem like there is no gray area between being able to program and not, I would say that writing in a markup language is one. You shouldn't divide the world into "cans" and "can'ts" with a question like this.
If he's a generally bright guy, yes you should encourage him to learn HTML and CSS. I wouldn't propagandize it as the thing that real men do or the greatest thing since sliced bread. Rather my argument would be to have a more complete perspective of what, after all, he's already been doing. Just as a racecar driver shouldn't necessarily need to pick up a wrench, but knowing what to do with one is useful for a deeper understanding. If you offer your friend a positive sell, the worst that can happen is that he'll say no and not take your advice. And who knows, he might even like it.
A lot of people either can't program or just wouldn't enjoy it, but don't mind writing in markup all that much. Most research mathematicians these days write their papers directly in a markup language, TeX/LaTeX, that in some ways looks a lot like HTML. Some mathematicians also like to write computer programs, but most of them don't. If they did like it, there is a good chance that they would have ended up in Silicon Valley. In fact in my profession, the whole question of can or can't write markup, or can or can't write programs, is stale. We're long used to a continuous range of abilities.
In my opinion, you can't have enough knowledge about this sort of stuff when doing any type of computer design or software implementation.
The more you know about the underlying technology, the better you will be at working with the high-level frameworks and constraints you live in.
Even if you work only in Photoshop in order to design a website, having the knowledge about what works and what will be more difficult in HTML/CSS/Whatever will give you an edge when designing that website over someone who doesn't know those details.
Of course, with knowledge comes constraints, which might be bad in and of themselves. Some of the best new technologies out there was built by people who didn't know that almost everyone else thought that what they tried to do was impossible.
But I still hold that more knowledge = Good Thing™
Web site creation especially a commercial website involves a LOT of different skill sets.
Back-end requires:
System Administration, Database Administration,
Web Applications development (anytime a website becomes interactive) requires server side programming skills and knowing various tools like (PHP, Java, ASP, Perl, C, C#, pick-flavour-of-the-month-server-side-language) and client side programming requires knowledge of browser behaviours mark-up languages and browser-side layout systems (HTML, javascript, CSS...)
Web Design requires artistic visual skills and related tools (Graphics programs)
Web Content requires language skills (Knowing how to proof read, translate, etc.).
Site Optimization requires knowledge of how to make sites appeal to various readers and audiences (both human and robotic)
A professional website involves several folks working in-tandem to bring all of the above together in various quantities.
If you are going to pursue something as a career, you need to know a bit about all aspects of that space and then follow in on what really excites you. So if someone is good at creating visually appealing content they should simply plan the content, and collaborate with someone to "program" their vision into the site.
Learning tools, and knowing about various components, is good as it tells you the boundaries and the playing field scope, but you don't need to know all of it to achieve professional competence in one specialization.
I'm learning web dev and I am already stucked at some point..
How do I convert a PSD template to a html/css website ?
I've cropped all part of the image and saved them in .gif separately, but then ? Do I have to manually place them in a dreamweaver empty template ? I thought there was an automated way to do so..
Also, I've tried "Save for web and devices.." but when saving, it creates a .html file and a single image which contains every element ?! I expected several images so that I could rearrange them in dreamweaver.
While certain applications advertise/provide automation of the "conversion" process from composite graphic to web layout you want to avoid using those features. They will cause you more trouble than they are worth. Especially if you are going to use CSS for layout (which I strongly encourage). Thats not to say those features dont have some limited valid usages (more on this in point 2) it just that they arent going to magically generate your site from a graphic.
In order to use "Save for Web..." you need to use the Slice tool to slice down the image into the different images you need for layout. Then when you do save for web and deices with html it will export the html/css and the images. Again this isnt magic and chances are youre going to have to completely redo most of what its done for you - making it useless for anything more than slicing a certain area of the layout (say a single menu).
There isnt a fully automated way to do this, generally speaking because depending on what you need the layout to do you have to go about laying things out in different ways and while its theoretcially possible to account for all the possible potential requirements in a nice little export GUI its not really feasible.
The bottom line is to do this you have to learn HTML/CSS. And the more you learn the more you will hate Dreamweaver (at least in "layout view"). Garaunteed.
Yea, web design doesn't work by magic. The proper way to do is to manually write the actual code that positions the elements, not just smack them in place in Dreamweaver. There's plenty of good tutorials out there, check these out for example:
http://net.tutsplus.com/videos/screencasts/how-to-convert-a-psd-to-xhtml/
http://www.devwebpro.com/creating-css-layouts-the-best-tutorials-on-converting-psd-to-xhtml/
Welcome to reality.
You'll have to slice and dice yourself (well, slice and dice the image yourself, but don't slice yourself no matter how much you want to), and then place each individual part in your HTML or template.
There are a number of automated services that convert PSDs for you:
http://converxy.com
http://psd2htmlconverter.com/en/
http://www.psdtoweb.de/
http://csshat.com/
However, you might also want to consider a service-based approach as well. There is a thriving community of professional slicers out there (just google "psd to html" and you'll see what I mean).
You might also try to redesign from a program or framework such as:
http://html.adobe.com/edge/reflow/
https://webflow.com/
http://www.ekomobi.com/en/home.html
http://macaw.co/
http://foundation.zurb.com/
http://getbootstrap.com/
http://www.awwwards.com/what-are-frameworks-22-best-responsive-css-frameworks-for-web-design.html
It really depends on your budget, your timelines and your skillset.
I'm a big proponent of understanding something really well before trying to automate it. So, like the other posters have said, slicing by scratch (handcoding) is very valuable, especially if you don't already understand it well. However, you might just not care to invest the time needed to achieve a good understanding of the subject. And, that's perfectly okay too.
I think that ad the end of the day, there is no "correct" solution. Different people have different requirements which will change the choice.
This may help you, it walks you through the process.
I read somewhere that when creating a HTML email, you should use the table-based layout. You should not care about creating tableless css based layout. Is that true?
I have to create a newsletter layout for my company, but I dont feel confortable writing 3 nested tables.
If you want your HTML-email to look good in most email clients, you should write your HTML as it still was 1999 :)
I'd highly recommend paying a visit to the Email Standards Project website. It lists almost every major email client (both standalone and web-based) on the market and outlines how much HTML support is built into each one.
Also check out Campaign Monitor's email design guidelines for some practical guides for proper HTML email building -- including, sadly yes, "use tables."
This is probably more based on the reality of email client rendering (which is terrible) than anything else. Technically it's almost certainly wrong, but pragmatically it might be the best advice. Truppo touches on this.
I would love a world where no one expected HTML to be used where plain text would do, but that is not the situation. If your job is to come up with HTML that will not embarrass you when your subscribers try to view it in their favorite email clients (applications or web based email), it is hard to stick with semantic markup and CSS.
Take what I am saying with a grain of salt because I have only done this as a learning exercise and not professionally. Based on an article I had bookmarked and further links I found in that article, the following pages seem to have a good discussion of the real issues involved in sending HTML email.
http://www.sitepoint.com/article/code-html-email-newsletters/
http://www.sitepoint.com/article/principles-beautiful-html-email/
http://www.sitepoint.com/article/designers-guide-html-email/
Given the issues involved, using tables for layout makes practical sense.
There's certainly no standard that mandates it, and in fact, best practices dictate that tables should not be used for layout (except in the case of laying out tabular data).
There is an argument to be made for using tables in presentation, as there's no guarantee the plethora of desktop and web-based email clients will render CSS-based presentation properly... However, I wouldn't say that's an argument in-and-of itself.
I won't advise you to do it, but you had probably hear this because a lot of email reader supports only a few html and css.
They often don't bundle a full html/css parser, and in the past table was much used to do layouts..
You may want to look at this, although this is specifically about the Oulook html/css subset support described:
http://msdn.microsoft.com/en-us/library/aa338201.aspx
The reason tables are used is two-fold:
HTML e-mail can be rendered in a vast array of clients with widely differing abilities. It's like trying to design a website for every browser, then multiply it by 10.
Quite a few web e-mail clients play havoc with CSS layout.
I found outlook having problem with div based layouts.
We've been doing some tests with customers on how newsletters look on their computer and found that a majority is using a layout in Outlook or in Mail that shows a width of only about 45 characters. They don't bother to double-click to open the email in a new window or scroll around.
The emails with some content other than a logo and text that appeared somewhat better were the ones with only one big GIF...
+1 on Campaign Monitor's advice. I've also seen a lot of great content from Emma. In my experience, the simpler you can make an email newsletter template, the better. This is doubly-true in a world where an increasing percentage of users are reading your message on a mobile device with a small screen.
In the past it was common to use tables for page layout, and many people who create pages are still more comfortable doing it this way.
As James says, best practice is to use CSS positioning facilities for page layout except when it actually is tabular data; but personally I often find it hard to get the effects I want with CSS.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have a development process question.
Background: I work for a modest sized website where, historically, the designers created mockups/screenshots of what they wanted pages and components to look like, and the engineering team (myself included) turned them into html/css.
This works relatively well from a code cleanliness perspective, and helps significantly when it comes to writing javascript. It has fails, however, in helping to maintain consistency from one page/component to another. On one page, a header font might be 12px and on another 11px, largely because its a complicated site with lots to keep track of (and we've cycled through 4 designers.) We have only a few truly universal styles, and they only get used when the engineers recognizes the style - not when the designer tells them to.
Our most recent designer is a relatively capable HTML/CSS coder. We thought we might have him create mockups in HTML/CSS and hand us off the code for quick integration. Our hope was that the designer would be better at being consistent in his style and that it might save us some development time up front.
What we've discovered is that our designer is not quite as good as CSS as we had hoped and that his code is often slightly bloated and incompatible with what we need to do. Also, his style of coding is fundamentally different from the rest of the engineering team and isn't jiving terribly well with our established coding practices.
Question: How do you do the hand off from design to engineering? I know I've heard of companies that let their design team do all of the template coding, but I'm curious how that works. Does the design team actually incorporate members of the engineering team in those scenarios?
As we're structured right now, there's not a chance in hell we'd let our designer write the final templates and check them into SVN, even if he was a proficient HTML wiz. There's too much in the templates that requires knowledge of our codebase and of potential performance issues.
How do we get this process working? Is it a pipe dream?
Specifically - personally - since I come from a web-dev, small-shop background I do the CSS work and slicing the PSD (typically) myself. But then I like to think I'm well rounded like that :)
Generally, the best experience I've had of this was a largish company with very defined groups of developers including the design team who produced the gfx, the apps team who did the vast bulk of server-side coding and app architecture, and the UE (user experience) team who sewed the two together, producing XSLT/JSP/HTML markup in general, and the CSS and JS for the client-side.
There was a very structured process of:
userstory ->
"wireframe" (documents) ->
design (PSD) ->
"flat" markup (DHTML only) ->
integrated markup (with web-app)
Where "wireframe" would be close to a spec for UE, produced with UML or maybe visio. I have heard the term applied to step 4 which I think fits better, but this is what it was referred to as there.
Whilst this works well for the question at hand, I found it had other problems built in. It was very hard to work across teams, and because of the timescales the design team rarely involved UE in decision making (which put UE in some awkward positions), the apps team and design could be working at cross-purposes, and there wasn't a lot of scope to learn in these boxed in teams.
My suspicion (and I think ideal scenario) is that the developers on a project would each be capable of working with, say, 80% of the technology involved (be it CSS, SQL, whatever) to spread the decision control and risk, but each domain would have one (more?) "czar" who could act as authority and oversight within the domain. Actually producing those designs is to my mind a strange and magical skill in it's own right so I see no real overlap with developers there, but I think a pool of artists and project teams of cross-skilled programmers would be very powerful.
Apols for the long-windedness. I could go on at considerable length on this, I've spent a lot of time thinking about it.
btw, it seems like you could do with some serious web-devs there, (no offence). Having problems to "maintain consistency from one page/component to another" screams failure to grok CSS
In my experience, unless you limit your design severely, you need real coding skills to build a web page with interaction. Let me elaborate some. If you have built your pages very modular (think of GUI toolkit widgets) you can give your designer a handful of them, he can build the basic structure like playing toy blocks with a nice finishing paint.
Often, modularization alone is not enough for desired interactivity. So, some blocks needs their interactions to be designed carefully as well (like animation, fluid layout to accommodate indeterminate content, customized behaviour via extra javascript, caching to eliminate redundant requests and speeding up things) or ability to accommodate minor presentation variations, which brings us to the realm of programming, where you calculate dimensions, enable/disable parts, keep track of time, preload stuff, invalidate preloaded stuff and so on.
Enter HTML/CSS/JS. They are more of a product of evolution than intelligent design. You cannot always declare your intent and be done with it. You need attributes declared in your html, stupid hacks in CSS combined with extra markup, ridiculous amounts of js to smooth rough edges, duplicate rendering code on the server side. These tool were never meant to build applications.
I don't think one can achieve a complete separation of design and application development in these tools at hand. The effort required is too high to justify the marginal returns.
If you end up heavily modifying designer's code (which is othen the case if he is not one of the developers also), there is no point in making him suffer trying to express his intent using the wrong tools, nor developers breaking the design while modifying it and consequently fixing it. I don't even mention user experience.
In my opinion, no small internet businesses who want to ship a product in a reasonable time should spend their scarce resources to go against the grain. Let people do what they do best in collaboration if necessary. If you can't divide design process at an arbitrary satisfying point, you may as well not bother to separate at all. Pipelining works well for machines whose goal is determined to the last detail and not changing. I can't say the same for humans building and designing things be it software or hardware.
Where I work it's basically the same. Designers create mock-ups and specifications of the UI design, right down to the pixel, and the developer creates HTML/CSS/code out of that.
The reason I say code, is that we use UI frameworks (namely, GWT), and as much as we would want to, code and CSS styles are still very coupled. I do not believe there exists one UI framework in which code can be completely decoupled from the UI design.
So I guess for now it's still entirely the developers job. Though I would like to hear about organization which are able to hand off some of the work to designers.
The problem with handoffs is that the idea and implementation of one group is not going to match the abilities and implementation of the next group. Just by their nature handoffs are going to be wrought with problems. So what is an alternative to the ubiquitous handoff scenario? I think that integrating the user experience (UX) into an agile and iterative development process makes sure that what is really important occurs:
The customer's needs are researched then validated.
Early and continuous collaborating between usability experts, designers and programmers.
The actual process works by having everyone collaborate with the customer up-front on their needs. Then the design is researched and prototyped in the iteration before coding begins. Thus when coding is occurring, the next set of designs are being worked on. Programmers should be looking forward at what designers are doing and the designers look back to be sure programmers are on target. Once a design is coded, it goes to the customer for acceptance, by that time the programmers are working on the next set of interfaces.
Jeff Patton did a podcast on Agile UX recently that goes into some of the implementation concepts and common problems.
There is a whole group on Yahoo dedicated to agile usability (which mostly involves interface design).
For the CSS inconsistencies... I'd just suggest making a style guide then trying to stick to it. Have someone be in charge of "design consistency" that way the can spank anyone inventing yet another way to display the user.
At my company, my ideal work flow doesn't work very often, but sometimes it does. I löve when this happens: The engineers write the webapp and output semantic html with only minimal CSS. then you have the designers do the CSS.
I like it when it goes this way, because:
It is easy for me to write semantic
HTML.
I am not very good at coming up
with a good design for my semantic
html.
It is entirely possible to do
the CSS without asking me questions.
The markup just speaks for itself.
However, this rarely works. Because:
The CSS has to be modified whenever the HTML changes and the designers' time is sparse.
Moreover, our designers don't enjoy styling my markup, and fighting for their time is not pleasant.
Our designers often want to change the markup. Mostly because they believe some layouts cannot be done without changing the markup or because they believe that it's the only way to make IE obey. They are technically not able to change the markup, though.
I have my doubts about many of their cases. Many times they claim IE incompatibility, I strongly doubt they really know IE that well. There are neat CSS hacks to make IE obey without resorting to
<br clear="all">
So, sadly, usually this ideal is a little off for me.
A separate designer - developer workflow is the best way to go. Designing a website and coding it are altogether different jobs. There are issues of cross browser compatability, CSS, XHTML, apart from coding standards to deal with.
You could also opt for outsourcing your HTML to a specialized PSD to HTML conversion expert like us (ButterflyHTML). It may work out cost effective in the long run