Twelve Things Most Sites Need - Part II

نوشته شده توسط:ramin h
جمعه 21 مرداد 1390-04:10 ب.ظ

Twelve Things Most Sites Need - Part II

by Mike Cherim — Mar 3, 2008

In the first installment, Twelve Things Most Sites Need - Part I, I offered a six-pack of must-haves. Specifically I suggested sites should have a proper navigation menu, a meaningful, well-formed title, a method of contact, a site map, passive accessibility, and standardized markup. Now, as I offered the last six, in the order in which I thunk ‘em up, here is the balance.

7. A Usable Page Weight

Ironically I used to hate the Web. I started with dial-up and it was a miserable experience. Moreover, back in the day it seemed that every site I visited required some sort of plugin or add-on to make it work. Frankly, the Internet was a pain in the butt. This has changed on some levels. The need for plugins or add-ons is greatly reduced what with operating systems pre-loaded with all the necessary support. But some people still have dial-up. For the last six years I’ve had cable broadband and it’s a dream. I’m spoiled. And it’s very easy to forget the less fortunate and go hog wild, loading my pages with heavy graphics. It’s easy to forget how doing this will make for a less-than-happy experience to traditional dial-up and distant DSL users. Gotta keep the weight down.

I’m not saying the Web isn’t a place for heavyweights, it is, but with due consideration. If you want to offer heavyweight graphics and whatnot, let visitors navigate to them, instead of offering them on the initial page load. And warn users if something big is coming up. It’s only fair to allow those who want to opt out the opportunity to do so.

I suggest aiming for an upper limit of 100kb per page of combined background and embedded images (this is testable). You can buy a lot for a 100kb. To get the most bang for the buck, reduce the over all number of images, optimize them exporting only flattened, compressed files, and please pre-size embedded images for their location (being sure to add the height and width attributes to the img element). I’ve seen thumbnail-sizes that were really 900kb monsters with styles off! That’s just wrong.

8. A Helpful Error Page

If you’ve ever been lost, it’s always nice to see some helpful soul willing to give directions (assuming you are willing to admit you’re lost). On the Web you can be that helpful soul. Not only, as mentioned in the last installment, can you offer a site map to proactively guide your visitors, you can offer a friendly, styled “404” error page (or pages if you want to cover more errors). Your error page should offer at the very minimum offer a link home, a navigation menu, and at least a link to the site map. If you want to be a really helpful soul, though, try combing most if not all your nav tools and putting them on one page. Make a perfect 404 page offering a site map on the page (easy with dynamic site maps), search, even contact info, and more.

This is not hard to do. Ask your Web host for starters. Specifically ask them about custom error pages since you’ll want to provide something useful and most default server error pages, even styled ones, aren’t really very helpful at all.

9. Good Headings

In the last installment I spoke of the importance of using the right mark-up for the purpose at hand. I mentioned headings but didn’t go into detail. That’s because headings are so important they, well… they deserve a heading of their own. The use of headings is logical, and styling them is wide open, just use your imagination.

What good are they? They offer section demarcation, semantics and ordering, beauty in the right hands, a search indexing benefit, greater accessibility, and even a navigation source for some users of assistive technologies like screen readers. What more incentive could you possibly need to act on this recommendation?

10. Jump Links Provided

You may have detected by my suggestions so far that I’m big on helping Website users. I feel that the easier my sites are to use, the better their experience will be. I want them to not only find the goods, being supported along the way as needed, passively and on demand if at all possible, but I want them to want to come back. So, one of my twelve is going to have to be offering skip or jump links. I find these are very helpful to everyone with exception to most of those who use a mouse or pointer — and that is a greater number of people than you may realize. A jump link affords users the opportunity to jump down the page to the content or navigation, by-pass redundant or lengthy sections, access help content, and jump back up the page if you consider a top link or back to menu link a jump link. I do. Some may argue that it’s a replication of browser behavior offering links like this, but I’ve not heard recently of record numbers of browser-savvy surfers if you know what I mean. Plus, they’re simply innocuously helpful.

One rule: If you’re going to offer jump links, it’s best to make them visible, but not always necessary. There are ways to hide jump links from view while still maintaining a high level of accessibility and usability to a very large percentage of users. Do note, however, that displaying them will increase that percentage to 100.

11. Focus Styles

I’m not a dedicated keyboard user, but I do use my keyboard a lot. It’s helpful at times, convenient at other times. It’s an option. Sometimes I use my keyboard on the Web, tabbing onto pages, bouncing around from link to link following the natural source order of the page. Sometimes, however, depending on the site, this can be difficult. I’ll be tabbing along, minding my own business, when all of a sudden, wham, I’m lost. I don’t know where I am on the page. The reason is invariably the developer of the site failed to offer one to the most simplistic of accommodations: link :focus. Probably due to simple ignorance. But I’m here to change that.

To offer link focus it involves nothing more than a simple style sheet entry, like this:

a:focus, a:active { color : black; background-color : yellow; }

The a:active is for Internet Explorer, and to provide the when-activated styling on other graphical browsers. Obviously you can get more creative, but that above will help make your Web pages a lot more navigable to keyboard users and nobody will suffer a diminished experience.

12. Robots.txt File

You may be wondering why I included something so mundane as a robots.txt file in this line-up, but I feel it’s very helpful to have one. It provides instructions to honest indexing robots and spiders like the GoogleBot, telling them to stay out of certain directories you don’t really want them in anyway. Why have your bandwidth wasted needlessly?

Some people, I’ve heard, want to disable right-click on their sites thinking that they may somehow actually succeed in stopping people from copying their images (can’t be done), yet they don’t have a robots.txt file excluding their images directory. The latter would be far more worthwhile. It’s very easy to make one, there are even tools you can use to help you get the job done.

Is There More?

