Tag Archives: Microsoft

About Microsoft Office.

From Export as CSV to Export as Excel

Agile & Scrum, Technology, Usability, , , , , ,

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

Agile & Scrum, Technology, , , , , , ,

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.

Lenovo did something really rotten

Technology,

The news that Lenovo pre-installed adware on all consumer laptops sold in the US for the last three months of 2014 (yup, that would be the Thanksgiving through Christmas prime shopping season of the year) is being sadly under-reported by the mainstream press, although the tech press has a better idea of just how much mischief Lenovo did.

The really outrageous point here isn’t that adware came along with the other bloatware that all Windows users suffer from: it’s the fact that this adware was deliberately designed to undermine SSL, which underpins all security on the Internet.

Here’s how SSL is supposed to work: if you connect to Kerika, you are using a secure, encrypted connection to somebody that you genuinely believe is Kerika, Inc. of Issaquah, Washington, United States.

But how do you really know that it’s Kerika on the other end, and not someone pretending to be Kerika?

The only reliable way is to click on the lock icon shown in your browser (whenever you are on a secure SSL connection to any website), and your browser will then tell you who you are connected to, and more importantly, why the browser believes you are actually connected to Kerika and not somebody pretending to be Kerika.

Kerika SSL certificate
Kerika SSL certificate

The image above is the actual SSL certificate shown when you connect to Kerika, and then click on the lock icon in your browser.

It says, in effect, that a company called Symantec Corporation is the one that vouches for Kerika’s identity: in other words, it is Symantec Corp. that is assuring you that it really is Kerika that you are connected to, and not somebody pretending to be Kerika.

These SSL certificates could be issued by anyone, for example Facebook relies upon a company called DigiCert:

Facebook SSL
Facebook SSL

And Bank of America relies upon a company called Verisign:

Bank of America SSL
Bank of America SSL

Unless you happen to be using a Lenovo computer that you bought last Christmas, in which case there is a “man-in-the-middle” that you weren’t aware of:

Lennovo's fake SSL
Lennovo’s fake SSL

(Above image captured by security researcher Kenn White, @kennwhite)

On this Lenovo computer, an adware company called “Superfish” is the one that’s vouching for Bank of America, which isn’t right at all!

This is a classic “man-in-the-middle” attack scenario: most people would see the lock appear on the browser when connecting to a secure website, like Bank of America’s, and assume that they are safe. Instead, their communications is actually being intercepted by Superfish before it gets to Bank of America.

This is inexcusable, even for the “very minor compensation” that Lenovo got from Superfish.

(And, by the way, this is pretty much how most Windows PC manufacturers make money: there is so much price competition in the Windows market that they all resort to bloatware and adware to juice up their profit margins…)

And because the same piece of adware was distributed on literally thousands of machines, the same private encryption key is being used on all of these machines, which makes it easy for people to use these bogus SSL certificates to create man-in-the-middle attacks on any number of banks and other secure websites.

(And, of course, the private encryption key has already been decrypted, just hours after the news about Lenovo broke this morning.)

All this makes for appalling news for anyone who bought a Lenovo PC towards the end of last year. Merry Christmas.

Why we are integrating with Box; Part 5: The OneDrive Option

Kerika, Technology, ,

(The fifth in a series of blog posts on why we are adding integration with Box, as an alternative to our old integration with Google Drive.)

This post is shorter than the others in this series for one simple reason: the OneDrive API has no way for third-party apps to manage permissions on folders, and that’s a show-stopper for us in terms of providing a really good user experience.

This limitation was probably more frustrating for us than the case with Dropbox:

  • We are next door to Microsoft: Issaquah is just 15 minutes away from Redmond, which means its easy for us to find people to talk to at Microsoft.
  • Microsoft has a great history of working with third-party developers and a very robust partner program.
  • Nearly all enterprises who are interested in Kerika are long-standing users of the Microsoft stack (SharePoint/Project/Exchange); a Kerika+OneDrive solution would have been a relatively easy sale in terms of internal IT politics within most enterprises.

We hadn’t taken OneDrive very seriously when it was available only as SkyDrive, i.e., when it was available only as part of the full Microsoft stack, but once Satya Nadella became CEO and (coincidentally?) Microsoft decided to un-bundle their cloud platform and create OneDrive, the platform became much more interesting for us.

(We had seen only lukewarm enthusiasm, at best, for the full SkyDrive package, but OneDrive as a standalone alternative to Google Drive, Dropbox, Box, etc. was more interesting.)

