Infinite Loop
Web Design Priorities

When working on any web project big or small there are a number of factors you need to consider carefully. I am referring to web design specific priorities not general project priorities like time, money, resources etc.. This is rough list of the main ones I think through before starting any project. In an ideal world we would try to give them all top priority but in reality this can rarely be done, often achieving one will mean compromising on another.
 

Functionality
The site (or App) needs to do the things required of it. Most times this has the highest priority but sometimes there are lesser functions that are nice-to-have.

Design/Graphics
The site needs to be aesthetically pleasing. Sometimes this is important enough to trump usability or even functionality. Design is usually the number one culprit for reducing other priorities in this list. As a web designer gains experience and as browsers support fancier code this becomes easier. Sometimes design can be too low of a priority. I can’t tell you how many boring back-end web services I have seen where the lack of design ends up eroding the usability. 

Usability
The site needs to be easy and intuitive for people to use. Other priorities often reduce usability more than we would like, usually design. Web designer can over time get a feel for decent usability but absolutely nothing beats real user testing.

Accessibility
There is almost no situation where a web designer will know the exact skill-set of all users and exact software/hardware used to view a site now and into the future. Therefore you should build for as broad a range of users as possible. 
Accessibility falls under four broad categories:

  • Users: The technical skill, age, gender, cultural background, physical and mental abilities of your users can all impact the site design. From element size to colour, text, images, sound and video, all these things can make your site more or less accessible to certain user groups.
  • Software: What browser is the site being viewed in, what plugins do they have Flash, JavaScript? It is virtually impossible to support all browsers, you need to make a call on what percentage of users will not be supported. Using Progressive Enhancement is the preferred method of catering to both old and new technologies while enabling content/function to the widest possible base.
  • Hardware: Is the site being viewed on a PC with a huge monitor, laptop, tablet, mobile? Do they have fast, slow or even persistent internet speed? Sites should always be as fast to load as possible, load only parts that the user wants as they need them where possible. The technique of Responsive Design is quickly becoming the preferred method of supporting varying devices and screen sizes. 
  • Search Engine Optimisation: While not technically a facet of Accessibility, if no one can find your site it will not be accessible to many people at all. The layout, content and code of site may be impacted by SEO depending on its priority.

Maintenance
Even if a site perfectly meets user and client needs it may be a nightmare to maintain. Depending on the skills and tools available to those maintaining and building the site priorities may be compromised to achieve a site that can be maintained sufficiently. Code, files and names should all be as clean, neat, concise, valid, logical and Semantically Correct as possible.
 

At the end of the day all web site design involves compromises. It the the job of a good web designer to choose and win the right battles.

I remember sometime back around 2001 when I discovered CSS Zen Garden, it changed the way I saw the web forever. A site who’s style could drastically change with no change of HTML, at the time it was a revolution! CSS 1k is a similar project in which the CSS file can be no larger than 1k. Pretty impressive.

Clinically what I do is “Allow people to interact with Machines”, in essence what I do is “Design experiences”. The truth is somewhere in between.
Great and inspiring article.. 

Is the most advanced tool the right one for the job?

I recently had a colleague advise me to use SASS rather than plain old CSS. I have seen it around for a while but until now it never really grabbed me. SASS and its newer variant SCSS is a metalanguage for CSS which lets you add programming style variables and functions to CSS. This is a really brilliant idea, by allowing you to add object-oriented type mechanisms to CSS you could in theory build far more complex CSS in fewer lines of code and maintain it with less difficulty.

Sounds great so far, so what could possibly be the drawbacks? Firstly you need to install a Ruby compiler to get the .scss/.sass extension to work. Not to difficult.

Secondly .scss files compile into .css, so I imagine that if anyone edited the raw CSS, you would have versioning issues when going back to the SASS. This could be an issue in an team where separate developers have access to the same files especially if some don’t know anything about SASS.

