Category: Web Development


Google+ as trojan horse.

August 31st, 2011 — 5:29am

Stilgherrian wrote an article recently regarding Google+ taking it to task for not being upfront about its plans to be more than a social network and instead become an online identity service.

Normally I’m a big fan of Stil but the article feels a bit more like breathless drama mongering than his usual fare. I fall on his and my.nameis.me side of the fence in relation to the #nymwars but I would have thought that it was fairly obvious that any site that provides the concept of personhood (or user) in what is the normally stateless environment of the web should be considered an identity service.

There’s nothing particularly sinister about what Eric Schmidt said in the conversation with Andy Carvin, smart technical people have been discussing this issue for a very long time now it’s simply that nobody in the online world covers as many services as Google does so it’s a bit more carefully scrutinised when Google talks about it. As it should be.

Some sites, notably twitter and facebook, have expanded the concept into Authentication services that span multiple sites and obviously Google would like to play the same game. Google accounts have been valid OpenID for years now so your Gmail address has been an identity for all kinds of services (in the sense of identity as Authentication) for quite a while.

There’s a lot of separate concepts around Identity at play here so I’ll take a moment to try and define them.

  • Authentication – Your identity can be used as a key to unlock different services. For example you can use either facebook or twitter to create an account on Quora which is a completely different service.
  • Trust – Other observers may place varying degrees of trust on a persistent identity. Some social media sites use concepts like reputation or karma to rank users based on a very basic trust rating. Frankly, nobody online has really managed to get a handle on Trust as a service.
  • Expression – Your identity is tied to how you communicate. Your tone or your behaviour may change depending on the identity you are currently assuming.

To me, even more than the loss of anonymity issue, the loss of Expression is the one of the great problems with the ‘real name’ policy. Eric Schmidt and G+ are apparently concentrating on Authentication and Trust and are comfortable with trying to force a change to how people view Expression to get there.

Personally I’d be more happy if everyone online took responsibility for their own identities themselves but I realise that, for now, the process to get to that point is a bit of a steep learning curve. I think that if any company should fill the gap and provide the role of Identity services it should be the ABC and other national broadcasters around the world but that’s probably another post for another day.
Disclaimer: I work for the ABC although I’ve held this belief for longer than I’ve actually worked there.

1 comment » | Media, Web Development

A YQL example in javascript and in PHP

December 18th, 2009 — 9:19am

Following on from my quick attempt at using YQL to trawl through Senate and House of Reps debates on the Australian internet filter being proposed I thought I’d stick the code up here as some people might find it useful to see how you can use YQL in just about any language to get the results you want.

First off I made a very quick javascript version which just grabs the list and appends each piece of returned data to the page.

<script type="text/javascript" src="http://www.google.com/jsapi"></script>
<script type="text/javascript">
    google.load("jquery", "1.3.2");
    google.load("jqueryui", "1.7.0");
</script>

</head>
<body>
    <h1>A list of debates in the Australian Senate including the words internet+filter</h1>
    <div id="container">

    </div>
</body>
<script type="text/javascript">
function parseDebates(data) {
	var results = data.query.results.match;
	$.each(results, function() {
		var $div = $('<div />');
		if(this.speaker) {
			var name = $('<p>')
				.append(this.speaker.first_name+" "+this.speaker.last_name)
				.append(' on '+this.hdate+' in  '+this.parent.body+'');
			var content = $('<blockquote>'+this.body+'</blockquote>');
		}
		$div.append(name);
		$div.append(content)
		$('#container').append($div);
	});
}
</script>
<script type="text/javascript" src="http://query.yahooapis.com/v1/public/yql?q=select%20*%20from%20openaustralia.getDebates%20where%20type%3D'senate'%20and%20search%3D'internet%20filter'&format=json&env=store%3A%2F%2Fdatatables.org%2Falltableswithkeys&callback=parseDebates"></script>

And then we can do essentially exactly the same thing in PHP, except instead of appending the data to the page we take the same returned results, generate an RSS xml schema and print that.

