Design Overhaul

Rest assured that the system as a whole is much more than you see.

For instance, for security reasons, it was necessary to build an HTML parser package that, not only parses and validates HTML, but also CSS, DTD, etc.. On top of that, security analysis classes were developed to prevent the use of Javascript in HTML and CSS templates.

phpclasses.org/secure-html-filter

That was a vital component to prevent that authors inject Javascript that could be used to perform cross-site scripting attacks and other types of Javascript based security exploits.

Just the base version of those classes took more than two months, without counting fixes that happened later, even until just a few days ago.

Another component that took a lot of time was the HTML editor. It is a basic HTML content editor that has some special features that let you insert and edit special templates which are parts of the design themes HTML template marks.

meta-language.local/forms-examples. ...

This editor lets the designers see a live preview of the design theme pages. It also lets the designers switch layout options of the template marks with just a few clicks, like switching the navigation bars orientation from horizontal to vertical, like many designers wished.

That editor component also took more than two months just to develop the base version.

By the way, those components are already open source, so anybody can use them in their projects at will.

These are just a couple of examples to show that the design system is much more than just a file editor.

Still, these components were not developed just with the design system in mind. They will be reused throughout the site. For instance the HTML editor and the secure HTML parser will be used to enhance the blog system, as well this comment forum system that you are seeing, letting the users submit richer articles.

So, the conclusion is that it was well worth the effort, despite much of the work was not yet fully exploited.


The design preview system is good for both designers and users that will vote on the proposals. That is the way that they can see how the design looks in different pages.

Just previewing the default empty page would not be enough. There are some icons and CSS styles that designers could edit or replace, which could only be seen in certain types of pages.

Maybe you did not try all types of pages. But some users tried and reported issues to the designers that other users also read. That feedback helped users make their minds.


Rest assured that this system will be used again in other redesigns because it all boils down to different sets of HTML and CSS templates and icons.

The body of each type of page that may be subject of redesign is also made of that. It is just a different set of template marks that represent different types of page blocks.

The site just has too many type of pages to be redesigned. That is why 5 years estimate is not unrealistic. So lets just divide and conquer.

Of course with newer technologies becoming usable, the site can evolve regardless of the site. For instance, as IE 6 becomes obsolete, perhaps next edition of the contest will drop GIF icons for good. IE 6 is the only browser in use that does not handle PNG transparency right.

Anyway, besides the fact that the design system is made of components that will be reused for other site purposes, your wondering of whether I am planning mass productions of Rome would lead me to another subject.

Unfortunately I will not comment right now. There is something along those lines coming up but I prefer to only talk about it in a few months when it is ready to launch.


As for the sitemap, you may not use it, but other people use it. Other than that is good for SEO as well. In any case, the point is that the information about the site that you asked is mostly there.

This site is already so large that you could not fit all types of pages in a single site navigation bar.

There are many features that people don't know because it is a good idea to flood users with detailed information about the site.

Alternatively, the site uses those "Site tip of the day" boxes that you may have see in the login welcome page and the site newsletters. Those tips suggest some interesting features to the users. That is a less aggressive way to advertise the site features to the users progressively.

phpclasses.org/tips.html

Other features like the site jobs section are advertised more aggressively in site banners because they generate revenue for the site. That does not mean that you will necessarily notice them. Self-advertising just increases the chances that you realize about those features.

By the way, the site never had a games section. Maybe you are thinking of some other site.


I do not agree that the social bookmarking links should go to the bottom of the page. That is vital for the site to gain more traffic from word of mouth passed by e-mail, Twitter, Delicious, etc..

The same goes for other changes you are suggesting. Things have a reason for being placed where they are. That was enforced already in this contest because it is important for the site.

If I made those changes you are suggesting now, it would not take long before somebody started complaining that something was removed, when in fact they just changed the place.

It already happened when the "Contribute" link was renamed. Previously it was named something else. Just because I changed to "Contribute", I got an angry message from an author that wanted to contribute but the site was no longer allowing it.

This is another reason why the site cannot be subject to many substantial changes at once. It will only upset users that are used to find things in certain places.

> As for the sitemap, you may not use it, but other people use it. Other than that is good for SEO as well. In any case, the point is that the information about the site that you asked is mostly there.

My intention was not to say that sitemaps aren't useful. I was just stating that relying on them for navigation to other sections isn't usually a good thing.

> On top of that, security analysis classes were developed to prevent the use of Javascript in HTML and CSS templates.

The use of an HTML parser to enforce security and prevent Javascript is a whole separate topic. I applaud you for thinking about security - it's something that a lot of people don't do these days and I'm constantly writing about it. Just a note - you can solve a lot of problems by simply not allowing users to input HTML at all and using a series of codes like bbCode and such to give users the ability to have "rich" comments. Keep in mind that forum applications have been dealing with this issue for years and having "pseudo" HTML has worked out well for them. Having myself recently designed, planned, and worked on a multimillion dollar application that centered around a web-based HTML editor, it's a LOT of trouble in the end. Unfortunately, the application's PURPOSE was to allow people to build web pages, so we didn't have the option of using bbCode or something similar. But allowing users to save and display HTML is a GIANT can of worms.

Even something like CKEditor, which has been around since the browsers first introduced their rich editor components, has had a lot of trouble with compatibility among different browsers, platforms, and users. Unless there's an extreme NEED to allow users to post HTML instead of bbCode (or whatever), you may want to consider using the latter option. Beyond simple compatibility problems, there are always new forms of XSS attacks coming out, which may make your system temporarily vulnerable until you patch it. Please trust me - that road is a lot more work than you might think, and I have yet to see any system that GREATLY benefited from going into rich-text comments. Sure, some people find it useful to bold certain items, but we are all having a very effective discussion without use of any rich text right now. (Plus, usually there's a lot of Javascript overhead that goes along with rich text editing, which makes the site feel sluggish.)

> The site just has too many type of pages to be redesigned. That is why 5 years estimate is not unrealistic. So lets just divide and conquer.

