The simplest approach is to use one or more portals to list these different orders. A portal filter can limit the orders listed to a specific type and you can sort the portal to list the newest first if that is useful. A button in the portal row can use Go To Related Records to bring up that record on a different layout.
Right, that was the plan. The question is, would you create a list specifically for the dashboard layout or just pick an existing list even though it's records will not be used?
I imagine a 'join table' would serve best for this type of display (i.e. a new table with foreign keys to to the primary keys of other tables you want to correlate), as it allows the many-to-many relationships you probably need
you probably want to also look at the selector-connector technique (although that's a bit more mind-bending), as this would allow data from different sources to be shown in the same portal:
hope that helps
I like the 'connector' idea. Since this layout might display data from anywhere, it might as well be, in the context of a connector table. It's arbitrary, but neater. The data will all be in filtered portals.
I see no need for a join table. You should be able to link the table occurrence for your dashboard layout directly to orders. A Cartesian join with portal filter may be used for this.
I would suggest ignoring portals and instead using reports activated by a search script. Reports are thousands of times more powerful than a portal since you can build hierarchies, etc.
What often happens is that rather than understand a clients needs, a designer just throws a lot of ideas into menu choices, buttons, etc.
Working with mostly the iPhone, I have been forced to abandon all of the layout gimmicks that impressed me and try to make simple list like displays and most of all to begin to understand what the user would want to see.
Replaccing dozens of portals, etc that may only confuse the user with a few starting buttons that then move to another layout with a few other options is quick and simple (just don't extend the drill down past three or four layouts as one accountant/developer did in the 80s with a bookkeeping application which after 12 drill throughs still could not change the amount entered for a check).
For instance, in a personal shopping cart app for groceries, etc, I first created a complex interface and after much stress finaly limited it an opening screen with a few choices:
View all items
View all stores
View shopping cart
and one or two more.
Basically I look at the items to see what I need to buy. A button shows me the ones not selected and I can check items to buy. Then I pick the store I am in or going to and all of the items I've checked show up in that stores report. Oh, the items that are available at any store will show up there. Buying one and unchecking it unchecks them for all stores.
I can also email a list of items to pick up to anyone who is at a store.
Rather than overwhelm myself with 6 portals on one layout, I use a few buttons to run a report that gives me all the info.
Of course there are times when many portals and graphs are needed providing real time views of sensors.
I would suggest that rather than try to use all of the FMP technology you can, that you ask the users what it is they need and provide that.
I understand what you're saying, but in this case, I'm the client (this is for my own automotive business), The concept is to re-create something similar to the paper systems typically used which, in part, you'd call a "rack" of repair orders. The dashboard concept, as I see it, is rather like that of a car where everything you need to do the job is lined up in front of you. The basic front desk functions are to create estimates, appointments and repair orders from customers on the phone and who walk in, take payments and print invoices and receipts. I want this to be done in the simplest way, with the fewest user inputs possible, in part because the "user" isn't necessarily much of a computer person. Portals seem to me the best, if not the only way to do this. I'm just starting to put it together now, so we'll see how it goes...
For something like this you would start from a "session" table and user login record specific. I create a new session record each time a user logs in, they operate from and through that session relationship. This serves two purposes as it records the login attempts as well. You will also need the concept of a "constant" value or unifying field where you keep a single record in every table you wish to display in the display equal to that of the session, in my case I use, 1.
Does this make sense? I can go further but this might be enough!
Hope it helps!!
1 of 1 people found this helpful
Since this is for your own use, you don't need support for multiple sessions. All you need is this relationship:
Dashboard::AnyField X RepairOrders::AnyField
To list your repair orders orders with a status of "open", use a portal to RepairOrders with this portal filter expression:
RepairOrders::Status = "Open"
To get a portal listing incomplete repair orders, make a copy of this portal and change the portal filter to filter for incomplete repair orders.
Note that hat you will need at least one record in dashboard.
Good idea, but since my company is now two people, and if all goes well, as many as four later this year, it's not really needed yet, but if this works out well (if I finish it!) I'd imagined sending it out as share ware. This would be a good feature for the "released" version!
Maybe, maybe not.
Will each user need anything different from the other?
Dashbords are not normally used to edit data but rather to view it--with buttons like you describe to pull up detail views where the actual editing takes place.
If that's the case here, then I see no need to complicate your solution with support for different sessions for each user.
Its simple to link to 2 fields rather than just one for an easy filter of a portal.
Each record has the created by Account Name field plus the ID field.
On the dashboard there are two global fields. One for data entry and the other which is a calc for Account Name. Thus each record is now linked by creator and data entry in the global.
So, two layouts one links with creator and one just uses one field for data field.
I agree and thus no need for managing "sessions". Also, the original description here does not seem to indicate the need for even that as I think that you'd want to see all "open" or "incomplete" work orders in most cases and not just those by the current user.
But I freely admit that I may be making an incorrect assumption as to the scale of this business.
There is also the issue of not wanting employees to see some information.
For instance in the construction industry a sucessful contractor has to deal with the problem of employees wanting to become a competing contractor and finding the customer list interesting and the bids. Hey, I can under bid and get the job.