Making it easier to know when Kerika has a new version

Kerika,

The Kerika team works in 2-week Sprints, but not every Sprint results in a feature being deployed to production: sometimes we have to wait for enough pieces to be built before we can release an entire feature.

(Bug fixes always get deployed at the end of each Sprint, and we we aim to have zero known bugs at all times.)

If you left Kerika running overnight in your browser while we rolled out a new version, it’s important to make sure your browser updates itself to get the latest software from our server.

To make this easier, we are introducing a notification inside the app that will let you know that you need to reload/refresh Kerika to make sure you are working with the latest version. This notification appears only when we have a new version deployed, and we can detect (or suspect) that your browser is running outdated code.

This is what the notification looks like:

New version notification
New version notification

Managing the privacy of your Kerika boards

Kerika, Team Collaboration, Technology, , ,

Kerika offers a great deal of control over how each board is shared:

  1. A board can be made public to everyone.  This makes sense for open-source projects and many nonprofit and advocacy groups, where the goal is to get maximum visibility and publicity rather than to hide the details of what the project is about.

    Making a board public means that anyone who has the URL of the board can view it, even people who are not Kerika users.  Note: we are talking about viewing the board; viewing doesn’t mean anyone who isn’t part of the board team can make changes.

    If a board is viewable by the public, it can be found by anyone using Kerika’s search function.

  2. A board can be viewable by everyone who is part of the account team. This is the default setting, and it makes a lot of sense for most organizations: you want your coworkers to be aware of what your team is doing, unless the project is particularly sensitive.

    An account team consists of everyone who is a Team Member or Visitor on any board owned by the account.

    As people get added to individual boards, they are also automatically added to the account team.  When someone is removed from every board owned by an account, they are automatically removed from the account team as well.

    As with public boards, described above, we are talking only about viewing, not changing: only people who are Board Admins or Team Members on a particular board’s team can make any changes to that board. (And, of course, the Account Owner who owns the board.)
    If you use Kerika’s search function, you can find boards that are being shared with the account team, provided you are part of that particular account team.

  3. A board can be kept private.  This means that only the people who are listed on the board’s team — as a Board Admin, Team Member or Visitor — can view the board.  (And, of course, the Account Owner who owns the board.)

    This is appropriate for any sensitive projects, e.g. stuff related to personnel matters or confidential contracts.

    Private boards can’t be found by Kerika’s search function either, and it doesn’t matter if you know the URL for the board: only the specific people listed on the board team can see anything related to that board.

For each board owned by an account, the Account Owner or Board Admins can manage the board’s team: decide who is part of the team, and what sort of role (Board Admin, Team Member, or Visitor) each person has.

  • Board Admins and Team Members can make changes to all the items on the board, including any documents attached to the board.
  • Visitors have read-only access to the board and all its documents.
  • A person’s role can be changed at any time by the Board Admin or Account Owner: the effect is immediate, and extends to all the documents associated with the board as well regardless of whether you are using Google or Box for your file storage, or whether you are storing your files with Kerika.

A board’s team and current privacy settings can be viewed by clicking on the Team button that appears on the top-right of the Kerika app, when viewing a board:

Board Team button
Board Team button

Clicking on this button brings up the Board Team dialog:

Board Team dialog
Board Team dialog

Each person who is part of the Board Team is listed in this dialog, in alphabetical order along with their role.

At the bottom of the dialog is the board’s current privacy setting: in the example shown above, the board is being shared with everyone who is part of this user’s account team. (We have obscured the URL in the screenshot for security reasons.)

If you are a Board Admin or the Account Owner, you can change the privacy of the board using the Change Privacy link that’s shown on the bottom of the dialog:

Board Privacy options
Board Privacy options

So, every board can have it’s own privacy settings: private, shared with account team, or public.

When you are viewing the boards in an account, Kerika shows clearly what the privacy setting is for each board:

Privacy settings, at a glance
Privacy settings, at a glance

If you are part of someone’s account, you will be able to create new boards in that account: you will automatically be a Board Admin on those new boards, but the owner will always be the account you are working in.

You can set your privacy preferences for each account; this will determine whether new boards you create are automatically shared with your coworkers or not:

Privacy preferences
Privacy preferences