Have you thought about separating the site into different, smaller sites that each focus on their own major topic (e.g. jobs.phpclasses.org, hosting.phpclasses.org, etc, with the main site being www)? That might be a good way to divide and conquer, and also help with SEO.

One of the projects I work on does just this. There is a "common" folder that contains classes that are shared between the major modules, but each site can be customized to its own needs.

> Rest assured that this system will be used again in other redesigns because it all boils down to different sets of HTML and CSS templates and icons.

At least right now. Five years ago, most people didn't worry about XSS attacks - they worried about SQL injection and that was it. Most browsers didn't prevent an iframe from talking to a parent on a different domain. We've come a long ways in five years, and in the next 5 years, we'll probably see "Web 3.0" and "Web 4.0" and the system might not be capable of handling the technologies and security problems that go along with them.

Regarding the things that the system can do, I did try all of the options eventually. But I suppose I still don't quite see the advantage of it over a more free-form design contest. Good design evolves in stages - you don't expect the designers to give you the final product. That's why designers usually submit graphic-only comps first.

So on round 1, people can quickly view and vote on all designs with just a glance at the comps. Round 2 is designed to get a more detailed version of what people liked in round 1. By round 2, you're dealing with a lot less number of entries and HTML templates can easily be checked for security issues (although if you simply host the design previews on their own separate domain or subdomain, then you can use an iframe to view them without worrying about Javascript attacks affecting the main site).

I guess what I'm trying to say is that the system seems "cool" but it's not that much more effective than the normal design / bid process, and you had at least a few people simply not participate at all due to the tight restrictions, which you could reasonably say makes the system less effective. Yes, it may be a unique system, but is it working better than the way that everyone else is doing it? You said that a lot of its functionality hadn't been exploited yet, but isn't that technically the measure of a product's success? Whether people make good use of it? If they're going through the same motions as they would in another normal design contest, then there's no real benefit to them at all.

I don't mean all this to be harsh or anything, either. I just feel like there can be more done in a shorter amount of time. Maybe that's just my managerial background kicking in, but I like to see things succeed and succeed quickly.

> By the way, the site never had a games section. Maybe you are thinking of some other site.

Maybe. I could have sworn there was something like that a few years ago and it disappeared, but who knows. Maybe my mind is finally going.

> I do not agree that the social bookmarking links should go to the bottom of the page. That is vital for the site to gain more traffic from word of mouth passed by e-mail, Twitter, Delicious, etc..

That's fine - I was just commenting on what I see a lot of other sites doing. I think they put things like that on the side or on the bottom because the bottom area of a web page is often the place people go when they have a specific thing in mind that they're looking for and it's not at the top.

> It will only upset users that are used to find things in certain places.

I understand this problem, but there IS a point in any project where major changes need to be made, and those changes WILL anger some people. If you try too much to avoid angering anyone, then you are letting the whims of one person (or simply the fear of angering someone) hold back the site.

However, if you have a community of people helping to build / rebuild the site, then you can ONLY do good things.

All you can do for the angry people is acknowledge their issues and hope that they see the good in the improvements you're making. If people are angry enough to email you about the change, then it usually means that they are addicted to the site and simply need a bit of friendly assurance and guidance. I've found that some of the angriest people can end up being your biggest supporters in the end - they just tend to be vocal and want to be heard, and if you acknowledge their issues, then they'll usually go quiet and start using the new changes. The CONTENT of the site will be what makes everyone stick around in the end.

If you're still hesitant about it all, there's no reason you can't start the redesign as a separate version of the site that anyone can access at any time. That way, people can preview and use the new design for a little while before it becomes a permanent change.

Thank you Jonathan...

You are saying what I have been thinking all along. I LOVE this site for it CONTENT. There are MANY PHP sites that have classes for me to search through and use, but this, by far has the best CONTENT out there.

This is not an attack, just an opinion.

When I found out about the site redesign, I got excited. I immediately broke out my sketchbook and drew out what I thought was a beautiful redesign... I started to lay it out in PhotoShop so I could break the elements down. Then I opened up the "tool" and stopped in my tracks.

Don't get me wrong, the tool is great. But the creative limitations the tool brings are immense.

My design was to move the login/user functionality fixed to the bottom of the browser, with various mouse-over states. To modernize the look navigation system. to give the overall look of the site a sleek, modern feel.

But as I said in an email, my hands, as a designer, were completely tied.

I spent well over 6 hours trying to work around these limitations, like the table'ized navigation... having a second row below the navigation with inline styles forcing what should have been accomplished with a simple css padding/margin-bottom... having td's between each menu element with a   forcing what should have been accomplished with a simple css padding/margin - right/left...

This, and many other things left me having to perform css hacking hell... even to the point of having to display:none elements that should not be hard-coded.

Heck, I couldn't even find a creative way to break out of the [logo][title][logo] structure that plagues the top of the page.

Eventually, I gave up... It was way too much CSS hackery that resulted in something I felt was not even worth showing to the rest of the world.

The bottom line is this... Many community-drive full site redesigns have been successful in the past... and they all started with exactly what Jonathan described.

This doesn't mean that every page-type body needs to be modified... In fact, I would even suggest you initially leave the content area the way it is (aside from allowing css changes to those pages). But allow every aspect of the site to be modified. Sure, there are some things that must be there, like advertisements... But there was so much more that _could_ have been allowed for modifications.


I love your site's content, and I will continue to use it for no other reason than content. I will say, however, people do not visit Rome because it offers them something of value _today_... people visit Rome to _look_ at the amazing things they did _in the past_.

The day might one day come, when a site offers a set of features, a look and feel, and the _beginnings_ of great content that is hard to beat. If our PHP Classes community is not ready to compete, it may become like Rome.

Heck... just look at what Git did to Svn... SVN is great, works well, but Git has a slick interface with a few extra features and SVN is quickly becoming a thing of the past.

I don't know what makes you think I am not well aware of the security issues of publishing user submitted HTML.

I have just told you that it took a lot of time to develop an HTML parser and security filter package. Why would have done it if it was not for addressing the security issues?

If you are not sure if the package is capable of dealing with all sorts of exploits that can be performed using HTML with Javascript or malformed tags, you may look at what exactly it does before you jump to conclusions that it is something that should not be used to prevent security exploits robustly.

