Re: Change Diary Field Font
Ok, but this RFE was previously accepted and slated to be implemented in a future release. In other words according to the notes it had made the cut. Now if it truly DIDN'T make the cut, then I would have expected somebody to inform me. Closing previously accepted AND approved RFEs merely due to age = not cool. BTW, bell was rung. It was confirmed that the RFE was closed merely because of age. RFE has been re-opened under a new number. Tim Powell -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Easter, David Sent: Friday, December 04, 2009 2:05 PM To: arslist@ARSLIST.ORG Subject: Re: Change Diary Field Font So I guess I need to ring somebody's bell and see why they decided to close it when was outstanding for a long time due to BMC not implementing it. Just to follow up on this, BMC tends to be aggressive in closing RFEs that have not been implemented across multiple release vehicles. In other words, if an RFE is logged against version 2.0, was not accepted for implementation in version 3.0 or 4.0, and isn't expected to make it into 5.0; it is a strong candidate for just closing it. This is done in an effort to be honest with those logging the RFE that it has not made the cut several times and therefore is not very likely to ever be implemented as described. For example, this RFE was submitted in June of 2005. It was closed in February of 2009 - about 4 years later. There are pros and cons to leaving RFEs open forever, which I'm not going to debate here, but I'm just letting you know why RFEs get closed even though they were originally excepted but not implemented. Even though a specific RFE is closed, the general capability might be part of a larger theme or broad enhancement found in a future release. Product Management does take into account smaller and historic point RFEs when making larger decisions around product direction - even if the point RFE had been closed as no plans to implement within a particular time period. For example, were a broader move made in a future release to support Rich Text or HTML formatting in character based fields, and that would subsume both this and other such formatting RFEs logged over the years. -David J. Easter Sr. Product Manager, Solution Strategy and Development BMC Software, Inc. The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or public relations representative for BMC Software, Inc. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Timothy Powell Sent: Wednesday, December 02, 2009 10:45 AM To: arslist@ARSLIST.ORG Subject: Re: Change Diary Field Font Here is the latest on the RFE: Regarding: RFE0009445, at 2/3/2009 2:58:05 PM, created by x Hi , We have reevaluated this RFE and since it's been outstanding for a long time, we feel that this RFE won't be practical for us to implement now. *** So I guess I need to ring somebody's bell and see why they decided to close it when was outstanding for a long time due to BMC not implementing it. Tim On Wed, 2009-12-02 at 12:43 -0500, Carey Matthew Black wrote: I think this could be done in the v7.1 Mid-Tier with a custom CSS for the field. I also think the v6.3's Mid-Tier could also be customized (with more effort, but in a similar way) too. However for the User Tool I think we are out of luck for the kind of specific (single field) font change. However, as a form of workarounds... ) Maybe the text could be converted to a View field and displayed with specific font settings in that display. It may not be trivial to implement, but I think it could be done. ) Another approach would be to give the users a report button that would preview the field's content. So that the effort the user needs to take to see the fixed width content is reduced to a single button click. Just a few thoughts. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Change Diary Field Font
Ok, but this RFE was previously accepted and slated to be implemented in a future release. In other words according to the notes it had made the cut. Not exactly. 99.9% of the time, RFE's are not accepted - they are put Under Consideration. That means the RFE will be considered during the release planning of the listed targeted release - but does not necessarily mean it will be implemented. More RFEs are placed Under Consideration than get into any given release and thus RFEs that cannot be implemented due to technology limitations, conflicting business priorities or time restraints can be further deferred. Think of it somewhat like elimination rounds in a game show. If the initial RFE submission is placed under consideration, that means the review committee felt it was a reasonable idea and that it could go on to be assessed during the planning stage of the targeted release. If, during the planning stage, the RFE is found to meet the criteria for inclusion in the release, then it will be scoped further and tentatively placed into the backlog for that release. If all goes well, it gets into the release - but changes in priority always happen and even once it's in the backlog for the release, there's still a chance that something of higher priority may defer it to a later release. If it's deferred to a later release, it will be reviewed again during that future planning session and the cycle continues. We try to be very explicit about these facts in communication with customers so that we stay cool with their expectations. The RFE process, for example, is found here: http://www.bmc.com/support/review-policies and documents what the various statuses mean. -David J. Easter Sr. Product Manager, Solution Strategy and Development BMC Software, Inc. The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or public relations representative for BMC Software, Inc. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Timothy Powell Sent: Monday, December 07, 2009 11:29 AM To: arslist@ARSLIST.ORG Subject: Re: Change Diary Field Font Ok, but this RFE was previously accepted and slated to be implemented in a future release. In other words according to the notes it had made the cut. Now if it truly DIDN'T make the cut, then I would have expected somebody to inform me. Closing previously accepted AND approved RFEs merely due to age = not cool. BTW, bell was rung. It was confirmed that the RFE was closed merely because of age. RFE has been re-opened under a new number. Tim Powell -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Easter, David Sent: Friday, December 04, 2009 2:05 PM To: arslist@ARSLIST.ORG Subject: Re: Change Diary Field Font So I guess I need to ring somebody's bell and see why they decided to close it when was outstanding for a long time due to BMC not implementing it. Just to follow up on this, BMC tends to be aggressive in closing RFEs that have not been implemented across multiple release vehicles. In other words, if an RFE is logged against version 2.0, was not accepted for implementation in version 3.0 or 4.0, and isn't expected to make it into 5.0; it is a strong candidate for just closing it. This is done in an effort to be honest with those logging the RFE that it has not made the cut several times and therefore is not very likely to ever be implemented as described. For example, this RFE was submitted in June of 2005. It was closed in February of 2009 - about 4 years later. There are pros and cons to leaving RFEs open forever, which I'm not going to debate here, but I'm just letting you know why RFEs get closed even though they were originally excepted but not implemented. Even though a specific RFE is closed, the general capability might be part of a larger theme or broad enhancement found in a future release. Product Management does take into account smaller and historic point RFEs when making larger decisions around product direction - even if the point RFE had been closed as no plans to implement within a particular time period. For example, were a broader move made in a future release to support Rich Text or HTML formatting in character based fields, and that would subsume both this and other such formatting RFEs logged over the years. -David J. Easter Sr. Product Manager, Solution Strategy and Development BMC Software, Inc. The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or public relations representative
Re: Change Diary Field Font
Uncle. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Easter, David Sent: Monday, December 07, 2009 4:21 PM To: arslist@ARSLIST.ORG Subject: Re: Change Diary Field Font Ok, but this RFE was previously accepted and slated to be implemented in a future release. In other words according to the notes it had made the cut. Not exactly. 99.9% of the time, RFE's are not accepted - they are put Under Consideration. That means the RFE will be considered during the release planning of the listed targeted release - but does not necessarily mean it will be implemented. More RFEs are placed Under Consideration than get into any given release and thus RFEs that cannot be implemented due to technology limitations, conflicting business priorities or time restraints can be further deferred. Think of it somewhat like elimination rounds in a game show. If the initial RFE submission is placed under consideration, that means the review committee felt it was a reasonable idea and that it could go on to be assessed during the planning stage of the targeted release. If, during the planning stage, the RFE is found to meet the criteria for inclusion in the release, then it will be scoped further and tentatively placed into the backlog for that release. If all goes well, it gets into the release - but changes in priority always happen and even once it's in the backlog for the release, there's still a chance that something of higher priority may defer it to a later release. If it's deferred to a later release, it will be reviewed again during that future planning session and the cycle continues. We try to be very explicit about these facts in communication with customers so that we stay cool with their expectations. The RFE process, for example, is found here: http://www.bmc.com/support/review-policies and documents what the various statuses mean. -David J. Easter Sr. Product Manager, Solution Strategy and Development BMC Software, Inc. The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or public relations representative for BMC Software, Inc. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Timothy Powell Sent: Monday, December 07, 2009 11:29 AM To: arslist@ARSLIST.ORG Subject: Re: Change Diary Field Font Ok, but this RFE was previously accepted and slated to be implemented in a future release. In other words according to the notes it had made the cut. Now if it truly DIDN'T make the cut, then I would have expected somebody to inform me. Closing previously accepted AND approved RFEs merely due to age = not cool. BTW, bell was rung. It was confirmed that the RFE was closed merely because of age. RFE has been re-opened under a new number. Tim Powell -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Easter, David Sent: Friday, December 04, 2009 2:05 PM To: arslist@ARSLIST.ORG Subject: Re: Change Diary Field Font So I guess I need to ring somebody's bell and see why they decided to close it when was outstanding for a long time due to BMC not implementing it. Just to follow up on this, BMC tends to be aggressive in closing RFEs that have not been implemented across multiple release vehicles. In other words, if an RFE is logged against version 2.0, was not accepted for implementation in version 3.0 or 4.0, and isn't expected to make it into 5.0; it is a strong candidate for just closing it. This is done in an effort to be honest with those logging the RFE that it has not made the cut several times and therefore is not very likely to ever be implemented as described. For example, this RFE was submitted in June of 2005. It was closed in February of 2009 - about 4 years later. There are pros and cons to leaving RFEs open forever, which I'm not going to debate here, but I'm just letting you know why RFEs get closed even though they were originally excepted but not implemented. Even though a specific RFE is closed, the general capability might be part of a larger theme or broad enhancement found in a future release. Product Management does take into account smaller and historic point RFEs when making larger decisions around product direction - even if the point RFE had been closed as no plans to implement within a particular time period. For example, were a broader move made in a future release to support Rich Text or HTML formatting in character based fields, and that would subsume both this and other such formatting RFEs logged over the years. -David J. Easter Sr. Product Manager, Solution Strategy and Development BMC Software, Inc. The opinions, statements, and/or suggested courses of action
Re: Change Diary Field Font
So I guess I need to ring somebody's bell and see why they decided to close it when was outstanding for a long time due to BMC not implementing it. Just to follow up on this, BMC tends to be aggressive in closing RFEs that have not been implemented across multiple release vehicles. In other words, if an RFE is logged against version 2.0, was not accepted for implementation in version 3.0 or 4.0, and isn't expected to make it into 5.0; it is a strong candidate for just closing it. This is done in an effort to be honest with those logging the RFE that it has not made the cut several times and therefore is not very likely to ever be implemented as described. For example, this RFE was submitted in June of 2005. It was closed in February of 2009 - about 4 years later. There are pros and cons to leaving RFEs open forever, which I'm not going to debate here, but I'm just letting you know why RFEs get closed even though they were originally excepted but not implemented. Even though a specific RFE is closed, the general capability might be part of a larger theme or broad enhancement found in a future release. Product Management does take into account smaller and historic point RFEs when making larger decisions around product direction - even if the point RFE had been closed as no plans to implement within a particular time period. For example, were a broader move made in a future release to support Rich Text or HTML formatting in character based fields, and that would subsume both this and other such formatting RFEs logged over the years. -David J. Easter Sr. Product Manager, Solution Strategy and Development BMC Software, Inc. The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or public relations representative for BMC Software, Inc. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Timothy Powell Sent: Wednesday, December 02, 2009 10:45 AM To: arslist@ARSLIST.ORG Subject: Re: Change Diary Field Font Here is the latest on the RFE: Regarding: RFE0009445, at 2/3/2009 2:58:05 PM, created by x Hi , We have reevaluated this RFE and since it's been outstanding for a long time, we feel that this RFE won't be practical for us to implement now. *** So I guess I need to ring somebody's bell and see why they decided to close it when was outstanding for a long time due to BMC not implementing it. Tim On Wed, 2009-12-02 at 12:43 -0500, Carey Matthew Black wrote: I think this could be done in the v7.1 Mid-Tier with a custom CSS for the field. I also think the v6.3's Mid-Tier could also be customized (with more effort, but in a similar way) too. However for the User Tool I think we are out of luck for the kind of specific (single field) font change. However, as a form of workarounds... ) Maybe the text could be converted to a View field and displayed with specific font settings in that display. It may not be trivial to implement, but I think it could be done. ) Another approach would be to give the users a report button that would preview the field's content. So that the effort the user needs to take to see the fixed width content is reduced to a single button click. Just a few thoughts. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Change Diary Field Font
Is there a way to change the display font in a diary field without messing up every form in my system? This is an email I got from one of my users: Is there any way I can tell remedy to use a monospaced font in the Work Log when displaying on the screen? It does use a monospaced font when printing the log, but displays the log on the screen with a proportional font. The result is often ugliness on the screen. For instance, here is a HealthQuest display from the work log of a recent ticket I worked: ACTIVITY BY PATIENT THE WOODLANDS B W TW 12/02/09 02:24 XYZZX, OXXXR W03X00 PATIENT HISTORY OF ACTIVITY -- Log Dte/Tm Visit Func Actv Eff Date/Time Loc Room-Bd Ac Srv Tp Dis By St 120109 2258 9335 XFER XFER 12/01/09 22:58 WNL6 6254-01 IP MED Z2R A 120109 2059 9335 ADM ADM 12/01/09 19:57 VUTW ED01-01 SP MED HHT A 120109 1610 9335 ERTW ERRG 12/01/09 15:45 EDTW EC EMR HHT A 120109 1546 9335 ERTR ERTR 12/01/09 15:45 EDTW EC EMR HHT X This is very hard to follow. Here is what it should look like (it actually prints like this even though the screen looks like the above): ACTIVITY BY PATIENT THE WOODLANDS B W TW 12/02/09 02:24 XYZZX, OXXXR W037X0 PATIENT HISTORY OF ACTIVITY -- Log Dte/Tm Visit Func Actv Eff Date/Time Loc Room-Bd Ac Srv Tp Dis By St 120109 2258 9335 XFER XFER 12/01/09 22:58 WNL6 6254-01 IP MED Z2R A 120109 2059 9335 ADM ADM 12/01/09 19:57 VUTW ED01-01 SP MED HHT A 120109 1610 9335 ERTW ERRG 12/01/09 15:45 EDTW EC EMR HHT A 120109 1546 9335 ERTR ERTR 12/01/09 15:45 EDTW EC EMR HHT X ARS 6.3 Patch 21 HD 6.0 Oracle 10.2.0.4.0 w/9 libraries Oracle lives on a remote server Windows 2003 4 gig on app server and 8 gig on DB server Claire Sanford Information Systems Division Memorial Hermann Healthcare System Phone: 713 448 6035 claire.sanf...@memorialhermann.org ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Change Diary Field Font
I entered this as an RFE to BMC about 2 years ago. Last I looked, the status of the RFE was Slated for future release. Tim Powell On Wed, 2009-12-02 at 11:04 -0600, Sanford, Claire wrote: ** Is there a way to change the display font in a diary field without messing up every form in my system? This is an email I got from one of my users: Is there any way I can tell remedy to use a monospaced font in the Work Log when displaying on the screen? It does use a monospaced font when printing the log, but displays the log on the screen with a proportional font. The result is often ugliness on the screen. For instance, here is a HealthQuest display from the work log of a recent ticket I worked: ACTIVITY BY PATIENT THE WOODLANDS B W TW 12/02/09 02:24 XYZZX, OXXXR W 03X00 PATIENT HISTORY OF ACTIVITY -- Log Dte/Tm Visit Func Actv Eff Date/Time Loc Room-Bd Ac Srv Tp Dis By St 120109 2258 9335 XFER XFER 12/01/09 22:58 WNL6 6254-01 IP MED Z2R A 120109 2059 9335 ADM ADM 12/01/09 19:57 VUTW ED01-01 SP MED HHT A 120109 1610 9335 ERTW ERRG 12/01/09 15:45 EDTW EC EMR HHT A 120109 1546 9335 ERTR ERTR 12/01/09 15:45 EDTW EC EMR HHT X This is very hard to follow. Here is what it should look like (it actually prints like this even though the screen looks like the above): ACTIVITY BY PATIENT THE WOODLANDS B W TW 12/02/09 02:24 XYZZX, OXXXR W 037X0 PATIENT HISTORY OF ACTIVITY -- Log Dte/Tm Visit Func Actv Eff Date/Time Loc Room-Bd Ac Srv Tp Dis By St 120109 2258 9335 XFER XFER 12/01/09 22:58 WNL6 6254-01 IP MED Z2R A 120109 2059 9335 ADM ADM 12/01/09 19:57 VUTW ED01-01 SP MED HHT A 120109 1610 9335 ERTW ERRG 12/01/09 15:45 EDTW EC EMR HHT A 120109 1546 9335 ERTR ERTR 12/01/09 15:45 EDTW EC EMR HHT X ARS 6.3 Patch 21 HD 6.0 Oracle 10.2.0.4.0 w/9 libraries Oracle lives on a remote server Windows 2003 4 gig on app server and 8 gig on DB server Claire Sanford Information Systems Division Memorial Hermann Healthcare System Phone: 713 448 6035 claire.sanf...@memorialhermann.org _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Change Diary Field Font
I think this could be done in the v7.1 Mid-Tier with a custom CSS for the field. I also think the v6.3's Mid-Tier could also be customized (with more effort, but in a similar way) too. However for the User Tool I think we are out of luck for the kind of specific (single field) font change. However, as a form of workarounds... ) Maybe the text could be converted to a View field and displayed with specific font settings in that display. It may not be trivial to implement, but I think it could be done. ) Another approach would be to give the users a report button that would preview the field's content. So that the effort the user needs to take to see the fixed width content is reduced to a single button click. Just a few thoughts. -- Carey Matthew Black BMC Remedy AR System Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap Pick two. On Wed, Dec 2, 2009 at 12:25 PM, Timothy Powell timothy.pow...@pbs-consulting.com wrote: I entered this as an RFE to BMC about 2 years ago. Last I looked, the status of the RFE was Slated for future release. Tim Powell On Wed, 2009-12-02 at 11:04 -0600, Sanford, Claire wrote: ** Is there a way to change the display font in a diary field without messing up every form in my system? This is an email I got from one of my users: Is there any way I can tell remedy to use a monospaced font in the Work Log when displaying on the screen? It does use a monospaced font when printing the log, but displays the log on the screen with a proportional font. The result is often ugliness on the screen. For instance, here is a HealthQuest display from the work log of a recent ticket I worked: ACTIVITY BY PATIENT THE WOODLANDS B W TW 12/02/09 02:24 XYZZX, OXXXR W 03X00 PATIENT HISTORY OF ACTIVITY -- Log Dte/Tm Visit Func Actv Eff Date/Time Loc Room-Bd Ac Srv Tp Dis By St 120109 2258 9335 XFER XFER 12/01/09 22:58 WNL6 6254-01 IP MED Z2R A 120109 2059 9335 ADM ADM 12/01/09 19:57 VUTW ED01-01 SP MED HHT A 120109 1610 9335 ERTW ERRG 12/01/09 15:45 EDTW EC EMR HHT A 120109 1546 9335 ERTR ERTR 12/01/09 15:45 EDTW EC EMR HHT X This is very hard to follow. Here is what it should look like (it actually prints like this even though the screen looks like the above): ACTIVITY BY PATIENT THE WOODLANDS B W TW 12/02/09 02:24 XYZZX, OXXXR W 037X0 PATIENT HISTORY OF ACTIVITY -- Log Dte/Tm Visit Func Actv Eff Date/Time Loc Room-Bd Ac Srv Tp Dis By St 120109 2258 9335 XFER XFER 12/01/09 22:58 WNL6 6254-01 IP MED Z2R A 120109 2059 9335 ADM ADM 12/01/09 19:57 VUTW ED01-01 SP MED HHT A 120109 1610 9335 ERTW ERRG 12/01/09 15:45 EDTW EC EMR HHT A 120109 1546 9335 ERTR ERTR 12/01/09 15:45 EDTW EC EMR HHT X ARS 6.3 Patch 21 HD 6.0 Oracle 10.2.0.4.0 w/9 libraries Oracle lives on a remote server Windows 2003 4 gig on app server and 8 gig on DB server Claire Sanford Information Systems Division Memorial Hermann Healthcare System Phone: 713 448 6035 claire.sanf...@memorialhermann.org _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Change Diary Field Font
Here is the latest on the RFE: Regarding: RFE0009445, at 2/3/2009 2:58:05 PM, created by x Hi , We have reevaluated this RFE and since it's been outstanding for a long time, we feel that this RFE won't be practical for us to implement now. *** So I guess I need to ring somebody's bell and see why they decided to close it when was outstanding for a long time due to BMC not implementing it. Tim On Wed, 2009-12-02 at 12:43 -0500, Carey Matthew Black wrote: I think this could be done in the v7.1 Mid-Tier with a custom CSS for the field. I also think the v6.3's Mid-Tier could also be customized (with more effort, but in a similar way) too. However for the User Tool I think we are out of luck for the kind of specific (single field) font change. However, as a form of workarounds... ) Maybe the text could be converted to a View field and displayed with specific font settings in that display. It may not be trivial to implement, but I think it could be done. ) Another approach would be to give the users a report button that would preview the field's content. So that the effort the user needs to take to see the fixed width content is reduced to a single button click. Just a few thoughts. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