The short answer is, yes, of course. But if you satisfy all twelve items in this two-part article, you have done well. You’ll be offering a quality site that is a cut above many sites of the Web. And the benefits, you may find, will actually be noticeable, and perhaps even tangible. Happy coding.




HTML, the Foundation of the Web

نوشته شده توسط:ramin h
جمعه 21 مرداد 1390-04:10 ب.ظ

HTML, the Foundation of the Web

by Niels Matthijs — Mar 3, 2008

HTML is hot again. Some time ago the HTML5 promo machine got up to speed, causing a little mini-fuss. In a parallel universe, others are still putting a lot of time and effort into the development of xHTML2. This (public) renewal of interest in HTML caused plenty of discussion, revealing several blank spots in the general knowledge of HTML. This article will hopefully plug one of the most notorious holes shut.

For many front-end developers, HTML remains mostly an excuse. It is viewed as a language of hooks, constructed for adding javascript, css and other enhancements to web documents. In recent events, this kick-started a small semantics debate again, where people were reminded about the semantic value of HTML. A reminder voiced by raging standardista, still fired up from previously fought debates and awareness battles.

HTML != Semantics

Everyone with a passion for front-end development will recognize the importance of the standardista when it comes to HTML awareness. Yet this doesn't mean that their methods should go totally uncriticized. With all the attention they raised for the semantic function of HTML, some people have started to see HTML as a purely semantic language. Which it is not.

Evidence of this can be seen in the "divitis" issue that followed the early rise of web standards. When front-end developers were urged to switch from table-based layouts to div-based layouts, some took the advice a bit too literally. They turned everything into divs, ignoring the semantic purpose of the elements at hand. This triggered an ever bigger reaction of the standardistas and led to demonization of the div element. Divitis was considered the AIDS of front-end development and using divs became almost taboo. Only when absolutely necessary were they allowed.

Enter Minimal HTML

The fear of purely structural elements (divs and spans) branched off a new movement. A group of people that didn't believe in the absolute need for structural elements and tried to build pages with purely semantic elements as much as possible. They banished extra divs when used for styling but forgot about the original function of the div and span along the way. In the end, they made HTML a poorer language than it was supposed to be.

two layouts, different by structure

Consider the following two basic page layouts. A simple layout consisting of four main areas. The context area gives contextual information on the main content area. A layout like this (not considering any graphical design enhancements) could easily be made with four divs. This is setup A, preferred by minimalists. Setup B shows a situation where the layout is build using five divs. Take a moment to think which setup you prefer, purely on a structural basis.

HTML = Semantics + Structure

HTML is more than just semantics, it's also about structuring your document. The main difference between both type of elements is that semantic elements explain the purpose of an element, while structural elements explain the relation of its content to the content of other elements within a document.

In setup A we have four separate divs, structurally all on the same level. This tells us all divs are related in the same way, only the order of appearance will indicate some sort of relationship. In setup B the main content and context area are grouped in a content div. This is an indication that the relation between context and main content is a lot stronger or at least different than the relation to the other element. And on the other hand, the content area shares a similar relation with header and footer.

Structurally, setup B not only holds more information about the relationship between the separate areas, it's also more correct. This makes it the better implementation of the two. The extra div used to group main content and context is not useless, but adds useful meaning to the document.

Enter Minimalitis

Minimalitis is the disease formed by the aversion of divitis, and is equally dangerous as divitis. People who suffer from minimalitis will write badly structured documents and will often incorrectly use (or simply abuse) elements to avoid the use of divs (often they use a p tag) and spans (em, strong and even the b tag are popular). Another sign is the merge of block and inline elements on the same level. While this is not exactly illegal, it's a serious warning of possible minimalitis and bad structuring.

And yet, the cure for this disease is simple. Reinstate the power of the div and span, but use it for its intended purpose. Use divs and spans to bring structure to your document. Contain elements that share a similar relationship within the same level. Use it to separate elements from others that share a different relationship. And use them together with a meaningful class or id whenever you don't have a valid semantic element to describe your content.

The Future of Structuring

Luckily, the people working on HTML5 have understood this and added a couple of extra structural elements to the language. Instead of leaving us with a simple div and span, two elements with a simple structural meaning, they added elements like footer, header, article, section and aside to help us better define structures in HTML documents.

The fun thing about these elements is that they not only hold structural meaning but also semantic meaning. Instead of simply structuring a document they hint at the relationship elements bear to other elements or the page in general. Tags like footer and header not only contain a section of a document, they also hint at the function of the contained elements and the relation to the other elements on the page.

Hopefully this will give the opportunity to those suffering from divitis or minimalitis to write better structured code while keeping the document as semantic as possible. Until then, just know that a div has more power than simply adding a rounded corner or border to the graphical design. Structural elements are there to reveal relations between elements, a sometimes forgotten power of HTML.

Personal Promo

Niels Matthijs spends his spare time combining the luxury life of having no kids and a wonderful girlfriend with the agonizing pressure of blogging under his Onderhond monicker. As a front-end developer he is raised and nurtured at Internet Architects, a Belgian company investing a lot of time in making the web a more accessible and more pleasant place.




Tomorrow's Web Design: Popular Design Software Challenge

نوشته شده توسط:ramin h
جمعه 21 مرداد 1390-04:09 ب.ظ

Tomorrow's Web Design: Popular Design Software Challenge

by David Rodriguez — Apr 18, 2008

Recently, I took up a project. A co-worker of mine created a fully standards-compliant XHTML website from the ground up titled HTML for Beginners, which will be released sometime soon. His code was hand-written and it's elegant and functional. On the homepage of the site, he used a three-column layout with a header and footer, and on the interior pages of the site he used a two-column layout. Here are screenshots (the look of the final site may change, hence no direct HTML links):

