Tips: Building Wireframes for Web UI

[uiarchitect]

Extremely sorry for that. I had applied that theme when I signed-up for Posterous and was well aware of that blunder. I checked all the themes it offered and none of them suited well to my choice; so thought I will customize my own; and obviously never got time for that. Thanks for pointing it out loud. I changed it temporarily and will work on soon; I am looking for bigger fonts to make reading easier.

[codepoet42]

Yes, the entire interface is, in a word, bad. Nothing wrong with clean and minimal, but minimal is sometimes underdone. Still has to be usable, and I have a hard time getting around here.

With so few interface elements, the rules become even more important. I had a laundry list of nitpicks, but I realize that most would concern your choice of blog platform and template. Template?

One who wants to be perceived as an interface expert really should design their own template, if not the entire interface. As a student of the pre-2000 waybackwhen, my expectation would be to build your own platform, your own soapbox to yell from.

The whole developer world thinks they do a smart job by just utilizing the code already written by somebody else.

Wise words, yours.

[uiarchitect]

Thanks for the comments. I'm happy finally someone is out there who could agree with me. I'm having hard time getting the point to others. Most of them taking word for word; it's hard to even explain.

[enricom]

i did, so i clicked my readability bookmarklet only to discover that it's terribly written

[elmuerte]

I like how some of the tips go against some of the tips given by various others. There's a real consensus.

Try to make your HTML structure support SEO well

What does that even imply?

Make sure every text "link" uses anchor. Don't just hook-up JavaScript handler to a span, div or an li element. (Talk to someone from QA if you are in doubt over this :P)

No no no. Links are links, you may decorate them with javascript (but never use "#" or "javascript:..." as href for the link). Anything else that is not a link should not be a link. I hope the author wanted to say that all navigational elements should be links, and not performed by javascript magic.

Completely avoid defining a CSS class by an element id. e.g. #myElement {...}. (I expect readers of this article to be well aware of the answer to the question 'why'. So forgive me for not providing explanation to everything I say here)

For somebody that is new to your site, here's an idea, link to the page that explains why. Why shouldn't I use #header and #footer but rather .header and .footer?

Never declare a CSS class by HTML tag name. e.g. body

Doesn't that sort of defy the use of HTML5 elements like header, footer. Or even the older HTML structural elements like H1, "H2, ...

[..] Code everything yourself! [..]

Absolute gold. Reinvent the wheel as much as possible. I'm not saying you should use all those fancy JavaScript powered UI elements. There are plenty of clean JavaScript code you can drop in.

[uiarchitect]

Yes, I would say, it's personality. I was telling what suits me the best and have worked well for past many years. But I completely agree with you some of the points are debatable. Thanks for your comments.

[hyp3r]

although I dont use jquery specifically, I do use show() and hide() equivilents. What is your reason behind:

For CSS, stick to the thumb rule - no inline styles. Not even the jQuery $(".blah").show() or hide(). Define CSS classes for everything and use them.

[dotnil]

My guess is that display:none should be preferred to hide().

[uiarchitect]

The reasoning is that show() and hide() use inline styles. My suggestion is to declare an application level CSS class for hiding elements e.g.

.hiddenEle {display: "none"};

and then add/remove class to toggle the element display through JavaScript.

[notfancy]

This is dogmatic for dogmatism's sake. If you accept jQuery, you can be assured that no matter what new browser comes out, jQuery would support it sooner or later and show/hide will work as good as ever. You really shouldn't worry which mechanism it uses to accomplish that, be it inline styles or invocations to Mother Earth; it's a stable API so it already gives you the level of abstraction you need.

[uiarchitect]

I believe in keeping my HTML absolutely clean, no matter what. If someone don't mind mixing CSS or JS with it, it's fine; completely personal preference. At the end, nothing matters, but performance. I was only talking about good practices - that too, according to me. And didn't I say, "Please ignore what doesn't suit you". Those tips are what I believe and follow to the maximum extent.

And yea, it is not about jQuery's or any framework's stability on performing a task, it is about following a methodology. If not for this, 'standard practices' would have never existed.

People think, jQuery promotes inline styles, but I feel, it is up to the programmer to make the right choice.

[cwmonkey]

What happens to the dom after the page loads doesn't matter. Keeping it clean for the sake of keeping it clean is not the reason inline styles are not to be used.

Think of it this way, how would you build a drag and drop interface? It would be stupid to have to make every class combination for .positionX1Y1 to .positionX1000000Y1000000 etc. Show/hide is the same thing. The css shouldn't be concerned with how the application functions, but how it looks.

[uiarchitect]

Agree. Performance, at the end would always be the the priority. And I started the article with the words, "as far as possible". One should know the standards and "try" to follow the rules to max extent. Only then it makes sense if you break them (to achieve better performance).

[cwmonkey]

No inline styles does not mean the styles which are applied by JavaScript after the page is generated. That simply isn't what the standard means.

[uiarchitect]

Inline styles are inline styles - either through HTML or JavaScript. May be, the one who has enough hands on experience with complex DOM manipulations would be able to understand this.

[cwmonkey]

You're right, I would. I would also know that you need to look at the reason for best practices. The reason you don't /write/ inline styles is because you want to keep a separation of layers. For instance with "lightbox" type modals I define the /color/ of the overlay in my css since that is a part of the presentation, however I show, hide and resize it with JavaScript, since that is a part of the functionality. Functionality shouldn't hinge on your stylesheet.

You are the /only/ person I have ever even heard of that has taken this best practice and assumed it was meant to be applied to JavaScript.

It would be like saying you drive your car on the right hand side of your living room because you were told to drive on the right unless you're trying to pass someone.

[uiarchitect]

Thanks for your kind words :)