<?php
	$apicall = "http://query.yahooapis.com/v1/public/yql?q=select%20*%20from%20openaustralia.getDebates%20where%20type%3D'senate'%20and%20search%3D'internet%20filter'&format=json&env=store%3A%2F%2Fdatatables.org%2Falltableswithkeys";
	$ch = curl_init();
        curl_setopt($ch, CURLOPT_URL, $apicall);
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
        $output = curl_exec($ch);
        curl_close($ch);

	$debates = json_decode($output);
	$output = '<?xml version="1.0"?>';
	$output .= '<rss version="2.0">';
	$output .= '<channel>';
	$output .= '<title>Internet Filter debates in the senate</title>';
	$output .= '<description>A list of debates mentioning the words Internet+Filter in the Australian Senate</description>';
	$output .= '<link>http://www.hallofbrightcarvings.com/external/internet-filter.html</link>';
	foreach($debates->query->results->match as $mention) {
		if($mention->speaker) {
			$output .= '<item>';
			$output .= '<title><![CDATA['.$mention->speaker->first_name.' '.$mention->speaker->last_name.' on '.$mention->hdate.' in '.$mention->parent->body.']]></title>';
			$output .= '<description><![CDATA['.$mention->body.']]></description>';
			$output .= '<link><![CDATA[http://www.openaustralia.org'.$mention->listurl.']]></link>';
			$output .= '</item>';
		}
	}
	$output .= '</channel>';
	$output .= '</rss>';
	header("Content-type: text/xml");
	echo $output;

Comment » | Web Development

Australian Internet Web Filter

December 17th, 2009 — 12:10pm

Still in the process of gathering more information about Senator Conroys wrong-headed scheme to try and censor the web of ‘Refused Classification’ content. Currently the hardest thing so far has been to try and get a clear definition of what the hell ‘Refused Classification’ actually encompasses. Seems to vary greatly depending on medium, and even within individuals media it seems to be pretty confusing and ‘airy’.

Anyway, spent a few minutes today tinkering with Yahoo’s fantastic YQL API that allowed me to set up a couple of pages to trawl through Senate and House of Rep debates for anyone mentioning the words ‘internet+filter’. I’ll likely try and turn them into RSS feeds when I get some more spare time, but in the meantime the Senate one is here and the House of Representatives one is here.

Comment » | Web Development

HTML wireframing example

December 10th, 2009 — 3:10pm

Part 1 of this HTML wireframing tutorial can be found here

We’ll take these changes one at a time.

The first is an easy fix and makes sense; we can do it just by moving the markup in the page around – no problems there, this doesn’t move us outside the realm of what a standard wireframe would produce.

The second starts to bring in more functionality than we would normally be comfortable with in a wireframe. While it’s certainly possible for wireframes to visually show tabs or accordions or carousels or any number of design elements, it’s difficult for a static wireframe to accurately depict how each one of these will actually work or what content each of them will reveal.

Luckily, with HTML wireframes we have a series of tools that help us turn the static wireframes into a functional prototype that clarifies these issues with very little effort.

Adding functionality with jquery

Using any one of the standard javascript libraries allows us to quickly and easily add functionality to static wireframes that will allow the client to really get a sense of how certain design patterns you may choose to use will actually work with their content.

In this case adding the functionality is as simple as wrapping the three elements in a separate div with an id of ‘accordion’ and adding

<script src="http://jqueryui.com/latest/jquery-1.3.2.js" type="text/javascript"></script>
<script src="http://jqueryui.com/latest/ui/ui.core.js" type="text/javascript"></script>
<script src="http://jqueryui.com/latest/ui/ui.accordion.js" type="text/javascript"></script>
<script type="text/javascript"></script>

To the head of the page. See it in action here by clicking on the titles in the right section. It’s important not to get too caught up in this part, it’s likely that the client may well want quite a lot of implied javascript functionality in any  modern site. You will need to keep close watch on time to make sure you don’t spend hours adding functionality for little gain – if it can’t be added quickly to the wireframes then make a note of it and move on, don’t get caught up with fiddly issues that are better dealt with during development after the wireframes have been signed off.

