Playing God With End-User's Intentions
While dealing with frustrations with his IDE, a Zone Leader wonders why self-version-checking modules cannot be better in this day and age. While it is likely a possibility, what is the ultimate cost for such an effort?
Join the DZone community and get the full member experience.Join For Free
Recently, I started to see an issue with my IDE locking up after just a few minutes of usage. The situation was really odd, as it seemed that the editor portion of the IDE would cause the program to lock-up when I attempted to allow the intelligent code completion to fire. When this happened, I would have to force the application to quit, then find the task ID of all the servers running in all of the IDE sessions I had open ... and kill them.
The following commands became my friend:
As you might imagine, this became old really fast, and I decided to roll back to the last major release of my IDE. With everything back to working as usual, I was pleased. However, my mind started encountering flashbacks when the IDE self-version-checking module suggested that I upgrade to the version that caused me all of these issues.
I asked myself, "why can software not be better at making suggestions?" I mean, this approach to reminding users that a newer version is available really hasn't changed much since self-version-checking modules became mainstream.
Making Auto-Updates Better
With the situation noted above, I began to ponder just how hard would it be to maintain some metadata capturing my usage of the application? I mean, in this case, I have to login to the vendor's web-site in order to pull down the latest IDE updates. Perhaps, the process to force quit the application could also append to that metadata too?
I feel like some intelligence could be added to the application to understand my situation. In an ideal world, the self-version-checking module could determine that I have already attempted the new version and decided to roll-back to an older version. Asking the customer to upgrade to that same (broken) version would only lead to customer frustration.
Then, when a newer version is released (and I am now two major releases behind in this example), the self-version-checking module could not only alert that the new version is available, but also note how my prior issues have been addressed.
I know it might sound extreme, but I remember when the concept of a self-version-checking module was considered extreme. Back then, the normal was to locate seek any new updates and pull them down manually.
Making Feature Decisions
Now, taking a look at things from a different perspective ...
One of the teams on my current project worked on an application that leverages the CanvasJS and Fabric.js libraries. As they got deep into the details of the implementation, they recognized the need for scrolling and panning functionality that wasn't quite complete in these frameworks.
As a result, the team ended up having to introduce a great deal of custom code to mimic the end-user's expectations on how the scrolling and panning would work. More specifically, the direction in which the scrolling functionality on a mouse, trackpad, and Apple's touchpad seemed to differ. What that meant was, implementing the scroll event in a manner that matched the mouse, did not match the functionality on the trackpad or the touchpad.
In order to get through the MVP (minimum viable product) release, the team initially decided to implement the solution which matches their expectations of the most-common user scenario. As one might expect, it did not take much time before the QA team found these differences.
In the end, the team had to include more custom code to yield the same result, despite the input device in use. They tried to make decisions that would work with everyone but ended up having to code for every possible scenario.
In both of the examples above, the focus is to provide even more functionality to the end-user to provide a better experience:
- be smarter with the updates that are being recommended (considering issues found with the current implementation)
- provide a better way to scroll and pan across the graphical canvas
The fundamental problem with this approach is that we are asking software engineers to assume a God role and make decisions for the end-user. For me, this falls into line with the 80/20 rule (Pareto principle), where software developers spend 80% of their time focusing on the 20% of the application which is considered the most complex features and functionality.
While I wish software was smarter and that we could add intelligence into these self-version-checking routines, I feel like the end result may end up looking like the challenges the design team faced when trying to set a scrolling standard for multiple input devices. The team realized that there wasn't going to be a one-size-fits-all approach for the implementation since devices behaved in the opposite manner — which was not acceptable.
For the developers on the IDE product team to create this intelligence, they would likely have to handle more scenarios than one might expect - especially when the core product interacts with so many different hardware options and operating systems. They would also have to bake-in decisions on what to do, which might differ from the end-users' expectations.
- maybe others would want to see the upgrade message (perhaps the issue was with something unrelated to the IDE)
- maybe end-users would expect the input devices to function differently (push up on a touchpad could be expected to be different than the mouse wheel)
When I take a step back and think about it from that perspective, I would much rather the team be focused on adding new features and functionality and not build the mother of all self-version-checking modules.
Have a really great day!
Opinions expressed by DZone contributors are their own.