iOS 7 is a great improvement over iOS 6, but we are sorely disappointed that a very simple bug fix to the iOS Maps App and the Calendar App remains undone!

Here’s the problem: if you create a calendar entry and add an address in the “Location” field, for some bizarre reason the Calendar App does not recognize the full address.

Here’s an example: a meeting between Rame and Arun is scheduled to take place at 255 108th Ave NE in Bellevue, Washington (which, by the way, is a well-known local office building known as the Civica Center). When you create the calendar entry, you can type in the full address like this:

But when you are viewing the calendar entry, the Calendar App only recognizes “255 108th Ave NE” as a clickable link: everything after the comma, in this case “, Bellevue” has been ignored.

That’s bug #1: a simple bug, which could be solved simply by adding some logic to read the rest of the text string after the comma since the entire field is a “location” anyway!

Now we come to the iOS bug, which is far more irritating — and, indeed, baffling considering that the Maps App was designed specifically for mobile devices with built-in GPS capabilities!

If you click on the “255 108th Ave NE” link within the Calendar App, e.g. to get driving instructions for getting to this location, the Maps App completely ignores your current location!

Instead, it starts, very bizarrely, with the center of the continental United States and offers suggestions in Omaha, Nebraska (about 1,000 miles away from the current location of the phone, as you can see from the blue dot in the upper-left corner):

Why would a Maps App designed specially for a mobile phone ignore the value of the user’s current location, and start off by suggesting locations that are hundreds of miles away?

Google Maps, in contrast, doesn’t have this problem. If you copy-and-paste just the “255 108th Ave NE” string into the Google Maps app, it wisely starts off by suggesting the closest locations, not the ones that happen to be closest to the center of the continental United States:

A problem that seems so simple to fix, and yet it persists one year after Apple’s Maps was introduced…

We have built a simpler way to handle invitations and requests in Kerika, part of a continued (indeed, never-ending!) push to improve usability. A quick recap of what invitations and requests are all about:

Invitations

Invitations are the messages you receive when someone wants to add you to a project team. If you have never worked with someone before, you need to accept their invitation to join a project – to establish a working or “buddy” relationship. This simple mechanism reduces the possibility of you getting dragged onto projects that you have no interest in, or getting involved with people you don’t know.

When you are invited to join a project, you get a (regular) email that looks like this example:

After you have accepted an invitation from someone, it becomes easier for that person to add you to other projects: we call this an “auto-add”, where they can add you to another project without waiting for your to accept yet another invitation. This makes it easy for you to work with the same set of colleagues and friends without having to wait for them to accept one invitation after another. So, if you are “auto-added” to a second project, you get a notification email that looks like this:

Requests

Requests can be made in a couple of different ways:

You might want to upgrade your role on a project, where you are not the Project Leader or Account Owner. For example, you might be a Visitor on a project, with read-only privileges, who wants to become a full-fledged Team Member. In that case you can easily request an upgrade in your role by using the Project Team dialog box, which is found in the upper-right corner of the Kerika application. Here’s an illustration of how that’s done:

In this example, Betty is currently a Team Member on the project, and is requesting an upgrade to Project Leader. This request for an upgrade in role gets sent to whoever is currently a Project Leader, and the email sent looks like this:

The other type of request is made when a Team Member wants to add someone else to a project team: this will automatically trigger a request sent to the Project Leader, who is asked for approval since it is Project Leaders who ultimately control who gets to be on the project team. The email sent to the Project Leader looks like this:

What’s new: the Inbox

The email aspect of invitations and requests isn’t changing – although we are looking at ways to reduce the odds of these emails getting trapped by spam filters. What is changing is the way you can access invitations and requests from within the Kerika application itself: we have simplified the user interface to look like this:

The old envelope icon is being replaced with an orange square that contains the total number of outstanding (pending) invitations and requests you have: in the example above, this is 6.

Clicking on the orange square will bring up a compact display of all your pending invitations and requests organized into an “Inbox” and a “Sent” list:

In the example above, there are 4 items pending in the Inbox; from top-to-bottom, they are:

• Betty has “auto-added” Arun to the Marketing Review project; Arun’s gotten a notification to that effect. He can open this project by clicking on the Open Project button, which will remove this item from his Inbox.
• Betty has a request to invite Sean to the Build a website project. Since Betty is only a Team Member, her invitation has triggered an request for the Project Leader (Arun, in this case) to approve her invitation. If Arun approves Betty’s request, her invitation to Sean will get sent automatically by the system.
• Betty wants to upgrade her role in the Build a website project from Team Member to Project Leader; this request has gone to Arun who is one of the current Project Leaders. (Maybe Betty wants to be able to add people more easily to this project, without having to wait for Arun’s approval…)
• Susan has invited Arun to join the Getting Started project as a Team Member.

What’s new: the Sentbox

Clicking on the Sent link would bring up a list of all of Arun’s pending invitations and requests:

In the example above, this includes:

• A request made to Betty to upgrade Arun’s role in the Getting Started project from Team Member to Project Leader.
• An invitation to rika@kerika to join the Release 29 project.