This procedure does, however, highlight one of the major advantages of HTML wireframing over other wireframing techniques – it clearly and accurately shows exactly how a page or element is supposed to look and function without active javascript. Developers will find it enormously advantageous to see exactly how something is supposed to work under its simplest conditions before they start adding the usability frills of javascript. It’s a wireframe version of
Progressive Enhancement.

The third issue is a bigger problem for static wireframes than the second and highlights one of the main issues regarding wireframes in general: how do you handle alterations in state? How does a user in different states impact the elements on the page? It is possible to create multiple static wireframes showing the different states, but this can quickly grow out of hand and can make it hard for clients to recognise that separate wireframes relate to the same page. It’s also confusing for developers and designers who have to search through large numbers of files to find the specific state they’re interested in.

Adding annotations or notes can also quickly grow unwieldy and confusing. This is where prototyping tools such as  Axure really start to come into their own, allowing for startlingly complex prototypes to be created. Luckily HTML wireframers have their own little bag of tricks they can reach into to help solve this problem.

Adding state with polypage

The fact we’re already using jquery to add a few useful flourishes and touches to the existing wireframe means we can now reach for a slightly more complex jquery plugin called ‘polypage’. When activated polypage parses the class names of the page looking for any that begin with pp_ and create a menu consisting of the string following the pp_ in the class name.

Download polypage from its github repo.

Extract so that your wireframes can access the files and from there it’s a remarkably simple process to add the logged in/out states to the markup itself.

Adding a class of ‘pp_logged_in’ to the ‘user_nav’ ul is all we need to create a new state on the page of ‘logged in’. If we create a second ‘user_nav’ ul and populate it with the list items that a non logged in user would see then we can add a class of ‘pp_not_logged_in’ and polypage will know to display that state when the logged_in state in is not true. With this example you can see how easy it is to add more states to your page simply by adding appropriate markup and class names. Let’s say that we also want to indicate that people who are administrators get links under all the document names in the list that allow them to edit the document. Well simply add the appropriate markup, add the class ‘pp_logged_in_and_admin_or_admin’ to the element and we now have an extra state to select in the polypage menu – clicking both or just clicking admin reveals the new state related elements on the page.

Polypage accepts a certain amount of logic in establishing states.
You can use as class names:

  • ‘pp_<state_name>’ to display something when that state is activated
  • ‘pp_not_<state_name>’ for displaying something when that state is deactivated
  • ‘pp_<state_name>_and_<state_name2>’ for displaying something
    when both states are selected.
  • ‘pp_<state_name>_or_<state_name2>’ for displaying something
    when either one of the states is selected.
  • As shown above, we can also chain those logic states together for
    more complex states
    (ie, ‘pp_<state_name>_and_<state_name2>_or_<state_name2>’).

Looking at the new wireframe it becomes apparent that the ‘Logout’ link when you’re logged in and the ‘Log in’ button when you’re not should both trigger state changes as well. Polypage makes this possible by adding

< a href="#pp_toggle_logged_in">

To the ‘Log out’ href add

< form action="#pp_toggle_logged_in">
</ form>

Around the ‘Log in’ fields. Take a look at the expanded example we’ve been creating here.

As you can see, polypage is an incredibly simple, powerful and useful tool for taking HTML wireframing from a basic display to an incredibly useful and detailed prototype. Developers, designers and clients all like it because it simply and clearly shows interactions that have traditionally been difficult to explain to all three domains without vastly different documentation. It supports some very advanced features and you can easily use it add notes or annotations to a wireframe to provide clients, developers and designers extra information targeted specifically to them. Its ease of use and the speed at which you can add complex states to a wireframe make the initial extra time needed to develop a wireframe in HTML worthwhile.

A few wireframe Dos and Don’ts

Do make wireframes and prototypes – they will help you clarify user journeys and the relative importance of elements
with clients. Prototypes will help everyone involved nail down functionality and states before the serious development begins.

