Last week saw our latest work launched successfully to a forum audience in Guadaloupe in the Caribbean: STZC.ORG.
The client is an EU funded research project whose aim is to encourage tourist destinations in the Caribbean to measure and improve on sustainable tourism practices.
The site's users, i.e. the destination managers of various tourist destinations in the Caribbean, are able to complete destination profiles and evaluation questionnaires on the site, and then generate PDF reports automatically. The administrators are also gien the tools to edit site content themselves, upload files, create user accounts for each destination and have access to all the destination reports. The site is built to support three languages for all content: English, French and Spanish and the site administrators are able to translate all content themselves.
STZC.ORG was built using the Drupal open source system, with customised modules to handle the evaluation questionnaires and report generation. Extensive use of Drupal's CCK and Views modules were used to handle the large questionnaires (150 questions, spread over 4 forms, in three different languages). As the budget was tight, any design work was kept to a minimum, making use of Drupal's default templates as much as possible.
Users were allowed to use the site at launch and they successfully managed to varry out tasks on the site smoothly, thanks to the work we put in making to make the user interface intuitive and easy to use.
We are proud of this launch as it fits in with our aim of increasing non-profit and 'green' projects in our portfolio.
Sunday, November 16, 2008
Tuesday, September 16, 2008
Drupalcon Szeged 2008 videos
If you missed it, like I did, fret not. You may have missed the networking and mingling, but the presentations are here, on video: http://tinyurl.com/6jk8gc
Wednesday, September 3, 2008
Drupal: Use long CCK field labels
If you use CCK for creating Drupal nodes, you will find that there is an inherent 128 char limit for the field labels. This limit is due to the database column size so tough luck in trying to change this limit. If you absolutely must use labels longer than 128 char, like for questionnaires, here's a workaround which lets you use the feld description text as the label (the contents of this description text is usually shown as smaller greyed-out text under the field).
The disadvantage of this is you will not be able to show help description under the field, but this is only for the fields that you want longer labels on... fields with shorter labels can still show descriptions.
I've implemented this as a module called desc_as_label. When you need to have a field label longer than 128 chars, just use a field label prefixed with an underscore - this will not be shown to the user as the underscore is just to tell the module to use the description as the field label. Then type in the actual long label text into the field description field.
The code for the .info and .module files are shown below. Save them into a sites/all/desc_as_label and enable it in your site's Modules section.
As always, comments welcome!
File desc_as_module.info:
File desc_as_label.module:
The disadvantage of this is you will not be able to show help description under the field, but this is only for the fields that you want longer labels on... fields with shorter labels can still show descriptions.
I've implemented this as a module called desc_as_label. When you need to have a field label longer than 128 chars, just use a field label prefixed with an underscore - this will not be shown to the user as the underscore is just to tell the module to use the description as the field label. Then type in the actual long label text into the field description field.
The code for the .info and .module files are shown below. Save them into a sites/all/desc_as_label and enable it in your site's Modules section.
As always, comments welcome!
File desc_as_module.info:
; $Id$
name = "Description as Label"
description = "Use the longer descriptive help text in CCK fields as the actual label."
core = 6.x
package = CCK
dependencies[] = content
version = VERSION
File desc_as_label.module:
<?php
// $Id$
/**
* @file
* Allow the use of the long 'help text' description to be used as the field label when
* long labels are needed. Prefix the field title with an underscore and the help
* text will be used instead. If help text is used, the help text will not be repeated
* below the field.
*
* @version $Revision$
* @modifiedby $LastChangedBy$
* @lastmodified $Date$
*/
/**
* Implementation of hook_form_alter().
*/
function desc_as_label_form_alter(&$form, $form_state, $form_id)
{
if (in_array($form_id, array('_content_admin_field', 'content_admin_field_main'))) {
_desc_as_label_admin_instructions($form);
} else {
_desc_as_label_process($form);
}
}
/**
* Amend the label to use the description, if the label has a leading underscore.
* @param &$form The form to be modified, as passed into hook_form_alter().
*/
function _desc_as_label_process(&$form)
{
foreach ($form as $element_name => $element_array)
{
if (strpos($element_name, 'group_') === 0) {
_desc_as_label_process($form[$element_name]);
}
elseif (strpos($element_name, 'field_') === 0) {
if (strpos($element_array['#title'], '_') === 0) {
$form[$element_name]['#title'] = $form[$element_name]['#description'];
$form[$element_name]['#description'] = '';
}
}
}
}
/**
* Show instructions for field admin form
* @param &$form The form to be modified, as passed into hook_form_alter().
*/
function _desc_as_label_admin_instructions(&$form)
{
$form['new']['label']['#description'] = $form['new']['label']['#description'].' '.t('Maximum 128 characters. If you want a longer field name, you can use field Help description text as the field name instead. To do this, prefix this field name with an underscore, e.g. _longquestion, and then put the actual label to use in the Help description field.');
}
The browser is dead, long live the browser!
Ok, that may have been a bit melodramatic. The point is whether the web "browser" as it appears today is ready to be replaced. By not another browser, but another paradigm in how we access online apps and info.
I was reading about Google Chrome, Google's browser, (actually, the comic version, which I thought was really cool). I was impressed. It is what grown-up browsers should be, although I've yet to try it first hand (Mac version not yet available). Of course, all the bugbears of web access is covered (phishing, malware, privacy, etc) - this is I think a consequence of being able to rethink the browser and create something from scratch. The real leap however is in building something that will handle web apps well. This means rethinking the Javascript engine and memory management, which is what they have done.
While Chrome is an evolution, it is still an evolution in browser technology, not in the way we access information and apps online. An ideal scenario is when the browser completely 'disappears' from the user and allows us to just get on with using apps and access data straight form the the device or OS. In this way, the browser becomes just the engine behind it all. Perhaps this is where Google is getting to, but using Chrome as a transitionary technology, as they did mention this:
"... In the case of webapps, we've made it so you can launch them in their own streamlined window, without the url box and browser toolbar. ... We don't want to interrupt anything the user is trying to do. If you can just IGNORE the browser, we'de done a good job."
Google's decision to use Webkit is key IMHO. Webkit is the rendering engine behind Chrome and Webkit can be embedded in all sorts of things, not just Windows, OSX and Linux. Once we start seeing something like Webkit (plus things like the V8 Javascript virtual machine that Chrome uses) being part of the device or OS, then I think we'll start to free outselves from the confines of the browser.
Perhaps Mozilla's Aurora concept is a glimpse of this vision.
I was reading about Google Chrome, Google's browser, (actually, the comic version, which I thought was really cool). I was impressed. It is what grown-up browsers should be, although I've yet to try it first hand (Mac version not yet available). Of course, all the bugbears of web access is covered (phishing, malware, privacy, etc) - this is I think a consequence of being able to rethink the browser and create something from scratch. The real leap however is in building something that will handle web apps well. This means rethinking the Javascript engine and memory management, which is what they have done.
While Chrome is an evolution, it is still an evolution in browser technology, not in the way we access information and apps online. An ideal scenario is when the browser completely 'disappears' from the user and allows us to just get on with using apps and access data straight form the the device or OS. In this way, the browser becomes just the engine behind it all. Perhaps this is where Google is getting to, but using Chrome as a transitionary technology, as they did mention this:
"... In the case of webapps, we've made it so you can launch them in their own streamlined window, without the url box and browser toolbar. ... We don't want to interrupt anything the user is trying to do. If you can just IGNORE the browser, we'de done a good job."
Google's decision to use Webkit is key IMHO. Webkit is the rendering engine behind Chrome and Webkit can be embedded in all sorts of things, not just Windows, OSX and Linux. Once we start seeing something like Webkit (plus things like the V8 Javascript virtual machine that Chrome uses) being part of the device or OS, then I think we'll start to free outselves from the confines of the browser.
Perhaps Mozilla's Aurora concept is a glimpse of this vision.
Wednesday, August 27, 2008
Mozilla Ubiquity - I've seen the future
It's almost as if the stars were aligning for me. First, I decided to move from Windows to Mac. This is when I discovered Quicksilver - a pimped-up command line tool that puts every Mac command at your fingertips. And now, Mozilla put this same power on the web with Ubiquity, and more.
In their own words, Ubiquity is an "... experiment into connecting the Web with language in an attempt to find new user interfaces that could make it possible for everyone to do common Web tasks more quickly and easily." Ok, doesn't really say much, it basically replaces all those cuts and pastes and clicking on bookmarks and gong to new URLs with a simple type-a-few-letters-in-your-browser interface. The video below does a much better job of illustrating.
That's just a start. What it enables is also mashups, but done inside the browser, by the user. You just have to see it for yourself to understand what this means: download Ubiquity, go to the tutorial page, and try out the Map example. It totally blew me away...
Imagine the day when Ubiquity becomes truly ubiquitous, going beyond the browser and into mobile devices and, in addition to text, also understanding gestures... exciting!
In their own words, Ubiquity is an "... experiment into connecting the Web with language in an attempt to find new user interfaces that could make it possible for everyone to do common Web tasks more quickly and easily." Ok, doesn't really say much, it basically replaces all those cuts and pastes and clicking on bookmarks and gong to new URLs with a simple type-a-few-letters-in-your-browser interface. The video below does a much better job of illustrating.
That's just a start. What it enables is also mashups, but done inside the browser, by the user. You just have to see it for yourself to understand what this means: download Ubiquity, go to the tutorial page, and try out the Map example. It totally blew me away...
Imagine the day when Ubiquity becomes truly ubiquitous, going beyond the browser and into mobile devices and, in addition to text, also understanding gestures... exciting!
Subscribe to:
Posts (Atom)
