Already have an account?
Go to to login

To learn more, contact our sales team

Customer Driven Development

January 22nd, 2010 by Seth Kenvin

Frequent user interaction aligns our efforts

A month or so ago Andrew Angus of our customer Switch Marketing pointed out that often his firm starts multiple simultaneous projects with a single set of clients. The way our software was working, the participating clients would have to accept individual invitations to each project. He pointed out that this can be a nuisance to his clients, and that sometimes people don’t at first go through accepting each invitation resulting in their not gaining access to every project. So, his recommendation was to change our software such that when two people have been in a project together before, when one of them invites the other to a new project, the addition should be automatic with no need to accept an invitation. We agreed, and built it, and are grateful to Andrew.

Automatic addition of prior team-mates to project means no invitation acceptances which is of course mostly a benefit for video.Market7 users, but Michael Haley of our customer Bars + Tone pointed out to us that after we made that change this also can mean no notification of some new team members’ arrival in projects’ activity feeds. He finds it useful to know when first log-ins happen, which makes sense to us too. So, using our agile development practices, we wrote a story in Pivotal Tracker that when an experienced video.Market7 user first into a project a new project of theirs, that occurance should go to the project’s activity feed.

Next week all of our customers will benefit from both Andew’s and Michael’s good ideas after we release new code that includes the latest customer-driven development ideas which our engineers just completed programming.

, , , , , , , , , , , , , , , , , , ,


Addressing Annotative Player Issues

February 10th, 2009 by Seth Kenvin

Several customers have recently encountered video quality issues in our Annotative Player module. This is from a combination of slack guidance on parameters for video uploads, and of how we transcode video to prepare it for our player. Also the player’s performance efficiency can be improved. As practitioners of test-driven development we regret releasing code that doesn’t work as well as it should.

Fortunately we are also practitioners of agile development and the issue of improving video play is now elevated to the top of our priorities. We released some new code a few days ago and may have additional interim code releases this week. Our next scheduled production release is next Wednesday February 18 in which we plan substantial improvements in our transcoding and playing of video as well as revised guidance on upload parameters.

We greatly appreciate feedback from our customers on their experiences, which can be provided at (also linked to within our service) or by email to We applogize for any problems encountered due to our needing to improve upload guidance, transcoder and player, and we are determined to get that right very shortly.

Some tips in the mean time:

  • Uploading Flash-encoded (.flv) video minimizes transcoding impact since our player is Flash
  • Likewise, bit rates around 800Kbps or lower should mitigate
  • While it’s certainly not our long term solution to this, the “Download” button in the player can be used any time to natively play video in the format in which it was originally uploaded

Thanks to our customers who have helped us assess and address this responsibility of ours.

, , , ,


Production Brief Approval = Agile In Action

December 4th, 2008 by Seth Kenvin

We try to take a light approach to layering functionality onto our Web services, and use agile development for the execution. When a notion seems potentially useful, especially if users request, we’ll build a nub of it with which we and others can experiment, and then consider what are essential extensions for best utility. And we try to balance that such that the new functionality does not distract from existing stuff people are already finding useful.

The ongoing evolution of approval functionality is an example. is used for committee construction of a deliverable that’s subjectively evaluated and naturally people have asked for an ability to approve of that deliverable and/or steps along the way of construction. On the other hand, we do not want to make our application overly weighty in terms of exactly who’s allowed to approve exactly what and exactly how interactions with the approved or unapproved item are modified as a result.

We decided to experiment with approval by initially constraining it to one module. We chose Production Brief for a few reasons. Our first foray in our early November software release, was simply to put a toggle at the top of the production brief that either displayed a red “Dispproved” with “Approve” as a gray, actionable button which when pressed would become a green “Approved” with “Disapprove” gray and actionable.  Once that functionality was out there in use, the merit for a few additional features was confirmed such as a log tracking who did what approval actions for accountability, and also some dialog so people impacting approval state understood implications of their actions. The results is the extent of functionality you can check out in the screen capture below.

So that’s where we are as of writing this blog post. We expect that the approval concept will extend to other parts of such as script versions, uploaded files, and video footage submitted for review. And based on what we hear from users, features within approval may evolve and emerge.  Some aspects may in fact consolidate, for example I’d love to conceive a way for the approval interface to be collapsed to fewer than three buttons. But overall, this is now an area we’ll leave alone for a little while and observe user reactions before we tinker with it more.

, , , ,


Ode To Agile

October 11th, 2008 by Seth Kenvin

, , ,


10 Tips is 8 More Than We Need

March 10th, 2008 by Shannon Newton

On Monday at SxSW I watched Bryan Mason and Sarah Nelson from Adaptive Path discuss the 10 tips for managing in a creative environment. This post focuses only on two tips. Don’t worry, At the end of this, I will list the other eight tips for those of you who absolutely MUST look under the bandage.

What I love about the adaptive path research was how they took a cross disciplinary slice. They spent time studying diverse, creative groups including restaurants, theater troupes, and professional writers among others.

Tip #1: Actively turn the corner

This diagram is of the creative process:

The first half of creating anything involves a divergence of ideas. You start with a single idea and then everyone starts throwing in different ideas that diverge from the original. No idea is eliminated at this stage and often experiments and mini-models are created. Then you turn the corner. At some explicitly defined point, you stop taking in new ideas and start converging towards a single point by eliminating what is unnecessary. This reduces scope creep, release slippage and the dreaded moving target. Eliminated ideas aren’t trashed, simply put into a “future creation/release” bucket.

Tip #2: Kill your darlings

Eliminate the ideas you LOVE that don’t get you closer to the goal first. Don’t eliminate the low hanging fruit or easy choices first. Choose instead to go after eliminating the tough choices from the beginning. By biting the bullet and eliminating the difficult choices first, the low-hanging fruit (those ideas to which you are not attached) becomes easy.

The eight other tips:
3. Cross-train the entire team
4. Rotate leadership
5. Know your roles
6. Practice, practice practice
7. Make the mission explicit to the entire team
8. Leadership is a service
9. Generate the creative projects around the group’s interests
10. Remember the audience

BONUS: Celebrate Failure (after all, it’s part of the creative process)

, , , , , , , , , ,


Approaching The Elephant

January 27th, 2008 by Curtis Schofield

In any exploration there needs to be focus and attention on the right details. We speak of the bigger picture, but very often the bigger picture is obfuscated by our own tendency to identify. The challenge that comes out of identity is using it as the right tool in the right context.

Through-out the software development process, identity shifts both on an individual basis and on the basis of perspective. In order to approach the Elephant our practice of learning and exploring as professionals must move back towards understanding the bigger picture.

Appreciating the bigger picture in the agile process is about respecting how much massive potential exists in the world and how limited our resources are.

It is about creating and publishing humanistic software.

It is about simplification and refinement of our own understanding. Understanding the external and internal models that limit our operation in both the world of software and the world at large.

Most Importantly, it is about transforming the conceptual into the concrete. Just as people cannot eat the sound of toast, our users cannot interact with ideas, they need widgets and buttons and text_fields  (oh my!)

At Market7 we are approaching the collaboration elephant, come join us.

, , , ,