IMAP (Internet Message Access Protocol) has been around since the 1980′s, but Comcast has never supported it with their comcast.net email accounts. IMAP has many benefits over POP, but I won’t go over those here.

Windows 8′s native email client doesn’t support POP, and this has finally been enough for Comcast to venture into supporting IMAP. Currently support is only in beta, and you only have the option of POP or IMAP – not both like most email providers have offered since the 80′s and 90′s.

How do you get IMAP? You sign up for the IMAP Trial from XFINITY® and cross your fingers that all goes well. The page does say “This page is for those subscribers that use Windows 8″ but if you read the terms, it’s not platform specific so Windows 7 and prior as well as Mac users can take advantage of IMAP as well.

(The following is a response to a guest blog post on Forbes.com titled “Time to Stop Building Mobile Websites“)

When I first read the headline of the Forbes guest post, I was puzzled. It’s akin to someone writing an article titled “The Titanic Never Sank.” It’s an inaccurate, sensationalist headline. The article also contained a fair amount of false information. The core message is good, but unfortunately the author made some extremely inaccurate claims when trying to prove his point. I’m going to address those points – both their fallacies and core facts.

Step 1 in building your mobile website is to determine your target audience

Focusing on mobile as a separate channel is a distraction that turns the platform into an either/or proposition that hurts results.

First off, it completely depends on the goal of the website. Many successful founders will even suggest some companies focus on mobile first and not even bother with a desktop presence. Secondly, some websites have functionality and flows that simply do not translate well to mobile. Third, it’s simply not feasible for larger websites to quickly rebuild from the ground up to offer a mobile presence via a responsive site. In the short term, providing a specific mobile version is suitable while the main site is overhauled. Claiming that not building a responsive site “hurts results” is an extreme overgeneralization that should simply be ignored.

The most important aspect of building a mobile website

“Mobile” as a separate marketing channel existed for about six months – somewhere back in 2009. It had an extremely short lifecycle because technology and user behavior caught up, waved a cheery hello and then raced right by.

I’ve been building mobile sites since 2001. I have no clue where the 2009 date comes from, but it has nothing to do with mobile sites not previously existing as a “separate marketing channel”.

The mobile and traditional Web separated initially because of slower processors, slower connection speeds and lousy displays. That distinction is disappearing – fast. [...] The only difference? Screen size. My phone still has a relatively small screen.

You need to think about form factor in your marketing, not mobile versus desktop.

That was true, back in 2001. As far as modern smartphones go, that hasn’t really been the case for years. There were methods to deal with slower processors, connections and screen sizes… all since at least 2001. In many cases, the displays on smartphones are higher quality than those on desktop computers (eg IPS vs TN panels.) Mobile devices clearly have smaller physical screens than most desktops or laptops.

However, the biggest distinction isn’t even touched on – usability. How a mobile device is used is vastly different than a desktop computer. The idea of “Think form factor, not mobility” is very misleading at best. Again, one has to look at the target for the site – will they be using the site on their smartphone while sitting at their desk? Most likely not. They will be using it as a mobile device. Their connection may not always be great, the lighting conditions may not be as controlled and the environment in which the site is used may be much more chaotic. Because of this, how data is passed and stored needs extra care. How much contrast you give a design is also important, as is font, graphic and button size to name a few. It’s not just about the size of the screen, it’s about how and where the site is used.

Mobile vs desktop websites

If you want me to cry, tell me you’re building a “mobile website” for your company. [...] No sane person builds a separate mobile site to deliver content or support e-commerce. You might create a separate checkout funnel. But a full-fledged mobile website can cause loads of painstaking effort, and at the end of the day it’s worthless.

The author just called Amazon.com worthless and Jeff Bezos insane. While Jeff may be insane, I tend to think it’s in a good way and there’s no way I can logically call Amazon “worthless”.

Mr. Lurie’s comments about when to build an app were pretty good, other than the “it’s a waste of effort” remark. Unfortunately, making assertions like “No sane person builds a separate mobile site to deliver content or support e-commerce” overshadows and discredits the rest of his message.

“Instead, build responsive designs”

This is a great idea in many cases. Again, it depends on the site’s function, it’s audience and many other factors. As far as generalizations go, it’s not too bad. Still, Mr. Lurie interjects fallacies.

“You maintain one content management/e-commerce infrastructure.”
“You deliver one set of content to one site.”
These can be done with a separate mobile site as well. Any good CMS or ecomm system will allow for multiple “themes” or “skins” to be applied based on the device that’s accessing the site. Any reasonably well-built custom framework should also allow for sharing content between themes.

“You support all mobile devices that include Web browsers.”
A core method of building a responsive site are called “Media Queries”. These were only introduced in CSS3. This became an official W3C recommendation on June 19, 2012. http://www.w3.org/TR/css3-mediaqueries/ Millions of mobile devices exist that don’t support this. If your target includes a large amount of these devices, a responsive site may pose big problems.

“It’s better for search engine optimization (SEO).”
Although Google recommends responsive sites, it’s not because there’s any impact on SEO. And reading the link he provided shows this. Not only that, but it also shows how to solve the issues he cites as reasons not to provide a dedicated mobile site. Finally on this point, just because there is a dedicated mobile site doesn’t mean it’s at a different URL or that it serves up different content.

How should you build your mobile website?

Know your audience. Know your goals. Know your technology. Know your user experience. Armed with that knowledge, often a single responsive site can be a good solution. Sometimes an app works better and sometimes a dedicated mobile site is the best solution.