Interestingly, the feedback we got also pointed to why adoption of OneDrive might be slower than Microsoft would like: OneDrive is being marketed as part of the Office 365 solution set, and many of organizations we were talking to seem slow to adopt Office 365.

One big reason for dragging their feet is that few enterprises that we talk to are enthusiastic about the implied upgrade to Windows 8.x.

(Upgrading to Win 8.x isn’t a technical requirement, but the sales push from Microsoft is for the full Win 8.x/O365 deal.)

One cause for this, of course, is that there isn’t any great love out there for the new Win 8.x user interface: few end-users seem enthusiastic, and IT folks are very worried about training and support for a radically different user experience.

Even within Washington State’s government agencies — where one might expect Microsoft to have a home field advantage — we haven’t seen any real enthusiasm for OneDrive; in fact, Box is the only cloud service provider to have a master services contract with Washington!

The full series:

 

Why we are integrating with Box; Part 3: Considering Alternatives

Kerika, Technology, , ,

(The third in a series of blog posts on why we are adding integration with Box, as an alternative to our old integration with Google Drive.)

Adding an alternative to Google Drive was never going to be easy; Kerika has a deep integration with Google:

  • Our registration and sign-in process was built entirely to work with Google IDs.; originally implemented using OAuth 1.0, and then upgraded to OAuth 2.0.
  • The product is available on the Chrome Web Store and the Google Apps Marketplace, so enterprise users can sign up and manage users using their Google Dashboard.
  • When users add desktop files to their cards and canvases on Kerika project boards, these get shared using their own Google Drives.
  • Originally, we had an integration with Google Contacts as well, although we dropped that some months ago since it added to the privacy baggage of working with Google.
  • And, until Google killed this service, we used Google Checkout to handle online payment.

Adding another platform would be a ton of work, and it would delay an exciting product roadmap of new features.

Ultimately, the strategic decision for Kerika came down to: should we add more features to our product, while staying within the Google space, or broaden the appeal of the existing product by adding another platform?

We concluded that the core Kerika product, as it exists today, was already very usable: we could see how it had helped users in a variety of industries and organizations, of all sizes, across sectors, and around the world. And, we could reach even more users if we added a cloud storage platform that didn’t have the privacy baggage that was hampering Google Drive.

Having decided on a broad strategy for the company, the next critical question became: which cloud platform would make more sense for our users?

We considered three alternatives:

  • Dropbox
  • OneDrive/SkyDrive
  • Box

We were initially attracted to Dropbox because of its wide popularity, which far outstrips that of Box or OneDrive.  We figured that if we were going to go through all the trouble of adding another cloud platform, we might as well go for the one with the largest user base.

But, first, we needed a plan of attack…

We started our process by first documenting all the functions of Google Drive that Kerika’s user experience relies upon.

These turned out to be a fairly large set, so we whittled it down to a core must-have set, and a larger nice-to-have set.  This gave us rational technical requirements that we could use to evaluate Dropbox, OneDrive and Box.

The most essential requirement we had was that the Kerika application should be able to manage permissions on folders, not just individual files.  Here’s why it’s essential for the Kerika user experience:

A bunch of our competitors offer a superficial level of integration with cloud platforms, generally at the “file picker” level only.

This means they have a button on their UI somewhere that allows users to pick a file from their Dropbox, Google Drive, etc. and add it to a card on a project board.

But this superficial integration offers no real benefit in a team environment: if you add a file to a card using just a file picker, other folks on the project team don’t automatically get access to that file.

Instead, when they try to open files attached to cards, on a board where they are part of the team, they must ask the file owner for permission — each and every time!

Kerika’s user experience is much better: when you add a file to a card or canvas, the software makes sure that every member of the project team gets instant access to that file, and that access is automatically adjusted to reflect their current role: Team Members get read+write access; Visitors get read-only access.

And the critical requirement was that the Kerika app could manage permissions on entire folders, not just individual files.

A typical Kerika board can easily include a hundred or more cards; in fact, some of our users have boards that run to over a thousand cards. Each of these cards could have several files attached to them.

So, if we are going to manage thousands of files for a single project, we really need to be able to create folders — and ideally sub-folders as well — so that we didn’t just spray these thousands of files all over each users’ cloud storage.

We also started informally polling our current users and future prospects about how they would view a Kerika+Dropbox vs. Kerika+OneDrive vs. Kerika+Box solution.  (The feedback we got was surprising…)

And, finally, we tried to get a sense for how transparent each of these companies would be — how easy it would be build a partnership arrangement, to have a dialog with their platform teams.

The full series:

 

It’s now easier to work with Microsoft Office files

Usability, ,

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!