Do not spend hours getting them looking ‘perfect’ – clients can find over designed wireframes confusing and may mistakenly focus on design elements rather than the issues wireframes are supposed to clarify.

Do share wireframes with Developers and Designers – they will be able spot potential issues that you can fix before passing them on to the client. Developers especially can find the polypage state classes indispensible when developing a functional specification.

Do not become too attached to your HTML wireframes – getting wireframes done quickly tends to produce sloppy  HTML and it’s better to start again with a clean slate when it comes to the final product rather than try and reuse the markup you’ve already produced.

Do use the appropriate tool for the job – if you can get the get what you need from a few simple diagrams on some A3
paper there’s no point spending days developing complex prototypes in advanced software.

With luck this article will have planted a few seeds in your mind regarding including some kind of wirefraimg stage in your development process. The potential benefits for low outlay make it well worth it.

1 comment » | Web Development

Install zen coding snippets for Aptana

December 4th, 2009 — 7:18pm

Install aptana for eclipse

Get the zen-coding plugin for aptana from the google repo

Create a new aptana project in eclipse’s base project directory called zencoding (or whatever). Create a directory inside that project called scripts.

Paste the files and lib directory from the downloaded plugin into the scripts directory.

Restart eclipse (although that shouldn’t really be required).

1 comment » | Web Development

The Design Patterns of Social Media

November 26th, 2009 — 9:37am

Most websites nowadays incorporate some kind of community aspect that allows users to provide feedback to the site’s owners and to each other. In fact, ‘building community’ is one of the most important aspects of any modern website. Websites that focus on their community or group nature are described as being social sites, an umbrella term that can cover a great number of disparate services. This article will describe how Developers can utilise social design patterns on a site in order to promote or dull certain behaviours in an online community.

So What is Social Media?

Social Media is a fancy term to describe how people have been using the internet since its inception. Before the web, social media was BBS (Bulletin Board Systems) and multiplayer text based games. More recently the rise of site aggregators such as digg, reddit and metafilter or social aggregators such as facebook, linkedin or myspace are more well known, the social principles behind these sites however, are as old as networked computers. Social Media is community – it’s individuals coming together to share their interests and to engage as people.

So What are Design Patterns?

Design Patterns are common principles that developers use as shorthand to describe a technique they intend to use to solve a given problem. They are a shared terminology that describe an optimal solution to a commonly encountered problem.

How do they fit together?

When developing a site that is supposed to encourage a sense of community it is important to recognise what kind of community you’re trying to encourage. People using your site will end up doing things that you never expected so using design patterns will allow you to nudge your users towards certain types of behaviour that you wish to promote.

This is best illustrated by an example.
Consider a forum designed for people who are interested in talking about carpentry. The topic itself isn’t really important; it could be anyone of the millions of social forums or systems that are designed to encourage community interaction over a specific topic. When the forum is first created it may quickly fill with people who are excited and enthused to find likeminded people, many conversations start covering thousands of aspects of carpentry and related topics. Time progresses and posts grow more detailed, broad topics are narrowed into specific subjects. People begin to recognise distinct individuals; personalities emerge and direct conversations in their own ways. Topics that previously had created debate and interest have now been discussed over and over, people begin to grow disillusioned with the cyclical nature of the conversations they are having, conversations that have little or nothing to do with carpentry become the predominant topics. New users feel lost and confused at the lack of carpentry discussions and when they try to start new topics about dovetails and joins are shouted down by older users who are tired of the same conversation happening again and again, pointing to various past discussions the new user can find the information they want. The community begins to disintegrate into factions of users, splintering between old and new, carpentry purists and people more interested in maintaining the personable conversations between people, and often, between administrators and users. People begin to leave and a once vibrant online community fades away, not with a bang, but with a whimper, a few remaining souls lingering until the system administrator finally turns the power off on the servers.

The number of online communities that have experienced that life-death cycle is beyond counting. It has occurred since the internet’s inception, it’s been occurring for so long and so often that it’s possible to see the similarities inherent in every one of them – to map the patterns and to track the changes that work to make sure that the self-destruction doesn’t occur. Navigating this user-cycle can be a delicate game, but it is possible to implement patterns that give a social site the best possible chance to survive.

