Job ter Burg:

There are some practical issues, though. Time being a major factor for most of us. Also, don't forget that beta testing is more than just liking or disliking features, it is about test driving the software in the real world, to see if nothing is broken.

I certainly understand the issues involved.  The idea is something I have thought about over the years, nothing more than that.  I am certainly not calling anyone out.  

It's a tough situation for Avid too: beta testers are needed to test out real-world  situations, but the people who really need to test don't have the time or the needed hardware to do it or both.  I have been a beta tester before but turned down the most recent invitation....because most of the shops I work at these days have gone over to FCP and I am just not using Avid enough in the real world to be  a good tester.

Job ter Burg:

hat this arrogant company overcharges us for

Totally different issue for a different thread!

I like your hypothetical "thread".  However, is this much different from what we are going through now?  The only difference is that Mods can say "I had no idea this was coming out..."

Job ter Burg:

betatesting moderator x:

We have no influence on what is actually released or not.

This is a bit extreme, but there is a bit of truth to it.   Beta is for testing, not design.  If Avid puts "design" out to a popular vote, nothing will get done.  As I stated, I really don't care about bin color, clip color etc., but I really would like to see Avid re-vamp the way effects are handled, more like DS or FCP.  So does Avid put that out for a vote?  What becomes #1 priority and what gets pushed down the list?  Avid walks a fine line with its current user-base and the new editors coming to the market.

I am glad I am not a product designer at Avid in the current product development structure

switthaus:

is this much different from what we are going through now?

I think the difference could be that mods might be perceived more as part of Avid than as part of the user base here.

Beta is for testing, not design.

Precisely.

Hi all,

drbgaijin:

But I LIKE the advanced keyframe mode without having first and last keyframes in place!

No, you don't; everyone hates them.  Just read the thread if you don't believe me.  

switthaus:

I like your hypothetical "thread".  However, is this much different from what we are going through now?  The only difference is that Mods can say "I had no idea this was coming out..."

Right.  At the moment, nobody on here is saying I'm arrogant or condescending or out of touch with the user base, because I am the user base.  I like it that way.

ciao,
Carl

p.s. I realize people may say I'm arrogant or condescending about things other than NLE UI design.

camoscato:

drbgaijin:

But I LIKE the advanced keyframe mode without having first and last keyframes in place!

No, you don't; everyone hates them.  Just read the thread if you don't believe me.  

Yes Sir! I humbly appologise for getting into the wrong thread!
I will start my own "I love the Advanced Keyframe" thread and watch as it grows by 1 new post of support every month!

Maybe I am a bug?

Regards,
Douglas

camoscato:

Hi all,

drbgaijin:

But I LIKE the advanced keyframe mode without having first and last keyframes in place!

No, you don't; everyone hates them.  Just read the thread if you don't believe me.  

Wow - I thought I liked the advanced keyframe mode, too, but now reading this I realize I must have been mistaken

Cheers

BarkinMadd:

Wow - I thought I liked the advanced keyframe mode, too, but now reading this I realize I must have been mistaken

Steve,
I am guessing, but I think that editors like Larryand friends probably use AfterEffects very much for more complex effects and use MC's effects for more straightforward (3 keyframes only) effects. So having the basic keyframe mode together with the first and last already set was a very efficient way for them to quickly do this.
I never have gotten into AfterEffects, and have been learning AvidFX and BCC filter fx from the ground up. If I remember correctly you have also spent quite a lot of time learning AvidFX and the BCC filters.
I appreciate the problems Larry and editor friends are experiencing, and have no objections if Avid can return the keyframing to its previous way of working.
But the point I wanted to make was that not everyone is unhappy with the new situation introduced with MC5.

Regards,
Douglas

adam5000:

Just upgraded from MC 3.5 and I'd read about it before, but now seeing it first hand, I don't get why there would be a need to suddenly limit the user interface options

I have been in mourning since updating to MC 5 because the new  "color choices" are so limited and I can no longer set a bin background color as a default.  In addition I have no choices to change the shape and style of the buttons.  Also I have no way to set a default font for the project window, meaning every new project I create I have to change the font from the unreadable 9 point to a larger, more readable font. The same is true for the project window background colors.

Are these the kinds of interface items you're missing as well?

For me the whole discussion on Beta testing is a red herring.  In fact I doubt that there was much wrong with MC5's Beta testing.  

By the time a release is in Beta the features and changes are in place as specified by the design team. My understanding is that Beta testers are asked to test that the features and changes included in the release work as the designer specifies they should.  For the most part MC5 did.

No amount of adding extra Beta testers, or who actually does the beta testing, will change a releases features or how they are designed to work!!  The testers help engineering identify possible problems with changes not working as expected. They probably even give Avid a reasonable early heads up on what some users will not like about changes.  But by beta those changes are in place come H.... or high water.

The problem for me is really at the design stage. There a thorough understanding of the product and the 100's (1000's) of different workflows their users have is IMO essential. Also an awareness of when designs concept's MAY impact on any of those workflows and an openness to pass on this info to end users....  should the "greater good" dictate going ahead with the changes.

It is at this early stage that the highest quality of consultation and a decent brains trust is imperative. This is where I think contributions from people like Larry would be most significant.  

The design task has the potential to be incredibly thankless. The simple adage that you can only please all of the users some of the time, some of the users all the time but never all of the users all the time springs to mind. 