You cannot compare the whole solution with CKEditor because that is mostly a Javascript editor. Real security audits of the submitted HTML happen on the server side with PHP. That is what the secure HTML parser does. The CKEditor counterpart is the HTML editor, which is all in Javascript.

bbcode is not a solution for this century. It is a patch for publishing systems with lack of proper security filtering resources.

Every current browser supports HTML editors. Of course there are browser differences that make developing a consistent solution a more challenging task. That is why it took more than 2 months to develop and there is still room for improvement.

This site just did not allow HTML content editing before because the HTML parsing and filtering package was not developed until this year.

But if you wonder if the solutions that were developed are robust enough, you may try them yourself and evaluate, they are Open Source. More eyes auditing the code are always useful.

phpclasses.org/formsgeneration

phpclasses.org/secure-html-filter


There is not much point in using sub-domains for different site sections. It is just a renaming of the URLs.


Graphic mock images of design proposals are not useful for this site. This site provides a design editor solution that lets you preview real HTML and CSS with real site pages. You cannot do that with just graphic mocks.

Contests that accept graphic mocks may elect a design that is not feasible. It only works on images, but not in HTML pages.

A design submission system that was provided in this contest is much more adequate to provide designs that can really be implemented.

The reason why other design contests just accept static images, is because it is complicated to implement a design submission like of this site. It certainly took a lot more time to develop but its advantages are evident.

If Henry Ford (and every other car maker) just did it like everybody else, we were probably still riding horses instead of driving cars. I did not develop this design system to do better than other design contest sites. I did it because the site needed something better than a design mock image contest.

There would not be any point in making a first round of the contest with graphic mocks. That would not guarantee that the final implementation could be done in practice.

The people that excluded themselves from participating because they could not submit image mocks, I am afraid they would never make the final stage because they seem to not want to turn their proposals into HTML, CSS and images that would really work and look well.

They probably leave that part of the task to somebody else in the design shops they work for. The PHPClasses.org site could not do that for them. So, either you provide a final solution or you are not helping in the purpose of the contest.

Still, nothing stops any designer to create their mock designs in Photoshop or even in paper. I am sure many contestants did that first. The final result must be submitted in feasible HTML, CSS and images.


I am not trying to avoid people anger. That is pretty much impossible because there will always be people that are unhappy with certain details. It is impossible to please everybody.

However, I agree with you that people that express anger regarding something they feel wrong are very important. Those are the ones that bothered to complain because they want the site to be better. That is why I never ignored those people.

The point of not making too many radical changes is that leads to people stop using the site resources for not being able to find things where they used to be seen. If people do not find the "Contribute" link, they will not contribute and the site stops growing. Some will complain, but most other won't.

Changes can be performed gradually. That is what happened in this site since the beginning. It is a smoother path to let people adapt.

> I don't know what makes you think I am not well aware of the security issues of publishing user submitted HTML.

Two reasons:
#1. A lot of people aren't aware at all, and those who are don't always have a full grasp on everything.

#2. The benefit you've described from having rich text comments and such doesn't seem to be worth the risk and hassle of properly securing HTML. The tradeoff just doesn't seem to make sense.

Having spent years on an application that focused on this very topic, I usually have more experience on this topic than most people (I am not trying to brag - it is simply the experience that I happen to have), and I constantly see other developers suggesting their "ultimate" solution. I usually point those developers to this site:

ha.ckers.org/xss.html

And even if they were to address 100% of the attacks on that page, all it takes is some minor changes (changing the position of a delimiter character, for example) to create an entirely new attack, forcing you to constantly be in maintenance mode.

