A small bug fix we did recently: when you do an Export of data from a Task Board or Scrum Board, you get a notification from Kerika when the export completes: that’s because the export could potentially take a long time, if you had a very large board, i.e. with hundreds of cards on it.
(In practice, most exports take just a few seconds, so the notification comes very quickly after you start the Export.)
The notification comes in two forms:
- By email, with a link to open the file containing your exported data.
- In your Kerika Inbox, on the top-right of the Kerika application, looking like this:
There was a bug that clicking on the “Dismiss” button on Kerika Inbox didn’t make the notification go away: it would reappear after a page refresh.
That bug has been fixed. Enjoy.
A new tutorial video on how to export cards from a Task Board or Scrum Board, in the HTML format or as an Excel workbook — featuring our very-soon-to-be-released new user interface.
There are a couple of reasons we did this:
- 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.)
- 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
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.
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.
One of our users in Massachusetts alerted us to a bug in the export function that we have fixed with our latest release: it turns out the export function wasn’t correctly preserving the sort order of cards within the column, which was a nuisance.
Bug fixed, and as always, our thanks to our users for providing valuable feedback!
Some characters shouldn’t be used when you name a project — and we are going to make a change in Kerika that will rename any old projects you have to replace these characters with blank spaces — because they cause problems when you need to export the cards on your Task Board or Scrum Board.
Here’s what you need to avoid:
- Forward slash (“/”)
- Backward slash (“\”)
- Colon (“:”)
- Semi-colon (“;”)
When you do an export, the exported data are stored in a file in your Google Drive (if you are using Kerika+Google) or your Box account (if you are using Kerika+Box) and these characters are used by these cloud services as file separator characters, which means they cannot be part of a file name.
So, your export will fail (and we end up logging an error on our server, which doesn’t make us happy either)
We did make a change in Kerika a month ago that stopped new projects from using these characters in their names, but it looks like there are still a bunch of old projects out there that have these characters in their names, and now we are going to try to clean up these as well.
A tiny change in labeling in our latest version will, we hope, make it clear that Kerika’s Export feature is actually pretty smart about managing the amount of data that you export from a board:
What used to say “Export cards” now says “Export the cards shown”.
“Cards shown” means just what it says: if you are hiding some columns from view, or filtering your view of the board to show just those cards that match particular colors or tags, then only the cards currently shown are going to be exported.
This makes it really easy for you to manage what information goes into an export: if you don’t want the Backlog of a Scrum Board to be included, for example, just hide the Backlog from view before clicking on the Export button.
If you work for a government agency in the United States – at the Federal, State, or Local level – you are subject to various public disclosure requirements, thanks to the Freedom of Information Act and various other federal and state “Sunshine” laws.
(And, if you work for a governmental organization anywhere in the European Union, that’s going to be true for you as well.)
Kerika makes it one-click easy for you to meet you disclosure requirements, thanks to the Archive and Export feature:
Archiving freezes a project, presumably in it’s “done” state: everyone who used to have access to the project still does, but all cards, canvases and documents associated with that project are made read-only.
This means that you now have a pretty good record for what a project looked like when it was completed: what work was done, by whom, and which documents were used and what conversations took place.
And the kind of integrated, comprehensive view of a done project is something that you can get only from Kerika: the old mix of SharePoint and Project and regular email just doesn’t work!
Exporting is the other piece of the disclosure puzzle: with just one mouse click, you can export all (or some) of the cards in a board, in CSV or HTML format.
Exporting in HTML is particularly helpful when meeting disclosure requests because the HTML output can be easily edited, using Microsoft Word for example, to take out items that need to be redacted for security or privacy reasons.
That’s the difference with a modern project management and team collaboration software like Kerika: the worst part of your government job just became one-click easy.
Kerika lets you export cards from a Task Board or Scrum Board in CSV or HTML format: the CSV format is useful for putting data from Kerika into another software tool, like Excel, but the HTML format is designed for human consumption.
Here’s an example of a card that’s been exported as HTML:
By using the Workflow button (on the top-right menu bar), you can adjust your display to show just the Done column on a board, and then further use the Tags button to limit the number of cards that are shown in this column.
For example, you could display just the Done column, and filter the cards to show just the ones that were assigned to you.
Do an HTML export of this, and you will be able to easily cut-and-paste the output into a Word document or email, and submit your status report!