There's something to be said for corporate standards for browsers. Sure, it's almost always some flavor of IE, but at least you're only charged with making sure that your application runs and looks good on one browser on a single OS.
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.
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.
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.
My advice: make Friday "IE day", as happy hour will never be happier.
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.
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 Pattern
This 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 first
Once 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 NOW
Don'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 files
Critical 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 pay
Don'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.
Comments
But i don't agree with IE approach you're proposing.
In my design i strongly focus on standards and try to make everything strict as i go trough the design. Most of modern browsers will accept that and the difference between them is not important as long as the application works. Also in IE the problem starts if you need to make it work in IE7 and less. These are the most annoying browsers. Fortunately the percentage of them is low in these days. So low that i assume that no one is using them and omit them in process of building the Theme. Of course there are clients that are committed to this browser (I know big corporations that still have IE6 on deck), and i have to design theme for them but I do this after designing the "core".
One more thing. I've noticed that in most of templates APEX uses browser specific css (ex. -moz-border-radius). For me, Opera user :D, it's a mistake that need to be fixed. basically Don't build for browser build with standard and check in browsers if something goes wrong usually there is some simple solution. Also reed about Progressive enhancement approach witch is the way what these days web design gurus are going.
Best regards
piotr from APEX-Designers.com
Unfortunately, I had to provide support for IE7, so the standards approach was not an option.
I do agree with you; make things as standard as possible, so that modern browsers will all "play nice" with the HTML & CSS.
I also didn't think that the Opera issue would come up so soon, either! :) You're not going to like my opinion here, but I'll share it anyways: forget Opera.
It's a numbers things, not a standards thing. If you're looking for the most compliant browser, then sure, Opera is almost always the winner. But if you're designing software that you're trying to either use at or sell to organizations, the chances that any of them "support" Opera are almost zero.
Thus, in most cases, the investment up front is almost never worth the return. Also, if you stick to standards throughout, Opera should have few, if any issues with rendering properly.
In writing this, I now have 2-3 more "rules" that I think should have been included - time for a second post!
Thanks,
- Scott -
Can I find any more information on how to implement the page 0 solution to incluse workspace_images in the css-file?
Thanks in advance
Cees van Oosten
It's quite simple. Just create a PL/SQL region that uses htp.prn to "print" the CSS. When referring to images, use v('WORKSPACE_IMAGES') or v('APP_IMAGES') for the path before the image name instead of the static path.
Hope this helps.
- Scott -