Or, if their solution tries to sanitize data by forcing the submitted data into a parser (which sounds like what you're doing), they usually end up with users who complain that the parser strips out too much. Other times, the parser may not be able to understand "safe" tags and practices that are bad when mixed in certain ways. For example, take a user that has submitted a transparent <div> that fills the screen and takes the user to a bad site on the next click. Chances are that all of the tags and attributes used would be valid, and it's not exactly an XSS attack, either.

MySpace had this exact problem, and a lot of users hated the design system because they could put in SOME HTML (more than just formatting), but not all the HTML they wanted, and it became frustrating. Then there were the people who went overboard with gaudy-looking HTML, which made it look really bad. MySpace eventually took down their rich text editing engine for comments because of all sorts of problems with it.

Now we have Facebook, which has overtaken MySpace in popularity and gives FAR less customizability to its users, yet for its millions of users, most are not complaining about the lack of HTML editing and rich text comments.

But if you HAVE to have rich-text comments for some reason (I don't know if you've gotten a lot of letters demanding it or something...), then you say that bbcode is not a solution for this century, and I partially agree. I agree that it's not a solution OF the century (the end-all), but I still think that it has a lot of use:

#1. Given its popularity, there are a lot of users who already know it and don't have to re-learn anything new.

#2. The users who DO use rich-text will probably only be concerned with minor formatting, which bbCode handles. Do users need to be able to define full tables in their comments? I would be surprised if they did.

Also, bbCode is just an example. I'm not stuck on bbCode specifically, which is why my original reply talked about "pseudo" HTML. There are different variations, but I used bbCode as my example because of its widespread use in forums.

> Every current browser supports HTML editors.

That's not ENTIRELY true. Yes, most current browsers probably support those editors, but the problem is that all HTML editors (at least all of the major ones) rely on the browser's built-in editor engine, and they simply expand upon it. Since each browser's internal editor engine is different, you'll often run into compatibility issues. Firefox on Linux may render a tag in its engine differently than Firefox on Mac or PC. Safari has tons of compatibility issues - write something on Safari and then open and save it in IE and there's a good chance you'll get a different result.

Now, if you're forcing the results into a parser, then you have to deal with the issue of incorrect results after the parser "sanitizes" the data. Let's say you write something in Safari and preview it before saving - it looks good, then the user saves it and the result looks different. Now you have a user complaining that the comments engine is messing up their post. Or their browser's internal engine may be able to render invalid HTML by doing some "soft" rendering. But when the post is saved, the HTML parser throws out the whole 5,000 word post, and then you've got a REALLY angry user.

===================================================================
ALL of this begs the question - is it worth it?
Have you had a high demand for this feature? Why would your site need it more than the users of Facebook, or any other major site? Is the potential risk of missing an XSS attack or dealing with frustrated users worth the ability to have users put in more than just simple formatting?
===================================================================

> There is not much point in using sub-domains for different site sections. It is just a renaming of the URLs.

Yes, the URL is different, but you and I both know that people have come to expect that a different DOMAIN means that they are on a different web site. Just a mental distinction for a lot of people, and you can use this to your advantage.

It's the easiest way to divide and conquer - by separating out major areas of content into separate "sites", it gives you license to redesign one site without having to redesign the others at the same time. It also opens the door to the opportunity of having slightly different designs for each major site (which would probably give you more flexibility to design for different types of pages).

> This site provides a design editor solution that lets you preview real HTML and CSS with real site pages. You cannot do that with just graphic mocks.

That's because that is not the purpose of graphic mockups. Graphic mockups are intended to give a QUICK idea about a potential look and feel. It opens the door to more design entries because they can be produced QUICKLY, and it also lets the users judge and vote QUICKLY. Once the users vote on the mockups that they like, THEN the designers can take the time to convert those top entries into HTML / CSS that can be previewed accurately.

I would not expect the final design to be a mockup. A mockup is simply the first step and the freedom of being able to design free-form usually produces more ideas - things that are outside-the-box, and make voting more interesting.

I think we could probably argue back and forth for a while on this, but I know you listen and respond to user feedback, so maybe that feedback should be the judge of the success of this approach.

So far, it doesn't sound like people have really liked a lot of the results, and I would say it's largely because of the restriction. You're asking people whether they like blue or red instead of grey. I've only seen one design entry (the elePHPant one) that looked like it had any drastic difference. Even with one good entry, it doesn't make the contest interesting for the people who are voting. They are seeing a blue paint job, then clicking to the next theme. They see red this time, and they click to the next theme, and so on.

I would be willing to bet that the large majority (70-80% at least) of your voters are not viewing every version of every theme. I'd bet that most of them don't view anything beyond the first version/page of each theme, and for those who DO view anything more, it's on one theme and that's the one they vote for. Also, if you look at the time spent viewing each theme, I'd gather that they're not spending a lot of time viewing each one. There's probably 6-7 seconds until the preview loads completely, another 3-5 seconds of viewing time, and then a click to take them to the next theme.

Check your logs to see if those are accurate statements. If so, then users are taking the exact steps they would take if they were looking at graphic mockups, because that is the way they want to vote.


> Contests that accept graphic mocks may elect a design that is not feasible. It only works on images, but not in HTML pages.

I completely agree. 100% with you here. That's why usually graphic mocks are only eligible for the first round of voting, and you usually elect 10 or 20 mockups. Once you have a top 10 or top 20 set of mockups, those designers are notified and they are responsible for turning the image into a feasible HTML version. If they can't do it, then their design is disqualified, but they need to follow all the rules that you give them (leaving room for banners and such) if they're going to do it.

> It certainly took a lot more time to develop but its advantages are evident.

I guess I still don't see the advantages, especially if people aren't fully using the system.


> If Henry Ford (and every other car maker) just did it like everybody else, we were probably still riding horses instead of driving cars.

If Henry Ford asked C. Harold Wills for help, but said he couldn't change anything except for the color, then Henry Ford probably wouldn't have ever built the car that helped form his company.

And if every other car maker DIDN'T produce cars just like Henry Ford's successful method, then they'd probably have gone out of business a long time ago.

There is a time and place for innovation. Sometimes its good to reinvent the wheel, but many times you end up with the same result in the end.

> The people that excluded themselves from participating because they could not submit image mocks, I am afraid they would never make the final stage because they seem to not want to turn their proposals into HTML, CSS and images that would really work and look well. They probably leave that part of the task to somebody else in the design shops they work for.

That's not a safe assumption to make. Most of the people I've come across creating mocks in Photoshop are familiar with turning them into HTML, and are probably very comfortable doing so. Unless you asked the users whether they would be able/willing to convert it into HTML, then I wouldn't assume anything about that part of it. It's easy enough to simply post a requirement that any designer will need to convert the mockup into HTML if the mockup makes it past the first round of voting.

It is simply time-consuming to turn any good design into -GOOD- HTML/CSS, and most designers don't want to produce HTML versions of 5 comps when there's 100% chance that 4 of them won't be used. It's just not efficient use of time.

I do this all the time myself. I design several comps in Photoshop, present them to the client, and when the client chooses one, I convert it into an HTML template, make sure it works properly in all browsers, and then show them the HTML result to get a second approval of the progress.

> Still, nothing stops any designer to create their mock designs in Photoshop or even in paper. I am sure many contestants did that first. The final result must be submitted in feasible HTML, CSS and images.

The restrictions of the current design system DO stop them. There's no sense in creating a mock design if the new design system doesn't allow them to submit it for voting... The designers who chose not to submit things because of these restrictions have repeatedly said they were too limiting, which is what prompted this whole discussion to begin with.

> The point of not making too many radical changes is that leads to people stop using the site resources for not being able to find things where they used to be seen. If people do not find the "Contribute" link, they will not contribute and the site stops growing. Some will complain, but most other won't.

Most users have a purpose when visiting a site. It seems we are talking about regular users, who keep coming to this site because of its content, so they have the advantage of knowing what the site has.

Given that, if a new design's navigation is SO radically different and hard-to-use that users cannot find the content that they KNOW is there, then there's a bigger problem - the design process has failed. The purpose of having an open contest with community feedback is so that regular users can see what they're going to be using and complain if something major is missing.

That is also why preparation and planning is so important. Knowing what sections are most active and what people click on the most will help ensure that those stay on the navigation. (This is also keeping in mind that any page on the current navigation bar will statistically get more activity just due to exposure, so you have to factor that in when making judgments about crafting the navigation)

Referring to my last reply, I had also mentioned making the redesign available to use concurrently with the current design, so people can switch back and forth (maybe the redesign is just on a different URL / subdomain). That enhances the feedback that you get, since people will be able to really use the new design and give accurate feedback about it.


Wow. These replies are starting to get really long... :)