All your preferences can be set at https://kerika.com/preferences.  The default setting is Share with Account Team, which works well for most people, most of the time.

 

Some minor bug fixes

Agile & Scrum, Bug Fixes, , , ,

We did an update yesterday that included a bunch of minor bug fixes and usability tweaks. (It also included a ton of behind-the-scenes improvements to our architecture and product development processes, but if we did our job well you shouldn’t see any of that change…)

  1. When the Kerika server is being updated (to a newer version), your browser will no longer keep trying to reconnect while this is underway.

    We have some code in place to help fix broken network connections: if your browser can detect that it’s connection to the Kerika server is broken for any reason (usually a network error), the browser will automatically attempt to reconnect.

    This doesn’t make sense if the server is down for planned maintenance.

  2. If you are working in multiple accounts and you decide to switch between them, we offer your choices in a more logical way: all the account owners you are connected to are listed alphabetically, and then each account owned is listed alphabetically.

    Our previous display was kind of random making it hard to scroll through a long list of accounts. This affected only a very small number of users who were working on many different accounts, but still…

  3. Now that we are encouraging our customers to converge around service accounts, we are trying to make sure these service accounts don’t get too crowded from the perspective of any single user.

    We have always had the ability to “favorite” some boards (and templates) so you can have your own personal, curated list of boards that you care about — and so you can ignore the rest — but now we have made it easier for Board Admins to move their boards to the trash or archive (or to restore them later) so they can help keep the commonly-shared service account in a more useful and relevant state for all the users within that account.

  4. A really small thing, but we decided to change the Sort by Status feature on our Task Boards and Scrum Boards so that On Hold cards appear at the bottom of the column, below all the others.

  5. Bug fix: if you changed the name of a board using the Board Settings dialog (assuming you are one of the Board Admins), the new name is now reflected immediately in the breadcrumbs.

  6. If someone who is currently a Team Member on your Task Board or Scrum Board is made a Visitor, he/she will not be removed from the current card assignments.  This makes it easier to change your mind if you decide you want that person to be a Team Member after all: just change this person’s role in the Board Team dialog, back to Team Member, and all the old card assignments will be there.

 

A simpler menu for cards and columns on your Task Boards and Scrum Boards

Agile & Scrum, Kanban & Lean, Kerika, Usability, , ,

We used to have separate button, and associated menus, for actions related to cards and for actions related to columns:

Separate card and column actions
Separate card and column actions

This reflected the history of the Kerika product: we first designed and built the card actions, and much later added the column actions.

In retrospect, however, we concluded that separating these into two separate menus was not a good idea: it was confusing for our users to remember which menu supported which action. (Even the Kerika team, which uses Kerika for everything that the company does, was having trouble remembering the differences between the two buttons and menus.)

We have fixed that usability problem with our latest release: a single button is shown, and the popup menu that appears includes both card actions and column actions:

Combined Card and Column Actions Menu
Combined Card and Column Actions Menu

Clicking on the Sort and Move actions brings up all the sorting and moving options you have; the Sort menu now has a much richer set of actions:

Sort options
Sort options

We have also done some small tweaks to the sorting action: Sort by Status now puts the On Hold cards at the bottom of the column, below all the ones flagged as Normal.

G Suite Marketplace listing disappeared

Kerika, Technology

About a week ago, the Kerika listing on the G Suite Marketplace disappeared for reasons we still don’t understand.  We have been working actively with Google’s engineers to fix this, and are confident they will soon deliver a solution — the problem is on their end, not ours — and in the meantime we would like to apologize to anyone who is affected by this.

The underlying problem is that G Suite Marketplace is transitioning, and right now there are some overlapping systems in place that are creating problems for Kerika (and possibly other third-party apps).

Historically, if you wanted to publish your app on the G Suite Marketplace, you did so using the Chrome Web Store — which is where you also published your app for the Chrome Web Store, obviously.

This always led to to some confusion from our perspective: we had to maintain two identical product listings using the same Chrome Web Store Developer Dashboard.  And since this process has been in place, for the past several years, Google itself has been deprecating the use of the Chrome Web Store to distribute browser-based apps through this store.