Original design; strict, valid XHTML; top-level page:

Original design; strict, valid XHTML; interior page:

My project was to take four programs: CoffeeCup Visual Site Designer, Microsoft Expression Web, Adobe Dreamweaver, and Microsoft Frontpage 2003 and attempt to recreate the two designs above. Here's the catch: I could only use the WYSIWYG (what you see is what you get) features of each program. I could not edit the code directly at all.

Why do this?

I went to this year's South by Southwest Interactive Festival and attended a panel there titled, "Does Tomorrow's World Need Designers?" The entire purpose behind the panel was to get some meta thinking going on. The focus and general idea was that in the (possibly near) future, individuals would have the tools to easily create and "design" unique visuals for all things — Websites, shoes, cars, you name it — without the need of a professional designer. It was even brought up that in a worst-case scenario, even artificial intelligence could get so advanced that it would "learn" design and create things like unique, appealing Websites on the fly.

I'm not so sure about that last part. But the part about the everyday Joe having the tools he needs to design his site without the skills and knowledge of a designer (that is to say, without knowing HTML, CSS, or having the trained eye of someone who has been working with the Web for years and has seen its trends) interested me. So, arming myself with a series of the most popular WYSIWYG editors, I set out to see how close to this reality we have come.

First up: Frontpage 2003

I went into this application knowing full well that this thing is old. Old though it may be, it's still in good circulation and still one of the most-used programs for butchering the Web with bloated code and table-based layouts building Websites.