I should also clarify something. I was not trying to insult your intelligence about security. I find it better to be safer than sorry, so I don't assume anything about what a person knows about security.

I am not a lot of people. I am well aware of the security issues. I don't know why you assume I do not "have a full grasp on everything".

As for ha.ckers and sla.ckers I have been there precisely to put the filtering system to a judgement and torture until nobody else had any case to demonstrate that my filter would not pass.

sla.ckers.org/forum/read.php?12,299 ...

Actually, if you have looked at the Secure HTML parser class, you would notice that it comes with a unit test script that tests the vectors from xssAttacks.xml against good filter responses.

phpclasses.org/secure-html-filter

I don't know any PHP solution that provides this level of quality control.

But if you think it is easy to provide an attack that bypasses this filter classes, I would certainly like to know.

I can understand if you tried to develop a similar solution of this level of reliability and you gave up because it was too hard. That does not mean that nobody else can try to do it and succeed.

If MySpace gave up on HTML editing because users entered undesired types of HTML code, it is their fault that they did not filter the HTML conveniently. It does not mean that nobody can do it right.

As a matter of fact Google allows HTML editing of forum posts. AFAIK Google security was not compromised because of that.

They just put in the editor toolbar the HTML format controls that they allow, which currently is just bold and italic. But you can paste HTML copied from anywhere. They perform the necessary filtering and end up allowing other types of tags besides bold and italic.

It seems that this is what MySpace should have done. Instead they gave up because they did not have the competence to provide a better HTML editing solution.

I do not have many requests for entering HTML comments in the forums, but I feel the need myself. It is not so much about formatting text styles, but mainly for inserting images, embedding videos, presentations and download files that often the users need to provide examples of data about problems they are reporting. I do not need to enable all sorts of HTML to provide this.

Anyway, my priority is the blog system. There is a pile of good guest article proposals that were not approved yet because they do not look nice using the current plain text formatting system.

Soon you will see many interesting articles well formatted in HTML making it well worth the effort that the HTML editor and secure HTML parser development took.

I don't know why you assume that the HTML parser will produce incorrect results. You seem to have not tried it, so you are making wild guesses of something you do not know.


I do not need to use a different domain to show different designs. Tens of designs were approved and all show in the same domain. Even if I want to show a different design in a sub-set of pages, I do not need a different domain.


That graphic mockups do not serve to preview how real site pages will look like, everybody knows. That is why they would be useless for this contest.

This is a contest, not a deal with Web design customer. Each designer is not expected to come with many proposals to please the Web site owner because it will not be the Web site owner that will decide.

Each designer should come with the best proposal in his opinion and let the users of the site decide which is the best of all proposed by different authors. But the best, is the one that integrates well in each site page.

Therefore graphic mockups will not do because there is no way to make them satisfy the site requirements without need for human moderator evaluation. Images and paper accept everything. The design system enforce requirements that are there intentionally.

What would be the point of accepting mockups of designs that later you realize that cannot be done in order to satisfy the real page requirements? Just to get many contestants with the false hope that they could win? Does not seem to be a good idea.

This contest already got 34 approved entries. How many more do you think it would be sufficient? 600 hundred? I don't think the users of the site would have patience to review 600 mockups, many of which would be unrealistic.

I don't know where you see that users did not got interest in more than one design. Practically all designs had comments and votes and the voting period has barely begun.

If you read the comments, you can see that the people that are commenting have tried the designs in different resolutions, pages, and types of users.

Of course not all users reviewed all designs extensively. It is like in any election. You cannot expect that all users have the time and patience to do it, especially when there are more than 30 contestants.

All indicates that there will be a second turn between the two most voted designs. With just two options, users can dedicate more time to evaluate them before making the final decision.


I just mentioned Henry Ford to give an example of somebody that invented something that people did not ask but it was exactly what they needed.

There was no shortage of people claiming that cars were machines of the devil and should not be used. They did not want to accept progress and kept making exaggerated excuses for not using cars. That similar to what you are doing.

This design system can be better but it is already very powerful and adequate for the purpose it was developed. It imposes restrictions intentionally because those are related with the feasibility of the proposed designs.

For instance, some people complained that navigation bars are made of tables, as if using tables is crime and you will go to hell if you use them.

Some claimed that they cannot style the navigation bars to lay them out vertically. Those can only blame themselves for not having read the site blog posts that teach them how to switch navigation bars layout with 2 clicks.

Some wanted to put site top navigation at the bottom of the pages. Why would the system allow something that does not make sense just because a designer wanted it that way?

Designers that really want to participate must adapt to the constraints. The world does not revolve around them. It is the other way around. They must adapt to the world as it is or else they will always be frustrated for not making an effort to fit in this world.

Nobody said it was easy. That is why the contest prize is not low.

I get the sense that you are taking offense to my comments. Please understand that that I do not know you personally, or what your exact level of expertise is. I have tried to make it clear that I am not insulting you or the product you're creating. I've seen by your contributions that you have a good handle on PHP, but I have learned over time not to assume anything about anyone. There are people who know PHP like the back of their hand, but aren't familiar with good security practices. If you're not one of those people, then that's great, but you should not take offense to me simply not assuming that you are a security expert.

I did see that your package had addressed the issues with the attacks listed from ha.ckers.org, which is why I had brought it up in my post and pointed out that new attacks can be created everyday and everytime a new technology/browser plugin becomes popular enough. My entire point was to show that this path leads to constant maintenance, which means lots of your time and also the chance of "missing" a new exploit.


> I can understand if you tried to develop a similar solution of this level of reliability and you gave up because it was too hard.

:) No need for personal attacks. I assure you that we were successful in developing our solution; we didn't give up, but it did take up a lot of our time to constantly monitor for new types of attacks and update the filter rules to address them. Luckily, after I established a process for doing this, I was able to hand it off to one of my developers to free up my own time for other projects, but it doesn't sound like you have that same liberty.

