Tag Archives: Usability

About software usability in general.

By Invitation Only: clarifying privacy settings on your Kerika boards

We made a small label change that we hope makes it clearer what your choices are for managing the privacy of your Kerika Task Boards, Scrum Boards or Whiteboards: “By Invitation Only”.

We used to have a setting that we had labeled “Team Members and Visitors”; it came with some help text that we thought clarified the issue, but which didn’t work well enough for everyone — as we found out through our ongoing conversations with users.

This is what it used to look like:

Team Members and Visitors
Team Members and Visitors

 

It turned out that not everyone was reading the help text that appears just below the choice for “Team Members and Visitors”.

So, we are tweaking the choice to say “By invitation only”, which we hope will be more self-explanatory.

By invitation only
By invitation only

Sometimes the best usability improvements come from just changing a few words…

From Export as CSV to Export as Excel

We used to have Export as HTML and Export as CSV as options for our Task Boards and Scrum Boards, and with our latest version we are tweaking the Export as CSV to become Export as Excel instead.

There are a couple of reasons we did this:

  1. We now include chat and document links in the export: this was done specifically to help our many government users who need to respond quickly to Freedom Of Information Act (FOIA) requests.
    (See our separate post on how Kerika makes FOIA-compliance one-click easy.)
  2. Everyone who uses the CSV export wants the data to end up in an Excel file anyway, so why not put it in that format to start with? (After all, it’s easy to go the other way as well, from Excel to CSV…)

Export as Excel

Export as Excel

Introducing Planning Views: a whole new way to view your Kerika Boards!

We are delighted to introduce Planning Views, a very innovative, very unique way to view your Kerika Task Boards and Scrum Boards!  (Yes, it goes way beyond what simple calendar views, like those you might get from other tools, work :-))

Let’s start with your familiar view of a Kerika Task Board or Scrum Board, which we will start calling the Workflow View from now on:

Example of Workflow View
Example of Workflow View

 

There’s now a simple drop-down that appears on the breadcrumbs, letting you switch to one of the Planning Views:

Selecting a View
Selecting a View

 

Your new viewing choices include:

  • Next 3 days: this will show you everything that’s Due Today, Due Tomorrow, Due the Day After, and beyond
  • Next 3 weeks: everything that’s Due This Week, Due Next Week, Due the Following Week, and beyond.
  • Next 3 Months: everything that’s Due This Month, Due Next Month, Due the Following Month, and beyond.

Planning Views provide a date-oriented view of your Task Boards and Scrum Boards: a Planning View takes your cards and rearranges into time-oriented columns.

Here’s an example of a Next 3 days view:

Example of 3-day View
Example of 3-day View

 

Our Workflow view got neatly (and quickly!) pivoted to arrange all the cards in terms of when they are due:

  • All cards without any due date are shown first, in the Not Scheduled column.
  • Next, any Overdue cards are always shown in a special column by themselves, so they can be easily rescheduled.
  • Beyond this are columns for Today, Tomorrow and the Day After.
  • And finally, there is the And Beyond column, which summarizes all the cards that have due dates beyond the day after tomorrow.

Here’s the same board, but viewed in terms of the Next 3 weeks:

Example of 3-week View
Example of 3-week View

 

Switching between these views is super-fast, and these views update in real-time: if a due date for any card is changed by anyone on your project team, no matter where they are located, this change is instantly reflected in your view.

The Next 3-months view is an even higher-level view of the board:

Example of 3-month View
Example of 3-month View

 

All these views support smart drag-and-drop of cards: if you drag a card across, or up/down a column, the Due Date is automatically changed to reflect the new date.  As you move the card, the new date is shown in orange so you know exactly what will happen next:

Smart drag and drop
Smart drag and drop

 

Since your Planning Views aggregate cards that may be in different columns on your Workflow View, we made it really easy for you to see at a glance where each card is in terms of your workflow:

Where cards are in your Workflow view
Where cards are in your Workflow view

 

Navigating forward and backward in time is also easy, as is jumping to “today’s view” if you have navigated too far into the future:

Navigating the Planning Views
Navigating the Planning Views

 

As you navigate forwards or backwards, the “And Beyond” column magically adjusts to show you just what’s out of your current view!

Planning Views work just as well with Task Boards (if you are using Kanban) and Scrum Boards (if you are using Agile).

Check out Planning Views — it’s exactly the kind of great design and innovation that you have come to expect from Kerika…