Overall, building the design in WYSIWYG-only mode with Frontpage was a clunky pain in the rear. I was forced to draw table layout cells and "style" them with Microsoft Office-style tools, like, "Format Cell..." and "Cell Properties." It was pretty clunky is all I can say, and many times, the cells didn't want to stay where I put them. When you add a new layout cell, all the others try to guess where they're supposed to go in relation, leaving you to manually drag them back to their intended spots, or using the annoying eraser tool (which sometimes erases in the right spots, and sometimes doesn't) to erase borders and cells that the layout added on its own when you added your intended cell.

There were some things I simply couldn't do, like add the background image to the header, without manually coding. So the background had to stay out. In the end though, the product came out looking pretty neat in the designer:

Frontpage 2003, in the design view:

Unfortunately, though, in a Web browser, the design didn't look quite the same:

Frontpage 2003, top-level page, viewed in a real browser (Firefox 2):

The interior page design came pretty close, though:

Frontpage 2003, interior page, viewed in a real browser (Firefox 2):

Frontpage 2003 Pros:

  • Lots and lots of features
  • Decent help system

Frontpage 2003 Cons:

  • Way outdated software
  • Still prefers to use tables for layout
  • Lots of features, but most you will never use
  • The sheer number of features thrown at you can be overwhelming
  • Not newbie friendly
  • Not veteran friendly
  • Barely intermediate friendly
  • A page can look one way in the design view, but drastically different in production, and because the design view looks fine, how are you supposed to fix it?

And in this corner: Adobe Dreamweaver CS3! (Mac version)

I knew Frontpage would be a nightmare, which is why I decided to work with it first. I didn't really know what to expect with Dreamweaver. I'd heard good things; I'd heard bad things.

I have to say, it was a nice change of pace from Frontpage. Drawing a layout in a similar manner as I did in Frontpage was much easier, because I could actually use divs instead of tables for the layout. The easiest way to do it was to use the AP (absolutely positioned) divs rather than the normal divs, because to get the most out of a non-AP divs I'd have to do some manual coding.

Drawing the layout was a snap. I drew it up in matter of seconds, and it only took a few minutes to tweak it so the positions were nearly pixel-perfect. You can select a div and move it pixel-by-pixel with the arrow keys on your keyboard, so that was nice. I then filled each div with the content I wanted before I styled the divs.

This is where things got a little clunky. There are very few WYSIWYG tools for adding background colors, changing text (except the size and face), adding margins/padding, aligning a background image, etc. I searched for quite a while for ways to style my page without having to type my own CSS, but it was futile. Eventually I broke down and used the "CSS" button, which seemed to be the only way to style these divs to the point that they would be able to mimic the original design I was working on. The CSS button brought up a semi-intuitive dialogue that let me add some styling to the selected object, and when I was done, the style went over to the pane on the right side of the window.

It was in this little pane that I did almost all of my styling, using almost hand-coded CSS. I say "almost" because there are drop-down boxes that let you choose from a list of elements, like "body," "h1," "a," "a:hover," etc. Since I was not actually in the raw HTML file and typing my styles manually, I figured this was something that could "squeak by" as WYSIWYG. Though in reality, someone who didn't know CSS would have a hard time building an attractively modern site this way.

Having said that, I do think Dreamweaver CS3 is a great program in a professional sense. If I was not limited by this project to just the WYSIWYG mode and could actually use the code editor, I can see Dreamweaver being pretty useful to those who like professional applications for this sort of thing. (I still personally prefer a text editor and a local version of Apache/PHP/MySQL). Though, it is a little overly-technical; the wording for some of the options and the methods of styling they use could be more intuitive and streamlined.

In the end, this is what the site looked like in Dreamweaver's design view:

Dreamweaver CS3, top-level page, in designer view:

And here's what the end result looks like in a browser:

Dreamweaver CS3, top-level page, in a browser (Firefox 2):

Dreamweaver CS3, interior page, in a browser (Firefox 2):

Notice in the top-level page how Dreamweaver had a bit of trouble converting some of the symbols when text was pasted into it. All in all, though, the end result was pleasing and it came close to the original design. Unfortunately, though, I can't say that Dreamweaver CS3 is a tool to quickly-and-easily build a site if you have little knowledge of CSS.

Dreamweaver CS3 Pros:

  • Can do some advanced things with the visual editor if you know the CSS
  • Adding basic CSS properties to divs with a CSS button is fast on creation
  • Drawing a layout with AP divs is a good quick start

Dreamweaver CS3 Cons:

  • Not very newbie friendly
  • Minimal styling can be done without knowledge of CSS
  • Managing your styles and divs can be a pain once you've already created them
  • Many features and tools are in illogical places, forcing you to hunt around for them
  • You need to know HTML and CSS if you plan to just jump in and use the program; there are no tools for beginners

Ah, Expression Web. Let's see what you've got.

Microsoft's successor to the very dated Frontpage next took the stage. Here's how it went down.

I was presented with Expression Web's interface and, while there was definitely a lot going on there, it was organized pretty well. Just scanning the interface with my eyes, I almost immediately saw the <div> tag just sitting there on the right side of the window; in a neat little pane. Knowing that I needed five divs for the site, and seeing how much time I had to send tweaking the position and styles in Dreamweaver when I used absolutely-positioned divs, I double-clicked the <div> tag five times. Five divs were dropped into my design window, indicated by a small "div" tab and a dotted outline, one on top of the other in block format.

Inside each div I could type and edit text or add images/tables/lists/whatever, as if each div was its own little Word document, using all the familiar Microsoft Word tools. This made adding the divs and their contents easy. So in just a few minutes, I had five divs on my page in blocks, all filled with all their content in 12-point Times New Roman font. Now came the hard part: styling everything. If this was going to be anything like the other WYSIWYG programs I've used (see above), this would be an exercise in stumbling about aimlessly until I found what I needed.

Thankfully, Expression Web is not those other programs. I noticed a “New Style” link on the right side of Expression Web’s window. I clicked it. A dialogue popped up with a menu on the left side with the most commonly-used CSS modifications. Sections like “Box” for the box model (padding and margins), “Layout” for positioning and floating, “List” (for lists when you want to style them; I didn’t make much use of this but it made it easy to change the bullet type when I needed to, and I could see it being easy to create a floated-list navbar with this), and others like “Background,” “Font,” and so on. This dialogue was pretty intuitive, and as long as you know the basics of CSS, you can stumble around in it as an intermediate user and accomplish what you’re looking for. I was able to use this dialogue to assign backgrounds, margins and padding, floating, and positioning to all my divs, because there’s a neat little checkmark at the top of the dialogue that says “Apply to the selected page object.” So if you select an entire div, it gets the CSS. Select just a single word or li element, and only that gets the style. And I didn't have to hand-code a bit of it.

As I added styles to all my divs, they jumped around the page to fit in their proper places. Things (like the footer) that were set to “clear: both” (via the designer mode) jumped to the bottom of the page and filled the entire width of the window, as intended. Text that should wrap wrapped in all the right places; Expression Web handled it pretty well.

At this point, my page was essentially done. I just needed to make a few tweaks to the page. This is where things started to get a little more difficult. Intuitively, I would be able to select any of my divs or other elements within those divs and right-click it, then edit the CSS in the same dialogue I created it in. Instead, when you try something like this, Expression Web throws you into Split view, showing you the raw HTML/CSS of the page in a top pane and your design view in the bottom pane. This was jarring; I didn’t want to edit the code (that wasn’t the point of my project), I wanted to change the CSS in the designer.

It turns out there’s a “Manage Styles” pane on the right side that has a list of all the styles you’ve created. If you mouseover any element on your page, it tells you what style it is using. You then find that style in the Styles manager, right-click it, and then click Modify Style. I think “Edit Style” would have been better wording, and secondly, finding this feature was jarring. Everything had gone so smoothly up until that point.

In any case, using Modify Style brought up that same dialogue and making tweaks was simple enough. However, I needed to make several tweaks (I wanted to go back to some divs and add a bottom border; I also wanted to go back to a couple of the lists and apply custom bullet images; plus, I wanted to change the link colors in only one div). Making several tweaks was too time-consuming, because for each tweak, I had to mouseover the element I wanted to change, find out what style name Expression Web had given it, and then go into the Styles Manager, right-click the style, and click Modify Style, then click Apply/OK before the tweak was done. When you need to make several tweaks, this is not the most intuitive way.

After making all the necessary tweaks, the page came out almost exactly as I wanted it in the designer.

Expression Web, top-level page, in designer view:

And the results in a browser were good too.

Expression Web, top-level page, in a browser (Firefox 2):

Expression Web, interior page, in a browser (Firefox 2):

Expression Web pros:

  • If you know a little about HTML/CSS, you can jump right in.
  • Easy to get the layout of the page set up with several divs.
  • Great styles dialogue to help you style a whole page or just an individual object.
  • Just about everything was self-explanatory.
  • Easy to scan the program with your eye to find the tool you need.
  • Each div you create feels like a mini Word document, with all the familiar text formatting tools.
  • Easiest software for someone with a little knowledge of HTML/CSS to just pick up and run with.
  • Pages created in this software looked practically perfect in the major browsers I tested them in (IE7, Firefox 2, Safari, Webkit, Opera).
  • Of all the programs, Expression Web and Visual Site Designer came the closest to reproducing the subject page exactly. (More on VSD in a bit).

Expression Web cons:

  • Making minor tweaks is quick... if you want to make one minor tweak. You have to follow a series of steps to change some of the smallest things, and if you want to change a lot of little things it takes more time than it should.
  • The right-click menu is semi-useful in design view, but an "Edit Style" option would do wonders for this program, making it run smooth as silk instead of just "really well."
  • Great program; a bit of a steep price. Not good for complete beginners.

Truly WYSIWYG: Visual Site Designer

I've already stated it above: Expression Web and Visual Site Designer came the closest to exactly reproducing the subject page exactly. But how does Visual Site Designer perform?

If I may express the answer in one word: "really well." (Okay, two words.) Upon opening the program, I'm presented with three options: New Website, Open Website, and Use Template. Tempted as I was to browse the templates, this was not my goal. I clicked New Website, and I got a small dialogue asking me for the basics of my design. Title, height, width, background color, and link/visited link colors. After filling out these settings, I clicked OK and the designer view popped up. A blank white screen with tools on the left side and along the top of the window.

It only took a quick moment to familiarize myself with the tools that were there, and it was easy to tell what each tool did at a glance thanks for the colorful icons. Any tools that weren't labeled directly (like the Page, Fill, Effects, Link, and Styles tools) had mouseover tooltips and a handy dialogue explaining what they do when you use them the first few times that you can disable via a "do not display this dialogue next time" checkbox.

There were no divs, no HTML tags, no CSS styles; the entire designer is truly WYSIWYG. Creating the layout of my page was braindead simple: pick the rectangle shape tool, give it a color, draw. I drew the header, sidebars, and footer in a matter of seconds, and was able to adjust their shapes, colors, and sizes in the object window. The object window was a neat little feature; it floats as a separate little window, and it changes to depict the settings of whatever tool you have selected. This way, you never have to look around for your tool settings; they're always in the object window so you always know where to look.

After drawing the layout of the page, it was time to add the text. Clicking the text tool changed the object window to let me change the font family and size, and I could see that there were other options that would let me do things like add drop shadows or even rotate text if I wanted to. Unfortunately, this design did not call for these fun-looking features so I had to dismiss them for now and just type normal, colored text.

When I clicked on my page with the text tool, a red text box popped up with a little handle on top that I could use to drag it, and left/right arrows on either side of the box so I could widen/shrink it. I stretched the box to a decent size and typed in the content, then highlighted the text and formatted it with the correct colors/sizes in the object window. Repeating this process for each section of my page, I was done with the page content in minutes.

Similarly, dropping in images was a breeze. Click the image tool, browse for the image, click OK. Now you can freely drag it anywhere on your page. Again, in the object tool, I saw more features than I required, like adding a glow/shadow or shaping the image (rounded corners, pentagon, circle, etc.), but again my design did not call for this so I had to play with those later.

By the time I had my page laid out the whole thing was 95% done, I had lots of objects on the page. Sidebars, a header, a footer, a background image for the header, a few textboxes, a couple of images... none of these by themselves was any problem at all to create. However, when I needed to go back and change something, I found myself having to watch carefully where I clicked my mouse. There's no way to "lock" objects in place in Visual Site Designer, so when I wanted to select the text in a sidebar, for example, I had to be careful to select the text instead of the sidebar, or else I might end up dragging the sidebar accidentally or worse, changing some of its attributes. This was not a major flaw, because there is a multi-step Undo in case you accidentally do something like this, but the entire operation in Visual Site Designer seemed designed to be fast and smooth, and for the most part, it was; but this little bit of technicality hindered the "carefree smooth design" feeling I got when using the software.

A really big time-saving feature in Visual Site Designer was its "copy page" function. When you click the "Add Page" button to create a second page (which I needed to do for the interior design), I was given the option to copy an existing page. I copied the homepage, and it created an exact replica of the page I had just created. Now, all I had to do was adjust the left sidebar and remove the sidebar on the right, then change the content and I was done with the second page. If I wanted to create more pages, I would definitely be using the copy page function to keep my design intact and keep all pages uniform.

I never once had to type a line of HTML or CSS to do this. In fact, I couldn't: Visual Site Designer is completely WYSIWYG; you don't get direct access to the page's HTML/CSS. Visual Site Designer handles it all for you in the background. However, this is not to say that if you want to use HTML you can't; Visual Site Designer has an HTML Tool that will let you insert an HTML object. Basically, this creates a div of any size/shape/position you want, and you can insert hand-written HTML, CSS, Javascripts, whatever. Unfortunately, for the sake of this project, I could not use that.

So, in the end, here's what the page looked like in Visual Site Designer:

Visual Site Designer, top-level page, in design view:

And in a browser, the designs look pretty close to the original page.

Visual Site Designer, top-level page, in a browser (Firefox 2):

Visual Site Designer, interior page, in a browser (Firefox 2):

Visual Site Designer pros:

  • Really cost-effective. A mere $49.00 USD, compared to $399 (Dreamweaver), $299 (Expression Web) or $129 (Frontpage, through Amazon.com).
  • Really easy to use.
  • Of all the programs, Visual Site Designer and Expression Web came the closest to reproducing the page exactly.
  • Truly WYSIWYG; no need to know HTML or CSS. Extremely beginner friendly.
  • Fastest of all the Web editors to complete the job.
  • Built-in one-click upload.
  • Manages all your files for you.
  • All the tools feel unified; they share the same properties window so you always know where to look to change settings.
  • Many shapes to choose from, and placeable guides with X Y coordinates make it easy to design a layout.
  • Creating new pages for your site while keeping the same layout is easy; just create a new page, and select the "copy page" function to copy an already-existing page and just change the content.

Visual Site Designer cons:

  • No code view; you can't edit the HTML directly (however, there is an HTML Tool that will let you use advanced HTML and scripts on your page in an object-based manner).
  • Cannot edit pages that already exist. VSD can only create new sites, or edit sites it created.
  • Click carefully; you don't want to accidentally move some of your page elements if you have multiple stacked on top of each other. This isn't a major flaw because you can always Undo, but if you're in a hurry you could accidentally select an object you don't want selected.

So, does tomorrow's world need designers?

Heck yes. In a nutshell, I wouldn't recommend Frontpage 2003 to anybody for any purpose, to be perfectly honest. Dreamweaver CS3, though, could be a good application for serious web development for those who already know the technical side of things, and I really think it could be good for web developers in a professional environment, but because of its high "techy-ness," it's definitely not a tool that could let the average Joe create a "Web 2.0" site.

Expression Web and Visual Site Designer, though, are steps in the right direction if providing easy-to-use WYSIWYG tools is the future of Web design. In a reality check, though, in most of these programs, I could not have created anything near the designs I did above if I wasn't already familiar with Web design. If I was to challenge the average Joe with the project above (to exactly copy an already-existing design from scratch), he'd have to sit down and do some research first, and I imagine it's reasonable to think it would take him days to accomplish the task.

The only exception is Visual Site Designer, in which you can basically just draw your page. But even with software this intuitive and quick-to-master, the tools are no replacement for knowledge and skill in the field of design.

Expression Web and Visual Site Designer are both Grade A tools, but professional and even hobbyist Web designers are a long way off from being replaced by such tools, though beginners, intermediates, and veterans can find something to like in both of those programs.

The ominous, impending uprising of maniacal artificial intelligence that designs Websites, on the other hand, may be something to worry about...




Simple CSS: Creating More Readable Text

نوشته شده توسط:ramin h
جمعه 21 مرداد 1390-04:09 ب.ظ

Simple CSS: Creating More Readable Text

by David Rodriguez — Apr 21, 2008

Typography is an important part of Web design. Just like in the print world, your content needs to be readable to your viewers for it to be of any use. As a general rule, you want to make sure your Web site provides as little resistance as possible to the user, and the easier your site is to read, the better. CSS provides three very useful properties to enhance the readability of your site: font, line-height, and letter-spacing.

A sample page

Let's begin with a small sample Webpage. You can view it here. This page uses a small, pretty standard design with some low-key colors to help emphasize the content. This is a good use of design and color if your site fits in the "content is king" category (and most sites do), especially if your content consists of articles or other long blocks of text, like a blog.

The thing to notice here is that the text does its job: it communicates a message and the user can walk away having consumed your content. But the text is the same across the whole page, with the exception of a color change in the small subheading below the header text and the positioning of it. Here's the CSS that's being used in the sample page.

body {
	text-align: center;
	margin: 0;
	padding: 0;
	background-color: #363942;
	color: #382513;
}

#container {
	margin: 15px auto;
	text-align: left;
	background-color: #D8CAA8;
	border: 1px solid #4B1E18;
	padding: 0px;
	width: 850px;
}