> If MySpace gave up on HTML editing

I think you missed my point. MySpace had all sorts of problems, but that wasn't what I was trying to expose. My point was two-fold:

#1. MySpace felt it necessary to provide rich-text comments to their users. And even though their users made use of the rich-text capability, almost nobody used or needed any HTML beyond simple formatting, images, and videos (all of which could be addressed with pseudo HTML code).

#2. FaceBook came to power while MySpace struggled with all of their issues. It did away with rich-text editing, and they still continue to grow with very little complaint from their users (about the lack of rich-text comments/statuses/etc). In order to address those basic needs of sharing images and videos, they provided separate interfaces for attaching thosse items.


> AFAIK Google security was not compromised because of that.

Actually, Google has had to fix several successful XSS attacks. Read Chris Shiflett's blog - he's covered at least one of the attacks.

Google was subject to the same problem I've been describing - it was able to filter out most of the attacks, but new ones were invented, and Google's security was compromised until they could fix it.


> I do not need to enable all sorts of HTML to provide this.

I know. That's why I've been suggesting pseudo HTML. It offers the same capabilities that basic HTML offers with little overhead processing time, and far less maintenance. You shouldn't ignore that type of solution just because it's "old" - if it works and is practical, then that's all that should matter. Even Experts Exchange uses pseudo HTML for their article submission area, and it's been working well for them so far.


> I don't know why you assume that the HTML parser will produce incorrect results. You seem to have not tried it, so you are making wild guesses of something you do not know.

I am not making wild guesses - I am stating what happens based on my experience. I -HAVE- tried it. The application had a very wide range of users on all platforms and browsers. Maybe it was susceptible to more issues because my users were creating complex web pages that used much more than simple formatting, image, and video tags. Perhaps if you're limiting your users to very simple HTML, you won't run into the same problems, but then it goes back to my above point about using pseudo code if you just need simple formatting.


> I do not need to use a different domain to show different designs.

I'm not sure what you mean? I was suggesting different subdomains to separate the site into multiple sites, so each could have its own design. I'm not sure how your comment relates to that?


> What would be the point of accepting mockups of designs that later you realize that cannot be done in order to satisfy the real page requirements? Just to get many contestants with the false hope that they could win? Does not seem to be a good idea.

Judging by your comments, I think you are not stepping back to look at the full picture as we're talking about this.

Put aside the design system for a moment - the design system is there to allow people to apply a new coat of paint to an existing car, and that's not what these other designers are asking for. They're not trying to create mockups that will fit the design system - you seem to have a thought that everyone is trying or SHOULD be trying to create designs that ONLY fit the design system. That's not what we're talking about, so please stop thinking about page requirements for a moment.

The mockups are not INTENDED to meet the final page requirements. Mockups are simply IDEAS. They don't HAVE to fit the requirements right away. There is absolutely no purpose for mockups other than to generate creative ideas. That's it - get creative new thoughts and ideas about the way a page should look, about navigation, and so on. Mockups are not intended to be final, and people who submit mockups know this quite well.

It's not about giving false hope, either. People entering the contest and submitting a design are aware that they are submitting designs for a web page. They aren't going to paint a picture of their house and submit it as a design entry for a web page. It just doesn't happen, and for the rare occasion that someone is trying to be funny or ridiculous, then they probably know that their design entry is not going to work out. Anyone submitting a mockup should have reasonable expectations about what should be on a mockup.

Given that this is a contest judged by a lot of site users, any mockup that was too ridiculous or not feasible wouldn't make it past the first round of voting, leaving you with only feasible designs that could be turned into actual HTML templates for round two. I don't understand why this would not work - it has worked for plenty of other sites.

> I don't know where you see that users did not got interest in more than one design.

