We have always offered all users, including people with the free Standard Accounts, the ability to customize their accounts, and now we are making that a little easier.
For most people, the most convenient way to grab a photo or company logo is from a Web site, and that’s possible now when you customize your account.
When you click on the Add Photo or Add Logo buttons, you will now have the option to upload an image from your local computer, or grab it from a website:
Along with the hundred styling changes and UI cleanup we are wrapping up, we also took the opportunity to fix around 58 different errors and warnings being reported by our server.
This might sound like a lot, so perhaps a little context is useful:
Kerika is built on top of Google Apps (at least, for now): we use Google’s OAuth service to sign up and sign in people, and we use Google Drive to share files within project teams.
A lot of errors show up as a result of this Google integration, only a fraction of which are solvable from our perspective:
Some errors relate to people from restricted Google Apps domains trying to use Kerika. This happens at least once a week — someone working at a company that has Google Apps for Business tries to sign up for Kerika, but fails because their Google Apps Administrator (typically, someone within their IT department) has prohibited any third-party apps from integrating with their Google Drive.
This is an example of an unsolvable problem — we can’t override the existing protection that this company has set up (and nor would we want to!) so we are going to redirect users to an explanatory page that helps them understand the problem is not with Kerika.
Sometimes Google Apps has outages: when this happens, we can get a cascade of errors on our servers, because these outages are typically intermittent and inconsistent across our user base. Some folks experience problems, others don’t. We are trying to come up with a way to inform people about what’s happening, so they don’t think it’s Kerika that’s busted.
Sometimes Google burps: not have an outage, but experience a fleeting problem with uploading a file. We might get nothing back from Google than a generic “500 error: system not available”.
We have also had problems related to our use of Firefox for the Render Server: Firefox’s latest updates are sometimes less stable than previous ones, and in general Firefox is starting to have a really big footprint in terms of memory usage.
And, finally, we have had our own bugs, just like any other software developer. Some of these have been tricky to find, but as we find them, we squash them.
Kerika is starting to get used in larger organizations more: big global companies, and state and local governments, and as we move into these types of user communities we are finding that people are more likely to create large numbers of projects.
(On average, people create 4-5 projects if they are relatively passive users of Kerika, while more active users — like Project Leaders — might create 30-40 projects over a couple of months.)
To make this smoother, we have been improving the performance of the creation of new projects, as well as the copy-paste function for projects.
It turns out both are closely related, so improving one should help with the other!
A few weeks ago we introduced a new feature: if you included a URL reference in a card’s details, attachments or chat, we would fetch that Web page’s title and show that, instead of just the “raw URL”.
This turned out to be a really helpful feature, and so we are expanding it in our next version by adding logic to handle a wider variety of URLs: the new logic should make it easier to have smart references to URLs show up in your cards even when these URLs are pointing to obscure Web sites, Intranet sites, etc.
One of our oldest features has outlived it’s usefulness…
(No, we didn’t actually shoot this dog. Or any other dog.)
We have something we call the “Render Server”: it’s a separate server from the rest of Kerika, and it’s sole purpose has been to create thumbnail images of Whiteboard projects.
This feature was originally built to make it easier for people who created rich, layered Whiteboards — boards where canvases are contained with other canvases, like the amazing Foundation for Common Good Whiteboard project created by Charles Fraser‘s team (in the UK, and worldwide) which looks something like this:
Foundation for Common Good
This is just a partial view of the top-level of a series of canvases, layered within each other to create a rich, multi-media world.
The Render Server helped people understand that some shapes on a canvas contain other canvases within them: for example, if you hovered your mouse over one of the circles on this canvas, you could see — somewhat dimly — a thumbnail of the canvas that was contained within that page:
Showing layered pages
This feature was also used when you added canvases to cards on Task Boards and Scrum Boards: the card details dialog would show a thumbnail of the canvas, like this
Thumbnail image of a canvas attached to a card
This feature was cool, and made for great demos, but it was ultimately not all that useful in a practical sense.
(And that’s true for a lot of cool ideas: things that make for great demos don’t always provide great utility in regular use.)
The thumbnails were too small to be of much use on Whiteboards, and when shown on card details for Task Boards and Scrum Boards they just took up too much space.
So, it’s buh-bye to the Render Server: a cool idea, whose time seems to have passed.
(No, really: we didn’t shoot the dog! We promise!)
Our next update to the Kerika software, scheduled for release this weeekend, will have a bunch of minor styling updates — over a hundred styling changes, in fact.
Most of these are fairly subtle; it’s quite likely you will not notice over 90% of them at all, because this new release is really a UI cleanup effort rather than a big feature release.
Over the past couple of years Kerika had acquired some “UI crud”: little inconsistencies in the fonts, colors, and interactions that had build up over time as you release new features, and we have been releasing new functionality every 4-6 weeks for over 3 years now. It’s like barnacles on an otherwise beautiful wooden boat…
(Not us, but somebody else, polishing somebody else’s boat.)
For example, we found there were minor variations in shades of grey throughout the app: a light-grey shading in one place was off by an octect or two from a light-grey shading in another place. A tooltip was missing from one button here or there, or a tooltip wasn’t phrased as well as it could have been.
Taken individually, these are very trivial indeed — and, unless you examine the entire UI with a magnifying digital color meter, like we did, you wouldn’t have found these tiny inconsistencies, but they can have a cumulative effect that makes the UI seem vaguely fuzzy. (Just like barnacles, if left un-scrapped, can slow down even the most beautiful boat.)
The most visible change we made is the card details display: what you see when you open up a card on a Task Board or Scrum Board
New Card Details dialog
This display is cleaner than what we used to have: it has a more consistent appearance with the rest of the Kerika user interface, and gives equal prominence to all the user interface elements within this dialog — because all of these elements are, in face, equally important to users. Our previous design gave undue prominence to Details, Attachments and Chat, which reflected nothing more than the historical evolution of the Kerika software; now, everything about a card is equally accessible.
The layout is also a lot cleaner: unnecessary decoration has been eliminated, and the overall style is more “flat” (i.e. in keeping with Microsoft’s Metro/Modern design styling, which even Apple has now adopted for iOS 7).
In an earlier blog post we noted that Google is making it increasingly hard for people to create and maintain distinct Google IDs, and this is creating more problems for Kerika users, forcing us to rethink our “cookie strategy”. Here’s the background:
Long-lived and short-lived cookies
When you sign in to Kerika, you do so using your Google ID: the Kerika server gets an authorization token from Google and places a cookie on your local computer so that you don’t have to sign in again, if you close and then reopen your browser.
We had been using what’s known as a “long-lived cookie”: one that doesn’t automatically expire when you close your browser. That made Kerika more like a news site than a banking site: when you login to a news site as a registered user, you get a long-lived cookie so that you don’t have to login again, even after you have closed your browser (or even restarted your computer).
Banking sites, on the other hand, use “short-lived cookies”: if you close your browser tab, open a new one and try to access your bank account again, you will be asked to re-login.
Short-lived cookies are generally used for more sensitive websites, like banking, because there is a big tradeoff in terms of user convenience. Kerika had previously opted for long-lived cookies because we wanted to make it really convenient for people to get back to their Kerika boards after having closed their browser.
The problem we face
The problem we are facing now is that it is increasingly more likely that your Kerika login is out of sync with your Google login. There are at least two ways in which this could happen, one of which was always a risk, and the other a new risk resulting in the shift in Google’s approach to user IDs:
The old problem: people with multiple Google IDs would frequently switch between them, without logging out of Kerika. For example, someone has two Google IDs: A and B. She may have signed up with Kerika while she was logged in as User A. Since we were using long-lived cookies, a Kerika cookie identifying her as “User A” will stay on her machine until she logs out of Kerika. But, in the interim she may have separately logged out of Google as User A and logged in as User B (perhaps to check her Gmail on a different ID). This would result in a situation where she is known to Kerika as User A, and currently logged into Google as User B. In this scenario, she would be unable to open any files attached to her projects because of the mismatch in IDs.
The new problem: Google is making it easier for people to be logged in as two different IDs, using the same Chrome browser. (Note: this is true only with the Chrome browser; not true with Safari, Firefox or IE as far as we know.) This considerably increases the odds that a user is currently logged into Kerika as User A, and simultaneously logged into Google as User B. Because the user never consciously logged out from Google – just switched IDs while on YouTube or Gmail or somewhere – she may be unaware that she isn’t who she thinks she is…
The short-term solution
We can mitigate this problem by switching over to short-lived cookies. This makes the user experience a little more annoying, in our opinion (because you have to login more frequently to Kerika, or remember to keep your browser alive), but it should help reduce the odds that your Kerika ID is out of sync with your Google ID.
The long-term solution
Allow users to sign up directly at Kerika, without using their Google IDs!
We currently have a function to let you Cut/Copy and then Paste a project from one account to another, but it’s starting to look like this is a bad idea because it is very difficult to implement cleanly.
The underlying problem is that a project is more than a collection of cards: it is also part of a network of people relationships, connections to other projects, etc., and these can’t all be moved cleanly from one account to another.
For example, consider a series of projects that are organized as Scrum Boards, linked to a shared Backlog within one account. If we copy and paste one of these projects to another account, what exactly should happen to that Backlog? It’s not an easy matter to simply copy the entire Backlog over as well, to the new account — that may not be the most sensible outcome in all, or even most, circumstances.
Consider an even more basic problem: a project has a bunch of folks working on it today. If you copy and paste the project to another account, what should happen to this team? These folks may not have previously been part of the new account’s team: they would have to get invited to join projects in that account, and very likely the new account’s owner would have to upgrade her account to support the larger team size.
There a bunch of conundrums like this to work through, and it’s not clear that this is even worth the considerable effort it would take to create a bullet-proof solution – how often, after all, do people need to move a project from one account to another?
If the answer is “not very often”, then it’s probably better for us to remove this functionality, rather than leave users with a less-than-great experience…
Every card, every canvas, every board in Kerika has a unique URL.
This makes it really easy to link items together, by using the URL in a card’s chat or description. And, with our latest version, Kerika makes this even easier by showing the title of the other card. Check out this quick tutorial video:
Although Kerika is built on top of Google Drive, you can still share files in Microsoft Office format.
Here’s how it works:
By default, your files are converted to Google Docs format when you add them to a card or canvas in Kerika, but if you prefer, you can keep them in their original Microsoft Office (or other program, like Adobe) format.
Toggle the “Use Google Docs for projects in my account” to OFF, and your Microsoft Office files will remain in their original format even as they get shared using Google Drive.
To make this preference even more useful, we have added a “smart download” feature: if you are storing your files in Microsoft Office format, clicking on a file attached to that card will automatically download that file for you, so that you can open it in Microsoft Office.
For example, if you have added a Microsoft Word file to a card, and are storing it in the original MS Office format, clicking on the attachment will download the file and launch Microsoft Word so that you can immediately start editing the file.
In some cases you might see a “403 Access Denied” message appear: if you do, there is a simple workaround for this problem – just open docs.google.com in a separate browser tab, and try again. It will work this time.
A very important point to note: if you download and edit a file, make sure you attach the modified document as a new attachment to your card (or canvas); otherwise your team members won’t see the latest version!
This website uses cookies to improve your experience. We'll assume you're OK with this, but you can opt-out if you wish.AcceptRead More
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