#header {
	height: 80px;
	border-bottom: 1px solid #284907;
	margin-bottom: 15px;
	padding: 15px;
}

#header h1 {
	position: relative;
	vertical-align: center;
	color: #382513;
	margin-bottom: -10px;
}

.subheading {
	color: #284907;
}

#sidebar {
	border-left: 1px solid #8FB65F;
	margin: 0 0 15px 15px;
	padding: 0px 15px 15px 15px;
	float: right;
	width: 175px;
}

#content {
	padding: 0 15px;
}

#footer {
	clear: both;
	border-top: 1px solid #284907;
	padding: 15px;
	margin-top: 15px;
}

Choosing your fonts

To improve readability, we'll want to choose a font that looks good with the colors you've chosen and at the size you plan on making your text. Typically, a non-serif font is advisable for the main content, while headers benefit from the added noticeability of serif fonts. If you come from a print background, this may sound backward. Usually, in the print world, serifs are preferred for blocks of text because the serifs help the eye distinguish each line. However, modern operating systems have options to smooth the edges of screen fonts automatically, so non-serif fonts come out looking better as main content and serif fonts look good in small doses.

With this in mind, I'm going to use one of my favorite lines when it comes to CSS and fonts:

font-family: Arial, Helvetica, sans-serif;

These fonts are some of the safest you can use in your design, and if cross-browser compatibility is a concern, memorize them. They're good to use on their own, or you can use them as a starting point for your non-serif text. In this case, for simplicity's sake, I'm going to stick with just these three for the content. The body section of the CSS now looks like this:

body {
	font-family: Arial, Helvetica, sans-serif;
	text-align: center;
	margin: 0;
	padding: 0;
	background-color: #363942;
	color: #382513;
}

And with that small change, the overall readability of the page has changed slightly for the better: see for yourself.

The slight change is good, but all of the font is still the same family and this creates a bad sort of uniformity. We want some distinction going on here, so let's set our headings and subheading apart from the rest of the content. We'll ignore the h1 at the very top for a bit, since we'll want to do something a little different with that in a second.

For the subheading and the heading in the content, I'll be using a serif font. Just like above, this next line is probably one of my favorites:

font-family: Georgia, "Times New Roman", Times, serif;

Again, these are some of the safest fonts you can use in Web Design, even if it's just for a starting point and you plan to expand your typography a bit later. Reserve this line for headers and other places where it would look good in small doses; the eye has a tougher time reading serif fonts on a screen than non-serif fonts so whole blocks of serif text can be jarring.

So now, our subheading class looks like this:

.subheading {
	color: #284907;
	font-family: Georgia, "Times New Roman", Times, serif;
}

And we need to create a new rule for h2 tags in the content section. We do so like this:

#content h2 {
	font-family: Georgia, "Times New Roman", Times, serif;
}

Alright, now the header information is more separated from the content, which is good. Take a look here.

Now, what about that h1 header we have at the top of the page? We're going to make it larger and give it less contrast to its background. This is so that users will know what site they're on, but won't be distracted by the header.

We'll do this with this code:

color: #6B5846;
font-size: 48px;

And the full header h1 rule now reads:

#header h1 {
	position: relative;
	vertical-align: center;
	color: #6B5846;
	margin-bottom: -10px;
	font-size: 48px;
}

You can view the modified header here.

Now we turn our attention toward the sidebar and footer. The text in the these places is the same as the body text in main content area. The sidebar and footer typically play secondary roles, so we'll give them smaller text and a different font family with a single font rule:

font: 12px Verdana;

Now, our sidebar and footer divs have the following CSS:

#footer {
	clear: both;
	border-top: 1px solid #284907;
	padding: 15px;
	font: 12px Verdana;
	margin-top: 15px;
}

#sidebar {
	border-left: 1px solid #8FB65F;
	margin: 0 0 15px 15px;
	padding: 0px 15px 15px 15px;
	float: right;
	width: 175px;
	font: 12px Verdana;
	color: #5A4735;
}

Right now, the content text feels a bit overwhelming. We'll reduce its size with this:

font-size: 15px;

And we'll put it in the content rule, so now it reads:

#content {
	padding: 0 15px;
	font-size: 15px;
}

And now we have our fifth iteration of the CMRT page. We've taken some good steps in making sure the different sections of our site each have their own look and feel while still feeling unified. Now, we can take it a step further with the line-height property.

line-height — Be good to your visitors!

Your visitors are there to see whatever content you have up on your site. They've come to see you and they're your guests! Treat them well. You don't want to strain their eyes when they view your page. Use line-height to make your text more readable. Adding more line height to your text increases the amount of space between each line, and it helps the eye make that jump as it moves down your content.

We'll give the content div a line height of 160%, which basically gives it 60% more line height than it normally has, based on font size. This is a decent amount of line height and gives the text some room to breathe. For the sidebar, since the text is smaller, we'll only give it a line height of 140%. So, now our content and sidebar CSS are as follows:

#content {
	padding: 0 15px;
	font-size: 15px;
	line-height: 160%;
}
	
#sidebar {
	border-left: 1px solid #8FB65F;
	margin: 0 0 15px 15px;
	padding: 0px 15px 15px 15px;
	float: right;
	width: 175px;
	font: 12px Verdana;
	line-height: 140%;
	color: #5A4735;
}

And with this, the text takes on a much more pleasant look. See here. The eyes don't have to work as hard to read the text now, so it's easier for your visitors to consume your content.

Adjusting letter spacing

There are only a couple of places where letter spacing comes into play with this page, but it too can play a part in increasing your site's readability and help make each element on the page more distinct. Headers and headings are usually good candidates for letter spacing. From a design point of view, you can use letter spacing on your header text to add some improved visuals to your page, like we're going to do in the header div with this:

letter-spacing: 20px;

This increases the space between the letters of your text by 20px. 20px is a big number for ordinary text, but for the header at the top of the page, which is just 4 letters, it helps it stretch to be just about as wide as the subheading beneath it, giving it more of a header feel.

For the headings (the h2 tags) in the content of the page, we're going to increase the letter spacing by just 2px. This will lend the headings a more prominent feel and separate them further from the text, and the adjustment is minor enough that it will not distract from reading:

letter-spacing: 2px;

So our header's h1 CSS and our content's h2 CSS now look like this:

#header h1 {
	position: relative;
	vertical-align: center;
	color: #6B5846;
	margin-bottom: -10px;
	font-size: 48px;
	letter-spacing: 20px;
}

#content h2 {
	font-family: Georgia, "Times New Roman", Times, serif;
	letter-spacing: 2px;
}

You can see what it all looks like when done right here.

Expanding on this CSS

There are a lot of different ways you can apply these properties, too. For the design of the page I purposely used a simple, rather unintuitive design so I could focus on the text as it changed during the above steps, but applying this kind of CSS to a much more vibrant and elegant design can drastically improve its effect on your visitors. I don't intend to "pretty up" the CMRT sample page, and if I do, it will be for a totally separate article, but if you'd like to take a crack at making it look prettier while preserving the font and text adjustments, hit me up and we'll talk about it.

Stay tuned for more of the Simple CSS series!




Don't Be Afraid of Serif Fonts

نوشته شده توسط:ramin h
جمعه 21 مرداد 1390-04:08 ب.ظ

Don't Be Afraid of Serif Fonts

by David Rodriguez — Apr 28, 2008

As the practice of Web design ages, some common rules and "best practices" inevitably embed themselves in the craft. Among these are the processes for using specific types of semantics when coding your site, like using divs as hooks in your X/HTML for your CSS, and making your page beautiful and functional that way. Another is to ensure readability of your site by choosing a proper number of fonts (generally, no more than three or four, and for the minimalist, one or two). More important than that is the type of font you choose.

Typography in your Web design is undoubtedly important. For some time now, it's been taught and practiced that using a sans-serif font is the best choice for page content and large blocks of text in Web design, while serif fonts should be reserved for use in small doses or as the style of choice for your headings. WPDFD even has a very recent article that states this. Some other places you can find this teaching:

  • About.com
  • Urban Fonts
  • Web Design Reference

In a nutshell, here are some of the key points in using sans-serif fonts.

  • Sans-serif fonts look good at most sizes.
  • They tend to have a more contemporary or business feel.
  • Most operating systems render them neatly.
  • Serif fonts tend to lose readability at smaller sizes.
  • Serif fonts, when viewed on a Windows computer, may look terrible. This is because Windows has a ClearType ability that smoothes the edges of screen fonts, which would make the serif fonts look good, but many Windows computers don't have this option turned on by default.
  • Sans-serif fonts, on the other hand, can look good with or without Windows' ClearType turned on.

Overall, designing with sans-serif fonts for your main content is a good general typography rule for your Web design. Many often-visited sites use sans-serif fonts for viewing on the web, and it certainly works well for them. Google is an obvious example. Also, Microsoft and Yahoo follow this convention. Especially prominent sites in our own field, like A List Apart use it to very good effect. And if you'll take a quick look around, you'll notice WPDFD sticks mainly to sans-serif fonts, as well.