How do we implement Patterns that work?

The first step to implementing patterns that work, and through them, a community that will survive long term use, is to determine what kind of community you wish to encourage. Certain kinds of patterns will help promote certain kinds of behaviour. Patterns such as ‘Reputation’ can help foster a sense of competition between users, which can be beneficial, but can also be detrimental if you’re not attempting to cultivate a competitive spirit. Likewise, providing users with a advanced options to create unique and personalised identities with a ‘Profile’ pattern can result in improved user engagement and personal investment, but can also lead to users being more concerned with their personal identities on the site than producing content for consumption. Being aware of how different patterns influence behaviour allows developers to implement the right solution to reach the right result for you and your users.

Comment » | Web Development

Javascript Accessibility Guidelines

November 20th, 2009 — 2:22pm

Purpose: The nature of the internet is that not everyone will receive JavaScript in the way intended. Therefore JavaScript should be applied in a way that enhances the page, rather than requiring it.

Use un-obtrusive JavaScript
Type: Maintenance, robustness, accessibility
The three pillars of web development are:

  • Content and structure: HTML         <h1>Main heading</h1>
  • Presentation: CSS             h1 {color: black}
  • Behaviour: JavaScript         getElementsByTagName(“h1”)

The only required part of that triumvirate is HTML, which has the content and controls. Both CSS and JavaScript should in essence be enhancements.

An ‘unobtrusive’ script will:

  • Not make assumptions about what methods browsers support.
  • Check that the correct HTML is there to act upon, otherwise do nothing.
  • Keep the functionality independent of the input device.
  • Keep the scope of the script self contained.

For example, to create a show/hide area with this HTML:
<div id=”container”>
<h2>Heading</h2>
<p>Some text…</p>
</p>

The script could hide the text, wrap the heading content in a link, and attach an event to that link that shows the paragraph below.

If the script does not function, the text is shown. Just about any situation can be dealt with in this way, by planning for the scripts from the start, but implementing them at the end (i.e. building the back-end functionality as though there was no JavaScript available).

Once the back-end functionality is in place, layering on the behaviour (front-end scripts) can greatly enhance pages without requiring JavaScript. With this technique in place, you can also provide a mechanism to turn-off scripts where they are causing difficulties for people with partial JavaScript support.

Further reading:
http://dev.opera.com/articles/view/the-seven-rules-of-unobtrusive-javascrip/

Use standard HTML controls
Type: Accessibility, robustness
It must be possible for assistive technologies to identify the name, role, state and properties of all user interface components such as form elements, links and components generated by scripts. The easiest way to achieve this is to use standard HTML controls for web user interface components.

Accessibility guideline: WCAG 2 – 4.1.2

Use a library for complex scripts and cross-browser event-handling
Type: Robustness, maintenance
A JavaScript library will not take away the need for cross-browser testing, however, it will considerably reduce the time required to make a script cross-browser compatible. For short scripts with limited functionality a library is not needed, this requirement is aimed at sites with more extensive JavaScript functionality.

The exact library used is at the discretion of the developer, but it should support unobtrusive JavaScript.
Libraries can impact the download speed of a web site, however following these practices should minimise that impact:

  • Make scripts external files, therefore cacheable.
  • Put the scripts at the bottom of the HTML page, so that the page loads before the script.
  • Minify the scripts (the library probably has a minified version already). http://crockford.com/javascript/jsmin
  • Set the server to use Gzip for HTML/CSS/JavaScript files (not image or binary files).
  • Use a library that is either small, or does not require a large initial download. (I.e. some libraries only call the components needed.)

Do not use onchange for navigation
Type: Accessibility
Using “onfocus” or “onchange” events to open a new page can cause a lot of confusion, so do not initiate a change of page or a pop-up with those events. This means that a menu using a select drop-down should have a ‘go’ button.

Accessibility guideline: WCAG 2 – 3.2.1, 3.2.2

