A couple of days ago I visited an expert´s forum concerning Universal Design:
“Universal Design is the design of products and environments to be usable by all people, to the greatest extent possible, without the need for adaptation or specialized design.” (Ronald L. Mace, 1988)
Thinking about this definition of Universal Design, I have two critical points to make: Who is meant by all people? And why is no need for adaptation a goal at all?
In the first place I regret the fact that the debate was dominated by speeches NOT referring to ALL people at all! Organized by the German Family Ministry it focused on generation fairness rather than the UNIVERSAL aspect of Universal Design.
By far the best contribution at this event was made by Peter Glaser – regarding him as an excellent speaker and a bright mind, I should pay more attention to him in future: He was about the only one there to understand that a UNIVERSAL claim cannot be limited to elderly or disabled people here in Germany or other first world countries – UNIVERSAL needs to imply ALL people on our planet.
If I understand the idea behind Universal Design correctly, I think it is one of the most important ideas around: Do not discriminate against any people anywhere in the world by means of technology, products or services.
But with my personal (free-) software-specific view on design I am puzzled about the rejection of adaptations in the definition by Ronald L. Mace.
I am convinced that the exact opposite is true. To me GOOD Design makes it extremely easy to adapt a product to the special needs of the user(s). This believe is one impulse behind my commitment for free software. The mechanisms of free software encourage people to derive special solutions for their needs on the basis of developed technology standards.
Some examples:
Do you have any other examples?
To sum it up: I believe free software is a good – if not the best – approach to achieve the noble goal of creating non-discriminating technology for all, or Universal Design. We are on a good path, even though it is still too complicated to actually do the needed adaptions today, especially if you are not a software-developer. We can still do better.
Shouldn`t we always keep that in our minds, when we create free software?
Well, it’s always easy to state that something is slow, so let me be a bit more precise: If you need to do a lot of complex date/time operations in you applications, Zend_Date might turn out to be the major bottleneck. If you just need localization for some date’s Zend_Date presumably won’t be your problem.
In the Calendar app of Tine 2.0 it turned out, that Zend_Date consumes 66% of the time of a Month view Request in a realistic szenario.
Just bashing Zend_Date would be to easy, as it has a remarkable feature set. Most notably in my view:
- solves the year 2038 problem on 32 bit systems
- full timezone support
- full localization support
- full support for ISO 8601 date string identifiers
As Date/Time is a really complex topic, here my full acknowledgement for this feature set at a time when PHP couldn’t help on all this.
On the other hand you don’t always need all the nice features it has, but you might want to use Zend_Date as generic date/time abstraction all over your applications. In this case Zend_Date is slow and has a lot of potential for improvements.
Zend_Dates could be created from a date string in an arbitrary format and locale. This is great if you need to parse custom date strings.
When dealing with Zend_Date in backend operations, you normally only use very few date/time representation formats. e.g. ‘yyyy-MM-dd HH:mm:ss’ which is the mysql date/time format.
For this kind of input Zend_Date has no optimization. An easy performance patch for this problem could be:
if ($format === 'yyyy-MM-dd HH:mm:ss') { $matches = array(); preg_match("/^(\d{4})-(\d{2})-(\d{2})[T ]{1}(\d{2}):(\d{2}):(\d{2})/", $_ISO, $matches); if (count($matches) == 7) { list($match, $year, $month, $day, $hour, $minute, $second) = $matches; // NOTE: PHP5 timestamp support is 32 bit and ends on 2038-01-19 03:14:07 if ($year < 2038) { $date = mktime($hour, $minute, $second, $month, $day, $year); $format = Zend_Date::TIMESTAMP } }}When converting Zend_Dates to strings, the same as above applies. Here an easy patch could be:
if (! $part) { $part = self::TIMESTAMP;}if (array_key_exists($part, self::$_dateMap)) { $dt = new DateTime('@' . $this->getUnixTimestamp()); $dt->setTimezone(new DateTimeZone($this->getTimezone())); $s = $dt->format(self::$_dateMap[$part]); switch($part) { case 'm': $s = (int) preg_replace('/^0/', '', $s); break; } return $s;}with this dateMap
private static $_dateMap = array( 'yyyy-MM-dd HH:mm:ss' => 'Y-m-d H:i:s', 'MM' => 'm', 'm' => 'i', // spechial handling required! 'M' => 'n', 'd' => 'j', 'h' => 'g', 'H' => 'G', 'HH' => 'H', 's' => 's', 'I' => 'I', 'z' => 'T', 'U' => 'U', 'eee' => 'N', 'D' => 'z', 'e' => 'w', 'X' => 'Z');
As ZF requires PHP 5.2.4 and above, we can use native PHP functions to improve setTimezone:
public function setTimezone($zone = null){ try { $dtz = new DateTimeZone($zone); $this->_offset = $dtz->getOffset(new DateTime('1970-02-01 00:00:00')); $this->_timezone = $zone; } catch (Exception $e) { require_once 'Zend/Date/Exception.php'; throw new Zend_Date_Exception("timezone ($zone) is not a known timezone", $zone); } if (($zone == 'UTC') or ($zone == 'GMT')) { $this->_dst = false; } else { $this->_dst = true; } return $this;}This are just 3 very easy patches, but for a Tine 2.0 Calendar month view request it saves 41% of the request time!
Derick Rethans contributed a great DateTime class to PHP which is in included beginning with version 5.2 which got even more improved in version 5.3. This class solves the year 2038 problem, has full timezone support.
So my first idea was to write a new Zend_Date class which requires PHP version >= 5.3 to be used as a drop in replacement. Unfortunately it turned out, that the design of Zend_Date is not compatible with the DateTime, or to be more precise, the new class would also be slow due to two base restrictions in Zend_Date:
- ISO representation for date string identifiers
- Zend_Date also represents date intervals which have a separate class in PHP.
At the end I implemented on own wrapper class around DateTime which supports some old Zend_Date signatures, so that we don’t had to edit all our code. Zend_Date is only used when Server side locale handling is needed, like in exports.
Switching from Zend_Date to native DateTime brought us a speed up of 66% in a calendar month view request.
We just have published a new version for Kontact Mobile on Maemo. I would like to encourage you to tell us how you like it.
Why should you try Kontact Mobile and give feedback?
Kontact Mobile is doing really well. It is a promising product, feature rich, free software, KDE and it is here to stay. But the current project of porting Kontact to the mobile world is – what it looks like now – only supported till the end of this year. So we really need your feedback now. Next year we will not have the same power as now to let your wishes go into the project. So, please try it right away, spread the word and do not forget to
Let us K(DE)onquer the mobile world.
|
June '13 | |||||
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
