CSS – Safari ignoring width property

This has been occurring lately, and I couldn’t find much written about it, took me a couple of days googling it and trying to find what would be the reason that Safari would ignore our width property. After discovering that the width property is completely messed up on Safari browser only on Mac computers  as Safari on Windows didn’t have the same. I found that the solution for that is just to add a max-width property along with the width property. This has fixed it for the most part. No much reasoning I found after that, but seemed to me that width property has be associated with a max-width property as well in order to have the layout looking right.


div {width: 155px; max-width: 155px;}

 

If anyone has different suggestions or a reasoning behind this, surely share.

Advertisements

UX Common Pitfalls – 3

3. Relying on Flash to Convey a Message

So after discussing two of the major pitfalls for UX designers these days, one has to discuss what seems to be a controversial topic among many of the UX designers these days; whether to use Flash in sites or not?

Yet the discussion here isn’t as much on discussing the pros and cons of using Adobe Flash, for this I’d recommend some of the well written articles about this:

Website Performance

No one can deny that Flash has added lots beautiful interactive design when it was first introduced yet later, we discovered the prominent issues evolving from building sites Flash. The Cons of using Flash are so much user based, as you may have noticed. First, it has performance issues for the site, this affects usability. Performance directly affects usability. According to an article about website optimization, Amazon found out that every additional 100 milliseconds of load time decreased sales by 1 percent.  In fact, user frustration increases when page load time goes more than 8 seconds. That same article presents a study by Google, that adding half a second to search results decreases traffic and revenues by 20 percent. – The Psychology of Web Performance

Unfortunately, many of the UX experts these days are technically detached which makes them thinking of mainly having a fancy site. Having a fancy site does have its trade offs.  And when that tade-off is a performance issue, you have fallen into one of the worst yet common pitfalls in UX design. UX experts, hence, have to study well that their fanciness could affect site’s speed. Site’s slow speed would frustrate the user’s experience. Frustrated user’s experiences would decrease traffic and you’re headed to a big failure. A good article about Designing for Performance is presented here on alistapart.com, Improving UX Through Front-End Performance

Accessibility

Second major issue you’ll face with building sites in Flash it does not work well for accessibility, since it is based on images and that has the hindrance of having alternative texts, again the issue with screen readers.

Touch Screen Devices

Third major issue would be its compatibility with touch screens, something you would not want to ignore or forget when building sites today. People browser through their iPads and Galaxies everyday and this number is increasing significantly as I mentioned before in my first blog of this series.

Flash Plugins

Last major point in using Flash is:

flashErr

I am sure many of us have seen these messages before. Yes, plugins do have their issues and they are not very stable. In using Flash into your site, you are setting yourself up to whatever issues the user may have with their browsers. And the most common of the issues on browsers are the Flash crashing issues.

 

Then here comes the question, when should one use Flash then?

When Not?

So before saying the when? I have to say the when not? As mentioned in the title of this blog, it should be used by you shouldn’t rely on it in conveying your message. especially if this message is warning, like  weather site warning of thunderstorms, or utility site warning of power shortage, these messages should be in developed using Flash.

Another instance where you do not want to use flash is relying on it on user’s enrollment and payment, since this could pose issues as well like plugin crashed while user is enrolling or paying. You do not want your users to face such issues.

When to use Flash?

Flash can be of very good use if you are presenting some that best be presented graphically, such as car model sites, fashion sites, artists/musicians or cartoon sites. These are just few examples.

It can also be used within your normal site to present a certain ad which you think would best be presented in flash. Many of the major sites are practicing this and it still provides good experience for the use. Such as bbc.co.uk, USAToday and many others..

Flash can be used in many instances, but bear in mind, it should only be used when the site’s performance isn’t badly affected and goes along only when it is needed. For this reason, UX experts should study well how sites are made and optimized technically before coming up with too fancy ideas which would affect badly the user’s experience due to the mal performance of the fancy site.

 

 

Browser Compatibility Issues – Part V

Elements have different properties in different browsers. For example <ul> would have different margin and padding in IE from other browsers.

For this reason, many people have been using for long reset.css, which in turn resets all the property values which will return the values

ul {margin:0; padding:0; border:0; font-size:100%; font:inherit; vertical-align:baseline;}

This approach, though being useful, I did not always like using. I would rather reset my own properties for the element I see behaving differently or better style it right away.

A newer way for having your elements react similarly on different browsers is by using normalize.css , though this one is more HTML5 focused, and this is where the web is going if not there already..