Well, you didn't answer my question about checking the logs. There are always going to be comments - I didn't say there would be no activity at all (which would be a ridiculous claim, given that we're talking about the subject). Re-read what I suggested was happening, and compare it to your logs.


> They did not want to accept progress and kept making exaggerated excuses for not using cars. That similar to what you are doing.

I disagree, I think that is what you are doing with this design system. The design system is forcing people to accept the same animal with a different set of colors. It's like you're saying, "We don't need a car - we just need to paint our horse."

I am arguing for a system that would introduce progress by letting people suggest ideas on how to change ANYTHING, not just the colors.


> This contest already got 34 approved entries.

Yes, and I've flipped through them. There were only a handful that could be considered anything more than simply changing some hex values to change the color scheme.

You also have a group of people that WOULD have been willing to submit mockups if it weren't for the design system restricting them to simple paint jobs. Chances are that there wouldn't be 600, but you'd definitely have seen more variety, and -possibly- better quality (there's no guarantee, but there's simply a greater chance by having more entries).


> For instance, some people complained that navigation bars are made of tables, as if using tables is crime and you will go to hell if you use them.

-shrug- Some people are snobs about HTML. Everything has its place and use, and I think tables can still be practical. But those people might think that tables are "not a solution for this century" just because they're old. :)

Even though I'm fine with tables, let's assume that doing a more open-ended design meant that someone suggested a new template with a primarily-DIV/CSS layout that resulted in faster rendering and less code. If they can make a valid case that shows that DIV/CSS is FAR better than tables, then let them make that case. If it's not necessarily better, but just "newer", then there should be no reason to go away from tables. Use whatever is proven and practical.


> Some claimed that they cannot style the navigation bars to lay them out vertically. Those can only blame themselves

Agreed, although I think they were probably referring more to the need to provide a more thorough / full layout mockup and simply chose the wrong example of a design system restriction.

> Some wanted to put site top navigation at the bottom of the pages. Why would the system allow something that does not make sense just because a designer wanted it that way?

So let them submit a mockup with navigation at the bottom of the pages. If you're trusting your voters to pick the winning design, then you should also trust them enough to know that putting navigation on the bottom is probably / frequently a dumb idea.

> Designers that really want to participate must adapt to the constraints.

It's not to say that you can't have ANY constraints at any time. Like I've repeated over and over again - round 1 of a mockup system is the only time where constrants are loosened just to let people's creativity go. Round 2 is where they are forced to adapt their design into an HTML page that can meet those constraints.

You may be thinking, "Well, the design system forces them to adapt their design, etc..." but the problem is that the design system is forcing the same basic site structure down the throats of the designers. Sure, there may be SOME options (vertical vs horizontal navigation), but generally speaking, it wants to preserve the content structure, and maybe - just maybe, a design might have a better idea of how to present the content.

I am not taking offense to your comments but I feel it is tedious to repeat my justifications for not accepting some suggestions that you are insisting.

I also commented that if you doubted that the required security measures are in place, you should try them and evaluate yourself, instead of making suppositions of something you did not try.

I never intended to offend you when I said that I could understand if you tried something and gave up if it was to hard. I could not determine before if you actually succeeded. That is why I said "if". Anyway, please accept my apologies if you took offense for that.

I agree with you that many qualified developers are not concerned enough with security issues. That is certainly not my case.

Anyway, you seem to have misunderstood that the security level provided by my HTML parser and filter is based on handling all the cases listed the ha.ckers.org vectors. I just mentioned that to let you know that I am aware of those test cases, not that I use them as measure to evaluate the level of security protection of my approach.

If your security solution is based on keeping up with latest XSS attacks listed in that site, I am afriad that is the wrong approach. That is what is called the blacklist approach. You just be omiting security breach sympthoms, not providing a general cure.

Now I can understand why you say it is hard to address and maintain yoru solution, as you will always be subject to new attacks.

The right approach is using the whitelists. You should only accept well formed HTML and CSS and documented tags and properties. Everything else is not tolerated. Even some well documented and well-formed tags and properties have to be rejected.

If you have to accept a particular tag or property that is not documented but you are 100% sure that it is secure, add it to the whitelist, but by default it must be rejected.

This way you do not have to play catch up with newly discovered security exploit techniques.

If somebody discovers a way to workaround your white lists, that is because you have not implemented them well. It is not impossible to have ways to work around your implementation if you follow this approach. Nobody is such a perfect programmer that cannot make mistakes.

But if you follow the white list approach rigorously, chances are that your solution is generally immune to newly discovered exploit approaches.

You are also pretty immune to exploits done using new technologies because you will only support them if you white list the newer tags and properties that they introduce.

My approch of white listing newer technologies that require new HTML tags is by supporting newer DTDs, for instance. When you do that, you analyze which tags in the DTD may be dangerous, and so you do not allow them to be white listed.


I don't think you know Google forums. They are fairly recent, lanched in 2008 I suppose. They were developed to provide a richer forum experience to the users, replacing the old Yahoo groups like forums style. So, no vulnerabilities of Google forums are known so far. They allow HTML editing.

Still, in the old Yahoo groups, HTML messages were allowed if the group owner wished.

If Facebook avoided HTML editing, it is their problem. I do not think the success of any social network is related with the lack or presence of HTML editing support. So, your comparison of MySpace versus Facebook not allowing HTML editing does not related with the success of each network.

Pseudo-HTML is a limited solution because you do not take advantage of the browsers built-in HTML editing support. You make people learn a new tag language to add new features.

My approach is more flexible. There is no need to reinvent a new tag language. I support special text marks for inserting in the Visual HTML editor using menus accessible with mouse clicks. The resulting document is still HTML, not a pseudo-HTML language.

If you were not aware of this, you should try the HTML editor itself. When I say you have not tried it, I am talking about my HTML editor, not that you have not tried to implement a content editor yourself.


What I mean that you do not need separate sub-domains is that you can have all in a single domain, and still have separate code for each feature.


You keep ignoring what I said before regarding the design contest. This edition allows editing the main HTML and CSS templates and icons. Future editions will allow to edit the templates of most common types of pages. One step at a time.

I think it is non-sense for you to insist in minimizing this approach by stating that it is just providing a new coat for the site.

Right in this edition designers are allowed to change the places of different types of elements of page header and footers. It is way more than just letting designers change colors and icons.

I already explained several times the inconvenience of having multiple stage contest on which in the first phase designers are allowed to propose unrealistic layouts mockups that are not feasible in HTML.

It would be a bad approach because it would leave out designers that provide mockups of feasible layouts but were not so appealing for users, and so would not get enough votes to pass to next stage.

Furthermore, something that you are probably not aware, is that the majority of the designers did not want to show their proposals before the voting process started. They feared to be copied.

If I were to make a multiple stage contest, every designer would have to show their ideas for voting before moving on to the next stage. That would allow other designers that passed to borrow their ideas, thus stealing their creative work.

The bottom line is that your multiple stage approach is full of inconveniences that I do not want to deal with. Sorry, it does not please you, but I hope you understand my reasons.


I don't think you read the comments that many users posted about the different themes. Some complained precisely that the layouts do not work well in certain cases.

People that made such comments obviously tried the themes in several variants of browsers, resolutions and type of pages. There is no need to analyze any logs because the comments made by those users are true claims. They really used the theme preview system to view the designs in many combinations of preview options.


The design system imposes constraints on purpose. If you let the users do anything they wanted, they would probably get rid of advertising. That can't be done because the site needs the advertising revenue from non-premium user accesses. For many users removing advertising is not a dumb idea, but it be very bad for the survival of the site.

Likewise I cannot allow users to put at the bottom of the site pages the navigation bars that have the links to the pages most users want to visit. Otherwise the users will not visit as many pages they wanted, thus hurting the site revenue.

What do you prefer? That I design system that allows lets you propose things that hurt the site revenue, or one that keep the site open as a viable business?

This is just an example of common good sense. If certain type of layout changes are bad for the financial viability of the site, why bother allowing uses to make such types of changes in first place? It would be stupid if I allowed it.

-shrug-

Ultimately, you're going to do what you want to do, and that's fine - it's your site. This situation simply reminds me of past projects where project leaders came up with features/decisions first and later looked for feedback that would reinforce the decision that had already been made.

You'll always find support for just about any idea, which just makes it harder to dissuade someone who is too close to the forest (in my opinion). Sometimes a person has invested so much time and energy into reinventing the wheel that they don't initially realize that they've spent a long time to end up with the wheel - a useful solution, no question about it, but a solution that already exists in some way.

> I don't think you know Google forums.

No, I do and have used them. I think you had idealized Google to a degree that their "solution" was flawless. I was just trying to illustrate that even Google's massive amounts of money and manpower cannot avoid security problems altogether.

> The right approach is using the whitelists.

I recognize this as a BETTER approach than blacklists, which is why I said several posts ago that users might complain if/when their posts look different after being sanitized.

Ultimately, you're relying on the browser's internal editor component, which is different from browser to browser, from platform to platform, from version to version. There are a lot of varieties, and there's a good chance that they will sometimes be wrong. You may not experience a security exploit from it if you're just stripping out "bad" data, but you may experience complaints. I'm simply talking about probabilities based on dependence.

> Pseudo-HTML is a limited solution because you do not take advantage of the browsers built-in HTML editing support. You make people learn a new tag language to add new features.

Perhaps the difference between us is that I do not put much faith in the browsers. As much as possible, I try to steer clear of browser dependence, and when I can use something that people are already familiar with (most people know the basic pseudo HTML codes like [b]bolded text[/b] and if they don't, it's easy to list the major 5 or so tags off to the side), then I follow that path. It simply seems like a safer, faster, and easier approach. There's just not that much to be gained from the HTML editing, in my opinion, to make it all worthwhile. Again, if you feel differently, then best of luck.

> When I say you have not tried it, I am talking about my HTML editor,

Actually, I played with the system for a while the second or third day after the contest began. Admittedly, I did not complete a full design submission, nor have I touched the editor since then. Maybe it's changed since the beginning of the contest, but at that point, it definitely felt quite rigid.

> What I mean that you do not need separate sub-domains is that you can have all in a single domain, and still have separate code for each feature.

Hmmm... I realize you can do that, but I'm not sure how that relates to what I was proposing. I wasn't trying to say that you should build COMPLETELY different code for every site. I was trying to say that separating out sites to different subdomains can provide a CONCEPTUAL or ORGANIZATIONAL separation. Allow me to explain.

A lot of people don't make full use of a site that has a ton of widely-varied features, because they often come to the site for one particular purpose. If the site is good, then they bookmark or tag the site as a good resource or answer for that purpose, and everything else is lost. I would imagine that a lot of people come here for the code and don't make full use of the other sections (at least not as much as they COULD be doing).

There are probably users here that would be IDEAL candidates for using the jobs section or searching for hosting, but the FOCUS of the site is on code. By separating out the features onto different sub-domains, you can establish "sites" which have a specific focus on a topic. That way, instead of someone just considering the "jobs section" of PHPClasses as a secondary resource to Dice.com or Monster or whatever, they might consider a separate, jobs-only site as another primary resource that competes directly with Dice.com or whatever. It's not really much different FUNCTIONALLY, but it can definitely make people think differently about the feature if that "feature" is actually a full site dedicated in focus to that topic.

> Future editions will allow to edit the templates of most common types of pages. One step at a time.

My current impression, from your comments, is that the "second step" could take 5 years because the first step took 1 year, and was far simpler than the second step. I also currently think that the second step represents the ability to change the site in a far deeper manner, not just additional page types but a little more on the structure side, as well. I suppose I feel like that using the normal design comp / conversion / etc process would have resulted in ideas that could be directly applied to step 2 and step 1 could have been skipped without the need for any special design system.

> It would be a bad approach because it would leave out designers that provide mockups of feasible layouts but were not so appealing for users, and so would not get enough votes to pass to next stage.

I think the keyphrase here is "were not so appealing for users" - if something isn't appealing to a user, then it shouldn't pass to the next stage. Perhaps you have an idea that there will be a large quantity of infeasible designs and you'll end up having to reward someone who painted the Mona Lisa but didn't create a good WEB PAGE design. If that's the case, then you should know that in most design contests, there aren't many infeasible design entries. Usually the ones that AREN'T feasible are that way because they are thrown together quickly and without talent, so while they are not feasible as potential web pages, they also are fairly ugly designs. You have the additional advantage of working with a technical user base who would be able to identify a design as something that would not work.

> Furthermore, something that you are probably not aware, is that the majority of the designers did not want to show their proposals before the voting process started. They feared to be copied.

I'm not sure how that would be different from the comp / mockup method. It is far more common for all mockups / entries to be hidden until voting begins, precisely for that reason. So I'm not sure why you're bringing it up as a difference?

> If you let the users do anything they wanted, they would probably get rid of advertising.

You are also ignoring what I have previously said. There is no reason you cannot impose rules on entries. Most design contests have some basic rules for each entry, and those who don't follow those rules get rejected. The difference is that by allowing the designers to do whatever they want to do, within reason of the rules, you allow them more creativity.

Honestly, the way you are talking about the mockup process sounds like you have not tried it before or maybe you had the unfortunate experience of participating in one that was not set up correctly. There is a reason why that process is used by nearly every industry and every form of media. It simply works when done correctly. I'm really not sure what makes you feel like it is so ill-suited for this site - the reasons you have provided so far just don't really apply to the process when it is done correctly.

Worth1000.com runs mockup design contests everyday for digital compositions and logos. Granted, it's a slightly different animal, but the logo design contests are a little closer to web page design contests. There are mockups that are revealed at voting time, which all have to adhere to rules, and once the creative part of it is done, a company can choose multiple entries and work with them further to create a finalized version.

I'm not telling you to let it run free without any rules at all. I agree, that would be stupid and would not make financial sense. But if you tell the designers, "Listen, you can create whatever you want, but the attached images of advertising examples MUST appear in your design," then 99% of your entries will follow that rule because they don't want to waste their time. You can impose whatever rules you need (for the sake of the site). Everything else can be judged as a dumb or good idea by the people who will end up having to use the site.


My final note on all of this - I think it's pretty much too late for any change right now. I'm arguing based solely on the merit of the ideas. I'll understand if you have better uses of your time than to continue this.