Plone, Social, Usability

Plone Cathedral Sprint 2010 in Cologne

This week I’m attending the first Plone Sprint held in my hometown of Cologne! The aim of the sprint is to focus on completing tasks for the upcoming major release of version 4.0 and even the next incremental version 4.1.

I’m working on the sprint group that is trying to clean up the search interface and make the Plone search experience a little bit better.  I think we’re making some progress already – and as always – it’s great fun! :)

Standard
News, Plone

Plone Conference 2008 venue and dates

It’s now official where and when the Plone Conference 2008 will be held. The winner is Washington DC and the dates are October 8 – 10 preceded by two days of Plone training sessions, and followed by 2-3 days of sprinting.

Congratulations to Alex Clark and the ZPUGDC!

Plone in Trier

I’d like to openly disclose that I voted for the DC proposal, although it would have been more convenient for me personally to attend a conference in Europe. My vote this year was for a change of continent.

I hope I will be able to attend and see you there!

Standard
Lessons Learned, Rants, Software

Licensed to ill?

I get to do cool things with Plone. Sometimes I even get to do it together with cool friends. On one such occasion we are using a very capable PDF generator called PDFlib to generate print quality PDFs through Plone. The actual version we are using is PDFlib Personalization Server (PPS) version 6. PDFlib is license based. More precisely it costs money for PPS licenses. Fair enough. In the course of our project (iconic brand customer to be publicized at later stage) we discovered that we needed more production servers to balance the load, so more servers were ordered.

What we then learned is that the PDFlib PPS v6 does not exactly play nice with new dual core based servers; PPS v6 treats each core as one separate CPU, each requiring a separate license. That is to say the licensing costs per CPU per server has now doubled. The standard price of a single PPS license is € 1350,- (ca USD 1852,-) . In the meantime the current version of PDFlib has matured to 7 which requires only one license per server, albeit a more expensive one.

As PPS v6 is already running in a mission critical system, upgrading to v7 is not an option at this time. All the servers in our new data center have at least dual core Xeon CPUs, adding to the dilemma. I called PDFlib Germany thinking they would be sensible, having changed the licensing for the better with v7. No dice.

No retroactive license change for v6. No flexible migration deals. No nothing.

I could either upgrade all existing servers to the more expensive single server license v7 (and additional licenses for each new server) or buy a single v6 license for each and every core. I would not mind paying something for a single server license upgrade for v6, but the limited options provided by PDFlib at the moment are just plain stupid in my opinion; I have the choice between the plague or cholera.

Update: We are currently considering throwing out PDFlib and using Reportlab instead. Reportlab is lacking some features, but the added development needed to reportlab is possibly outweighed by the senseless PDFlib license costs. Further more, it would be cool to be able to add functionality to reportlab and release it back to the open source community!

Do you think this is a lame clever business decision by PDFlib? Let them know. Do you think I’m wrong? Let me know. Have you ever been left hanging from changes to hardware and/or licensing? I’d love to hear about your predicament and how you dealt with it.

Standard
Rants, Software, Usability

Do you know where you’re going?

UPDATE 2013: Problem (mostly) solved today. Multiple rounds of shortening still tend to garble the original url address.

In software development you’ll – unfortunately – sooner or later end up having to compromise between usability and functionality. These compromises are often a result of either financial, time or technological constraints. However, the wonderful thing with software is that you can always improve, add and modify after the fact.

Services like jaiku and twitter enables you to let the world know every novel, quaint or painfully inane activity that you are up to at any time, through almost every thinkable mode of communication, save semaphores and smoke signals. One mode being sending and receiving updates per SMS via your mobile phone. A standard SMS text message is limited to 160 characters. As twitter and Jaiku also supports the sending and receiving updates via SMS, they have implemented the limitation set by this lowest common denominator. For instance twitter even keeps 20 characters for itself and you get to play with a remaining 140 characters per update.

I’ll leave it to others to ponder the consequences on the language and communication – if any. I wanted to bring the attention to a usability issue brought about by this technological constraint, not start a discussion about the evolution or devolution of language and communication, although interesting in itself.

To be able to post links (URLs) to pages on the Internet in their updates on twitter and Jaiku, people are using additional services like urlTea and tinyurl to help reduce the numbers of characters to transmit the address, but leaving it functional. Those services take a potentially long address like ‘https://www.cia.gov/library/publications/the-world-factbook/ index.html’ and truncate it to ‘http://tinyurl.com/2b2kg9’, leaving more characters to write a personal message to go with the link with. However, any identity or clue as to where that address may lead has now been removed. (Not to mention the additional burden the use of those additional services places on the poor user. I’ll leave that discussion for later posts.)

I’ve illustrated how this looks when using the web interface of twitter below:


Screenshot of twitter.com

Notice that there are no clues in that address as to what to expect when you click on it. The clever twitterer might suggest that if you’ve been following Chris Pirillo for a little while you’d expect the link to be leading to one of his web casts on his site, but then again there is no information in that address to tell you at a glance what to expect. You can’t know if it’s linking to the story you already read two weeks ago, if it’s self promotion if it’s linking to a site you know and trust – it could even link to an address that would get you in trouble at work.

Enter ‘The Gulf of Evaluation’:

“Does the system provide a physical representation that can be directly perceived and that is directly interpretable in terms of the intention and expectations of the person?The Gulf of Evaluation reflects the amount of effort that the person must exert to interpret the physical state of the system and to determine how well the expectations and intentions have been met. The gulf is small when the system provides information its state in a form that is easy to get, is easy to interpret, and matches the way the person thinks about the system.” Donald Norman in ‘The Design of Everyday Things‘, Doubleday 1990.

I’ll argue that the gulf of evaluation is light years wide in the case in question. I’d like to have some transparency please. Show me a proper address!

Of course it could be argued that some users of the mentioned services would actually support the extra layer of obscurity afforded by the use of nameless addresses – that it actually generates more traffic from people clicking blindly than it would if people could see the real address and source. I do not have a firm opinion about that, however.

There are of course ways to alleviate for this unfortunate loss of information, letting us know where we’re going before wasting our time or getting fired (if using Jaiku and/or twitter hasn’t already gotten you fired) by clicking on the wrong links anywhere but the SMS’. I’ll propose two modes of improvement. One involves internal changes to the services themselves, and the other external additions with no need for involvement from the Jaiku or twitter development team. They both have advantages and disadvantages.

I’ll start with the blatantly obvious one; Jaiku and twitter should look up the truncated addresses before they are rendered and parse them. That is to say a truncated address would be shown in full when using all web based interfaces. Why on earth should we be limited and constrained to the lowest common denominator on the web? We can have gazillions of characters! Heck, keep the limit to 140 characters displayed on the web , just like the current solution, but show those URLs in full in addition to those 140 characters. However this would require the time and attention from the official development teams that are probably already preoccupied with other challenges, fixes and policies.

The second and almost as obvious one would be to develop a plug in for e.g. Firefox that would identify addresses from services like tinyurl and urlTEA, look them up and show the complete address in the status bar below left and as a tool tip when hovering with the pointer over the link. I’ve illustrated how this may look below:


Screenshot of twitter.com

The two immediate advantages of this solution would be that it require no commitment from an internal development team and that it would work with any web page, not only with the content coming out from twitter or Jaiku.

Here’s a another perspective on URL shortenings from Jeff Atwood of codinghorror.com

Standard