Standardizing data type customizations across the board I agree is not really a good idea. It could break a lot of things..
What would be nice though is simple cosmetic look and feel of the application. You log in and you see a logout button along with links to go different places.. The least you could expect in terms of screen standardizations is have logout buttons at most screen at the same place with another button to go back to the home page. I think having the Home Page link on the Navigation bar right on top of all other options and the Logout button right at the bottom of all options may be a great idea too.. Might not be a bad idea to have the help option feature there as well.. Sometimes on some screens in some applications you see the Help button but it does nothing, even if you have help installed. Fortunately this works on most screens.. Joe From: Benedetto Cantatore Sent: Thursday, November 11, 2010 9:55 AM To: arslist@ARSLIST.ORG ; jdso...@shyle.net Subject: Re: "Working as designed" type defects Like most, I'm frustrated with the inconsistencies that have been around since version 7.0. Many are cosmetic and merely a matter of rearranging objects. I'm on the bandwagon there, just fix it and make it work the same from form to form. I'm concerned with changing the values of the fields. Is it worth breaking backwards compatibility, modifying all your existing data just to make things more consistent? Is the consistency gained worth the tradeoff in making that change? Ben Cantatore Remedy Manager (914) 457-6209 Emerging Health IT 3 Odell Plaza Yonkers, New York 10701 >>> jdso...@shyle.net 11/10/10 6:37 PM >>> ** Alternately you could customize some of the most frequently used forms to have the Logout button that looks the same as the Home Page and drive that button with a Perform-Application-Exit process.. might take some work, but that would give some degree of consistency on where you can find the Logout link/button.. I absolutely agree that it should have been available a little more through the application to maintain some sort of visual as well as functional consistency.. Joe From: Meyer, Jennifer L Sent: Wednesday, November 10, 2010 6:23 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: "Working as designed" type defects ** We reported that Risk Level/Approval Level defect last year, Tim. Its working as designed! And the Close buttons are a royal pain. There is a fix for the missing workflow, but when there just isnt a Close button thats frustrating. Check out the Object List on the Mid-Tier: no Close, Logout, Home, or New Search. That one drives me up the wall. To log out, you have to search for and open the Home Page, then click Log Out. Jennifer Meyer From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Timothy Powell Sent: Wednesday, November 10, 2010 5:39 PM To: arslist@ARSLIST.ORG Subject: Re: "Working as designed" type defects ** How about the simple fact that Close buttons and/or links are not always in the same location and sometime are not present at all. In CM, Urgency, Impact and Priority use a scale of 1 x with 1 being the most severe and x being the least severe. But the Risk Level values run 1-x with 1 being the least severe and x being the most severe. That ISS ticket came back to us as Working as Designed. The reasoning was that a 1-x scale with 1 being the least severe and x being the most gave the customer the opportunity to extend the Risk Level to accommodate custom risk calculations. But if that is the true design reason, then my argument is that Priority, Impact and Urgency should also be designed that way and also allow that extension capability. Im going to change the ISS ticket to an RFE and see what happens. Like you point out, I just want it to be consistent. Tim From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Meyer, Jennifer L Sent: Wednesday, November 10, 2010 4:50 PM To: arslist@ARSLIST.ORG Subject: Re: "Working as designed" type defects ** Guillame, I feel your pain. I want to respond, not to gripe about the lack of consistency across applications, but because I also noted this while testing the ITSM 7.6 applications. Tasks perform differently across applications, Problem and Known Error have minimal interaction with Task at all, and Saved Searches arent consistent in the consoles. This is how its designed, however, and we are reporting a large number of other defects, so Im personally hoping that providing consistency across lesser-loved applications is BMCs next focus. Jennifer Meyer Remedy Technical Support Specialist State of North Carolina Office of Information Technology Services Service Delivery Division ITSM & ITAM Services Office: 919-754-6543 ITS Service Desk: 919-754-6000 jennifer.me...@nc.gov http://its.state.nc.us E-mail correspondence to and from this address may be subject to the North Carolina Public Records Law and may be disclosed to third parties only by an authorized State Official. From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Guillaume Rheault Sent: Wednesday, November 10, 2010 1:54 PM To: arslist@ARSLIST.ORG Subject: "Working as designed" type defects ** I'm sending this post to the list community to see what is the general feeling about issues that BMC Support classifies as "working as designed" The category of issues I am referring to specifically here is inconsistencies in functionality between ITSM modules or within a single specific module. More specifically, and to name only a few, in ITSM 7.5.1 but apparently still present in 7.6.3: - Assigned group searches in tasks are different than assigned group searches in change - Assigned group searches, change manager group searches, and change implementer group searches are different - Task tab in problem investigation is different than the task tab in the incident form When I raise these issues with BMC support, I get the reply that it's working as designed. Well the problem with that, is that customization is required to make functionality, and look and feel consistent. It seems to me that BMC should create a "Design Defect" classification in addition to the existing defect classification, which are essentially implementation defects. I mean why should I need to create an RFE for something that should work consistently in the first place? Seems like "Working As Designed" is simply an easy way out of the situation. Quality Assurance **should** catch these defects. Is this too much to ask? A defect is a defect because the customer perceives that as a defect, that should be the bottom line. This is not new functionality, only making the functionality and user interface work to the way it is expected. Thoughts? Guillaume _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"