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
