Wednesday, April 28, 2010
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!
Monday, April 26, 2010
Wednesday, April 14, 2010
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.)
- Made small formatting tweaks to make things cleaner overall
Monday, March 15, 2010
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.
Monday, March 1, 2010
Saturday, February 27, 2010
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.