But. (You knew that was coming, didn't you?)

I fired up my RSS reader recently and came across a fairly attractive page with an entry about designing with type characters. This particular page doesn't touch directly on using serifs in Web design, but I found it easy to read.

It was also fairly refreshing. Seeing so many sans-serif fonts used in only so many ways on the Web isn't exactly tiresome, but it certainly does lend a certain charm to serif fonts when you seem them executed well in Web design.

That same page above also has links to a few other pages that use serif fonts well. For your convenience, I'll link them here, too, and include my thoughts:

  • Twisted Intellect
    I like this page. It reads well and it's a very elegant design. The typography here is very nice.
  • The 3rd SEED Conference
    While Twisted Intellect uses serif fonts, it doesn't use them for lots of content. The 3rd SEED Conference does exactly the opposite: the entire design is serif fonts; no images. It's just layout, placement, and typography. This is executed beautifully and I really like what's been done here.

There are some other sites I've come across while just browsing leisurely, too, that caught my eye with their use of serifs.

  • Jens Meiert: Why Reset Style Sheets are Bad
    This is a good-looking, minimalistic blog that uses serif fonts to good effect. And hey, the page even touches on an interesting topic.
  • Fun With Fonts
    This is not only a cute short story about a robot; it's also a good use of typography. The serif font here accomplishes its job very well.

The examples of good-looking pages above were all delightful to look at and to read. As opposed to sans-serif fonts, it seems that serif fonts do take a bit more skill for a Web designer to wield effectively, but the payoffs can be quite impressive.

Things to keep in mind

From what I can see, there are numerous advantages and disadvantages to using a serif font.

Benefits of using a serif font:

  • Thanks to the vast majority of web sites using sans-serif fonts, using a serif font can lend your page a refreshing, personal, warmer, and more visually attractive appeal. Any or all of these effects can be accomplished with the right styling.
  • A page using serif fonts is different, and helps you stand out.
  • Serif fonts tend to give a web designer more to "work with." Their shapes can range from rigid and stoic to elegant and understated.
  • I think serif fonts benefit more from color and experimenting with color, though this is just personal opinion on this one.

Things to watch out for when designing with serif fonts:

  • This is one of the biggest points against using a serif font, so pay close attention: Serif fonts, especially when italicized, usually look terrible in Windows! The ClearType preference must be turned on for the fonts to look nice, and many Windows users do not know where to turn ClearType on or what ClearType even is.
  • Serif fonts lose readability at smaller font sizes. A medium to large font size works best.
  • See here for an example of how serifs can break down and make the eye struggle at too small a size.
  • Serif fonts tend not to have a "business" feel about them, so it's probably still best to avoid them when designing a commercial site. They lend themselves better to "personal" or "informative" content.

When you really look at the points against serif fonts, though, you can see that generally they break down into two main problems: readability in Windows and text size concerns. Both of these problems aren't as big a trouble as you might think.

For one, Internet Explorer 7, while not the best browser around, uses its own ClearType rendering, whether or not ClearType is turned on in a user's Windows settings. Most Windows users still use Internet Explorer to browse, so serifs for these users will seamlessly look as you, the designer, intend them. The widespread use of Internet Explorer 7 alone significantly reduces the concern for how serif fonts will look in Windows.

Secondly, if a user does use Firefox or another browser in Windows, your concern for how your serifs will look can drop a bit more. It's safe to think that most (or at least some) users who have another browser installed also have enough knowledge of Windows preferences that they'll have ClearType turned on, or have the knowledge of how to do so.

As far as text size is concerned: that's totally up to you. This is a non-concern as far as many Web designers consider it, since you are the designer and can choose to use a decent-sized serif font. This leads to a third point against serifs that is focused more on you than on technicality: serifs are a bit tougher to use in Web design than sans-serifs.

That's not a terribly large issue, though, because it's one that you can get around with your design. In fact, as is the case with the sites I've listed above, it may not even be something to "get around," but instead an intentional tool to work with in your design.

Keeping the "design" in Web design

I would like to see more modern Web designs using serif fonts for their content. They look really nice when used well, and it's a scary thought to think that we may be running into design clichés with the whole sans-serif-for-content "rule." The Web is a great canvas, and I hope designers can continue to do great and beautiful things with it, especially when those beautiful things step outside the lines and manage to remain functional.




Showcase Your Design!

نوشته شده توسط:ramin h
جمعه 21 مرداد 1390-04:08 ب.ظ

Showcase Your Design!

by David Rodriguez — Apr 30, 2008

Do you have a good Web design? I'd love to see it.

As part of an upcoming article for WPDFD, I'm going to showcase and discuss some good-looking, functional, and well-coded designs. If your design can match any of these three primary descriptors, a screenshot of your design and a link to your site might make it into the article.

Just drop me a line at drodriguez@wpdfd.com with links to any of your designs that you think should make it. I'm not yet sure how many designs I will be displaying in the article, but if the article is well-received and readers seem to enjoy it, I'll probably do more articles like it later. So, even if you don't make it into the first article there's a chance you'll make it into a later one.

In addition, the best designs have a good chance of ending up on our Featured Designs page. Sweet!

Feel free to submit your design by e-mailing me directly.

For your design to make it into the first article, please submit it before Wednesday, May 7, 2008. Don't worry if you can't make it by that time, though; you can still submit your design after May 7. Hopefully, if there are more articles like this later, you'll have a chance at getting into one of those, and there's always a chance at ending up in the Featured Designs.

Here's looking forward to seeing all your beautiful works!





  • تعداد صفحات :15
  • 1  
  • 2  
  • 3  
  • 4  
  • 5  
  • 6  
  • 7  
  • ...  
The theme being used is MihanBlog created by ThemeBox
شبکه اجتماعی فارسی کلوب | Buy Website Traffic | Buy Targeted Website Traffic