All posts by user

When you copy and paste a project, do you want the team too?

Here’s a new feature we are adding: when you copy and paste an entire project from one account to another, you can decide whether to take the team as well.

Consider these two scenarios:

  • Alice makes a copy of a project that she owns and pastes it right back into her own account. (Why? Well, maybe she wanted to make a backup copy, or maybe the actual project was going to split into two parallel efforts and so copying-and-pasting the entire project makes sense.)
  • Bob makes a copy of a project that Alice owns, and pastes it in his own account. (Of course, to do this Bob would need to have access to Alice’s project in the first place.)

In the first scenario, the duplicated project is showing up in the same account as it was before, so Kerika assumes that the team should be copied as well: in other words, “Project A” and “Copy of Project A” will both have the same team, at least to start with although each version of the board may then change its project teams independently of each other.

In the second scenario, however, it’s a little more murky: did Bob just want to copy the cards and canvases of Alice’s project, or is he trying to actually set up the same project in his own account? It’s hard for Kerika to make a really good guess in this scenario, so the system asks you:

If Bob responds “Yes” to this question, his copy of Alice’s project will also come with all the team members who were originally working on Alice’s project.

Of course, this might mean that Bob is now adding some folks to his account team: people he hadn’t worked with before.  These people are added automatically to Bob’s account team if he wants to take the team along with the project.

Adding images to canvases: differences between Google and Box

Kerika+Google, our integration with Google Drive, and Kerika+Box, our integration with Box, are very similar in terms of user interface, but the underlying cloud storage platforms are different in some subtle ways.

One of these has to do with the way images that are added to a canvas are named: when you add an image to a canvas, either by using the Upload button or simply by dragging and dropping the image from your desktop onto the canvas, Kerika will show a small thumbnail of the image on your canvas.

The thumbnails provided to Kerika by Google are better than those provided by Box in a couple of ways:

  1. Box’s thumbnails are square, which can result in a cropped view of the image; Google’s thumbnails show the entire image.
  2. Google’s thumbnails can be resized nicely on the Kerika canvas, simply by selecting it and then dragging on one of the corners; Box’s can’t.
  3. If you rename a Google thumbnail and take off the original file extension, e.g. you rename “picture.jpg” to be just “picture”, the thumbnail still renders correctly, but Box’s doesn’t. (Because Box relies on the file extensions to detect the file’s MIME-type.)

There are some other quirks with the way Box and Google work, but most of them are going to be invisible to most Kerika users.

Google is going to do to GoDaddy what it did to AltaVista

We have been trying out Google’s new domain management service for the past month, and we are impressed.

(Caveats: this service is in “beta”, whatever that means in Google-speak; it is available only to people in the U.S.; it doesn’t handle every one of the new top-level gLTDs — yet.)

But for all that, Google’s simplicity of UI and the overall user experience is way better than what we have seen from Register.com, GoDaddy, NameCheap, and a bunch of others.

In many ways this reminds us of Google in 1999, when it’s very simple search engine was a welcome contrast to the muddled portals offered by companies like HotBot, Lycos, and AltaVista.

Everything extraneous has been stripped out, and the process of transferring and managing domains has been made very clear even for non-technical people.

Folks like GoDaddy have a very short window of time to, literally, clean up their act before Google mows them down.

 

Google Apps Bizarro World

Google Apps has created a Bizarro World for some of its premium customers, and in the process is doing really bad things to its ecosystem of independent software vendors (ISVs) like Kerika.

Two questions come to mind:

  1. Do they know?
  2. Do they care?

First, an explanation of how this Bizarro World came about…

Google Apps has a lot of free users — anyone with a Gmail or YouTube account, for example — but they also have several million business users who pay around $5 per user, per month, to get “Google Apps for Business” (which is also variously rebranded as Google Apps for Government/Education/Nonprofits…)

It used to be that any Google user could easily try out an app like Kerika that uses a Google ID for sign-in, and Google Drive to store files.

This was a pretty good arrangement, and among other things it encouraged ISVs to integrate with Google Apps — which helped Google in it’s “all your base are belong to us” goal of world domination.

Last year, however, they made a significant change: premium users of Google Apps can now only try out new apps like Kerika if their Google Apps Admin permits it.

