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! :)
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.
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!
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.
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. That is why businesses globally will look for the best software development perth services, for example, so they can be provided the technology needed for their business to thrive and adapt within their environment.
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 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 the remaining 140 characters per update. Many businesses use SMS communications to help alert customers about deliveries, offers, and updates. To find out more about businesses using SMS, visit this website. Businesses are increasingly using messaging as a means of communication. They use messaging platforms, particularly for communicating with customers and within the company. By choosing the right strategy available on https://www.agora.io/en/products/real-time-messaging/ or similar sources, real-time messaging can also be used for business-to-business (B2B) and business-to-consumer (B2C) communications.
However, I’ll leave it to others to ponder the consequences on the language and communication – if any. I wanted to bring 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:
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 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 latter; 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.
Another solution 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:
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.