I have built many dedicated mobile sites and I have also built responsive sites. Often with large existing sites that want to provide a better experience to mobile traffic, we’ve used the same database and framework but applied a mobile theme to the layout so that it works better on mobile devices. This has often proven to be far more cost effective than rebuilding the original site.

Another project I’m currently working on is a dedicated mobile site for a software as a service product. There are over a hundred thousand sites on this platform and millions of people use the sites. The administration for the service is full of complex forms, hundreds of editable fields, detailed wizards and a lot of other functionality that is simply painful on mobile. I’m rethinking the whole process to how, when, where and why the users use the site, in the context of mobile. It’s very important to not ignore the context of use. The site will be responsive, but primarily to target multiple mobile device sizes and pixel densities.

It’s becoming increasingly important to be able to test your website – be it a standard version, responsive or a mobile specific version – on multiple devices. All of the major smartphone makers use Webkit (the basis of Chrome & Safari), except, of course, Microsoft.

Quite often websites will display the same in Google Chrome as they do on Android. However, sometimes they do not. Also, sometimes interactivity needs to be tested to see just how well it works on a touchscreen. Using the Android SDK helps you do that without having to have a huge range of devices with multiple versions of the Android OS at your disposal.

Step 1: Downloading and Installing the Android SDK

Download the SDK from the Android developer site
Read the Installation instructions – the page will change depending on which OS you use it for. I’m on a Mac, so I see the Mac instructions.

Personally I put the unzipped folder into my /Applications/Utilities directory.

Step 2: Preparing the Emulator

You’re going to notice there aren’t any applications you can just double click on and have them work. For non-Windows users, you’re going to be working inside the tools directory as well.

Windows: double-click on the SDK Manager.exe in the main Android SDK directory.
Mac or Linux: You will need to use the Terminal to start the emulator. Then you need to type ./android sdk from within the tools directory.

Step 3: Creating an “Android Virtual Device” (AVD)

- In the window, on the top right there’s a button for New… Click that
- Give it a name, and choose a Target – this is the version of android you want to use. I chose 2.3.3 as it’s very common right now. 4.0.3 is also becoming popular, so if you’re reading this a few months after publishing, I’d go with 4.0.3. (I currently use both.) You can also check for  the current Android version marketshare.
- Set the resolution. I chose WVGA800
- IMPORTANT: Under Hardware, click New… and add Keyboard support. Then set the Value to Yes. Otherwise typing will be a pain This will allow you use your computer keyboard with the Android SDK emulator.

Step 4: Start the Android Emulator

With the Android Virtual Device Manager still open, select the device and click Start… leave the settings on the next window as their default settings, then click Launch.

Step 5: Login and Launch the Default Android Browser

You will need to click and drag the lock icon to the right to login. After you do that, click the globe icon to launch the web browser.

Chances are you’ll quickly want to rotate the screen into landscape view, and there’s not a single UI element to help you do this (unlike the iOS SDK.) There’s several keyboard commands which may help you, including rotating the screen. They’re here http://developer.android.com/tools/help/emulator.html#controlling

Why not use Internet Explorer 9’s Developer Tools for testing IE8 & IE7? Here’s why.

Twice last week this issue has come up so I’m providing some examples and reasoning as to why you should not even bother using Internet Explorer 9 for testing websites for how they would look in Internet Explorer 8 and Internet Explorer 7.

Background
IE has traditionally not been developer friendly out of the box. In IE9, that changed and Microsoft provided Compatibility Modes within Developer Tools (F12).

Months back, working with a couple devs, I was told this is how they test with IE8. I thought “wow, great that Microsoft is trying to help developers.” I never looked into this feature before, as I had always just used VMs for testing, long before IE9. So when IE9 came out, I continued that patter. (Microsoft provides free virtual machine images for testing.) However, my distrust for them overpowered me and I decided to run some tests.

The first test I ran was Acid3 http://acid3.acidtests.org/ Viewing the screenshots below, you will see the immediate differences I saw: A different score and slightly different rendering (eg “FAIL” in the corner.)

Acid3 test in IE8 (native)

Acid3 test in IE9 set to IE8 mode

Keep in mind one huge difference is the new JavaSript engine in IE9. Changing to IE8 or IE7 does not change the JS engine. This should be a huge red flag to those who were working on this feature, but based on results, they thought it was worth shipping anyway even though they acknowledge it’s a big issue http://blogs.msdn.com/b/ie/archive/2011/03/24/ie9-s-document-modes-and-javascript.aspx

“We have made every effort to ensure that IE9’s compatibility document modes support the same functionality that we shipped for these modes in IE8. However, because the Chakra engine is not the same as we shipped in IE8, it is bound to have some differences.”

This is an important issue, and I disagree that they “made every effort”  as they could have built it to switch engines, but I digress…

Now I have run into a few more people thinking this works, as well as a few more scenarios where it doesn’t – unrelated to JavaScript. There’s also CSS issues which I haven’t seen Microsoft acknowledge.

Here’s a few examples to show you how IE8 stacks up to IE9 in IE8 mode.

Finally, I did some of these same tests in IE7 and encountered similar results.

A few versions back, Firefox (Mozilla as a whole) dropped support for its original method of supporting CSS3 rounded corners (border radius). Previously it needed the -moz prefix – -moz-border-radius

Starting in Firefox version 13, Firefox no longer honors the -moz prefix in respect to border-radius.

One solution is simply to remove the -moz prefix. You can do this via find and replace – find: -moz-border-radius and replace it with: border-radius

This will cause older Mozilla browsers to not display border-radius anymore. So you could also add just border-radius as an additional rule.

Support for the prefix was removed in Gecko 13.0 (Firefox 13.0 / Thunderbird 13.0 / SeaMonkey 2.10).