gia vang hom nay , seo uy tin , bao ve viet nam , cong ty bao ve viet nam , dich vu bao ve viet nam , thoi trang viet nam , thoi trang viet nam , tin tuc moi viet nam , tin moi viet nam , chia se mon ngon , phim viet nam , ung dung game , tin giai tri , tin cong nghe , khach san da lat , anh showbiz , my pham trang da , bao da ipad , op lung iphone , bao ipad , tap chi sao , kem duong da , may tinh bang , samsung , dien thoai sky , iphone , smartphone gia re , phim club , bao cong nghe , ipad , iphone 5s , thoi trang , tai game mobile , game mobile , meo vat , me va be , OpenCart Themes , thoi trang tre em

tactile

- thoughts on CSS, UIs and UX.

Progressive enhancement by adding classes

Posted: December 12th, 2012 Author:

Progressive enhancement is a Front-end Development practice that ensures your clients can still operate a webpage without (for instance) JavaScript support.
JS-driven widgets typically have styling applied, so it’s important to only add those styles if JavaScript is supported. One of the better ways to do this is by adding the relevant classes via JavaScript, but leaving the control of these classes in the HTML. Let me explain…

Read the rest of this entry »

A checklist for common front-end needs

Posted: December 11th, 2012 Author:

After building the front-end on a number of web apps, I’ve noticed there are a number of common functions or helpers each web app needs for Front-end development purposes.

Some tasks are trivial to solve, by virtue of being included in some web app frameworks, others are repeat offenders that you find yourself building for each and every web app.

App-wide needs

The web app should set a default language code

<html lang="en">

This acts as the basis for an i18n setup. It’s also good to set defaults.

The <title> element should include a basic information hierarchy

<title>Page name or title [| Section name] | site name</title>

This is more meaningful and allows for better history backtracking. It’s also better for SEO.

The core CSS file should be included on every page

<link rel="stylesheet" href="core.css">

Emphasis on file. You should be bundling all your reusable CSS files into one file at build-time. This CSS file should be included in the <head> element on every page.

The core JavaScript file should be included at the bottom of every page

<script src="core.js"></script>

Emphasis on file. You should be bundling all your reusable script files into one file at build-time. This script file should be included at the bottom of every page, before the closing </body> element.

Section or context-specific needs

The web app should specify what business objects are used in the page context, or indicate the section of the site

<html class="obj_1_name obj_2_name section_name">

This is useful for section-specific style overrides, where the styles in one section are distinct from those in another.

A user or layout-context CSS file should be included on every page that uses that context or layout

<link rel="stylesheet" href="guest.css">

Most of our CSS should be wrapped up in the core CSS file, but sometimes you’ll want to include an extra block of styles because the layout or styling is unique. A good example of this is the split between being a guest user vs. an authenticated user. Guest users will see marketing related content. Authenticated users would see app-specific styles.

A page or section of the web app should be able to add its own specific script file

<% Footer script block %>
<script src="home.js"></script>
<% end Footer script block %>

The core scripts should not be overloaded with page or section-specific scripts. Since the core script will be cached, the impact of this additional script should be negligible.

A page or section of the web app should be able to add its own specific CSS file

<% Head link block %>
<link rel="stylesheet" href="page_home.css">
<% end Head link block %>

Likewise with page-specific scripts, the front-end developer should be able to add CSS for sections or pages within the app. This will keep the core CSS file down in terms of size.

A page or section should be able to set its related page or section nav item to ‘active’

<nav>
  <ul>
    <li class="active"><a href="/">Home</a></li>
    ...
  </ul>
</nav>

This is one of two ways to set active nav-items. The other is to use the page_slug ID and match it to an ID for each nav-item. There will be some circumstances where it would be better to set a class on the active nav-item, so your web app should provide this.

Page specific needs

The page name should be added as an ID value to the root node

<html id="page_slug">

This gives a CSS author the ability to set page-specific style rules or exceptions to the style rules

Set page-specific keywords

<meta name="keywords" content="[keywords]">

This will allow for better search indexing

Each page should have a page title in the header of the page content

<article>
  <header>
    <h1>Page title</h1>
  </header>
  ...
</article>

This gives the document a good structural outline, some extra elements to use for styling and helps with SEO.

Content-specific needs

If you’re building an ecommerce app, you should mark-up all prices consistently