The advantages would be mainly that it preserves some of the defaults which may be useful and not inconsistent with browsers. This is handy rather than resetting everything to zeros. With this being said, you will have more control over your elements styling. It also corrects some bugs which are not corrected by CSS. Here’s a full of list of the advantages of using normalize.css.

Another reference on Best Practices:

https://speakerdeck.com/dmosher/so-you-want-to-be-a-front-end-engineer

Browser Compatibility Issues – Part IV

z-index has its issues with IE7. I tried going over many forums to see how to have it solved.
One of the forums exceptionally useful is: Squish the Internet Explorer Z-Index Bug
which actually discussed the problem I was having at that time.
I know there are more issues to z-index with IE7 than this one mentioned in this post.

So basically that forum explained something that I’m still trying to understand since it is the way IE7 is interpreting it:

There’s a hover effect of a dropdown menu in the page, the dropdown has a position absolute.

<!doctype html>
<style>
    ul.main > li {float:left;}
</style>
<ul class="main" style="position: relative;">
	<li>main1</li>
	<li>main2
<ul style="position: absolute; top: 10px; left: 10px; z-index: 125;">
	<li>sub1</li>
	<li>sub2</li>
</ul>
</li>
</ul>
<div id="cont" style="position: relative; z-index: 10;"><img src="image source" alt="" width="" height="" /></div>

Problem
The problem with this code is that no matter the z-index of the cont div is, it still would show above the hovered menu which is hovered over it, even though the hovered menu has a higher z-index.

Solution
add a z-index in the parent ul.main to be less than the contained ul’s z-index
i.e.

ul.main, ul.main > li {z-index:50;}

Browser Compatibility Issues – Part III

This issue is a JSON issue.

We had lots of JSON objects in the page and things were all working fine on Firefox and IE9 until we started testing JSON objects on IE7 and we kept having the following error “JSON undefined”

After some research, I found that there’s no native support for JSON in IE7, for this reason, one should use json2.js created by Douglas

Here’s another forum for this.

Off course another main point that’s worth noting in constructing your JSON objects would be, getting rid of all the trailing commas that are extra at the end of JSON last element in the array. This does matter in IE but doesn’t in other browsers.

IE7 Opacity Filter with JQuery methods

So I have an undisplayed div that has an opacity applied to it which is triggered by a Jquery method to be fadeIn with a certain event. This doesn’t work with IE7.

Code:

<script type="text/javascript">
$(function(){
     $('#fade').fadeIn();                   // does NOT work on IE7 with filter Opacity
});
</script>
<div id="fade" style="position:absolute; z-index:20; top:0; left:0; background-color:#000; opacity:0.7; filter:alpha(opacity=70); zoom:1;"></div> 

For this reason, fadeIn() is not the solution here. Here’s the right code:

  $('#fade').fadeTo("slow", 0.7);

Browser Compatibility Issues – Part II

So next to discussing the HTML/XHTML and CSS major issues when it comes to cross-browser testing, comes a third one which is as important especially when making your pages more interactive, the JavaScript. 

This part is not meant to discuss all the JavaScript issues cross-browser, yet just useful tips to tackle those issues. 

If one is interested on knowing which browser is supporting what version of JavaScript, here’s a list that I came across in my research: http://ejohn.org/blog/versions-of-javascript/

The reason I thought of this post is what I’ve been seeing as mishandling of some browsers to my legacy javascript and what I proposed to my colleagues to do. Where I work, there’s a big deal of working with legacy JavaScript, though I have been doing most of the DOM changes in JQuery now. 

Problem: 

The users would go to our site on an IPad, IE9 and Safari on a Windows machine, click submit of their order. If their connection is slow (by any chance) and especially those using IPad since they might not be on a wifi at the time, they click submit again, and again and again.. 

Those four times of submission will actually cause 4 submissions on the backend whereas on a normal machine, the submission times aren’t affected as long as the page is loading.

Partial Solution:

Some suggested to use this.disabled on the anchor of the submit. This solved the problem on IE9 but not on IPad and Safaris. 

Solution: 

I suggested using JQuery because of its compatibility on different browsers since you don’t have to deal with what browser using what version of Javascript. 

Not only, one should consider using JQuery or any of the other reliable JavaScript libraries for their fancy animations, ease of writing, good documentation and provided methods. But one should also consider that they do play a big role in cross-browser functionality. 

Notes: 

JQuery Browser Compatibility