I’ve deliberately worded this blog post and I’ve been meaning to write it for a while. Along with the jams, this is your opportunity to revolutionise these platforms. No doubt a lot of what I’m saying was what I also said back in January when, for the Domino2025 jams, I appealed to everyone to think big. I feel I need to repeat the bullet points from that blog post:
- Take a step back and think beyond a specific use case requirement
- Don’t focus on detail of an individual feature, focus on direction
- Back it up with justifications
- Be aware of the announcements at IBM Connect last year and where the product has moved since, and especially what’s upcoming in FP10
Particularly on that last point, I want to mention IdeaJam, because I’ve seen and heard that mentioned in terms of the ideas there. Before I went on a Domino2025 jam I methodically went through all ideas on IdeaJam with more than 100 votes. A high percentage were already in the product. A number of others were stale. The product has moved on significantly since 2011, the expectations of developers and users have changed significantly. It’s time to let that go and think afresh.
Now more than ever it’s also important to step back, review those jams, the kinds of things the community was asking for and the kinds of things announced since. At the time I thought I was thinking big when recommending replacing the Notes Client with a Chromium application. That kind of thinking has been echoed to some extent by HCL Places, but its use of a Progressive Web App, integration of way more than we have in Notes Client and talk about using some kind of push technology to update the PWA from the server all go way beyond what I was advocating. And who in the jams was expecting as outcomes HCL Nomad (Notes on iPad with iPhone and Android to follow), DominoDB node module with more to follow, gRPC to improve performance and the recently announced DQL to make querying easier and more powerful?
And who was thinking of a reinvention of low code with Domino at its heart and round-tripping for no code/low code/high code? Without using Domino Designer? And with a fresh, modern UI for users?
These are the kinds of ideas that will grow the platform rather than keep customers hanging on for a few more years.
It’s a shame that much of what I’ve read on the Domino ideas site don’t excite me. The highest rated at the moment is increasing the size of the document properties box and making it resizable. Yes, it’s a pain point. But it’s narrow in focus. How will this help people using Domino for traditional web development? How will it help identifying if an email in V10 and beyond was sent delayed? How will it help XPages developers? How will it help people supporting HCL Nomad? How will it benefit people using the DominoDB module?
This is why I entered a different idea. Making the content of Document Properties an API. And extending it. Making it filterable, sortable, searchable. I’ve put a lot of thought into it and spent a lot of time. I thought about all developers. I spent the time to give justification and benefits. I thought about some additional information that it might be useful to add. I thought about additional functionality it might support. I raised challenges, like how to have it sortable for LotusScript or how to handle duplicate field names. And I’m still thinking of additional benefits – as an API, it could be used to copy as JSON and build as an audit. It could also be used for deletion logging.
It’s not a world-changing thought. But it’s bigger, with greater justification and thinking of a wider audience than many ideas. It considers what’s available in other SQL or NoSQL databases. It delivers support information that will make Domino way more powerful than some of the competition we’re starting to go over. Does Cloudant or MongoDb allow you to get a collection of fields changed since date X or on last save? I know whenever my Domino applications have interacted with other non-Domino databases it’s often hard to get answers on what was changed when (though it’s unclear if this is a limitation of the database or the support technician). It also means I’m more likely to get functionality that I want, not what I asked for. And as application developers, we know how often we get a request for functionality that’s not been thought through fully, which results in scope creep, changes to the request or additional requests because what was wanted wasn’t made clear in the initial request.
Yes, there are pain points that need addressing. But any development costs. Working on feature X means delaying feature Y.
I haven’t looked specifically at the ideas in thsi context, but it’s also worth reiterating. Building something into the product that’s already available elsewhere at a cost from a business partner means instead of you paying for it, everyone pays for it – in lack of progress on other products. We’re seeing some products being acquired – it was done with XPages, there was an annoucement at CollabSphere about MarvelClient, and in Connections we have ICEC. But I will always be very firmly against any idea that IBM / HCL should build functionality that a business partner – and their developers – have made and continue to make their living from while also advocating the platform.
This is our opportunity to shape the product. And it’s right that we should do so in a way that builds for the future, rather than just treading water. And we also need to be very mindful of what the world outside our yellow bubble expects, both as developers and users. Now is the time to broaden our horizons and build products that can better compete with the competition.