>
> This program drives me nuts. Despite its obvious potential, it is
> hopelessly counterintuitive.
>
>
> It aims not to be counterintuitive. It may do some things differently than,
> say, Adobe Premiere (a usability disaster) or iMovie or Kdenlive, but it all
> fits in a broader vision that makes it both more efficient and still easy
> (or easier!) to use.
>
> Take splitting for example. In pitivi, it is modeless. You may have to take
> a look at the section on splitting in the user guide circa page 19.
>
I have to agree w/ Jeff on this one. It doesn't seem to be counter-intuitive
(where intuition says "use it like this" but the application works the exact
oposite). I'm not schooled in any other video editing software and found the
tool to be immediately usable and didn't have a problem understanding it's
functions or how to use them. My difficulty came with it's bugs (and it
still has some - sometimes I can't render, just doesn't do it, I have to
close and re-open, then it will do it).
> The tools in the Timeline bar never become active. And there isn't one
> blessed word in the absolutely inadequate documentation on the subject.
>
> I have a hard time believing that 25 pages of documentation can be
> absolutely inadequate.
>
> That being said, I can indeed see that there is no mention that "the
> timeline toolbar does not become sensitive until you actually select a clip
> to operate on". I guess I should add that to my neverending todo list for
> the manual, but I don't know where you expect this information to appear in
> the manual exactly?
>
Maybe not in the manual - why not enable all the tools, but have a pop-up if
the tool is used when it can't perform it's function? They click scissors w/
no clip selected - tell them a clip must be selected first, etc.
I've been thinking of making a new official screencast when the next version
> comes out, but it's taking a long time to come out. And making screencasts
> takes a *long* time... at least if you want them to match the narrating
> quality of the one I did three years ago for 0.13.1.
>
Aha! Now this is a key point. A very very key point. Consider the irony:
We have the creator of a video editing software who says it takes a very
long time to create a screencast of his tool, and no doubt will be using his
tool to do the final edit / rendering.
Honestly, I don't know why it would be so difficult. Yet, I too have found
it to be so, and my very use of the tool is this purpose, make a screen
cast, edit it, render it. And if this tool isn't timely for the creator of
the tool, imagine the frustration from all the other users.
A typical scenario of mine is to take several different screen casts and put
them together, cutting out unwanted parts, etc, and then rendering. I have
found pitivi very difficult in the long haul to do this easily. Each release
has gotten better, and now it is a lot easier, but still has some quirks
(like playing in the preview, the video is delayed. I know the screen has
changed in the video, but the player hasn't yet reflected the video change,
if I pause and click that frame "bingo", it updates).
I'm entirely open to constructive criticism, for example saying "this
> particular section is unclear" or "there needs to be a new section on how to
> accomplish X", but just saying that the entire manual does not care about
> newcomers and that we should "learn" that "everybody walks before they can
> run" is a bit rude. It's not like I don't know that there surely are some
> things that are hard to grasp to newcomers, I just can't magically guess
> what they are and I can't magically find 20 hours a week to write the thing.
> Writing documentation isn't exactly trivial and I've been pretty much alone
> in writing the contents in my spare time.
>
I'm with you 100%. I'm in software development and there are a couple things
I've learned in the process:
1. You make your app dummy-proof, the world comes up with a better dummy.
2. You test the app in the way it was meant to be used, after all, you're
the creator and you know how it should be used. The user doesn't know your
intent so they find the most arcane ways of trying to accomplish things and
that's where 90% of all the complaints come from.
3. Typically programmers are left-brainers, so all the documentation is
written literal word-for-word. Most users (and probably more-so in the video
editing world) are right-brainers and don't understand word-for-word literal
statements and instructions. Really, this is just a frustration that can't
be avoided easily, no matter how clear you spell something out, people still
amaze me at taking things exactly the opposite way than what was stated.
It's almost like dilbert in real life sometimes.
My recommendation on documentation for this project: make it all short
howtos. Most people already know what they want to do and instead of having
to read the entire section on editing to find the 2 things they wanted to
do, if there was a "howto" for each of those items they could skip through
the howtos and just read/watch the two or three they really need. The manual
could be more of a discourse of the details around the howtos, why they work
the way the work, etc...
And I'd do the howtos in screen-capture format. A picture is worth a
thousand words and a 60-sec 15fps video would be worth 0.9 million words -
imagine having to write that many words in a document vs spending 5 min to
capture/clip/render a quick "here's how you do XYZ" howto video.
I'm very serious about this idea and hope you consider it. Using the 80/20
rule, 20% of all the functions (the most commonly used ones) can be covered
within a few minutes and would "train" 80% of all the users of the tool
immediately. For the other 20% of the users that wanted more detail, there's
the manual, a forum, this list, etc.
On that note, a forum can quickly become a FAQ - just make the best example
of a commonly asked question and it's answer "sticky". Again 80/20. 80% of
the people going to the forum will have their answers in just 20% of the
forum discussion - the stickys.
Jeff (and all other developers involved), thanks for taking the time to
produce this awesome tool. It has bugs, which are mostly just quirks now
(bug - can't get around it, quirk - close and re-open and it's "fixed" -
inconvenient but not a show-stopper), and it's come a long way in just two
releases (about a year of development?), and I find it invaluable when it
comes to editing my videos. I looked at that other video editing tool that
was mentioned a few days ago about merging w/ them, etc. I gave up
immediately. Seemed too difficult to use right out of the box. It was so
un-important I've already forgot it's name... Started with an O I think...
Here are a couple suggestions from my usage (besides fix the bugs):
1. Have a timeline direct editor. Imagine a pop-up that lists each
video/audio clip, where they "appear" in the render, whether the audio/video
portion is there, at what level opacity, how long it plays, and which
segment of the video clip to start this "insertion". - it would be a direct
representation of what you're having to store in memory/project. Here's why:
I have 3 clips sliced and diced. I drag'n drop, cut, delete, etc for 30 min.
Click render. 20 min later when I watch the final I see I got one of the
clip points wrong by 3 seconds. I have to slide everything else to the right
(to make room), stretch out the clip or reduce it a little at a time, at
full zoom - very slow process, butt each clip back up to take out my temp
workspace/room, re-render, find out it's off by 1.5 seconds now, go through
the process again.... If a pop-up with all the timing info was available I
could easily just make the adjustment using the numbers and my keyboard - a
few seconds of work, and I'm rendering again... I know this is asking a lot.
A whole lot. Consider if this were outside pitivi, it would be a lot easier.
If it were in pitivi and you made this type of edit the easiest thing
(code-wise) would be to save the project with the new settings, close it,
and re-open it to "refresh" the now edited timeline. Maybe you could change
the clips around as the person is editing it, but I think that would be
harder. If it were a stand-alone app, the project would be closed, the user
does the edits and saves, the project re-opens. If it's an external app, the
next step would be to have a "render" button on it. It would become pitivi
minus the timeline and previewer. You can still leave the rendering in
pitivi if you wanted, pitivi could take command line arguments indicating
the project and to render it to "this" output file. That would keep the
external editor to a minimum.
2. The ability to save user-defined render profiles. I always have to change
the options. Every time without fail. If I could instead edit a render
profile and set the dimensions/fps/audio channels/output formats/etc and
then reload that profile to the current project it would make rendering a
lot easier. Right now I have to go back to a previous project (or a
screenshot of it's render settings) to setup my "new" project correctly. And
when you produce several different formats from one project, this gets to be
a pain.
Again, thanks so much for your hard work. I appreciate it, it's made my life
easier by far.
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Pitivi-pitivi mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pitivi-pitivi
