My job this week was to sit in with our medical coders to find out how we could make their life easier. One of the items mentioned by many of them was the requirement to type in the full ICD-9 code including the decimal point. Other software does not require this as the decimal point always occurs at position 3 according to them. If other software does it then it must not be too hard right?
If fact our FoxPro based product does not require you to type the decimal place. As we convert people from that product to the new Java / Cloud based product this has been a sticking point with them and for good reason. Your data entry staff wants to type the least number of keys possible.
Being a non-tainted innocent comes in handy when programming. I had no background on this issue. I implemented and tested the code in a hour or so. We are using a JIDE shrinkable / searchable combobox table to handle the data entry for this field. As you type the visible content of the table shrinks until it becomes the one matching code. I updated the shrinkable and searchable code to handle everything with and without the decimal point. I also found E codes have the decimal point at the 4th position instead of the 3rd and S codes don't have a decimal point at all. Code a couple of IF statements and those rules work as well. Put in a boolean so you only set this special processing when you are on a diagnosis field and I am done.
I begin to tell people I fixed the issues and they start to have fits! You are going to break all the old clients! I have told everyone you can't have that! The decimal point is right on the numeric keypad, they can type it! Whoa there, I did not break anything. You can still type the decimal point like before, if you skip typing it I do the search with it in the proper place. I handle the edge cases.
People were saying NO NO NO because they only saw one side of the solution. They hit the "it will break others" point and stopped. I had no intention of breaking existing user's data entry habits, never ever considered that a viable option. When programmers are not involved in decisions then this sort of thing will happen. They don't ask the programmer because they have already determined it is too hard or impossible. They will then turn around and require you do something that is nearly impossible that they feel is super easy. Your company needs to have a good feature request vetting process in place. It never hurts to ask but is sure can hurt to not ask.
Everyone has calmed down at this point. They really are happy this feature is in place. Our medical coders are going to be really happy when the new release comes their way in a few weeks. QA will have to get it a solid beating before it is released but the testing is pretty straight forward.
I am ready to move on to the next seemingly impossible issue.
Showing posts with label JIDE. Show all posts
Showing posts with label JIDE. Show all posts
Tuesday, August 21, 2012
Wednesday, March 14, 2012
Win 7 Professional always freezes at 15% during patch installs
Various machines around the office - all Win7 64bit Professional - freeze during patch install shut down at 15% complete. We hit the reset button, tell it to boot normally when prompted and the patches install just fine. This has happened every time over the past year that we have installed patches. I don't have this issue at home where I am running Win7 64bit Ultimate and Home. Annoying but does not seem to be a show stopper.
I have completed my work on the JIDE update. There are some outstanding issues but others are fixing them while I get back hot and heavy on the MigCalendar scheduler replacement. I have some open Mac issues with Jidesoft. They don't appear to do much testing on the Mac which is a shame. You can basically use the main OS look and feel on the Mac but the other ones are useless. Colors that are not readable, tabs that are not clipped so they paint on other tabs etc.
I was doing various bits of editing of the code under IntelliJ 11 on the Mac and PC and ended up getting SVN all confused. I finally just extracted a fresh copy of the code and renamed the directory to get the Mac to play nice again. I was doing weird stuff like double editing files on my home PC and the Mac laptop then trying to revert on one and check in on the other. Classes were moved to new packages etc. which I am sure caused a great deal of grief. All fixed now, just some of the fun of being a multi-platform developer.
The MigCalendar conversion is going nicely. The new JIDE based grid is so much faster at everything you can hardly believe it is functional, it feels like something should be missing otherwise how can it be this fast? MigCalendar has a lot of wonky ways of doing things and used a lot of static collections to do it. Glad to be rid of it. I did a build yesterday with no MigCalendar references in it at all. I deleted a ton of code and old dialog boxes in the process. Plus the new scheduler is so much more flexible and configurable. The clients are going to be elated when we ship.
I plan on writing an email to the MigCalendar folks letting them know why we are discontinuing the use of their product. I figure developers rarely are notified as to why they have lost a sale so it seems only fair. We just found it to be to bulky, not flexible and the documentation to be poor to non-existent. I was never able to find any useful references on the web either an they only allow you to see their forums if you are paid up on your license. Not a way to run a successful business in our book.
I have completed my work on the JIDE update. There are some outstanding issues but others are fixing them while I get back hot and heavy on the MigCalendar scheduler replacement. I have some open Mac issues with Jidesoft. They don't appear to do much testing on the Mac which is a shame. You can basically use the main OS look and feel on the Mac but the other ones are useless. Colors that are not readable, tabs that are not clipped so they paint on other tabs etc.
I was doing various bits of editing of the code under IntelliJ 11 on the Mac and PC and ended up getting SVN all confused. I finally just extracted a fresh copy of the code and renamed the directory to get the Mac to play nice again. I was doing weird stuff like double editing files on my home PC and the Mac laptop then trying to revert on one and check in on the other. Classes were moved to new packages etc. which I am sure caused a great deal of grief. All fixed now, just some of the fun of being a multi-platform developer.
The MigCalendar conversion is going nicely. The new JIDE based grid is so much faster at everything you can hardly believe it is functional, it feels like something should be missing otherwise how can it be this fast? MigCalendar has a lot of wonky ways of doing things and used a lot of static collections to do it. Glad to be rid of it. I did a build yesterday with no MigCalendar references in it at all. I deleted a ton of code and old dialog boxes in the process. Plus the new scheduler is so much more flexible and configurable. The clients are going to be elated when we ship.
I plan on writing an email to the MigCalendar folks letting them know why we are discontinuing the use of their product. I figure developers rarely are notified as to why they have lost a sale so it seems only fair. We just found it to be to bulky, not flexible and the documentation to be poor to non-existent. I was never able to find any useful references on the web either an they only allow you to see their forums if you are paid up on your license. Not a way to run a successful business in our book.
Labels:
15%,
broken,
calendar,
freeze,
install,
JIDE,
jidesoft,
mac,
mig,
migcalendar,
patch,
professional,
stop using,
testing,
update,
win7
Wednesday, February 1, 2012
Some days you just rewrite what you did the previous day
Today was one of those days. I thought I came up with a really cool solution to block times and appointments sharing a cell span for the new appointment scheduler using JIDE. I had it all implemented yesterday and it appeared to be working nicely as I went home for the night and off to enjoy my son's band concert.
This morning I sat down and ran the program again just to see if I could get it to fail. Of course it did fail after a short time of testing. My fake data starts with one time block and two appointments with none of them overlapping. A time block is used to paint the background of the group of cells - say from 8 AM to noon - in a special hatched color pattern. This allows the provider to block a set of time for specific tasks such as OB or cancer only patients. You are allowed, encouraged actually, to schedule appointments in that time block. You can't move or resize the time block using the mouse, that is all done via a configuration dialog so you don't accidentally move it about during normal business activity. It needs to paint first and all appointments on top of it.
I had a bunch of code looking at each appointment as it was added to the schedule to see if the an existing cell span needed to be extended - either earlier start row or growing the row count. It worked most of the time unless I added appointments in a certain order and they overlapped but did not cause the cell span to grow. So the block was from 8 to noon and an appointment was from 9 to 10. It fits but I did not account for it thus I ended up adding two cell spans to JIDE table which annoys it when you try to delete them. I had added a cell span dump call to my table allowing me to see why the painting was all wacky. I tied the dump into an unused button on my test interface as I did not want the output filling up as I was dragging appointments around trying to get the problem to replicate. Once I really looked at the code I was not happy about adding a bunch more logic for special overlaps and cleaning up JIDE table Cell Spans and internal Cell Spans. Time to step back and take a new perspective.
What I decided to do is add the appointments as a collection. I can put each appointment in its column, then I can sort a column of appointments by row and row span. After sorting I can easily come up with unique cell spans. I add those spans to the JIDE grid then I also calculate which row / column to do the setValueAt call for adding appointments to a collection for that cell. You don't get paint calls for every cell in the table, only the one in the upper left corner of a cell span. I needed to consolidate all appointments for a span to that one callback spot. An earlier attempt at that had less than stellar results.
I ended up deleting a lot of code and making the logic a ton easier to debug and understand. Looking at the data to decide what to paint is also cleaner. Still runs slower on the Mac that I want so tuning will be in order but I want to get overlapped appointment painting to work first then I will tune things. I have a feeling it is JXLayer related on the Mac and I might not have much control over that. I have broken down and reconstructed the logic more than once already so no need to optimize yet.
Today's implementation appears to be pretty solid. I have been unable to get it to screw up after beating on it via lots of drag and drop and tossing numerous appointments at the grid. I even fixed a clipping issue that only occurred on the Mac. I am doing all my development on the PC but I copy the code over to the Mac as a backup being as I don't have a sandbox area in SVN to check anything in just yet. It is also good to run on more than one platform to catch any weird errors, graphical glitches or performance problems early in the process.
I have notes all over my whiteboard, scratch paper and in PSPad that I will go through so I can cross off the random thoughts that did not work. Next up is painting overlapping appointments by insetting them from the edge and tracking the mouse into them allowing you to change the Z order. Could get kind of hairy but I think the new way I am storing things is going to help. My plan today was to implement that once I felt the code was solid. Since the code was not solid I did not get around to it today. Guess that is why we have tomorrows.
Next scary piece will be implementing a pivot. Allowing time to run in the columns and column categories to run as the rows. I don't want an IF statement every other line so I might have an object ready for each layout type for processing rows vs. columns. I hate to duplicate code but if it becomes too messy it will be worth it. Double the testing for sure. Get that all in place and I get to do week and month views. Somewhere in there I will have to move this into our main application to replace the current MigLayout. It needs to be a fully working custom control before I do that so I can concentrate on the real appointment data at hand and not on fixing scrolling and painting bugs. Plus it will allow other developers here to help out with dialog boxes and all the other decorations needed by a scheduler.
This morning I sat down and ran the program again just to see if I could get it to fail. Of course it did fail after a short time of testing. My fake data starts with one time block and two appointments with none of them overlapping. A time block is used to paint the background of the group of cells - say from 8 AM to noon - in a special hatched color pattern. This allows the provider to block a set of time for specific tasks such as OB or cancer only patients. You are allowed, encouraged actually, to schedule appointments in that time block. You can't move or resize the time block using the mouse, that is all done via a configuration dialog so you don't accidentally move it about during normal business activity. It needs to paint first and all appointments on top of it.
I had a bunch of code looking at each appointment as it was added to the schedule to see if the an existing cell span needed to be extended - either earlier start row or growing the row count. It worked most of the time unless I added appointments in a certain order and they overlapped but did not cause the cell span to grow. So the block was from 8 to noon and an appointment was from 9 to 10. It fits but I did not account for it thus I ended up adding two cell spans to JIDE table which annoys it when you try to delete them. I had added a cell span dump call to my table allowing me to see why the painting was all wacky. I tied the dump into an unused button on my test interface as I did not want the output filling up as I was dragging appointments around trying to get the problem to replicate. Once I really looked at the code I was not happy about adding a bunch more logic for special overlaps and cleaning up JIDE table Cell Spans and internal Cell Spans. Time to step back and take a new perspective.
What I decided to do is add the appointments as a collection. I can put each appointment in its column, then I can sort a column of appointments by row and row span. After sorting I can easily come up with unique cell spans. I add those spans to the JIDE grid then I also calculate which row / column to do the setValueAt call for adding appointments to a collection for that cell. You don't get paint calls for every cell in the table, only the one in the upper left corner of a cell span. I needed to consolidate all appointments for a span to that one callback spot. An earlier attempt at that had less than stellar results.
I ended up deleting a lot of code and making the logic a ton easier to debug and understand. Looking at the data to decide what to paint is also cleaner. Still runs slower on the Mac that I want so tuning will be in order but I want to get overlapped appointment painting to work first then I will tune things. I have a feeling it is JXLayer related on the Mac and I might not have much control over that. I have broken down and reconstructed the logic more than once already so no need to optimize yet.
Today's implementation appears to be pretty solid. I have been unable to get it to screw up after beating on it via lots of drag and drop and tossing numerous appointments at the grid. I even fixed a clipping issue that only occurred on the Mac. I am doing all my development on the PC but I copy the code over to the Mac as a backup being as I don't have a sandbox area in SVN to check anything in just yet. It is also good to run on more than one platform to catch any weird errors, graphical glitches or performance problems early in the process.
I have notes all over my whiteboard, scratch paper and in PSPad that I will go through so I can cross off the random thoughts that did not work. Next up is painting overlapping appointments by insetting them from the edge and tracking the mouse into them allowing you to change the Z order. Could get kind of hairy but I think the new way I am storing things is going to help. My plan today was to implement that once I felt the code was solid. Since the code was not solid I did not get around to it today. Guess that is why we have tomorrows.
Next scary piece will be implementing a pivot. Allowing time to run in the columns and column categories to run as the rows. I don't want an IF statement every other line so I might have an object ready for each layout type for processing rows vs. columns. I hate to duplicate code but if it becomes too messy it will be worth it. Double the testing for sure. Get that all in place and I get to do week and month views. Somewhere in there I will have to move this into our main application to replace the current MigLayout. It needs to be a fully working custom control before I do that so I can concentrate on the real appointment data at hand and not on fixing scrolling and painting bugs. Plus it will allow other developers here to help out with dialog boxes and all the other decorations needed by a scheduler.
Thursday, January 19, 2012
The land of JXLayer
I am deeper into the MigCalendar to JIDE conversion process. I am still working on the prototype for the scheduler control and have a good hunk of the rendering working. That means I get to play with drag to size and drag to move. I am using a JXLayer to handle this as the main JIDE grid needs to do its own row height and column width sizing that I don't want to screw up.
JXLayer is really nice in that your can paint anything on a glass pain after all the stuff under the glass has already rendered. I have appointments so I keep their rounded rectangle associated to them. If the cursor is over / near the top or bottom edge of the rounded rectangle I paint a thicker border for the rectangle in the JXLayer. The JXLayer also watches for mouse press / release actions for the thick border rectangle so I can start dragging operations allowing the user to resize the appointment to a new time frame.
Next up was the auto scrolling of the JideScrollPane as they near the edges of the screen. I have to monitor the viewport rectangle for changes while I am in my dragging code to adjust my rectangles. Lots and lots of point and rectangle processing going on in this code along with clipping and offset calculations. At this point it is all working rather nicely although I can get it to screw up a bit from time to time. I need to figure out snapping to time slots. I don't want to increment by the minute but maybe 15 minutes is too much. They can always popup a true time editor dialog to get exact numbers. The drag to size needs to be reasonable but not so crappy you will never use it. Dragging the appointment to another cell in the grid also needs to happen. For that I am thinking of a simple drag to let you move it anywhere, a CTRL + drag to only move the appointment vertically (i.e. change start time) and a SHIFT + drag to only move horizontally (i.e. under another provider, facility, room or category depending on the current column configuration). There are a lot of time you only want to change one axis and I know a lot of paint programs use CTRL, ALT and SHIFT to lock the mouse movement.
With that in mind I am considering a "status bar" custom control to show the tool tip text, row (time slot) and column (provider, etc.) information as multiple level row / column headers can be off screen meaning you don't know exactly where you are in the grid always without this special status information.
Writing a scheduler has been a unique experience for sure. You see various 3rd party .NET controls that emulate Outlook in one fashion or another. There is almost nothing other than MigLayout on the Java side. We need to be cross platform so .NET is out even though I know how to code in C#. The other choice would be a web based product but we a lot of support data that needs to be cached leaving that out too.
Sometimes writing your own control is the only option. I have used JXLayer in the past to draw spinning busy cursors. I had not used it for mouse interaction. It has been pretty easy so far once you figure out your painting offsets based on the scrollpane and other JComponents you are dealing with. Not sure what I would do if I need to port this to a touch interface for iOS or Android. My boss got Ice Cream Sandwich on this Xoom this morning. My updates always seem to be a day or so later in the staggered refresh cycle but I am excited to give it a shot when it magically appears. He tried our mobile app out under it and it appeared to work fine. Not a big surprise as the same code base works on phones and tablets. I am using 2.1 as minimum required API so I am not using any cool fragments or other tablet features that appeared in the 3.x series. I just want to see the bad boy running and to play with the new OS stuff.
Next up was the auto scrolling of the JideScrollPane as they near the edges of the screen. I have to monitor the viewport rectangle for changes while I am in my dragging code to adjust my rectangles. Lots and lots of point and rectangle processing going on in this code along with clipping and offset calculations. At this point it is all working rather nicely although I can get it to screw up a bit from time to time. I need to figure out snapping to time slots. I don't want to increment by the minute but maybe 15 minutes is too much. They can always popup a true time editor dialog to get exact numbers. The drag to size needs to be reasonable but not so crappy you will never use it. Dragging the appointment to another cell in the grid also needs to happen. For that I am thinking of a simple drag to let you move it anywhere, a CTRL + drag to only move the appointment vertically (i.e. change start time) and a SHIFT + drag to only move horizontally (i.e. under another provider, facility, room or category depending on the current column configuration). There are a lot of time you only want to change one axis and I know a lot of paint programs use CTRL, ALT and SHIFT to lock the mouse movement.
With that in mind I am considering a "status bar" custom control to show the tool tip text, row (time slot) and column (provider, etc.) information as multiple level row / column headers can be off screen meaning you don't know exactly where you are in the grid always without this special status information.
Writing a scheduler has been a unique experience for sure. You see various 3rd party .NET controls that emulate Outlook in one fashion or another. There is almost nothing other than MigLayout on the Java side. We need to be cross platform so .NET is out even though I know how to code in C#. The other choice would be a web based product but we a lot of support data that needs to be cached leaving that out too.
Sometimes writing your own control is the only option. I have used JXLayer in the past to draw spinning busy cursors. I had not used it for mouse interaction. It has been pretty easy so far once you figure out your painting offsets based on the scrollpane and other JComponents you are dealing with. Not sure what I would do if I need to port this to a touch interface for iOS or Android. My boss got Ice Cream Sandwich on this Xoom this morning. My updates always seem to be a day or so later in the staggered refresh cycle but I am excited to give it a shot when it magically appears. He tried our mobile app out under it and it appeared to work fine. Not a big surprise as the same code base works on phones and tablets. I am using 2.1 as minimum required API so I am not using any cool fragments or other tablet features that appeared in the 3.x series. I just want to see the bad boy running and to play with the new OS stuff.
Wednesday, December 21, 2011
JIDE Table as a base for the scheduler
For the moment I am going to punt on MigCalendar and give JIDE a shot for our scheduler. We already have a license for JIDE so might as well get some use out of it and we can drop a custom control and JAR files from the project with the switch.
The JIDE table supports various row sizes, multilevel columns, custom rendering, row labels, etc. Pretty much everything we need I hope as long as I can get a really nice looking custom cell renderer in place. Row / Column spanning is in there but night be tricky to handle what we need. I also need to pivot things but will probably do that with a table reconfiguration instead of using their pivot stuff due to special layout needs.
I did run into some issues with the new MarginArea as the demo they provide was missing that file. I almost got the code running by guessing at they layout but it was not working. A quick email to them got me the example code I needed to complete the task. Very happy with the turn around time on that request.
Going to take some effort to get it all in place but for the first days work I feel I got a lot of progress done. The documentation is still a bit iffy, English is a second language for them and web support is light but I have a feeling I can fight through this one.
I hate to give up on MigCalendar but so many here have tried to make it work the way we need it that it is really time to move on to something else that hopefully solves most of our needs and does not introduce too many new headaches.
The JIDE table supports various row sizes, multilevel columns, custom rendering, row labels, etc. Pretty much everything we need I hope as long as I can get a really nice looking custom cell renderer in place. Row / Column spanning is in there but night be tricky to handle what we need. I also need to pivot things but will probably do that with a table reconfiguration instead of using their pivot stuff due to special layout needs.
I did run into some issues with the new MarginArea as the demo they provide was missing that file. I almost got the code running by guessing at they layout but it was not working. A quick email to them got me the example code I needed to complete the task. Very happy with the turn around time on that request.
Going to take some effort to get it all in place but for the first days work I feel I got a lot of progress done. The documentation is still a bit iffy, English is a second language for them and web support is light but I have a feeling I can fight through this one.
I hate to give up on MigCalendar but so many here have tried to make it work the way we need it that it is really time to move on to something else that hopefully solves most of our needs and does not introduce too many new headaches.
Subscribe to:
Posts (Atom)