Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About BruceJ

  • Rank
  • Birthday 01/26/1969

Profile Information

  • Gender
  • Location
    Kansas City
  • Interests
    Electronic Medical Records, hospital based

Contact Methods

  • Website URL
  1. I know what you mean, searching for ideal layouts and looks. I'm a psychologist and do a lot of work with industrial and organizational psychology. I have a strong appreciate for the way that people interact with machines, especially computers and the effects of colors and positioning. First - decide if your database is something that is going to be stared at all day long by users, or is it something that will be a quick reference that users will use for a matter of minutes at a time. If your users will be staring at your interface for hours at a time, you are responsible for a large part of their quality or life! There's a reason that many of the software solutions, such as Word, are created in soft grays or subtle blues, these are less taxing on the eyes and do not compete for attention. We have also found in research that Serif fonts have no benefits and may actually slow a user down. One of the best cross platform Sans Serif fonts is Verdana, it can be read even in smaller fonts. Also, remember when placing objects, our eyes will scan the screen and fields from left to right, top to bottom. This means that a catchy object on the left side may distract the user from the rest of the information, as well as note that the bottom left is the least scanned location... This also affects field labels, the most natural path for our eyes are left to right, so labels should go in front of the field, not below or above it. Use this left to right principle to place your information that requires critical analysis on the right half of the screen. As mentioned previously, consistency is important in look, feel and operation because it trains the users what to expect. Inconsistency causes cognitive dissonance and is distracting to the user. For example, buttons should have labels that say what they do, graphics are just candy. The only graphics that are useful are those that we have grown to see in almost all applications, a printer to print, and X to close, arrows to move forward or backward, etc.. If your database is going to be used just briefly by users, you can get a little flashier, but you have less time to "train" the user, so your interface has to be very basic, lots of space between objects. You can choose a more fashionable color if you want to impact mood. For example, deep/dark solid colors increase tension, light pinks and greens can calm, etc.. Look up the psychological effects of colors if you want to play around with this. Again, if the users are going to be using your database for long periods of time, using something other than neutral grays or light blues is going to result in less satisfied users. They may not realize that you are the culprit of their unhappy work life, but you will have an impact on them they will not realize.
  2. If you populate Global fields while running on the server, to content will only be showing for that user. Instead. Un-host the file. Populate the global field, and then host the file again. I'd prefer to use a separate small file with one record and many fields instead of globals, then use a calculation or script to pull the content into your file/record/field you want to use it. This way, you can change these "global" type of fields on the fly without "un-hosting" the whole ******* thing.
  3. Can you be more specific? What type of practice or level of care? e.g. Outpatient Family Practice, Psychiatric Inpatient Hospital, Optometrist Office, Nursing Home, etc. I do many solutions for inpatient and outpatient psychiatric hospitals and counseling offices. There's many fundamental differences depending on what type of service you are wanting to develop for. Also - are you wanting to include a business side of the EMR that includes Utilization Management or, god forbid... billing. Billing seems to be the bug that people have trouble with. My advice, don't reinvent the wheel just because you can. If the business office is happy with some old DOS based system that works.. let it be.
  4. I know this can't be that complicated, but let me make sure I get clarity on this because if I'm wrong, it will be too late to fix in the multi-user environment and will not be under my control to host and edit. My Understanding: In my preferences table with one record, I add regular fields (not global) and then in the same table, I add calc fields, stored globally that pull from the regular fields. Then, in the other tables that I want to use the preferences, I just refer to the global field even though it is in an unrelated table. When hosted on a server, one changes the regular fields in the preference table, record 1 and the global updates of course and is applicable to ALL users? I believe that I understand that the reason for creating the calc version of the global is so that it updates for all users and not just for the user that made the changes. Did I understand this correctly? I've tested it in the single user environment and it works, but I don't have an easy way to check it on a server environment without dragging out another PC and making a mini LAN.
  5. Thanks for the suggestion to use globals. My concern, when this is hosted on a server, user A changes the preferences, but they only change for user A don't they? I understand that globals are ideal for a single user application, but if I want to global to cross over for all users in a multi-user environment, won't this get bungled up when it's hosted on the server? I know in the my past lives, the only way to get a global to show up for all users, was to take the application off of hosting, change the globals while in a single user environment and then host it back up on the server again. Of course this isn't practical since I'm not going to be living in the server room. Perhaps there's some secret to only having one record with globals in it that I'm not aware of.
  6. I'm having a brain fart... I'm setting up a Preferences table with company logos and other reference info, like sensitivity settings for a MetaPhone match, etc. I know I can only have ONE record and they should Not be globals (hosted multi-user database, FMP version 8.5). [color:red]My QUESTION Do I need to set up a matching relationship with every other table that's going to draw from the preferences record?
  7. I did this back w FMP3 and it was tricky to set up because the Citrix people didn't understand how FMP worked. Be sure they know you still need to run FMP on a server or partitioned drive just like you would if you were hosting it over a LAN. Then the actual application that is hosted by Citrix is the CLIENT version of FMP that has to be multi-user licensed otherwise, more than one instance of it running will act as if you've used a single user license on multiple machines and FMP is smart enough not to let this work. Usually, the company that wants to host via Citrix has their own Critrix server. I'm sure there's services that do this out there, but I'll bet you'll need to teach them about FMP and it is NOT MS Access... they'll get it wrong the first several times until they decide to listen to you. Good luck. I think most of these types of needs have gone the way of PHP interface. Might be worth convincing your client to do this instead.
  8. I agree with this want... I hate all the work around stuff but I guess that's what allows us to charge more for our work.. ha ha ha... Kinda the same reason PhotoShop is so dang non-intuitive - to keep the rift raft out and make it seem like you need an expert to work it!
  9. If the Status area with the Rolodex is visible, the scrolling will flip from record to record. Without the status area showing, it just scrolls the screen.
  10. I think it's really good. It flows properly from Left to Right and Top to Bottom with what I understand is the work flow process. This is the natural direction that our eyes have been trained to scan and search. Only thing I can imagine is the bottom section with all the key date fields, you might put these on tabs to spread them out and hide many of them if they aren't always necessary... perhaps they are and a person needs to see all the dates at once to help make a decision. In this case, don't change a thing! I do prefer the delete button on the portal row and the "new button" near the top, but I'd put it on the Left side of the header... again knowing that our eyes scan left to right and you'd want this seen first. Also, most common Delete icons involve a Red X, usually any starburst shape means something's being created. Think of the color blind.
  11. It might be necessary to have two sources of addresses.. if a customers address changed then it would change any historical info on old orders, unless of course you also contained shipping addresses right in the order file that just looked-up the customer's address at time of shipping. I think this is getting more complicated than it has to be. I think the original question was how to see close or near match addresses to avoid duplication. To do this, I'd use some calc fields and relationships. Make a calc field that strips out any numbers or spaces in the street address in both the address file and invoice file. Then create a relationship that matches up these calc fields plus a zip code field. When your user enters the address, the can use a portal to see if any near matches come in and then choose one if its a match or click a button to "make new" or "update".. well that's pretty crude description, but you may get the idea I'm shooting for. There's a lot of ways to skin a cat... but I'd do away with the separate address file and keep it all in the contacts file. I'd also keep addresses in the Orders file. Then I'd enter the address in the order.. use the portal for near matches... or... use a similar method to find the customer from the order file, use a lookup for the shipping address in the order.. and then an "update" button if the address that's pulled in needs to be updated to the customer file. Actually ranking degrees of matching can be done, but that's a bit more sophisticated. It can be done by creating very lengthy matching calc fields and yours would be a bit more complicated unless you used separate fields for HouseNumber and StreetName... hey... that give me an idea.. that might make it quite a bit easier, it's just not a natural way of entering data, but your users will get used to it in about 3 days!
  12. You may want to try using a portal instead of going into find mode and scripting it. To do this you have to have fields dedicated to entering find criteria. Then create a relationship between these fields and the target fields. This way you can just use check boxes for the grades to find and it will include all that you check.
  13. I can't even count tables let alone write accounting type software! Ha That's why I stick to medical/hospital stuff usually. The fourth table was really a Customer table in my mind, but not really a must have unless you plan on doing something with customers repeat business. I personally hate it when I go to buy a simple little widget and the clerk wants all my personal info... I'm paying with cash and want to be anonymous, especially when I'm buying my tin foil hat!
  14. The way I've done my point of sale applications includes Four tables: Inventory (kInventoryID, Description, StartingNumberOnHand, Calc_StartNumb_minus_SUM_QuantitySold) Invoice (kInvoiceID, CustomerID, Calc_SUM_TOTAL_of_LineItems) Line Items (kInvoiceID_Child, kInventoryID_Child, QuantiySold, PriceEach_LookUp, TOTAL_Qty_x_Price) Ok... here's the deal... in the Inventory you have a starting number of items on hand, simply subtract the sum of the quantity in the related line items. If you really need to track serial numbers of items on hand and items sold... then you have to go a different approach and it's like having a unique inventory item for every single item.. pain in the butt. If all you need to do is note the serial number of those sold, you can create a field in the line items to hold it. Of course, you'll need a new line item for each of the same items sold. Note - be sure to work a way to reconcile the inventory through adding a field in the inventory that can be added or subtracted from the OnHand amount as surely items will disappear or reappear. If an item is returned and placed back in inventory, just go to the invoice and change the amount sold to a Negative amount. By the way... QuickBooks will do all this for you, but you don't get to bang your head against the wall figuring it out.
  15. Ok, as much as is pains me to say this, I have a quick and easy sure solution to exactly what you are trying to accomplish... Two words... [color:blue]QuickBooks It will even link to your bank account, keep inventory and all that fancy stuff. I'm all for being creative and independent, but why re-invent the wheel. It's like that old story about NASA spending thousands of dollars to develop a pen to write in zero gravity and varying air pressures.. very sophisticated. The Soviet Union faced the same problem, they used a pencil.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.