I would have thought that a relatively simple way to keep users (relatively) happy would be to set and achieve a goal of fixing at least 4 items from any of the long standing wish lists with each major upgrade.

Overall, when it comes to design objectives, as I've stated before I believe the primary focus should be on changes and new features that enhance the concepts of momentum and speed in the workflow, not hinder them. Simply put, that means achieving the shortest distance between point A and point B. I also strongly believe that design should take into account and correct, as much as is possible, the long standing individual weaknesses in the GUI that have been identified and complained about (in some cases) by users for many years. Any feedback I would offer would be guided by these principles.

Larry Rubin:

as I've stated before I believe the primary focus should be on changes and new features that enhance the concepts of momentum and speed in the workflow, not hinder them. Simply put, that means achieving the shortest distance between point A and point B.

                                                                    I would also add the lack of *realtime functionality* at the software level. There is no reason why so much has to be rendered. Much more layers of realtime can be added *at the software level.* Sony Vegas does this well, so why can't MC ? There are a few ways Avid *could go regarding this issue:

1. Enable hardware support of 3rd party solutions such as AJA, BlackMagic, MOTU.

2. Program driver's for use on graphics cards, such as nVIDIA's CUDA or Matrox's, or ATI's hardware GPU accelerator engines, so rendering could be hardware based (Thus much faster).

3. Forget all of the above and use CPU power alone (Vegas does this, thus making their software run well on just about any laptop PC)

4. Ignore this suggestion and rely on unrealistically expensive sales of proprietary hardware I/O boxes, such as the MOJO DX or NITRIS DX.

Mark Job

AndrewAction:

The testers help engineering identify possible problems with changes not working as expected.

This is an important point. Beta testers are not necessarily there to consult on design and functionality choices, they are used to catch bugs. This is why the time commitment is so high, and why people like Larry and the other commenters here are not appropriate for that work and wouldn't want to do it anyway.

This just means however, that the discussion here is caught on semantics: what we are really calling for is a user-advocate/consultant to be allowed to give feedback in the design stage (call it alpha, beta, whatever) rather than after changes have been committed -- and not for the sake of debugging but in regards to decisions on functionality and on priorities for development (like fixing long-standing problems and meeting user feature requests). 

If Avid is not willing to have a more generally open development process (like actually tracking bugs and requests with a public ticket system, as many software developers do today), they could at least do this. There are plenty of good candidates to choose from for this role.

lunelson:

what we are really calling for is a user-advocate/consultant to be allowed to give feedback in the design stage

Hi all, to help the designers to shape the software there's the Feature request forum: all of the customer wishes, many of which largely asked for well before the birth of the Avid forums, are recorded over there, and as far as I recall nobody asked for something like the so-called-smart-tool (I agree with whoever called it the stupid tool), or to modify the CTRL key behaviour.

switthaus:

If Avid puts "design" out to a popular vote, nothing will get done.  As I stated, I really don't care about bin color, clip color etc., but I really would like to see Avid re-vamp the way effects are handled, more like DS or FCP.  So does Avid put that out for a vote?  What becomes #1 priority and what gets pushed down the list?  Avid walks a fine line with its current user-base and the new editors coming to the market.

Scott I think here you come to the core of the problem. Avid has with MC5 introduced functionality that IMHO nobody had asked for. That doesn't mean it is good or bad. But in combination with the way it was introduced it is logical that people question both the design team/procedure and the testing team/procedure. Job and Larry also point to an issue that is related to the communication between a design team and a (beta) testing team and what position a moderator gets into from the end users perspective.

I have no idea what happened at Avid but it seems that the design team underestimated the testing cycle the new functionality (smart tool) had to go through to reach an acceptable functional level for the professional editor. Now the damage has been done and the issue is how to correct it and restore faith in the patch procedure.

I agree 100% with your suggestion that it would be great if editors like Larry would join the beta test team but only if this includes good communication with the design team. Having taken part in software development myself I know how essential good communication between the design team and testing team is. If Larry had the time and if there are no conflicts of interest with the pentagon channel he might also get paid for his feedback by supplying him personally the latest hardware for free.

Basically I believe Avid is required to invest more in development in cooperation with its users. Believing all the knowledge needed to develop all Avid products to the next stage is internally present inside Avid is wrong. I know this is already being done but Avid needs to open up a little bit further. I do understand that by involving more people into the development the risks of leaking valuable development information to the public also increases 

ok, going to give my opinion now,

I have waited a bit, read the thread through and came to the final conclusion on MC5:

MY PROS

-STABLE!, I run it 12 hours a day... Very few times it crashes.
-audio RTAS tools, GREAT! big step forward
-AVCHD import, good, BUT takes a lot of time though...
-approved for Windows 7 64bit, one of THE most stable windows version I have yet worked on

MY CONS

-Smart Tool: I don't use it, don't want to use it, sometimes I struggle with it after selecting itself again.
-keyframing simple effects... waste of time to check the effects for spline to linear... please make linear again default!

BUT these time-consuming CONS, are nothing compared to the STILL NOT AVAILABLE qt reference files from AMA. There you have something 'superfast' like AMA to speed up your workflow. And it is not possible to export it through qt ref. Seriously... this function WAS available in MC3.5, but they disabled it because, MAC users couldn't do that. Now, what happened to that. It's like having the fastest car in the world, but in traffic jams, it's useless...

Just my point of view. I don't care about UI colors and tricks, just performance and timesaving. (Background render would fit perfectly into that, but this is a thread about MC5, not about future requests.)