However, when designing a product, you simply don't have that luxury anymore. Your application must now not only run but look good on all popular versions of popular browsers: MSIE, Chrome, Firefox and maybe even Safari. And if you think that these browsers behave exactly the same on different operating systems, you're completely wrong.
As we put the final touches on sumnevaSERT v2.0, I wanted to share some of the experiences that I went through over the past few months with regards to user interface - mostly so that you can learn from my mistakes and plan accordingly.
Design and stick with a Design PatternThis is the most important step. If you skip it, or do it poorly, it will flow throughout your entire project and come back to haunt you on a daily basis.
Simply put, a design pattern is how different components will be laid out on the page. It's OK and quite often that you have two or three variations of this (one-level tab vs. two-level tab, sidebar vs. no sidebar, etc.).
Once a design pattern is defined, do all that you can to not stray from it. If you designed the HTML & CSS to work with 2 columns of reports, then stick to that. APEX templates are flexible to a point. Once you cross that point, not only do your applications start to look "busted", but issues with usability will start to arise on at least one of the browsers.
It helps tremendously to use a tool such as Balsamic Mockups to come up with a design pattern for your site.
Design and test the Templates firstOnce you have a design pattern, it's time to convert that to APEX templates. While this is also one of the most important pieces of advice, it's also the one that you will undoubtedly fail on. It's 100% impossible to get this all done up front, so set your expectations accordingly. However, if you can get some portions of the templates done before you start adding content, that will go a long way later on.
While designing your templates, keep the HTML as clean as possible - do not use any inline styles or other tags that could be interpreted differently by different browsers.
Also, I usually start with a clean Theme, and only use the APEX provided templates as a guide. There is no application out there that needs all 75+ templates that the APEX themes provide. Thus, I typically start with a brand new theme and build that up as needed.
Another trick that I have used forever is how I name my templates. APEX template names are too specific - "Form" region, "Report" region, and "Chart" region all look the same to me - and they should! Thus, I create a single region called "Content Region", and use that for all content - Forms, reports, charts, trees, etc. If I need a second region, it's likely going to be called something like "Content Region - Narrow" - and as the name implies, will be narrow. This small change will go a long way in keeping the templates as usable and compact as possible.
Start your cross-browser testing NOWDon't wait until you more than a few days into development to start testing on different browsers. In fact, delegate a different browser for each day of the week for both development and testing to ensure that your application works well in all of them.
My advice: make Friday "IE day", as happy hour will never be happier.
Two (or more) CSS filesCritical when supporting most browsers and IE, you'll need to have at least two CSS files. I can't imagine putting all CSS classes into a single one and having all browsers play nice with it. You can start out with a single one, and when you hit a point where you'll have to clone it, at least you'll have a good solid base.
If you use a STYLE tag, you will payDon't use a STYLE tag. Can't emphasize this enough. It will come back to haunt you, as one browser will be OK with it, and others (i.e. IE) won't. At that point, you'll have to retro-fit your HTML to use classes, add them to both files, and re-test.
You'll be most likely tempted to do this when rendering HTML from PL/SQL, as if you use a STYLE tag, you don't have to open up another application to add the class, etc. Don't be lazy.