Ok, thanks for the explanation Helena.  Definitely food for thought, we'll discuss internally to see if we can come up with a solution.

Hi Marco

We agree, it would great if we could support realtime updates to the document you are working on.  It is in our backlog, and with your suggestion, we'll be prioritising this.

Thanks,

easyBacklog

Sorry, but we don't agree with this.  Delete is a very rarely used feature, and we want users to think about it before pressing it by mistake.  This is a common web user experience pattern, and whilst you may disagree, we unfortunately think differentiating this destructive feature is important for users.

Hi there

To delete a backlog, I admit could be deemed a bit cryptic, but follows a reasonably standard user experience from other web applications which is to keep less used features in the settings section.  

To delete a backlog, simply go to the backlog, click Settings, and Delete is available on the right hand side.

Thanks,

easyBacklog

Unfortunately at this stage we don't offer any customisation for the cards.  We would certainly consider it if there is demand for it.  If you could explain in a bit more detail why you need it and what you want exactly, we can see if others vote this functionality up.

Thanks for the input.

easyBacklog

Hi Brian

Unfortunately I am really not sure what you are trying to do.

Can you please explain what you mean be history?  Or preferably, explain what your objective is and I will see if I can explain how it is done with easyBacklog.

Thanks,

Matt

Glad you like it, thanks!

Hi Gordon

Would you mind trying again now?  There were wide scale problems last night due to Amazon issues (see http://www.pcworld.com/article/2012852/amazon-web-services-outage-takes-out-popular-websites-again.html) which may have been causing the problem.

Thanks,

Matt

We did a major deployment today, and we came across an error that was causing failed requests with Roger.  It turns out that his backlog was taking just under 6 seconds to render on the server, which is completely unacceptable.

Because of the urgency of this, we've devoted a fair amount of time today to finding a solution, and we've released some updates today that have brought that rendering time down to around 1.5s, so a 4x performance improvement.  Whilst this is good, this is not good enough, and we'll be working to improve that even further.

Obviously there is client-side rendering performance as well, and we'll be considering Torsten's suggestions here too, to ensure the performance remains snappy even when working with large backlogs.

Sorry for the problems, and hopefully we'll have it lightning fast again even for our heavier users.  I expect you'll notice the performance improvements already.

Thanks,

Matt