Lastly it is only really more efficient if you are already familiar with the advanced programming concepts which it offers. If team members have varying degrees of coding expertise, moving to a more advanced language may add another hurdle to maintenance.

So I will do a little more investigation before I jump on board the CSS framework bandwagon. Ohh, I just discovered LESS and XCSS, looks like a late night for me.

Fonts on the Web

I was asked recently to explain in non-technical terms what the best font options for the web were. To make a choice you need to understand at least a little about how each option works. Here is my summary of each method and my personal preference for choice.

Preference 1:  Web Safe fonts
These are the very basic fonts that have been used on the web since the internet was born. They are basically a list of fonts that everyone will have. (ie. both Windows and Mac users) The best list of these I have found is here: http://www.ampsoft.net/webdesign-l/WindowsMacFonts.html

  • Pros: No limitations on using these fonts. No download required by the user. Works on all devices and systems. 
  • Cons: Very limited font options. May look pixelated at larger sizes.


Preference 2:  @font-face free Web fonts
This type of font is an asset of the site you are visiting. The user downloads it and as long as you comply with any legal restrictions they can be used on any site. You can find many at www.fontsquirrel.com or do a google search for “free font face fonts

  • Pros: Once downloaded the font can be used anywhere on the site with no restrictions.
  • Cons: A limited but now growing range. May not be available for specific fonts. User must download each font when they first see the site (styles like bold or italic count as a separate font).


Preference 3:  Externally hosted fonts
Fonts hosted externally and pulled into your site. Free ones can be found at www.google.com/webfonts or for purchase on https://typekit.com or webfonts.fonts.com. I would consider Google or Tylekit as good a method as Preference 2.

  • Pros: Once downloaded and/or purchased the font can be used anywhere on the site with no restrictions. A slightly larger range.
  • Cons: User must download each font from an external site and the font change is dependant on that site. May require a one-off or monthly fee.


Preference 4:  Embed fonts using another method such as Cufón or Flash
Cufón is a font embed method that uses JavaScript to convert your fonts into a vector graphic. Flash font replacement replaces the text with a Flash object. Given the font in these methods is not openly included on the site you should be able to embed any font this way, however it is definitely legal grey area so be careful.

  • Pros: Can use any font (depending on legal issues).
  • Cons: Non standard compliant, Can’t select or copy text (with Flash you can if you set it right), JavaScript must be enabled and the Flash plugin for flash (wont work on Apple devices iPhones/iPads). Can have issues with text wrapping.

Preference 5:  Render fonts as images
Convert the font into a picture.

  • Pros: No restrictions on fonts. Looks pixel perfect every time.
  • Cons: Text is not accessible or scalable in any way. It cannot be read by search engines without Alt text. Cannot be dynamic and is time consuming to change.
The Interchangeableness of HTML tags

Recently a colleague asked me what difference between the <div> and <span> tag was, which got me thinking that in fact most HTML tags are only technically different due to the default CSS values applied to them. Of course there’s the semantic and logical way we are supposed to use them, but in theory you could build a web page entirely out of any single tag.

You can turn a <div>  into a <span> by giving it the CSS property display=”inline” and a <span> into <div> with display=”block”. With the right CSS you can turn a <ul> into a <table> and a <optgroup> into an <acronym> if you really wanted to.

So, how far can you take this? Say you wanted to make a web page about Kebab scented perfume, well you could do that using only (the now depreciated) <b> tag. This is how you would do it:

Here is the HTML:

    <b id="wrapper">
        <b id="header">
            <b class="logo"></b>
            <b class="h1">Eau de Kebab - Anthy.P</b>
        </b>
        <b id="main">
            <b class="segment lamb">
                <b class="img"></b>
                <b class="text">
                    <b class="h2">Eau • de • Lamb</b>
                    <b class="p">Only the finest shish makes it in to this premium scent. 
                    The pure essence of a thousand lambs combined with dripping sauce, 
                    succulent pita, lettuce and a little tomato.</b>
                </b>
            </b>
            <b class="segment chicken">
                <b class="img"></b>
                <b class="text">
                    <b class="h2">Eau • de • Chicken</b>
                    <b class="p">In this our second most popular scent, we capture the 
                    divine essence of Chicken Kebab and bottle it. No other perfumery in 
                    the world would be so bold.</b>
                </b>
            </b>
            <b class="segment falefel">
                <b class="img"></b>
                <b class="text">
                    <b class="h2">Eau • de • Falafel</b>
                    <b class="p">Coming soon...</b>
                </b>
            </b>
        </b>
    </b>