In other words, no more experimentation, exploration, discovery…

Instead, we have the quite deliberate creation of a bureaucratic bottleneck (justified by the always useful umbrella excuse of “this is better security”?) where every user in every organization that wants to try out Kerika must first find out who their Google Apps Admin is — which is no easy task, if your organization consists of several tens of thousands of employees! — and then get them to approve the use of Kerika by everyone within the organization.

This is simple enough if your organization is small — you can easily contact your Google Apps Admin — but what happens if, say, you work in a university with 30,000 other people in that Google domain?

We have been finding out the hard way that Bizarro World hurts: the Google Apps Admin at one university has been working for over 6 months to reconcile Google’s demands with the university’s own policies.

Because…

  • Only the Google Apps Admin can approve use of Kerika.
  • The university prohibits system administrators from entering into any agreements — all licenses and agreements can be accepted only by the Purchasing Department.
  • No one in the Purchasing Dept is a Google Apps Admin, since this is an IT function that has nothing to do with purchasing.

It’s a perfect Catch-22

Google’s message to its premium users

So, back to our original two questions:

Does Google know this is happening? Yes, they know.

It actually affects two large universities right now that are interested in trying out Kerika — each university has a population of about 30,000 people, so, yes, Google does know this is a problem.

And, we have

Does Google care? Apparently not.

The Google Apps Admins at these universities cannot get any kind of help from Google, and we at Kerika have directly brought this to the Google folks and not heard anything either.

Welcome to Bizarro World.

 

Our smart highlights are now even smarter

One of the coolest features in Kerika is how well the system alerts you to changes made on your Task Boards and Scrum Boards that you haven’t seen — i.e. because you were working on another board at the time your coworkers made changes, or maybe because you were fast asleep in a different timezone!

Whenever a coworker makes any change to a card that you haven’t seen — moving the card to a different column, changing its description, changing its tags, leaving some chat, etc., the change is highlighted on the card using orange.

Smart highlights
Smart highlights

And when you catch up on that change, e.g. open the card and read the new chat, the orange highlight gets turned off automatically.

(You can also mark a card’s changes as “read”, using the right-mouse-click menu.)

These smart highlights are great for distributed teams, and indeed for any person who is involved with multiple projects because it lets you catch up on what’s changed while you weren’t looking.

Now, these smart higlights are even smarter: if a card has multiple changes to it that you haven’t seen, e.g. it has a new attachment and it has new chat, Kerika keeps track of which changes you have caught up with, and which ones you haven’t.

In this example, if you read the chat, the orange highlight of the chat icon will go away, but the orange highlight of the attachments icon will remain until you catch up on the new attachments as well.

Kerika: getting smarter every day…

Getting rid of a pesky “Mixed Content” warning

When you first use Kerika, your browser has a reassuring sign that your connection to our servers is being encrypted:

No warning when you first use Kerika
No warning when you first use Kerika

But as soon as you open a card that contains any attachments, e.g. files stored in your Box account if you are using Kerika+Box, this reassurance would disappear, and instead you would see a warning about “Mixed Content”, which basically means that some of the data shown on your Kerika page was coming from a source that wasn’t using HTTPS.

Why there is a mixed content warning
Why there is a mixed content warning

This was because of a small bug in how we were dealing with the thumbnails we got for files stored in your Google or Box account: for faster performance we were caching these on our own Amazon S3 cloud storage (so we wouldn’t have to keep getting them from Google/Box every time you open the same card.)

It turns out that we weren’t fetching the thumbnails from S3 using HTTPS, which meant that as soon as you switched to the Attachment view of a card, your browser’s address bar would show the “mixed content” warning.

There was no real vulnerability resulting from this, but it did interfere with the user experience for that minority of users who like to keep a sharp eye on their browser’s address bar so we have fixed that with our latest release.

Now you should always have the warm reassurance of seeing the green secure site symbol on your browser when you open a card!

When “Recently” is no longer recent

Where dates are shown on Kerika’s boards and cards, we try to show them in relative terms rather than absolute terms.

For example, if something was updated today, we use the word “Today” instead of the actual date.