<div itemprop="offers" itemscope itemtype="http://schema.org/Offer">
  ...
  <b itemprop="price">
    <span itemprop="priceCurrency">ZAR</span>
    <abbr title="Rands">R</abbr>&nbsp;4<span class="separator">,</span>999<span class="decimal_point">.</span><span class="cents">99</span>
  </b>
  ...
</div>

Not only does this help with styling flexibility, but also better semantic use. The snippet above uses schema.org microdata.

Conclusion

I’ll add more as I think of them, but hopefully this should cover most of the Front-end Developer’s needs.

I think we’re in for some exciting times when we throw CSS precompilers such as Sass and LESS into the mix. This setup is all about modularising the UI based on information and technical architectures, something that the precompilers are built for.
Still, this is uncharted territory. What’s your experience? What do you have to rebuild each and every time?

Static assets served separately

Posted: December 2nd, 2012 Author:

I want to know: why do most web application servers (Django, Rails, etc) serve static assets?
It seems wasteful to me (in terms of web performance) that a tied-up application server has to deal with the extra burden of serving static assets.

It also seems silly for designers and front-end developers to have to configure, install and use an app environment to do work on mostly static elements such as the CSS and JS.

Read the rest of this entry »

Cast amongst the wordsmiths and awareness-builders

Posted: October 28th, 2012 Author:

Last week I was told via email of some great news: I had won a ticket to the Content Strategy Forum 2012. I was keenly aware of this conference and was itching to attend (some of the smartest folks guiding the web were speaking), but the price tag far exceeded my annual training budget as a freelancer. So, with a ticket secured, I travelled through to Spier Wine Estate outside of Stellenbosch to meet some of my influencers (such as Luke Wroblewski) and other fellow web workers.
Read the rest of this entry »

position:fixed; headers and hash URLs / fragment identifiers

Posted: September 19th, 2012 Author:

I came across an interesting problem today while working with a fixed header and a hash-URL or fragment identifier URL. When loading a URL with a fragment identifier, the fixed header can obscure the content you’re linking too; not great.

Some of the suggested fixes on the web are a little short-sighted – I might have a more elegant solution, but it’s still not bullet-proof.

Read the rest of this entry »

Video is dumb

Posted: September 18th, 2012 Author:

The more I think about the aspects that make the web great, the more I wish they could be applied to video.
Video, in the traditional sense, is dumb. It’s a single-direction, force-fed slop of visual and auditory data that can only really be processed by humans.

Video is dumb
Read the rest of this entry »

Weaving a styling tale

Posted: August 2nd, 2011 Author:

Imagine for a moment that CSS is a diligent (and somewhat queer) fashion designer.  He is always trying to dress his subject matter in all manner of fashion, from the formal to the flashy.  Think of CSS as a roving clothing-wielding fashionista.

CSS peppers his daily routine with studying his favourite subject matter: HTML Elements.  The Elements are a curious set of creatures to CSS, and nowhere is this curiosity more evident than in CSS’s regular [and published I might add] fashion reports on his subject matter. Reading like the annals of an Ethnographer, CSS describes what it was like when he first encountered The Elements…

Read the rest of this entry »

Freed from IE6!

Posted: January 12th, 2011 Author:

yola minus IE6 equals awesome

It has been more than 8 months since www.yola.com went live with a redesign, built and designed by a small team of people here in Cape Town.
Before we started the build (after months of design by committee), a simple decision was made: Let’s abandon Internet Explorer 6. This simple decision has had a significant impact on our development and design work at Yola, all for the better.
Read the rest of this entry »

The bane of touch-screen interfaces

Posted: April 7th, 2010 Author:

The touch-screen experience on the new iPad should be nothing short of amazing, if the iPhone is anything to go by. The user’s experience on this new device will tend towards a perfect one, a nirvana of human-machine connectedness, but comes with one major disclaimer: You have to be able to see the interface.

A man using the touch-screen interface of the new iPad

Touch Screen Interfaces - a big 'Up Yours' to non-sighted users. Photo by Steven Rhodes

Read the rest of this entry »

CSS Reset and ‘Sensible Defaults’

Posted: March 10th, 2010 Author:

Web Standards Advocates should really be called Zealots. I am also guilty of punting Web Standards, sometimes with no sound reasoning behind my convictions. This ‘blind faith’ led me to a point where one of my team members reigned me in and showed me the misinterpretation of my ways, and it had all to do with Reset CSS and my lack of ‘Sensible Defaults‘.

Read the rest of this entry »