BUG (SERIOUS) - malformed context menu lookup action

Andrew I am simply asking my own questions around the issue MJ raised. They are not unfair questions. For to me as a user, inconsistent interface behaviour is a serious issue whether you call it a bug, design issue or anything else. Users don’t want to necessarily know all the ins and outs of the technical details under the hood and want software where they are not expected to know that stuff in order to understand why things they expect to see are not there.  Therefore hiding behind this is a knee feature when it is really a failure of design (as you are not conceding as I understand that it is not possible) is a response that says as a design team you don’t want to admit you don’t understand your users expectations of wanting a simple, clean an consistent interface with minimal steps. It’s up to FL how they respond when users call out they are missing their expectations but saying sorry that’s a new feature request doesn’t cut it because we know FL operates on their own agenda when it comes to new feature, and those new features often are aimed at a smaller segment of the user community while fixing up what you have missed in existing basic functions in the interface is ignored. Another reason your suggestion is this a new feature does not cut it because new features are what FL has clearly associated with something users pay for, and this is not something you could sell to users as something they would pay for because once again we go back to this is inconsistent interface behaviour because the design team focus too much on the technical internal view instead of the user experience.

Thanks for your time.

Andrew Batishko said:

I'm giving MJ an opportunity to provide additional information about what she is seeing as a "SERIOUS" bug.

It is correct that the application is currently working as designed. This never means that it is operating in an ideal fashion.

It's interesting to me that the expectation is that all things would work with Power Lookup. Depending on how you count, there are probably more things in the context menu that don't work with that tool than do. There are many places in the application where different functionality is available to different types of data.

Having the Power Lookup tool support People/Places/Things would be a new feature. Typically we recommend that requests for these be submitted to the feedback site. Creation of a case is typically used for bug reports.

There are many places in the application where user expectations don't match the way the application behaves. For what I hope are obvious reasons, we try to minimize these. There are many reasons for these differences. Some differences are resolved by a bug fix. Some differences are resolved by implementing a new feature. Some differences are resolved with documentation. Some differences remain in the application over an indefinitely long period of time despite everyone's desire for an application that perfectly meets all expectations.

Thank you Andrew for taking the time to respond. I do appreciate that. On sone points we are going to have to continue to disagree As FL’s actions speak louder than their intent. FL has a long way to go to get back to being the company I first dealt with many years ago and we could spend the next week debating your perception of things as an employee of the company v my perception as an individual customer. But that would bore everyone else to tears and take your focus of more important things. So I’ll leave you with this thought. If all if the customers went away you could all develop the software you as you all think it should function.  With all the customers gone there would be no cash flow for the business. So who would pay your wages or the company’s bills? But you know what we only challenge you to do better, to listen more deeply to your customer, to fix the less glamorous aspects of the software because we believe in the core product you offer, and we believe you as employees of the company are up to the challenge. 

Andrew Batishko said:

DIsciple II said:

For to me as a user, inconsistent interface behaviour is a serious issue whether you call it a bug, design issue or anything else.

I agree, with the caveat that not all examples of inconsistent interface behavior are of equal severity. I would expect some amount of disagreement between users on the level of significance.

DIsciple II said:

Therefore hiding behind this is a knee feature when it is really a failure of design (as you are not conceding as I understand that it is not possible) is a response that says as a design team you don’t want to admit you don’t understand your users expectations of wanting a simple, clean an consistent interface with minimal steps.

I have no problems with admitting to design failures. It was one of the things in my list of sources of differences between application behavior and user expectation, until I took out the list because it was growing long and didn't seem worth iterating. I also stated "This never means that it is operating in an ideal fashion." (which in retrospect is a slightly confusing way to say "Even if the application is working as designed, it's no guarantee that the design is ideal."

DIsciple II said:

It’s up to FL how they respond when users call out they are missing their expectations but saying sorry that’s a new feature request doesn’t cut it

I disagree with what seems to be your assumption that we are rejecting the idea of implementing the Power Lookup feature in question. Cases are written for bugs, which are unintended flaws in the application. Cases may also be written up for new features that are in development and being tested during their first (and occasionally subsequent) beta cycle. The feedback site is intended to track suggestions for new functionality. Directing someone to the feedback site is in no way an indication of the likelihood that an issue will be addressed. It's only an indication of the kind of work required to address it.

DIsciple II said:

Another reason your suggestion is this a new feature does not cut it because new features are what FL has clearly associated with something users pay for

I also disagree with this statement. I recognize that I'm not likely to change your mind here, but for the sake of others reading this, I think you will find a wealth of new features available for free just in Logos 9 alone (to say nothing of the new features added during the life cycle of version 8) which require absolutely no purchase from users. And, in fact, feature improvements to existing functionality (as opposed to brand new features that stand on their own) are usually (though not always) free as opposed to paid improvements. The request made for Power Lookup sounds to me like something that could be considered for a free feature, but would need to be prioritized against other features and bug fixes. A part of the prioritization process is seeing support and feedback from customers on the feedback site.