Today, I came across via Twitter a blog post from Gab Davis, community and IBM Champion legend – and I make no apologies for calling her that, because she is. The blog post concerned me a lot because our community is lauded – rightly so – as being generally more helpful, more collaborative, more open than other IT communities. I truly believe that mostly it is. Everything I see from those who seek to get involved reinforces that. But it’s something we must work assiduously to maintain. So now seems a good time to share one of the earliest blog posts I wrote, back in January 2010. Some of the content may have dated. But it was written to pre-empt any potential criticism of me blogging about Dojo charting, which Chris Connor had previously blogged a little about but which I’d learned some more. My worry was unfounded, as I hoped. But the blog post ended by encouraging others to blog about Dojo charting or other topics I might blog on, if they felt they had additional information to add. It fits perfectly with my beliefs about sharing content and reinforces what Gab says about the absence of ego in our sharing.
And I’ll echo that sentiment again. If you have anything to add to a topic I’ve blogged on, regardless of what you think of what I’ve written, share it. Let’s all learn. Let all our users and customers benefit. Let’s raise the satisfaction in this platform we love. Because anything else only at best minimises the benefits.
Over the last week I have been doing some investigation on dojox charting, building on the XPages tutorial samples of Chris Connor and the pure dojo tutorials of Doug McMaster and Eugene Latzukin on SitePen, the basis for parts of the article on dojocampus. Despite their work, I suffered a number of frustrations trying to produce the charts I wished to. For example, Chris’s sample charts look great, but if I was using the pie chart widget for a customer, their first question would be “What do the portions of the pie represent?” This is not intended as a criticism of Chris’s excellent examples, but how do we extend the example to have a legend or tooltips to provide this information? After quite a bit of investigation, in markup HTML using an HTML table data source, it appears you can’t.
I have come to expect such frustrations when working with dojo because of the patchy nature of the documentation. The examples on the dojocampus site are useful, but it is a little embarrassing that they don’t work on Internet Explorer, when dojo is trumpeted as overcoming cross-browser problems. It usually covers the basics, but if you want to use other properties or functions of the classes, the documentation on them is very limited. There is the dojo api website, which is useful as a list of the properties and functions available for certain releases of dojo, but doesn’t help you implement them – especially if you’re using markup rather than javascript. More often than not the only option, if you wish to implement dojo, is to roll up your sleeves and dig about in the javascript code. I’m by no means a javascript expert but I have written my own extensions of the dojo classes (e.g. a dijit.form.SimpleTextarea that validates with the same styling as the other widgets) and I consider myself good at reading through code and understanding what it’s doing. Nonetheless, I find it daunting and frustratingly time-consuming to wade through the code. That challenge may be too much for some developers. Could we say the quality of the dojo documentation is good enough for them to use it?
These frustrations reminded me of the frequent posts to forums about the quality of the XPages Help documentation, and there seem to be a number of developers out there for whom XPages may even be the first time they have dipped their toes in the waters of web development. Even though I agree that, as ever, some mischievous developers may be jumping on the bandwagon to further their own agendas, nonetheless there is also a demographic amongst our community that are feeling out of their depth. Yes, there are some people who just want someone else to give them all the answers, but there are others who don’t have the skills to be able to work the answers out for themselves.
Who should people turn to for help? Some might say IBM. I would say one another. And the evidence suggests I’m not wrong. Over the last year a whole raft of resources has sprung up on the web around XPages, whether that be through personal blogs, the XPages blog, or the Domino Designer wiki. Through this blog I’ve been in communication with a few developers to try to help with their own challenges. Business partners have also been involved with coordinating XPages training with IBM. And at this time of year we should also mention Lotusphere. Members of our community have been working hard over the last couple of months to produce sessions at Lotusphere, and good luck to them all. I am sure that, as ever, there will be some excellent learning that comes out of those sessions. And for those who cannot attend, like me, there are Lotusphere Comes To You events as well as local LUGs (there’s a session at Lotusphere next week about creating and running a LUG – BOF508 Creating and Running a Lotus User Group Event). There is also the Sandbox on the developerWorks website, and who cannot have used OpenNTF.
If we all work with a silo mentality, individuals might achieve some good things. If we share our knowledge and feed off one another, we can achieve great things. It is that belief that drove me to start this blog, because I felt I had knowledge to contribute to the community and had the confidence to publish it. Don’t get me wrong, with each article I’m always hoping I’m not saying something everyone already knows or something that’s incorrect, and the comments I receive are very encouraging. But I also believed it was part of the duty of a Business Partner to take an active part in the community, which is why this is not a personal blog, but a company blog (and I hope my colleagues will have the confidence to share some of their expertise in the future). By then perhaps I will have the confidence in my expertise and reputation to be more involved in the community outside of this blog.
My point in this article is that without Chris’s sample charts, it would have taken me much longer to do as much as I have with charts. I did not expect all the answers from Chris’s charts, nor would it have been right for me to do so. But this is why I will be writing probably a number of articles of charts, not out of any criticism of anyone else’s work, but because I feel I have learned something that others might benefit from. And equally I don’t expect this to be a definitive resource. If anyone should find errors, please point them out. If anyone extends my examples further and feels they have more to contribute, again please do so. We cannot reach the sky ourselves. But by climbing on one another’s shoulders, maybe we might.
