Tag Archives: Microsoft Office

About Microsoft Office.

Managing multiple versions of files just got a lot easier

With our latest update we have made it much easier to manage different versions of files, across all your Task Boards, Scrum Boards and Whiteboards.

(This was inspired by our recent fix to a bug that didn’t properly download the latest version of a file attached to a card or canvas; while fixing this we started thinking deeper about how to make file management even easier for our users.)

Here’s how file management works now: when you hover your mouse over a file attachment, a new action called +NEW VERSION is available:

Uploading new version of document
Uploading new version of document

Clicking on the +NEW VERSION button will let you pick any file from your computer that’s of the same type, and Kerika will add that and track the file as a new version of your old attachment.

This is possible even if the new file has a different name altogether, as long as the two files are of the same type.

For example, a filed called Budget.xlsx can get a new version that’s called Plans.xlsx — both are tracked as different versions of the same file, even though they had different names.

This makes it even easier to manage all your files using Kerika!

Bug, fixed: adding SharePoint URLs as attachments on cards

Thanks to one of our users at Washington State’s Employment Security Department, we found and fixed a bug that was causing problems when users tried to add SharePoint URLs as attachments on cards, for Task Boards and Scrum Boards.

The problem turned out to be in some code we have that tries to check whether a user is entering a valid-looking URL.  SharePoint’s URLs are somewhat unusual in that they include the “{” and “}” characters, which most other web servers don’t use.

Our old code was treating these characters as invalid, thereby rejecting URLs coming from SharePoint.

This has been fixed now.

Thanks!

How Project Settings Work in Kerika (A Preview of Coming Attractions)

Here’s a teaser video of the new Kerika user interface, which we are getting close to releasing…

Among other things, we will consolidate and improve a bunch of project management features under a new “Project Settings” button.

Check it out:

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

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.

It’s now easier to work with Microsoft Office files

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.
  • Go you personal preferences page, at https://kerika.com/preferences, and you will see this preference switch:
Setting your Kerika preferences
Setting your Kerika preferences

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!