Meanwhile, the Chrome Web Store Dashboard itself is getting a much-overdue UI makeover, and while this is underway the dashboard doesn’t have all the functionality that the old dashboard does, and there, of course, some bugs remaining in the new dashboard that Google needs to iron out.

(While the old Chrome Web Store Dashboard was ugly as sin, it was old and stable. The new Dashboard is much nicer, but not quite, quite ready yet.)

And there’s also the Google Cloud Platform API Dashboard: newer than the Chrome Web Store Dashboard, and with a completely different user interface and functions, since it manages an app developer’s use of many different cloud services from Google.

This has become another place to maintain your app’s product listing, and this seems to be where our problems originated: the G Suite Marketplace currently takes some information from the Cloud Platform Dashboard, and some information from the Chrome Web Store, to define your product listing.

We have been actively working with Google’s engineers, support and product management to try to resolve this problem — and we are grateful for the attention they have been giving us — and we hope to be out of the woods soon. One unexpected benefit of these problems has been the opportunity to talk to Google about our experience as third-party app developers: hopefully our feedback can help them make the G Suite Marketplace more useful to both Google’s customers and ours :-)

Using Service Accounts to manage all your Kerika Users

Agile & Scrum, Team Collaboration, Technology, , , ,

For some segments of our users, e.g. college students using Kerika for their course projects, it makes sense to treat each user as an independent entity, since the relationships between these students will vary from class to class, from semester to semester.

These collaboration networks are very dynamic, and it’s impossible to predict whether a team that got together to work on a three-month class project will stick together after that project is over, or work as the same group of people on the next class project.

In business environments (companies, nonprofits and government agencies), however, the teams are more stable: people don’t change jobs every few months.  But, turnover can still be a problem: if Joe leaves your company, how can you be sure that all the boards and documents that Joe had created are not lost along when Joe is gone?

The simple solution to this is to use service accounts to own all the boards that are being used by a community of users, like a department or even the entire company (if the company is small enough).

A service account looks like any other Kerika account — it is associated with it’s own email, e.g. kerika@example.com — but it isn’t actually a real person: the email will have been set up by the organization’s IT staff or management, and the password is typically shared between a small handful of supervisory people.

Unlike real people, service accounts will always stick around: they won’t retire, resign, or get run over by a bus…

This means the organization has continuity and security with respect to it’s Kerika boards and documents: because the project assets are owned by kerika@example.com, rather than joe@example.com, it doesn’t matter whether Joe is still working at the company or not.

We encourage all our professional users — people working in companies, nonprofits and governments — to set up service accounts as a best practice, and we can help you: just email us at support@kerika.com and we will do all the account consolidation for you:

  • All the boards owned by the people in your organization will be transferred to the ownership of the service account instead.
  • Everything about each board is preserved as part of the transfer: all the cards, canvases, due dates, etc. remain the same after the transfer; it’s just that the boards are no longer owned by joe@example.com and susan@example.com, but instead are now owned by kerika@example.com
  • You can decide who to consolidate within the service account: typically it is everyone in the organization, but if you have different departments or cost centers, it will make sense to have more than one service account — one for each department or cost center.
  • After the consolidation, individual users within your organization will no longer have separate accounts: their Kerika identity, preferences, history, etc. are all preserved, but instead of working in several different accounts, they will all be working in a single service account, that’s under the control of your organization.
  • All this can be done by us, overnight: the next day your users can come into work and login as they did before, and have access to all the boards they had the previous day. All the boards will look the same, and your users can pick exactly where they left off.

When users have been consolidated within a service account, any new boards that they create will automatically be owned by that service account, rather than by the individual users.  This ensures that all current and all future project assets are owned by the service account, i.e. by the company, rather than by individual users.

It’s still possible for individual users to have privacy within the service account: for sensitive work (e.g. personnel matters) they can adjust the privacy of individual boards to be “share with board team only”.  When the privacy is set to board team only, the board will be visible only to the people who are specifically added by the Board Admins to the board’s team.

The Account Owner, i.e. the service account, will always have access to every board within that account, regardless of the board’s privacy settings. This is consistent with how other organizational assets are currently managed: if you have a work email, for example, you expect to have privacy from your coworkers, but you know that the company’s IT department will always have access to your email if they need it — and your email doesn’t really belong to you, but to your employer.