Blog

Getting Things Done

Monthly Archives: November 2010

Penn State Ag Sciences College Selects Teambox to Get Things Done

November 30 2010 - CA 001, Cases, Collaboration, open-source - 1 Comment

Chris More is hands down my favorite Nittany Lion and he does not play for the Football, Basketball or Lacrosse team. No he plays for our Team and for that I cannot say more than he does in the case study we just published on our site.

A small excerpt:

“Prior to implementing Teambox, we used email groups as a method to send a message to the group to solicit a response. Anytime someone used email instead of Teambox, we asked them to create the message in Teambox. It quickly caught on and now my inbox mainly includes notifications to check out conversations in Teambox, which is a much more efficient and pleasant use of my time.

Another major benefit to the collaboration was the ability to look back at what was discussed or shared. Catching up on a conversation and joining an already started thread was much easier and logical using Teambox than sifting through emails.

When surveyed, the Penn State Team stated that the top three advantages of Teambox over previous communication methods are:

  1. Simple interface without every bell and whistle to confuse users
  2. Very limited training to get instant benefit
  3. Ajax interface”

Read the entire case study here:

http://teambox.com/l/penn-state-case-study

And thank you Chris, for giving us the chance to show you how we change the way people work and get things done!

Karl Goldfield

CA 001

@karlgoldfield

New technologies

November 29 2010 - Inbox webcomic - Write Comment

New technologies

Isaac Murgadella

Illustrator

@ismurg

Our webcomic appears: Inbox

November 29 2010 - Inbox webcomic - Write Comment

For the last 100 years traditional comics strips established themselves as vital cultural and pop references. Webcomics are their natural evolution. Over 10 years running and today it’s possible to find a webcomic about every theme. From talking about recent news to simply making us smile while sneaking in a 5-minute coffee-break and browsing our favorite pages. Strips like Penny Arcade, PVPOnline, and xkcd have deservingly built a strong presence in online media.

Webcomics are now basic elements of the net — just like a Youtube video or a blog… or slideshows of cute kittens. They’re easy to read and spread (well, kittens have their own ways to appear always in our inbox…)

And today, Teambox begins its own adventure into this field with the ‘Inbox of Teambox’ series. Every Monday, Wednesday and Friday you’ll find new strips here on the Teambox blog. We’re hoping we can continue to make it fun to get things done and be a part of that smile on your face on your next coffee-break!

Isaac Murgadella

Illustrator

@ismurg

Giving Thanks – What would I do without the web?

November 26 2010 - Collaboration, Insight, Teambox - Write Comment

Thank you binary, fortran, VT100 and C++. Thank you Digital and International Business Machines and haha Al Gore (Well the people he ‘borrowed’ credit from). See my life is what it is today thanks to the global computing essence dubbed ‘the internet’.

Sorry nature lovers and those who want to stay in the past, but I love it. I love my net book, my Driod, my blog and website, my 25 email addresses, my Teambox account, my team of developers in Barcelona, my virtual assistant in the Phillipines, my facebook account, my linkedin account, my twitter account, StumbleUpon, Google Search (I know, I know) and Trillian oh could I go on? Indeed. Read the rest of this entry »

Karl Goldfield

CA 001

@karlgoldfield

Performance: One step back, two steps forward

November 24 2010 - Programming, Teambox - 5 Comments

In this post we explain technical details about how Teambox’s backend is built.

As many of you may have noticed, Teambox was performing poorly this monday and tuesday. This was the result of my efforts optimizing our slowest and most frequently accessed actions.

If this didn’t make any sense, let me explain first. Teambox is a database intense application. This means that a lot of content is constantly being generated by the users and we offer it in a lot of ways, since the user experience is heavily customized for each user.

After some research using New Relic RPM[1], I concluded that the overview page could have some optimizations, as it was slow and by far the most used page. So I rolled up my sleeves and started reducing the number of database queries while keeping the exact functionality. In my development machine I noticed an improvement of about 50% in both number of queries and memory usage. Great news! Well… not so fast, it turned out that in production not only I didn’t observe this improvement, but we started having serious issues with our database and the response time grew significantly. Read the rest of this entry »

Jordi Romero

Teambox CTO

@jordiromero

Change with a Healthy Dose of Collaboration

November 22 2010 - CA 001, Collaboration - Write Comment

We have been growing over here. With growth comes change, it is inevitable. The goal is to plan change and manage the distractions that come along for the ride. We do our best to make sure everything is expected, but sometimes surprises good and bad come your way.

Sometimes, what looks like a good surprise could be a less than stellar one in disguise.  A recent example for us was our Lifehacker post at the end of September. Let me make something very clear; it is unbelievable that we got this post and we are grateful. This is in no way a complaint as it drove traffic and continued to prove that the market values our offering. But it was a surprise, and in business even good surprises are tough.

We spent the week prior to the post in executive meetings trying to outline a plan that would help educate and empower our current user base. Building tools like user guides, starting online web trainings and focusing on internal efforts all to help the user get the most from the system. Then we woke up on the morning of the 29th and well we had to change.