The Whiteboard Daily Digest: a feature that died quietly, a long time ago

A long time ago we used to have a feature we called the “Daily Digest” which sent an email everyday summarizing all the changes that had been done to your Whiteboard projects overnight.

(This was back before we added Scrum Boards and Task Boards as a feature, when all we had was our patented Whiteboards.)

We never got this feature to work properly: not because it was buggy in a technical sense, but because we could never figure out how to make it a useful feature.

After trying numerous times to tweak it we finally gave up a long time ago.

And promptly forgot all about it.

It turns out that the feature had only been turned off on our server software; it hadn’t actually been ripped out.

We stumbled upon it in an obscure corner of our vast code base recently and were surprised to find it still there, albeit in a “commented-out” form.

Well, it’s gone for good now. It never worked well, it had been turned off for years, and now it’s in the trash…

What happens if you have a Kerika+Google and Kerika+Box account, in the same name?

As you know, we offer a great integration with both Google Drive and Box, giving you the choice of using either of these cloud storage services when you sign up as a Kerika user.

For most people, the choice of whether to use Google or Box is often made by their employer, whose IT departments may have already developed a cloud strategy for their organization.

For a small number of people, particularly those in organizations that haven’t committed to a particular cloud strategy yet, they do have the choice of using either cloud service, or even both.

So, what happens if you have the same email address, e.g. someone@example.com, and you set up a Google ID and a Box ID that use this same address?

You could end up with two different Kerika accounts that use the same someone@example.com ID: that’s because each sign up, from Google and from Box, takes a different path into Kerika.

This is not a great situation to be in, and we certainly don’t recommend it, but the software does try to behave well when confronted with this situation.

If another Kerika user invites you to join her project team, the invitation will show up in both your Kerika+Google and your Kerika+Box account — and in your email, of course — but when you try to accept the invitation Kerika will check to make sure you are logged into the correct service.

Here’s an example: Jon, who uses Kerika+Google, invites Arun to join one of his projects. Arun happens to have both a Kerika+Google account, and a Kerika+Box account, but Jon doesn’t know that — and he shouldn’t have to care, either!

When Arun sees the invitation, he happens to be logged into his Kerika+Box account:

Invitation received on Kerika+Box account
Invitation received on Kerika+Box account

 

But when he tries to accept the invitation, Kerika checks to see whether Arun and Jon are both using the same cloud service, and discovers that Arun is logged into his Kerika+Box account and not his Kerika+Google account:

Prompt to login to Kerika+Google account
Prompt to login to Kerika+Google account

 

So, Kerika works behind the scenes to help Arun sort out his two accounts.

Using Kerika with Safari in “Private” mode

Using Kerika with Safari in “Private” mode can result in some odd behavior, and that is entirely due to the way Safari works — it’s pretty much out of Kerika’s control :-(

The underlying problem is that Safari doesn’t allow Web apps to use local storage (cache) when the browser is in “Private” mode.

Since Kerika relies upon local storage to provide a smooth, real-time effort, this can compromise the user experience if you use Safari in Private mode.

To learn more, check out this Stack Overflow article.

We are going to drop support for Internet Explorer 9

We have been one of the last jazzy Web apps out there that was still running on Internet Explorer 9, but that’s going to change: with our next release, due in a month or so, we will be asking Internet Explorer users to upgrade to IE10 or later.

The main reason for this change is that all “modern” browsers — and IE9 qualifies as “modern” only when it stands next to IE8 — do a lot of work within the browser itself that Kerika currently does: stuff like managing and manipulating the DOM structure of the Kerika application.

This means that the Kerika client-application — the bit that you actually see and use in a browser — is unnecessarily complicated, and somewhat slower, than it needs to be, because we are doing some work that IE10+, Chrome, Firefox and Safari all do within the browser itself.

Dropping support for IE9 will enable us to provide a faster user experience, with less complexity in the code.

Why Box can seem too “chatty” with their email notifications

Some of our Kerika+Box users have been complaining about the number of email notifications they get when new projects are created: this has to do with Box, rather than Kerika, but it’s helpful to understand what’s going on, and what you can do about it.

When you create a project in Kerika, Kerika creates a dedicated folder for the files that will be used in that project.  This folder is shared with whoever needs access to that Kerika project.

Every Kerika user can set a personal preference:  you can choose to share your new projects with your account team automatically when they are created, or just with people as and when you add them one by one to a Kerika project.  By default, this is set to “share with account team” since this helps people discover new projects within their organization.

One downside of this: whenever you create a new project team, especially if it owned by a service account, a new Box folder will get created for this project and shared automatically with everyone who is part of that account.

This was resulting in way more emails than anyone wants to see, so we have made a change in the way we work with Box:

  • When people get added to a Box folder, through Kerika, they will no longer get an email notification.
  • However, the Account Owner will still be notified; there doesn’t seem to be any way around this.

 

Don’t smile (too much)

When you chat on a card, on any Task Board or Scrum Board (or on the canvas on a Whiteboard), the chat message gets sent to the right people as emails.

And who are the “right people”? Well, anyone who is assigned to that card will get the chat sent as email, and Project Leaders can optionally get chat pushed to them as email as well. Everyone else can catch up with the chat when they visit their board.

When chat messages get pushed to you as email, you can reply to them just like regular email (all you need to do is a simply “Reply”, not a “Reply All”).

But, don’t go crazy with emoticons!  Most smileys work OK, but not every emoticon will get encoded correctly (using UTF-8).

So, it’s natural to be happy when you are using Kerika, and it’s OK to smile while you work, but don’t use too many strange emoticons in your email replies!

:-)