Do not enforce timing in pages
Type: Accessibility
Given the different ways that people use pages, it is impossible to tell how long someone will take to get to a particular part of the page. Therefore any time limit set on a page will be too long for some people, and too short for others.

It is difficult to provide very specific guidance, but the principle is that there should be no time limits unless:

  • The user can turn off the limit.
  • The user can adjust the limit over a wide range.
  • The user is given at least 20 seconds to extend the time limit with a simple action.
  • The limit is needed for a real time event, such as an auction.
  • The limit is greater than 20 hours.

For HTML and JavaScript, it can help to:

  • Prevent session time outs: Provide a checkbox at the beginning of long forms that allow the user to specify a longer session time limit, or no limit with a logout link instead.
  • Give the user control over scripts with time limits: Allow the user to turn off a time limit, set it at up to 10 times the original time, or to pause the time limit.

Accessibility guideline: WCAG 2 – 2.2.1

Avoid movement, blinking or updating pages
Purpose: Prevent distracting people with cognitive disabilities.
Movement in pages can be very distracting for many people, but particularly for people with learning difficulties, or conditions such as Dyslexia. Continuous movement can be distracting to the point that it becomes impossible for some people to carry out the task they have come to the website to accomplish.

Animation, moving areas of the page, or even video should not start automatically and continue playing for longer than a few seconds without giving the user a method of stopping them. An exception is made for loading indicators where there is limited interaction and it might appear to be broken if it were not included.

Accessibility guideline: WCAG 2 – 2.2.2

Do not use more than 3 flashes a second
Type: Accessibility
Flashes in pages may also cause seizures in people with photosensitive epilepsy. Seizures can be triggered by flickering or flashing in the 4 to 59 flashes per second (Hertz) range with a peak sensitivity at 20 flashes per second as well as quick changes from dark to light (such as strobe lights).

For any area of flashing or blinking content, it should not be:

  • More than 341 x 256 pixels (approximately 10% of a 1024 x 768 pixel screen), or
  • Flashing more than 3 times per second.

Accessibility guideline: WCAG 2 – 2.3.1

Clearly display errors in form entry
Type: Accessibility, Usability
If client-side (JavaScript) validation is used, it should include a pop-up saying which fields had errors, and an error indicator in each label which had an error. Ideally, when the pop-up is dismissed the focus would be put just above the top error message.

WCAG 2 – 3.3.1, 3.3.3
Ensure inserted code is valid
Type: Accessibility
When HTML is added to a page through JavaScript, the resulting HTML should be valid. This can be tested with the “View rendered source” feature in browsers such as Firefox.

Accessibility guideline: WCAG 2 – 4.1.1
Ensure AJAX (partial page updates) is accessible
Type: Accessibility
When part of a page is updated, people using screen readers or screen magnifiers may not be aware that something has changed.

The first issue is that screen readers often use a cached copy of the page, and unless that is updated the user may not have the updated area. This can be solved by adding this script, and calling the function after an update:
http://juicystudio.com/article/improving-ajax-applications-for-jaws-users.php

The second issue is that, even when available, the person may not know about the updated area of the page.

Making sure that someone using a screen reader knows of an update is tricky. Currently, you can only use content (including a hidden statement to refresh the page after making a change), or allow people to select an option where updates cause JavaScript pop-ups, or an option to turn off scripts.
To make sure people using a screen magnifier can tell something has updated, it is good practice to make it apparent that something is happening where they clicked, as their view follows the mouse very closely.
Use ARIA for custom applications
Type: Accessibility
If custom elements are used, there needs to be a mechanism in the code that identifies what that element is supposed to do. For example, if a custom button is created that shows when it is pressed, then access technology needs know about the name, role, state, properties, and values of that button.

In both HTML and Flash, the default controls already support this, but if non-standard controls are being used, this has to be taken into account.

If there is not an option to ‘turn off scripts’, then the Accessible Rich Internet Applications (ARIA) specification should be used: http://www.w3.org/WAI/intro/aria.php

ARIA provides methods to make the JavaScript and AJAX widgets work with access technologies.