Jumping into Talker and Teambox, the buzz was already alive. We had more questions, more clients to help and more front line efforts to mitigate. We also could not afford to ignore the buzz and now had to share the news of the post with anyone and everyone. Simply put, everything changed.

While we had to adapt, it was not as difficult as it might seem. We had the tools, the ones we promote, and used them to quickly change course. The results? A traffic boon that continues even six weeks after the post. And now, the week of head spinning adaptation seems a distant memory. The new user guide is up, their is a recorded web training and we have added some really cool stuff to the system. I am proud to say that if it were not for the Teambox team and the Teambox tool, we may not have succeeded.

That is why I am proud to represent this group. Thanks team, you rock!

Karl Goldfield

CA 001

@karlgoldfield

Fire your designer

November 19 2010 - Programming, Startups - 26 Comments

I’ve been in the developer and startup environments for the past years, and one pattern kept coming up: Programmers evolve to the latest technologies and frameworks, but designers are still doing the same thing they did in the year 2000.

It seems to be accepted that, while programmers learn new languages constantly, designers should only worry about aesthetics. And so we all accept that we should stop using the best tools available so that their work can fit into the team.

Let’s look at a couple situations that might sound familiar:

Case 1: The designer that doesn’t know HTML

I’ve seen companies with “usability experts”, which design sites in photoshop or illustrator and then send them to the programmer team to build a layout. Seriously, why can’t this person learn HTML? It’s their job to produce results, after all.

Case 2: The designer that only does HTML

This is by far the worst case. In the typical case, you’re looking at your site thinking “it’s nice, but it could SO use a better design”. So you hire a designer.

The thing is that now somebody is making a completely independent design, that doesn’t take into account your existing stylesheets, and uses completely different conventions. By accepting her new layout, you’re now increasing your code debt. You are now dealing with legacy parts of the design, the new one and there’s a coding-style clash.

But you buy into it, and you decide to use that design. You invest a whole day merging the design into your application (time is money, wasn’t this the designer’s job?), and translate the static html into your favorite %w(ruby python php node java) template system, and it’s done! Your designer doesn’t have a clue of how it works. Not to mention the version-control system…

The day for changes in the design comes, and now you’re screwed. You can’t do styles yourself, and your designer can’t understand your code. What now? Options:

  • She edits the original static files.
  • She fires up the inspector and tells you exactly what to change.

Both options sound like a waste of non-designers time. In the first case, you spend big time merging in changes from obscure css files. In the second case, you both need to spend time into the re-design together.

But there’s another option:

  • Hire a designer that understands developer workflows and can save you time while building the product with you.

Because we need to understand that…

Web design is industrial design

And a design that can’t be used in the factory won’t make us millions. Your resources are limited, and you need to streamline the work to keep the wheel turning. Anybody who’s not aligned with it is costing you time and money. Designers are no exception.

  • Git makes your programming workflow so much easier, why not teach your designer?
  • SCSS or SASS makes css more fun, why settle for something worse?
  • Most changes can only be seen in the real application, why not set up a development environment for your designer?

Tomorrow we setup a little trial for a designer candidate. We will be building a site in some hours, taking full advantage of Git, HAML and SASS with her. That sounds like a great real-world use case. (We’ll be posting the results!)

Conclusion

Design and code and so closely related that it’s hard to be doing only one of them anymore. It’s time to learn new things.

Build a self-improvement culture in your company –if you’re reading this, you’re probably doing it right! Let everybody grow into that. Try to learn from designers, and be more user-oriented. Try to teach designers to be more development-oriented. Advance together.

But if all this doesn’t work, fire your designer.

Pablo Villalba

Teambox founder

@micho

Musicians and poets and artists

November 19 2010 - Startups - Write Comment

I think part of what made the Macintosh great was that the people working on it were musicians and poets and artists and zoologists and historians who also happened to be the best computer scientists in the world.

Excerpt from “Good artists copy, great artists steal“

Pablo Villalba

Teambox founder

@micho

Don't forget the User Experience

November 16 2010 - Design - 1 Comment

Apple’s documentation for developers has good tutorials on how to get started, and how to master each of their development libraries. But where it really shines is in its Human Interface Guidelines.

Because they want developers to build great applications, they went as far as helping you define your product definition statement:

Finally, examine the set of features you intend to deliver. With the image of your user audience in mind, try to distill the list of features into a single statement, a product definition statement, that describes the solution your product offers and who your users are. For example, the desktop iPhoto application allows users to, among other things, organize, edit, share, print, and view photos. But a good product definition statement doesn’t just focus on features, it also describes the intended audience. Therefore a sound product definition statement for iPhoto could be “An easy-to-use photo management application for amateur photographers.“ Notice how important it is to include a definition of your user audience in the product definition statement: Imagine how different an application iPhoto would be if it was designed to be “an easy-to-use photo management application for professional photographers.”

They also walk you through the design process, helping you build applications that are better understood by the user, easier to use, and sell better.

It’s refreshing to read documentation that treats design as the product-defining process it really is. After that, programming is just making it happen.

Pablo Villalba

Teambox founder

@micho