Using Kerika, but not using English

Right now, the Kerika user interface is entirely in English, but we have users worldwide and many of them use Kerika with other languages, e.g. Greek, Japanese, Korean, etc.

When you export data from a Task Board or Scrum Board that includes non-English characters, the foreign characters are actually preserved correctly as part of the exported data, but if you need to then import data into some other program, like Microsoft Word or Excel, you need to make sure the other program correctly correctly interprets the text as being in UTF-8 format.

WHY UTF-8?

UTF-8 is a coding standard that can handle all possible characters, so it works with languages like Greek, Japanese, etc. which don’t use the Roman alphabet.

For a long time now, UTF-8 has been the only global standard that works across all languages, because of its inherent flexibility in handling different character sets.

When you do an export of data from a Kerika Task Board or Scrum Board, we create the CSV files in UTF-8 format, and include what’s called the Byte Order Mark (BOM) in the first octect of the exported file.

Including a BOM is the best way to let all kinds of third-party programs know that the file is encoding in UTF-8: it’s a standard way of saying to other programs, “Hey, guys! This text may contain non-English characters.”

And for the most part, including a BOM works just fine with CSV exports from Kerika: Google Spreadsheets interprets that correctly, Microsoft Excel on Windows interprets that correctly, but not…

EXCEL ON MACS

Many version of Excel for Macs, going back to Office 2007 at least, have a bug that doesn’t correctly process the BOM character. Why this bug persisted for so long is a mystery, but there we are…

The effect of this bug is that an exported file from Kerika, containing non-English characters, will not display correctly inside Excel on Mac, although it will display correctly with other Mac programs, like the simple Text Edit.

There’s not much we can do about this bug, unfortunately.

THE TECHNICAL BACKGROUND TO ALL THIS:

BOMs are used signify what’s called the “endianess” of the file.

Endianess is a really ancient concept: in fact, most software developers who learned programming in the last couple of decades have no idea what this is about.  You can learn about endianess from Wikipedia; the short summary is that when 8-bit bytes are combined to make words, e.g. for 32-bit or 64-bit microprocessors, different manufacturers had adopted one of two conventions for organizing these bytes.

For Big-Endian systems the most significant byte was in the smallest address space, for Little-Endian systems the most significant byte was in the largest address space.

(If you have a number like 12345, for example, the “1” is the most significant digit and the “5” is the least significant. In a Big-Endian system this would be stored as “1 2 3 4 5”; in a Little-Endian system it would be stored as “5 4 3 2 1”. So, when you get presented with any number, you really need to know which of the two systems you are using, because the interpretation of the same digits would be wildly different.)

(About a dozen years ago Joel Spolsky, former PM for Excel, wrote a great article on the origins and use of BOM, for those who want to learn more about the technical details.)

Why this affects Kerika at all? Because when you do an export of cards from Kerika, the export job is run on a virtual machine running on Amazon Web Services.

We have no idea what kind of physical hardware is being used by AWS, and we are not supposed to care either: we shouldn’t have to worry about whether we are generating the CSV file using a little- or big-endian machine, and whether the user is going to open that file with a little- or big-endian machine.

That’s the whole point of using UTF-8 and a BOM: to make it possible for files to be more universally shared.