The Collapsing Works!

Like, completely! We finally got the collapsing panel to work. It starts at 100%. When you click to close it, it changes to pixels first, hides the table, then closes it. When you click to open, it opens, changes to 100%, then unhides the table. Beautiful! JK, also managed to fix the table size to fit phone screenwidth. Awesome!

Progress on Mobile Find Patient

All right, so after quite a bit of trial and error and a lot of Googling, we finally resolved the error in the way the Javascript handled percent values. The only problem was that the way one site claimed that percent height's worked, turned out to not be accurate. So it was a miracle that everything worked the way that it did. It seems, then, that resolving the "popping" problem we had with the collapsible divs might not be possible. Instead we are going to have to re-engineer this without percentages. Oh, well, progress is progress!

The New Mobile Site

Surprisingly JK and I found that getting the hang of the JSP was not as hard as we anticipated. We do have to follow a lot of trails through the trunk, but these are not that hard to pin down. Since my last post we have almost entirely completed the Patient Search page for the mobile site. This is a huge milestone. We are now left with trying to figure out how to get the findPatient div to resize when a search is in progress. What we have done:

• Shrunk page elements to be suitable for mobile environment
• Brought language bar up to rest immediately under the page info (fixing the display problem on the iPhone)
• Shortened the user login bar
• Shortened the search field
• Eliminated unnecessary whitespace (breaks, etc.)
• Coded the JavaScript to scroll the findPatient and createPatient fields
• Made small formatting tweaks to make things cleaner overall

Now as we approach the end of the semester we hope to get the patientSearch page done, at least, so that we have something concrete to show in our final presentation. Regardless of what we get done before then, we will be continuing into the summer. Hopefully we will soon begin on the patient summary page.

Long Since Due Update

After some discussion and planning between us and Ben Wolfe, we have settled on a definite course of action from here out. We are going to be designing an entirely new mobile interface, but we will be working one page at a time. We're starting out with the patient search and patient summary pages. We will be designing first and then coding these pages in JSP. We are taking special care to order the elements by importance to the user base (primarily clinicians). Since we have a presentation coming up, we are working on a mock-up layout that we can present.

Location of Pages in the Project

I did some digging and found this article on the OpenMRS website. It was not that hard from there to find the location of our web pages: http://dev.openmrs.org/browser/openmrs/trunk/web/WEB-INF/view.

What Was Our Project Scope Again?

Recently JK and I hit a roadblock that we simply cannot walk around. The spacing problem that I showed in the last post could only be fixed one way: turning the white link list (userBar) into a drop down menu in the CSS. Unfortunately, the only way this can be done is with an unordered list. "Well, that's perfect!" I thought, "The blue link list (navList) was an unordered list, so surely userBar would be as well." Wrong! userBar turned out to be a series of spans. Yuck! So we decided that despite our attempts to do a purely CSS operation, we were going to have to mess with the HTML. Being a "skilled" web designer (meaning an undergrad who had taken an Internet Development course), I wisely suggested that we validate the HTML before we start editing, so we don't throw errors on top of errors. Heh, first mistake. It turned out that the page (yes, this is just the home page, not the entire site, which we must also work on), whose DOCTYPE header claimed to be XHTML 1.0 Transitional, had 73 errors and 1 warning! In our local copy of the HTML we managed to eventually boil this down to 3. Now, remember, this is just the home page. One of the remaining errors was an autocomplete attribute we didn't want to mess with (you know, the kind you put in forms that all the major web browsers understand but for some reason isn't standard even though there is no reasonable workaround?). The other two errors were tell-tale signs that the HTML had been generated on the server side. Not good! This means that now JK and I will have to dig down into the MVC that OpenMRS uses to manage their project and find out which piece exactly generates the HTML and we can go about changing it so that it generates it the way we need it to. Sound fun? JK isn't looking forward to it. Personally, I'm excited, but I must admit it is daunting.

So now our project has gone from "create the mobile stylesheet" to "digging down in the MVC to regenerate the HTML." Meanwhile, the rest of our class is laughing at us because we finally have to do some "real" coding.

More Problems

Remember how beautiful the page looked before logging in?



Yeah, then you log in.