The great thing about the Sentbox is that it lets you pull back (i.e. cancel) an invitation or request that you may have made in error, or where you have subsequently changed your mind.

For example, you may have typed in someone’s email address incorrectly when you were adding them to your project – although Kerika’s seamless integration with Google Contacts makes that less likely! – and you would naturally want to cancel that invitation (quickly) before it gets accepted by the wrong person.

To learn more about people and roles in Kerika’s project teams, check out this video:

Amidst all the fireworks of Independence Day (here in the U.S.), we released a new version of Kerika with a bunch of new functionality:

• Card history has been added as a feature: from now on, each card will show who did what, and when.
• When you add Microsoft Office documents to cards, you can choose whether to convert these to the Google Docs format or not. (Files will still get shared using your Google Drive.)
• We have added email notifications for Project Leaders: you can now get email alerts sent when cards are added to your projects, reassigned, or marked as Done.
• Easier ways to manage your tags and do quick filtering of your view of a project board.
• Easier way to retrieve entire projects that you may have deleted.
• A smoother integration with Google Docs Search.
• If someone tries to run Internet Explorer in the deadly “compatibility mode” that we discussed earlier, they are automatically redirected to a web page that explains why compatibility mode is not a good idea.

And… over one hundred minor usability tweaks and bug fixes!

Here’s Google Voice’s transcription of a voice-mail:

Hey, I wanted to. Sorry I was. I would call me when you called driving a satellite probably be in the popular half hour and, I pledge appointment if you’re around. Gimme a call. Otherwise, I think it later. The off and also from Iraq. Thanks. Bye

We finally tracked down a weird problem that had been affecting some Internet Explorer (IE9): Kerika wouldn’t load properly. This is what users saw:

The “loading…” image would just stay on the screen, forever.

It really puzzled us when a few users started reporting the problem because we weren’t experiencing it ourselves, no matter how much we tried testing Kerika on Internet Explorer. Finally, one of our users reported the problem in a way that gave us a very valuable clue: for some reason he had inadvertently made his Internet Explorer 9 switch to “compatibility mode”. With Internet Explorer running in compatibility mode, Kerika won’t work, and neither will much of the modern Web.

The fix to this problem is simple: if any users have toggled their Internet Explorer browsers into compatibility mode by mistake (i.e. hit Alt+8 inadvertently), then please turn your IE9 back to “regular mode”.

How easy is it for users to inadvertently switch their IE browser to IE8 mode? Too damn easy! If you are trying to use the asterisk (“*”) key, you need to type Shift-8. A little carelessness on your part, and you will end up typing Alt-8 instead and switching to IE8 mode! Talk about bad UX design…

Meanwhile, we are going to make a change to Kerika in the next version that will redirect users to an explanation page on our website if the server detects that they are running in IE8 or older.

In case you are wondering what “compatibility mode” is all about, here’s the unhappy history: starting around Internet Explorer 5, which was launched in 1999 at the height of the dot-com boom and amid the fierce battle for browser supremacy with Netscape (remember them?), Microsoft adopted a strategy of getting their largest enterprise customers to create web sites that were based upon Microsoft standards, which differed substantially from what were already emerging as more open, global standards for web sites and browser behaviors.

This was based upon the old model of “owning the platform“: a strategy that had worked brilliantly for Microsoft for many years, helping them dominate one market after another, and for a long while it seemed to work well with browsers as well. Large enterprises built their pages using Active X and ASPX, and while these pages rendered just fine as long as you were inside Microsoft’s walled garden, they were not great long-term investments for these enterprises because the open Web moved onto standards like Javascript and other components of HTML5.

The walls of the garden started crumbling when Firefox came on the scene. At first, Firefox was considered an interesting hobby and Microsoft certainly paid it no attention at all — by around 2005, however, Firefox’s market share was very noticeably growing and Microsoft found that it had effectively dismantled its own browser team, having concluded prematurely that they had already won the browser war. In other words, they hung out the “Mission Accomplished” banner a little too soon.

By the time Firefox started gaining momentum, Microsoft’s IE team was down to a program manager and a couple of developers: in other words, it was the tiniest maintenance team you could imagine. Things did start to change in 2006 when Microsoft belatedly woke up to the Firefox threat, and scrambled to put the band back together again by transferring back all the old IE developers to build IE7. (The old IE team was now all over the place, with a bunch of folks having moved to Xbox which was a particularly hot place to work just then.)

When the newly reconstituted IE team tried to regain momentum in the browser market, they were stuck with Microsoft’s legacy: a large number of enterprises had built up Intranet sites and applications that were increasingly divergent from the emerging HTML5 standards. And so, the next few releases of Internet Explorer (IE7, IE8 and IE9) had to straddle the old, Microsoft-specific world and the new, HTML-5 compliant world.

Internet Explorer 8 never quite made it, but IE9 was definitely better. However, Microsoft still isn’t completely free of the past, as this chart shows:

There’s still a lot of old IE out there, which is scary when one considers that these old versions are not even getting security patches any more. (The 6.21% of the world that’s running IE6, for example, must be fueling all sorts of botnets!)

Until Microsoft can get free from its own past, “compatibility mode” is likely to stick around.