and the CSS:

    	  
    html, body { margin:0; padding:0; width:100%; height:100%; }
    b { margin:0; padding:0; display:block; font-weight:normal; font-family:serif; }
    #wrapper { height:100%; background:url(images/eaudekebab_background.jpg) repeat; }
    #header { min-height:170px; position:relative; z-index:0; }
    #header .logo { position:absolute; top:-40px; left:-80px; width:279px; height:509px;  background:url(images/greyscale_anthony.png); opacity:0.4; z-index:1; }
    #header .h1 { float:right; color:#FFF; font-family:"LTZapfino Two"; font-size:86px;  line-height:1.3em; margin:0 20px 0 0; z-index:2; }
    #main { margin-left:98px; z-index:10; }
    #main .segment { width:202px; min-height:370px; float:left; margin:0 30px 15px 0; position:relative; background:#030504 url(images/eaudekebab_gradient.jpg) repeat-x; border-radius:10px; border:solid 1px #FFF; }
    #main .segment .img { position:absolute; background-repeat:no-repeat; }
    #main .segment .text { padding:195px 15px 0; color:#FFF; }
    #main .segment .text .h2 { font-family:"MrsEavesBold"; font-size:21px; margin-bottom:0.4em; }
    #main .segment .text .p { font-size:16px; line-height:1.1em; }
    #main .segment.lamb .img { top:-70px; right:-24px; width:133px; height:253px; background-image:url(images/eaudekebab_bottle1.png); }
    #main .segment.chicken .img { top:-70px; right:-36px; width:173px; height:253px; background-image:url(images/eaudekebab_bottle2.png); }
    #main .segment.falefel .img { top:-55px; right:-17px; width:133px; height:253px; background-image:url(images/eaudekebab_bottle3.png); }

and here is a screenshot of the final web page:

Nice!

Came across this fantastic article about writing succinct JavaScript. Certainly some eye openers there. “undefined == null” and “forename = forename || 'Bob';”, amazing! But not too sure if I would go all the way with some of them. While var b = {}; is definitely shorter than var b = new Object(); I am not sure that it is more human readable. Great article though.

This is a great Boagword article about the possibility of using responsive design to solve issues of ‘the fold’. I personally get annoyed when people talk about the fold on a web page… bottom of the screen for which user? browsing on which device? But I do agree that things higher up on the page get more attention. So imagine a world where you could use the same techniques used to change the layout of a page from desktop to mobile to move things up or down depending on where the bottom of the screen actually falls. Very interesting.

http://boagworld.com/technology/are-media-queries-the-answer-to-the-fold

Nice site I stumbled upon offering free Photoshop templates for standard user interface objects, like buttons, sliders, check-boxes etc.. really nice looking ones too.

http://freeuikits.com

The right “Case”

While at work I am often supplied with All caps text to use as headings and important messages. I always make sure to change it to Sentence case before inserting into HTML.

Not only is all caps semantically incorrect it is the least flexible in terms of CSS styling. Changing the case of any text can be easily be done visibly using the CSS text-transform property, changing to Upper case, Lower case and Title case. or even using font-variant to change it to Small caps. However no CSS rule can change it back to Sentence case if the text is not originally in that format.

Accessibility best practice also states that text should always be clear and readable out of context and without styling. As I understand it many screen readers will read All caps text as an acronym, which would be very annoying.

Word has a feature to easily switch between cases and there are handy several online tools too.