There’s a simple reason for that: relative times and dates are much easier for people to comprehend than absolute values. In other words, it’s much easier for someone to comprehend “5 minutes ago” than “Dec 30 2014 3:58PM PST”.

Absolute dates and times may be more accurate, but relative values are a whole lot easier to process for regular humans.

One problem we had with our display of relative times, however, was that they were not continuously updating — instead, they relied upon the page being refreshed in order to show the most accurate relative time description.

For example, if something was updated “2 minutes ago”, the phrase would remain displayed on the screen for a long time, if the page was never refreshed. This obviously can lead to confusion, since users are not going to be aware of when they last refreshed a page.

With our newest release, we have fixed that problem: relative times will still be in use, but they will update themselves automatically, so that “5 minutes ago” will soon become “10 minutes ago” and then “1 hour ago” without the user having to do anything.

Another nice improvement in Kerika’s usability!

A mysterious grey dot

Here’s one of the weirder bugs we ever fixed: it turns out that there is a tiny grey dot in the middle of every canvas on a Whiteboard.

Grey dot in the middle of the canvas
Grey dot in the middle of the canvas

It’s been there for a while, ever since we introduced some animation to make it easier for people to understand that canvases can be embedded inside cards on Task Boards and Scrum Boards, as well as being used independently on Whiteboards.

But the funny thing is that none of our users, nor anyone on our team, noticed it because too many of us, it seems, eat in front of our computers all too often, so our screens are flecked with little bits of food debris most of the time :-)

One of our team members finally noticed it after assiduously cleaning his computer screen, and that’s how we discovered there was an HTML element there, with a zero size and absolute position at the center of the canvas (to help with the “exploding” animation effect when a canvas is opened).

Although this element has a height and width of zero, it also has a 1 pixel wide solid grey border, which is used in the animation.

And that’s what appeared as the tiny grey dot in the middle of the screen: one pixel of grey border, not any debris from our lunch.

Adding cards while your Tags filter is turned on

The Tags filter button, which appears on the top-right corner of your Task Boards and Scrum Boards, lets you filter your view of a crowded board by showing just those cards that match a particular tag that you are using (or a particular color coding):

Tags button
Tags button

It used to be that when you were filtering your view of the board, you couldn’t add any new cards.

The reason made sense from a technical, geeky perspective, but it proved confusing and frustrating for our users, so we have added more flexibility by letting you add new cards even while you are using filtering.

The new cards will appear as you add them to the board, and stay there until you refresh your view of the board. At that point, whether the new cards continue to appear or not will depend upon whether they meet your tags filtering criteria or not.

That sounds complicated, we know, so let’s take a look at the original logic behind not letting users add cards while using tags filtering…

In the example screen shown above, the board has a bunch of tags defined, like admin, box, bug, canvas, and cleanup.

Suppose we were using filtering, to only show those cards that are tagged bug and box. With this filtering in effect, you are going to see only a small subset of all the cards that exist on the board — only those cards that have either bug or box as a tag. (Or both.)

So, what should happen if you add a new card to the board, which isn’t tagged bug or box?

From a strictly logical perspective, this new card shouldn’t be displayed, because it doesn’t match the filter criteria you are currently using — it should be displayed only if the new card had bug or box as one of its tags.

We originally dealt with this problem by saying that you couldn’t add new cards while using tags filtering, because the new cards would disappear immediately after you had added them, which we felt would make for a very confusing user experience.

(People would likely think they failed in their attempt to add a new card, and keep trying. Eventually they might turn off tags filtering, and then find they had added many copies of the same new card.)

So, that was one solution to the problem, but it still presented a user experience challenge because many folks would forget that they had turned on tags filtering, especially if they were bouncing around between multiple boards. (Yes, Barb, we are looking at you!)

If a user returned to a board and didn’t realize that they had tags filtering turned on, they would get confused as to why they were unable to add new cards.

We thought of a couple of different solutions to this problem, including the use of callouts (those balloon-like bubbles that appear to give you hints about how a page works) but we aren’t generally a fan of callouts — too many apps misuse them to excess these days.

So we have come up with what we think is a better solution: if you are using tags filtering, go ahead and add new cards. They will show up, but if you refresh your page, your tags filtering will be re-applied, and the new cards will be displayed only if they match the tags you want to show.