ARIA works by simply adding attributes to HTML elements. For example, you could define a ‘tree’ menu with:
<ul role=”tree” tabindex=”0″ >
<li role=”treeitem”>First item</li>
[…]
</ul>

The role defines what type of control it is, the tabindex is used to allow keyboard navigation.
There are various roles defined in the spec that should cover most situations, such as menu, toolbar, slider, tooltip, tree etc.

When using ARIA the tabindex attribute can be used, and is used to add or remove things from the tab order. An un-ordered list cannot normally be focused on when using a keyboard, but adding tabindex=”0” will mean that you can, and in the normal order. Using a value of -1 (or less) will allow you to remove things from the tab order, and this can be done dynamically with JavaScript.

You can also say when something has a ‘state’, such as checked, expanded, and selected. For things that are not links or traditional form controls, this will be vital to match the visual representation.

Using the ARIA attributes, updates to the content can be announced through the ‘live’ attribute. This can be off, polite, assertive, or rude.  For example, the following section of HTML would have its updates announced:
<div id=”myLiveRegion1″ aria-live=”assertive”>
[updating content]
</div>

The screen reader software can then decide how to deal with the update, announcing a polite update when the user stops what they are doing, or interrupting them with a rude announcement.

NB: Use of ARIA attributes does make the HTML invalid (until HTML5 becomes supported), but it is recommended for the purpose of making a scripted interface accessible.

Accessibility guideline: WCAG 2 – 4.1.2

5 comments » | Web Development

Clay Shirky talks about finding the time

November 20th, 2009 — 11:01am

I think I’ve watched this video a dozen times and each time I enjoy as much as I did the first time I saw it. The embedded YouTube video looks strange because it uses the accessible media player I created using the YouTube API and I haven’t created any skins for it to make it look pretty.

Part 2

Comment » | Web Development

How to respond to social media

November 20th, 2009 — 10:31am

Here’s an interesting flowchart from the United States Airforce on how to approach social media taking an interest in your organisation.

flow chart depicting how to respond social media

Comment » | Web Development

Debugging CSS

November 20th, 2009 — 9:47am

A debug stylesheet I threw together to try and give a few basic rules for helping to debug css issues.

@charset "utf-8";

@media all {
/**
*  DEBUG RULES: For easy debugging. Just stick id="debug" in the  tag
*  and then the debugging classes you want to turn on. Options are:
*  class="colours"     [Makes each div a seperate vibrant colour]
*  class="names"       [Prints the ids at the begining of each div with black font on a white
*                      background as well as displays the class name of every element on the page
*                      on a blackground with white font]
*  class="border"      [Turns on coloured borders depending the hierachy of each element on the page]
*  class="margin-off"  [Turns off all margins]
*  class="padding-off" [Turns off all padding]
*  Combinations of these classes can also be used (ie: body id="debug" class="border names padding-off")
*/
#debug.colours #container {
    background: grey;
}
#debug.colours #header {
    background: green;
}
#debug.colours #main {
    background: yellow;
}
#debug.colours #sideNav {
    background: blue;
}
#debug.colours #content {
    background: purple;
}
#debug.colours #sideBar {
    background: pink;
}
#debug.colours #footer {
    background: orange;
}
#debug.names div::before {
    content: attr(id);
    background-color: white;
    color: black;
}
#debug.names * [class]::before {
    content: attr(class);
    background-color: black;
    color: white;
}
#debug.border * { outline: 2px dotted red }
#debug.border * * { outline: 2px dotted green }
#debug.border * * * { outline: 2px dotted orange }
#debug.border * * * * { outline: 2px dotted blue }
#debug.border * * * * * { outline: 1px solid red }
#debug.border * * * * * * { outline: 1px solid green }
#debug.border * * * * * * * { outline: 1px solid orange }
#debug.border * * * * * * * * { outline: 1px solid blue }

#debug.margin-off * {
    margin: 0;
}
#debug.padding-off * {
    padding: 0;
}
/**
*  End Debug rules.
*/
} /* @media rule; end of */

Comment » | Web Development

Back to top