When you add files to your Kerika+Box projects, either as attachments to cards on Task Boards or Scrum Boards, or on canvases and Whiteboards, these get stored in your Box account.
If you have a premium (enterprise) version of Box, you can directly download these attachments, instead of having to go through Box’s preview display first: just hover over an attached file, and you will see a “download” button appear:
Directly downloading files from Box
This works fine for enterprise users of Box, but if you are using the free version of Box, you will see a Box error page, like this:
Kerika+Google, our integration with Google Drive, and Kerika+Box, our integration with Box, are very similar in terms of user interface, but the underlying cloud storage platforms are different in some subtle ways.
One of these has to do with the way images that are added to a canvas are named: when you add an image to a canvas, either by using the Upload button or simply by dragging and dropping the image from your desktop onto the canvas, Kerika will show a small thumbnail of the image on your canvas.
The thumbnails provided to Kerika by Google are better than those provided by Box in a couple of ways:
Box’s thumbnails are square, which can result in a cropped view of the image; Google’s thumbnails show the entire image.
Google’s thumbnails can be resized nicely on the Kerika canvas, simply by selecting it and then dragging on one of the corners; Box’s can’t.
If you rename a Google thumbnail and take off the original file extension, e.g. you rename “picture.jpg” to be just “picture”, the thumbnail still renders correctly, but Box’s doesn’t. (Because Box relies on the file extensions to detect the file’s MIME-type.)
There are some other quirks with the way Box and Google work, but most of them are going to be invisible to most Kerika users.
When you first use Kerika, your browser has a reassuring sign that your connection to our servers is being encrypted:
No warning when you first use Kerika
But as soon as you open a card that contains any attachments, e.g. files stored in your Box account if you are using Kerika+Box, this reassurance would disappear, and instead you would see a warning about “Mixed Content”, which basically means that some of the data shown on your Kerika page was coming from a source that wasn’t using HTTPS.
Why there is a mixed content warning
This was because of a small bug in how we were dealing with the thumbnails we got for files stored in your Google or Box account: for faster performance we were caching these on our own Amazon S3 cloud storage (so we wouldn’t have to keep getting them from Google/Box every time you open the same card.)
It turns out that we weren’t fetching the thumbnails from S3 using HTTPS, which meant that as soon as you switched to the Attachment view of a card, your browser’s address bar would show the “mixed content” warning.
There was no real vulnerability resulting from this, but it did interfere with the user experience for that minority of users who like to keep a sharp eye on their browser’s address bar so we have fixed that with our latest release.
Now you should always have the warm reassurance of seeing the green secure site symbol on your browser when you open a card!
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.
Since we use OAuth 2.0 to let people sign up (and sign-in) using their Box or Google IDs, Kerika never actually sees any user’s password.
But, a lot of our users don’t quite understand how OAuth works, and they expect that when they go to the My Account screen in Kerika, they should be able to change their password right there.
Well, we aren’t going to move away from OAuth because we believe that’s a far more secure arrangement than having Kerika manage your password, but with our new release we are making it easier for people to figure out where they should go to change their passwords:
Change Password
If you go to your Kerika account (http://kerika.com/my-account) and click on the Change Password button, it will take you to either Box or Google website where you can change your password.
A small “feature”, but one which we know will help smooth the way for at least some of our users 🙂
We did a quick refresh to Kerika today, and we will be quiet for a while our development team — which is based in India — takes a well-earned Diwali break for about 2 weeks.
Here’s another new feature: you can create a new Box Note or Google Doc (depending upon whether you are using Kerika+Box or Kerika+Google) from within a card itself, and have that attached automatically to your card.
Adding a new Box Note
A single mouse-click is all that it takes to create a new Box Note or Google Doc, add it to your card (on any Task Board or Scrum Board), and open that Box Note / Google Doc and start using it.
When you are done editing your new Box Note / Google Doc, you can come back to Kerika and you will find it is already attached to the card where you were working!
All in one mouse-click!
One small adjustment you might need to do: many browser will automatically block pop-up windows. When you create a new Box Note or Google Doc, Kerika tries to open it immediately in a new browser tab, so that you can start using it.
If your browser gives a warning about a pop-up window, please allow pop-ups from Kerika — this is the only use of pop-ups by Kerika, and it makes a great feature even better!
We were at Boxworks14 last week, and had a great time!
We met a bunch of interesting folks, including Heidi Williams, Senior Director of Platform Engineering, who — along with Peter Rexer and others from her team — gave some really insightful deep-dives into Box’s technology stack.
(Among other things we learned that we could improve the Kerika user experience by changing the way we do OAuth 2.0 with Box.)
Keynote speeches were amazing: the hyper-kinetic Aaron Levie made for a rousing start, but the real star was Jared Leto who not only brought his Oscar onstage, but in a jaw-dropping move handed it over the audience for people to take selfies with while he blithely continued with his “Fireside Chat”.
Jared’s move even upstaged Aaron, which is pretty hard to do (as you will know, if you have ever encountered Aaron in the flesh…)
Other great speakers included Jim Collins, author of Built to Last, Vinod Khosla of Khosla Ventures (and, originally, Kleiner Perkins and Sun Microsystems), and Andrew McAfee from MIT.
Here at Kerika, we often get asked how we do Scrum as a distributed team.
Here’s the model we have evolved, which works for us mainly because we are the very essence of a distributed Agile team: we have people working together on the same product from locations that are 10,000 miles apart!
And this means that we are the most enthusiastic consumers of our products: we use Kerika to manage every part of our business and we only build what we would ourselves love to use.
Here’s the basic outline of our Scrum model:
Kerika’s model for 2-week Sprints
Each Sprint is 2 weeks long: that that works well for us; other folks might find that 3 weeks or 4 weeks i better. Pick what works for you.
Each Sprint begins with Sprint Planning, where the Scrum Team gets together with the Product Owner to decide which cards will be pull from our main Product Backlog into the Sprint Backlog.
Each Sprint is organized as a separate Scrum Board: this makes it really easy for us to concentrate upon needs to get delivered in that particular Sprint, without getting distracted by what was done in the past or what remains to be done.
And Kerika makes it really easy to pull cards (literally!) from the Backlog onto a Scrum Board, and then hide the Backlog from view so it doesn’t distract the Team while the Sprint is underway.
Half-way the Sprint, at the end of the first week, we do a gut-check: does the Sprint look like it is going reasonably well? We don’t ask if it is going perfectly: almost no Sprint does; what we are looking for is any indication that the Sprint is going to severely under-deliver in terms of the Team’s commitments to the Product Owner.
We could do these gut-checks every day during our Daily Standups, but in the first part of a Sprint cycle these can often give us false positives: it’s easy to tell early on if a Sprint is going to be disastrous, but it’s hard to tell for sure that it is actually going to end well. But about midway through the Sprint we start to have a more reliable sense for how things may turn out.
In keeping with the Scrum model, our goal is to complete a potentially shippable set of features and bug fixes with each Sprint, although this doesn’t necessarily mean that we will always ship what gets built after each Sprint. (More on that later.)
For each feature or bug, however large or small, we make sure that we have design and testing baked into the process:
An analysis document is prepared and attached to the card, either as a Google Doc or as Box document. (We had been using Kerika+Google exclusively for years, but have recently switched to Kerika+Box since we completed our Box integration.)
The document is often just a few paragraphs long, because we always take cards representing large features (or other big work items) and break them up into smaller cards, so that no card is likely to take more than a day’s work. Kerika makes it really easy to link cards together, so it’s easy to trace work across multiple cards.
For bugs, the attached document describes the expected behavior, the actual behavior, and the root cause analysis. Very frequently, screenshots showing the bugs are attached to the cards.
For new features, several documents may be attached, all quite small: there may be a high-level analysis document and a separate low-level design document.
For all features and bugs, we do test planning at the time we take on the work: for back-end (server) work we rely primarily on JUnit for writing automated tests; for front-end (UI) work we have found that automated testing is not very cost-effective, and instead rely more on manual testing. The key is to be as “test-driven” in our development as possible.
There are several benefits from doing formal planning, which some folks seem to view as being antithetical to an Agile model:
It helps find holes in the original requirements or UI design: good technical analysis finds all the edge cases that are overlooked when a new feature is being conceptualized.
It helps ensure that requirements are properly interpreted by the Team: the back-and-forth of analysis and reviewing the requirement helps ensure that the Product Owner and the Team are in synch on what needs to get done, which is especially important for new features, of course, but can also be important to understand the severity and priority of bugs.
It deliberately slows down the development pace to the “true” pace, by ensuring that time and effort for testing, especially the development of automated tests, is properly accounted for. Without this, it’s easy for a team to quickly hack new features, which is great at first but leads to unmaintainable and unstable code very soon.
At the end of the 2-week cycle, the Team prepares to end the Sprint…
We like to talk about Sprints as “buses”: a bus comes by on a regular schedule, and if you are ready and waiting at the bus stop, you can get on the bus.
But if you are not ready when the bus comes along, you are going to have to wait for the next bus, which thankfully does come by on a regular 2-week schedule.
This metaphor helps the Team understand that Sprints are time-boxed, not feature-boxed: in other words, at the end of every 2 weeks a Sprint will end, regardless of whether a feature is complete or not. If the feature is complete, it catches the bus; otherwise it will have to wait for the next bus.
And here’s where the Kerika team differs from many other Scrum teams, particularly those that don’t consume their own products:
At the end of each Sprint, we do the normal Sprint Retrospective and Show & Tell for the Product Owner.
But, we also then take the output of the Sprint and deploy it to our test environment.
Our test environment is the one we actually use on a daily basis: we don’t use the production environment as often, preferring to risk all of our work by taking the latest/greatest version of the software on the test environment.
This forces us to use our newest software for real: for actual business use, which is a much higher bar to pass than any ordinary testing or QA, because actual business use places a higher premium on usability than regular QA can achieve.
(And, in fact, there have been instances where we have built features that passed testing, but were rejected by the team as unusable and never released.)
This is illustrated above: the version of Kerika that’s built in Sprint 1 is used by the team to work on Sprint 2.
This is where the rubber meets the road: the Kerika Team has to build Sprint 2, while using what was built in the previous Sprint. If it isn’t good enough, it gets rejected.
At the end of Sprint 2, we will release the output of Sprint 1 to production. By this time it will have been used in a real sense by the Kerika Team for at least 2 weeks, post regular QA, and we will have a high confidence that the new features and bug fixes are solid and truly usable.
We could summarize our model by saying that our production releases effectively lag our Sprint output by one Sprint, which gives us the change to “eat our own dogfood” before we offer it to anyone else.
This website uses cookies to improve your experience. We'll assume you're OK with this, but you can opt-out if you wish.AcceptRead More
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
