Now that it's clear to me that the ProductMaint entity is intended to be
used as a type of template for recurring fixed asset maintenances, I'd like to add a data entry screen to the Asset Maintenance component for ProductMaint. I was thinking it would be more understandable for someone in the maintenance role to call it a Fixed Asset Maintenance Template. In other words, the ProductMaint entity would be used, but it would be called a Fixed Asset Maintenance Template in the UI. Also, to keep things simple for the users of Asset Maintenance, if the fixed asset isn't already connected to a product and a ProductMaint is created for it, would it be okay to create a Product record on the fly? What do you think? -Adrian |
The more important and powerful concept is not that there is a template for maintenance, but that a FixedAsset is an instance of a Product. If anything the usefulness of a FixedAsset being associated with a Product should be emphasized more in the UI. For example in the maintenance area if the FixedAsset is not associated with a Product that it is an instance of, then there should be a warning message about that, and that also makes it clear that there is no maintenance schedule because of it, etc. In other words, I don't really like the idea of hiding these sorts of concepts in general. Making them more clear and easier to understand will ultimately make the power of the concepts clear and the patterns in the system, and reusing familiar things like a Product, will become empowering. The approach of hiding these sorts of things may make certain things easier, but overall makes the system more confusing and difficult to use, especially when a user gets out of the area you've tried to make easy and hide the complexity (unless you design an application for very specific tasks, then limit away to optimize it; the generic apps can be used if something comes up that wasn't planned for). -David On Jun 26, 2008, at 3:13 PM, Adrian Crum wrote: > Now that it's clear to me that the ProductMaint entity is intended > to be used as a type of template for recurring fixed asset > maintenances, I'd like to add a data entry screen to the Asset > Maintenance component for ProductMaint. > > I was thinking it would be more understandable for someone in the > maintenance role to call it a Fixed Asset Maintenance Template. In > other words, the ProductMaint entity would be used, but it would be > called a Fixed Asset Maintenance Template in the UI. > > Also, to keep things simple for the users of Asset Maintenance, if > the fixed asset isn't already connected to a product and a > ProductMaint is created for it, would it be okay to create a Product > record on the fly? > > What do you think? > > -Adrian |
Good points, thanks!
-Adrian --- On Sun, 6/29/08, David E Jones <[hidden email]> wrote: > From: David E Jones <[hidden email]> > Subject: Re: Asset Maintenance Idea > To: [hidden email] > Date: Sunday, June 29, 2008, 2:07 AM > The more important and powerful concept is not that there is > a > template for maintenance, but that a FixedAsset is an > instance of a > Product. > > If anything the usefulness of a FixedAsset being associated > with a > Product should be emphasized more in the UI. For example in > the > maintenance area if the FixedAsset is not associated with a > Product > that it is an instance of, then there should be a warning > message > about that, and that also makes it clear that there is no > maintenance > schedule because of it, etc. > > In other words, I don't really like the idea of hiding > these sorts of > concepts in general. Making them more clear and easier to > understand > will ultimately make the power of the concepts clear and > the patterns > in the system, and reusing familiar things like a Product, > will become > empowering. The approach of hiding these sorts of things > may make > certain things easier, but overall makes the system more > confusing and > difficult to use, especially when a user gets out of the > area you've > tried to make easy and hide the complexity (unless you > design an > application for very specific tasks, then limit away to > optimize it; > the generic apps can be used if something comes up that > wasn't planned > for). > > -David > > > On Jun 26, 2008, at 3:13 PM, Adrian Crum wrote: > > > Now that it's clear to me that the ProductMaint > entity is intended > > to be used as a type of template for recurring fixed > asset > > maintenances, I'd like to add a data entry screen > to the Asset > > Maintenance component for ProductMaint. > > > > I was thinking it would be more understandable for > someone in the > > maintenance role to call it a Fixed Asset Maintenance > Template. In > > other words, the ProductMaint entity would be used, > but it would be > > called a Fixed Asset Maintenance Template in the UI. > > > > Also, to keep things simple for the users of Asset > Maintenance, if > > the fixed asset isn't already connected to a > product and a > > ProductMaint is created for it, would it be okay to > create a Product > > record on the fly? > > > > What do you think? > > > > -Adrian |
In reply to this post by David E Jones
So, should fixed asset maintenances in general be disabled when the fixed asset isn't related to a product?
-Adrian --- On Sun, 6/29/08, David E Jones <[hidden email]> wrote: > If anything the usefulness of a FixedAsset being associated > with a > Product should be emphasized more in the UI. For example in > the > maintenance area if the FixedAsset is not associated with a > Product > that it is an instance of, then there should be a warning > message > about that, and that also makes it clear that there is no > maintenance > schedule because of it, etc. |
Administrator
|
Adrian,
From: "Adrian Crum" <[hidden email]> > So, should fixed asset maintenances in general be disabled when the fixed asset isn't related to a product? At some point you have to relate a fixed asset to a product, so I'm not sure of the question... Jacques > -Adrian > > --- On Sun, 6/29/08, David E Jones <[hidden email]> wrote: >> If anything the usefulness of a FixedAsset being associated >> with a >> Product should be emphasized more in the UI. For example in >> the >> maintenance area if the FixedAsset is not associated with a >> Product >> that it is an instance of, then there should be a warning >> message >> about that, and that also makes it clear that there is no >> maintenance >> schedule because of it, etc. > > > > > |
In reply to this post by Adrian Crum-2
It's a good question... and I'm not sure if we need to go that far. It is conceivable that someone would want to track maintenance history without planning for future maintenance, and so they wouldn't need the Product and ProductMaint records. -David On Jun 29, 2008, at 9:15 AM, Adrian Crum wrote: > So, should fixed asset maintenances in general be disabled when the > fixed asset isn't related to a product? > > -Adrian > > --- On Sun, 6/29/08, David E Jones <[hidden email]> wrote: >> If anything the usefulness of a FixedAsset being associated >> with a >> Product should be emphasized more in the UI. For example in >> the >> maintenance area if the FixedAsset is not associated with a >> Product >> that it is an instance of, then there should be a warning >> message >> about that, and that also makes it clear that there is no >> maintenance >> schedule because of it, etc. > > > > |
Free forum by Nabble | Edit this page |