uh.. not sure what happened there folks... I managed to hit "send"
without using the mouse. :) So let me try to finish that.... See below
for the "rest of the story"....
On Wed, Mar 19, 2008 at 9:09 PM, Carey Matthew Black
<[EMAIL PROTECTED]> wrote:
> Andy,
>
> I do not believe there are dumb questions. Just questions that are
> asked, and ones that are not asked. :)
>
> In ARS there is this general association between the UI (User
> Interface) and the data storage (database table layout). This is a bit
> artificial in the more general application development universe. It
> has it's advantages, and it's costs. In this case.... you are basing
> your data storage and UI on an existing "application". (An Excel
> spreadsheet is hardly an application in my book, but for now that
> description will do.) As you think about how that idea should be
> implemented in ARS I think you have a few things to consider.
>
> 1) Does the "request parts" and "return parts" data elements have the
> same structure?
> Do they both require all of the same data inputs?
> a Part ID?
> a purchase order?
> a reason for return?
> a reason for purchase?
2) Is the process for "filling out the forms" (for a part request
and/or return) the same?
Do you have the same starting points?
Do you always ask for the same data element next?
Are there any shortcuts that might exist for one that does not
exist for the other? (Lookup based on a previous Purchase request to
make the return "faster"?)
I think you will find that while there are similar data elements,
there are really different processes involved in the two requests.
In the universe of ARS an ARS Form is both a UI and optionally a data
storage definition. It defines how the fields are arranged for the
User and how the data for each field is stored on the database all in
one fell swoop of the mouse. However, you do not have to do things
that way. It is possible to use a Display only form to walk the user
through the process and collect all the data in the desired order, and
then push the data to one or more "back end" data storage forms too.
In your case, it may be as simple as just using two ARS forms. Then
providing the user a way to get to the correct form.
Of it could be more complicated and you could use two (or more) ARS
display only forms to collect the data from the user and two (or more)
other ARS non-display only forms to store the data that the user
supplies.
(As with most design questions, the devil is in the details.)
As a most basic design I would start with a single ARS form for the
"request parts" process.
If at the end of building that you find that the exact same process
could be used for the "return parts" process then your all good with
just one back end form. But you might want a different "user facing"
form to ask for the data with different strings for the condition of a
"return". If so then build a display only form to get that data and at
the end of that process you can store the data in the "request parts"
form.
If at the end of building the "request parts" form you discover that
the "return parts" form is very different then you really have not
lost any time or wasted anything. You just need to start a second form
for the second process. You may find that the two processes share one
common data element (the part) and that it should be an independent
part from either process and just referenced from each of the
processes. In that case you end up with three ARS forms.
I generally find that breaking the application down into tasks(parts
of larger processes) is a good way to layout the data elements and the
UI (user interface) all in one conversation with the business. They
are often very similar to each other, but sometimes they are also very
different than each other too.
I hope that helps explain what I was talking about in more detail. (
If not feel free to let me know what I was not clear about.)
--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)
Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap.... Pick two.
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
